XSS sample using Zone Alarm link

[fax]

Hi!
the XXS presented here can do very limited damage for user of online banks or other 'serious' on-line businesses.

1. Most Banks have two separate codes for accessing and operating with the account;
2. Many web banks prevents the autocomplete to work;
3. Many uses virtual keyboards;
4. Many uses disposable codes, TANs, you need to input addittional to your user password to get access;
5. Few banks use tokens to generate passwords

For underground thiefs there are far more effective tools then XXS (i.e. ad-hoc trojans, advanced keylogggers, etc.).
So commercially speaking your 'product' is not very lucrative...

Fax

[elio]

Originally Posted by Mrkvonic

Automatically remember your password
Well, that does kind of contradict the meaning of password right?

Oh, uh... wrong, according to Mozilla security crew

Originally Posted by Mrkvonic

Doing sensitive stuff online
This has much to do with your country law and bank policy than the Internet.

Right, and we all know how smart are people working for government agencies and financial institutes when it comes to technology.
BTW, you forget Paypal and company.
Not to mention all the other nasties that can be done with someone else's identity, exploiting his browser, his cookies and his IP address, not necessarily involving any immediate online money transfer.

Originally Posted by Mrkvonic

Why click on a link in an email to access your bank site?

Yeah, why bother to click when you can be comfortably sent there inside an invisible frame while you're browsing your favorite Lusty-Teens-With-Lubed-Latex-Teddy-Bears website?

Originally Posted by Mrkvonic

Life online

It's your online life, your right to live it dangerously
As I said, many annoying things don't necessarily involve money transfers...
Sounds like you're a regular poster on one internet message board at least.
What if someone used a XSS trick to make you post thousands of "I'm a JavaScript slave" messages on every topic here?
But then you're a Noscript user, so I guess easier targets can be found around

Originally Posted by fax

For underground thiefs there are far more effective tools then XXS (i.e. ad-hoc trojans, advanced keylogggers, etc.).
So commercially speaking your 'product' is not very lucrative...

You would be surprised...

[fax]

Originally Posted by elio

You would be surprised...

Yep, phishing...
But you don't need any sophisticated XSS to do phishing...
Most user will click on whatever they receive

Fax

[Rmus]

Originally Posted by elio

