Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security vulnerabilities decomposition


Published on

In most companies security is driven by compliance regulations. The policies are designed to contain the security vulnerabilities each company is interested to comply with. These vulnerabilities can be measured only at the end, after the software has been developed, which is way too late. The result of this approach is a high number of insecure applications are still produced and injection is still King. Is there another way to create a more secure the software from the start? This presentation will look at security vulnerabilities from a different angle. We will decompose the vulnerabilities into the security controls that prevent them and developers are familiar with. We will flip the security from focusing on vulnerabilities (which can be measured only at the end, after the software has been developed) to focus on the security controls, which can be used from beginning in software development cycle. Recommended to all builders and security professionals interested to build a more secure software from the start.

Published in: Technology
  • Be the first to comment

Security vulnerabilities decomposition

  1. 1. Security Vulnerabilities Decomposition: Another way to look at Vulnerabilities Katy Anton
  2. 2. @KatyAnton OWASP Top 10
  3. 3. @KatyAnton Application Security Team After Report
  4. 4. @KatyAnton Software Development Team After Report
  5. 5. @KatyAnton • SQL Injection: mentioned in 1998 in Phrack magazine • XSS: Described in 1999 by Microsoft Injection 2004 2009 2010 2013 2017 Injection A6 A2 A1 A1 A1
  6. 6. @KatyAnton • Software development background • Project co-leader for OWASP Top 10 Proactive Controls (@OWASPControls) • OWASP Bristol Chapter Leader • Principal AppSec Consultant Katy Anton
  7. 7. @KatyAnton Common Weakness Enumeration A formal list of software security weaknesses in: - architecture - design - code
  8. 8. @KatyAnton Source: NVD - CWE Categories
  9. 9. @KatyAnton Injection
  10. 10. @KatyAnton CWEs in Injection Category CWE-93: CRLF Injection CWE-74 Injection CWE-943:Improper Neutr. of Special El in Query CWE-94: Code Injection CWE-91: XML Injection CWE-79: XSS CWE-77: Commmand Injection CWE-89: SQL Injection CWE-90: LDAP Injection Source: NVD CWE-78: OS Cmd Inj CWE-88: Argument Inj
  11. 11. @KatyAnton
  12. 12. @KatyAnton Another way to look at Vulnerabilities
  13. 13. @KatyAnton Decompose the Injection Data interpreted as Code Input Parser Output Get / Post Data File Uploads HTTP Headers Database Data Config files SQL Parser HTML Parser XML Parser Shell LDAP Parser SQL HTML XML Bash Script LDAP Query
  14. 14. @KatyAnton Extract Security Controls Vulnerability Encode Output Parameterize Validate Input SQL Injection ☑ ☑ XSS ☑ ☑ XML Injection ☑ ☑ Code Injection ☑ ☑ LDAP Injection ☑ ☑ Cmd Injection ☑ ☑ Primary Controls Defence in depth InputParserOutput
  15. 15. @KatyAnton Intrusions (or lack of Intrusion Detection) “If a pen tester is able to get into a system without being detected, then there is insufficient logging and monitoring in place“
  16. 16. @KatyAnton The security control developers can use to log security information during the runtime operation of an application. Security Controls: Security Logging
  17. 17. @KatyAnton 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 Source: Best Types of Detection Points
  18. 18. @KatyAnton Request Exceptions • Application receives GET when expecting POST • Additional form/URL parameters submitted Authentication Exceptions • POST request with only the username variable. The password variable has been removed. • Additional variables received during an authentication request (like ‘admin=true’') Input Exceptions • Input validation failure on server despite client-side validation • Input validation failure on server side on non-user editable parameters (hidden fields, checkboxes, radio buttons, etc) Source: Examples of Intrusion Detection Points
  19. 19. @KatyAnton Secure Data Handling: Basic Workflow Application Server Operating System Software Application Param Queries Encode outputValidate Data Log Exceptions
  20. 20. @KatyAnton Sensitive Date Exposure Data at Rest and in Transit
  21. 21. @KatyAnton Storage by Data Types Data Types Encryption Hashing Data at Rest: Requires initial value E.q: credit card ☑ Data at Rest: Does not require initial value E.q: user passwords ☑ Data in Transit ☑
  22. 22. @KatyAnton How Not to Do it ! Data at Rest: Design Vulnerability Example encryption_key = PBKF2(pwd, salt, iterations, key_length); In the same folder - 2 file: The content of password.txt:
  23. 23. @KatyAnton Encryption Cryptographic Storage Strong Encryption Algorithm: AES Key Management • Store unencrypted keys away from the encrypted data. • Protect keys in 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: Security Controls: Data at Rest
  24. 24. @KatyAnton Security Controls: Data in Transit TLS TLS Application Server Operating System Software Application Application Server —> Non-browser components Client —> Application server
  25. 25. @KatyAnton Third Party Components Using Software Components with Known Vulnerabilities
  26. 26. @KatyAnton The type of software with vulnerable components: • Difficult to understand • Easy to break • Difficult to test • Difficult to upgrade • Increase technical debt Root Cause
  27. 27. @KatyAnton Sum of the total different points through which a malicious actor can try to enter data into or extract data from a system. What is Attack Surface?
  28. 28. @KatyAnton Minimize the attack surface. Source: Fundamental Security Principle
  29. 29. @KatyAnton Examples of external components: 1. Open source libraries - for example: a logging library 2. APIs - for example: vendor APIs 3. Libraries / packages by another team within same company Components Examples
  30. 30. @KatyAnton • Third-party - provides logging levels: FATAL, ERROR, WARN, INFO, DEBUG. • We need only: DEBUG, WARN, INFO. Ex1:Implement a Logging Library
  31. 31. @KatyAnton Simple Wrapper Module Module Interface Module Module Module Library Module Module Helps to: • Expose only the functionality required. • Hide unwanted behaviour. • Reduce the attack surface area. • Update / replace libraries. • Reduce the technical debt.
  32. 32. @KatyAnton Scenario: • Vendor APIs - like payment gateways • Can have more than one payment gateway in an application • Required to be inter-changeable Ex2: Implement a Payment Gateway
  33. 33. @KatyAnton • Converts from provided interface to the required interface. • A single Adapter interface can work with many Adaptees. • Easy to maintain. Adapter Design Pattern Your Code Third-party code Adapter
  34. 34. @KatyAnton • Libraries / packages created by another team within same company • Re-used by multiple applications • Common practice in large companies Ex3: Implement a Single Sign-On
  35. 35. @KatyAnton • 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. Façade Design Pattern
  36. 36. @KatyAnton Secure Software Starts from Design! Façade Pattern To simplify the interaction with a complex sub-system. Adapter Pattern To convert from the required interface to provided interface Your Code Third-Party Code Adapter Wrapper To expose only the required functionality and hide unwanted behaviour. Third-Party Library Your code Module Module Module Module Module Module Module Interface
  37. 37. @KatyAnton Environment Misconfiguration
  38. 38. @KatyAnton • During Development: • Use dedicated users with same privileges as in production • Follow the “Least privilege” security principle • During Deployment: Check for privileges • Infrastructure-as-Code (IaC) • After Deployment: Adopt configuration management • Provide continuous configuration scanning across servers to identify and remediate misconfigurations Configuration Hardening
  39. 39. @KatyAnton Final Takeaways CWEs
  40. 40. @KatyAnton Final Takeaways CWEs Focus on Security Controls which prevent
  41. 41. @KatyAnton Final Takeaways Verify Early and Often CWEs Focus on Security Controls
  42. 42. @KatyAnton Security Controls for Secure Development Application Server Operating System Software Application Param Queries Encode output TLS Validate Input TLS TLS OS CommandLogs Log Exception Param Data Secure Date Key Management Solution Encapsulation Harden Parser XML Configuration Hardening
  43. 43. Thank you Katy Anton @KatyAnton