Hacker News Reader

Comment by rvnx | Hacker News Reader

It's cute but probably just a consequence of a content editor at Barclays who has copy-pasted some old content.

A technical solution could be to add a strict CSP policy but in general the problem is broader and applies to a lot of banks.

The real issue is that banks (and it's not specific to Barclays) are loading JavaScript code from third-parties.

The fact that it is InternetArchive (yet another Internet cache) is not more worrying than GoogleUserContent.com for example.

Otherwise, the "asking money for redemption/forgiveness" part to Barclays is a bit borderline in my opinion.

View on HN

Content editors should not be able to add arbitrary code to a bank's website unless it undergoes review from someone who understands web security. If there is some kind of content editing tool, it should only allow content (not arbitrary scripts) to be edited.

> Content editors should not be able to add arbitrary code to a bank's website unless it undergoes review from someone who understands web security.

Hardly anybody really understands web security.

I've audited e-banking websites before. Every file, every element needs to be accounted for. This is beyond "an honest mistake" and it should have been caught by any of the (many) scans the bank orders for its websites. And the scan/report should have caught that. Who does their scans/reports? What is the scope of these scans? Who reviews these reports?

This is not about content. Content is "make a new page with that template and add a photo and the new text about XYZ product". Not a new functionality/code.

I wonder who signed this off prior to.release and what does their wiki/Jira mentions.

Edit: e-banking and other banks websites/online presence(s).

Edit2/rant: I have been the go-to audit/sec/compliance guy for more than a decade. It amazes me in this forum that there are very few discussions/POVs on the audit/security element. In most cases (like this one), an experienced auditor would have picked this up in 20mins. If only Barclays (in this case) bothered to escape the fixed-10 years old checklist/audit program these would never have happened.

> This is beyond "an honest mistake" and it should have been caught by any of the (many) scans the bank orders for its websites. And the scan/report should have caught that. Who does their scans/reports? What is the scope of these scans? Who reviews these reports?

It is partially baffling at least. We had to do a standalone website ad campaign for a bank (same level/recognition as barclays) once, some kind of rewards program where all you could do was browse what was possible to redeem your points for. No accounts, no cart, no integration whatsoever, it was basically a static site (with some user interactivity). We'd get scanned constantly and were always made aware of mistakes or issues, one of them being 3rd party resources.

On the other hand, I wasn't too impressed with their security scanning. Two issues had come up that made me dubious of what all good this actually did.

First was some kind of ssh vulnerability. We were using an older (but still supported) amazon linux ami. The ssh was actually patched but the version did not match what they wanted in the security tool's version. We had to get them to talk with AWS to ensure it was an actual patched version of ssh and the security scanning tool just wasnt accepting it as valid.

The other was some kind of javascript vulnerability in a library. There was an open cve on the library, an open issue on github, with comments on how to fix it, but the library itself wasn't being updated. I manually patched it and named it version x.y.z-patched or something. Report comes back that its still a vulnerability. I'm like what? Impossible I just patched it and tested it myself. The CVE no longer works. So I just renamed it to x-patched.y.z and poof, we pass validation.

This was my version time with vulnerability testing and I was kinda let down by it. I assumed they had people (or tools) actually trying to exploit the site like how I tested the patch for the javascript library prevented the CVE from working instead of just looking for version numbers and comparing to a list of known issues.

This doesn't make the scanning dubious; it's just shows it's limitations of simply being a check of known vulnerabilities.

If you hadn't scanned, would you have fixed the CVE at all?

I get what you are saying but I also think the parent has a point, if it was that easy to do an end run around the scanning (accidentally or otherwise) then it's not really suitable for auditing external parties. For your internal teams you can probably have some level of confidence they will fix it in good faith.

Yeah it's complicated.

Scanning is useful to automate a "thing" but your audit is multifaceted and should probably require peer review (pull/merge requests).

In simple terms, scanning should _hopefully_ help a dev who wants to do the right thing, but it won't help a malicious dev, so you're gonna need something else.

Peer review, least privileged access, protective monitoring, etc.

Until about a year ago I was working as a FE developer for a major intenrnational bank.

All the processes and knowledge were in place to make sure all considerations were taken with our software with regards to security. But... all that good work and intention goes out the window when the marketing and analysis teams could pretty much, on a whim dump any old JS onto a production page via GTM. During my 18 months there, there were numerous issues (thankfully not security issues - at least that we know of) indroduced via this method inc a full outage of the customer onboarding journey.

What is GTM?

Google Tag Manager https://tagmanager.google.com/

"customer onboarding journey" sounds altogether twee for a major international bank. Banks are mattresses with insurance policies. Why is there even a journey to be broken?

Because they have to know who you are in a fair bit of detail both to comply with the law and to know who they should let take money out of the account. Because they need you to agree to a bunch of contacts. Because they need to get you things like a bank card. Because they need to decide if they want to lend you money (most often in the form of a credit card). And so on and so forth.

I see GTM being used (abused?) by marketing teams regularly, but I'm really surprised that a bank with its own development team would allow it.

It is really powerful and sometimes incredibly useful in some scenarios (e.g I once built a schema.org metadata system that scraped the pages on the fly for a site with a broken CMS). Simo Ahava does clever things with it.

But from what I can tell, it seems to be a way of avoiding communication between teams, or a political power grab inside bigger companies - a parallel CMS. And the silly bit is that it's normally not doing much more than could be achieved by copy and pasting a few lines of code into a template.

It's a backdoor way for Google to add more tracking.

Well the clue's in the name. But I'd argue that Google analysing metadata about who's loading what/when through GTM is a lesser evil, when compared to normalising everyone sticking megabytes of mystery scripts on their sites with the tool.

I'd say 'frontdoor' given that the standard first tag to implement is Google Analytics. But I am sure they also generate some data for their own use about the number and types of tags that each site is adding via GTM.

It's a Google backdoor for your team to add more tracking etc.

The important point is that it's a backdoor for marketing (and adtech) teams to get around developer/security requirements. At some point, someone on those teams gets frustrated that their one-line code requests (just load this script! add a gif banner here!) keep falling behind in the backlog. That happens in part because the product team often doesn't care about marketing, and sometimes because developers know that "just one more script!" paves the road to hell. At some point the third-party that's trying to get their business going through your business convinces the marketing team to add GTM, the marketing team says to the dev team "Hey we need GTM to implement THIS script". This time, because the other side has promised them $$$ in terms ROI, the marketing team pushes really hard for it, and eventually a product manager approves the request to get them off their back. The rest, as they say, is history (at retro time, multiple times down the road).

Just this week marketing asked me to install another instance of GTM that was controlled by an outside ad agency. That was a hard no.

For clarification, you mean Google Tag Manager?

I was once investigating "partner reporting that our embed loads slowly". The investigation result was something like: their HTML injects JS, which injects another JS, which injects GTM, which injects an SDK, which injects the embed.

Of course it all loads only when the user does not have any adblocking or tracking protections enabled.

I work for a large media comp and this is exactly the reason we don't give editors access to GTM (or even all developers), nor do we allow tools such as Optimizely intended for A/B testing, and we went away from letting them paste HTML into articles to include custom elements.

Unfortunately, we still have lots of 3rd party stuff in GTM, and technically any ad can run random js on our sites. Thats where most problems come from these days.

Editors still technically have the power to brick a given site through our old inhouse CMS which has no proper access control levels, hopefully not for long...

> technically any ad can run random js on our sites

If you configure your ad network to run all ads cross-domain, then they are very limited. For example, in GPT (which I work on) you call "googletag.pubads().setForceSafeFrame(true)".

(Disclosure: speaking only for myself)

> All the processes and knowledge were in place to make sure all considerations were taken with our software with regards to security. But... all that good work and intention goes out the window when the marketing and analysis teams could pretty much, on a whim dump any old JS onto a production page via GTM.

That's what's great about content security policies: put a CSP on the page, and when people try to add scripts without going through proper processes it just won't run.

If you're using Google tag manager, the csp would have to allow scripts from gtm though?

Yes, but it won't allow GTM to load scripts off OTHER domains. It basically re-adds the requirement of engineering gating off 300 different adtech trackers.

Heh, look at the script that they're loading.

You can tell by the URL path (it's under /content/dam) that it's served by Adobe Experience Manager (Adobe's CMS, dam stands for digital asset manager, where you store static assets like images and js). The script itself is "target.js", which is Adobe Target - their A/B framework - which "supports custom code insertion"[1] similar to a tag manager.

It's not GTM, but this is like loading the GTM script itself from archive.org.

[1]: https://docs.adobe.com/content/help/en/target/using/introduc...

It's worth noting that AEM is often very badly set up, following requirements from managers who have no idea or concern about web development, and later maintained by low cost content editors who barely know some HTML. Moreover, this CMS seems to be a standard for big sites even though the licenses are costly, development is slow and complicated, and it adds a lot of human hours to the site maintenance.

When I was coming up as a CMS operator there were a lot of jobs to undertake site updates for banks and law firms - the JDs were always caveated about needing to understand both regulatory as well as security issues.

I never applied as I like pushing the boundaries when it comes to using CMSs, but if they're calling it out from Day One it's also on the operator to not do it even if they could.

Adding scripts might be considered OK (content editors could be given light-weight developer tasks), but modifying the site's CSP definitely isn't. There aren't many things you can do to stop an attacker injecting code in to your site, but having a CSP that whitelists servers under your control and blocks everything else is something that you can implement. Changes to the CSP should not be done lightly.

The fact that the CSP is whitelisting archive.org makes this look like an attack to me, or at least a test run before a real attack. I don't believe this was a simple mistake.

I'm gonna invoke hanlon's razor (never attribute to malice what can equally be explained by stupidity) here to assert that this isn't an attack.

Looks like their main homepage doesn't have a CSP policy at all https://cspvalidator.org/#url=https://www.barclays.com

I really hope they have a postmortem and actually implement a CSP for their site, pretty crazy not to, especially for a bank.

"implement a CSP for their site, pretty crazy not to, especially for a bank."

I just checked some of the local banks. Oh dear...

Sure, but this is Barclays.

Fun story: I had a Barclaycard once. I chose to get bills/invoices via snail mail because I'm old fashioned. Didn't use the card for almost a year after signing up and then finally bought something online with it. Got an invoice next month and paid it. Then got another invoice the next month over 60ct for the invoice sent via snail mail. Fair enough, they stated that when I signed up. But then I got another bulk the following month because, you guessed it, the invoice for the invoice was sent via mail. I tried to be clever then and paid 1.20€, but that doesn't work since I still got a letter saying there's still enough money in my account covering the invoice. So after four or five months I just gave up and canceled my account.

> A technical solution could be to add a strict CSP policy but in general the problem is broader and applies to a lot of banks.

The Web is broken, and CORS/CSP headers will only be able to fix only some individual cases, of a bigger, currently unfixable design problem.

The tons of random JS APIs brought into the browser without a any real critical review are making the initial design of scripts on the web being inherently secure, to them not being so.

The state of things needs to be brought back to the point where arbitrary JS simply cannot mess up your browser by design, and when you can load resources from everywhere safely regardless of tricky settings of now 10+ CSP related headers.

Or alternatively, there needs to be a solution to completely shut down those APIs, any "advanced" functionality to load 3rd party resources, reinforced by cryptohashes, and signature checks to verify loaded resources.

WASM needs to be killed with fire before it's too late.

Fully agreed!

Why? I don't know much about WASM, but surely it is better than the cobbled together monstrosity that is JavaScript.

All the insecurity of js, but with the opaqueness of assembly.

Hard disagree. WASM is as good an opportunity as any to enforce better security habits, and indeed seems to be designed specifically with browser security/sandboxing in mind. "Killing" WASM does precisely nothing to fix the status quo around JS insecurity.

Yes, so were Java and applets. And we all know what happened there.

Hard disagree. WebASM and emscripten is the way away from JavaScript, into a better future where code is more cross platform and more performant.

No bank should ever use third party resources. Problem solved.

Imagine a situation where somebody manages to inject own script into bank's page not through employee's negligence, but through some exploit.

You would still have an issue where there is simply no functionality to killswitch all those novel APIs of arguable safety, and tell the browser to shut down any script not explicitly listed as allowed on the site.

"tell the browser to shut down any script not explicitly listed as allowed on the site"

Isn't that what CSP headers are for?

CSP has been an inconsistent, ever growing standard, with a history of implementation breakages. I think only CSP 3.0, and a long WIP safe types standard have approached the level of being actually useful.

I saw websites with a screen long CSP header to work around standard's inconsistencies like frame-src/child-src, and form redirects. I think it's only a matter of time when somebody will find a chink in that weak armour.

The lack of sane by-default policy makes you vulnerable the moment attacker finds a way to redirect a browser to a non-CSP protected page on your domain. Mitigations exist, but... many buts.

Reflection attacks, when attacker injects your own hashed scripts, and data exfiltrating css on pages where they shouldn't be are still possible in various scenarios unless you inline all scripts, and set CSP per every URL.

Other data exfiltration sources, and injection sinks keep being found few times a year.

CSP is a paint over rust.

> The state of things needs to be brought back to the point where arbitrary JS simply cannot mess up your browser by design

What do you imagine your more restricted JavaScript being permitted to do, where it is safe to run on a banking website?

The same thing the language was originally intended for? Namely, the <marquee> content.

It's kind of bizarre how many people are out to defend Barclays here. Normally HN is the first to criticize websites for bad Javascript, ugly fonts, scrolljacking, etc.

It's not the TSB IT fiasco but it's still an error on their part.

If people are cutting Barclays slack, perhaps it's because the guy on Twitter is painting this as a satanically evil deed when it was probably just someone making a stupid mistake.

Additionally, the aggregate bandwidth cost of delivering that JS file during its lifetime is probably less than $0.05. How many copies of this file would need to be concatenated to equal the size of David After Dentist?

No one levels up on the Internet — and especially Twitter — by being calm and reasonable.

I looked at the Tweet (you know, it's also the article title) and it does no such thing - even referring to this as the Internet Archive CDN.

This is entirely a strawman you are burning down to make light of the fact that far from a stupid mistake, this is recklessness enabled by the joke of an "web development" industry. This stupidity is common practice and certainly no one in this thread seems even slightly inclined to clean it up.

You can do any stupid things in any development environment. Let's execute a SQL from Android App to Oracle in Bank!

Loading JavaScript from an external website is not "just someone making a stupid mistake".

It means they don't have their security in order, they're a bunch of amateurs and their banking license should be revoked.

Barclays was just borrowing some resources from Internet Archive. What's the big deal?

Anyone with write access to the file can run their code on the bank's website.

With a $19M liability hanging over their heads the archive could do with some extra cash.

> It's cute but probably just a consequence of a content editor at Barclays who has copy-pasted some old content

It's unlikely that a content editor would be able to do this, given the industry.

Well, as a guesture it would be nice if they could just add some money for the lawsuits against the archive. Aside from being an unwilling CDN, it has quite some other perks.

Reply on news.ycombinator.com