OWASP Top 10 Proactive Controls 2016 Part II

Narudom Roongsiriwong, CISSPMarch 30, 2017

WhoAmI● Lazy Blogger

– Japan, Security, FOSS, Politics, Christian– http://narudomr.blogspot.com

● Information Security since 1995● Web Application Development since 1998● Head of IT Security and Solution Architecture, Kiatnakin Bank PLC (KKP)● Consultant for OWASP Thailand Chapter● Committee Member of Cloud Security Alliance (CSA), Thailand Chapter● Consulting Team Member for National e-Payment project ● Contact: narudom@owasp.org

OWASP : Core Mission

● The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit also registered in Europe as a worldwide charitable organization focused on improving the security of software.

● Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks.

● Everyone is welcomed to participate in OWASP and all of our materials are available under free and open software licenses.

OWASP Top Ten Proactive Controls – v2

C1: Verify for Security Early and OftenC2: Parameterize QueriesC3: Encode DataC4: Validate All InputsC5: Implement Identity and Authentication ControlsC6: Implement Appropriate Access ControlsC7: Protect DataC8: Implement Logging and Intrusion DetectionC9: Leverage Security Frameworks and LibrariesC10: Error and Exception Handling

C5: Implement Identity and Authentication Controls

Three Different Terms

● Authentication● Session Management● Identity Management

Authentication● The process of verifying that an individual or an entity is

who it claims to be● Commonly performed by submitting a user name or ID and

one or more items of private information that only a given user should know, should have or should be

Session Management

● A process by which a server maintains the state of an entity interacting with it

● This is required for a server to remember how to react to subsequent requests throughout a transaction.

● Sessions are maintained on the server by a session identifier which can be passed back and forth between the client and server when transmitting and receiving requests.

● Sessions should be unique per user and computationally impossible to predict

Identity Management

● A broader topic● Not only includes

authentication and session management

● But also covers advanced topics like identity federation, single sign on, password management tools, delegation, identity repositories and more

Some Recommendation for Secure Implementation

● Use Multi-Factor Authentication● Mobile Application: Token Based Authentication● Implement Secure Password Storage● Implement Secure Password Recovery Mechanism● Session Generation and Expiration● Require Reauthentication for Sensitive Features

Using Multi-Factor Authentication● Multi-factor authentication (MFA) ensures that users are

who they claim to be by requiring them to identify themselves with a combination of: – Something they know – password or PIN – Something they have – token or phone – Something they are – biometrics, such as a fingerprint

Mobile Application: Token Based Authentication

● Avoid storing/persisting authentication credentials locally on the device

● Perform initial authentication and then generate a short-lived access token which can be used to authenticate a client request without sending the user's credentials

Implement Secure Password Storage

● An application must securely store user credentials● Cryptographic controls should be in place such that if a

credential (e.g. a password) is compromised

Implement Secure Password Recovery Mechanism

● Step 1) Gather Identity Data or Security Questions● Step 2) Verify Security Questions● Step 3) Send a Token Over a Side-Channel (Out of Band)● Step 4) Allow user to change password in the existing

session● Step 5) Logging

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

Session: Generation and Expiration

● On any successful authentication and reauthentication the software should generate a new session and session ID

● Set expiration timeouts for every session, after a specified period of inactivity

● The length of timeout should be inversely proportional with the value of the data protected

Require Reauthentication for Sensitive Features

● For sensitive transactions, it is important to require the user to reauthenticate and if feasible, to generate a new session ID upon successful authentication.

● When to do– Changing password– Changing the shipping address for a purchase– Changing email address for notification

Vulnerabilities Prevented

● OWASP Top 10 2013 – A2: Broken Authentication and Session Management

● OWASP Mobile Top 10 2016– M4: Insecure Authentication

References

● OWASP Authentication Cheat Sheet ● OWASP Password Storage Cheat Sheet ● OWASP Forgot Password Cheat Sheet ● OWASP Choosing and Using Security Questions Cheat Sheet ● OWASP Session Management Cheat Sheet ● OWASP Testing Guide 4.0: Testing for Authentication ● OWASP IOS Developer Cheat Sheet

C6: Implement Access Controls

Authorization (Access Control)

● The process where requests to access a particular feature or resource should be granted or denied

● Not equivalent to authentication (verifying identity)● Access control design requirements should be considered at

the initial stages of application development

Some Recommendation for Secure Implementation

