AlbusSec:- Penetration-List 08 Cross-Side-Request-Forgery(CSRF) — Sample

Hi Information Security folk, I hope you are well and doing great in your life, Also I hope You liked my previous article about Command-Injection. However, Today we’ll learn about Client-Side-Request-Forgery(CSRF). Where I’ll teach You Basic knowledge about CSRF, Exploitation, Bypass, and Real World scenarios. 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

Cross-Side-Request-Forgery(CSRF):-

CSRF is also called “One-Way” attack, XSRF, Sea-Surf, and Hostile Linking. Client-Side-Request-Forgery(CSRF) is a type of vulnerability that manipulates a user into executing an unwanted application function on behalf of the attacker. The CSRF vulnerability was arisen due to an improper Authentication Mechanism. For Example- If a user is authenticated on a Vulnerable application, then all requests coming from that user must be Authorized. Therefore an Attacker will create a Malicious link or Malicious Web page and that link will be sent to the victim, then whenever the victim processes the Malicious link, then It’ll trick it into performing an unwanted action on the vulnerable application.

• CSRF-Exploitation
• CSRF-Mitigation
• CSRF-Bypass
• Real-World-Scenario

Exploitation:-

An attacker first finds a modern website where he can go through lots of functionality like signup, login up, account delete and email change, etc. Because An Modern application has a big attack surface for CSRF. let’s take an Example- Users could log in to AlbusSecurity and it has the functionality to update their email address.

POST /api/v2/user/1234/update-email/ HTTP/1.1
Host: www.Albus-Security
Cookie: SessionId=ABC123
...

new_email=user@business.com

In the above Request, You’ll see that there is no protection for CSRF, therefore An attacker will create malicious code to exploit CSRF. A Simple Code.

<form method="POST" action="https://www.Albus-Security/api/v2/user/1234/update-email/">
  <input type="hidden" name="new_email" value="attacker@evil.com" />
</form>
<script type="text/javascript">
  document.badform.submit()
</script>

However, We know that Victim is currently logged into www.Albus-Security, Whenever Victim process Malicious link that sent by Attacker. So it’s Malicious, there is the HTML form, so whenever the Victim opens that link the Email was changed, Because In the HTMl form is an auto-submitted function crafted by an attacker on the user’s behalf, and the following HTTP POST request will immediately be sent to www. Albus-Security. And Victim’s email address will be changed from victim@business.com to attacker@evil.com. However Writing a code, consumes lots of hours, therefore You can use CSRF POC Generator that is built into Burp-Suite-Professional for CSRF Exploitation.

Complete-Guide-For-Burpsuite: { Coming-Soon }

Cross-Side-Request-Forgery(CSRF) Mitigation:-

Before We go for CSRF-Bypass You need to know How Modern Web-Application will take prevention for CSRF. However, this prevention must be constantly configured to provide the strongest line of prevention.

CSRF-Token:-

The most Common prevention is to use a Token that is associated with a particular task, and that is sent as a hidden value in every action that was performed in the Web Application. This Token is also called the Anti-CSRF token or Synchronizer token.

Whenever the Developer implements the CSRF token to prevent CSRF attacks, two key-point were arising. First, the CSRF token should be configured to be generated on the Server-Side. Second, The CSRF implementation should be renewed per request, not per session. therefore these combinations will make the best prevention But Whenever an Application generates a token with each click it might lead the user to need to re-enter their Credentials. This is why the application will generate a token per session not per request. But If the application doesn’t strongly manage sessions, then more Vulnerability arises. Basic Example- How Token will generated? Firstly Web-Server Generate a Token per session and store it. The Token is default set as a hidden value, So Whenever Any form is submitted by the User, the token will be included in the POST Request Data. Now Application will compare Stored Token and Received Token. therefore If the token is matched then it will be a Valid Request, if not then the request application will reject that request.

Cookie-Management:-

The Reason that CSRF Vulnerability was arising was that the Cookie Management is allowed for cross-domain passing of cookies, therefore An Application will set a flag for a cookie that makes it into a Same-Site Cookie. A Same-Site Cookie is a cookie that can be sent if the request is being created from the origin related to the Cookie(not Cross-Domain), This type of cookie Management is more Secure, it is still just an additional layer of defense that leaves holes for particular application attacks including XSS.

Adding Additional Header:-

Some Developers implement a Referer Header to verify the origin of the Request to prevent CSRF attacks. Basically, This is to confirm that the request has been created from Origin(Not Cross-Domain). But this approach often creates bypasses, that’s why I’ll not suggest it.

So finally here we come to an end, not an end because It’s not a complete article. Because this article is uploaded as a Sample and not a proper Article. And Very Soon I’ll publish the “Penetration List” 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:-

Penetration-list-Sample