Web applications are a common target for attack. By their nature, web apps are typically exposed to the public Internet and protect access to sensitive data or valuable processing capabilities. If an attacker can identify an exploitable vulnerability in the code, taking advantage of it may enable them to steal sensitive data or simply to cause damage to the target organization.
One well-known web application vulnerability is cross-site request forgery (CSRF). This type of vulnerability is a bit different from most web application attacks in that the attacker never interacts directly with the target website. Instead, they trick a user into taking an action that is not in the user’s best interest.
The lack of direct interaction limits what an attacker can do with a CSRF attack. Trying to trick a web application into dumping sensitive information is useless since the data would go to the victim, not the attacker. However, as demonstrated by a bug discovered in phpMyAdmin – a web-based database administration tool – CSRF vulnerabilities can still have a significant impact.
An Overview of CSRF
The goal of a cross-site request forgery attack is for the attacker to force the user to take actions on their account that are not in the user’s best interests. A successful CSRF attack requires an attacker to achieve several prerequisites.
CSRF attacks are performed by forcing a user to browse to a link that causes them to take some action on a particular site. This requires a target website that accepts commands via HTTP queries. For example, a URL such as yourbank.com?action=send&target=12345&amount=1000 may generate a transfer of $1000 to account number 12345. The first step in a CSRF attack is identifying a website of interest to the attacker that accepts commands in this way.
Next, the attacker needs to be able to get an authenticated user to browse to this URL while logged into the site. With the use of cookies and “keep me logged in” options, this can be easier than it sounds. An attacker could take their chances by using a malicious link in a phishing email or take a more sophisticated approach by placing a malicious ad on the bank page itself (more difficult but definitely possible).
When the user clicks the link or loads a page containing code or an image that forces a visit to a certain URL, their browser sends along with any available cookies. As a result, the request looks legitimate and the target page performs the actions that the “user” has requested. Due to the nature of a CSRF attack, their uses are limited. An attacker’s only involvement in the process is the initial malicious link, so requesting a page to print sensitive data (or similar attacks) is useless since that page is sent to the user, not the attacker. However, CSRF vulnerabilities can be exploited in a variety of ways, including initiating bank transfers and changing account passwords.
The phpMyAdmin Vulnerability
phpMyAdmin is a widely used tool for database administration. Recently, a zero-day vulnerability has been disclosed for the tool that would allow an attacker to delete a server from the list of ones managed by the application. The vulnerability in question is a CSRF bug in the setup page on phpMyAdmin. This is the only page vulnerable to the attack since all of the other pages include the use of a token to protect against CSRF attacks.
The use of a token is considered best practice when protecting against CSRF vulnerabilities. The nature of a CSRF attack means that the attacker needs to pre-generate the complete URL to be used in the attack and get the user to browse to that page. This can be easily defeated by having the server generate a secure token that the user must include in later requests. Since the attacker can’t forge a valid token to include in a request, attempted exploitation of the vulnerability can be easily detected and blocked. In the case of the phpMyAdmin vulnerability, other pages on the tool contained token validation, but the setup page was simply overlooked for some reason.
Identifying and Blocking CSRF Attacks
Cross-site request forgery vulnerabilities are a well-known type of web application attack. While it can be a powerful attack, most web application frameworks include protections against CSRF. In fact, this is the reason that it was dropped from the most recent version of the OWASP Top Ten list of the most common web application vulnerabilities.
However, this does not mean that CSRF is not a threat to web application security, as demonstrated by the phpMyAdmin flaw. OWASP dropped it from the Top Ten list because it was “only” discovered in 5% of web applications, demonstrating that it is still a widespread issue. The nature of CSRF vulnerabilities can make them difficult to detect. Since the malicious request originates with a legitimate user and contains their authentication information, it can be difficult to differentiate from a legitimate request.
However, one of the advantages of CSRF being such a well-known vulnerability is that it is well-covered by defensive solutions. A good web application firewall (WAF) will have strong detection and blocking capabilities for CSRF attacks. For more sensitive applications that require additional protection, runtime application self-protection (RASP) can provide additional insight into an application’s execution state and help to identify abnormalities in a request that can point to a CSRF exploitation attempt.
