A CSRF is sneaky by nature. It fools a site into sending a mischievous request which will allow it to inherit the person being targeted’s access rights and identity. Once achieved it effectively has a disguise for its nefarious activities.
This kind of thing is only possible because the majority of browsers automatically request a website’s credentials, things like session cookies, IP addresses, Windows domain credentials, etc. This means that if the site currently thinks the user is authentic, it can’t know which requests are counterfeit and which ones are bona fide.
CSRF attacks focus on the functions that cause a state change on the server, things like an alteration to the victim’s email password or email address or making a purchase.
An attacker doesn’t benefit from making the person being targeted retrieve data because the response is not sent to the attacker, it goes to the person being targeted instead, so it makes sense for CSRF attacks to focus on requests for state changes instead.
There is also an attack called Login CSRF, in which the victim’s personal information is salvaged. The attacker achieves this grab by forcing a user that has not been authenticated to sign in to an account controlled by the attacker. The target may be oblivious to this and while they remain so they might enter personal information such as debit card details into the account.
The attacker can sign in to the account once more to look at this information, and they can also see a history of the targeted individual’s activity on the web app.
On occasion, the CSRF attack can be stored on the susceptible website itself. Weaknesses like these are known as “stored CSRF flaws”. All an attacker needs to do is store an IFRAME or IMG tag in a field that allows HTML, or with a more complicated cross-site scripting attack. If this attack can hold a CSRF attack within the website, the attack will be much more severe. This becomes more likely since the victim is almost bound to look at the page with the attack in it, as opposed to any of the other millions of web pages out there on the web. It’s also more likely because the website has already established the target’s authenticity.
Alternative terminology
In their online documentation and threat modeling process, Microsoft terms this approach a ‘One-Click’ attack, and it can also go by a variety of alternative names that you might want to be aware of including XSRF, “Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking.
Prevention measures that will fail
There are lots of clever ideas out there about how to repel a CSRF attack, but there are also some which are not so clever. Here are the ones that won’t get you a gold star.
Secret cookie usage
Even secret ones are sent along with each request, as are authentication tokens no matter whether the end-user was fooled into submitting the request or not. Additionally, the application container uses session identifiers to identify associations between the request and a particular session object. It does not confirm whether the end-user submitted the request intentionally.
Only accepting POST requests
It is possible to have apps that only accept POST requests to execute business logic, which might lead you to believe that an attacker will not be able to create a mischievous link for a CSRF attack. However, the truth is that there are many ways for an attacker to be fooled into sending a counterfeited POST request. It could be as simple as hosting a form on an attacker’s website that contains concealed values. It could then be set off by automated JavaScript or simply prompted by the person being targeted themselves when they submit the form.
Multi-Step Transactions
Multi-Step transactions are not adequate for preventing a CSRF because the attacker only needs to establish the steps of the transaction.
URL Rewriting
You might consider this a worthwhile approach to preventing a CSRF because the attacker won’t be able to infer the session ID of the person being targeted, but unfortunately, the URL reveals it. There isn’t much point in patching one security vulnerability by creating a new one.
HTTPS
HTTPS alone cannot repel a CSRF attack, but it’s important to realise that it’s going to be a necessary basis for any preventative measures that are worth their salt.
with