I also unconditionally approve your attitude to security, default deny (which, if taken seriously, would reveal how anti-virus products as they're conceived today are just a money-mongering joke).

The sad fact is that AV so dominates the security industry that other solutions are pretty much ignored by the mainstream security media. You have to search for White Papers and the like to get other information.

But you're suggesting to whitelist HTTP connections (i.e. the sites I can open) and prompt me (block me!) every time I follow a casual link

I didn't say that. My procedure deals with situations where the user plans to make a secure transaction, during which time the normal browser rule is disabled and only White Listed links are permitted. In casual surfing, the normal browser rule permits all traffic.

The Noscript extension has been recently called "madness" because denying just code execution (in a non-blocking, easy-opt-in fashion) would be too much "crippling the web"...

I agree, and again, my White Listing procedure is implemented only when engaging in secure transactions. Normal surfing is not "crippled."

The most important aspect is that the page is not made up to appear like the original, it is the true original from the true original server (just "enhanced" with some alien code of mine).

This, of course, is very sophisticated and visually, would fool anyone. But it is possible to prevent against, if the user wants to set up the procedures.

Even supposing that you whitelist the "good" HTTP traffic (and this sounds hardly effective if I decide to post the data in a google group, in a google document or in another wonderful read/write google tool using an account set up just for this scam), how do you cope with the fact I could order a money transfer (supposing this is a bank account or Paypal) or send an email containing the interesting data to my disposable mail address (supposing this is a webmail) or any other funny activity I can imagine to perform impersonating you without leaving the vulnerable site*?

To suppose that I would engage in some type of transaction like that initiated from anything "Google" is ludicrous.

Those types of transactions should be done only by going directly - not from links - to secure sites that you have accounts with, that you know how they work, how the site communitates to its users regarding accounts.

You mentioned that "normal" users wouldn't bother with learning about that. Maybe not, but those who do (and I know many) would not get caught engaging in transactions initiated by data posted in a Google group, and we (those in my circle of friends who help people) *strongly* advise against any of the Google (or other) tools that purport to simplify things.

It's become a cliche that we don't use enough "common sense" or "engage our brain." But it's true, and unfortunately, this practical type of thinking gets lost in the estoteric discussions of threats, exploits, and the myriad sophisticated products purporting to deal with these situations.

XSS is not discussed much, and is certainly one of the more serious threats today, especially since most people are easily duped, and would be completly unaware of what is going on behind the scenes.

It should cause people to examine closely their procedures for engaging in online transactions, and even their entire security strategy. Many don't seem to have one.

As far as compromises on "social networking" sites - this is a different situation altogether. I'm not involved in that type of activity, nor is anyone that I know. So I can't comment on preventative measures, but I'm sure they exist.

Looking at examples like those you have posted help us to see how these things work, and is the only way to understand how to protect against them.

This has been my oft-mentioned complaint, that most security advisories/bulletins do not follow up their announcements with step-by-step details of how exploits work. This leaves the user with nothing to analyze, therefore nothing on which to base a security response, other than "keep your AV updated," and, "install the latest patch."

Fortunately, if you are willing to dig and search, you can get the proper information.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[elio]

Hi Rich,
many thanks for your thoughtful response.

I would only like to clarify what seems a little misunderstanding:

Originally Posted by Rmus

To suppose that I would engage in some type of transaction like that initiated from anything "Google" is ludicrous.

No, I mean that the script while being in your valuable and vulnerable site acting as you could evade your technique by posting the stolen data to a site which is likely in your firewall whitelist, like (as I wrongly assumed) some Google read/write tool.
Furthermore, depending on the kind of the vulnerable site, I added that it could even not need to evade your constraints and leave the vulnerable site itself: by using email, if we're talking about some webmail (BTW, many vulnerabilities of this kind have been reported against Yahoo), or by performing the transaction directly (programmatically filling fields and submitting forms) if it makes sense as a goal.

Originally Posted by Rmus

Those types of transactions should be done only by going directly - not from links - to secure sites that you have accounts with, that you know how they work, how the site communitates to its users regarding accounts.

As I said multiple times, those transaction wouldn't be necessarily initiated by you.
They could be initiated and completed in background (e.g. inside an invisible frame) exploiting just the fact you're already authenticated (possible in a different window) or have some form of semi-automatic login in place (e.g. "remember me" cookie or password automatic completion).

Originally Posted by Rmus

XSS is not discussed much, and is certainly one of the more serious threats today, especially since most people are easily duped, and would be completly unaware of what is going on behind the scenes.

It's becoming quite discussed in web development circles, because commercial "solutions" which claim to improve web site security avoiding to hire and motivate better developers do exist, and they're a very profitable business.

It's not discussed as much among end users, maybe because today there's no commercially viable way to monger money from a client-side antiXSS solution, unless you can afford to stand against the powerful advertising and behavior-tracking industry.

The only available (and IMHO very valuable) defense against XSS in user-land, so far, is the Noscript Firefox extension.
It is free, open source and appreciated among independent web security researchers, less loved (for obvious reasons) by publishers, security corporations, mainstream programmers and clueless web designers.

The best part is that you know exactly what it does, why it does it and how it does it: no snake oil, no closed source engines, no secret sauces.

The concepts behind it are default deny, minimum privileges and explicit trust boundaries: simple, proven and effective.
The way they're implemented reveals a careful effort in balancing security and usability.
The (non)feature I like most is that no blocking prompt asking obscure security questions is ever thrown at user's face, because this greatly reduces the risk for behavior conditioning ("Do you want me to rape your wife [Yes|No]? Sure thing!").
Instead, intuitive handles are always at click reach to elevate privileges where and when needed. User can decide by himself if he really needs scripts or the site is already running just fine, thanks, and if he trusts the site enough to allow them.
So even in the worst case (completely clueless user) navigation will be just as safe as in a vanilla browser, but most of the time it will be much safer.
Not because the browser itself is made more secure (even if it is, to a certain extent), but because the web becomes a slightly less savage and swarming place.

Just my 2 cents
Elio

[Rmus]

Originally Posted by elio

Furthermore, depending on the kind of the vulnerable site, I added that it could even not need to evade your constraints and leave the vulnerable site itself: by using email, if we're talking about some webmail (BTW, many vulnerabilities of this kind have been reported against Yahoo), or by performing the transaction directly (programmatically filling fields and submitting forms) if it makes sense as a goal.

Hello Elio,

These are good points. There is a lot I've not mentioned regarding what I take into consideration about internet security, and discouraging the use of the above are two.

Regarding discussion of XSS:

It's not discussed as much among end users, maybe because today there's no commercially viable way to monger money from a client-side antiXSS solution, unless you can afford to stand against the powerful advertising and behavior-tracking industry.

Fortunately, in forums like this, people can get information. The fact that not many have posted, perhaps shows the lack of awareness about this type of threat - including me until now.

Until you posted that code, I was unaware of the specifics of how these things worked. That's why I kept pestering you for a working example.

Again, as I mentioned in my above post, specifics about most exploits are not always readily available.

The idea about preventing against pharming is one I discussed in an old thread on HTTPS security. This technique just happens to also work in this case.

Good explanation of FF NoScript. Certainly is a very practical solution. FF sales should jump. Maybe you will get a commission.

Just click here and fill out the form with your bank information for a direct deposit


regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[lucas1985]

Originally Posted by Rmus

The idea about preventing against pharming is one I discussed in an old thread on HTTPS security. This technique just happens to also work in this case.

This thread?
I do use a separate HTTPS rule in my firewall w/logging.

[Pedro]

Originally Posted by Rmus

The fact that not many have posted, perhaps shows the lack of awareness about this type of threat - including me until now.

Got you here, WRONG!

I'm just trying to get the picture. Since i'm replying, mainly to note that there could be others too, just reading and trying to learn something, i'd ask for you guys to break it down by the types that exist.

XSS type 1, 2, etc. What do they imply, how do each happen and how to counter them.
At least one seems to imply code on the "legit" site alone. Some other refers to a second window open that abracadabra can read my cookies and such. (HELP)

[Rmus]

Originally Posted by Pedro

Got you here, WRONG!

I (happily) stand corrected!

XSS type 1, 2, etc. What do they imply, how do each happen and how to counter them.

If you are referring to the types discussed here:

http://en.wikipedia.org/wiki/XSS

I mentioned them in the other thread:

http://www.wilderssecurity.com/showt...=173750&page=2

See post #32.

At this point, I was addressing just the user interaction stuff, because the article gives no specifics. It's not until elio posted his code that there was anything of substance to deal with.

At least one seems to imply code on the "legit" site alone.

The code elio posted in this thread illustrates this, and two solutions are discussed:

1) mine with firewall rules

