Comments on Attack and Defense Labs: Bypassing CSRF protections with ClickJacking and H...

Hello there.................. i m a begginer........

2012-02-05T10:11:44.225-08:00

Hello there..................

i m a begginer.............
for this i will hav to create a website?
and then upload these scripts?

I like the helpful information you provide for you...

2012-01-31T02:01:23.905-08:00

I like the helpful information you provide for your articles. I’ll bookmark your weblog and check again here frequently. I am quite sure I’ll learn many new stuff proper here! Best of luck for the following!

You...are...awesome! This blog is so great. I re...

2012-01-17T15:31:46.993-08:00

You...are...awesome! This blog is so great. I really hope more people read this and get what you're saying, because let me tell you, its important stuff. I never would've thought about it this way unless Id run into your blog. Thanks for putting it up. I hope you have great success.

Each and every post of the form The CSRF token sho...

2012-01-15T22:20:31.739-08:00

Each and every post of the form The CSRF token should be checked, it hepls us in protecting the evil form submission.

Nice One

2011-12-12T21:55:45.313-08:00

Nice One

@anon Thanks. What you have suggested would actual...

2011-01-26T00:29:40.562-08:00

@anon
Thanks.
What you have suggested would actually work but that may not be necessary. If you implement strong Clickjacking protections in your application then this vector is automatically taken care of.
If you block this vector without Clickjacking protection then CSRF can still happen using the HTML5 Drag-n-Drop API, its a little bit more tedious to pull off when compared to this though.

I found this post a bit late, but interesting read...

2011-01-25T11:25:48.348-08:00

I found this post a bit late, but interesting reading nonetheless.

Maybe a viable counter-measure to this kind of attack is to implement a request filter that checks:

1. Presence of the CSRF token
2. If token present, check if form was submitted via POST
3. Check for the presence of query parameters on the request URL

If any of those checks fail, the requested action would be denied.

@pinkgothic thanks for the info. I have never used...

2010-03-20T10:17:33.174-07:00

@pinkgothic
thanks for the info. I have never used zend so I dont know how it works there. AFAIK in PHP POST data takes precendence over GET, which is the exact opposite of JSP. So I dont think this attack can work against it. However I have never used zend, are you saying this attack works on zend? that would be intresting

...ohduh. Sorry. url() View Helpe...

2010-03-19T02:30:24.075-07:00

...ohduh. Sorry. url() View Helper. Been working with Action Helpers too often lately.

Warning, PHP-centic comment ahead: This kind of t...

2010-03-19T02:28:52.782-07:00

Warning, PHP-centic comment ahead:

This kind of thing is why we ended up changing the Zend HTTP Request Object (well, extending and using, not changing) away from its hard preference of GET over POST for getParam(), and molded it into one that reads out the request_order/variables_order INI settings and behaves accordingly.

In nine out of ten cases, I'm a fan of aggregating request parameters in some way, since it helps defeat an unfortunately still wide-spread belief that making something POST means it can't be hacked 'anywhere near as easily', and forcing people to deal with all incoming methods hones their security sense a bit more - but prefer-GET-over-POST is definitely broken in so many ways. *always changes this*

It's especially evil in Zend, actually, since by default if you manage to get someone to pollute their GET-parameter space on one page, Zend's url() Action Helper will drag that along to other pages - i.e. it wouldn't help if you had a <form action="<?php $this->url('controller' => 'your-controller', 'action' => 'your-action'); ?>"> in that script.

(We changed that with our own version, too.)

*shudders* Nightmare.

@cedric Thanks :) Any defense that prevents ClickJ...

2010-03-17T12:18:48.018-07:00

@cedric
Thanks :) Any defense that prevents ClickJacking will automatically prevent this attack as well.

@Marcos
Interesting stats!. Session IDs in the URL or a CSRF token in the URL can also thwart a ClickJacking attack because the URL for the iframe cannot be guessed by the attacker. I dont see anyone talking about it or maybe its lost in the noise about the framebusting-based approach.
Views?

@cedric: right, this is another frame-busting code...

2010-03-17T04:21:02.947-07:00

@cedric: right, this is another frame-busting code. Twitter and other sites now already implement that code. In our work, we had run an experiment to assess the prevalence of such sites: ~3.8% = 352 sites. See section 4.3 for more details :)
embyte

A temporary fix that could work could be a simple ...

2010-03-13T13:19:52.865-08:00

A temporary fix that could work could be a simple javascript script like this http://www.cryer.co.uk/resources/javascript/script1.htm . Very interesting article. Thank you.

Hi Marco, I can see that your approach is justifie...

2010-03-12T11:46:39.913-08:00

Hi Marco, I can see that your approach is justified based on what you were trying to achieve. Good luck for your own presentation @ asiaccs2010. Am looking forward to Paul's talk too, should be interesting. Take care.

Hi there, I reached your answer for "chance&q...

2010-03-12T03:39:04.546-08:00

Hi there, I reached your answer for "chance" since blogger did not informed me :) I see the point, actually we could have run the experiments in simulation by detecting overlaps only looking at the elements' coordinates. Btw, we decided to go for the "real clicks" scenario since many applications are pretty complex to analyze for their dynamic behavior (see Javascript/CSS events as you are saying). Moreover, our primary goal was to conduct a study of the prevalence of clickjacking attacks on the web and that's why we employed noScript in its modified version (and to make noScript run we need to physically interact with the page by clicking on the elements).
Regarding the fact that we used FX to conduct the research you are right. It would be nice to deploy the same system on Explorer, e.g. by running Explorer in Linux with "wine" (the emulator) and porting ClickIDS to Explorer as BHO.
I am pretty sure that many CSS attacks are tailored for Microsoft and Explorer.
Note that our findings have been manually tested on Explorer too.
Great that you like the work.
Next April there will is a talk at BH Europe on clickjacking, I don't know Paul but hopefully will be interesting.
Have a nice day.

Thanks Marco. I do realise that ClickJacking relie...

2010-03-07T15:01:11.334-08:00

Thanks Marco. I do realise that ClickJacking relies on careful CSS rendering. Since I wanted to emphasize on the 'anti-CSRF' technique here, I left out the CSS part in the example's IFRAME for simplicity. I read through your whitepaper, it is a very impressive piece of work and a novel approach. I have some observations. Your 'testing unit' scans through the page for clickable elements and clicks on them. The ClickIDS scans for other clickable elements in the same region and then triggers an alert. Instead cant you simply scan for all clickable elements and look for overlapping units and trigger the alert. That might be much faster and efficient. For the rare cases where sections of the pages are changed based on mouse movements, you can rescan the page. Moreover since FF is used for the testing there is a possibility that some attacks were missed. Because in my limited experience with CSS I have seen differences in how IE and FF align elements. And IE being more popular more attacks would target its users. These could have possibly gone undetected in your assessment. Would like to hear your views on this. Its an excellent academic effort, congrats!

Nice. Just one remark. The IFRAME inclusion is a s...

2010-03-03T08:44:52.771-08:00

Nice. Just one remark. The IFRAME inclusion is a standard technique for this kind of web attacks. Clickjacking is something different in which the IFRAME is (usually and in simpler attacks) css-rendered transparently and overlaid at the web page in order to trick the user into clicking on elements controlled by the attacker. Maybe you would be interested in a work with a recently conducted on Clickjacking : "A Solution for the Automated Detection of Clickjacking Attacks" - Have a nice day, embyte