Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flash + 307 redirect = Game Over

lists.webappsec.org

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Flash + 307 redirect = Game Over

#11

Post by mbreese »

Yansky wrote: post #10
nbpoole wrote: post #8

Earlier quoted context omitted.

No. Let me try explaining the simplest possible version of this attack. Your bank ( http://victim.com ) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer , you can transfer money to another person (the recipient is specified in the POST body). The attacker sets up the following things on attacker.com: 1. A page that replies with 307 redirects to…

The user would first have to go to the attacker.com phishing site though right? It sounds like it makes phishing scams a lot easier. (thanks for the explanation btw)

My reading is that it's not necessarily phishing because they wouldn't need to ask the user for any information. All that would be required is for the user to be signed into the targeted webapp.

It could be totally automated. But, since the attacker doesn't get the response, they couldn't necessarily do anything with that. That doesn't make this any less dangerous, as in the bank example, you don't necessarily need to see that your transfer was successful in order to get the money.

Re: Flash + 307 redirect = Game Over

#12

Post by nbpoole »

Yansky wrote: post #10
nbpoole wrote: post #8

Earlier quoted context omitted.

No. Let me try explaining the simplest possible version of this attack. Your bank ( http://victim.com ) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer , you can transfer money to another person (the recipient is specified in the POST body). The attacker sets up the following things on attacker.com: 1. A page that replies with 307 redirects to…

The user would first have to go to the attacker.com phishing site though right? It sounds like it makes phishing scams a lot easier. (thanks for the explanation btw)
is all that you need to execute this attack in your browser. An attacker can hide the applet via CSS and put it on a legitimate looking page. All the target needs to do is be logged in.

Re: Flash + 307 redirect = Game Over

#13

Post by dminor »

bensummers wrote: post #9
nbpoole wrote: post #4

Earlier quoted context omitted.

Fortunately, the attack is limited by the fact that the attacker can't see the response from the server. If the attacker could view the response, it would break CSRF protection based on nonces as well.

What if that forged request was to a "create new account" URL, for example? Or to delete something important? Or transfer some money? Do you need to see the response to do bad things?

I think what he's saying is if your CSRF protection is based on a nonce, this vulnerability doesn't break it.

Re: Flash + 307 redirect = Game Over

#14

Post by ben_h »

nbpoole wrote: post #8
euroclydon wrote: post #7

Earlier quoted context omitted.

So my bank would have to already have a page which returns a 307?

No. Let me try explaining the simplest possible version of this attack. Your bank ( http://victim.com ) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer , you can transfer money to another person (the recipient is specified in the POST body). The attacker sets up the following things on attacker.com: 1. A page that replies with 307 redirects to…

Good explanation, thanks.

The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to be included in all non-GET requests. How does the attacking app satisfy this token check?

Re: Flash + 307 redirect = Game Over

#15

Post by scommab »

nbpoole wrote: post #12
Yansky wrote: post #10

Earlier quoted context omitted.

The user would first have to go to the attacker.com phishing site though right? It sounds like it makes phishing scams a lot easier. (thanks for the explanation btw)

is all that you need to execute this attack in your browser. An attacker can hide the applet via CSS and put it on a legitimate looking page. All the target needs to do is be logged in.

If you want to be super evil about it you could also embed the evil POSTing code in a swf that looks like an unevil ad and then let an unsuspecting ad network distribute it for you.

Edit: grammar.

Re: Flash + 307 redirect = Game Over

#16

Post by nbpoole »

bensummers wrote: post #9
nbpoole wrote: post #4

Earlier quoted context omitted.

Fortunately, the attack is limited by the fact that the attacker can't see the response from the server. If the attacker could view the response, it would break CSRF protection based on nonces as well.

What if that forged request was to a "create new account" URL, for example? Or to delete something important? Or transfer some money? Do you need to see the response to do bad things?

No, but that wasn't my point. My point was that this vulnerability can be (and has been) worked around by using nonces in the header. If you can see the response body, that protection becomes worthless as well (and there is no workaround for that).

Re: Flash + 307 redirect = Game Over

#17

Post by nbpoole »

scommab wrote: post #15
nbpoole wrote: post #12

Earlier quoted context omitted.

is all that you need to execute this attack in your browser. An attacker can hide the applet via CSS and put it on a legitimate looking page. All the target needs to do is be logged in.

If you want to be super evil about it you could also embed the evil POSTing code in a swf that looks like an unevil ad and then let an unsuspecting ad network distribute it for you. Edit: grammar.

Correct. Put it up using Google Adwords or a similar network, make sure attacker.com has a proper crossdomain.xml file (because the SWF won't be served from attacker.com), and you have a working exploit that can be deployed all over the Internet.

Re: Flash + 307 redirect = Game Over

#19

Post by euroclydon »

ben_h wrote: post #14
nbpoole wrote: post #8

Earlier quoted context omitted.

No. Let me try explaining the simplest possible version of this attack. Your bank ( http://victim.com ) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer , you can transfer money to another person (the recipient is specified in the POST body). The attacker sets up the following things on attacker.com: 1. A page that replies with 307 redirects to…

Good explanation, thanks. The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to be included in all non-GET requests. How does the attacking app satisfy this token check?

Rails WAS configured to accept the token OR a custom header, relying on the fact that custom headers can't be created cross domain. The patch fixes this, by requiring BOTH. Hmmm... So how do they know what the custom header is? Are they typically static?

Re: Flash + 307 redirect = Game Over

#20

Post by rst »

ben_h wrote: post #14
nbpoole wrote: post #8

Earlier quoted context omitted.

No. Let me try explaining the simplest possible version of this attack. Your bank ( http://victim.com ) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer , you can transfer money to another person (the recipient is specified in the POST body). The attacker sets up the following things on attacker.com: 1. A page that replies with 307 redirects to…

Good explanation, thanks. The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to be included in all non-GET requests. How does the attacking app satisfy this token check?

The bug was that Rails didn't check for the authenticity token in case of requests that were labeled as XmlHttpRequest (i.e., Ajax), and the redirect-from-flash game allows the attacker to forge the label. The fix makes it check in all cases; this is why it comes with stuff that you're supposed to patch into your layouts and application.js to put authenticity tokens into all your Ajax calls.
Post reply on HN