Skip to main content

Common Web Application Vulnerabilities - Part 7

November 04, 2014

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

We’re essentially duplicating the POST request, prepopulating the parameters with our own values. Since the parameters are in hidden form fields and we’re using JavaScript to automatically submit the form, simply visiting the malicious site will add a new “hacker” user with admin privileges - provided the administrative user is currently logged in.

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.

Additional Posts

Related Blogs

November 05, 2014

Common Web Application Vulnerabilities - Part 8

Session fixation is an attack against a web application’s session management functionality. The issue is not as common today given that many of the cu...

See Details

November 06, 2014

Common Web Application Vulnerabilities - Part 9

Padding oracle attacks are becoming more frequent and recently made headlines with the Padding On Oracle Downgraded Legacy Encryption (POODLE) vulnera...

See Details

November 07, 2014

Common Web Application Vulnerabilities - Part 10

In this post, we will cover a couple of concepts and implementations that have historically been used to circumvent the Same-Origin Policy (SOP). Spec...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Privacy Policy

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.


Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cybersecurity Events in your area.