How to protect widgets from forged requests

 

Lets say you have a JavaScript widget which needs to fire off a request to your web application if and only if the user wants to click on it. You don't want this request to be vulnerable to CSRF so you write an iframe to the page. Based on the origin inheritance rules the parent site won't be able to read the CSRF token. However what about clickjacking (or likejacking )? Because of CSRF you must be within an iframe and there for the x-frame-options cannot help, and the same holds true for frame-busters.

The attacker is going to apply an SVG mask the iframe after the widget has loaded. This mask will make the iframe invisible. At this point the attacker can either resize the iframe to be the size of the page or have this now invisible iframe follow the cursor. Either way whenever the user clicks anywhere on the page, the iframe receives the click event and its game over.

So there is a duality, it seems you are stuck between CSRF and Clickjacking. What the best solution (if any) to this problem?

Clicking on the widget needs to open a pop-up window containing a new page -- an iframe is not good enough, it must be a new window -- which is entirely under the control of your web application. Confirm the action, whatever it is, on that page.

Yes, this is somewhat inelegant, but the present Web security architecture doesn't give you any better options.

There is no way to prevent request forgery while under a clickjacking attack. No CSRF defense exists that can withstand a clickjacking attack, because there is no way to distinguish a real click from a fake click on the client side.

OWASP mentions in their CRSF prevention spreadsheet that one of the preconditions for the CSRF token defense to work is that no XSS attack is underway.

In my view this should also include clickjacking, as the CSRF token even hidden inside iframe cannot defend against clickjacking. The request is being forged by a direct user click.

So in the end we are not really stuck between CSRF and Clickjacking - CSRF defenses are meant for a different type of attacks where there is a lot less power on the side of the attacker.

So towards the questions you mention concerning clickjacking and CSRF:

  • What is the best solution (if any) to this problem? - The best defense for clickjacking on the client side is to open a new browser tab or a resized browser window with a page from your site and confirm the action there, as @Zack mentions. This is what the twitter button does, and there cannot be request forgery in this scenario either.

  • So there is a duality, it seems you are stuck between CSRF and Clickjacking - The CSRF defenses are not meant for cases like XSS or clickjacking attacks, they are effective only against less powerful attacks (email with malicious link, post malicious link in forum etc.)

    • There is no good programmable solution on clickjacking. Some companies sue spammers as a defense to clickjacking. Others choose to show popup windows once user clicked inside iframe, although it degrades user experience, especially in case of single-click-button. This is exactly what Twitter do for the “Retweet” button. Facebook currently deploys this approach for the “Like” button, asking for confirmation whenever requests come from blacklisted domains. I've heard that Googlebot perform some clickjacking heuristics while indexing pages with its “+1” button (checking computed styles, elements overlapping and so on)…

    链接地址: http://www.djcxy.com/p/87118.html

    上一篇: 如何从AJAX调用顺序加载图像[Web Development]？

    下一篇: 如何保护小部件免受伪造请求