Gareth has an interesting suggestion on his blog. In his new entry IFrames are Evil, he suggests introduction of some html attribute (or tag) to disable/enable iframes.
Considering the possibilities of attacks using iframes, ranging from CSRF to CSS attacks, (and the recent Bank Of India "drive-by download" hack, where malwares were downloaded onto the victims computer), I thought it'd be a good to ask the view of other slackers. :)

Further, I also wanted to know what does ma1 think on providing an "optional" feature to block iframes through NoScript.

---
I'd love to change the world,
but they won't gimme the source code.
Code in my Bug!

I think it useless, disabling stuff like javascript, Java, Flash, Cookies, and now Iframes doesn't help at all. While were at it, let's throw out HTML also and go back to plaintext. I don't know anyone -besides people in the appsec corner- that is using NoScript. People don't know, and they don't care. All they want silly e-cards and stupid stuff.

Well I have to disagree Ronald, if iframes were disabled by default and only enabled when a developer needs to use them it would help browser security. For the end user I agree if it was their choice, but if we leave it to the web developer to enable what they need then I can see the internet becoming more secure than it is currently.

Take the following analogy, the current browser world is like this:-
"It's like having a loaded gun delivered to your door without having any background checks or any record it was delivered. Anyone can pick it up and use it"

@Gareth:
Whether or not this is a good idea, I'm not going to debate (since I have no answer myself), but implementing a CSRF protection in this manner is rather useless since the request to the server is still made, and everything is processed, since the tag is in the response. If you want to use this to stop CSRF then a better solution is to have a per directory file which is requested to find out to what page/subdirectories iframe requests can be made. Or even just add this to the content restrictions mechanisms they're planning on building.

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

@kuza55

Of course it wouldn't prevent all CSRF attacks but it would help prevent some. My point was that the state of iframes as they stand is a joke, why does every single page and site have them enabled when they don't have to. My security tag idea could be applied to more than just iframes as well.

You can disable it browserwise, that isn't the problem. Only no-one will do this, I talk about mom and dads here, not us. Because they aren't educated at all, when they see a kitten purring on a banner asking them to install yet another backdoored screensaver, they will click. No matter if you throw up warnings or "permission" screens, they instantly click: "remember my choice" lol ^^

I rather have a system where ALL external content is excluded from loading through the site you are watching. Or so to speak, permission from that site alone. If some content is fetched from remote servers through that page -like an iframe- you could have a small screen that overlays the DOM and asks you wether you want it to load or not. So basically all non-same origin content is denied, including but not limited to images, html, flash, java, css, etc.

That would be great, but people will get annoyed by the popup or screen asking them to remember the setting or something, or turn it off completely. You know, people are lazy. ^^ ah I am repeating myself.

I understand your idea Gareth, but CSRF can be done through images also. So basically we cannot protect the surfers by throwing up barriers and chain them some more, it won't work. I have given up educating regular surfers.

Quote:

I don't know anyone -besides people in the appsec corner- that is using NoScript.

I completely agree with this... and we cannot really blame people for it.
Let's face it, they don't have to worry about what Javascript can do to them, and how IFrames can exploit their system.

However, what my point was that unless these issues are *reduced*, may be through Content Restriction, why not have such an *optional* feature for us in NoScript itself.

I, however, must also admit that I don't yet have any solid view on the topic myself. That's why I put it up for discussion. :)

---
I'd love to change the world,
but they won't gimme the source code.
Code in my Bug!

Right well as a security guy I want to be able to disable iframes on my browser settings or through noscript, at the moment this is not possible. I couldn't care less if aunt sally wants to click a banner that says she's won $1000.

But remember if sites themselves decided when the iframes were used and on what page then it doesn't matter what personal settings the user had.

Regards to CSRF this idea could be improved to prevent all CSRF iframe attacks by using a separate file to decide the preference.

Iframes are more dangerous than images because you can perform POST attacks, multiple page interaction and redirects.



Edited 1 time(s). Last edit at 09/10/2007 03:42AM by Gareth Heyes.

Hi everybody.

1. I like Gareth's proposal, which conceptually overlaps with the Content Restrictions which are in the works, thus I guess we should wait for them to be implemented (and possibly ensure it covers iframes, images, CSS and other means to cross-pollinate requests as well), because having a browser (de-facto) standard to rely upon is mandatory for hoping the lazy web developer to take a look at it.

2. I agree iframes are a bit more dangerous than images, even if once malicious content has been injected it's hard to say what's more dangerous and what's less.
At any rate, it won't be hard to integrate a "Forbid iframes" option working just like the "Forbid Java" and other plugin stuff, i.e. showing a placeholder for on-demand activation. It will be done in NoScript 1.1.7.1 (1.1.7 has just been released)