● Force All Requests to go Through Access Control Checks● Deny by Default● Principle of Least Privilege● Avoid Hard-Coded Access Control Checks● Code to the Activity● Server-Side Trusted Data Should Drive Access Control

Force All Requests to Go Through Access Control Checks

https://projects.spring.io/spring-security/

Deny by Default

● Consider denying all access control checks for features that have not been configured for access control

Principle of Least Privilege

● When designing access controls, each user or system component should be allocated the minimum privilege required to perform an action for the minimum amount of time

● Benefits of the principle include:– Better system stability– Better system security– Ease of deployment

Avoid Hard-Coded Access Control Checks

● Hard-coded access control makes auditing or proving the security of that software very difficult and time consuming

● Access control policy and application code, when possible, should be separated

● On the other hand, enforcement layer (checks in code) and access control decision making process (the access control "engine") should be separated when possible

Hard-coded role checks

RBAC

if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {deleteAccount();

}

if (user.hasAccess("DELETE_ACCOUNT")) {deleteAccount();

}

Code to the ActivityRBAC (Role Based Access Control)

[Authorize(Roles = "Jedi", "Sith")]

public ActionResult WieldLightsaber() {

return View();

}

Role Based Authorization

[ClaimAuthorize(Permission="CanWieldLightsaber")]

public ActionResult WieldLightsaber()

{

return View();

}

Claim Based Authorization

ASP.NET Roles vs Claims Authorization

Apache Shiro Role Based Access Control

http://shiro.apache.org/

if ( currentUser.hasRole( "schwartz" ) ) { log.info("May the Schwartz be with you!" );} else { log.info( "Hello, mere mortal." );}

Checks heck if the current use have specific role or not:

Apache Shiro Permission Based Access Control

http://shiro.apache.org/

Check if the current user have a permission to act on a certain type of entity

if ( currentUser.isPermitted( "lightsaber:wield" ) ) { log.info("You may use a lightsaber ring. Use it wisely.");} else { log.info("Sorry, lightsaber rings are for schwartz masters only.");}

Check if the current user have access to a specific instance of a type : instance-level permission check

if ( currentUser.isPermitted( "winnebago:drive:eagle5" ) ) { log.info("You are permitted to 'drive' the 'winnebago' with license plate (id) 'eagle5'. " + "Here are the keys: have fun!");} else { log.info("Sorry, you aren't allowed to drive the 'eagle5' winnebago!");}

Apache Shiro Permission Based Access Control

http://shiro.apache.org/

Server-Side Trusted Data Should Drive Access Control

● The only client-side data that is needed for access control is the ID or IDs of the data being accessed

● Most all other data needed to make an access control decision should be retrieved server-side

Vulnerabilities Prevented

● OWASP Top 10 2013 – A4: Insecure Direct Object References– A7: Missing Function Level Access Control

● OWASP Mobile Top 10 2016– M6: Insecure Authorization

References

● OWASP Access Control Cheat Sheet ● OWASP Testing Guide for Authorization ● OWASP iOS Developer Cheat Sheet Poor Authorization and

Authentication

C7: Protect Data

How to Protect Data

● Encrypting Data in Transit● Encrypting Data at Rest● Implement Protection in Transit● Mobile Application: Secure Local Storage

Encrypting Data in Transit

● What benefits do HTTPS provide?– Confidentiality: Spy cannot view your data– Integrity: Spy cannot change your data– Authenticity: Server you are visiting is the right one– High performance !

● HTTPS configuration best practices– https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_

Sheet – https://www.ssllabs.com/projects/best-practices/

Encrypting data in Transit : HSTS (Strict Transport Security)● Forces browser to only make HTTPS connection to server● Must be initially delivered over a HTTPS connection● Current HSTS Chrome preload list

http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json● If you own a site that you would like to see included in the preloaded

Chromium HSTS list, start sending the HSTS header and then contact: https://hstspreload.appspot.com/

● A site is included in the Firefox preload list if the following hold: – It is in the Chromium list (with force-https).– It sends an HSTS header.– The max-age sent is at least 10886400 (18 weeks)

Encrypting data in Transit : Certificate Pinning● What is Pinning ?

– Pinning is a key continuity scheme – Detect when an imposter with a fake but CA validated

certificate attempts to act like the real server● 2 Types of pinning

– Carry around a copy of the server's public key; ● Great if you are distributing a dedicated client-server

application since you know the server's certificate or public key in advance

