Security Ninjas: An Open Source Application Security Training Program
20 likes10,870 views
The document outlines a comprehensive agenda for an application security training program focused on common AppSec mistakes and best practices. Key topics include injection vulnerabilities, broken authentication, cross-site scripting, security misconfigurations, sensitive data exposure, and cross-site request forgery, along with preventive measures for each. The training emphasizes the importance of security planning, continuous updates, and minimizing risks through policies such as the principle of least privilege and input validation.
Security Ninjas: An Open Source Application Security Training Program
- 1. * CONFIDENTIAL Shru% Gupta Applica%on Security Engineer, OpenDNS Security Ninjas Applica%on Security Training Program
- 2. Agenda Most Common AppSec Mistakes + Hack Lab Best Prac%ces Q/A Swag
- 3. Setup Firefox FoxyProxy Burp Suite Docker container or Web server instance
- 4. Agenda Most Common Mistakes + Hack Lab Best Prac%ces Q/A Swag
- 5. #1 Injec6on ▪ What is it?
- 6. #1 Injec6on
- 7. #1 Injec6on
- 8. #1 Injec6on ▪ What is it? – Untrusted data is sent to an interpreter – command / query – headers – cookies – {.. any other form of input ..} – Interpreter is tricked into execu6ng unintended commands
- 9. #1 Injec6on ▪ What all is suscep%ble? – SQL – Hadoop – SOAP – XML – {..Anything..}
- 10. #1 Injec6on ▪ Why does it happen? ‒ Use of interpreters doesn’t clearly separate untrusted data from commands ‒ Lack of input valida6on/ sani6za6on ‒ AWacker is able to change execu%on context
- 11. #1 Injec6on ▪ Basic SQLi example SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1
- 12. #1 Injec6on ▪ How to prevent it? - Use APIs that provide parameterized / sani%zed interfaces - Validate input against whitelist - DON’T use a blacklist - Escape special characters which you had to whitelist
- 13. #2 Broken Authen6ca6on & Session Management ▪ Weak Authen%ca%on logic ▪ Imperfect implementa%on ▪ Insufficient protec%on of session token ▪ Etc.
- 14. #2 Broken Authen6ca6on & Session Management ▪ How to prevent it? - Use strong algorithms to generate (random) secrets - Protect secrets throughout their lifecycle - Consider having centralized authen%ca%on and session management APIs - Implement strong account management func6ons (e.g., account crea%on, change password, recover password, etc.) - Protect against XSS
- 15. #2 Broken Authen6ca6on & Session Management ▪ Authen%ca%on bypass example
- 16. #3 Cross-‐Site Scrip6ng (XSS) ▪ What is it? - Applica%on takes untrusted data - Sends it to web browser without proper valida6on and encoding - Allows aPackers to execute scripts in the vic6m’s browser - hijack user sessions - deface web sites - redirect user to malicious sites - etc.
- 17. #3 Cross-‐Site Scrip6ng (XSS) ▪ Types of XSS – Reflected – Stored – DOM based
- 18. #3 Reflected Cross-‐Site Scrip6ng (XSS) ▪ Injected script is instantly reflected off the web server ‒ error message ‒ search result ‒ any other response that includes some or all of the input sent ▪ Delivered via another route to the vic%m - email, other website, etc.
- 19. #3 Reflected Cross-‐Site Scrip6ng (XSS) ▪ Example: hWp://example.com/index.php?user=<script>alert(123);</script>
- 20. #3 Stored Cross-‐Site Scrip6ng (XSS) ▪ Injected script is permanently stored on target servers - database - message forum - visitor logs - comment fields ▪ Vic%m then retrieves malicious script from the server when he requests the stored informa%on ▪ Examples - Forums - Kibana search interface for Elas%csearch
- 21. #3 Cross-‐Site Scrip6ng (XSS) ▪ How to prevent XSS? ‒ Input valida%on ‒ Context based output encoding hWps://www.owasp.org/index.php/XSS_(Cross_Site_Scrip%ng)_Preven%on_Cheat_Sheet ‒ Content Security Policy ?
- 22. #4 Insecure Direct Object References ▪ Reference to internal implementa%on object is exposed ▪ e.g., file, directory, database key, etc. ▪ Lack of access controls/ other protec6ons ▪ AWackers can manipulate these references to access unauthorized data
- 23. #4 Insecure Direct Object References ▪ Example: ▪ Anyone can access any file uploaded on HipChat if he has the URL
- 24. #4 Insecure Direct Object References ▪ How to prevent it? - Verify user is authorized to access the exact resource they have requested - If the reference is an indirect reference, does mapping to the direct reference fail to limit the values to those authorized for the current user?
- 25. #5 Security Misconfigura6on ▪ Can be anywhere in the tech stack ‒ planorm ‒ web server ‒ database ‒ framework ‒ etc. ▪ Collec%ve effort between devs and Infra
- 26. #5 Security Misconfigura6on ▪ Example: ‒ default user account is not removed ‒ script kiddie runs automated tool ‒ tools can easily detect this ‒ dang!
- 27. #5 Security Misconfigura6on ▪ How to prevent it? ‒ Security hardening throughout Applica6on Stack ‒ Unnecessary features enabled or installed? ‒ Secure values not set? ‒ Default accounts/ passwords s%ll enabled or unchanged? ‒ Overly informa6ve error messages to users? ‒ Sopware out of date?
- 28. #6 Sensi6ve Data Exposure ▪ Client side - hardcoded secrets, cache, headers, excep%ons, .. ▪ In transit - SSL problems, MITM, .. ▪ Server side - weak crypto/ keys/ hashes, insufficient DB protec%on, ..
- 29. #6 Sensi6ve Data Exposure ▪ FB access token example
- 30. #6 Sensi6ve Data Exposure ▪ How to prevent it? ‒ Determine what data needs to be protected and how much ‒ Use strong crypto algos/ keys / modes / passwords ‒ Don’t store data unnecessarily ‒ Turn off autocomplete on forms and caching ‒ Encrypt all sensi6ve data at rest and transit (internally & externally) ‒ Control access to sensi%ve data
- 31. #7 Missing Func6on Level Access Control ▪ Making sure only the right people have access to the right func%ons ▪ Func%ons may be called through ‒ URL parameters ‒ REST style URLs ‒ etc.?
- 32. #7 Missing Func6on Level Access Control ▪ Facebook 12k bug bounty which let anyone delete images
- 33. #7 Missing Func6on Level Access Control ▪ How to prevent it? ‒ Hiding func%onality from the UI won’t help ‒ Server side Authen6ca6on and Access Control checks ‒ Server side checks shouldn’t solely rely on informa%on provided by client ‒ Deny by default ‒ Central authoriza%on module ? ‒ Rate limi%ng?
- 34. #8 Cross-‐Site Request Forgery (CSRF) ▪ APacker can formulate all HTTP parameters for a request ▪ Browsers send session cookies automa%cally ▪ AWacker tricks end user into execu6ng unwanted ac6ons on a web applica%on in which he/she is currently authen6cated ▪ Target: state changing func%ons
- 35. #8 Cross-‐Site Request Forgery (CSRF)
- 36. #8 Cross-‐Site Request Forgery (CSRF) ▪ Example: <img src="hWp://example.com/app/transferFunds? amount=1500&des%na%onAccount=aWackersAcct#“ width="0" height="0" />
- 37. #8 Cross-‐Site Request Forgery (CSRF) ▪ Myth : Mul%step transac%ons are immune to CSRF ▪ AWackers can easily forge a series of requests by using mul%ple tags or possibly JavaScript
- 38. #8 Cross-‐Site Request Forgery (CSRF) ▪ How to prevent it? ‒ Add unpredictability ‒ Unique random token ‒ CAPTCHA ‒ 2 factor confirma%on ▪ There are OWASP libraries you can use e.g., CSRF Guard
- 39. #9 Using Components with Known Vulnerabili6es ▪ Applica%on/Tech Stack uses vulnerable components ‒ Frameworks ‒ Libraries ‒ Servers ‒ OSes ‒ other components
- 40. #9 Using Components with Known Vulnerabili6es ▪ Easy exploita%on using tools like Metasploit
- 41. #9 Using Components with Known Vulnerabili6es ▪ How to prevent it? ‒ Keep a check on vulnerabili%es that come out ‒ CVE ‒ Mailing lists ‒ Calculate risk ‒ Upgrade vulnerable components
- 42. #10 Unvalidated Redirects and Forwards ▪ Applica%on takes input from user ▪ Uses it to formulate Redirect/ Forward loca%on without input valida%on ▪ AWacker misuses this for malicious redirec%ons/ forwarding
- 43. #10 Unvalidated Redirects and Forwards ▪ AWack scenarios: ‒ Malware installa%on ‒ Phishing ‒ Access Control bypass ▪ e.g., ▪ hWps://login.opendns.com/umbrella/?return_to=hWps://dashboard2.opendns.com/ ▪ hWps://login.opendns.com/umbrella/?return_to=hWps://dashboard2.opemdns.com/
- 44. #10 Unvalidated Redirects and Forwards ▪ How to prevent it? ‒ Avoid using user input to determine des%na%on URL ‒ Whitelist allowed pages or external sites ‒ Ensure URL is valid and authorized for the user
- 45. Setup Destroy your Docker container/stop the Webserver running the vulnerable applica%on
- 46. Agenda Most Common Mistakes + Hack Lab Best Prac%ces Q/A Swag
- 47. Security Planning ▪ Involve the Security team when planning a big feature / product ▪ Have Security features or controls added to User Stories when planning
- 48. Using 3rd Party Code ▪ What to do when using: – Security Libraries – Other Libraries
- 49. Defense in Depth ▪ Why is it important? - fail overs - edge cases - adding more fric%on for aWackers
- 50. Keep Sohware, Technologies etc. updated ▪ Why is it important? ‒ BePer and more features ‒ Security vulnerabili6es get patched in newer versions ‒ Newer versions get the most aPen6on ‒ Old ones stop gevng support ‒ Turn on auto updates for Chrome ‒ Look at updates on the AppStore
- 51. Use Hard Passwords ▪ Why is it important? ‒ Brute forcing passwords ‒ Dic%onary based aWacks ‒ Hash cracking ▪ Use a password manager ▪ Password Manager for shared accounts ▪ Reset when someone leaves
- 52. Be Minimalis6c ▪ Principle of Least Privilege ‒ Employee termina%on ‒ Mistakes ‒ Vulnerabili%es in other S/W which leverage this ▪ Don’t install redundant sohware, plugins, etc. - Maintenance issues - People forget to uninstall them - Don't get much aWen%on from the community - Open ports/ services
- 53. Don’t Hardcode Secrets in Source Code ▪ Put them in a config file ▪ Keep that in a secure place ▪ Restrict access to it
- 54. Input Valida6on ▪ Why is it important? ‒ Input coming from outside the trust boundary ‒ Clean it on the first point of entry ‒ Future dependencies more secure ‒ If reusing some user input from db/ internal storage, sani6ze it as per your program’s context ‒ Mul%ple orders of Injec%on
- 55. Error Handling ▪ Why is it important? ▪ Least informa%on disclosure
- 56. Logging and Aler6ng ▪ Why is it important? ‒ Iden%fy threats ‒ Inves%ga%ons ‒ Mi%gate problems before they become too big ‒ Good also from func%onality and QA standpoint
- 57. * Shru% Gupta shru%@opendns.com Ques6ons?