OWASP Top 10 List Overview for Web Developers


Published on

The OWASP Top 10 List was recently updated for 2013, and many developers still do not know what it is or why they should care. It is a list of the top web security threats developers need to address to produce secure websites. Most developers aren't security experts, so the OWASP Top 10 Project has created resources designed for developers to quickly test their applications. Come hear about the list, why and how you can use it to make your job easier, and learn about resources you can use to quickly determine if your applications are addressing security threats properly.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OWASP Top 10 List Overview for Web Developers

  1. 1. Overview for Web Developers Benjamin Floyd @dataplex
  2. 2. Gold Silver Bronze
  3. 3. First a Story…
  4. 4.  Passionate about security  .NET Developer  Senior Consultant for Headspring in Houston
  5. 5. The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted.
  6. 6.  The goal is to raise awareness about application security  Identifying some of the most critical risks facing organizations  Referenced by standards  PCI DSS  DISA, FTC, MITRE  Released in 2003, 04, 07, 10, 13
  7. 7.  Help your organization get started in application security  Secure your applications without being an expert
  8. 8. $80 Million in HELOC FraudDave and Busters, TJ Maxx, Heartland 45.6 Million CC Stolen Texas comptroller’s office data breach exposes 3.5 million teachers’ and employees’ Social Security numbers
  9. 9.  Your Project…  Address security threats one at a time  Automate the tools available at OWASP, M$, etc  Your Organization  Discuss regulations and penalties (risks to ROI)  Better coding practices means better code  Your customers  They should be demanding this already! And they will…
  10. 10. Let’s Dig In…
  11. 11.  A1 Injection  A2 Broken Authentication and Session Management  Was formerly 2010-A3  A3 Cross-Site Scripting (XSS)  was formerly 2010-A2  A4 Insecure Direct Object References  A5 Security Misconfiguration  was formerly 2010-A6  A6 Sensitive Data Exposure  2010-A7 Insecure Cryptographic Storage and 2010-A9 Insufficient Transport Layer Protection were merged to form 2013-A6
  12. 12.  A7 Missing Function Level Access Control  Renamed/broadened from 2010-A8 Failure to Restrict URL Access  A8 Cross-Site Request Forgery (CSRF)  Was formerly 2010-A5  A9 Using Components with Known Vulnerabilities  New but was part of 2010-A6 – Security Misconfiguration  A10 Unvalidated Redirects and Forwards
  13. 13. Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
  14. 14.  Querystrings…  Str sql = “SELECT * FROM ImportantTable WHERE Id =“ + Request.Querystring[“id”];  Forms…  Sql = “…” + model.UserInput + “;”;  Cookies…  Anywhere users can supply input that is interpreted!
  15. 15.  Keep untrusted data separate from commands and queries:  Parameterized SQL (99%)  Command Injection (file paths, etc)  XML Injection (XPath, XQuery, etc)  LDAP (Active Directory)
  16. 16. Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
  17. 17.  Are session management assets like user credentials and session IDs properly protected? You may be vulnerable if:  User authentication credentials aren’t protected when stored using hashing or encryption. See A6.  Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).  Session IDs are exposed in the URL (e.g., URL rewriting).  Session IDs are vulnerable to session fixation attacks.  Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.  Session IDs aren’t rotated after successful login.  Passwords, session IDs, and other credentials are sent over unencrypted connections. See A6.
  18. 18.  Prevent XSS (A3)  Use framework provided authentication and session management APIs  .NET Membership Providers  OWASP ESAPI Authenticator
  19. 19.  Again…REALLY?!?!?! “…if you do not ensure that all user supplied input is properly escaped, or you do not verify it to be safe via input validation, before including that input in the output page. Without proper output escaping or validation, such input will be treated as active content in the browser.” “If Ajax is being used to dynamically update the page, are you using safe JavaScript APIs? For unsafe JavaScript APIs, encoding or validation must also be used.”
  20. 20.  Validate your input!!!  Properly encode your output!!!  .NET  Use Razor View Engine – encoding by default!  ASP.NET View Engine – Use <%: %> not <%= %>  Microsoft AntiXSS Library  Rich content – OWASP AntiSamy
  21. 21. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
  22. 22. Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
  23. 23. Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
  24. 24. Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
  25. 25. A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
  26. 26. Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.
  27. 27. Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
  28. 28. Where to go from here?
  29. 29.  Include security into your dev process  Application Security Requirements  Application Security Architecture  Standard Security Controls  Secure Development Lifecycle  Application Security Education
  30. 30.  Get organized and talk with developers  Code reviews  Security Testing  Penetration Testing  Security Controls Automation
  31. 31.  Get Started…seriously…  Risk Based Portfolio Approach  Enable with a Strong Foundation  Integrate Security into Existing Processes  Provide Management Visibility
  32. 32. What Else?
  33. 33.  Cheat Sheets on all of the top 10 list  Specific cheat sheets for specific languages or frameworks  Other related technology security issues  Database  Web server  Etc…
  34. 34.  http://www.troyhunt.com/2011/12/free- ebook-owasp-top-10-for-net.html  Free Ebook – OWASP Top 10 for .NET  Based on 2010 list
  35. 35. The Security Development Lifecycle (SDL) is a software development process that helps developers build more secure software and address security compliance requirements while reducing development cost.  Take the top 10 and build these checks into your process  “Push left”
  36. 36. The end…
  37. 37. Please rate this talk! http://spkr8.com/t/24751 Benjamin Floyd dataplex@gmail.com @dataplex Skype: Dat4plex http://www.CombatProgramming.com Please rate this talk!