– Note of the server's public key on first use● Trust-on-First-Use (TOFU) pinning● Useful when no a priori ("from the earlier") knowledge

exists, such as SSH or a Browser

https://www.owasp.org/index.php/Pinning_Cheat_Sheet

Encrypting data in Transit : Browser-Based TOFU Pinning● Browser-Based TOFU Pinning : Trust on First Use● HTTP Public Key Pinning IETF Draft

http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11 ● Freezes the certificate by pushing a fingerprint of (parts of)

the certificate chain to the browser ● Example:

Public-Key-Pins: pin-sha1="4n972HfV354KP560yw4uqe/baXc=";pin-sha1="qvTGHdzF6KLavt4PO0gs2a6pQ00=";pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";max-age=10000; includeSubDomains

https://www.owasp.org/index.php/Pinning_Cheat_Sheet

Encrypting data in Transit : Forward Secrecy

● Forward Secrecy (FS; also known as perfect forward secrecy) is a property of secure communication protocols in which compromise of long-term keys does not compromise past session keys

● Deploying Perfect Forward Secrecy– Instead of using the RSA method for exchanging session keys, you should use

the Elliptic Curve Diffie-Hellman (ECDHE) key exchange.● Note that you can still use the RSA public-key cryptosystem as the encryption

algorithm, just not as the key exchange algorithm.– ECDHE is much faster than ordinary DH (Diffie-Hellman), but both create

session keys that only the entities involved in the SSL connection can access– Because the session keys are not linked to the server’s key pair, the server’s

private key alone cannot be used to decrypt any SSL session.https://www.digicert.com/ssl-support/ssl-enabling-perfect-forward-secrecy.htm

Encrypting Data at Rest

● Classify data in your system and determine the data needs to be encrypted, such as credit card information for PCI DSS

● Strongly recommended that peer reviewed and open libraries be used– Google KeyCzar project– Libsodium– Bouncy Castle– Functions included in SDKs

● Be prepared to handle the more difficult aspects of applied crypto such as key management– Keys should be treated as secrets and only exist on the device in a

transient state– Hardware Security Module (HSM) is the alternative for key

management and cryptographic process isolation

Encrypting Data at Rest: Google KeyCzar

● Keyczar is an open source cryptographic toolkit for Java, Python and C++.● Designed to make it easier and safer for developers to use cryptography

in their applications. ● Secure key rotation and versioning● Safe default algorithms, modes, and key lengths● Automated generation of initialization vectors and ciphertext signatures

Sample Usage :

Crypter crypter = new Crypter("/path/to/your/keys");String ciphertext = crypter.encrypt("Secret message");String plaintext = crypter.decrypt(ciphertext);

https://github.com/google/keyczar

Encrypting Data at Rest: libsodium ● A high-security, cross-platform & easy-to-use crypto library. ● Modern, easy-to-use software library for encryption, decryption, signatures, password

hashing and more.● It is a portable, cross-compilable, installable & packageable fork of NaCl, with a compatible

API, and an extended API to improve usability even further ● Provides all of the core operations needed to build higher-level cryptographic tools.● Sodium supports a variety of compilers and operating systems, including Windows (with

MinGW or Visual Studio, x86 and x86_64), iOS and Android.● The design choices emphasize security, and "magic constants" have clear rationales.● PHP 7.2 will adopt libsodium as standard library (https://dev.to/paragonie/php-72-the-first-

programming-language-to-add-modern-cryptography-to-its-standard-library)

https://www.gitbook.com/book/jedisct1/libsodium/details

Implement Protection in Transit

● Make sure that confidential or sensitive data is not exposed by accident during processing

● Attacker could read the information in temporary storage locations or log files

Mobile Application: Secure Local Storage

● In the context of mobile devices, which are regularly lost or stolen, secure local data storage requires proper techniques

● Improper storage mechanisms may lead to serious information leakage (example: authentication credentials, access token, etc.)

● The best choice is to never save sensitive data on a mobile device, even using known methods such as a iOS keychain

Vulnerabilities Prevented

● OWASP Top 10 2013 – A6: Sensitive Data Exposure

● OWASP Mobile Top 10 2016– M2: Insecure Data Storage– M3: Insecure Communication– M5: Insufficient Cryptography

References

● Proper TLS configuration: OWASP Transport Layer Protection Cheat Sheet

● Protecting users from man-in-the-middle attacks via fraudulent TLS certificates: OWASP Pinning Cheat Sheet

