Common Web Application Vulnerabilities - Part 7
In this series of posts, my colleagues and I will dig into some specific, common web application vulnerabilities we observe regularly while performing network and application pentests. The intention of this series is to further expand upon a lot of the great information that already exists on the topic while preemptively addressing common questions we receive from our customers.
Part 7: Cross-Site Request Forgery Overview
Cross-Site Request Forgery (CSRF) vulnerabilities allow an attacker to cause a user to perform an unintended action. The vulnerability exists because browsers automatically send session cookies, and the same-origin policy does not prevent a site from sending a request to a different domain. For a successful CSRF exploit, the attacker needs to be able to determine all the parameters needed for the targeted function; the web application can only use HTTP cookies for tracking sessions. The user will also need to be logged in when visiting the malicious website, depending on the specific function the attacker is targeting.
Let’s use a very basic web application to demonstrate this vulnerability. The application was modified from a post on the Devshed forums to suit our purposes. This application has an authentication function and two defined user roles: user and admin. Admin users have the ability to view the list of users, add a new user and edit accounts. Regular users can only edit their own account.
Figure 1: Administrative vs. Regular Functions
The CSRF vulnerability exists in how the “Add User” function is implemented:
Figure 2: Vulnerable “Add User” Function
The function parameters are predictable. Only the username, password, confirm_password and role are submitted, and it appears that the web application has no way of tying a form submission to a particular session. Capturing the request confirms this:
Figure 3: Vulnerable “Add User” POST Request
Since the browser will automatically submit the session cookie, we can create a malicious page that will set each of the parameters and submit the form.
Figure 4: Malicious Web Page
Figure 5: User List Prior to CSRF Attack
Figure 6: User List After CSRF Attack
While this particular example required an administrative user to be logged in, a CSRF attack targeting a login function, for example, would not be restricted by this. If the default account and IP address of the web application are known - say for instance, a home router - an attacker can create a page to log into the router’s administrative portal and obtain a session cookie that can be sent with subsequent requests. In this scenario, attackers would not need to access the router portal directly. Instead, they would perform administrative functions via CSRF attacks.
One way to mitigate CSRF attacks is to implement additional methods to track sessions other than the session cookie. Let’s take a look at the following server-side code for a simple mitigation:
Figure 7: CSRF Token
This uses the “openssl_random_pseudo_bytes” function to generate 16 pseudo-random bytes and then calculates a 512-bit SHA hash. Other methods of token generation can be used. However, the key is they cannot be predictable from a large sample size. The token also needs to be tied to individual user sessions. Otherwise an attacker can reuse a valid token from their own session to conduct a CSRF attack. The token is submitted with the form via a hidden field:
Figure 8: Token Submitted in Hidden Field
On the server-side, the posted token value is compared to the established session token. If they differ, a possible CSRF attack has occurred, and the form is not processed:
Figure 9: Token Checked
Additional methods to mitigate CSRF include requiring the user to log in again for any sensitive function or verifying the action with something like a CAPTCHA.
This post discussed an overview of CSRF and how easy it is to exploit as long as an attacker knows the parameters of the targeted requests. While most CSRF attacks will require the user to be logged into the targeted application, any request can be forged without the proper security mitigations in place.
- Part 1.1 - XSS Overview and Reflected XSS
- Part 1.2 - Stored XSS
- Part 1.3 - DOM-Based XSS
- Part 4 - Command Injection Overview
- Part 5 - SQLi Overview and Examples
- Part 6 - Directory Traversal
- Part 8 - Session Fixation
- Part 9 - Padding Oracle Attacks
- Part 10 - Abusing Same-Origin Policy