CODEWITHSUNDEEP
securityweb-applicationscsrf
junzi749
junzi749

Reputation: 11

a real CSRF attack?

We team discussed CSRF attack recently. My team member said that the following is a CSRF attack: 1. Attacker sends a forged html file, which may have some forged request like steal cookie, to the victim 2. The victim saves the file 3. The victim opens the trusted website, then open the html file 4. The request of the file is executed

It can work on chase allowing make user log off. The following is the script:

<!DOCTYPE html>
<html>
<body>

<p>Create a link of an image:
<a href="default.asp">
<img src="smiley.gif" alt="HTML tutorial" width="32" height="32"></a></p>

<p>No border around the image, but still a link:
<a href="https://chaseonline.chase.com/secure/LogOff.aspx">
<img border="0" src="smiley.gif" alt="HTML tutorial" width="32" height="32"></a></p>

</body>
</html>

It can at least make myself logoff successfully. However, I felt like it is because the file is executed locally which make it work. If I open a real malicious website or page, it may not work. Can anyone give me any ideas?

Thank you~

Upvotes: 1

Views: 199

Answers (2)

Mansi
Mansi

Reputation: 55

Let me also take the classic example of CSRF attack, where the attacker tricks the victim to transfer money to his account, provided that the victim has an active session with the bank. This attack requires a POST request to be submitted on victim's behalf while he has a legit session with the bank. The attacker can make victim to visit a page that contains the following HTML:

<html>
<body>
      <form name="hack_form" action="http://CrapyBank.com/csrf.php?menu=400&TransferFunds=4000" method="POST">
          <input type="hidden" name="hack_param" value="hack">
      </form>
      <script type="text/javascript">document.hack_form.submit();</script>
</body>
</html>

Upvotes: 0

Aurand
Aurand

Reputation: 5547

Okay, let's say you run a website for a bank. Let's say that you have an end point which acceps POST request to https://bank.example.com/transfer with form data containing what account to transfer to and the amount of money to transfer. Of course, you'll check the session cookie to make sure that the request comes from a user with a valid session.

Now, a malicious website can build a form containing an account number they want they want money to be sent to and some arbitrary sum of money. Now all they need to do is post all visitors to the malicious site to https://bank.example.com/transfer. Any victim who lands on the malicious site after signing into your bank site (and getting a valid session cookie), can now have money stolen from them.

The standard fix for this attack is to require all endpoints which cause an important state-change to also submit a random, one-time, secret key which is separate for the user's cookie cache (generally included your web site on the page you expect the request to be coming from).

Upvotes: 2

Related Questions