CSRF

Cross Site Request Forgery (aka: XSRF or Sea-Surf)

CSRF happens when an adversary can get a targets browser to make an unexpected request to another site (cross-site). The goal is to have the request made, be linked in some way to the victim who triggered it. Typically through already authenticated sessions that they are holding.

In targeted attacks you will want to do some research on what sites the victim frequents. Otherwise non-targeted "wide net" attacks for popular sites will have the best success.

Things to look for:

• GET editing data

• Insecure web frameworks

GET editing data:

If we see a GET request editing data rather than just reading data then this is a good candidate for a CSRF attack. To abuse these request in CSRF we need to utilize HTML to force the victim browser to make the request. This is typically done with either an <img> tag or a hidden form on our attack.site.

Insecure Web Frameworks:

Many web frameworks only add CSRF protections to POST requests and not GET requests since they expect developers to not modify data with GETs. Added features like CORS can also open up holes in areas that may have previously been secured with ant-csrf tokens. Some of the frameworks that (at the time of writing) have vulnerable GETs are:

• Ruby on Rails

• Django

• Asp.NET

• Ajax

• Node

• Angular

Any of these could also be using Anti-CSRF libraries and coding practices to secure the site. However default settings is without these protections on GET.

GET <img>:

The following is an example of a line of HTML code that we would plant in our website that the user is visiting. This would then try to load an image at the following location which is a GET request to have the user follow us. If they are authenticated on the site then they will have passed their cookies along with the GET request and followed our profile.

<img src="https://somesocial.site/ourprofile?network=follow">

To secure your sites from this attack; don't do any back end data modifications via GET requests. All GET request should be read-only. Also utilizing Anti-CSRF libraries or CSRF Tokens can add further security.

POST hidden form:

Don't give up if it does not work the first time. Remember that the user has to visit and authenticate to the csrf destination site before visiting the malicious trigger.

Some tips for success; Think about the time of day and when your victim frequents the destination site for auth. Can you social-engineer them to visit it first? Send an email from that site! Get them to follow a social account where you post click bait about the site to make them want to visit it! Anything you can do to raise your chances.