A brief overview of OWASP top 10 risks and what it takes to minimize them in java.(Part -5)
A CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim. This vulnerability is extremely widespread.
Attacker creates forged HTTP requests and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is authenticated, the attack succeeds.
- Do not use GET requests (URLs) for sensitive data or to perform value transactions
- Use only POST methods when processing sensitive data from the user.
- However, the URL may contain the random token as this creates a unique URL, which makes CSRF almost impossible to perform.
- The token is a generic term that is used for implementations of the “synchronizer token pattern”.
There are several working implementations that use the token today, including Struts 1 and 2, Webwork, SpringMVC, and even OWASP’s own CSRFGuard Project .
Using ESAPI to prevent CSRF (synchronizer token pattern)
Generate new CSRF token and add it to user once on login and store user in http session.
This code should be executed when the user logs into the application. This is done in the default ESAPI implementation, and it is stored as a member variable of the User object that gets stored in the session.
On any forms or urls that should be protected, add the token as a parameter / hidden field.
The addCSRFToken method below should be called for any url that is going to be rendered that needs CSRF protection.
Alternatively if you are creating a form, or have another technique of rendering URLs (like c:url), then be sure to add a parameter or hidden field with the name “ctoken” and the value of DefaultHTTPUtilities.getCSRFToken(). That should do the work of adding the data to the url or form. We’ll validate it in the next step.
On the server side for those protected actions, check that the submitted token matches the token from the user object in the session. (Assuming you’ve implemented this properly, a failure constitutes a security issue.)
Ensure that you call this method from your servlet or struts action or jsf controller, or whatever server side mechanism you’re using to handle requests. This should be called on any request that you need to validate for CSRF protection. Notice that when the tokens do not match, it’s considered a possible forged request.
On logout and session timeout, the user object is removed from the session and the session destroyed.
In this step, logout is called. When that happens, note that the session is invalidated and the current user object is reset to be an anonymous user, thereby removing the reference to the current user and accordingly the csrf token.
9 Using Known Vulnerable Components
Some vulnerable components (e.g., framework libraries) can be identified and exploited with automated tools, expanding the threat agent pool beyond targeted attackers to include chaotic actors.
Mounting an attack is dependent on the vulnerable component. Depending on the vulnerability of the component the attacker can exploit the vulnerability to mount an attack.
1) Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin).
2) Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
3) Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
4) Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.
When using 3 rd party tools and libraries depending on the project they should be checked for known vulnerabilities.
10 Unvalidated Redirects and Forwards
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.
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.
3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
Avoid redirects and forwards wherever possible
Don’t allow user parameters in target URL
1.Dangerous redirects:
The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website.
When applications allow user input to forward requests between different parts of the site, the application must check that the user is authorized to access the url, perform the functions it provides, and it is an appropriate url request. If the application fails to perform these checks, an attacker crafted URL may pass the application’s access control check and then forward the attacker to an administrative function that is not normally permitted.
Originally published at http://neatrick.wordpress.com on December 11, 2015.
