Ads Area

CSRF via GET Requests | Best way to find CSRF Vulnerability | Bug Bounty Approach

Hey Guys, what's up, back again with another blog. I know this time, it took me some time to bring the fresh content for you, but this happened because I am involved in some urgent work. But no way out, again I am here with another special part of the Bug Bounty Series. But, before we get into it, let me warn you that the knowledge you get must never be used to inflict harm to an individual or an organization, and if that happens, we (thedecentshub) will not be held liable.

Lab Environment Configuration

So let's start this Blog, without wasting any further time.


CSRF FOR BUG BOUNTIES


Today we are going to learn a new strategy, based upon a bug bounty approach, which follows up to find the CSRF vulnerability in your respective target. Simply telling you up that we would be dealing up with the GET requests for this particular blog and for other requests like POST, I will come up later.

First of all, let me give you all a small intro to what is CSRF Vulnerability and how does it work?


CSRF a.k.a Cross-Site-Request-Forgery is a sort of act that is performed in such a way unknowingly to the victim(user), which tricks him to perform certain actions out of his real intent. Suppose tricking the user somehow to change his password, performing a successful attack on the change_password request. For example, wait for a while and we will be moving soon ahead with it.


Well, I am just here to make you aware of it and I do not intend to harm anyone. To carry out a successful CSRF attack, the attacker uses social engineering techniques and exploits certain vulnerabilities in order to get the victim to unknowingly submit a form carrying out some pre-determined work on behalf of the attacker - such as deleting an email account.

CSRF also aims to send commands and changes to the victim unknowingly, by abusing the user's browsing history. An attacker can collect information from the user's browser history and spoof the requests with the same-origin policy flag, tricking the website into performing actions such as password resets. It can be prevented with techniques such as tokens and signatures, although these also could be tricked and carried away.


Now let's talk about how to find them out successfully while dealing with GET requests.
Mainly today, GET requests are not mostly preferred for performing data-driven actions like deletion, updating, addition, and all. But some organizations and their respective web applications do. In this case, let's consider for example a bank application * that performs some sort of bank transfer using the GET request *. Being a GET request and if I consider you to be well aware of them, reading up my blog, you might be knowing that in it each and everything passes up in the URL in the form of query-string.

Since everything moves up in the URL, it could be at a high prone to be attacked and if a vulnerability such as Cross-Site-Scripting is exploited respective to that application, the game get's over, because XSS can cause the cookies as well as the URL Parameters to be sent to a third-party(malicious) web application hosted by the attacker. 

Now for exploiting this CSRF attack on the given GET request, we need to write a small HTML code which would be something like:-

<html>
<body>
<img src="https://www.bank.com/transfer?from=bob&to=joe&amount=500">
</body>
</html> 


Here the src passed in the image is the actual URL passed at the time of processing the given HTTP request. You could clearly see the "from" parameter which denotes the sender account, the "to" parameter which denotes the receiver bank account, and the "amount" parameter which denotes the monetary stuff. 

What the attacker intends to do here is, he will somehow trick the end-user to render the given HTML making sure, the user is logged in to the respective bank application for which the cookies must be stored in the browser(not expired). As soon as the user tries to render the given HTML page, the IMG attribute would be ready to load calling the URL provided in the "src" - to fetch the required content. But here, in this case, the "src" attribute contains the URL to process the transaction from the user's to the attacker's account. Hence, resulting in it being called automatically and the best part goes like that it requires almost no interaction from the user's end causing a high impact.


Hence this is one of the easiest and one of the highly impactful ways to carry out and finding successfully a CSRF vulnerability. So this much for this blog :) would be happy to see your engagement over this post and your thinking as well. Do tell me in the comment section what do you feel like about this approach and what more vulns and stuff you would like me to talk about.


My other posts -

https://www.thedecentshub.tech/2021/09/performing-osint-on-twitter-accounts.html

https://www.thedecentshub.tech/2021/09/bug-bounty-series-subdomain-enumeration.html

https://www.thedecentshub.tech/2021/09/creating-deepfakes-first-order-motion-model-for-image-animation.html

https://www.thedecentshub.tech/2021/08/why-hacking-is-always-seen-from.html

https://www.thedecentshub.tech/2021/08/osintgram-perform-osint-on-instagram.html

https://www.thedecentshub.tech/2021/08/retrieve-user-information-using.html

https://www.thedecentshub.tech/2021/08/reverse-shell-using-excel.html

https://www.thedecentshub.tech/2021/08/reverse-shell-from-word-documents.html

So Guys, this much for this blog, if you like the content you can follow me up, can also subscribe to my YouTube channel. If you Guys want that I keep bringing this sort of Blogs and videos for you, you can show your support to me ...

    Buy me a coffee and show your Support 😊

Till Next Blog Guys, *TaTa*, Goodbye. I hope you enjoyed the Blog 😊 




Tags
The Decent's Blog

The Decent's Blog

Hi there, I'm Apoorv Gupta - aka Agisthemantobeat �� I'm a Senior Software Engineer, WhiteHat Hacker, Developer, and Youtuber!! | ⚡ Fun fact: I love to learn everything and solve problems of people. A small zest of Certifications - NSE1, NSE2 (Network Security Associate), CSFPC, Microsoft AI-900, DP-900 and rest on my LinkedIn profile.

Post a Comment

0 Comments
* Please Don't Spam Here. All the Comments are Reviewed by Admin.