● OWASP Cryptographic Storage Cheat Sheet ● OWASP Password Storage Cheat Sheet ● OWASP Testing for TLS ● IOS Developer Cheat Sheet: OWASP iOS Secure Data Storage ● IOS Application Security Testing Cheat Sheet : OWASP Insecure

data storage

C8: Implement Logging and Intrusion Detection

Benefit of Application Logging

● Application logging should not be an afterthought or limited to debugging and troubleshooting.

● Logging is also used in other important activities: – Application monitoring– Business analytics and insight– Activity auditing and compliance monitoring – System intrusion detection– Forensics– Fraud detection

Tips for Proper Application Logging

● Use a common/standard logging approach to facilitate correlation and analysis– Logging framework : SLF4J with Logback or Apache Log4j2.

● Avoid side effects : define a minimal but effective logging approach to track user activities

● Perform encoding on untrusted data : protection against Log Injection attacks !

App Layer Intrusion Detection Points Examples

● Input validation failure server side when client side validation exists

● Input validation failure server side on non-user editable parameters such as hidden fields, checkboxes, radio buttons or select lists

● Forced browsing to common attack entry points ● Honeypot URL (e.g. a fake path listed in robots.txt like

e.g. /admin/secretlogin.jsp)

App Layer Intrusion Detection Points Examples

● Blatant SQLi or XSS injection attacks.● Workflow sequence abuse (e.g. multi-part form in wrong

order).● Custom business logic (e.g. basket vs catalogue price

mismatch).● Further study :

– AppSensor OWASP Project – libinjection : from SQLi to XSS – Nick Galbreath– Attack Driven Defense – Zane Lackey

Vulnerabilities Prevented

● All OWASP Top 10 2013 ● OWASP Mobile Top 10 2016

– M1: Improper Platform Usage

References

● How to properly implement logging in an application: ● OWASP Logging Cheat Sheet ● IOS Developer Cheat Sheet : ● OWASP Sensitive Information Disclosure ● OWASP Logging ● OWASP Reviewing Code for Logging Issues ● Tools

– OWASP AppSensor Project – OWASP Security Logging Project

C9: Leverage Security Frameworks and Libraries

Why Leverage Security Frameworks and Libraries

● Develop security controls from scratch leads to wasted time and massive security holes

● Secure coding libraries and software frameworks help software developers guard against security-related design and implementation flaws

Guidance

● Using the existing secure features of frameworks is better than importing third party libraries

● Web application security frameworks to consider include:– Spring Security (Java/Spring) – Django Security (Python/Django)– Flask Security (Python/Flask)– Apache Shiro (Java) – Google keyCzar (C++, Java, Python)

● Stay up to date!

Vulnerabilities Prevented

● All OWASP Top 10 2013● It is critical to keep these frameworks and libraries up to

date as described in A9: Using Components with Known Vulnerabilities

References

● OWASP PHP Security Cheat Sheet ● OWASP .NET Security Cheat Sheet ● Security tips and tricks for JavaScript MVC frameworks and

templating libraries ● Angular Security ● OWASP Security Features in common Web Frameworks ● OWASP Java Security Libraries and Frameworks ● Tools

– OWASP Dependency Check

C10: Error and Exception Handling

Mistakes In Error Handling Can Lead To

● Leaking information to attackers, helping them to understand more about your platform and design CWE 209. For example– Returning a stack trace or other internal error details can tell an

attacker about your environment– Returning different types of errors in different situations (for

example, "invalid user" vs "invalid password" on authentication errors) can also help attackers find their way in.

● Not checking errors, leading to errors going undetected, or unpredictable results such as CWE 391

Best Practices

● Manage exceptions in a centralized manner to avoid duplicated try/catch blocks in the code, and to ensure that all unexpected behaviors are correctly handled inside the application.

● Ensure that error messages displayed to users do not leak critical data, but are still verbose enough to explain the issue to the user.

● Ensure that exceptions are logged in a way that gives enough information for Q/A, forensics or incident response teams to understand the problem

Vulnerabilities Prevented

● All OWASP Top 10 2013

References

● OWASP Code Review Guide Error Handling ● OWASP Testing Guide Testing for Error Handling ● OWASP Improper Error Handling ● Tools

– Aspirator – A simple checker for exception handler bugs– All static code analyzer: SonarQube, CheckMarx, Fortify,

AppScan, etc.