Security Ninjas: An Open Source Application Security Training Program
NOTES -- Slide 8 Some of the categories we will discuss are very broad like this one. Untrusted command – get / post / rest style params Clicks Surprise inputs Slide 13 Very broad too Little or no auth Auth with some bypass possibilities Some problem with how session is generated, managed, expired Insufficient sessionID protection Slide 18 When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. Slide 27 Security hardening throughout Application Stack Unnecessary features enabled or installed? ports, services, pages, accounts, privileges Security settings in your development frameworks (e.g., Struts, Spring, ASP.NET) and libraries not set to secure values? Default accounts/ passwords still enabled and unchanged? Error handling reveal stack traces or other overly informative error messages to users? Software out of date? OS, Web Server, DBMS, applications, code libraries Slide 41 sign up for updates or do regular audits to see versions there might be technical dependencies easily exploited by attackers using metaspoilt, info gathering using headers & responses, etc. Slide 47 We can look at the architecture, give you tips around what you could use, what would be good. This would avoid making any major changes when the product is ready which would save everyone’s time in the long run. Have sprints with dedicated security features and use those as a selling point for our security conscious customers Slide 48 Carefully look at the license to make sure you can use it in your type of product. Ask Fallon if you are not sure Research how much support it gets, how popular it is Look to find out any vulnerabilities in it before you start using it Maintain it; Sign up for CVE updates Ask us if you need to get something reviewed Slide 50 Not only better and more features Security vulnerabilities get patched in new versions New versions get most attention by the companies and old ones stop getting support after some time fully Most Security Support by the community Turn on auto updates for Chrome; always look at updates on AppStore Slide 51 Use different passwords for different sites Password managers let you set complexity, generate random passwords, etc. Slide 52 Only grant access to whats needed to get the job done employee leaves; mistakes; vulnerabilities in other s/w which leverages this; Don’t install redundant software, plugins, etc. This opens up so much risk People forget to uninstall them; s/w doesn't get much attention from community; open ports are left; boom exploited by attackers; Slide 55 To prevent unintended execution actions e.g., fail open auth errors Leak minimal info about infrastructure as this info is leveraged by attackers to carry out further attacks
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Security Ninjas: An Open Source Application Security Training Program
Similar to Security Ninjas: An Open Source Application Security Training Program (20)
More from OpenDNS
More from OpenDNS (16)
Recently uploaded
Recently uploaded (20)
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?