Welcome guys, I found an awesome resource provided FREE by the guys over at Hackerone. It’s a hacking course equipped with individual lessons, sessions and a lab environment to try apply what you learned. Highly recommended you can reach it all via Hacker101. For the blogs purpose I’ll be completing the challenges. Let’s jump right into it.
Level 0
Classic bank interface the first thing that comes to my mind is a CSRF attack. Maybe since a bank example is usually the defacto example to use when explaining this vulnerability. I submitted the above form with value 1738 in the destination account and 100 in the amount field.
Raw request with rendered html response:
The raw response is as follows:
Cross Site Request Forgery:
This is a state-changing action (POST request for bank transfer) without any CSRF token to validate the transaction. If we can get the user to load our page through phishing and the victim is authenticated to the bank the following HTML script would exploit the CSRF vulnerability
Transferring $100 to the attacker’s account (666) in the screenshot.
Insecure Direct Object Reference:
I noticed while playing around with the request that it’s possible to include an addition parameter. Mainly “from”. The server processes this extra parameter (originally not included or even hidden just very guessable) as the account that the money should come from. We could simply use any arbitrary account number. Some would use Burp’s intruder to brute force a range with a different content length depicting a valid account in use. Intelligently we probably would be incrementing whatever our account is originally by a few.
Here you can see the from field that we appended in the body being processed by the server. In the response the injected from field is interpreted as the account to transfer the money from. I chose 917 because our original was 918.
Screenshot to illustrate additional parameter in request body being processed by the server
Reflected Cross Site Scripting:
I noticed that our value for the to and amount field is both being reflected in the response. Our normal XSS detection methodology leads us to try and inject some special character to the server to see if they make it back down un-escaped. Sending the following values for the amount and to parameters does the trick. 1738"'<>:
Response showing our reflected values. (to field html encoded and amount field not)
We notice that the to parameters value is being reflected but it’s html encoded so we write it off. Amount’s value on the other hand is reflected an un-escaped as show above. We build out payload understanding that we’re inside of a double quote – closing right bracket. We come up with the following
to=666&amount="><script>alert('document.URL')</script>
This is after realizing that if you try to close the alert with a semi-colon that it removes the closing script tag and kills the payload. Showing the response in the browser produces the following.
Screenshot showing XSS payload executing in the browser
