Session riding can be one of the more challenging attack types to guard against. In this video, you’ll learn how XSRF works and how the bad guys can manipulate a vulnerable application for their own gain.
<< Previous Video: Cross-site Scripting Next: Privilege Escalation >>
The cross-site request forgery attack is sometimes called a one-click attack or session riding. And you may see it abbreviated as XSRF or CSRF we often refer to this as sea surf. What’s interesting about this attack is it takes advantage of the trust that a web browser and a web site have with each other. When you authenticate to a website, you log in everything now between that browser and that website is trusted to be you. In a cross-site request forgery attack, the bad guy takes advantage of that trust to perform functions for themselves.
This is the type of attack that should never happen if the applications on the web site are developed properly. The application should have anti-forgery techniques. Often cryptography and encryption is involved to make sure that other users can’t send a request using your browser.
Here’s how a cross-site request forgery works. There are three devices that are operating. Here we have first our bad guy. Then we have a visitor to the bank site. This is someone who’s logging in to their normal bank account. And then we have the bank web server itself. In the first step the bad guy is going to create a funds transfer request. This is not a request that’s going to come from his account. It’s going to come from someone else’s account, but of course he needs someone else to perform this transfer for him.
So he’s going to send this hyperlink to a third party user. This might be in a message, it might be an email. But he’s going to somehow get that URL to a bank site visitor, who’s already logged in to their bank site account. They’re going to see this link. They’re going to click on that link. Which is then going to send a request to the bank web server to perform the web transfer.
The bank site’s visitor is going to click on this link. Which is going to send a message to the bank web server telling the web server, please perform a transfer from my account, and send that transfer off to the bad guys. That transfer is validated by the bank. It sends that transfer. And just like that, you’ve now transferred money from your account to the bad guy’s account without even realizing you’ve done it.
You can see now why it’s so important that the application developer create their applications to really validate, that all of the requests coming from a bank site visitor originated on that device. You don’t want a third party sending those messages in and having all of these funds transferred without some type of validation.