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

31–37 of 37 posts

Re: Flash + 307 redirect = Game Over

#31

Post by nbpoole »

amalcon wrote: post #29
wnoise wrote: post #18

Hooray flashblock.

Flashblock would probably not save you. It doesn't actually prevent Flash content from being downloaded and run; it just hides it with CSS. I use NoScript myself, but that tends to break too much by default for most people. When I set up a flash blocker for other people, I give them NoScript in "Allow Scripts Globally" mode.

Are you sure about that? Because that's not the way Flashblock describes itself:

    Flashblock is an extension for the Mozilla, Firefox, and Netscape browsers that takes a pessimistic approach to dealing with Macromedia Flash content on a webpage and blocks ALL Flash content from loading. It then leaves placeholders on the webpage that allow you to click to download and then view the Flash content.
It would be pretty useless if all it did was hide the content via CSS.

Re: Flash + 307 redirect = Game Over

#32

Post by amalcon »

nbpoole wrote: post #31
amalcon wrote: post #29

Earlier quoted context omitted.

Flashblock would probably not save you. It doesn't actually prevent Flash content from being downloaded and run; it just hides it with CSS. I use NoScript myself, but that tends to break too much by default for most people. When I set up a flash blocker for other people, I give them NoScript in "Allow Scripts Globally" mode.

Are you sure about that? Because that's not the way Flashblock describes itself: Flashblock is an extension for the Mozilla, Firefox, and Netscape browsers that takes a pessimistic approach to dealing with Macromedia Flash content on a webpage and blocks ALL Flash content from loading. It then leaves placeholders on the webpage that allow you to click to download and then view the Flash content. It would be pretty us…

Wikipedia cites this as the source for that assertion:

http://flashblock.mozdev.org/faq.html#fbFlashCookies

If it prevented the object from loading, it would block Flash "cookies".

edit: Looks like it does call StopPlay() on the movie, which prevents any audio/visual effects.

Re: Flash + 307 redirect = Game Over

#33

Post by nbpoole »

amalcon wrote: post #32
nbpoole wrote: post #31

Earlier quoted context omitted.

Are you sure about that? Because that's not the way Flashblock describes itself: Flashblock is an extension for the Mozilla, Firefox, and Netscape browsers that takes a pessimistic approach to dealing with Macromedia Flash content on a webpage and blocks ALL Flash content from loading. It then leaves placeholders on the webpage that allow you to click to download and then view the Flash content. It would be pretty us…

Wikipedia cites this as the source for that assertion: http://flashblock.mozdev.org/faq.html#fbFlashCookies If it prevented the object from loading, it would block Flash "cookies". edit: Looks like it does call StopPlay() on the movie, which prevents any audio/visual effects.

I just tested the extension and I can confirm that Flashblock only downloads and runs the content when the placeholder is explicitly clicked on. So, Wikipedia is wrong. ;)

Edit: If I browse to an SWF directly, it does appear to load the content. If I create the SWF via SWFObject, it does not load until I explicitly click on the placeholder.

That question is poorly worded. It's referring to blocking Flash cookies in general. Flashblock will not prevent the use of Flash cookies by applets that you allow to run.

Re: Flash + 307 redirect = Game Over

#36

Post by cheald »

euroclydon wrote: post #23
cheald wrote: post #22

Earlier quoted context omitted.

The CSRF token is generated and stored in the user session, so rather than just X-Requested-With: XMLHttpRequest, you now also get an X-CSRF-Token: . Rails doesn't check for XRW anymore; it just cares that you passed a valid CSRF token through, either as a POST variable (normal POST/PUT/DELETE) or in the X-CSRF-Token header (AJAX). In case you're wondering, yes, this does make caching with Varnish a bitch and a half.

I want know how the exploit works. The Flash app has to write a custom header. How does it know the value to put in the header, unless it's always the same for all sessions across all users. P.S. You cache POST/PUT/DELETES?

That's the point of the fix. The header is custom per user now. Before, the presence of the "X-Requested-With: XmlHttpRequest" header was enough to let Rails assume the request was legit. Since Flash doesn't respect the victim's crossdomain.xml, this is no longer a valid assumption, and you have to use a unique header per session.

This means writing this unique value out into the page somewhere, to be included with any AJAX requests, which means that you cannot cache these pages as you might before, since AJAX calls would fail for everyone except the person who populated the cache.

Post reply on HN