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
Why Anti-XSS for two sites in the same trusted domain?
Why Anti-XSS for two sites in the same trusted domain?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Re: Why Anti-XSS for two sites in the same trusted domain?
it thinks that my.ameriprise.com is trying to run some scripts in the context of (IOW "hijack") sso.ameriprise.comrdvavra wrote:What is the safety issue that NoScript sees here?
see the xss sticky in this forumrdvavra wrote:How can I configure it to accept the issue and really trust ameriprise.com?
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26
Re: Why Anti-XSS for two sites in the same trusted domain?
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.
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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Re: Why Anti-XSS for two sites in the same trusted domain?
It shows up as a lightbulb icon instead of the usual circle.rdvavra wrote:Since I saw no visible indication that the topic is sticky
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.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.
Yes, it's a very dangerous kind of attack.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.
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).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.
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.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.
Well, actually in this situation it's not a bad thing for you to come here and discuss it with us .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.
Bear in mind that Giorgio usually wants to know about false positives, so that he can try to improve the filter.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
Re: Why Anti-XSS for two sites in the same trusted domain?
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).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 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.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.
Thanks. I leave it in his capable hands.Bear in mind that Giorgio usually wants to know about false positives, so that he can try to improve the filter.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Re: Why Anti-XSS for two sites in the same trusted domain?
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 seenThrawn wrote:Bear in mind that Giorgio usually wants to know about false positives, so that he can try to improve the filter.
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26
Re: Why Anti-XSS for two sites in the same trusted domain?
Looks good. Kudos for escaping the dots and ending with a slash.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.
For ameriprise.com, that may be fine. It just wouldn't be a good global NoScript behavior.I have (perhaps thoughtlessly) declared that my.ameriprise.com and sso.ameriprise.com should be treated as a single trusted entity.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0