Security Vulnerabilities Decomposition Katy Anton OWASP Top 10 - PowerPoint PPT Presentation

Security Vulnerabilities Decomposition Katy Anton

OWASP Top 10 @KatyAnton

When the report is published @KatyAnton

Katy Anton • Software development background • Project co-leader for OWASP Top 10 Proactive Controls (@OWASPControls) • Principle Application Security Consultant @KatyAnton

C ommon W eakness E numeration A formal list for of software security weaknesses in: • architecture • design • code Source: https://cwe.mitre.org/ @KatyAnton

NVD: CWE Categories Source: https://nvd.nist.gov/vuln/categories/cwe-layout @KatyAnton

Injection Category @KatyAnton

CWEs in Injection Category • CWE-78: OS Cmd Inj CWE-77: Commmand Injection CWE-78: Argument Inj CWE-78: XSS CWE-91: XML Injection CWE-74 Injection CWE-93: CRLF Injection CWE-94: Code Injection CWE-89: SQL Injection CWE-943: Improper Neutr. of Special El in Query CWE-90: LDAP Injection Source: NVD @KatyAnton

@KatyAnton

Is there another way to look at it? @KatyAnton

Decompose the Injection Data interpreted as Code Input Parser Output Get / Post Data SQL Parser SQL HTML Parser HTML File Uploads XML Parser XML HTTP Headers Shell Bash Script Database Data LDAP Parser LDAP Query Config files @KatyAnton

Extract Security Controls Output Input Parser Vulnerability Encode Output Parameterize Validate Input R R XSS R R SQL Injection R R XML Injection R R Code Injection R R LDAP Injection R R Cmd Injection Primary Controls Defence in depth @KatyAnton

Intrusions (or lack of Intrusion Detection) @KatyAnton

If a pen tester is able to get into a system without being detected, then there is insufficient logging and monitoring in place @KatyAnton

Security Controls: Security Logging The security control developers can use to log security information during the runtime operation of an application. @KatyAnton

The 6 Best Types of Detection Points Good attack identifiers: 1. Authorisation failures 2. Authentication failures 3. Client-side input validation bypass 4. Whitelist input validation failures 5. Obvious code injection attack 6. High rate of function use @KatyAnton

Examples of Intrusion Detection Points Request Exceptions • Application receives GET when expecting POST • Additional form /URL parameters @KatyAnton

Examples of Intrusion Detection Points Authentication Exceptions • Additional variables received during an authentication like ‘admin=true’’ • Providing only one of the credentials The user submits POST request which only contains the username variable. The password was removed. @KatyAnton

Examples of Intrusion Detection Points Input Exceptions • Input validation failure on server despite client side validation • Input validation failure on server side on non-user editable parameters • e.q:hidden fields, checkboxes, radio buttons, etc S @KatyAnton

Secure Data Handling: Basic Workflow Application Server Operating System Log Exceptions Software Application Param Queries Encode output Validate Data @KatyAnton

Sensitive Date Exposure Data at Rest and in Transit @KatyAnton

Data Data Types Encryption Hashing Data at Rest : Requires initial value R E.q: credit card Data at Rest : Doesn’t require initial value R E.q: user passwords R Data in Transit @KatyAnton

Data at Rest: Design Vulnerability example How Not to Do it ! In the same folder - 2 file: The content of password.txt: encryption_key = PBKF2(psswd, salt, iterations, key_length); @KatyAnton

Encryption: Security Controls Strong Encryption Algorithm: AES Key Management • Store unencrypted keys away from the encrypted data. • Protect keys in a Key Vault (Hashicorp Vault / Amazon KMS) • Keep away from home grown key management solutions. • Define a key lifecycle. • Build support for changing algorithms and keys when needed • Document procedures for managing keys through the lifecycle Source: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html @KatyAnton

Data in Transit: Security Controls Application Server Operating System TLS TLS • Software Application TLS TLS @KatyAnton

Third Party Components Using Software Components with Known Vulnerabilities @KatyAnton

State of Software Security Apps with at least 1 vulnerable component: • 85.7% of .Net applications • 92% of C++ applications Source: https://www.veracode.com/state-of-software-security-report @KatyAnton

Root Cause • Difficult to understand • Easy to break • Difficult to test • Difficult to upgrade • Increase technical debt @KatyAnton

What is Attack Surface? Sum of the total different points through which a malicious actor can try to enter data into or extract data from an environment. @KatyAnton

Fundamental Security Principle Minimize the attack surface area @KatyAnton

Components Examples Example of external components: • Open source libraries - for example: a logging library • APIs - for example: vendor APIs • Packages by another team within same company @KatyAnton

Example 1: Implement Logging Library • Third-party - provides logging levels: • FATAL, ERROR, WARN, INFO, DEBUG. • We need only: • DEBUG, WARN, INFO. @KatyAnton

Simple Wrapper Module Helps to: Module Module • Expose only the functionality Module required. Module Module • Hide unwanted behaviour. Module Interface • Reduce the attack surface area. • Update or replace libraries. Third-Party Library • Reduce the technical debt. @KatyAnton

Example 2: Implement a Payment Gateway Scenario: • Vendor APIs - like payment gateways • Can have more than payment gateway one in application • Require to be inter-changed @KatyAnton

Adapter Design Pattern • Converts from provided interface Your Code to the required interface. • A single Adapter interface can work with many Adaptees. Adapter • Easy to maintain. Third-party code @KatyAnton

Example 3: Implement a Single Sign-On • Libraries / packages created by another team within same company • Re-used by multiple applications • Common practice in large companies @KatyAnton

Façade Design Pattern • Simplifies the interaction with a complex sub-system • Make easier to use a poorly designed API • It can hide away the details from the client. • Reduces dependencies on the outside code. @KatyAnton

Secure Software Starts from Design ! Wrapper Adapter Pattern Façade Pattern To expose only required To convert from the required To simplify the interaction with functionality and hide unwanted interface to provided interface a complex sub-system. behaviour. Module Module Your Code Module Module Module Module Module Module Module Module Module Module Module Module Adapter Facade Interface Third-party code Complex sub-system Third-Party Library

How often ? @KatyAnton

Rick Rescorla • United States Army office of British origin • Born in Hayle, Cornwall, UK • Director of Security for Morgan Stanley at WTC @KatyAnton

Security Controls Recap @KatyAnton

Security Controls In Development Cycle Application Server OS Command Logs Operating System Log Exception Software Application Param Data Secure Date Key Management Encapsulation Param Queries Mo Mo Mo Mo Mo Mo Encode Validate Mo Encap output TLS Input Librar TLS TLS @KatyAnton

Final Takeaways Focus on CWEs CWEs Security which prevent Verify Early and Often Controls @KatyAnton

References • OWASP Top 10 Proactive Controls https://owasp.org/www-project-proactive-controls/ • OWASP Cheat Series https://cheatsheetseries.owasp.org/ @KatyAnton

Thank you very much @KatyAnton @KatyAnton