7 ms·

Major sites running unauthenticated JavaScript on their payment pages

214 points by edent 8y ago

wazoox 8y ago
I am so old school, but I only use local installation of 3rd party tools and libraries. That means I have to update them, but that also means that no hidden update will break my site or worse, introduce vulnerabilities.
stabbles 8y ago
Is there a good browser plugin that tracks changes to sources of js files? That way you could mark certain sources as trusted, but whenever they change, they would be blocked until you mark them as trusted again.
- O_H_E 8y ago
  But how is it going to know the authentic source?
  - fredley 8y ago
    The source doesn't matter, only the content. If the hash of the file matches the hash you've already approved for jquery-3.3, then the file is (unless someone's found a collision in the hashing algorithm that hasn't been disclosed) jquery-3.3.
    - sprt 8y ago
      I think what they meant is how do you identify the authentic content the first time around?
      - throwaway899 8y ago
        By manually reviewing the said file or by trusting a central authority of some sort.
- fredley 8y ago
  This would be really neat, and not that hard to build from what I know about building extensions. Basically just store a hash of file, whenever external files are loaded see if their hash exists in your list, if not block it from loading until it's been reviewed. As an extra (paid-for?) feature hook into an online system that keeps track of hashes of known-good popular libs, and can mark as untrusted when a vulnerability is found with a version of e.g. jQuery and auto-flag that for users.
- paraditedc 8y ago
  And how do you know the browser plugin source code have not changed?
  - danShumway 8y ago
    In Firefox you can turn off updates for individual plugins, so you only need to trust Mozilla and the extension author once. Chrome is currently looking into getting rid of the ability for extension authors to obfuscate code -- minification is the highest level of obfuscation they'll accept now, and (opinion me) minified Javascript code is not that hard to read. Chrome does still need to get on the "let people turn off automatic updates" train though. But I'm not sure what to tell you about that -- you should not be running Chrome as your main browser anyway if you care about security/privacy. I'm not sure if Mozilla is planning to follow suite on blocking obfuscation. Assuming they are, if you don't trust the extension author even for the initial download, install the extension, read through the source code natively on your own computer, and then set it to not update after that point. It would be better if you could download the unminified/unbundled source code and install the extension yourself locally, but for whatever reason Firefox and Chrome have decided that's insecure. I feel the opposite, since requiring signed extensions makes it harder for me to audit code or place additional safeguards around that code, but... eh, what do I know? In any case, the current situation for extensions on Firefox is not all that different from installing something in a standard software repository.
    - O_H_E 8y ago
      >if you could download the unminified/unbundled source code and install the extension yourself locally Do you mean for a proprietary extension? AFAIK loading sources locally works fine in chrome.
      - danShumway 8y ago
        In Firefox, loading unsigned extensions is severely restricted. It's a separate process to install them, and they'll only last until you restart the browser. I'm not sure what Chrome's specific rules are; I think they allow loading local sources in dev mode, but warn you about it every time the browser launches? I generally advise people to avoid Chrome if they care about security/privacy anyway, so I've never checked in detail. But if Chrome does have a way for you to easily load extensions from source, and you're comfortable using it as a main browser, that could be a valid way for you to tackle a problem like this.
- deleted 8y ago
  [deleted]
helloguillecl 8y ago
It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scripts. The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website.
- Cthulhu_ 8y ago
  Yeah, especially if it's detecting a payment information form, just like they do with passwords atm. They can detect CC forms just fine (with their autocomplete functionality). I'd also like browsers to do automatic integrity checking - they should be able to have an internal list of signatures, tracking releases of well known libraries.
- dchest 8y ago
  > It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scripts. It would just teach users to ignore warnings. > The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website. No, it's not similar at all.
- interfixus 8y ago
  Why particularly for Chrome?
  - helloguillecl 8y ago
    Sorry, I wanted to fix that after I posted the comment.
  - josteink 8y ago
    Are you implying there are other browsers? /s The wonderful web as we used to know it has devolved into a pretty sad thing (and web-developers with it).
- deleted 8y ago
  [deleted]
tyingq 8y ago
I suspect this is common enough that a list of who DOES use SRI would be shorter.
robbick 8y ago
I'm disappointed by the response he got which said "This appears to be more of a risk acceptance rather than a vulnerability." I understand that some risk is acceptable but surely that is proportional to the cost of removing the risk and in this case that cost is so small.
- laurent123456 8y ago
  I agree that it should be fixed but we can't know that the cost is going to be small. Some websites are generated via dozens of layers of abtractions and maybe there's no options to add the sri without going deep inside some messy frameworks and changing several of these layers.