2) elio's description of the FF extension.

Is this what you are asking about?

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[Rmus]

Originally Posted by lucas1985

This thread?
I do use a separate HTTPS rule in my firewall w/logging.

That's it, Lucas!

Somewhere in those 105 posts the separate HTTPS rule is discussed.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[Pedro]

Originally Posted by Rmus

Is this what you are asking about?

Yes, thank you. I did read it already, but i was hoping for you guys to further discuss it. You seem to be mixing them in your arguements in this thread, but us simple folks need, well not graphics, but refer exactly to which type you are discussing.

Maybe break it down, like this attack is easily done with like so and so (your firewall method etc.), but this one is the tricky one, that envolves complications.

And where exactly does a local proxy help solve something, where does the Noscript fail (the developer himself seems to agree that some types of XSS will circumvent it), etc.

I probably read some of it already, but slipped by my head.
I'll read it better tomorrow, right now i'm going out .

One thought: an HTTP scanner should detect known attacks no?

Cheers

[Rmus]

Hello Pedro.

The idea of "types of attacks" in the Wikipedia article - Type 0, Type 1, and Type 2 each with technical differences - was new to me. I think that it complicates things, but I addressed them by what information was presented.

For me, it's simpler to understand two scenarios.

1) You are asked to click on a link to go to a secure site and provide information. This falls into "social engineering" and is easily prevented: "Don't Click."

2) You go directly to your secure site, and unknowingly, you are redirected to spoofed site - the "pharming" attack, which can be prevented by the firewall rule discussed. I'm not sure of other ways - there may be.

