1 Approach, 2 Technics
Laravel Uses 2 distinct Technics to prevent CSRF Attack.
The Approaches are The same:
to send a token (CSRF or XSRF) to The Client and Client Have to return
it back in following request
and there are 2 steps:
- server sends token (get a form) (CSRF or XSRF)
- client return token as X-token (post a form) (X-CSRF or X-XSRF)
when you see an X- token its an client-replied that client sends with Post to the server
The Reason we have 2 technics is not these uses different approaches,
its because web application Client-Side Architectures using 2 different Architectures :
- old-fashion : server generates pure html and send it to client
- Single Page Application : client SPA Framework (like Vue,React,Angular) send and receive data as Json or Xml and create proper Html in Dom
Now CSRF-Protection Technics Adapts with this Two Client-Side Architectures as Below:
+-------------+-----------------+-----------+------------+
| Client Arch | Protection Tech | Get Token | Post Token |
+-------------+-----------------+-----------+------------+
| old-fashion | sync-token | CSRF | X-CSRF |
| SPA | cookie-header | XSRF | X-XSRF |
+-------------+-----------------+-----------+------------+
Mechanism Description
1.Server Generates Token
Laravel make a CSRF Token (40 chars) and store it in session
/**
* Regenerate the CSRF token value.
*
* @return void
*/
public function regenerateToken()
{
$this->put('_token', Str::random(40));
}
After Generating and Storing token in Session, Token Will be Send To Client as CSRF and XSRF
client side will decide to use whatever it wants.
2.Server Sends Token To Client
for the old-fashioned (sync-token technic) client can receive The CSRF Token in two forms with call to csrf_token() helper method in blade:
- in form body :
<input type='hidden' name='_token' value='{{csrf_token()}}' />
- in meta tag that Ajax request can use it in its header
here is how this helper method returns corresponding value:
/**
* Get the CSRF token value.
*
* @return string
*
* @throws RuntimeException
*/
function csrf_token()
{
$session = app('session');
if (isset($session)) {
return $session->token();
}
throw new RuntimeException('Application session store not set.');
}
for cookie-header (SPA Frameworks) client framework (like Angular) can receive XSRF Token in the Cookie Because:
there is no Html Form generating in the server which server can seed
its hidden input in it. and The Way it can send its token to the
client is sending it with cookie. (This method named XSRF)
/**
* Add the CSRF token to the response cookies.
*
* @param IlluminateHttpRequest $request
* @param SymfonyComponentHttpFoundationResponse $response
* @return SymfonyComponentHttpFoundationResponse
*/
protected function addCookieToResponse($request, $response)
{
$config = config('session');
$response->headers->setCookie(
new Cookie(
'XSRF-TOKEN', $request->session()->token(), $this->availableAt(60 * $config['lifetime']),
$config['path'], $config['domain'], $config['secure'], false, false, $config['same_site'] ?? null
)
);
return $response;
}
Laravel put token in both places since its up to client which method to use, and expect client to response to one of this methods.
3.Client Sends X- Token To Server
In client-side:
- old-fashion (X-CSRF):
- post token in post data or:
- make ajax call like this:
`$.ajaxSetup({
headers: {
'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
}
});`
SPA Framework : These Framework put Token as X-XSRF-TOKEN in Post Headers
Server Checks X- Token Vs in-session Token
Now Its Time To Laravel Check For The Token
in VerifyCSRFMiddleware, Laravel Checks if The Request Should Be Check For CSRF Protection Token it Checks :
/**
* Handle an incoming request.
*
* @param IlluminateHttpRequest $request
* @param Closure $next
* @return mixed
*
* @throws IlluminateSessionTokenMismatchException
*/
public function handle($request, Closure $next)
{
if (
$this->isReading($request) ||
$this->runningUnitTests() ||
$this->inExceptArray($request) ||
$this->tokensMatch($request) //compares request_token vs session_token
) {
return tap($next($request), function ($response) use ($request) {
if ($this->shouldAddXsrfTokenCookie()) {
$this->addCookieToResponse($request, $response); //add cookie to response
}
});
}
throw new TokenMismatchException('CSRF token mismatch.');
}
Two of lines are in interest:
$this->tokensMatch($request)
and
$this->addCookieToResponse($request, $response);
so there are multiple data in each request that server can put:
- html form input _token (40 chars) (CSRF)
- html meta header csrf-token (40 chars) (CSRF)
- cookie XSRF-TOKEN (224 chars) (XSRF)
and multiple data can client send to server as response to the tokens
- post parameter _token (40 chars) (X-CSRF)
- http header X-CSRF-TOKEN (40 chars) (X-CSRF)
- http header X-XSRF-TOKEN (224 chars) (X-XSRF)
Why in CSRF token are 40 chars and in XSRF are 224 chars ?
We Will get to this a little bit latter
The Http Request Has To Match Token with one of the Above X-Token
/**
* Determine if the session and input CSRF tokens match.
*
* @param IlluminateHttpRequest $request
* @return bool
*/
protected function tokensMatch($request)
{
$token = $this->getTokenFromRequest($request);// it get token from request
return is_string($request->session()->token()) &&
is_string($token) &&
hash_equals($request->session()->token(), $token); //checks if it is equal to session token or not
}
/**
* Get the CSRF token from the request.
*
* @param IlluminateHttpRequest $request
* @return string
*/
protected function getTokenFromRequest($request)
{
$token = $request->input('_token') ?: $request->header('X-CSRF-TOKEN');//check sync-token
if (! $token && $header = $request->header('X-XSRF-TOKEN')) {
$token = CookieValuePrefix::remove($this->encrypter->decrypt($header, static::serialized()));
}
return $token;
}
first pattern to examine is sync-token, token from client can be in an <input name='_token' /> or it can be in Http Header if requested from an Ajax method call in the client.
the line
$token = $request->input('_token') ?: $request->header('X-CSRF-TOKEN');
will check for that and if it can be retrieved, it will return and check via the session_token
but if (! $token is NULL it will check against the cookie-header pattern:
getting $header = $request->header('X-XSRF-TOKEN') from header and decrypt it, if its need decryption
$token = CookieValuePrefix::remove($this->encrypter->decrypt($header, static::serialized()));
if it has been encrypted before it has been added to cookie
Cookie Encryption
This is The Reason That XSRF Token Could be 224chars :
Cookie Encryption
and you may disable cookie Encryption and make the XSRF Token 40 chars, Like The CSRF Token
so The Difference was for The Cookie Encryption.
Necessity of Cookie Encryption
But Why Cookie Needs to get Encrypted?? Why XSRF Cookie needs to get Encrypted??
In General, Laravel Store some data on cookies and cookie can be modified by client. because server dose not want modifications on client, it Encrypt Cookies .
this can be config to not to Encrypt CSRF Cookie Since it is not subjected to change by user and its only subjected to be stole by cookie hijacking which encryption is not going to preventing this event.
The only Difference its make is to having to token (unencrypted and encrypted)
for two CSRF Protection methods.
So if attackers can access a cookie-stored (X-XSRF) Token (Since Hijacking > Cookie is much easier to hijacking runtime html and css with XSS )
it cannot be Abuse With sync-token mechanism.
Since CSRF Attack with http-form parameter is easier since html can be in email
or etc While Runnig Js is Less common.
Conclusion
So if a client use old-fashion client architect . the cookie-header technic > ( XSRF stored in Cookie ) wont leave him with a data leak in cookie.
further information on this prevention patterns can be found here:
https://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention
