InformAction Forums

Since the last update of NoScript I have been unable to access VM webmail in Firefox; but can get in via IE7.

The sign in page works but when it gets directed to the Gmail site I get the following message in the yellow line at the top.

NoScript filtered a potential cross-site scripting (XSS) attempt from [https://identity.virginmedia.com]. Technical details have been logged to the Console.

Looking in the Console it appears that the Gmail page is being blocked by dozens of simple HTML commands resulting in reports relating to 'text overflow', etc. I'm not an expert on programming so not too sure what it is doing.

Also I cannot see any simple way of allowing access to the Virgin Media Gmail page.

Any ideas?

Thanks,

Mike.

Update...

Just disabled the XSS detection at NoScript/Options/Advanced/XSS; unticked the 2 check boxes and I can get into VM webmail again.

Not sure why a trusted site like VM would flag up this warning though?

Mike.

Could you please enable those back and look, when the issue happens again, for [NoScript XSS] lines in Tools|Error Console?
I need to examine them in order to tell what's going on and, if it's a false positive, whether I can work-around it in the code.

Not sure why a trusted site like VM would flag up this warning though?

XSS checks are independent from permission checks (and rightly so).

I'm getting the same issue.

The majority of the messages state the that mail.ntlworld.com, identity.virginmedia.com and www.virginmedia.com are potentially vulnerable to CVE-2009-3555

There is also a large block of text which is the "sanitised suspicious upload"

Update:

Unchecking the "Turn cross-site POST requests into data-less GET requests" checkbox allows me to log into the site without any problems.

Asking the site to reload the page pops up a dialog explaining it will unsafely reload a post frmo https://identity.virginmedia.com to https://www.google.com

Is there an easy way of adding to the XSS Protection Exceptions?

goldenhornet wrote: The majority of the messages state the that mail.ntlworld.com, identity.virginmedia.com and http://www.virginmedia.com are potentially vulnerable to CVE-2009-3555

This message is from Firefox, not from NoScript.

goldenhornet wrote: There is also a large block of text which is the "sanitised suspicious upload"

As I said above, I'd need to see the [NoScript XSS] line(s) you get in Tools|Error Console when this happens.

Still would help to post the Error Console message.

(The CVE-2009-3555 entries should be immaterial to this problem.)

Ok, I didn't see you could just type into the Exceptions text area

I've added ^https://www\.google\.com/a/ntlworld\.com/acs to the exceptions and all is groovy

I've unencoded the posted script and it looks like it's posting a signed xml document from the identity service to Google. I've replaced some of content of the message for obvious reasons.

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ID="**some stuff here**" IssueInstant="2010-06-14T12:14:16Z" Version="2.0">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n- ... thComments" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>**some stuff here**</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>**some stuff here**</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>
**some stuff here**
</P>
<Q>**some stuff here**</Q>
<G>
**some stuff here**
</G>
<Y>
**some stuff here**
</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="**some stuff here**" IssueInstant="2003-04-17T00:46:02Z" Version="2.0">
<saml:Issuer>virginmedia.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress">**some stuff here**</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData Recipient="https://www.google.com/a/ntlworld.com/acs" />
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2010-06-14T13:13:16Z" NotOnOrAfter="2010-06-14T15:15:16Z" />
<saml:AuthnStatement AuthnInstant="2010-06-14T14:14:16Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="twAccountID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">**some stuff here**</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="vmUserID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">**some stuff here**</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="twSiteID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">**some stuff here**</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="vmLoginID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">**some stuff here**</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

Hi all,

As mentioned by golden hornet just adding...
https://www.google.com/a/virgin.net/acs
to the exceptions on the Advanced XSS page cured it.

Thanks to all who had posted about this problem.

Mike

Hi

I've been haviong the same problem with a blueyonder.co.uk address. I've followed the suggestion above and added these to the XSS exceptions list

https://www.google.com/a/blueyonder.co.uk/acs
^https://www\.google\.com/a/blueyonder\.co\.uk/acs

but the page just bounces back and forth between the VM "thank you" page and the Google address above

Any ideas?

Cheers

Mark

M wrote: but the page just bounces back and forth between the VM "thank you" page and the Google address above

In order to help you, I really really need to see the [NoScript XSS] lines appearing in your Tools|Error Console when the problem happens.

I'm having the same problem. The section of the error log I think you're interested in, Giorgio, is this:

[NoScript XSS] Sanitised suspicious upload to [https://www.google.com/a/blueyonder.co. ... %3E%0D%0A+] from [https://identity.virginmedia.com/vm_sso ... lcache%3D2]: transformed into a download-only GET request.

The only change I've made is to replace the string that represents my email address. I hope this is enough for you to work out why NoScript complains when I try to access my Virgin Media WebMail.

Many thanks,

J21

@janus21:
Should be fixed in latest development build, thanks.

Tested with the development build, as suggested, and access to the Virgin Media webmail site is working fine.

Thanks very much,

J21

P.S. But I've reverted back to the latest production version, because with the development build I don't get the Satus Bar icon and, therefore, can't control or vary things for new sites. I'm assuming whatever was changed will be incorporated into the next live version and will wait for its release.

Thanks again,

J21

P.P.S. Apologies - I was too quick to jump to conclusions. One of my other Add-Ins was interfering. Disabling them all then re-enabling a sub-set means everything works as it should. Just need to work out which is the culprit and remove/report it.