Elio has demonstrated that the redirecting is no longer necessary, that the legitimate site itself can be compromised by code injection. However, at some point, information from the site has to be sent to the attacker. This is a type of "pharming" and can be prevented as above.

Elio has suggested other scenarios: social networks exploits, forums, etc. I confess to not having much concern about this, so some one else will have to take up preventative measures. Some of what has been written about this seems to fall into the "phishing" category. Or, one could just disable javascript in a social networking site.

And where exactly does a local proxy help solve something, where does the Noscript fail (the developer himself seems to agree that some types of XSS will circumvent it), etc.

I'm ignorant on both of these points, since I don't use either. Maybe someone else can provide information

One thought: an HTTP scanner should detect known attacks no?

I don't know how they work. I am suspicious of the reliabilty of scanners, and prefer to deal with these things in other ways.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[elio]

Originally Posted by Pedro

XSS type 1, 2, etc. What do they imply, how do each happen and how to counter them.

XSS means cross-site scripting, and this term just describes the situation where a script from a certain origin (domain) can evade its original context and run in a different domain.

The whole browser security is based on the so called "same domain policy", i.e. the enforced and strict assumption that a script belonging in a certain domain can access only data coming from the same domain: a script running from "evil-empire.com" should not be able to read data contained in a page from "bankofamerica.com".
The "same domain policy" is so much important that 99% of the development and review work done in the browser security field either is aimed to ensure this policy is always observed with no loopholes, or relies and builds on it being bullet-proof.
So, as long as there are no bugs in the browser code, the bankamerica.com content (possibly my userid and my password while I'm writing them or when they're auto-completed, or my money-transfer form if I'm already logged in and so on) should be unreadable/unwritable/unoperable by malicious sites, right?

Dead WRONG!
The "same domain policy" is very easy to be eluded, if the target site doesn't sanitize properly and exhaustively all the external data coming in with each HTTP request.
XSS is just this: a "same domain policy" subversion exploiting very common web development errors, rather than browser bugs (which are way more difficult to find).

Wikipedia lists type 0, type 1 and type 2, but unless you're an Internet Explorer user, the really interesting kinds are just Reflected (type 1) and Persistent (type 2):

Reflected XSS (type 1)
The kind of the XSS sample originating this thread.
It's called "reflected" because the attacker induces the victim's browser to send an especially crafted request to the vulnerable site, whose response includes (reflects) an attacker's script.

By "induces" most people (and Wikipedia as well) mean "uses social engineering to solicit a click on a malicious link from the human victim". This is a dangerous misconception, because such a level of human interaction is totally superfluous unless attacker is just going out for phishing.
In facts, the browser can be easily "induced", or better "forced", to perform the "especially crafted" request with no need for user consent/awareness, for instance by placing an invisible frame inside an interesting but malicious site, e.g. a porn page or a Bible blog. While user consumes his preferred content, inside the invisible frame automatic navigation silently happens...

By "especially crafted" we mean a request containing data which is rewritten back by the server either literally (with no filter/validations/escaping at all) or after wrong/weak sanitization: either way, the malicious JavaScript code ends to be injected inside the legit page and runs in the context of the legit domain, effectively evading our precious "same domain policy" - heck, we're actually in the right domain after all!

The kind of vulnerability which allows reflected XSS is hugely widespread (according to RSnake, 80% of the web sites are affected).


Persistent XSS (type 2)
This kind of XSS works pretty much like Reflected (malicious code from an alien origin being run in the context of a valuable web site, in conceptual violation of the same domain policy), with one important difference:
the injected code is permanently saved on the web site (like a classic, but invisible defacement), so any visitor of the page gets the same malicious JavaScript, even opening it from a legit bookmark or by manually typing the address in the location bar.
Obviously Persistent XSS, though scary, is much more unlikely than Reflected, because two conditions must be met for a site becoming vulnerable:

1. The site is read/write (e.g. a message board like this one, or a blog with open comments, or any so called "Web 2.0" social network for the matter), i.e. users must be able to post data which is permanently stored and shown to other users.
2. User-generated content is not properly filtered/validated/escaped. This criterion is technically the same as in reflected XSS, but quite harder to be met because even the less skilled programmer is much more careful when handling data that explicitly comes from users, is explicitly meant to be persisted in a database, and explicitly meant to be re-displayed to the general site audience.

Originally Posted by Pedro

Maybe break it down, like this attack is easily done with like so and so (your firewall method etc.), but this one is the tricky one, that envolves complications.

There's no "tricky" or "easy" attack.
Once JavaScript is injected in the vulnerable site, it can do anything the user can do there and cannot be stopped anymore.
Even RMus' firewall method just tackles with one of the multiple exploitation scenarios, i.e. the malicious JavaScript phoning home to store stolen data, but as I tried to clarify in my previous post, there are lots of nasties a JavaScript able to impersonate you in a valuable site can do without leaving the site itself, and so going unnoticed by even the stricter firewall rule.

-- DEFENSE --
Premise: as you probably understand by now, XSS is a problem originated by the web developer. The only ultimate solution is the web developer fixing his vulnerable site (and possibly learning from his errors).

From this true premise, most "security experts" deduce the false claim that users can do nothing to protect themselves.
While the "turn off JavaScript" advice is usually given when a specific browser vulnerability is spotted, we never hear this said aloud for XSS, even if it does work by elementary logic.
Maybe because XSS is not as dangerous as a browser remote execution vulnerability? This is very debatable and increasingly false as the world is embracing the web as its universal platform: if I use my PC just to do online trading, webmail, social networking and web telecommuting, having my web online identity compromised sounds about as bad (or even worse) as being enrolled in a botnet and loosing some bandwidth in mass-spamming.
I'm more inclined to believe that many "security experts" won't dare to tell you "turn JavaScript off" just because the 80% figure reported by RSnake is realistic, if not optimistic: the "security expert" couldn't add "until a patch is released by the vendor", because XSS is everywhere and there to stay. And nobody in his mind would tell people "disable JavaScript everywhere, for ever", right?

That said, even if the standard answer is "no", let's try to ask again
"Is there anything users can do to protect themselves from XSS, out of the obvious turning off JavaScript everywhere, for ever"?

Let's start with Persistent XSS(type 2): answer is "no way".
Once you visit the compromised site, the attack can't be stopped.
All you can do is hoping that the hole is found quickly and patched immediately by the site's owners.
Fortunately, as we already said this kind of vulnerability is quite unlikely to affect a "big fish", especially one whose core business the web itself. No developer there hand codes data validation and sanitization anymore: application frameworks do it better and every major "development tool" vendor now features (and charges for) an "Anti XSS Suite".
For instance, I don't expect any persistent XSS to surface in a Google owned site. And what about Microsoft? Same old news
So, if "even" Microsoft can fall (OK, that was a contractor, but then was it the only outsourced Microsoft site?) the only client-side counter-measure against Persistent XSS is still "keep JavaScript disabled as much as you can, especially on sites featuring user-generated content".

Let's focus on Reflected XSS (type 1) now, the only kind we can still hope, as users, to do something about (other that turning off JavaScript, obviously...)

Originally Posted by Pedro

where exactly does a local proxy help solve something

Nowhere.
Not a proxy as we know it, at least.
To be effective, a local proxy should contain a filter capable to perform all the sanitizations that those lazy/ignorant web developers were unable to implement by themselves.
Most important, this theoretical proxy should be capable of knowing which page originates each request, in order to apply different rules for the following different scenarios:

1. The request is originated by a page in the same domain
   Do not filter. If requests inside the same domain were filtered, I couldn't post anything meaningful in this forum (or anywhere else) because any non-trivial content may disguise an obfuscated script injection, just look at this cheatsheet to have an idea
2. The request is originated by a domain we trust and lands on a domain we trust
   We may prefer to filter or not, but deciding not to filter is becoming harder and harder as "Web 2.0" grows and mashups (sort of "remix" sites which cleverly reuse features from other sites, possibly consolidated in "Web APIs" or "Widgets") are becoming the prevalent kind of "Web 2.0" site. Very common examples of mashup features are Google/Yahoo maps and Google/Yahoo search, which are almost everywhere today. If you filter from trusted to trusted, even trusted mashup sites are very likely to break.
   Most important, several sites (like yahoo or microsoft) should radically change their topology, because today they normally aggregate different domains (e.g. yahoo.com and yimg.com) owned by the same entity and belonging to the same web application.
3. The request is originated by a domain we do not trust and lands on a domain we trust
   DANGER!!! Always filter! this is exactly the typical reflective XSS exploit scenario.
4. The request goes from a trusted domain to an untrusted one
   Why bother to filter? The trusted sites shouldn't originate XSS attacks, otherwise our trust is misplaced.
5. The request goes from an untrusted domain to another untrusted one
   Ditto. No filters needed, because we already do not trust those sites and we shouldn't keep any valuable property there.

So we can layout the following requirements for our proxy:

1. It MUST know the origin and the target of each request
2. It SHOULD maintain a whitelist of trusted sites (otherwise it MUST filter every request involving different domains, which is impractical because it would break all the mashups and the multi-domain sites)
3. It SHOULD block JavaScript on untrusted sites. JavaScript greatly eases attacker's life, and can be used to fuzzify the origin and obfuscate the content of the malicious requests, e.g. by chaining multiple XSS vectors or just exploiting loopholes in javascript: and data: URLs.
   Furthermore, it can be used to tailor an otherwise generic attack so that fits your specific browser or OS, to portscan your PC and your LAN, to review your navigation history in order to choose a likely target site or to efficiently launch multiple simultaneous attacks and/or multiple variants of the same attack, possibly resulting in a DOS of our filter. Last but not least, a new variant of mixed XSS/CSRF recently classified as "AJAX Hijacking" cannot be blocked by any filter because the malicious HTTP request doesn't display any XSS-distinctive marker, but requires JavaScript to be enabled in the attacker site.
   Having JavaScript disabled on untrusted sites also hardens policies #4 and #5 of the previous list, because if the landing site can't run scripts it is invulnerable to XSS by definition.
4. It SHOULD give us a mean to repeat filtered request skipping the filters if we decide they suppressed a false positive

#4 and #3 are both very difficult (if not impossible, depending on the browser-specific architecture) unless our theoretical tool lives inside our browser or can control its UI at least.
#2 is fairly feasible.
#1, the only MUST, is impossible unless our tool live insides our browser (don't say "referer header", most of us suppress it for privacy reasons, and even if we didn't it can be easily suppressed by an attacker using a META refresh or some edgy JavaScript trick).

So the technical MUST prerequisite is that "our AntiXSS local proxy must be a browser plugin or extension", capable of the aforementioned features.

Originally Posted by Pedro

where does the Noscript fail

The developer himself agrees that it can't block XSS type 2 in a trusted site (because you've got JavaScript enabled there), or XSS type 1 from a trusted site to another trusted site, because requests from trusted to trusted bypass filter to permit trusted mashups and multi-domain trusted web applications.
These limitations are quite reasonable and unavoidable, unless you prefer to permanently block JavaScript everywhere: furthermore, they do apply to the theoretical "AntiXSS local proxy" we've just described as well.

