AAWhat is CSRF
Cross site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.
A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft — including stolen session cookies.
CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.
How CSRF Attack Works?
When a user tries to access a site, the browser often automatically includes the credentials in the request, to make the login process more convenient. These credentials may include the user’s session cookie, basic authentication credentials, IP address, and Windows domain credentials.
The risk inherent in this mechanism is that attackers can easily impersonate the user. Once a user passes the site’s identity verification, the site cannot differentiate between a forged request and a legitimate user request.
In a CSRF attack, an attacker assumes the victim’s identity, and uses it to perform actions on behalf of the user, without their consent. Attackers typically follow this process:
- They use social engineering techniques to persuade the victim to click a link via email, chat message, or similar form of communication.
- Either the malicious link itself, or a web page the user visits, triggers a request to the targeted site
- The request supposedly comes from the user, and takes advantage of the fact that the user is already signed into the website.
- The website acknowledges the request and performs the attacker’s requested action, without the user’s knowledge or consent.
CSRF attacks typically attempt to change server state, but can also be used to gain access to sensitive data. If an attacker successfully performs a CSRF attack against the victim’s account, they can transfer funds, purchase a product, modify account information such as the shipping address, modify the password, or any other action available when the user is signed in.
An example of CSRF Attack:
A CSRF attack works as follows. While accessing the bank account, the user simultaneously browses some other websites. One of the sites ‘www.somesite.com’, contains a hidden form and a piece of JavaScript. As soon as the user visits the webpage, the browser silently submits the hidden form to ‘fictitiousbank.com’. The format and content of the request are exactly the same as the request triggered by the user clicking the submit button in the “pay bill” form provided by the bank. On sending the request, the user’s browser automatically attaches the authentication cookies to the request. Since the session is still active in the server, the request will be processed by the server as issued by the user.
let’s discuss an example of how this vulnerability can be exploited. Imagine your application has a /user/email route that accepts a POST request to change the authenticated user’s email address. Most likely, this route expects an email input field to contain the email address the user would like to begin using.
Without CSRF protection, a malicious website could create an HTML form that points to your application’s /user/email route and submits the malicious user’s own email address:
<form action=”https://your-application.com/user/email” method=”POST”>
<input type=”email” value=”malicious-email@example.com”>
</form>
<script>
document.forms[0].submit();
</script>
If the malicious website automatically submits the form when the page is loaded, the malicious user only needs to lure an unsuspecting user of your application to visit their website and their email address will be changed in your application.
To prevent this vulnerability, we need to inspect every incoming POST, PUT, PATCH, or DELETE request for a secret session value that the malicious application is unable to access.
HOW DO I PREVENT CSRF?
- Preventing CSRF requires the inclusion of an unpredictable token in the body or URL of each HTTP request. Such tokens should at a minimum be unique per user session, but can also be unique per request.
- The preferred option is to include the unique token in a hidden field. The unique token can also be included in the URL itself, or a URL parameter.
- Check Referrer field of each request.
- Use Captcha on all critical page.
Example:
Laravel automatically generates a CSRF “token” for each active user session managed by the application. This token is used to verify that the authenticated user is the person actually making the requests to the application. Since this token is stored in the user’s session and changes each time the session is regenerated, a malicious application is unable to access it.
The current session’s CSRF token can be accessed via the request’s session or via the csrf_token helper function:
use Illuminate\Http\Request;
Route::get(‘/token’, function (Request $request) {
$token = $request->session()->token();
$token = csrf_token();
// …
});
Anytime you define a “POST”, “PUT”, “PATCH”, or “DELETE” HTML form in your application, you should include a hidden CSRF _token field in the form so that the CSRF protection middleware can validate the request. For convenience, you may use the @csrf Blade directive to generate the hidden token input field:
<form method=”POST” action=”/profile”>
@csrf
<! — Equivalent to… →
<input type=”hidden” name=”_token” value=”{{ csrf_token() }}” />
</form>
Excluding URIs From CSRF Protection:
Sometimes you may wish to exclude a set of URIs from CSRF protection. For example, if you are using Stripe to process payments and are utilizing their web hook system, you will need to exclude your Stripe web hook handler route from CSRF protection since Stripe will not know what CSRF token to send to your routes.
Typically, you should place these kinds of routes outside of the web middleware group that the App\Providers\RouteServiceProvider applies to all routes in the routes/web.php file. However, you may also exclude the routes by adding their URIs to the $except property of the VerifyCsrfToken middleware:
<?php
namespace App\Http\Middleware;
use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;
class VerifyCsrfToken extends Middleware
{
/**
* The URIs that should be excluded from CSRF verification.
*
* @var array
*/
protected $except = [
‘stripe/*’,
‘http://example.com/foo/bar’,
‘http://example.com/foo/*’,
];
}
In addition to checking for the CSRF token as a POST parameter, the App\Http\Middleware\VerifyCsrfToken middleware will also check for the X-CSRF-TOKEN request header. You could, for example, store the token in an HTML meta tag:
<meta name=”csrf-token” content=”{{ csrf_token() }}”>
Then, you can instruct a library like jQuery to automatically add the token to all request headers. This provides simple, convenient CSRF protection for your AJAX based applications using legacy JavaScript technology:
$.ajaxSetup({
headers: {
‘X-CSRF-TOKEN’: $(‘meta[name=”csrf-token”]’).attr(‘content’)
}
});
What is the Impact of CSRF Attacks?
When a website sends a data request to another website on behalf of a user along with the user’s session cookie, an attacker can launch a Cross-Site Request Forgery Attack, which abuses a trustful relationship between the victim’s browser and the webserver.
In some cases, depending on the type of action, the attacker can gain full control of the user’s account. If the compromised user has a privileged role within the application, the attacker might be able to take full control of all the application’s functionality and data, which is devastating to both the business and the user. The result can be data theft, unauthorized fund transfers, damaged client relationships, changed passwords and many more.
biblografi : https://medium.com/@rajeevranjancom/cross-site-request-forgery-csrf-attack-6949edb9e405