Cross-site request forgery is an attack in which an adversary can submit a malicious request on behalf of the victim user. In an application with cross-site request forgery (CSRF) vulnerabilities, malicious users can submit unauthorized commands since the application trusts the origin user account. Also known as session riding, XSRF, session fixation, hostile linking, or the one-click attack, CSRF attacks primarily target legitimate requests that cause a server state change, enabling the attacker to inherit the victim’s identity and privileges.
Since application developers assume that a cross-site request forgery attack is not feasible before the application server has authenticated a user, they commonly miss implementing CSRF defenses at the site’s login form. This allows attackers to disrupt the integrity of a user’s session by mutating the browser state and binding all subsequent requests to the attacker’s authentication credentials. Such an attack is known as the login CSRF attack and has different risks and impacts from the classical CSRF attack.
This article discusses the login CSRF attack, its types, and prevention strategies.
What is a Login CSRF Attack?
A login CSRF attack is orchestrated by forcing a user to log into an attacker-controlled account. To achieve this, hackers forge a state-changing request to the site using their credentials and submit the form to the victim’s browser. The server authenticates the browser request and logs the user into the attacker’s account. When the victim submits sensitive information being logged in to the attacker’s account, the attacker can exploit this information to perform several unwanted actions, including identity theft.
Orchestrating a login CSRF attack typically involves two steps:
Building the malicious link with the exploit script
Tricking the victim user to submit sensitive information by orchestrating a social engineering attack
Depending on the user account and information exposed, the impacts of an attack range from mild to severe. Some consequences of a successful login CSRF attack include:
Unauthorized financial transactions
Deployment of malicious code
Complete account takeover
CSRF Login Attack Examples
There are multiple techniques that attackers can leverage to trick users so they can log into hacker-controlled accounts. CSRF login attacks are almost similar to classical CSRF attacks, except for those being performed at the login page.
A typical vulnerable application in PHP would look similar to:
<?php
if (isset($_POST[“user”], $_POST[“pass”])){
// code for checking the user and password
} else {
echo’
<form method=”post”>
<input name=”user”>
<input name=”pass” type=”password”>
<input type=”submit”>
</form>
‘;
}
?>
If the application server fails to validate login credentials appropriately, the hacker can trick the victim into visiting their malicious page using the code:
<form action=”http://target/login.php” method=”post”>
<input name=”user” value=”darwin-attacker-id”>
<input name=”pass” type=”password” value=”darwin-attacker-pass”>
<input type=”submit”>
</form>
<script>
document.getElementById(“LoginForm”).submit();
</script>
Once the user clicks on the submit button, the browser sends an authentication request to the server with the login credentials. The application checks whether these credentials are correct (since the attacker supplies them) and logs in to the user. The attacker then performs actions associated with other logged-in users, acquiring information to orchestrate advanced attacks.
CSRF login vulnerabilities have also been identified and fixed in several major sites and services. Some recently noted flaws that affected various popular services include:
Search History Console
Search engines provide a service where users can optionally store and later review their search and browser history. As search queries often contain sensitive data on the user’s activities and preferences, attackers may potentially use such data to build a profile of the user and steal their identity. Adversaries can access a victim’s search history by logging them into the service using the attacker’s account. The attacker’s account stores the target user’s search queries, which the attacker can retrieve using his login credentials.
eBay
In August 2013, a login CSRF flaw was reported (and further patched) on eBay’s website, allowing an adversary to modify a victim’s shipping address to one of its choosing. To exploit this security vulnerability, the attacker forced an active user session to send a request to ebay.com/intended-address-page. Since the server is vulnerable, it updated the shipping address to the one specified in the malicious link. This attack was simple to commit since the attacker only needed to fill form fields without guessing the victim’s legitimate credentials.
PayPal
In 2016, PayPal fixed a login CSRF vulnerability on its PayPal.me site that allowed hackers to misuse a legitimate user’s account information. As users have to enroll a credit card or bank account to fund PayPal accounts, attackers exploited login CSRF flaws to mount an attack through the following steps:
The victim uses an eCommerce site and chooses PayPal at checkout
A pop-up comes up, asking the user for their PayPal credentials
The hacker uses a hidden form field to log the user into the hacker’s account
The victim enrolled their credit card, but it got signed into the hacker’s account
Craigslist
A research paper by researchers at the University of Illinois, Chicago, highlighted that Craigslist’s settings page contained several CSRF vulnerabilities that hackers can leverage to direct users into malicious accounts. The vulnerability could allow attackers to take over a user’s account using the “change email address” functionality, which asks them to supply a new email address. The attacker can use their email, issue a password reset request, and recover the account using the reset link via email. Other CSRF login vulnerabilities that were reported to be found on Craigslist include session duration and default site settings.
iGoogle
Inherent design flaws were also reported on the iGoogle site that potentially made the site susceptible to login CSRF attacks. As iGoogle allows users to customize their homepage using gadgets, some gadgets are run inline — within the security context of iGoogle — for usability. Although the service asks users to make a trust decision before adding these gadgets, an attacker can orchestrate a login CSRF attack to replicate the trust decision on the user’s behalf, as follows:
The attacker adds an inline gadget to their homepage using a web browser
The attacker logs into Google using the victim’s basic authentication credentials and opens a frame to the iGoogle service
Google serves the inline gadget to the victim’s browser
The attacker can now control the victim’s browser and can perform various malicious actions such as:
Creating a fake login to an external site at the correct URL
Stealing user credentials using the autocomplete functionality
Read the user’s session cookies when they log in using different browser tabs
Google resolved the above-reported flaw by abandoning embedded plugins and using a robust token strategy for session identification.
Special Note: All the vulnerabilities listed above have since been fixed and are outlined only as representations of real-world attack examples.
Strategies to Prevent Login CSRF Attacks
Some common approaches to prevent login CSRF attacks include:
Inbuilt CSRF Defenses
Most programming frameworks have the synchronizer token pattern built in. It is recommended that developers and security specialists research the framework they are using to relay authentication tokens by default before implementing a custom CSRF token generator. While the framework may generate the session tokens, software teams assume responsibility for appropriate configurations to ensure protection from login CSRF attacks.
Although the synchronizer token pattern enforces server-side token validation, for robust login CSRF protection, a random token should be generated for each state-changing request. When a client issues a request, the web server compares the request token to the one stored for the user session. This technique is considered one of the easiest to prevent attacks since, without a valid token, a login request to the server is rejected.
Double Submit Cookies
When implementing a server-side validation for CSRF tokens is challenging, the double submits cookie technique provides an alternative CSRF defense. This technique sends a random value within request parameters and as a session cookie attribute. During login form submission, the site generates a pseudo-random value set as a cookie on the client browser. These random values are separate from session identifiers and should be included in hidden fields in every subsequent request header. Including this approach in the authentication and encryption cookie enhances the application’s login CSRF protection multi-folds.
User Interaction-based CSRF Defense
This technique involves the user to prevent unwanted actions. Examples of user interaction-based techniques that can be used to deter login CSRF attempts include:
Re-authentication authorization mechanisms
Use of CAPTCHA mechanisms
One-time request token
FAQs
Which prevention measures do not work against login CSRF?
Over time, several flawed techniques have been developed to prevent cross-origin requests. While some remediate inherent flaws, others are ineffective against login CSRF attacks. These include:
Using secret cookies
Accepting only POST requests to execute business logic
Rewriting the URL to hide the user ID
Multi-step transactions
HTTPS-based defenses.
Is login CSRF a phishing attack?
While login CSRF is not a phishing attack, attackers may rely on social engineering techniques to access victims’ session identifiers and trick them into logging into the hacker-controlled account. Since the server treats attackers as logged-in users, similar to phishing attacks, a login CSRF attack technique also allows attackers to construct a legitimate request on behalf of the victim.
This article has already been published on crashtest-security.com/csrf-login-attack and has been authorized by Crashtest Security for a republish.