And here we are: if you actually analyze Noscript internals, you'll find it implements exactly all the MUST and the SHOULD requirements of our theoretical tool.
So our "AntiXSS local proxy" is not that theoretical: it does exist, after all

Recap:

• Using Noscript gives protection from XSS type 1 and, to a certain extent, from XSS type 2.
  This protection tends to zero if you whitelist everything, and tends to infinite if you don't whitelist anything.
• When in doubt, and the site seems to already work fine or the content doesn't appear that valuable, don't whitelist.
  When in doubt, the content is really valuable and it requires JavaScript (it doesn't work at all otherwise), just "temporary allow".
• The only reason to drop your doubts is the site owner's reputation being such precious that he would refund any amount for damages you may receive from a XSS (which is your problem, but his fault by definition).
  You really don't need JavaScript to take your slashdot fix, read a blog or watch some porn

Originally Posted by Pedro

One thought: an HTTP scanner should detect known attacks no?

No it wouldn't. JavaScript is a dynamic language, it's delivered in textual form, and it's very easy to obfuscate and to be made polymorphic "on the fly".
A signature arms race would be very asymmetric, with JavaScript malicious code in a dominant position.
And if you want my opinion about "detecting known attacks", look at #2 in this enlighting list, which I found often quoted by the developer of Noscript himself (no surprise, if you look at #1).

Cheers
Elio

[lucas1985]

Wow lots of information to digest.
Could Firekeeper be a worthwhile solution (alongside NoScript)?

[Rmus]

Originally Posted by elio

Even RMus' firewall method just tackles with one of the multiple exploitation scenarios, i.e. the malicious JavaScript phoning home to store stolen data, but as I tried to clarify in my previous post, there are lots of nasties a JavaScript able to impersonate you in a valuable site can do without leaving the site itself, and so going unnoticed by even the stricter firewall rule.

As I mentioned, I'm focussing for the moment on just that one scenario.

Until I see working samples of the others (hint) I have nothing to go on. The writeups on some recent examples are not forthcoming at all about the particulars of these exploits.

regards,

-rich

[elio]

Originally Posted by Rmus

Until I see working samples of the others (hint) I have nothing to go on.

You won't trick me into inventing and posting an exploit encyclopedia.
I won't risk jail for your leisure
Just use your imagination. Imagine yourself already logged in a site of your choice, and all the wonderful things you can do without leaving that site. All you're imagining (reading labels, following links, entering data, pushing buttons...) can be done by a reflected XSS JavaScript impersonating you.
Learn JavaScript. Rule the world.
'nuf said

Originally Posted by lucas1985

Could Firekeeper be a worthwhile solution (alongside NoScript)?

Alongside, maybe.
In place of, never.

Firekeeper is a scanner, based on blacklisting rules.
Even if it has an interesting edge over a classic HTTP scanner, i.e. running inside the browser and thus accessing data as the browser sees it, it is still aimed to "detect known attacks":

Originally Posted by Elio

JavaScript is a dynamic language, it's delivered in textual form, and it's very easy to obfuscate and to be made polymorphic "on the fly".
A signature arms race would be very asymmetric, with JavaScript malicious code in a dominant position.
And if you want my opinion about "detecting known attacks", look at #2 in this enlighting list, which I found often quoted by the developer of Noscript himself (no surprise, if you look at #1).

But yes, Firekeeper for the known plus NoScript for the unknown sounds like a tough combo

[lucas1985]

Thanks elio
So, it seems that XSS is a huge and worldwide risk which recently has started to receive attention and solutions.

[Pedro]

Hey Elio, what a post! Thanks

Originally Posted by elio

No it wouldn't. JavaScript is a dynamic language, it's delivered in textual form, and it's very easy to obfuscate and to be made polymorphic "on the fly".
A signature arms race would be very asymmetric, with JavaScript malicious code in a dominant position.
And if you want my opinion about "detecting known attacks", look at #2 in this enlighting list, which I found often quoted by the developer of Noscript himself (no surprise, if you look at #1).

It was a dumb question, but not for the reason you think. I was simply asking, since it is code, it can be blacklisted just as a virus or trojan. I was not asking for an opinion on AV's, or if default allow is a nice strategy .
It was another question to get the point.

OK, to finish, 2 bold statements to induce further clarifying replies:

Noscript is an excellent tool for reflective/ type 1 xss exploit. Supposing all the right choices by the user when whitelisting, this is a non-issue.

Persistent should really be about my trust regarding the web developer. My bank should not have any holes, that coupled with noscript, there is no danger- Supposing if you will that i start a new browser session just to go to bank (not necessary if noscript is well whitelisted- but what is that anyway..). This also supposes that the only risk is my money in the bank. I don't know where are the other risks, besides privacy.

[elio]

Sorry for a late answer, very busy week (and not finished yet )

Originally Posted by Pedro

Noscript is an excellent tool for reflective/ type 1 xss exploit. Supposing all the right choices by the user when whitelisting, this is a non-issue.

Right.
The Noscript feature I prefer over other "blocking" solutions is that it doesn't prompt you for whitelisting, so lazyness and hurry (user's "inertia") play against long whitelists: the completely clueless user hitting an untrusted site which requires JavaScript will most likely believe it's broken and leave it alone.

