The path of secure software by Katy Anton
Download as PPTX, PDF0 likes231 views
This document discusses 10 controls (C1 through C10) for developing secure software. Each control is described in 1-2 pages and addresses how it mitigates many of the top 10 risks from the OWASP list, including injection, XSS, sensitive data exposure, access control issues, and more. Specific techniques are provided, such as query parameterization to prevent SQL injection, output encoding to prevent XSS, validating all input, secure authentication and authorization practices, encrypting data, and centralized error handling.
![C2. Query Parameterization - Correct Usage
string cmd= "SELECT * FROM users WHERE userId = @Id";
SqlCommand sql = new SqlCommand(cmd);
sql.SqlParameter("@Id", System.Data.SqlDbType.Int));
sql.Parameters["@Id"].Value = ID;
reader = sql.ExecuteReader();](https://image.slidesharecdn.com/thepathofsecuresoftware-katyanton-170914162920/85/The-path-of-secure-software-by-Katy-Anton-14-320.jpg)
![C5. Secure Password Storage
protect(sha512(password), [salt], [workFactor])
+
2nd Factor Authentication
Don’t use SMS as multi-factor (use FIDO or dedicated app)](https://image.slidesharecdn.com/thepathofsecuresoftware-katyanton-170914162920/85/The-path-of-secure-software-by-Katy-Anton-29-320.jpg)
![C5. Password Storage – How Not To Do It!
$password=bcrypt([salt] + [password], work_factor);
$loginkey =md5(lc([username]).”::”.lc([password]))](https://image.slidesharecdn.com/thepathofsecuresoftware-katyanton-170914162920/85/The-path-of-secure-software-by-Katy-Anton-30-320.jpg)
The path of secure software by Katy Anton
- 1. Join the conversation #DevSecCon The Path of Secure Software BY KATY ANTON CA / VERACODE
- 2. Katy Anton • Software development background • Certified Secure Software Lifecycle Professional (CSSLP) • Application Security Consultant @Veracode (part of CA Technologies) • OWASP Bristol Chapter Leader • Project Co-leader for OWASP Top 10 Proactive Controls
- 3. OWASP Top 10 Risks - 2013 A1 – Injection A2 - Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 – Unvalidated Redirects and Forwards
- 5. New Website
- 6. OWASP Application Security Verification Standard (ASVS)
- 7. OWASP ASVS
- 8. C1. Consider OWASP ASVS • Choose the level of security for your application • Extract the requirements for that level • Use requirements to generate test cases • Integrate security testing in SDLC.
- 9. C1. Build Security Into Software Early and Verify It
- 10. Development Code Commit Deployment Code review System Tests Pre-commit hooks Unit Tests Unit Test Regression Tests C1. Verify for Security Early and Often
- 11. C1. Vulnerabilities Addressed - All Top Ten! A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 - Unvalidated Redirects and Forwards
- 12. SQL injection example $email=‘;- - @owasp.org; $sql = UPDATE user set email=‘$email’ WHERE id=‘1’; $sql = UPDATE user SET email=‘'; -- @owasp.org' WHERE id=‘1’; Becomes
- 13. C2. Query Parameterization Example String cmd = String.Format(“SELECT * FROM users where userID = {}”,userID) reader = cmd.ExecuteReader(); Example of Query ParameterisationHow not to do it ! .
- 14. C2. Query Parameterization - Correct Usage string cmd= "SELECT * FROM users WHERE userId = @Id"; SqlCommand sql = new SqlCommand(cmd); sql.SqlParameter("@Id", System.Data.SqlDbType.Int)); sql.Parameters["@Id"].Value = ID; reader = sql.ExecuteReader();
- 15. Secure Database Access Credentials: • Store encrypted credentials out of the source code Database user: • Grant least privilege • Remove unrequired users Stored procedures: • Grant EXECUTE permissions on the stored procedures • Revoke or deny all permissions to the underlying tables for all roles
- 16. C2: Vulnerabilities Addressed A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 – Unvalidated Redirects and Forwards
- 17. XSS Example
- 18. C3. Encode Your Output
- 19. C3. Contextual Encoding Libraries Java OWASP Java Encoder Project .Net AntiXSS PHP Symfony 2+: Twig Zend Framework: ZendEscaper
- 20. C3. Vulnerabilities Addressed A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 – Unvalidated Redirects and Forwards
- 21. C4. Validate All Input
- 22. C4. Example of Validations • GET / POST data (including hidden fields ) • File uploads • HTTP Headers • Cookies • Database
- 23. C4. Vulnerabilities Addressed A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 - Unvalidated Redirects and Forwards
- 24. C5. Implement Digital Identity Controls
- 25. C5. Best practices • Secure Password Storage • Multi-Factor Authentication • Secure Password Recovery Mechanism • Transmit sensitive data only over TLS (v1.2) • Error Messages
- 26. C5. Strong cryptographic algorithms • PBKDF2 • scrypt • bcrypt Source: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
- 27. NIST: 2017 Digital Identity Guidelines • Allow all ASCII printable characters, including space • Minimum 8 characters length • Allow users to passwords lengthy as they want, within reason. • Offer guidance, such as a password-strength meter • Do not require password to be changed periodically • Permit to use “paste” functionality • Check against a list of bad password Source: https://pages.nist.gov/800-63-3/sp800-63b.html
- 28. Hash Password with a modern Hash Problem: • Long passwords can cause DoS • bcrypt truncates passwords to 72 bytes Solution: • SHA-512 - converts long passwords to 512 bits
- 29. C5. Secure Password Storage protect(sha512(password), [salt], [workFactor]) + 2nd Factor Authentication Don’t use SMS as multi-factor (use FIDO or dedicated app)
- 30. C5. Password Storage – How Not To Do It! $password=bcrypt([salt] + [password], work_factor); $loginkey =md5(lc([username]).”::”.lc([password]))
- 31. C5. Error Messages - How Not To Do It! Error message for not-registered userError message for valid user
- 32. C5. Vulnerabilities Addressed A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 – Unvalidated Redirects and Forwards
- 33. C6. Implement Appropriate Access Controls
- 34. C6. Vulnerabilities Addressed A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 – Unvalidated Redirects and Forwards
- 35. C7. Protect Data
- 36. C7. Data in Transit Data in transit: HTTPS • Confidentiality: Spy cannot view your data • Integrity: Spy cannot change your data • Authenticity: Server you visit is the right one MITM Protection - HSTS • HTTPS + Strict Transport Security Header
- 37. C7. Data at Rest 1. Strong algorithm – AES 2. Secure key management 3. Adequate access controls and auditing
- 38. C7. Vulnerabilities Addressed A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 – Unvalidated Redirects and Forwards
- 39. C8. Implement Logging and Intrusion Detection
- 40. C8. Examples of Intrusion Detection Points • Application receives GET when expecting POST • Additional form or URL parameters submitted with request • Input validation failure server side when client side validation exists • Input validation failure server side on non-user editable parameters such as hidden fields, checkboxes, radio buttons or select lists • HTTP headers, Cookies received differ from the expected Source: https://www.owasp.org/index.php/OWASP_AppSensor_Project
- 41. Logging Frameworks • Use logging framework • Encode untrusted data -> protection against Log injection attacks • Validate untrusted data-> protection against Log forging attacks
- 42. C8. Vulnerabilities Addressed - All Top Ten! A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 - Unvalidated Redirects and Forwards
- 43. C9. Leverage Security Frameworks and Libraries
- 44. C9. Examples • Access Controls • CSRF protection • XSS protection • ORM - SQL injection prevention
- 45. Current state of software Source: https://www.veracode.com/resources/state-of-software-security
- 46. Cyber breaches Root cause of the top 50 breaches in 2016: #1 A9-Using Components with Known Vulnerabilities Source: snyk.io
- 47. Unmanaged 3rd Party Components
- 48. C9. API Integration Best Practices “When you wrap a third-party API, you minimize your dependencies upon it: You can choose to move to a different library in the future without much penalty. “ Robert C. Martin
- 49. Wrapper Adapter C9. Design Patterns for Integration Façade
- 50. C9. Automate OWASP Dependency Check - supported languages: • Java • .NET JavaScript • Retire.JS scanner PHP • PHP Security Checker
- 51. C9. Best Practices • Use trusted sources • Encapsulate 3rd party libraries • Hide information • Reduce attack surface • Update regularly / replace
- 52. C9. Vulnerabilities Addressed - All Top Ten! A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 - Unvalidated Redirects and Forwards
- 53. C10. Error and Exception Handling
- 54. C10: Best Practices • Centralised error handling • Verbose enough to explain the issue • Don’t leak critical information
- 55. C10. Don’t leak information !
- 56. A1 – Injection A2 – Broken Auth. and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery A9 – Using Comp. with Known Vulnerabilities A10 - Unvalidated Redirects and Forwards C10. Vulnerabilities Addressed - All Top Ten!
- 57. Developer Controls C1 Build Security Early C4 Validate Input C6 Access Controls C5 Digital Identity C7 Protect Data C10 Error Handling C8 Logging C2 Secure Database Access C9 Leverage security C3 Encode Data
- 58. Project Page Project page: https://www.owasp.org/index.php/OWASP_Proactive_Controls Twitter: @OWASPControls
- 59. Join the conversation #DevSecCon Thank you Katy Anton Application Security Consultant Ca / Veracode
Editor's Notes
- #55: Think for example of coordinates: latitude and longitude have no value by themselves, but put them together, and they can pin-point the exact location on earth! The same thing can happened with error messages when attackers will aggregate /^ them from different parts /^ of the application. One way to deal with this, is to present the end user an error code, and store the details of the error in the database. ——> American English uses the Z, and British uses the S.