Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.
According to portswigger : In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer.
SAME-ORIGIN-POLICY :
Before you understand CSRF, Let's start by defining the term "origin". The origin of a page is decided by three unique factors: hostname, protocol and port number. For example, http://hello.com and https://hello.com have different origins as the protocol is different. Similarly http://one.hello.com and http://two.hello.com have different origins as the hostnames are different. The origin property is also different for two services running on the same host with different port numbers e.g. http://hello.com:8081 and http://hello.com:8082 are considered to be different origins.
Same Origin Policy (SOP) is a browser-level security control which dictates how a document or script served by one origin can interact with a resource from some other origin. Basically, It prevents scripts running under one origin to read data from another origin.
There are two parts to the SOP:
- It prevents scripts on origin X from reading data from origin Z.
- It prevents sites on origin X from sending anything but so called "simple" requests to origin Z. Simple requests are limited to GET and POST, and only a few headers can be modified....and therefore nulls out the use of CSRF.
The Same-Origin-Policy does not protect against CSRF. Why?
A CSRF attack is done by sending a request, and not by reading anything from the response. In fact, you neither can nor need to read the response.You would normally use simple requests in a CSRF attack.
How to do CSRF attacks?
For example, suppose an application contains a function that lets the user change the email address on their account. When a user performs this action, they make an HTTP request like the following:
POST /email/change HTTP/1.1
Host: csrf-vulnerable-website.in
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Cookie: session=wvthwsztyeQkAPzdQ6gHgTvlyxHfsBfE
email=just@test-user.com
Now the attacker can construct a web page containing the following HTML:
<html>
<body>
<form action="https://csrf-vulnerable-website.in/email/change" method="POST">
<input type="hidden" name="email" value="pwned@hacker.com" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
If a victim user visits this crafted web page, the following thing will happen:
- The crafted page will trigger an HTTP request to the csrf vulnerable website.
- If the user is logged in to the vulnerable web site, their browser will automatically include their session cookie in the request.
- The csrf vulnerable website will process the request in the normal way, treat it as made by the victim, and change their email address.
How to prevent CSRF Attack?
While Cross-Site Request Forgery (CSRF) continues to be a common attack on applications, organizations can easily prevent it with a CSRF token.
The good news is that a CSRF attack can easily be prevented by using a CSRF token. A CSRF token is a unique, secret, unpredictable value that is generated by the server-side application and transmitted to the client in such a way that it is included in a subsequent HTTP request made by the client. This common application security measure appends an unpredictable challenge in the form of a CSRF token to each request in order to ensure the validity of the source. The server application must verify that each sensitive HTTP request contains the right CSRF token.
How CSRF Token Works?
The client requests an HTML page that contains a form. ... When the client submits the form, it must send both tokens back to the server. The client sends the cookie token as a cookie, and it sends the form token inside the form data.
Example Attack:
- Let's turn this into a cool attack.
- First we craft a new website .
- Now add the payload that can create a fake login prompt telling the users to re-enter their password - so we can steal it.
- Then we build an attack site that will execute the following two things in order.
- First it will make sure the victim is not logged into the site, by using the logout CSRF. Ex.<img src="test.com/logout">
- And then we perform a login CSRF with the account credentials of our self-XSSed account. Ex. <img src="test.com/login?account=victim">
- Now we simply have to redirect the victim back to the site, and the victim will be authenticated with our account executing the payload, asking for the password.
- Now once the victim enter his/her Creds......we steal it.
Beautiful phishing attack. I think it's pretty cool of what you can do with this technique so try it out and let me know what you think about it and i will catch you guys later.✌
0 Comments