- dragonwriter 8y ago
  Also, “risk acceptance” and “vulnerability” aren't mutually exclusive. Vulnerability is the risk, the acceptance is deciding that the vulnerability is necessary because the cost to avoid or fix it is too high. But making that choice doesn't stop it from being a vulnerability.
- JustSomeNobody 8y ago
  I read that and translated it to, "This is between our customers and their credit card company. It's not like we'll get in any real trouble."
baybal2 8y ago
First, the WHATWG is better to finally settle on the hash standard, and produce a final normal standard document. But it being WhatWG, will not do that. Second, do not ever use 3rd party code served on payment pages, or, even better, have a wholely JS free payment page. Third, that fact alone that people are using all kinds of js frameworks for super duper critical code, tells of how little concern is given to security there. Fourth, PciDSS, where are you when we need you? Weren't it already against the rules to allow loading of code from third parties on payment pages???
- Someone1234 8y ago
  > Fourth, PciDSS, where are you when we need you? Weren't it already against the rules to allow third party code on payment pages??? No. You're required to get audited, document certain decisions, and follow some pretty high label 101 level security requirements. You can absolutely use third party libraries on payment pages (source: we do and are PCI certified).
  - baybal2 8y ago
    Really, so, you are truly allowed to serve code from random CDNs??? That's really something. I never could've imagined that.
    - Someone1234 8y ago
      PCI is a specific set of requirements. We've met those requirements and our certified auditor agrees. Which specific part of PCI do you feel third party libraries violates?
      - baybal2 8y ago
        I don't know, but I always had that feeling. Given that they are so paranoid with payment terminals, I thought that online payment pages will be no different.
        8y ago
cronin101 8y ago
> What's especially annoying about this, is that the CDNJS website has a "one-click copy" for SRI. Actually, from the screenshot it's clearly "two-click" and "one-click" provides a link without SRI. Obviously the vast majority of people in a rush are going to use the "one-click" option, secure or not. There's no reason why the SRI option shouldn't be default on CDNJS when the URL is specifying a specific version. Don't trust consumers to be competent, help them out with good UI patterns. We should be advocating default = secure here.
- giancarlostoro 8y ago
  > We should be advocating default = secure here. Leaving no room for them to screw it up is always a good option. I know (some) Junior (or really any) devs don't always consider security at all, so they will take the quickest option even if it's wrong or insecure, so long as it "works".
  - mstade 8y ago
    Particularly with management breathing down their necks to deliver.
leonk 8y ago
The method for the BA hack was not from javascript hosted externally. See https://medium.com/asecuritysite-when-bob-met-alice/the-british-airways-hack-javascript-weakness-pin-pointed-through-time-lining-dd0c2dbc7b50 https://medium.com/asecuritysite-when-bob-met-alice/the-brit...
- deleted 8y ago
  [deleted]
- strictnein 8y ago
  Yep, was going to say exactly this. All the SRI, CSP, etc is great, but if you can't control your own site you're screwed regardless.
asaph 8y ago
> If you absolutely have to load someone else's code, check to see if it has been altered. Third party JavaScript code can be altered for legitimate reasons. e.g. adding new features, refactoring, security fixes, etc. In order to prevent a site which uses SRI from breaking every time a 3rd party makes an update to a js file, 3rd parties should version their JavaScript resources with a version number in the URL. This, of course, places the added burden on the site that uses the 3rd party JavaScript resource. They need to update the version number in the URL and update the SRI every time the 3rd party releases an update. And this should be a manual process because automating it would defeat the whole point of SRI.
- amelius 8y ago
  Why not just copy the file, inspect it, and serve it from your own servers?
  - asaph 8y ago
    It's because that can break the site due to the browser's sandbox permissions model. Scripts are only allowed to make ajax calls to their origin servers. Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes.
    - jszymborski 8y ago
      You are totally right, but I'm wondering if we shouldn't change this practice. I'm starting to think if you're making a call to an external service, it should be proxied through your network. It'd increase bandwidth/latency, but you can be assured that the network calls your page are making are hitting the correct 3rd parties, and even inspect to see that the payloads are "correct". Edit: Surely, this at the very least should be the case for payment pages and banking websites.
      - asaph 8y ago
        > ... but you can be assured that the network calls your page are making are hitting the correct 3rd parties ... The browser's sandbox security model already does this for us with the same origin policy. > ... and even inspect to see that the payloads are "correct". This is what SRI already does for us.
