1. Cross-Site Scripting (XSS) – Impact MODERATE
XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are three known types of XSS flaws: 1) Stored, 2) Reflected, and 3) DOM based XSS.
Detection of most XSS flaws is fairly easy via testing or code analysis.
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
Am 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 output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed.
Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
Example Attack Scenario:
The 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:
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.
How Do I Prevent XSS?
Preventing XSS requires keeping untrusted data separate from active browser content.
2. Positive or “whitelist” input validation with appropriate canonicalization and decoding is also recommended as it helps protect against XSS, but is not a complete defense as many applications require special characters in their input. Such validation should, as much as possible, decode any encoded input, and then validate the length, characters, format, and any business rules on that data before accepting the input.
2. Insecure Direct Object References: Impact MODERATE
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.
Threat Agents: Consider the types of users of your system. Do any users have only partial access to certain types of system data?
Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws and code analysis quickly shows whether authorization is properly verified.
Technical Impacts: Such flaws can compromise all the data that can be referenced by the parameter. Unless the name space is sparse, it’s easy for an attacker to access all available data of that type.
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:
1. For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
2. 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 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.
Example Attack Scenario
The application uses unverified data in a SQL call that is accessing account information:
String query = “SELECT * FROM accts WHERE account = ?”;
PreparedStatement pstmt=connection.prepareStatement (query,);
pstmt.setString (1, request.getparameter (“acct”));
ResultSetresults = 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 account.
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):
1. Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. 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.
2. 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.
3. Cross-Site Request Forgery (CSRF): Impact MODERATE
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.
Threat Agents: Consider anyone who can trick your users into submitting a request to your website. Any website or other HTML feed that your users access could do this.
CSRF takes advantage of web applications that allow attackers to predict all the details of a particular action. Since browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones. Detection of CSRF flaws is fairly easy via penetration testing or code analysis.
Attackers can cause victims to change any data the victim is allowed to change or perform any function the victim is authorized to use.
Am 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. Without such an unpredictable 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.
Note that session cookies, source IP addresses, and other information that is automatically sent by the browser doesn’t count since this information is also included in forged requests.
OWASP’s CSRF Tester tool can help generate test cases to demonstrate the dangers of CSRF flaws.
Example Attack Scenario
The application allows a user to submit a state changing request that does not include anything secret. Like so:
So, 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.
If the victim visits any of these sites while already authenticated to example.com, any forged requests will include the user’s session info, inadvertently authorizing the request.
How Do I Prevent CSRF?
Preventing CSRF requires the inclusion of a unpredictable token in the body or URL of each HTTP request. Such tokens should at a minimum be unique per user session, but can also be unique per request.
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. 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.
4. Security Misconfiguration: Impact MODERATE
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, including all code libraries used by the application.
Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system.
Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.
Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.
Am I Vulnerable?
Have you performed the proper security hardening across the entire application stack?
1. Do you have a process for keeping all your software up to date? This includes the OS, Web/App Server, DBMS, applications, and all code libraries.
2. Is everything unnecessary disabled, removed, or not installed (e.g. ports, services, pages, accounts, privileges)?
3. Are default account passwords changed or disabled?
4. Is your error handling set up to prevent stack traces and other overly informative error messages from leaking?
5. Are the security settings in your development frameworks (e.g., Struts, Spring, and ASP.NET) and libraries understood and configured properly?
A concerted, repeatable process is required to develop and maintain a proper application security configuration.
Example Attack Scenarios
Scenario #1: Your application relies on a powerful framework like Struts or Spring. XSS flaws are found in these framework components you rely on. An update is released to fix these flaws but you don’t update your libraries. Until you do, attackers can easily find and exploit these flaws in your app.
Scenario #2: The app server 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 she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she reverses to get all your custom code. She then find a serious access control flaw in your application.
Scenario #4: App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.
How Do I Prevent This?
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. This process should be automated to minimize the effort required to setup a new secure environment.
2. A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. This need to include all code libraries as well, which are frequently overlooked.
3. A strong application architecture that provides good separation and security between components.
4. Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches.
5. Failure to Restrict URL Access: Impact MODERATE
Threat Agents: Anyone with network access can send your application a request. Could anonymous users access a private page or regular users a privileged page?
Attacker, who is an authorized system user, simply changes the URL to a privileged page. Is access granted? Anonymous users could access private pages that aren’t protected.
Applications are not always protecting page requests properly. Sometimes, URL protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist to attack.
Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack.
Am 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:
1. Is authentication required to access that page?
2. 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. Penetration testing can also verify whether proper protection is in place.
Example Attack Scenario
The attacker simply forces browses to target URLs. Consider the following URLs which are both supposed to require authentication. Admin rights are also required for access to the “admin_getappInfo” page.
If 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.
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), all of the following are recommended:
1. The authentication and authorization policies be role based, to minimize the effort required to maintain these policies.
2. The policies should be highly configurable, in order to minimize any hard coded aspects of the policy.
3. The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page.
4. If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access.
6. Insufficient Transport Layer Protection: Impact MODERATE
Threat Agents: Consider anyone who can monitor the network traffic of your users. If the application is on the internet, who knows how your users access it. Don’t forget back end connections.
Monitoring users’ network traffic can be difficult, but is sometimes easy. The primary difficulty lies in monitoring the proper network’s traffic while users are accessing the vulnerable site.
Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used.
Detecting basic flaws is easy. Just observe the site’s network traffic. More subtle flaws require inspecting the design of the application and the server configuration.
Such flaws expose individual users’ data and can lead to account theft. If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.
Am I Vulnerable?
The best way to find out if an application has insufficient transport layer protection is to verify that:
1. SSL is used to protect all authentication related traffic.
2. SSL is used for all resources on all private pages and services. This protects all data and session tokens 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.
3. Only strong algorithms are supported.
4. All session cookies have their ‘secure’ flag set so the browser never transmits them in the clear.
5. 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.
Example Attack Scenarios
Scenario #1: A 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: A 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 the site’s customers lures them to a lookalike site which doesn’t have a valid certificate, which generates 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.
Scenario #3: A site simply uses standard ODBC/JDBC for the database connection, not realizing all traffic is in the clear.
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. At a minimum, do all of the following:
1. Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.
2. Set the ‘secure’ flag on all sensitive cookies.
3. Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant) algorithms.
4. Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.
5. Backend and other connections should also use SSL or other encryption technologies.
For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements on Communications Security.
7. Unvalidated Redirects and Forwards: Impact MODERATE
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.
Threat Agents: Consider anyone who can trick your users into submitting a request to your website. Any website or other HTML feed that your users use could do this.
Attacker links to unvalidated redirect and tricks victims into clicking it. Victims are more likely to click on it, since the link is to a valid site. Attacker targets unsafe forward to bypass security checks.
Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.
Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder, since they target internal pages.
Such redirects may attempt to install malware or trick victims into disclosing passwords or other sensitive information. Unsafe forwards may allow access control bypass.
Am I Vulnerable?
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 (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.
3. If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and test those that do.
Example Attack Scenarios
Scenario #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.
Scenario #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 application’s access control check and then forward the attacker to an administrative function that she would not normally be able to access.
For more info refer OWASP Article on Open Redirects
To help organizations and developers reduce their application security risks in a cost effective manner, OWASP has produced numerous free and open resources that one can use to address application security in an organization. The following are some of the many resources OWASP has produced to help organizations produce secure web applications.
Application Security Requirements: To produce a secure web application, you must define what secure means for that application. OWASP recommends you use the OWASP Application Security Verification Standard as a guide for setting the security requirements for your application(s).
Application Security Architecture: Rather than retrofitting security into your applications, it is far more cost effective to design the security in from the start. OWASP recommends the OWASP Developer’s Guide as a good starting point for guidance on how to design security in from the beginning.
Standard Security Controls: •Building strong and usable security controls is exceptionally difficult. Providing developers with a set of standard security controls radically simplifies the development of secure applications. OWASP recommends the OWASP Enterprise Security API (ESAPI) project as a model for the security APIs needed to produce secure web applications. ESAPI provides reference implementations in Java, .NET, PHP, Classic ASP, Python, and Cold Fusion.
Secure Development Lifecycle: To improve the process your organization follows when building such applications, OWASP recommends the OWASP Software Assurance Maturity Model. This model helps organizations formulate and implement a strategy for software security that is tailored to the specific risks facing their organization.
Application Security Education: The OWASP Education Project provides training materials to help educate developers on web application security and has compiled a large list of OWASP Educational Presentations. For hands-on learning about vulnerabilities, try OWASP WebGoat. To stay current, come to an OWASP AppSec Conference, OWASP Conference Training, or local OWASP Chapter meetings.