InformAction Forums

by **Tom T.** » Mon May 07, 2012 12:56 am

Thrawn wrote:And when I write pages (I'm not primarily a web programmer), I'm always mindful of the need to sanitise output.

But not inputs?

by **Thrawn** » Mon May 07, 2012 12:44 am

Tom T. wrote:Since your profile here is publicly viewable, it is not a secret that you're a programmer/analyst yourself. Please tell me you'd never code a site so poorly that *navigating within the same site* (especially a secure one ) would produce XSS messages...

Well, I'm pretty sure I'd notice if something that I was writing was obviously XSS...and since I always use NoScript, I'd definitely notice if something that I wrote triggered its XSS filters

.

And when I write pages (I'm not primarily a web programmer), I'm always mindful of the need to sanitise output.

by **Tom T.** » Sun May 06, 2012 11:48 pm

Thrawn wrote:
Tom T. wrote:Thrawn, please see ABE Rules .pdf, section 1.3. As I read it, it does in fact differentiate literals from regular expressions. See if it doesn't read that way to you also, thanks.
ABE rules can have literals, yes, but we're talking about InjectionChecker exceptions.

I get so many ABE questions vs. XSS that It seems ABE was on my mind.

(Slight face-saving: You came up with an ABE rule also, and a good one.)

I hope that's my one big mistake for the day. Now, just two little ones, and I'm good. :lol:

(Thanks for the catch. Many eyes = fewer errors.)

ETA: I'd love to hear the site's reply to an inquiry, but the most frequent answer is "Use another browser." :evil:

Since your profile here is publicly viewable, it is not a secret that you're a programmer/analyst yourself. Please tell me you'd never code a site so poorly that *navigating within the same site* (especially a secure one

) would produce XSS messages...

[rant] Lazy, sloppy, or downright incompetent site designers seem to be pandemic -- and IMHO, banks and financial institutions are the worst. [/rant]

by **Thrawn** » Sun May 06, 2012 11:19 am

Tom T. wrote:Thrawn, please see ABE Rules .pdf, section 1.3. As I read it, it does in fact differentiate literals from regular expressions. See if it doesn't read that way to you also, thanks.

ABE rules can have literals, yes, but we're talking about InjectionChecker exceptions.

Looking at the Advanced-XSS options, which allows you to test your exceptions, I can confirm that an exception for

Code: Select all: http://www.example.com

will also whitelist

Code: Select all: http://www-example.com http://www.example.com.cn https://www.vulnerable-site.com?foo=http://www_example_com&bar=xssAttackGoesHere

The last is the most concerning; it means that a literal-string exception becomes essentially a tag that an attacker can use to switch off InjectionChecker...of course, that assumes an attacker with specific knowledge of his victim's NoScript configuration, but still, it's not what we want.

Tom T. wrote:
Thrawn wrote:By the way, are you confident that the sites in question are actually immune to XSS? Their regular traffic may be a false positive, but are you sure that a real XSS attack would be sanitised?
If not, then you may want to:
Tighten up the XSS exception so that it exactly matches legitimate requests, eg
Code: Select all
^https://billpay\.schwab\.com/path/to/legitimate/request\.htm
Protect the sites with an ABE rule like:
Code: Select all
Site .schwab.com Accept from SELF++ Deny
Contact the webmaster to ask them why their traffic looks like an XSS attack. Actually, you might want to question that anyway.

All excellent points, thanks. Especially the last one.

Thanks

by **Tom T.** » Sat May 05, 2012 10:08 pm

Thrawn, please see ABE Rules .pdf, section 1.3. As I read it, it does in fact differentiate literals from regular expressions. See if it doesn't read that way to you also, thanks.

Thrawn wrote:By the way, are you confident that the sites in question are actually immune to XSS? Their regular traffic may be a false positive, but are you sure that a real XSS attack would be sanitised?
If not, then you may want to:
Tighten up the XSS exception so that it exactly matches legitimate requests, eg
Code: Select all
^https://billpay\.schwab\.com/path/to/legitimate/request\.htm
Protect the sites with an ABE rule like:
Code: Select all
Site .schwab.com Accept from SELF++ Deny
Contact the webmaster to ask them why their traffic looks like an XSS attack. Actually, you might want to question that anyway.

All excellent points, thanks. Especially the last one.

by **Thrawn** » Sat May 05, 2012 11:21 am

By the way, are you confident that the sites in question are actually immune to XSS? Their regular traffic may be a false positive, but are you sure that a real XSS attack would be sanitised?
If not, then you may want to:

Tighten up the XSS exception so that it exactly matches legitimate requests, eg
Code: Select all
^https://billpay\.schwab\.com/path/to/legitimate/request\.htm
Protect the sites with an ABE rule like:
Code: Select all
Site .schwab.com Accept from SELF++ Deny
Contact the webmaster to ask them why their traffic looks like an XSS attack. Actually, you might want to question that anyway.

by **Thrawn** » Sat May 05, 2012 11:12 am

Tom T. wrote:Literals should work here:
Code: Select all
https://client.schwab.com https://billpay.schwab.com

Does that fix it?

AFAICT, those should work. The only downside of literals is that I think they're still treated as regular expressions, so the dots will actually match *any* character, and you haven't used the start-of-expression character ^. So you'd also be whitelisting eg

Code: Select all: https://client_schwab.com https://billpay-schwab.com http://www.example.com?foo=https://client.schwab.com

If you want to tighten this up, the regular expression versions would be:

Code: Select all: ^https://client\.schwab\.com ^https://billpay\.schwab\.com

by **Tom T.** » Sat May 05, 2012 2:33 am

Guest544 wrote:The site I normally pay my bills through (schwab.com) has updated their site and now the XSS feature prevents it from transitioning to the billpay site. It appears that instead of using a direct HTML link, they are now using a javascript drop down menu (which is why this is a problem now).

First, are *both* sites marked as trusted? See FAQ 4.2 for the stricter restrictions applied to sites not marked as trusted.

Guest544 wrote:I am familiar with the InjectionChecker engine, however, I still want it to check my whitelisted sites, just not the site in question. So the only other solution is to add it as a regular expression.

The site that pops up in question is "client.schwab.com" and is directing me to "billpay.schwab.com". From what I read about regular expressions, it sounds like I just need to add it for "schwab.com".

Since I don't have an account there, I can't test thoroughly, but did notice that the site is HTTPS-secured, as it should be.
To play it safe, why not include that, to prevent any non-HTTPS site from trying to slip by? (Maybe I'm overly cautious?)

Literals should work here:

Code: Select all: https://client.schwab.com https://billpay.schwab.com

Does that fix it?

by **Guest544** » Fri May 04, 2012 11:07 pm

The site I normally pay my bills through (schwab.com) has updated their site and now the XSS feature prevents it from transitioning to the billpay site. It appears that instead of using a direct HTML link, they are now using a javascript drop down menu (which is why this is a problem now).

I am familiar with the InjectionChecker engine, however, I still want it to check my whitelisted sites, just not the site in question. So the only other solution is to add it as a regular expression.

The site that pops up in question is "client.schwab.com" and is directing me to "billpay.schwab.com". From what I read about regular expressions, it sounds like I just need to add it for "schwab.com".

If someone could help me out with this, I would greatly appreciate it.

InformAction Forums

Site-specific XSS question (regular expression)

Post a reply

Expand view Topic review: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Re: Site-specific XSS question (regular expression)

Site-specific XSS question (regular expression)