Software Integrity

 

What is cross-site request forgery (CSRF)?

Cross-site request forgery (CSRF) is an attack in which a malicious web site, email, blog, instant message, or other program makes the victim’s web browser perform a function without the victim’s initial knowledge, on a trusted site where the user is currently authenticated.

Cross-site request forgery or CSRF attacks are also sometimes known as “confused deputy” or “one-click” attacks. Basically, these attacks take advantage of the target site’s trust of requests from its authenticated users. They specifically target state-changing requests, not theft of data.

For a CSRF to be successful, the user must be authenticated on the target site. The attack function must also be a function of the target site—for example, a fund transfer on a bank site, or a purchase on an e-commerce site.

Why is cross-site request forgery dangerous?

If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim has an administrative account, CSRF can compromise the entire web application.

What it looks like.

Jayne plans to use her bank’s website to transfer $500 to her son Mal’s checking account at college. What she doesn’t realize is that her bank’s website is not secure. Leland does, and is ready to exploit that vulnerability and make Jayne unknowingly transfer money to HIS account.

To do this, Leland builds an exploit URL that takes Jayne’s original transfer request…

GET http://citybank.com/transfer.do?acct=MAL&amount=100

…and alters it to transfer the money to Leland’s account… and to increase the amount of the transfer.

http://citybank.com/transfer.do?acct=BOB&amount=100000

Leland then plants the exploit URL in an email to Jayne. When Jayne clicks the link, the money is then transferred to Leland’s account, without Jayne’s knowledge.

How to fix it.

There are some basic defense strategies for preventing cross-site request forgery.

Dynamic security token

The most common solution is to generate and store a dynamic security token on the server and include it on every page that generates a request. The token submitted by the page is compared to the token stored on the server.  If the tokens match, the request is executed. If not, the request is rejected and an error message is displayed. This token provides the piece of information that an attacker cannot guess, since it changes with every request or every session. Tokens are most often stored in a hidden form field. That option works if the token is generated per session, per page, or per form. It is then automatically passed to the server with each request.

CAPTCHA.

A challenge-response test that requires the user to “prove they are human,” usually by identifying a series of letters or numbers that have been visually altered to make them unreadable to a computer.

Re-authentication.

Having your user re-enter their user name and password again.

Share secret.

Requiring your user to enter a PIN number.

Learn about industry-leading tools for every stage of your SDLC.