OWASP TOP 10 by Team xbios

397 views

Published on

OWASP Top 10 vulnerabilities in 2013 and its avoiding techniques.

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
397
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OWASP TOP 10 by Team xbios

  1. 1. By team Xbios
  2. 2. INJECTION flaws ‘ or 1 = 1 ’- -
  3. 3. Injection means… Tricking an application into including unintended commands in the data sent to an interpreter Interpreter Take strings and interpret them as commands Eg : SQL, OS Shell, LDAP, XPath, Hibernate, etc…
  4. 4. SQL Injection Example $username = $_POST[‘username’]; $password = $_POST[‘password’]; $query = “SELECT * FROM user WHERE username = ‘$username’ AND password = ‘$password’”; $user = $db->query($query);
  5. 5. Recommendations Avoid the interpreter entirely, or Use an interface that supports bind variables (e.g., prepared statements, or stored procedures), Encode all user input before passing it to the interpreter References For more details, read the new http://www.owasp.org/index.php/SQL_Injection_ Prevention_Cheat_Sheet
  6. 6. HTTP is a “stateless” protocol • SESSION ID used to track state since HTTP doesn’t and it is just as good as credentials to an attacker. • SESSION ID is typically exposed on the network, in browser, in logs, … Beware of side-doors Change my password, remember my password, forgot my password, secret question, logout, email address, etc…
  7. 7. Site uses URL rewriting (i.e., put session in URL) 3 2 Hacker uses JSESSIONID and takes over victim’s account 4 Bus. Functions E-Commerce Knowledge Mgmt Transactions Custom Code User clicks on a link to http://www.hacker.com in a forum Hacker checks referrer logs on www.hacker.com and finds user’s JSESSIONID 5 Communication www.boi.com?JSESSIONID=9FA1DB9EA... Administration User sends credentials Accounts 1 Finance Attack Illustration
  8. 8. Impacts User accounts compromised or user sessions hijacked Recommendations • Verify your architecture • Verify the implementation References Follow the guidance from http://www.owasp.org/index.php/Authentication_Cheat_Sheet
  9. 9. XSS <script> alert(”cross site scripting”); </script> ‘
  10. 10. Occurs any time… Raw data from attacker is sent to an innocent user’s browser Raw Data…. • Stored in database • Reflected from web input (form field, hidden field, URL, etc…) • Sent directly into rich JavaScript client
  11. 11. Impacts • Steal user’s session, steal sensitive data, rewrite web page, redirect user to phishing or malware site • Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior on vulnerable site and force user to other sites
  12. 12. Recommendations • Don’t include user supplied input in the output page • Defend Against the Flaw Primary Recommendation: Use OWASP’s ESAPI to output encode: • For large chunks of user supplied HTML, use OWASP’s AntiSamy References For how to output encode properly, read the new http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet
  13. 13. Insecure Direct Object References
  14. 14. Occurs when… • Developer exposes a reference to an internal implementation object. • Without an access control check or other protection, attackers can manipulate Impacts • Users are able to access unauthorized files or data
  15. 15. Insecure Direct Object References Illustrated https://www.onlinebank.com/user?acct=6065 • Attacker notices his acct parameter is 6065 ?acct=6065 • He modifies it to a nearby number ?acct=6066 • Attacker views the victim’s account information
  16. 16. Recommendations • Eliminate the direct object reference • Validate the direct object reference
  17. 17. Security Misconfiguration
  18. 18. Risks • Default settings can be insecure, and intended for development not production. • Attackers can use misconfigured software to gain knowledge and access. Impacts • XSS flaw exploits due to missing application framework patches. • Unauthorized access to default accounts, application functionality or data.
  19. 19. Recommendations • Know the tools you use, and configure them correctly. • Keep up to date on vulnerabilities in the tools you use. • Remove/disable any services/features you aren’t using.
  20. 20. Sensitive Data Exposure
  21. 21. Storing and transmitting sensitive data insecurely • Failure to identify all sensitive data • Failure to identify all the places that this sensitive data gets stored • Failure to properly protect this data in every location Impacts • Attackers access or modify confidential or private information • Attackers extract secrets to use in additional attacks • Expense of cleaning up the incident • Business gets sued and/or fined
  22. 22. 1 Victim enters credit card number in form Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Insecure Cryptographic Storage Illustrated Custom Code 4 Log files Malicious insider steals 4 million credit card numbers Logs are accessible to all members of IT staff for debugging purposes Error handler logs CC details because merchant gateway is unavailable 3 2
  23. 23. Recommendations • • • • Verify your architecture Protect with appropriate mechanisms Use the mechanisms correctly Verify the implementation
  24. 24. Missing Function Level Access Control
  25. 25. Risks • Hidden things can easily be found. • Creative people will eventually find your hidden URLs Impacts • Attackers invoke functions and services they’re not authorized for • Access other user’s accounts and data • Perform privileged actions
  26. 26. Failure to Restrict URL Access Illustrated https://www.onlinebank.com/user/getAccounts • Attacker notices the URL indicates his role /user/getAccounts • He modifies it to another directory (role) /admin/getAccounts, or /manager/getAccounts • Attacker views more accounts than just their own
  27. 27. Recommendations • For each URL, a site needs to do 3 things • Verify your architecture • Verify the implementation
  28. 28. Cross Site Request Forgery
  29. 29. Risks • Evil websites can perform actions for users logged into your site. • Vulnerability is caused by browsers automatically including user authentication data with each request Impacts • Initiate transactions (transfer funds, logout user, close account) • Access sensitive data • Change account details
  30. 30. CSRF Illustrated While logged into vulnerable site, victim views attacker site Communication Knowledge Mgmt E-Commerce Bus. Functions 2 Administration Transactions Hidden <img> tag contains attack against vulnerable site Application with CSRF vulnerability Accounts Finance 1 Attacker sets the trap on some website on the internet (or simply via an e-mail) Custom Code 3 <img> tag loaded by browser – sends GET request (including credentials) to vulnerable site Vulnerable site sees legitimate request from victim and performs the action requested
  31. 31. Prevention • Add opaque expiring tokens to all forms. • Requests missing tokens or containing invalid tokens should be rejected.
  32. 32. Using Known Vulnerable Components
  33. 33. Vulnerable components are common The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could range from minimal to complete host takeover and data compromise Impacts The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could range from minimal to complete host takeover and data compromise
  34. 34. Preventing Known Vulnerable Components • One option is not to use components that you didn’t write. But that’s not very realistic. • Most component projects do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. So upgrading to these new versions is critical.
  35. 35. Unvalidated Redirects and Forwards
  36. 36. Web application redirects are very common • And frequently include user supplied parameters in the destination URL • If they aren’t validated, attacker can send victim to a site of their choice Impacts • Redirect victim to phishing or malware site • Attacker’s request is forwarded past security checks, allowing unauthorized function or data access
  37. 37. Unvalidated Redirect Illustrated Attacker sends attack to victim via email or webpage Bus. Functions E-Commerce Communication Knowledge Mgmt Transactions Victim clicks link containing invalidated parameter Application redirects victim to attacker’s site Administration 2 3 Finance From: Internal Revenue Service Subject: Your Unclaimed Tax Refund Our records show you have an unclaimed federal tax refund. Please click here to initiate your claim. Accounts 1 Custom Code Request sent to vulnerable site, including attacker’s destination site as parameter. Redirect sends victim to attacker site http://www.irs.gov/taxrefund/claim.jsp?year=2006 & … &dest=www.evilsite.com Evil Site 4 Evil site installs malware on victim, or phish’s for private information
  38. 38. Avoiding Unvalidated Redirects and Forwards • Avoid using redirects and forwards as much as you can • If used, don’t involve user parameters in defining the target URL • If you ‘must’ involve user parameters, then either • Validate each parameter • Use server side mapping
  39. 39. How do you address these problems? • Develop Secure Code • Review Your Applications • Have an expert team review your applications • Review your applications yourselves following OWASP Guidelines
  40. 40. How do you address these problems? • Develop Secure Code • Review Your Applications

×