When a user is logged into a website, the browser sends some form of authentication data as session information with each request to that website, such as a session cookie, client certificate, or other stored credential. A CSRF flaw means that site does not distinguish between intentional actions taken by the user and forged requests generated by a malicious link or script request.
Rates of Credentials Management Flaws in Software
CSRF is one type of credentials management flaw. Some type of credentials management vulnerability exists in 42% of applications, according to Veracode static scan data.
While CSRF may be less common than, for example, the use of hard-coded passwords to operate certain types of devices, it is a form of insufficiently protected credentials. CSRF vulnerabilities may be especially concerning given how much people rely on web applications to manage important aspects of their daily lives and how much personal and business information is tied directly to web applications. CSRF attacks can also be used to exploit flaws in internet-connected devices from home routers to Internet of Things (IoT) devices—the same systems often vulnerable to other types of credentials management problems, such as hard-coded or default passwords.
This flaw is especially concerning to businesses and others with some type of administrator-level access to web applications. For example, people with access to the back end of a company's website may inadvertently send requests from an attacker. CSRF vulnerabilities can allow an attacker to gain administrator-level access or take over the site when a plug-in or module code that contains these flaws is active on the site.
How Cross-Site Request Forgery Attacks Work
CSRF attacks exploit flaws in the ways web applications handle authentication and credential checks. CSRF attacks require that the user is authenticated against the targeted site with some form of persistent cookie or credentials. This means that every request sent by their web browser to the targeted site will include those cookies or credentials. This is an important part of the functionality of most sites that require a user to log in. After all, people would quickly leave a social media or membership site that forced them to log in again every time they visit another page or open a new browser tab.
When CSRF requests are sent by someone who is not logged in, nothing happens; the request is simply discarded by the target site. When CSRF flaws are found in a site or application, these same requests from a logged-in user's browser can execute an array of state change requests.
Protecting a web application against CSRF flaws allows the application or target site to differentiate such unwanted requests from legitimate requests, and this protection can be achieved without detriment to the user experience.
In many cases, CSRF attacks originate from unwanted emails or questionable websites, so teaching users not to click phishing links can play some role in protection. However, the most powerful form of protection against this type of attack is to ensure that the request comes from a form that the user previously requested in the session to verify the information before submitting it.
Executing a CSRF Attack
In a Cross-Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited, the victim must be authenticated against (logged into) the target site. For instance, let’s sayexamplebank.comhas online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack onexamplebank.combut am not currently logged in, nothing happens. If I am logged in, however, the requests in the attack will be executed as if they were actions that I had intended to take.
Let’s look at how the attack described above would work in a bit more detail. First, let’s assume that I’m logged into my account onexamplebank.com,which allows for standard online banking features, including transferring funds to another account.
Now let’s say I happen to visitsomemalicioussite.com. It just so happens that this site is trying to attack people who bank withexamplebank.comand has set up a CSRF attack on its site. The attack will transfer $1,500.00 to account number 123456789. Somewhere onsomemalicioussite.com,attackers have added this line of code:
<iframe src="http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=123456789" >Upon loading that iframe, my browser will send that request toexamplebank.com,which my browser has already logged in as me. The request will be processed and send $1,500.00 to account 123456789.
Another Cross Site Request Forgery Example
I just bought a new home wireless router. Like most wifi routers, it’s configured through a web interface. The router was shipped to me with an internal IP address of 192.168.1.1. I’m having trouble configuring the router though, and fortunately the folks over atsomemalicioussite.comhave published a guide that shows me exactly what buttons to click in the router interface to get everything set up securely. The attackers have also set up a proxy server at 123.45.67.89 that will log all traffic that goes through it and look for things like passwords and session tokens.
As I clicked through the configuration guide, I missed the 1x1 pixel image that failed to load:
<img src="http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89" alt="pwned" height="1" width="1"/>
The attackers knew that when I was reading their tutorial, I would be logged into the router interface. So they had the CSRF attack set up in the tutorial. With that request, my router would be reconfigured so that my traffic will be routed to their proxy server where they can do all manner of bad things with it.
Preventing Cross-Site Request Forgery Vulnerabilities
Organizations can easily prevent most CSRF attacks by the use of a CSRF token. These unique tokens can be appended to each sensitive request. By adding a challenge token to every state change request, from transferring funds to creating administrator accounts on a website back end, and properly checking that token when processing requests, developers can ensure that these requests are legitimately submitted by authenticated users.
Each time the server renders a page that includes sensitive actions, a unique CSRF token is passed to the user. For this system to work properly, the server must then only take the requested sensitive action when the token is fully validated, rejecting all requests with either invalid or missing tokens. One common error when implementing CSRF flaw checks is to reject requests that have invalid tokens but allow requests with missing tokens to proceed, rendering the token process ineffective.
Finding and Remediating Cross-Site Request Forgery Vulnerabilities
To check for CSRF vulnerabilities, look for forms that allow users to make requests and check to see if an anti-CSRF token is generated properly. Most modern web frameworks can be configured globally to include anti-CSRF tokens on all form pages and to handle the verification transparently. Any time a user can submit a state-change request, such as transferring funds, making a purchase, adding an administrative user, or changing a password, this request must be protected by a CSRF token. If a form is not intended to allow users to make this type of change, its scope should be constrained to prevent misuse by attackers.
CSRF tokens can also be combined with other types of protective coding, including ensuring that session cookies are set with the SameSite cookie attribute. This attribute allows developers to instruct browsers to manage whether cookies are sent along with requests from third-party domains. Online banking sites, for example, may want to use the strictest level of cookie protection. You can also add the HttpOnly attribute to protect against some forms of cross-site scripting flaws; doing so also makes CSRF attacks more difficult to execute, as cross-site scripting vulnerabilities enable some types of CSRF attacks.
