Site-specific XSS question (regular expression)

[Guest544]

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.

[Tom T.]

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.

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?

[Thrawn]

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

[Thrawn]

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:

1. 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

2. Protect the sites with an ABE rule like:

   Code: Select all

   Site .schwab.com
   Accept from SELF++
   Deny

3. Contact the webmaster to ask them why their traffic looks like an XSS attack. Actually, you might want to question that anyway.

[Tom T.]

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.

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:

1. 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

2. Protect the sites with an ABE rule like:

   Code: Select all

   Site .schwab.com
   Accept from SELF++
   Deny

3. 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.

[Thrawn]

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.

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:

1. 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

2. Protect the sites with an ABE rule like:

   Code: Select all

   Site .schwab.com
   Accept from SELF++
   Deny

3. 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

[Tom T.]

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.
(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."

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]

[Thrawn]

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.

[Tom T.]

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?