3.
Regarding CSRF, I already said I'm developing a mix of server-side (developer-provided) and client-side (user-provided) firewall-like rules to specify allowed/denied cross-site requests, identified by origin, target and method: such an approach would greatly mitigate the threat, at least for valuable sites (my bank or paypal account), yet allowing "legitimate" mashups.
However, current NoScript Anti-XSS filters already strip out POST payloads from every request originating from an untrusted origin and landing on a trusted site, having as a side effect a first-line CSRF mitigation.

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 2 time(s). Last edit at 09/10/2007 07:03AM by ma1.

You know what I'd really like in noscript, if I had the time to learn Firefox plugin creation I'd do it but here goes hopefully you could add it to noscript and then you would be crowned a god in my eyes :), this would protect against CSRF on the browser level :-

1. Noscript scans the document for all links
2. It then appends a unique one time token on each of the URLS like CSRF_TOKEN=Eysd28437.
3. Then at the browser level it checks for the existence of this token before allowing a post or access to the image.

Now in order for a CSRF attack to work, the attacker has to supply the correct token for the user request, so noscript could store the token in the users session. I think that would work for most CSRF as the attacker would have to scan the source code as the user in order to retrieve the correct token and if they can do that then it's pretty much game over anyway.

Forgive me if this isn't possible with a Firefox plugin but it would be ace if it could be done.

@ma1

Oh yeah you know I'm a fan of your plugin but hey a little more praise won't hurt....

Your plugin rocks!

I can't wait for the 1.1.7.1 release

Gareth Heyes Wrote:
-------------------------------------------------------
> @ma1
>
> Oh yeah you know I'm a fan of your plugin but hey
> a little more praise won't hurt....
>
> Your plugin rocks!
>
> I can't wait for the 1.1.7.1 release

I second (third and fourth) that :P
Honestly Ma1. NoScript rocks. :)

---
I'd love to change the world,
but they won't gimme the source code.
Code in my Bug!

@Gareth:
many thanks for the praise.

However, I'm not sure I understand your concept, especially in the first step (scan and patch): how could NoScript tell which are the "good" links where the token has to be appended, and which are to be left alone (unless you are deeming CSRF by link not worth to be prevented)?

Also, how would forms, images, CSS, (meta) refreshes, window.open, frames and other non-link navigation machinery be supposed to work?

On a side note, here's a preview of how my anti-CSRF rules might look like:

# This rule won't allow any request to my bank site 
# but from the site itself or a bookmark.
# It will allow GET requests from a shared single-signon interbanking facility
TARGET https?://.*\.mybank.com/.*
DENY ALL
ALLOW ANY_METHOD FROM SELF, BOOKMARK
ALLOW GET FROM https: //.*\.interbanking-logon.com/.*

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

ma1 Wrote:
-------------------------------------------------------
> @Gareth:
> many thanks for the praise.

Hey no worries you deserve it :)

> However, I'm not sure I understand your concept,
> especially in the first step (scan and patch): how
> could NoScript tell which are the "good" links
> where the token has to be appended, and which are
> to be left alone (unless you are deeming CSRF by
> link not worth to be prevented)?
>
> Also, how would forms, images, CSS, (meta)
> refreshes, window.open, frames and other non-link
> navigation machinery be supposed to work?

Form actions could be scanned for the presence of a '?' if it is included then it would append the following to the URL &CSRF_TOKEN=8sS82ks or if it not included then it would add <form action="page.php?CSRF_TOKEN=8dKss92">.

Frames/Images/CSS/Meta could be appended like the following :-
images/image.gif#CSRF_TOKEN=1234

So the attacker tries to do the following <img src="http://website.com/account.php?action=delete">

Without the correct token noscript will not load the image/page.

This won't prevent standard links like this of course:-
<a href="http://website.com/account.php?action=delete">Delete Account</a>

> TARGET https?://.*\.mybank.com/.*
> DENY ALL
> ALLOW ANY_METHOD FROM SELF, BOOKMARK
> ALLOW GET FROM https:
> //.*\.interbanking-logon.com/.*
>

Excellent stuff, very similar to apache htaccess I like it

While I praise your work ma1, you know I'm a bit agnostic to the plugin. For the basic reason that patching a system is never a sollution. It is a shame you had to write the plugin, it should be defacto inside firefox to have the options you provide.

And what about HTML5.0 and XHTML2.0 anyone see what attrocities we can inflict with it? That would be a real hell, almost any HTML tag can be used to launch CSRF'ies. it is relatively easy to stop it now, but the future holds a very different image. HTML will be come smarter, the browser will become a Desktop on it's own, with DOM storage, cross DOM communication, SQL storage, and God knows what else...