Originally Posted by Pedro

Persistent should really be about my trust regarding the web developer. My bank should not have any holes, that coupled with noscript, there is no danger.

As I said, persistent XSS vulnerabilites are unlikely on high-profile sites, but reflected XSS happens everywhere:
Sparkasse Bank and many financial subsidiaries

Originally Posted by Pedro

The only risk is my money in the bank. I don't know where are the other risks, besides privacy.

Privacy == Money, depending on how much stuff you do online.
And I bet this "how much" can only grow in time, like it or not.
Using Noscript is just common sense: we all keep our front doors closed and check who's knocking before opening.

[elio]

Just noticing the vulnerability is still there, nice and exploitable, 2 weeks after my original post.
Looks like Zone Alarm people can't read their own logs

[Pedro]

Originally Posted by elio

Just noticing the vulnerability is still there, nice and exploitable, 2 weeks after my original post.
Looks like Zone Alarm people can't read their own logs

You mean they weren't voluntarily cooperating?

[elio]

Originally Posted by Pedro

You mean they weren't voluntarily cooperating?

Uh? giving away their users' accounts voluntarily?!

As I said before, I took mario's original PoC here: it's a full disclosure forum thread closely watched by all the major internet players (lurkers from Google, Yahoo, Mozilla...), and mario may or may not have contacted Zone Alarm directly about its findings.

