AlbusSec:- Penetration-List 08 Cross-Side-Request-Forgery(CSRF) — Sample-2
Hi Information Security folk, I hope you are well and doing great in your life, Before we go to the next step, You’ll need to learn about CSRF Vulnerability, therefore check our previous article on csrf, However, Today we’ll learn about CSRF-Bypass-Technique’s. Where I’ll teach You Some-Basic bypass techniques to advanced techniques to bypass CSRF Basic. However. Firstly, I will introduce myself. So, I’m Aniket Tyagi and I’m an Information Technology officer at the 5f eco foundation of India, an Information Security Researcher, and the founder of Albus Security. Without wasting our energy, Let’s get started
Client-Side-Request-Forgery Bypass:-
Before we go to the next step, You’ll need to learn first about CSRF Vulnerability, However today we’ll learn CSRF bypass, Basically, Most of the applications seem that they will implement some things against CSRF. But whenever you’ll intercept that request and going analyzing that request, then it might be possible that the application will not implement any proper restrictions against CSRF Vulnerability.
- Improper Token Implementation
- Manipulating Request Method
- Remove Referrer/Origin header
- Successfully bypass CSRF through Clickjacking Vulnerability
Improper-Token-Implement:-
Applications were using CSRF tokens to prevent CSRF Attack, but Sometimes applications were not validating csrf tokens properly, therefore an attacker will try to bypass csrf protection via csrf tokens. There are two possible ways to bypass csrf via token, First is to remove a token value, token parameter, or add ‘null’. let’s break this into small parts. An application will not properly secure against csrf. because Most of the case applications will only validate the request on token param, not value, therefore if the token parameter is available on a request, not value then it causes bypass.
POST /update_email HTTP/1.1
HOst: albussecurity.com
....new_email=attacke@gmail.com&token=
Sometimes An application will not validate anything, Meaning the application will not check the token param or a value, and if there is a request that doesn’t have anything then the application will accept that request and process that request.
POST /update_email HTTP/1.1
HOst: albussecurity.com
....new_email=attacke@gmail.com
Also if we add a null value and no token param, then also it might be possible that the application will process a request.
POST /update_email HTTP/1.1
HOst: albussecurity.com
....new_email=attacke@gmail.com&token=null
Now Second is an improper token implementation in which Some applications will validate the token value and token param but they will not validate that the token belongs to the same session as the user who made the request. therefore An application accepts any token that appears in its bucket of tokens. An attacker can inject valid tokens on malicious requests. Mean An attacker will inject their own token on csrf exploit or request
<form method="POST" action="https://www.Albus-Security/api/v2/user/1234/update-email/">
<input type="hidden" name="new_email" value="attacker@evil.com" />
<input type="hidden" name="token" value="Attacker_Token" />
</form>
<script type="text/javascript">
document.badform.submit()
</script>Manipulating Request Method:
Another Bypass technique is to change requests from POST to GET or GET to POST. And the reason, why it’s possible to bypass the csrf is to only change the request method, is that the application only depends on Post requests with a CSRF token. therefore if you can send that request on the getting method then it might be possible that a GET request is being validated by the application
GET /update_email?new_email=attacker@gmail.com HTTP/1.1
HOst: albussecurity.com
....Remove Referrer/Origin header:
An application validates the request if that request has a referer/Origin header. However, You need to bypass this header check to simply not send these headers.
<meta name="referrer" content="never">
<form method="POST" action="https://www.Albus-Security/api/v2/user/1234/update-email/">
<input type="hidden" name="new_email" value="attacker@evil.com" />
<input type="hidden" name="token" value="Attacker_Token" />
</form>
<script type="text/javascript">
document.badform.submit()
</script>Successfully bypass CSRF through Clickjacking Vulnerability:-
Clickjacking is similar to csrf because, in both vulnerabilities, an attacker controls the victim’s browser to generate a request and the user is not aware of this. A Clickjacking attacker will trick a user with the help of social engineering to submit a request, and trap the user to do attacker choice work through a bait-and-switch technique that makes the user think they performed a completely unrelated action. Basically, In Clickjacking victim is interact with UI elements on a targeted website that was implemented by the attacker. Most of the time CSRF bypass with clickjacking works on JSP applications and partially on ASP.NET applications. Now let’s take a simple example that application will have email update functionality. therefore if an attacker will try to exploit CSRF, but the application implemented a proper token mechanism, However, the application was vulnerable to clickjacking So an attacker will try to exploit csrf with the help of Clickjacking.
So finally it’s done for Sample, not properly done because I will mention more bypass tricks, also Real-World-Scenario on the book, You already know the reason that the upcoming article will be uploaded as a Sample and not a proper lecture. therefore Very Soon I’ll publish the “Penetration List” Book. In which You’ll get depth knowledge about Vulnerabilities. Because I’ll upload topics as a sample on medium, not a proper section. Thank You For Reading.
You can download a sample of the book:-
