SlideShare a Scribd company logo

Owasp Top 10-2013

•
•
n|u - The Open Security Community
n|u - The Open Security Community

The document summarizes the OWASP Top 10 security risks for web applications. It provides details on each risk such as the types of SQL injection attacks and how to prevent injection flaws. For each risk, it discusses how to determine if an application is vulnerable and recommendations for prevention, including input validation, authentication, authorization, encryption, and keeping components updated. The top risks are injection, broken authentication, XSS, insecure object references, security misconfiguration, sensitive data exposure, missing access controls, CSRF, use of vulnerable components, and unvalidated redirects.

Related slideshows

Web Application Security
Web Application SecurityWeb Application Security
Web Application Security
 
Testing Web Application Security
Testing Web Application SecurityTesting Web Application Security
Testing Web Application Security
 
Security testing presentation
Security testing presentationSecurity testing presentation
Security testing presentation
 
1 of 33
OWASP TOP 10 - 2013 Nitin Sharma
1. Injection 2. Broken authentication/session management 3. Cross-site scripting 4. Insecure Direct object refrences 5. Security Misconfiguration 6. Sensitive Data Exposure 7. Missing function level access control 8. Cross site request forgery 9. Using components with more vulnerabilities 10. Unvalidated Redirects and Forwards OWASP Top 10 Web Application Security Vulnerabilities
 SQL injection is a software vulnerability that occurs when data entered by users is sent to the SQL interpreter as a part of an SQL query  Attackers provide specially crafted input data to the SQL interpreter and trick the interpreter to execute unintended commands  a SQL Injection attack exploits security vulnerabilities at the database layer. By exploiting the SQL injection flaw, attackers can create, read, modify, or delete sensitive data A1 Injection
Am I Vulnerable To Injection?  The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.
 Preventing injection requires keeping untrusted data separate from commands and queries.  1.The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.  2.If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI provides many of these escaping routines.  3.Positive or “white list” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input. OWASP’s ESAPI has an extensible library of white list input validation routines. How Do I Prevent Injection?
Example String custname = request.getParameter("customerName"); // This should REALLY be validated too // perform input validation to detect attacks String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( ); Prepared Statement Example
 Weak authentication  Password-only  Easily guessable usernames (admin, etc.)  Unencrypted secrets are sniffable  How to break in  Guess/reset password  Have app email you new password  Sniff or crack password  Backend authentication  How are database passwords stored?  Trust relationships between hosts (IP address can be spoofed, etc.)  Countermeasures  Strong passwords  Remove default user names  Protect sensitive files A2 Broken Authentication and Session Management
 Attacker uses trusted application/company to reflect malicious code to end-user  Attacker can “hide” the malicious code  Unicode encoding  2 types of attacks  Stored  Reflected  Countermeasures  input validation  Positive  Negative: “< > ( ) # &”  Don’t forget these: “&lt &gt &#40 &#41 &#35 &#38”  User/customer education A3 Cross-Site Scripting (XSS)
Types of XSS Refleced/Non persistant XSS
Stored / Persistent Xss
 Preventing XSS requires keeping untrusted data separate from active browser content.  1.The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into  2.Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications require special characters in their input. How Do I Prevent XSS?
 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. A4 Insecure Direct Object References
Am I Vulnerable  The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:  Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
 Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):  Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object How Do I Prevent This?
 Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date. A5 Security Misconfiguration
Am I Vulnerable to Attack  1.Is everything unnecessary disabled, removed, or not installed (e.g. ports, services, pages, accounts, privileges)?  2.Are default account passwords changed or disabled?  3.Is your error handling set up to prevent stack traces and other overly informative error messages from leaking?  4.Are the security settings in your development frameworks (e.g., Struts, Spring, ASP.NET) and libraries understood and configured properly? A concerted, repeatable process is required to develop and maintain a proper application security configuration.
 The primary recommendations are to establish all of the following:  1.A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically.  2.A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. How Do I Prevent This?
 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 identity theft, credit card fraud, 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. A6 Sensitive Data Exposure
Am I Vulnerable to Data Exposure  The first thing you have to determine is which data is sensitive enough to require extra protection. For example, passwords, credit card numbers, health records, and personal information should be protected. For all such data, ensure:  1.It is encrypted everywhere it is stored long term, including backups of this data.  2.It is encrypted in transit, ideally internally as well as externally. All internet traffic should be encrypted.
 The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:  1.Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.  2.Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.  3.Ensure strong standard algorithms and strong keys are used, and proper key management is in place. How Do I Prevent This?
 Virtually all 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 unauthorized functionality. A7 Missing function level access control
Am I Vulnerable to Function level Access  The best way to find out if an application has failed to properly restrict function level access is to verify every application function:  1.Does the UI show navigation to unauthorized functions?  2.Are proper authentication and authorization checked?
 1.The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.  2.If the function is involved in a workflow, check to make sure the conditions are in the proper state to allow access. How Do I Prevent Function level Access?
 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. A8 Cross site request forgery
Owasp Top 10-2013
Am I Vulnerable to CSRF  See if each link and form includes an unpredictable token. Without such a token, attackers can forge malicious requests.  Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets. You should check multistep transactions, as they are not inherently immune.
 Preventing CSRF usually requires the inclusion of an unpredictable token in each HTTP request. Such tokens should, at a minimum, be unique per user session.  1.The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is subject to exposure.  2. OWASP’s ESAPI includes CSRF methods developers can use to prevent such vulnerabilities.  3.Requiring the user to reauthenticate, or prove they are a user (e.g., via a CAPTCHA) can also protect against CSRF How Do I Prevent CSRF?
 Vulnerable components, such as libraries, frameworks, and other software modules almost always run with full privilege. So, if exploited, they can cause serious data loss or server takeover. Applications using these vulnerable components may undermine their defenses and enable a range of possible attacks and impacts. A9 Using Components with Known Vulnerabilities
Am I Vulnerable ?  Determining if you are vulnerable requires searching the databases of your applications as well as keeping abreast of project mailing lists and announcements for anything that might be a vulnerability.
 Use components that you didn’t write. But realistically, the best way to deal with this risk is to ensure that you keep your components up-to-date. How Do I Prevent This?
 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. A10 Unvalidated Redirects and Forwards
Am I Vulnerable to Redirection  The best way to find out if an application has any unvalidated redirects or forwards is to:  1.Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.  2.Also, spider the site to see if it generates any redirects.
 Safe use of redirects and forwards can be done in a number of ways:  1.Simply avoid using redirects and forwards.  2.If used, don’t involve user parameters in calculating the destination. This can usually be done.  3.If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user. It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL. How Do I Prevent This?

More Related Content

