InformAction Forums

I am trying to log in to my account at https://www.ameriprise.com/default-client.asp. I have ameriprise.com in the NoScript Whitelist of trusted sites. I enter my User ID and Password and press the login button. NoScript responds that it “filtered a potential cross-site scripting (XSS) attempt from [https://my.ameriprise.com]”.

Software involved: Windows 7 SP1 64-bit, Firefox 28.0, NoScript 2.6.8.19.

When I look at the NoScript Console I see the following information:

[NoScript InjectionChecker] JavaScript Injection in///client/SmMakeCookie.ccc?SMSESSION=$SM$qg
(other Console stuff deleted)
&TARGET=$SM$https://my.ameriprise.com/FinancialAcco ... myaccounts
(function anonymous() {
SMSESSION=$SM$qg
(other Console stuff deleted)
[NoScript XSS] Sanitized suspicious request. Original URL [https://sso.ameriprise.com/client/SmMak ... ION=$SM$qg
(other Console stuff deleted)
&TARGET=$SM$https%3a%2f%2fmy%2eameriprise%2ecom%2fFinancialAccounts%2fhtml%2fSECURELOGINRESPONSE%2eHTML%3ftargetURL%3dhttps%3a%2f%2fmy%2eameriprise%2ecom%2faccess%2fauthreg%2fmyaccounts] requested from [https://my.ameriprise.com/FinancialAcco ... LOGIN.HTML].
Sanitized URL: [https://sso.ameriprise.com/client/SmMak ... %24SM%24qg
(other Console stuff deleted)
&TARGET=%24SM%24https%3A%2F%2Fmy.ameriprise.com%2FFinancialAccounts%2Fhtml%2FSECURELOGINRESPONSE.HTML%3FtargetURL%20https%3A%2F%2Fmy.ameriprise.com%2Faccess%2Fauthreg%2Fmyaccounts#7986593539932367908].

The two URLs visible in the Console are my.ameriprise.com and sso.ameriprise.com, both of which belong to the same trusted domain ameriprise.com.

I choose the XSS|Unsafe Reload command to force the request through (since I can’t see anything unsafe going on) and NoScript displays the following additional information:

ET [https://sso.ameriprise.com/client/SmMak ... ION=$SM$qg
(other displayed stuff deleted)
qzPI
[...]
KN
(other displayed stuff deleted)
LM&PERSIST=0
&TARGET=$SM$https%3a%2f%2fmy%2eameriprise%2ecom%2fFinancialAccounts%2fhtml%2fSECURELOGINRESPONSE%2eHTML%3ftargetURL%3dhttps%3a%2f%2fmy%2eameriprise%2ecom%2faccess%2fauthreg%2fmyaccounts]
FROM [https://my.ameriprise.com/FinancialAcco ... LOGIN.HTML]

What is the safety issue that NoScript sees here? How can I configure it to accept the issue and really trust ameriprise.com?

Thanks for your help.
Bob Vavra

rdvavra wrote:What is the safety issue that NoScript sees here?

it thinks that my.ameriprise.com is trying to run some scripts in the context of (IOW "hijack") sso.ameriprise.com

rdvavra wrote:How can I configure it to accept the issue and really trust ameriprise.com?

see the xss sticky in this forum

Thanks, barbaz, for pointing me toward a fruitful path. As a newbie it took me a while to decode “see the xss sticky in this forum.” I assume you meant the support topic “Re: Need help with XSS resp it's RegEx.” Since I saw no visible indication that the topic is sticky, and since the topic focuses on constructing a regular expression rather than XSS more generally, I did not immediately identify it as my desired path.

I have now constructed a regular expression regarding my.ameriprise.com and added it to the Anti-XSS Protection Exceptions so I can log in without triggering any warnings. Thanks for your help.

Please accept the following additional feedback. My reading of the available NoScript documentation indicates that I should not have had to create an Exception regular expression to resolve this matter. The FAQ sections 4.1 and 4.2 http://noscript.net/faq#qa4_1 say that Anti-XSS is to prevent untrusted sites from injecting JavaScript code into a trusted web page. Section 4.2 suggests that a user (temporarily) trust a source site to avoid the Anti-XSS warning, and that as a last resort a geek user can create an Exception regular expression to avoid the Anti-XSS warning.

The two sites involved are my.ameriprise.com and sso.ameriprise.com. Not only are they both trusted, but they are both part of the same trusted domain ameriprise.com. The notion that ameriprise.com would try to “hijack” ameriprise.com is rather odd. NoScript should recognize this situation and be more lenient about it.

If there is a reason for NoScript to continue its current behavior, then the documentation at http://noscript.net/features#xss and the FAQ at http://noscript.net/faq#qa4_1 should be updated to describe this situation more fully. They should also describe the ability to create a regular expression that matches a trusted origin site (prefixed with "@") which seems safer than opening up a trusted target site to any and all comers. The more help you can give geeks and partial-geeks in constructing a safe minimal regular expression based on the information in the Console, the more likely we are to avoid real injection attacks.

Thanks for listening.

rdvavra wrote:Since I saw no visible indication that the topic is sticky

It shows up as a lightbulb icon instead of the usual circle.

I have now constructed a regular expression regarding my.ameriprise.com and added it to the Anti-XSS Protection Exceptions so I can log in without triggering any warnings. Thanks for your help.

Would you like to post it here so that others can review it? When it comes to regex, it's wise to have many eyes.

The FAQ sections 4.1 and 4.2 http://noscript.net/faq#qa4_1 say that Anti-XSS is to prevent untrusted sites from injecting JavaScript code into a trusted web page.

Yes, it's a very dangerous kind of attack.

Section 4.2 suggests that a user (temporarily) trust a source site to avoid the Anti-XSS warning, and that as a last resort a geek user can create an Exception regular expression to avoid the Anti-XSS warning.

When you whitelist a site, it gets much more lenient treatment. Instead of throwing out anything vaguely suspicious, NoScript will apply advanced filtering to requests. The fact that it still triggered the filter means that it looks a lot like an attack (even though it may not be one).

The two sites involved are my.ameriprise.com and sso.ameriprise.com. Not only are they both trusted, but they are both part of the same trusted domain ameriprise.com. The notion that ameriprise.com would try to “hijack” ameriprise.com is rather odd. NoScript should recognize this situation and be more lenient about it.

I'm not certain of NoScript's (default?) behavior regarding subdomains. However, bear in mind that there are lots of situations where the owners of subdomains are different. Blogspot, for example.

If there is a reason for NoScript to continue its current behavior, then the documentation at http://noscript.net/features#xss and the FAQ at http://noscript.net/faq#qa4_1 should be updated to describe this situation more fully.

Well, actually in this situation it's not a bad thing for you to come here and discuss it with us .

Bear in mind that Giorgio usually wants to know about false positives, so that he can try to improve the filter.

Thrawn wrote:Would you like to post [the regular expression] here so that others can review it? When it comes to regex, it's wise to have many eyes.

I believe my regular expression ^@https://my\.ameriprise\.com/ means that NoScript will allow my.ameriprise.com as an origin site to inject Javascript code into any trusted target site. Since I rarely follow links from ameriprise to other sites, that seems relatively safe to me. More safe than if I were to allow sso.ameriprise.com to be a target for Javascript injection from any other trusted site (over 100 whitelisted sites and growing).

I'm not certain of NoScript's (default?) behavior regarding subdomains. However, bear in mind that there are lots of situations where the owners of subdomains are different. Blogspot, for example.

I did think about this. My whitelist includes several explicit sub-domain names such as crypto-js.googlecode.com and ebook.3m.com. But when I first went to www.ameriprise.com, before I tried to log in, NoScript offered me the chance to Allow ameriprise.com and I did. So I have (perhaps thoughtlessly) declared that my.ameriprise.com and sso.ameriprise.com should be treated as a single trusted entity. The NoScript features page http://noscript.net/features#sitematching does discuss this, but I haven't studied it yet.

Bear in mind that Giorgio usually wants to know about false positives, so that he can try to improve the filter.

Thanks. I leave it in his capable hands.

Thrawn wrote:Bear in mind that Giorgio usually wants to know about false positives, so that he can try to improve the filter.

speaking of which, FWIW this is the second forum topic about financial login sites that use "SmMakeCookie.ccc" triggering the XSS filter that I've seen

rdvavra wrote: ^@https://my\.ameriprise\.com/ means that NoScript will allow my.ameriprise.com as an origin site to inject Javascript code into any trusted target site.

Looks good. Kudos for escaping the dots and ending with a slash.

I have (perhaps thoughtlessly) declared that my.ameriprise.com and sso.ameriprise.com should be treated as a single trusted entity.

For ameriprise.com, that may be fine. It just wouldn't be a good global NoScript behavior.