For my concern I think we have a run-away truck on our hands.



Edited 1 time(s). Last edit at 09/10/2007 10:33AM by Ronald.

Ronald
hehe, that's why I say that the webappsec security industry in 5 years will be at it's most.

They are introducing more features than patches.. and all the features can be used for evil :D, what about "if itsn't broken, dont fix it!", any way.. :P

I'm just happy that my workfield wont dissapear in the following years, and worried about what could appear in the following versions, features are allways the biggest thread of security.

--------------------------------
irc://irc.irchighway.net/#slackers --> sla.ckers.org IRC channel
[sirdarckcat.blogspot.com] [www.sirdarckcat.net] [foro.elhacker.net] [twitter.com]

sirdarckcat Wrote:
-------------------------------------------------------
> I'm just happy that my workfield wont dissapear in
> the following years, and worried about what could
> appear in the following versions, features are
> allways the biggest thread of security.

(For continuation)
I am currently evaluating WebApp scanners for my company, and I stumbled across w3af. I feel that it has the potential to become the Metasploit Framework of WWW (and is infact developed on similar grounds).
I was also reminded of the slogan "XSS is the new Buffer Overflow, and Javascript Malware is the new Shellcode".
Apparently, future seems good :)

---
I'd love to change the world,
but they won't gimme the source code.
Code in my Bug!

This concept could easily be built into content restrictions. It's not a bad idea, and actually something I had already proposed, although I took it one step further and said "no new DOMs" which would include frames or JavaScript popups or anything else that created a new DOM.

- RSnake
Gotta love it. http://ha.ckers.org

NoScript 1.1.7.1
=====================================================================
+ New "Plugins/Forbid IFRAME" option (per Gareth Hayes' request)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

Cool man!

Nice work :D

@Ma1:
That was fast Dude. I am becoming your fan. :)

...and by the way, it was my request too :)

---
I'd love to change the world,
but they won't gimme the source code.
Code in my Bug!

@Om:
sorry mate, I updated the changelog to credit both.

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 09/12/2007 11:00AM by ma1.

@Ma1:
That's completely all right. :)
Thanks.

---
I'd love to change the world,
but they won't gimme the source code.
Code in my Bug!

I'm glad this was added.




Firefox is catching up to Opera finally. ;)

It already has javascript/java/plugins/styles/frames/iframe/etc blocking on a browser or site-to-site basis. /typical Kyran response

- Kyran

@Kiran:

Not to be picky, but...
NoScript 1.0 official release date: May 13, 2005.
Opera 9.0 beta 1: March 20, 2006.

One year to catch up... for Opera ;)

BTW, I suppose Opera has this, right?
If not, you know better than me that selective blocking is not that useful...

Does Opera's plugin blocking support one-click activation (true question, I just don't know)?

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

I must have missed too much. I don't remember NoScript having XSS protection like that. What if a site uses a third party stats script like Google's urchin.js? While not a problem for a user, it can easily throw off statistics.

And I don't understand what you mean by the last part...?

- Kyran

Kyran Wrote:
-------------------------------------------------------
> I must have missed too much. I don't remember
> NoScript having XSS protection like that.
Eh, you're not the only one who still believes NoScript just "blocks scripts" ;)

> What if
> a site uses a third party stats script like
> Google's urchin.js?

It just gets blocked, unless it's served from a trusted origin, no matter if the main site is allowed or not.
In other words, if you want stats you'd better learn how to munge your own logs, or hope your audience is glad to allow googleanalytics.com (very unlikely).

> And I don't understand what you mean by the last
> part...?

I mean that when NoScript blocks an object having a layout (e.g. an applet or a Flash movie, or an IFrame to stay on topic), this object is replaced in the document flow by a NoScript icon with the same size: you can click it to activate the blocked content on the fly without reloading the page (by default you need to confirm a prompt, too).
I was wondering if Opera had something like that, or it was just an "all or nothing", "switch and reload" blocking system.

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

*cough*

why all this hassle of a plugin btw?

does anyone at all knows that you can disable stuff in about:config?

Like: about:config > browser.frames.enabled 'false'
Like: about:config > javascript.enabled 'false'
Like: about:config > dom.max_script_run_time '5'

So I guess the argument will be: "Yeah but you can do it par site based"

My argument will be: So, you trust others? I trust no-one.

Ronald Wrote:
-------------------------------------------------------
> My argument will be: So, you trust others? I trust
> no-one.

What to say after the killer line ;)

Another argument, IMHO, could be the flexibility and control provided by NoScript. Not every user knows how to play with about:config. Moreover, there are times when we DO require javascript (and related technologies) to be enabled.

---
I'd love to change the world,
but they won't gimme the source code.
Code in my Bug!