At any rate, a "security firm" which does not care about securing its customer area or at least watching its server logs for "strange" activity looks a bit weird, doesn't it?

[Rmus]

Originally Posted by elio

At any rate, a "security firm" which does not care about securing its customer area or at least watching its server logs for "strange" activity looks a bit weird, doesn't it?

Hello elio,

I've gotten a bit behind with this thread - can you enlighten me:

Since this happens by using a direct spoofed link to ZA, how would a normal ZA user encounter this link?

If I understood what you explained earlier, this appending to a URL could inject the XSS code on any Login Page, so it's not clear to me why this should be limited to ZA.

regards,

-rich

[elio]

Originally Posted by Rmus

Hello elio,

I've gotten a bit behind with this thread - can you enlighten me:

Since this happens by using a direct spoofed link to ZA, how would a normal ZA user encounter this link?

Of the many exploitation scenarios, I will list just 3 because I'm lazy today:

1. Social engineering: the fact it works is demonstrated by this very topic, where many people followed my link even if it was not particularly crafted to be believable (it was quite suspect, indeed)
2. Spoofed email, just like in any phishing scheme but with the distinctive advantage that the link is actually a real ZoneAlarm URL to a real (not spoofed!) ZoneAlarm page: the JavaScript part I left "in clear" for didactic purposes can be effectively and easily obfuscated, but anyway all the adverted humans and the automatic security scanners (e.g. antiphishing toolbars) are trained to look in the URL is its domain.
3. Last but not least, if just one precondition among "automatic completion enabled", "user already logged in" or "persistent authentication cookie (AKA Remember me)" is met, the victim doesn't even need to interact with the injected page or follow any link, as all the action can happen silently inside an invisible iframe (embedded either in a porn site, in a bible blog, in a MySpace page -- very very easy!!! -- or in an incoming HTML email message)