Owasp Top 10-2013

  • 1. OWASP TOP 10 - 2013 Nitin Sharma
  • 2. 1. Injection 2. Broken authentication/session management 3. Cross-site scripting 4. Insecure Direct object refrences 5. Security Misconfiguration 6. Sensitive Data Exposure 7. Missing function level access control 8. Cross site request forgery 9. Using components with more vulnerabilities 10. Unvalidated Redirects and Forwards OWASP Top 10 Web Application Security Vulnerabilities
  • 3.  SQL injection is a software vulnerability that occurs when data entered by users is sent to the SQL interpreter as a part of an SQL query  Attackers provide specially crafted input data to the SQL interpreter and trick the interpreter to execute unintended commands  a SQL Injection attack exploits security vulnerabilities at the database layer. By exploiting the SQL injection flaw, attackers can create, read, modify, or delete sensitive data A1 Injection
  • 4. Am I Vulnerable To Injection?  The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.
  • 5.  Preventing injection requires keeping untrusted data separate from commands and queries.  1.The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.  2.If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI provides many of these escaping routines.  3.Positive or “white list” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input. OWASP’s ESAPI has an extensible library of white list input validation routines. How Do I Prevent Injection?
  • 6. Example String custname = request.getParameter("customerName"); // This should REALLY be validated too // perform input validation to detect attacks String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( ); Prepared Statement Example
  • 7.  Weak authentication  Password-only  Easily guessable usernames (admin, etc.)  Unencrypted secrets are sniffable  How to break in  Guess/reset password  Have app email you new password  Sniff or crack password  Backend authentication  How are database passwords stored?  Trust relationships between hosts (IP address can be spoofed, etc.)  Countermeasures  Strong passwords  Remove default user names  Protect sensitive files A2 Broken Authentication and Session Management
  • 8.  Attacker uses trusted application/company to reflect malicious code to end-user  Attacker can “hide” the malicious code  Unicode encoding  2 types of attacks  Stored  Reflected  Countermeasures  input validation  Positive  Negative: “< > ( ) # &”  Don’t forget these: “&lt &gt &#40 &#41 &#35 &#38”  User/customer education A3 Cross-Site Scripting (XSS)
  • 9. Types of XSS Refleced/Non persistant XSS
  • 11.  Preventing XSS requires keeping untrusted data separate from active browser content.  1.The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into  2.Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications require special characters in their input. How Do I Prevent XSS?
  • 12.  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. A4 Insecure Direct Object References
  • 13. Am I Vulnerable  The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:  Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
  • 14.  Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):  Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object How Do I Prevent This?
  • 15.  Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date. A5 Security Misconfiguration
  • 16. Am I Vulnerable to Attack  1.Is everything unnecessary disabled, removed, or not installed (e.g. ports, services, pages, accounts, privileges)?  2.Are default account passwords changed or disabled?  3.Is your error handling set up to prevent stack traces and other overly informative error messages from leaking?  4.Are the security settings in your development frameworks (e.g., Struts, Spring, ASP.NET) and libraries understood and configured properly? A concerted, repeatable process is required to develop and maintain a proper application security configuration.
  • 17.  The primary recommendations are to establish all of the following:  1.A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically.  2.A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. How Do I Prevent This?
  • 18.  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 identity theft, credit card fraud, 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. A6 Sensitive Data Exposure
  • 19. Am I Vulnerable to Data Exposure  The first thing you have to determine is which data is sensitive enough to require extra protection. For example, passwords, credit card numbers, health records, and personal information should be protected. For all such data, ensure:  1.It is encrypted everywhere it is stored long term, including backups of this data.  2.It is encrypted in transit, ideally internally as well as externally. All internet traffic should be encrypted.
  • 20.  The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:  1.Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.  2.Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.  3.Ensure strong standard algorithms and strong keys are used, and proper key management is in place. How Do I Prevent This?
  • 21.  Virtually all 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 unauthorized functionality. A7 Missing function level access control
  • 22. Am I Vulnerable to Function level Access  The best way to find out if an application has failed to properly restrict function level access is to verify every application function:  1.Does the UI show navigation to unauthorized functions?  2.Are proper authentication and authorization checked?
  • 23.  1.The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.  2.If the function is involved in a workflow, check to make sure the conditions are in the proper state to allow access. How Do I Prevent Function level Access?
  • 24.  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. A8 Cross site request forgery
  • 26. Am I Vulnerable to CSRF  See if each link and form includes an unpredictable token. Without such a token, attackers can forge malicious requests.  Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets. You should check multistep transactions, as they are not inherently immune.
  • 27.  Preventing CSRF usually requires the inclusion of an unpredictable token in each HTTP request. Such tokens should, at a minimum, be unique per user session.  1.The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is subject to exposure.  2. OWASP’s ESAPI includes CSRF methods developers can use to prevent such vulnerabilities.  3.Requiring the user to reauthenticate, or prove they are a user (e.g., via a CAPTCHA) can also protect against CSRF How Do I Prevent CSRF?
  • 28.  Vulnerable components, such as libraries, frameworks, and other software modules almost always run with full privilege. So, if exploited, they can cause serious data loss or server takeover. Applications using these vulnerable components may undermine their defenses and enable a range of possible attacks and impacts. A9 Using Components with Known Vulnerabilities
  • 29. Am I Vulnerable ?  Determining if you are vulnerable requires searching the databases of your applications as well as keeping abreast of project mailing lists and announcements for anything that might be a vulnerability.
  • 30.  Use components that you didn’t write. But realistically, the best way to deal with this risk is to ensure that you keep your components up-to-date. How Do I Prevent This?
  • 31.  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. A10 Unvalidated Redirects and Forwards
  • 32. Am I Vulnerable to Redirection  The best way to find out if an application has any unvalidated redirects or forwards is to:  1.Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.  2.Also, spider the site to see if it generates any redirects.
  • 33.  Safe use of redirects and forwards can be done in a number of ways:  1.Simply avoid using redirects and forwards.  2.If used, don’t involve user parameters in calculating the destination. This can usually be done.  3.If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user. It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL. How Do I Prevent This?