jszymborski 8y ago
It's for reasons like this that I recommend uMatrix for Firefox [0] and Chrome [1]. It's default function is to block scripts that don't belong to the root domain of the site you're visiting, and you can whitelist 3rd-Party domains by asset type on the fly from a dialogue. It's really handy for eliminating dodgy dependencies, and it doesn't break half as many sites as NoScript. [0] https://addons.mozilla.org/en-US/firefox/addon/umatrix/ https://addons.mozilla.org/en-US/firefox/addon/umatrix/ [1] https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf https://chrome.google.com/webstore/detail/umatrix/ogfcmafjal...
- danShumway 8y ago
  uMatrix is great because it doesn't just block scripts. You can block iframes, images, etc... You can also turn off stuff like webworkers. It's not perfect (I've noticed a few holes around how it manages cookies, for example), but it's really good. Removing scripts is nice, but if you're trying to prevent obscure attacks[0] or even common tracking techniques from 3rd-party sites, it's not enough. People look at Javascript like it's the primary insecurity on the web; in reality any time you can conditionally make a request to a server for any reason from anywhere, that's a vulnerability. So with uMatrix you don't just get the ability to say, "don't run scripts", you get the ability to conditionally and granularly blacklist/whitelist domains themselves. [0]: https://www.mike-gualtieri.com/posts/stealing-data-with-css-attack-and-defense https://www.mike-gualtieri.com/posts/stealing-data-with-css-...
hajderr 8y ago
I love these type of findings. Good job!
robert_foss 8y ago
> The Guardian > Despite being a tofu-knitting member of the bourgeoisie, I am yet to subscribe to teh Gruan. If I did, I'd risk their affiliate tracker going rogue and stealing my organic credit card details.
- edent 8y ago
  I know what I'm about!
kyrra 8y ago
How do people here feel about a website including 3rd party JavaScript from their payment processor or bank on the payment page? This article mentions Adyen JavaScript being included, but that seems fine here?
- edent 8y ago
  As I said, it is probably fine. But it does introduce yet another small risk. Perhaps the best solution is to just send a user to the payment provider rather than keeping them on your site.
  - kyrra 8y ago
    What are the repercussions if Adyen was hacked in this case? Would they be able to steal session cookies for the user's account on Spotify? Something else malicious?
paraditedc 8y ago
I don't think you need SRI if you already have SCP with hash? SCP covers dynamically loaded scripts also, which should provide more security than SRI.
- kretor 8y ago
  I think you meant CSP (Content Security Policy), not SCP
  - paraditedc 8y ago
    Yeah I mean CSP - https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Specifically script-src: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co... To many acronyms, my mind was probably thinking about SICP - https://mitpress.mit.edu/sites/default/files/sicp/index.html https://mitpress.mit.edu/sites/default/files/sicp/index.html
watertom 8y ago
So much for the pen test and the code review conducted by the PCI auditor. I guess I'm the only idiot who actually follows the guidelines....
growse 8y ago
I wonder if SRI management could be done at the browser/plugin/unblock level? Ie block the loading of a script if the content hash different from the last time it was loaded.
xtrapolate 8y ago
> "SRI has been available for two years and it still isn't being used enough." Two years is relatively fresh. There's probably a significant amount of customers with browsers that don't support this. Can't we just implement a simple poor-man's SRI ourselves? Download the 3rd-party script, hash it, check hash, proceed to exec() if all is well? This should be supported by much older browsers.
- jmngomes 8y ago
  Actually, IE and iOS Safari are lagging but other major browsers seem to have support for SRI for quite some time: https://caniuse.com/#search=sri https://caniuse.com/#search=sri
deleted 8y ago
[deleted]
ejcx 8y ago
I ALWAYS run 3rd party JavaScript on my payments page. That's what Stripe is, after all. In this blog post the author identifies probably 1 questionable third party resource. As scary as it sounds it's not exactly easy to just compromise major JS providers and start stealing cc data. It's possible but instances of it happening are extremely rare. Knowing what you're loading is more important than not loading anything. It's not realistic to expect no third party js in today's world, and even versioning+SRI has issues because it solves one problem by creating a new one.
- wccrawford 8y ago
  I think they point they're trying to make is that there's no guarantee the script you get isn't hacked unless you use SRI. The focus isn't on third-party javascript, but un-secured javascript.
deleted 8y ago
[deleted]
blitmap 8y ago
https://caniuse.com/#feat=subresource-integrity https://caniuse.com/#feat=subresource-integrity :( Why it's not supported on "iOS Safari"...
seanwilson 8y ago
One problem with SRI and locking down your version of a third party JavaScript library is you won't get security updates the third party makes to that library until you manually update your link. Another issue is third parties don't offer versioned links at all so SRI will prevent the link from loading when the library code is updated. What's the best solution to this? Expecting every website owner to manually review and approve each library version update has problems too and you have to be realistic in accepting most website owners aren't going to be constantly reviewing their libraries. Why is there no mechanism to allow a JavaScript bundle to be signed so we can be more confident the original developer made the modification like we do in other ecosystems? Are there ways you could add more sandboxing to scripts to limit their potential damage? Iframes let you do this (i.e. so scripts can't modify or read the outer page) to an extent for some scenarios.
- edent 8y ago
  The majority of those scripts are version controlled already. They're explicitly using V1.0.3 or whatever. So responsible site owners are already testing and approving version changes.
  - numbsafari 8y ago
    Indeed, to comply with PCI-DSS v3.2.1, requirement 6.1 you must "Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information", and requirement 6.2 you must "Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches." So you need to have an inventory of all vendor supplied software and hardware, monitor for security advisories from those vendors, and have an adequate change management process to respond to those advisories in a timely fashion. All of that needs to be auditable.
  - seanwilson 8y ago
    > So responsible site owners are already testing and approving version changes. I'm not saying it's not possible, I'm asking how it could be made easier and for sites in general, not just payment websites. The more resources something takes, the less developers that are going to do it so the web will be less secure.
austincheney 8y ago
Everything great and bad about JavaScript can be explained by a simple facet of human behavior and one simple principle of technology. JavaScript has a low barrier of entry, which means you don't have to be incredibly competent to write code or get hired to write code. It also means a novice with incredible potential could eventually learn to build great things in the language. An interesting phenomenon of human behavior is that people cannot practice charity and profit simultaneously (altruism versus egoism). It is a forced dichotomy. You have to choose and there is no middle ground. This forced choice is present even when the environment, incentives, and stimulus allow for both. This is long observed in scientific philosophy, but there is also a fair amount of behavioral health research on this as well. These factors could explain, even when normalizing for hours of practice, why open source practitioners may develop more skill and interest than developers limiting their practice to employment contributions. It might also explain why code in commonly despised fields, such as online advertising or e-commerce checkout platforms, are so incredibly awful and negligent.
- sdegutis 8y ago
  > An interesting phenomenon of human behavior is that people cannot practice charity and profit simultaneously (altruism versus egoism). It is a forced dichotomy. You have to choose and there is no middle ground. This forced choice is present even when the environment, incentives, and stimulus allow for both. This is long observed in scientific philosophy, but there is also a fair amount of behavioral health research on this as well. This may be common but it's not an absolute. There is a middle ground, you can profit without exploiting anyone, for the definition "use [someone or something] in an unfair or selfish way". The trick is to exploit using the definition "make full use of and derive benefit from", and making full use of anyone's talents and skills always includes improving their morale, which is mutually exclusive with being a selfish or greedy company.
  - austincheney 8y ago
    > There is a middle ground, you can profit without exploiting anyone That is not a middle ground. It is one of two classes of motivations. Profit does not imply exploitation, manipulation, or any form of dishonesty.
dzek69 8y ago
> Google supports SRI - but doesn't mention it anywhere on their Hosted Libraries site. It's not Google/CDN part to support SRI - its the browser itself
Tsubasachan 8y ago
iDeal redirects you to the bank's site. Seems safer to run your payments through them.
omk 8y ago
SSL is just half the solution when there is enough attack surface available through JavaScript. Users should have the ability to encrypt data within the browser (before any JS kicks in) only to be read by owners of a trusted domain. Keygen was the way to go; there's some hope with FIDO.
CM30 8y ago
So in other words, if you're running ads or A/B testing scripts on your payment page, you're open to security issues without much in the way of a fix. It's easy to say to use hashes and resource integrity, but some things are loaded from third party servers and change on the fly/dynamically...
purple_ducks 8y ago
Before SPA, one could restrict 3rd party scripts from being alive on the payment page. With the rise of SPAs, it seems there's going to be more and more 3rd party scripts unintentionally running on payment pages.

214 points by edent 8y ago

I am so old school, but I only use local installation of 3rd party tools and libraries. That means I have to update them, but that also means that no hidden update will break my site or worse, introduce vulnerabilities.

stabbles 8y ago

Is there a good browser plugin that tracks changes to sources of js files? That way you could mark certain sources as trusted, but whenever they change, they would be blocked until you mark them as trusted again.

O_H_E 8y ago
But how is it going to know the authentic source?
- fredley 8y ago
  The source doesn't matter, only the content. If the hash of the file matches the hash you've already approved for jquery-3.3, then the file is (unless someone's found a collision in the hashing algorithm that hasn't been disclosed) jquery-3.3.
  - sprt 8y ago
    I think what they meant is how do you identify the authentic content the first time around?
    - throwaway899 8y ago
      By manually reviewing the said file or by trusting a central authority of some sort.
fredley 8y ago
This would be really neat, and not that hard to build from what I know about building extensions. Basically just store a hash of file, whenever external files are loaded see if their hash exists in your list, if not block it from loading until it's been reviewed. As an extra (paid-for?) feature hook into an online system that keeps track of hashes of known-good popular libs, and can mark as untrusted when a vulnerability is found with a version of e.g. jQuery and auto-flag that for users.
paraditedc 8y ago
And how do you know the browser plugin source code have not changed?
- danShumway 8y ago
  In Firefox you can turn off updates for individual plugins, so you only need to trust Mozilla and the extension author once. Chrome is currently looking into getting rid of the ability for extension authors to obfuscate code -- minification is the highest level of obfuscation they'll accept now, and (opinion me) minified Javascript code is not that hard to read. Chrome does still need to get on the "let people turn off automatic updates" train though. But I'm not sure what to tell you about that -- you should not be running Chrome as your main browser anyway if you care about security/privacy. I'm not sure if Mozilla is planning to follow suite on blocking obfuscation. Assuming they are, if you don't trust the extension author even for the initial download, install the extension, read through the source code natively on your own computer, and then set it to not update after that point. It would be better if you could download the unminified/unbundled source code and install the extension yourself locally, but for whatever reason Firefox and Chrome have decided that's insecure. I feel the opposite, since requiring signed extensions makes it harder for me to audit code or place additional safeguards around that code, but... eh, what do I know? In any case, the current situation for extensions on Firefox is not all that different from installing something in a standard software repository.
  - O_H_E 8y ago
    >if you could download the unminified/unbundled source code and install the extension yourself locally Do you mean for a proprietary extension? AFAIK loading sources locally works fine in chrome.
    - danShumway 8y ago
      In Firefox, loading unsigned extensions is severely restricted. It's a separate process to install them, and they'll only last until you restart the browser. I'm not sure what Chrome's specific rules are; I think they allow loading local sources in dev mode, but warn you about it every time the browser launches? I generally advise people to avoid Chrome if they care about security/privacy anyway, so I've never checked in detail. But if Chrome does have a way for you to easily load extensions from source, and you're comfortable using it as a main browser, that could be a valid way for you to tackle a problem like this.
deleted 8y ago
[deleted]

helloguillecl 8y ago

It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scripts. The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website.

Cthulhu_ 8y ago
Yeah, especially if it's detecting a payment information form, just like they do with passwords atm. They can detect CC forms just fine (with their autocomplete functionality). I'd also like browsers to do automatic integrity checking - they should be able to have an internal list of signatures, tracking releases of well known libraries.
dchest 8y ago
> It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scripts. It would just teach users to ignore warnings. > The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website. No, it's not similar at all.
interfixus 8y ago
Why particularly for Chrome?
- helloguillecl 8y ago
  Sorry, I wanted to fix that after I posted the comment.
- josteink 8y ago
  Are you implying there are other browsers? /s The wonderful web as we used to know it has devolved into a pretty sad thing (and web-developers with it).
deleted 8y ago
[deleted]

tyingq 8y ago

I suspect this is common enough that a list of who DOES use SRI would be shorter.

robbick 8y ago

I'm disappointed by the response he got which said "This appears to be more of a risk acceptance rather than a vulnerability." I understand that some risk is acceptable but surely that is proportional to the cost of removing the risk and in this case that cost is so small.

laurent123456 8y ago
I agree that it should be fixed but we can't know that the cost is going to be small. Some websites are generated via dozens of layers of abtractions and maybe there's no options to add the sri without going deep inside some messy frameworks and changing several of these layers.
dragonwriter 8y ago
Also, “risk acceptance” and “vulnerability” aren't mutually exclusive. Vulnerability is the risk, the acceptance is deciding that the vulnerability is necessary because the cost to avoid or fix it is too high. But making that choice doesn't stop it from being a vulnerability.
JustSomeNobody 8y ago
I read that and translated it to, "This is between our customers and their credit card company. It's not like we'll get in any real trouble."

baybal2 8y ago

First, the WHATWG is better to finally settle on the hash standard, and produce a final normal standard document. But it being WhatWG, will not do that. Second, do not ever use 3rd party code served on payment pages, or, even better, have a wholely JS free payment page. Third, that fact alone that people are using all kinds of js frameworks for super duper critical code, tells of how little concern is given to security there. Fourth, PciDSS, where are you when we need you? Weren't it already against the rules to allow loading of code from third parties on payment pages???

Someone1234 8y ago
> Fourth, PciDSS, where are you when we need you? Weren't it already against the rules to allow third party code on payment pages??? No. You're required to get audited, document certain decisions, and follow some pretty high label 101 level security requirements. You can absolutely use third party libraries on payment pages (source: we do and are PCI certified).
- baybal2 8y ago
  Really, so, you are truly allowed to serve code from random CDNs??? That's really something. I never could've imagined that.
  - Someone1234 8y ago
    PCI is a specific set of requirements. We've met those requirements and our certified auditor agrees. Which specific part of PCI do you feel third party libraries violates?
    - baybal2 8y ago
      I don't know, but I always had that feeling. Given that they are so paranoid with payment terminals, I thought that online payment pages will be no different.
      - 8y ago

cronin101 8y ago

> What's especially annoying about this, is that the CDNJS website has a "one-click copy" for SRI. Actually, from the screenshot it's clearly "two-click" and "one-click" provides a link without SRI. Obviously the vast majority of people in a rush are going to use the "one-click" option, secure or not. There's no reason why the SRI option shouldn't be default on CDNJS when the URL is specifying a specific version. Don't trust consumers to be competent, help them out with good UI patterns. We should be advocating default = secure here.

giancarlostoro 8y ago
> We should be advocating default = secure here. Leaving no room for them to screw it up is always a good option. I know (some) Junior (or really any) devs don't always consider security at all, so they will take the quickest option even if it's wrong or insecure, so long as it "works".
- mstade 8y ago
  Particularly with management breathing down their necks to deliver.

leonk 8y ago

The method for the BA hack was not from javascript hosted externally. See https://medium.com/asecuritysite-when-bob-met-alice/the-british-airways-hack-javascript-weakness-pin-pointed-through-time-lining-dd0c2dbc7b50 https://medium.com/asecuritysite-when-bob-met-alice/the-brit...

deleted 8y ago
[deleted]
strictnein 8y ago
Yep, was going to say exactly this. All the SRI, CSP, etc is great, but if you can't control your own site you're screwed regardless.

asaph 8y ago

> If you absolutely have to load someone else's code, check to see if it has been altered. Third party JavaScript code can be altered for legitimate reasons. e.g. adding new features, refactoring, security fixes, etc. In order to prevent a site which uses SRI from breaking every time a 3rd party makes an update to a js file, 3rd parties should version their JavaScript resources with a version number in the URL. This, of course, places the added burden on the site that uses the 3rd party JavaScript resource. They need to update the version number in the URL and update the SRI every time the 3rd party releases an update. And this should be a manual process because automating it would defeat the whole point of SRI.

amelius 8y ago
Why not just copy the file, inspect it, and serve it from your own servers?
- asaph 8y ago
  It's because that can break the site due to the browser's sandbox permissions model. Scripts are only allowed to make ajax calls to their origin servers. Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes.
  - jszymborski 8y ago
    You are totally right, but I'm wondering if we shouldn't change this practice. I'm starting to think if you're making a call to an external service, it should be proxied through your network. It'd increase bandwidth/latency, but you can be assured that the network calls your page are making are hitting the correct 3rd parties, and even inspect to see that the payloads are "correct". Edit: Surely, this at the very least should be the case for payment pages and banking websites.
    - asaph 8y ago
      > ... but you can be assured that the network calls your page are making are hitting the correct 3rd parties ... The browser's sandbox security model already does this for us with the same origin policy. > ... and even inspect to see that the payloads are "correct". This is what SRI already does for us.

jszymborski 8y ago

It's for reasons like this that I recommend uMatrix for Firefox [0] and Chrome [1]. It's default function is to block scripts that don't belong to the root domain of the site you're visiting, and you can whitelist 3rd-Party domains by asset type on the fly from a dialogue. It's really handy for eliminating dodgy dependencies, and it doesn't break half as many sites as NoScript. [0] https://addons.mozilla.org/en-US/firefox/addon/umatrix/ https://addons.mozilla.org/en-US/firefox/addon/umatrix/ [1] https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf https://chrome.google.com/webstore/detail/umatrix/ogfcmafjal...

danShumway 8y ago
uMatrix is great because it doesn't just block scripts. You can block iframes, images, etc... You can also turn off stuff like webworkers. It's not perfect (I've noticed a few holes around how it manages cookies, for example), but it's really good. Removing scripts is nice, but if you're trying to prevent obscure attacks[0] or even common tracking techniques from 3rd-party sites, it's not enough. People look at Javascript like it's the primary insecurity on the web; in reality any time you can conditionally make a request to a server for any reason from anywhere, that's a vulnerability. So with uMatrix you don't just get the ability to say, "don't run scripts", you get the ability to conditionally and granularly blacklist/whitelist domains themselves. [0]: https://www.mike-gualtieri.com/posts/stealing-data-with-css-attack-and-defense https://www.mike-gualtieri.com/posts/stealing-data-with-css-...

hajderr 8y ago

I love these type of findings. Good job!

robert_foss 8y ago

> The Guardian > Despite being a tofu-knitting member of the bourgeoisie, I am yet to subscribe to teh Gruan. If I did, I'd risk their affiliate tracker going rogue and stealing my organic credit card details.

edent 8y ago
I know what I'm about!

kyrra 8y ago

How do people here feel about a website including 3rd party JavaScript from their payment processor or bank on the payment page? This article mentions Adyen JavaScript being included, but that seems fine here?

edent 8y ago
As I said, it is probably fine. But it does introduce yet another small risk. Perhaps the best solution is to just send a user to the payment provider rather than keeping them on your site.
- kyrra 8y ago
  What are the repercussions if Adyen was hacked in this case? Would they be able to steal session cookies for the user's account on Spotify? Something else malicious?

paraditedc 8y ago

I don't think you need SRI if you already have SCP with hash? SCP covers dynamically loaded scripts also, which should provide more security than SRI.

kretor 8y ago
I think you meant CSP (Content Security Policy), not SCP
- paraditedc 8y ago
  Yeah I mean CSP - https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Specifically script-src: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co... To many acronyms, my mind was probably thinking about SICP - https://mitpress.mit.edu/sites/default/files/sicp/index.html https://mitpress.mit.edu/sites/default/files/sicp/index.html

watertom 8y ago

So much for the pen test and the code review conducted by the PCI auditor. I guess I'm the only idiot who actually follows the guidelines....

growse 8y ago

I wonder if SRI management could be done at the browser/plugin/unblock level? Ie block the loading of a script if the content hash different from the last time it was loaded.

xtrapolate 8y ago

> "SRI has been available for two years and it still isn't being used enough." Two years is relatively fresh. There's probably a significant amount of customers with browsers that don't support this. Can't we just implement a simple poor-man's SRI ourselves? Download the 3rd-party script, hash it, check hash, proceed to exec() if all is well? This should be supported by much older browsers.

jmngomes 8y ago
Actually, IE and iOS Safari are lagging but other major browsers seem to have support for SRI for quite some time: https://caniuse.com/#search=sri https://caniuse.com/#search=sri

deleted 8y ago

[deleted]

ejcx 8y ago

I ALWAYS run 3rd party JavaScript on my payments page. That's what Stripe is, after all. In this blog post the author identifies probably 1 questionable third party resource. As scary as it sounds it's not exactly easy to just compromise major JS providers and start stealing cc data. It's possible but instances of it happening are extremely rare. Knowing what you're loading is more important than not loading anything. It's not realistic to expect no third party js in today's world, and even versioning+SRI has issues because it solves one problem by creating a new one.

wccrawford 8y ago
I think they point they're trying to make is that there's no guarantee the script you get isn't hacked unless you use SRI. The focus isn't on third-party javascript, but un-secured javascript.

deleted 8y ago

[deleted]

blitmap 8y ago

https://caniuse.com/#feat=subresource-integrity https://caniuse.com/#feat=subresource-integrity :( Why it's not supported on "iOS Safari"...

seanwilson 8y ago

One problem with SRI and locking down your version of a third party JavaScript library is you won't get security updates the third party makes to that library until you manually update your link. Another issue is third parties don't offer versioned links at all so SRI will prevent the link from loading when the library code is updated. What's the best solution to this? Expecting every website owner to manually review and approve each library version update has problems too and you have to be realistic in accepting most website owners aren't going to be constantly reviewing their libraries. Why is there no mechanism to allow a JavaScript bundle to be signed so we can be more confident the original developer made the modification like we do in other ecosystems? Are there ways you could add more sandboxing to scripts to limit their potential damage? Iframes let you do this (i.e. so scripts can't modify or read the outer page) to an extent for some scenarios.

edent 8y ago
The majority of those scripts are version controlled already. They're explicitly using V1.0.3 or whatever. So responsible site owners are already testing and approving version changes.
- numbsafari 8y ago
  Indeed, to comply with PCI-DSS v3.2.1, requirement 6.1 you must "Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information", and requirement 6.2 you must "Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches." So you need to have an inventory of all vendor supplied software and hardware, monitor for security advisories from those vendors, and have an adequate change management process to respond to those advisories in a timely fashion. All of that needs to be auditable.
- seanwilson 8y ago
  > So responsible site owners are already testing and approving version changes. I'm not saying it's not possible, I'm asking how it could be made easier and for sites in general, not just payment websites. The more resources something takes, the less developers that are going to do it so the web will be less secure.

austincheney 8y ago

Everything great and bad about JavaScript can be explained by a simple facet of human behavior and one simple principle of technology. JavaScript has a low barrier of entry, which means you don't have to be incredibly competent to write code or get hired to write code. It also means a novice with incredible potential could eventually learn to build great things in the language. An interesting phenomenon of human behavior is that people cannot practice charity and profit simultaneously (altruism versus egoism). It is a forced dichotomy. You have to choose and there is no middle ground. This forced choice is present even when the environment, incentives, and stimulus allow for both. This is long observed in scientific philosophy, but there is also a fair amount of behavioral health research on this as well. These factors could explain, even when normalizing for hours of practice, why open source practitioners may develop more skill and interest than developers limiting their practice to employment contributions. It might also explain why code in commonly despised fields, such as online advertising or e-commerce checkout platforms, are so incredibly awful and negligent.

sdegutis 8y ago
> An interesting phenomenon of human behavior is that people cannot practice charity and profit simultaneously (altruism versus egoism). It is a forced dichotomy. You have to choose and there is no middle ground. This forced choice is present even when the environment, incentives, and stimulus allow for both. This is long observed in scientific philosophy, but there is also a fair amount of behavioral health research on this as well. This may be common but it's not an absolute. There is a middle ground, you can profit without exploiting anyone, for the definition "use [someone or something] in an unfair or selfish way". The trick is to exploit using the definition "make full use of and derive benefit from", and making full use of anyone's talents and skills always includes improving their morale, which is mutually exclusive with being a selfish or greedy company.
- austincheney 8y ago
  > There is a middle ground, you can profit without exploiting anyone That is not a middle ground. It is one of two classes of motivations. Profit does not imply exploitation, manipulation, or any form of dishonesty.

dzek69 8y ago

> Google supports SRI - but doesn't mention it anywhere on their Hosted Libraries site. It's not Google/CDN part to support SRI - its the browser itself

Tsubasachan 8y ago

iDeal redirects you to the bank's site. Seems safer to run your payments through them.

omk 8y ago

SSL is just half the solution when there is enough attack surface available through JavaScript. Users should have the ability to encrypt data within the browser (before any JS kicks in) only to be read by owners of a trusted domain. Keygen was the way to go; there's some hope with FIDO.

CM30 8y ago

So in other words, if you're running ads or A/B testing scripts on your payment page, you're open to security issues without much in the way of a fix. It's easy to say to use hashes and resource integrity, but some things are loaded from third party servers and change on the fly/dynamically...

purple_ducks 8y ago

Before SPA, one could restrict 3rd party scripts from being alive on the payment page. With the rise of SPAs, it seems there's going to be more and more 3rd party scripts unintentionally running on payment pages.