Successfully reported this slideshow.
Your SlideShare is downloading. ×

Owasp top 10 vulnerabilities 2013

Ad

OWASP Top 10
Vulnerabilities - 2013
- Vishrut Sharma

Ad

OWASP
• OWASP stands for Open Web Application Security Project. An
online community that publishes methodologies, data on ...

Ad

Top 10 Vulnerabilities
• A1. Injection Vulnerabilities
• A2. Broken Authentication and Session Management
• A3. Cross Site...

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Upcoming SlideShare
Attackers Vs Programmers
Attackers Vs Programmers
Loading in …3
×

Check these out next

1 of 21 Ad
1 of 21 Ad

More Related Content

Owasp top 10 vulnerabilities 2013

  1. 1. OWASP Top 10 Vulnerabilities - 2013 - Vishrut Sharma
  2. 2. OWASP • OWASP stands for Open Web Application Security Project. An online community that publishes methodologies, data on web application vulnerabilities (detection and remediation techniques), standards, tools and technologies.
  3. 3. Top 10 Vulnerabilities • A1. Injection Vulnerabilities • A2. Broken Authentication and Session Management • A3. Cross Site Scripting (XSS) • A4. Insecure Direct Object References • A5. Security Misconfiguration • A6. Sensitive Data Exposure • A7. Missing Function Level Access Control • A8. Cross Site Request Forgery (CSRF/XSRF) • A9. Using Components with Known Vulnerabilities • A10. Unvalidated Redirects and Forwards
  4. 4. A1. Injection Vulnerabilities • An attacker may send untrusted data to an interpreter as part of a command or query tricking it into executing such query and allows attacker to access data without proper authorization. • Types: SQL injection, Blind SQL injection, OS Command injection, etc. • Example: vulnerable SQL call: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; Attack: the attacker modifies the ‘id’ parameter value in browser to send: ' or '1'=‘1. “ ‘ “ special character in SQL that specifies the beginning and end of string data.
  5. 5. A2. Broken Authentication and Session Management • Caused by poorly configured custom code or misconfigured off- the-shelf code. • Credentials should always be protected: An authentication system will need to pass some secret over the network. That secret should either be encrypted or hashed with a salt and should not be transmitted in clear-text. • Session ID should be secured: Session ID should not be exposed in the URL. It should be cryptographically random and should expire once the user terminates the session.
  6. 6. A3. Cross Site Scripting (XSS) • XSS is different from CSS (Cascading Style Sheets) which is a mechanism to add style (font, color, spacing, etc.) to a web page. • XSS is a type of injection attack that mostly affects HTML and Java languages. XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. • Types: 1. Reflected; 2. Persistent or Stored; 3. DOM-based
  7. 7. A3.1 – Reflected XSS • Client sends malicious input to a server and the server returns it back to the client. The client executes the code in the context of the current user. • Example: The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user. <% String eid = request.getParameter("eid"); %> ... Employee ID: <%= eid %> The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response.
  8. 8. A3.2 – Persistent or Stored XSS • Client sends malicious input to the server and the input is stored by the server. Later, the input is returned to another client and the data is executed as code in the context of the current user. • Example: An Input Box on a webpage to get email address from the user. The HTML code will look like below. <input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" /> Now, the attacker needs to find a way to inject code outside the <input> tag as below. <input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><script>alert(document.cookie)</script> This will get stored on the server and when another visits this page the browser will run the code and display cookie information of the current user.
  9. 9. A3.3 – DOM-Based XSS • Malicious input is never read from the server but instead sent by a malicious user from some previous state in the browser. The malicious input, in this case, is not attacking a vulnerability on the server but the vulnerable client-code. • Example: <script> document.write("Site is at: " + document.location.href + "."); </script> An attacker may append #<script>alert('xss')</script> to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. In this example, the code is immediately executed and an alert of "xss" is displayed by the page.
  10. 10. A4. Insecure Direct Object References • Occurs when a web application does not validate a client’s access to a resource. Web applications frequently send a set of links that have references to objects, such as database row, to their clients. • Example: Consider this URL which references to account number of the user. http://example.com/app/accountInfo?acct=1234567 An attacker can change the value of acct and may open the account details of another user.
  11. 11. A5. Security Misconfiguration • Flaws that arise due to misconfiguration of products, protocols, or features. • Missing Patches • Misconfigured or disabled security features • Default accounts • Unnecessary/unused services, features, or ports • Administrative backdoors
  12. 12. A6. Sensitive Data Exposure • Sensitive data like password, credit card information, session ID, etc. is either visible to users or transmitted in clear-text. • Example: A site simply doesn’t use SSL for all authenticated pages. Attacker simply monitors network traffic (like an open wireless network), and steals the user’s session cookie. Attacker then replays this cookie and hijacks the user’s session, accessing the user’s private data.
  13. 13. A7. Missing Function Level Access Control • Application does not perform access control check when a user accesses a resource i.e. every request the user makes is not verified for proper authorization. In such case, an attacker may simply access any resource on the server. • Example: The following URLs require authentication. Admin rights are also required for access to the admin_getappInfo page. http://example.com/app/getappInfo http://example.com/app/admin_getappInfo If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user is allowed to access the admin_getappInfo page, this is also a flaw, and may lead the attacker to more improperly protected admin pages.
  14. 14. A8. Cross Site Request Forgery (CSRF/XSRF/CSurf) • 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. • Example: The application allows a user to submit a state changing request that does not include anything secret. For example: http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control: <img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" /> If the victim visits any of the attacker’s sites while already authenticated to example.com, these forged requests will automatically include the user’s session info, authorizing the attacker’s request.
  15. 15. A9. Using Components with Known Vulnerabilities • 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. • Example: Apache CXF Authentication Bypass – By failing to provide an identity token, attackers could invoke any web service with full permission. (Apache CXF is a services framework, not to be confused with the Apache Application Server.)
  16. 16. A10. Unvalidated Redirects and Forwards • 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. • Example: The application has a page called “redirect.jsp” which takes a single parameter named “url”. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware. http://www.example.com/redirect.jsp?url=evil.com
  17. 17. Additional Knowledge • You will see, once you start scanning the applications and analyzing the results, a mention of vulnerability called Blind SQL Injection. Blind SQL Injection is a bit different than SQL Injection. • SQL Injection: Occurs when an attacker injects malicious SQL query in a web application which fetches the result from underlying database and shows as output. • Blind SQL Injection: Occurs when an attacker injects SQL query to perform true or false operations on database and determines output based on application response.
  18. 18. Comparison of SQLi and Blind SQLi SQL Injection Blind SQL Injection Attacker relies on error message returned from database Attacker might not see an error message It directly passes the query It asks true or false questions to the database Attacker is able to see the result Attacker is unable to see the result Attacker can reconstruct the database structure based on application response Attacker cannot perform any operation on database
  19. 19. Time-based Blind SQLi • Works on the basis that true or false queries can be answered by the amount of time a request takes to complete. For example, the statement waitfor used with the delay argument causes SQL server to pause for the specified period of time. waitfor delay ‘0:0:5’ This will pause the query for 5 seconds.
  20. 20. Why Blind SQL Injection This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection. When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query's syntax is incorrect. Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible.
  21. 21. Thank You

×