Security vulnerabilities decomposition

Security Vulnerabilities
Decomposition:
Another way to look at Vulnerabilities
Katy Anton

@KatyAnton
Application Security Team
After Report

@KatyAnton
Software Development Team
After Report

@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

@KatyAnton
• Software development background
• Project co-leader for
OWASP Top 10 Proactive Controls
(@OWASPControls)
• OWASP Bristol Chapter Leader
• Principal AppSec Consultant
Katy Anton

@KatyAnton
Common Weakness Enumeration
A formal list of software security weaknesses in:
- architecture
- design
- code
Source:cwe.mitre.org

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

@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

@KatyAnton
Another way to look at Vulnerabilities

@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

@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

@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“

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

@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: https://www.owasp.org/index.php/AppSensor_DetectionPoints
Best Types of Detection Points

@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: https://www.owasp.org/index.php/AppSensor_DetectionPoints
Examples of Intrusion Detection Points

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

@KatyAnton
Sensitive Date Exposure
Data at Rest and in Transit

@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 ☑

@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:

@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: https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
Security Controls: Data at Rest

@KatyAnton
Security Controls: Data in Transit
TLS TLS
Application Server
Operating System
Application Server —> Non-browser
components
Client —> Application server

@KatyAnton
Third Party Components
Using Software Components with Known Vulnerabilities

@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

@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?

@KatyAnton
Minimize the attack surface.
Source: https://www.owasp.org/index.php/Security_by_Design_Principles
Fundamental Security Principle

@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

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

@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.

@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

@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

@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

@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

@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

@KatyAnton
Environment
Misconfiguration

@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

@KatyAnton
Final Takeaways
CWEs

@KatyAnton
Final Takeaways
CWEs
Focus on
Security
Controls
which prevent

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

@KatyAnton
Security Controls for Secure Development
Application Server
Operating System
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

Thank you
Katy Anton
@KatyAnton

Security vulnerabilities decomposition

More Related Content

What's hot (20)

Similar to Security vulnerabilities decomposition (20)

Recently uploaded (20)

Security vulnerabilities decomposition