4

When I make an online payment using 3DSecure (Verified by Visa or Mastercard Securecode), NoScript informs me that it has stopped a potentially insecure script where site A (the bank or the credit card company) attempts to run a script with the destination at site B (the merchant) using Cross-site scripting (XSS).

NoScript tells me I can whitelist the destination site (the merchant) if I am very confident the target web page is immune to XSS vulnerabilities. Although I'm quite confident the originating site is safe, I am less confident about the destination site. I have added the merchant to the whitelist anyway, because I needed to book a train ticket. As a customer, what risks am I exposed to by adding the merchant to the whitelist? Can someone steal my credit card details?

2
+50

3D Secure is a fraud-prevention system:

3-D Secure XML-based protocol designed to be an additional security layer for online credit and debit card transactions. It was originally developed by Arcot Systems, Inc and first deployed by Visa with the intention of improving the security of Internet payments and is offered to customers under the name Verified by Visa.

And your concern:

NoScript informs me that it has stopped a potentially insecure script

It's most likely not an actual XSS attack.

This "XSS redirect" happens because the payment page on the website in question is redirecting you to a payment gateway. It is a redirect, yes, and it could be used to attack you yes, but!

  1. You should check for the green padlock in your URL bar on the website you're purchasing from. If there's no green padlock, do not even enter your details.
  2. When you submit the payment, you can see where it's redirecting you, as NoScript gives you a warning. Have you verified that the URL belongs to 3DSecure?
    • Unless the attacker has access to your machine, and is able to modify the NoScript plugin to report the wrong URL, then you should be fine. However, if an attacker has access to your machine, there are bigger things you need to worry about.

Note that in many cases, ignoring the XSS redirect (refusing to "Unsafe Reload") still allows the payment to go through for me. I am unaware if this is the case on the website you're visiting.


Potential risks

As a customer, what risks am I exposed to by adding the merchant to the whitelist? Can someone steal my credit card details?

It really comes down to the security of each site.

If you use https, and the certificates are properly issued, a man-in-the-middle attack is highly unlikely.

These https certificates will validate that you are on the correct website while encrypting your connection to/fro. However, your data is only as safe as both websites that handle it. If there's a vulnerability in either website, even if the certificates are valid, it might be possible for your data to be stolen.

It's definitely possible for a website to be hacked, and for data to be gathered on the inside, and then accessed later on. However, most credit card companies promise zero fraud liability. Does yours? While this won't prevent your personal information from getting out, it at least offers some mitigation in the event of a breach.


Should I worry about NoScript's anti-XSS warning here?

It depends. Does everything check out? Green padlocks in your URL bar? Generally, there is no need to worry. However, if either of the websites in question are breached, then no... you can't trust either website at that point.

1

I don't think this can be answered in a general sense - this is probably more of a comment, but too long to fit as one. It is too dependent on the configuration of the merchant, the bank, and the relationship between them.

For example, if the merchant stores your credit card number when you make a purchase, and has an XSS vulnerability which allows an attacker to read data from the page where you confirm your CVV number, an attacker could obviously get your CVV number. However, if the merchant is PCI compliant (which they should be), the attacker shouldn't be able to get your credit card number from this same vulnerability - the merchant should never output the full card number. If they had an XSS vulnerability that allowed them to monitor the data entered on the card entry screen, though, they might be able to steal your card number, even if it is then not stored for longer on the site.

3DSecure doesn't really change that, but adds a layer of verification that the bank can use to say "look, someone entered the letters of your 3DSecure password, which only you know, therefore it must have been you". In some ways, this actually causes further problems - if an attacker can find a vulnerability in the merchant payment system that causes a fake 3DSecure window to pop up, they could get you to enter letters from your password in a way which is difficult for a casual user to detect (iframes don't have URL bars...). Importantly, 3DSecure isn't about computer security. It's about fraud.

  • 1
    Strangely, the 3DSecure layer (Verified by Visa) for this card/bank doesn't ask any password or verification information. It just flashes something to the screen for several seconds, then redirects back to the merchant website, which then says Approved. Except now it doesn't, because of Noscript. – gerrit Feb 12 '16 at 14:57
  • 1
    Oh, one of those. I have one card that does that. Seems a bit pointless really - that's even easier to fake than the type in version! – Matthew Feb 12 '16 at 14:58
  • @gerrit That is pretty much how Verified by Visa works. What Matthew means is that the password is sent by the website in question, such as a key that "confirms" they are the correct host and therefore allowed to send such a request to VBV. – Mark Buffalo Feb 12 '16 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.