For this blog post I will be discussing CSRF attacks what this type of attack is, how attackers execute this attack, and real-world examples of people exploiting this vulnerability, and how to successfully prevent an attacker from exploiting this vulnerability on your application. To start a simple definition of what a CSRF attack, it is an attack that causes an unsuspecting user to execute an action that the user did not want to do. A cross site request forgery attack is not exactly stealing information rather manipulating a user to perform an action that would benefit the attacker like depositing funds into the attacker’s bank account.
A more technical look at how a cross site request forgery attack is executed is more social engineering than writing code. So, an attacker would send the victim a malicious link usually through email. In the malicious link an attacker would embed a request so if someone would click the link the request embedded in the link would be carried out. This will then carry out the forged request making it appear as though that the victim intentionally carried out the request put in the link. Which makes it difficult to prove that you were subjected to a CSRF attack because it is very difficult to distinguish a forged request from a real request. An example of how a cross site request forgery attack is carried out, would be to begin with the attacker must understand what a legitimate GET request of what they are trying to get the victim to do. Once an attacker knows a legitimate GET request, they can then forge a fake one and send it in the form of link to the victim. An example of the request being GET http:/BoA.com/transfer.do?acct=hacker&amount=$100 HTTP/1.1 this will be then used to transfer a $100 to the hacker’s account without the knowledge of the victim. A way to make this look like a normal hyperlink would <a href =”http:/BoA.com/transfer.do?acct=hacker&amount=$100” > Click to learn how to make millions</a>. This will be sent in an email about how to become rich and a person who is not knowledgeable of CSRF attacks could click on the link because they will only be seeing the “Click to learn how to make millions” hyperlink. Once the victim clicks the link, they will then unknowingly send money to the attacker’s account.
I looked up real world cross site request forgery attacks and found that Facebook has recently suffered from CSRF attack. There was an issue with the site that was allowing other websites to gather information like a person’s interests and likes on their profile. This vulnerability was found by someone who works for a cybersecurity company and discovered that the search results on Facebook were not protected against a cross site request forgery attack. This specific attack was executed if a user would visit a particular website and have a logged in Facebook tab open, then the attacker could gather information on the user. The particular site that the unsuspecting Facebook user is on could then use the Facebook search in the logged in profile and obtain “yes” or “no” responses. Meaning that the site could determine the user’s likes and interests by using this method of using the search for yes or no responses. The information that the attack obtained was not really damaging like stealing someone’s credit card, but more stealing someone’s information of their interests more than likely committed by a company that targets people with specific advertisements.
I investigated popular websites that used to be vulnerable to CSRF attacks from a decade ago. I found that YouTube used to be completely vulnerable when it came to defending itself to a CSRF attack where people could add you as a friend. A person executing this attack on the site could also add to the comment section as though that they were the person that they were targeting. An attacker could also have the unsuspecting user subscribe to a channel. Another popular website that used to be vulnerable to this attack was MetaFilter this is a weblog. On MetaFilter an attacker could use a CSRF attack to set a victim’s email address with the attacker’s email address. Afterwards the attacker could send another request that would utilize the forgot password option and it would then go to the attacker’s email address. This would in turn give a user’s whole profile over to the attacker which could be damaging.