Originally Posted by Rmus

If I understood what you explained earlier, this appending to a URL could inject the XSS code on any Login Page

On any vulnerable page, not necessarily a login page: once you're inside the domain you can navigate wherever you want.
"Vulnerable" means that some of the incoming data is echoed back not properly escaped/sanitized.
In other words, a lame/unaware/distracted/tired/undermotivated/underpaid/nameyouwhatbutinadequate web developer is needed to have a XSS vulnerability, but as you can see this requirement is commonly met.

Originally Posted by Rmus

so it's not clear to me why this should be limited to ZA.

In facts, it's not limited to ZA at all.
It's just funny that ZA, whose whole business is about security, hires and (under?)pays lame/unaware/distracted/etc. developers.
Well, after all it may mean that even average/above-average developers can fall...

[Rmus]

Hello elio,

Well, I purposely said "normal ZA" user because I would not expect them to fall for scenarios #1,#2. So I was expecting something different...

Even #3. Not using "auto-completion" myself, even discouraging those I help from doing so, I find it strange that security-knowledgeable users would do that these days.

Originally Posted by elio

It's just funny that ZA, whose whole business is about security, hires and (under?)pays lame/unaware/distracted/etc. developers. Well, after all it may mean that even average/above-average developers can fall...

Well, maybe you can do a good deed and make them aware of their shortcomings!

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier