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.
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. @KatyAnton
• Software development background
• Project co-leader for
OWASP Top 10 Proactive Controls
(@OWASPControls)
• OWASP Bristol Chapter Leader
• Principal AppSec Consultant
Katy Anton
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
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“
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: https://www.owasp.org/index.php/AppSensor_DetectionPoints
Best Types of Detection Points
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: https://www.owasp.org/index.php/AppSensor_DetectionPoints
Examples of Intrusion Detection Points
19. @KatyAnton
Secure Data Handling: Basic Workflow
Application Server
Operating System
Software Application
Param
Queries
Encode outputValidate Data
Log Exceptions
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. @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. @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
24. @KatyAnton
Security Controls: Data in Transit
TLS TLS
Application Server
Operating System
Software Application
Application Server —> Non-browser
components
Client —> Application server
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. @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. @KatyAnton
Minimize the attack surface.
Source: https://www.owasp.org/index.php/Security_by_Design_Principles
Fundamental Security Principle
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. @KatyAnton
• Third-party - provides logging levels:
FATAL, ERROR, WARN, INFO, DEBUG.
• We need only:
DEBUG, WARN, INFO.
Ex1:Implement a Logging Library
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. @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. @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. @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. @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
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
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