What is formjacking?












33















I just heard a very confused news broadcast about Symantec warning the world about the dangers of formjacking. The newsreader said it involved “hacking the form, not the website” whatever that means.



I googled around and found a Symantec blog post about it, where they describe the attack as follows:




  1. The attacker “injects” malicious JavaScript into the targeted webpage

  2. The user fills out the form on that webpage

  3. The JavaScript sends the entered data to the server of the attacker.


However, I would say that if an attacker has write access to the code on the server formjacking is the least of your concerns (and not the actual vulnerability – whatever gave them access is).



Why is formjacking the big deal (it was on the national news where I live) and not the fact that tons of websites (among which British Airways according to Symantec) have a ridiculously large vulnerability that allows attackers access to their servers?










share|improve this question

























  • I assume that, at least in part, the confusing thing about the news report is the "hacking the form, not the website" statement. To me that sounds like they"re not completely understanding the issue. After all, depending on your point of view, the form is a part of the website. Like DaveMongoose explains below there are technical differences that might limit an attackers possibilities in terms of server-side code or not, this is likely the reason for the vague statement in the news. COmplex things are complex and all...

    – Gero
    Feb 22 at 8:11











  • Could you link to the blog post?

    – Anders
    Feb 22 at 8:57











  • @Anders Embarrassingly it’s the blog post Tim used in his answer; I completely overlooked the section that fully answered my question.

    – 11684
    Feb 22 at 11:44











  • @11684 And I completely owerlooked the link in Tims answer! :-)

    – Anders
    Feb 22 at 13:24
















33















I just heard a very confused news broadcast about Symantec warning the world about the dangers of formjacking. The newsreader said it involved “hacking the form, not the website” whatever that means.



I googled around and found a Symantec blog post about it, where they describe the attack as follows:




  1. The attacker “injects” malicious JavaScript into the targeted webpage

  2. The user fills out the form on that webpage

  3. The JavaScript sends the entered data to the server of the attacker.


However, I would say that if an attacker has write access to the code on the server formjacking is the least of your concerns (and not the actual vulnerability – whatever gave them access is).



Why is formjacking the big deal (it was on the national news where I live) and not the fact that tons of websites (among which British Airways according to Symantec) have a ridiculously large vulnerability that allows attackers access to their servers?










share|improve this question

























  • I assume that, at least in part, the confusing thing about the news report is the "hacking the form, not the website" statement. To me that sounds like they"re not completely understanding the issue. After all, depending on your point of view, the form is a part of the website. Like DaveMongoose explains below there are technical differences that might limit an attackers possibilities in terms of server-side code or not, this is likely the reason for the vague statement in the news. COmplex things are complex and all...

    – Gero
    Feb 22 at 8:11











  • Could you link to the blog post?

    – Anders
    Feb 22 at 8:57











  • @Anders Embarrassingly it’s the blog post Tim used in his answer; I completely overlooked the section that fully answered my question.

    – 11684
    Feb 22 at 11:44











  • @11684 And I completely owerlooked the link in Tims answer! :-)

    – Anders
    Feb 22 at 13:24














33












33








33


2






I just heard a very confused news broadcast about Symantec warning the world about the dangers of formjacking. The newsreader said it involved “hacking the form, not the website” whatever that means.



I googled around and found a Symantec blog post about it, where they describe the attack as follows:




  1. The attacker “injects” malicious JavaScript into the targeted webpage

  2. The user fills out the form on that webpage

  3. The JavaScript sends the entered data to the server of the attacker.


However, I would say that if an attacker has write access to the code on the server formjacking is the least of your concerns (and not the actual vulnerability – whatever gave them access is).



Why is formjacking the big deal (it was on the national news where I live) and not the fact that tons of websites (among which British Airways according to Symantec) have a ridiculously large vulnerability that allows attackers access to their servers?










share|improve this question
















I just heard a very confused news broadcast about Symantec warning the world about the dangers of formjacking. The newsreader said it involved “hacking the form, not the website” whatever that means.



I googled around and found a Symantec blog post about it, where they describe the attack as follows:




  1. The attacker “injects” malicious JavaScript into the targeted webpage

  2. The user fills out the form on that webpage

  3. The JavaScript sends the entered data to the server of the attacker.


However, I would say that if an attacker has write access to the code on the server formjacking is the least of your concerns (and not the actual vulnerability – whatever gave them access is).



Why is formjacking the big deal (it was on the national news where I live) and not the fact that tons of websites (among which British Airways according to Symantec) have a ridiculously large vulnerability that allows attackers access to their servers?







web-application javascript






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 22 at 8:59









Anders

49.4k22143161




49.4k22143161










asked Feb 21 at 9:21









1168411684

27337




27337













  • I assume that, at least in part, the confusing thing about the news report is the "hacking the form, not the website" statement. To me that sounds like they"re not completely understanding the issue. After all, depending on your point of view, the form is a part of the website. Like DaveMongoose explains below there are technical differences that might limit an attackers possibilities in terms of server-side code or not, this is likely the reason for the vague statement in the news. COmplex things are complex and all...

    – Gero
    Feb 22 at 8:11











  • Could you link to the blog post?

    – Anders
    Feb 22 at 8:57











  • @Anders Embarrassingly it’s the blog post Tim used in his answer; I completely overlooked the section that fully answered my question.

    – 11684
    Feb 22 at 11:44











  • @11684 And I completely owerlooked the link in Tims answer! :-)

    – Anders
    Feb 22 at 13:24



















  • I assume that, at least in part, the confusing thing about the news report is the "hacking the form, not the website" statement. To me that sounds like they"re not completely understanding the issue. After all, depending on your point of view, the form is a part of the website. Like DaveMongoose explains below there are technical differences that might limit an attackers possibilities in terms of server-side code or not, this is likely the reason for the vague statement in the news. COmplex things are complex and all...

    – Gero
    Feb 22 at 8:11











  • Could you link to the blog post?

    – Anders
    Feb 22 at 8:57











  • @Anders Embarrassingly it’s the blog post Tim used in his answer; I completely overlooked the section that fully answered my question.

    – 11684
    Feb 22 at 11:44











  • @11684 And I completely owerlooked the link in Tims answer! :-)

    – Anders
    Feb 22 at 13:24

















I assume that, at least in part, the confusing thing about the news report is the "hacking the form, not the website" statement. To me that sounds like they"re not completely understanding the issue. After all, depending on your point of view, the form is a part of the website. Like DaveMongoose explains below there are technical differences that might limit an attackers possibilities in terms of server-side code or not, this is likely the reason for the vague statement in the news. COmplex things are complex and all...

– Gero
Feb 22 at 8:11





I assume that, at least in part, the confusing thing about the news report is the "hacking the form, not the website" statement. To me that sounds like they"re not completely understanding the issue. After all, depending on your point of view, the form is a part of the website. Like DaveMongoose explains below there are technical differences that might limit an attackers possibilities in terms of server-side code or not, this is likely the reason for the vague statement in the news. COmplex things are complex and all...

– Gero
Feb 22 at 8:11













Could you link to the blog post?

– Anders
Feb 22 at 8:57





Could you link to the blog post?

– Anders
Feb 22 at 8:57













@Anders Embarrassingly it’s the blog post Tim used in his answer; I completely overlooked the section that fully answered my question.

– 11684
Feb 22 at 11:44





@Anders Embarrassingly it’s the blog post Tim used in his answer; I completely overlooked the section that fully answered my question.

– 11684
Feb 22 at 11:44













@11684 And I completely owerlooked the link in Tims answer! :-)

– Anders
Feb 22 at 13:24





@11684 And I completely owerlooked the link in Tims answer! :-)

– Anders
Feb 22 at 13:24










3 Answers
3






active

oldest

votes


















46














The Symantec article you are referring to is like this one.



Looking at the graphic:



graphic



Point 1 is what is generally the most interesting to security researchers, because that is where the vulnerability is.



Points 2 and 3 just show what might be possible with such a vulnerability. For example, JavaScript can be used in phishing attacks (show a fake form) or to read out any data the user enters into forms. This is what Symantec calls formjacking, but it's of course nothing new.



Their article also has a section "How are websites being compromised?", which will likely interest you.



Vulnerabilities do indeed include the option to change server-side code, though not necessarily of the main application, but especially in JavaScript dependencies.



Issues with including 3rd party JavaScript are of course nothing new either. Burp eg calls it Cross-domain script include, and OWASP warns about it as well. Including 3rd party scripts always requires complete trust in the 3rd party as well as trust in their security processes.




Why is formjacking the big deal




Good marketing on the part of Symantec?






share|improve this answer





















  • 1





    It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!?

    – Mason Wheeler
    Feb 21 at 17:03






  • 18





    This is just XSS, is it not?

    – Captain Man
    Feb 21 at 17:22






  • 24





    +1 for "Good marketing on the part of Symantec"

    – R..
    Feb 21 at 17:27






  • 1





    @CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc.

    – tim
    Feb 21 at 17:43






  • 2





    @pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party.

    – David Richerby
    Feb 22 at 18:59



















37














Direct access to the server is not required



There are a number of ways that malicious javascript could end up on a webpage without the attacker having access to the server.




  • The author of the website might be linking to a library from an untrustworthy source


    • e.g. Web Developer A likes the image carousel on my-site.com and links directly to it - now the owner of my-site.com can modify that script whenever they like, potentially adding malicious code.



  • The author of the website might have copied some javascript from an untrustworthy source


    • e.g. Web Developer B is searching for a library to convert Celsius to Fahrenheit. They find a script on free.javascriptlib.zz which does the job, but don't notice it contains malicious code because the script itself is obfuscated.



  • The end user might sabotage themselves by using an untrustworthy browser extension or bookmarklet.


    • e.g. Alice has added a button to her browser which gives her an emoji keyboard, but it also inserts malicious code into the current page.



  • The end user might be the victim of DNS spoofing.


    • e.g. Bob's DNS lookup for https://code.jquery.com/jquery-3.3.1.min.js has been compromised, so it now delivers a version of jquery from an unsafe source which has had malicious code added.



  • ... etc. etc.


The other concern with these types of attack is that they can be difficult to detect. Javascript is executed client-side, and so none of these would raise flags about the site being compromised: it's unlikely that affected users would get any warning that their details have been stolen.





Regarding the British Airways vulnerability in particular, the BBC wrote an article speculating on the cause here: https://www.bbc.co.uk/news/technology-45446529



In it, they suggest that it was likely to be a third-party script and cite another example regarding Ticketmaster where "an on-site customer service chatbot was labelled as the potential cause".






share|improve this answer





















  • 3





    Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors.

    – Andrew Jennings
    Feb 21 at 17:49











  • You left off ads, which is probably the most problematic of attack vectors...

    – Jared Smith
    Feb 22 at 12:45



















13














I agree. Formjacking is not a vulnerability, but a type of attack, that can be executed if the attacker already has write-access to the webroot of the victim, or on the webroot of another site, that has full trust of the victim.



Therefore, Formjacking might also be an issue, if the victims webroot is safe, but they dynamically include third-party code or just try to serve ads, which also frequently leads to malformed trust relation ships.



Formjacking is interesting, as the victim of the attack is the customer of the company, the attacker is targeting and groups like Magecart have already earned quite some money with it.






share|improve this answer



















  • 1





    +1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server.

    – brichins
    Feb 21 at 17:11











  • Is it like sql injection?

    – MarkTO
    Feb 22 at 17:36











  • @MarkTO: No, I don't see much similarities here. Why would you think it is?

    – Euphrasius von der Hummelwiese
    Feb 23 at 9:37











  • Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it.

    – MarkTO
    Feb 25 at 17:04











  • @MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS.

    – Euphrasius von der Hummelwiese
    Feb 25 at 17:19











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203987%2fwhat-is-formjacking%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









46














The Symantec article you are referring to is like this one.



Looking at the graphic:



graphic



Point 1 is what is generally the most interesting to security researchers, because that is where the vulnerability is.



Points 2 and 3 just show what might be possible with such a vulnerability. For example, JavaScript can be used in phishing attacks (show a fake form) or to read out any data the user enters into forms. This is what Symantec calls formjacking, but it's of course nothing new.



Their article also has a section "How are websites being compromised?", which will likely interest you.



Vulnerabilities do indeed include the option to change server-side code, though not necessarily of the main application, but especially in JavaScript dependencies.



Issues with including 3rd party JavaScript are of course nothing new either. Burp eg calls it Cross-domain script include, and OWASP warns about it as well. Including 3rd party scripts always requires complete trust in the 3rd party as well as trust in their security processes.




Why is formjacking the big deal




Good marketing on the part of Symantec?






share|improve this answer





















  • 1





    It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!?

    – Mason Wheeler
    Feb 21 at 17:03






  • 18





    This is just XSS, is it not?

    – Captain Man
    Feb 21 at 17:22






  • 24





    +1 for "Good marketing on the part of Symantec"

    – R..
    Feb 21 at 17:27






  • 1





    @CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc.

    – tim
    Feb 21 at 17:43






  • 2





    @pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party.

    – David Richerby
    Feb 22 at 18:59
















46














The Symantec article you are referring to is like this one.



Looking at the graphic:



graphic



Point 1 is what is generally the most interesting to security researchers, because that is where the vulnerability is.



Points 2 and 3 just show what might be possible with such a vulnerability. For example, JavaScript can be used in phishing attacks (show a fake form) or to read out any data the user enters into forms. This is what Symantec calls formjacking, but it's of course nothing new.



Their article also has a section "How are websites being compromised?", which will likely interest you.



Vulnerabilities do indeed include the option to change server-side code, though not necessarily of the main application, but especially in JavaScript dependencies.



Issues with including 3rd party JavaScript are of course nothing new either. Burp eg calls it Cross-domain script include, and OWASP warns about it as well. Including 3rd party scripts always requires complete trust in the 3rd party as well as trust in their security processes.




Why is formjacking the big deal




Good marketing on the part of Symantec?






share|improve this answer





















  • 1





    It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!?

    – Mason Wheeler
    Feb 21 at 17:03






  • 18





    This is just XSS, is it not?

    – Captain Man
    Feb 21 at 17:22






  • 24





    +1 for "Good marketing on the part of Symantec"

    – R..
    Feb 21 at 17:27






  • 1





    @CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc.

    – tim
    Feb 21 at 17:43






  • 2





    @pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party.

    – David Richerby
    Feb 22 at 18:59














46












46








46







The Symantec article you are referring to is like this one.



Looking at the graphic:



graphic



Point 1 is what is generally the most interesting to security researchers, because that is where the vulnerability is.



Points 2 and 3 just show what might be possible with such a vulnerability. For example, JavaScript can be used in phishing attacks (show a fake form) or to read out any data the user enters into forms. This is what Symantec calls formjacking, but it's of course nothing new.



Their article also has a section "How are websites being compromised?", which will likely interest you.



Vulnerabilities do indeed include the option to change server-side code, though not necessarily of the main application, but especially in JavaScript dependencies.



Issues with including 3rd party JavaScript are of course nothing new either. Burp eg calls it Cross-domain script include, and OWASP warns about it as well. Including 3rd party scripts always requires complete trust in the 3rd party as well as trust in their security processes.




Why is formjacking the big deal




Good marketing on the part of Symantec?






share|improve this answer















The Symantec article you are referring to is like this one.



Looking at the graphic:



graphic



Point 1 is what is generally the most interesting to security researchers, because that is where the vulnerability is.



Points 2 and 3 just show what might be possible with such a vulnerability. For example, JavaScript can be used in phishing attacks (show a fake form) or to read out any data the user enters into forms. This is what Symantec calls formjacking, but it's of course nothing new.



Their article also has a section "How are websites being compromised?", which will likely interest you.



Vulnerabilities do indeed include the option to change server-side code, though not necessarily of the main application, but especially in JavaScript dependencies.



Issues with including 3rd party JavaScript are of course nothing new either. Burp eg calls it Cross-domain script include, and OWASP warns about it as well. Including 3rd party scripts always requires complete trust in the 3rd party as well as trust in their security processes.




Why is formjacking the big deal




Good marketing on the part of Symantec?







share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 22 at 8:29









Spooky

1074




1074










answered Feb 21 at 9:52









timtim

23.8k66699




23.8k66699








  • 1





    It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!?

    – Mason Wheeler
    Feb 21 at 17:03






  • 18





    This is just XSS, is it not?

    – Captain Man
    Feb 21 at 17:22






  • 24





    +1 for "Good marketing on the part of Symantec"

    – R..
    Feb 21 at 17:27






  • 1





    @CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc.

    – tim
    Feb 21 at 17:43






  • 2





    @pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party.

    – David Richerby
    Feb 22 at 18:59














  • 1





    It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!?

    – Mason Wheeler
    Feb 21 at 17:03






  • 18





    This is just XSS, is it not?

    – Captain Man
    Feb 21 at 17:22






  • 24





    +1 for "Good marketing on the part of Symantec"

    – R..
    Feb 21 at 17:27






  • 1





    @CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc.

    – tim
    Feb 21 at 17:43






  • 2





    @pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party.

    – David Richerby
    Feb 22 at 18:59








1




1





It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!?

– Mason Wheeler
Feb 21 at 17:03





It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!?

– Mason Wheeler
Feb 21 at 17:03




18




18





This is just XSS, is it not?

– Captain Man
Feb 21 at 17:22





This is just XSS, is it not?

– Captain Man
Feb 21 at 17:22




24




24





+1 for "Good marketing on the part of Symantec"

– R..
Feb 21 at 17:27





+1 for "Good marketing on the part of Symantec"

– R..
Feb 21 at 17:27




1




1





@CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc.

– tim
Feb 21 at 17:43





@CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc.

– tim
Feb 21 at 17:43




2




2





@pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party.

– David Richerby
Feb 22 at 18:59





@pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party.

– David Richerby
Feb 22 at 18:59













37














Direct access to the server is not required



There are a number of ways that malicious javascript could end up on a webpage without the attacker having access to the server.




  • The author of the website might be linking to a library from an untrustworthy source


    • e.g. Web Developer A likes the image carousel on my-site.com and links directly to it - now the owner of my-site.com can modify that script whenever they like, potentially adding malicious code.



  • The author of the website might have copied some javascript from an untrustworthy source


    • e.g. Web Developer B is searching for a library to convert Celsius to Fahrenheit. They find a script on free.javascriptlib.zz which does the job, but don't notice it contains malicious code because the script itself is obfuscated.



  • The end user might sabotage themselves by using an untrustworthy browser extension or bookmarklet.


    • e.g. Alice has added a button to her browser which gives her an emoji keyboard, but it also inserts malicious code into the current page.



  • The end user might be the victim of DNS spoofing.


    • e.g. Bob's DNS lookup for https://code.jquery.com/jquery-3.3.1.min.js has been compromised, so it now delivers a version of jquery from an unsafe source which has had malicious code added.



  • ... etc. etc.


The other concern with these types of attack is that they can be difficult to detect. Javascript is executed client-side, and so none of these would raise flags about the site being compromised: it's unlikely that affected users would get any warning that their details have been stolen.





Regarding the British Airways vulnerability in particular, the BBC wrote an article speculating on the cause here: https://www.bbc.co.uk/news/technology-45446529



In it, they suggest that it was likely to be a third-party script and cite another example regarding Ticketmaster where "an on-site customer service chatbot was labelled as the potential cause".






share|improve this answer





















  • 3





    Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors.

    – Andrew Jennings
    Feb 21 at 17:49











  • You left off ads, which is probably the most problematic of attack vectors...

    – Jared Smith
    Feb 22 at 12:45
















37














Direct access to the server is not required



There are a number of ways that malicious javascript could end up on a webpage without the attacker having access to the server.




  • The author of the website might be linking to a library from an untrustworthy source


    • e.g. Web Developer A likes the image carousel on my-site.com and links directly to it - now the owner of my-site.com can modify that script whenever they like, potentially adding malicious code.



  • The author of the website might have copied some javascript from an untrustworthy source


    • e.g. Web Developer B is searching for a library to convert Celsius to Fahrenheit. They find a script on free.javascriptlib.zz which does the job, but don't notice it contains malicious code because the script itself is obfuscated.



  • The end user might sabotage themselves by using an untrustworthy browser extension or bookmarklet.


    • e.g. Alice has added a button to her browser which gives her an emoji keyboard, but it also inserts malicious code into the current page.



  • The end user might be the victim of DNS spoofing.


    • e.g. Bob's DNS lookup for https://code.jquery.com/jquery-3.3.1.min.js has been compromised, so it now delivers a version of jquery from an unsafe source which has had malicious code added.



  • ... etc. etc.


The other concern with these types of attack is that they can be difficult to detect. Javascript is executed client-side, and so none of these would raise flags about the site being compromised: it's unlikely that affected users would get any warning that their details have been stolen.





Regarding the British Airways vulnerability in particular, the BBC wrote an article speculating on the cause here: https://www.bbc.co.uk/news/technology-45446529



In it, they suggest that it was likely to be a third-party script and cite another example regarding Ticketmaster where "an on-site customer service chatbot was labelled as the potential cause".






share|improve this answer





















  • 3





    Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors.

    – Andrew Jennings
    Feb 21 at 17:49











  • You left off ads, which is probably the most problematic of attack vectors...

    – Jared Smith
    Feb 22 at 12:45














37












37








37







Direct access to the server is not required



There are a number of ways that malicious javascript could end up on a webpage without the attacker having access to the server.




  • The author of the website might be linking to a library from an untrustworthy source


    • e.g. Web Developer A likes the image carousel on my-site.com and links directly to it - now the owner of my-site.com can modify that script whenever they like, potentially adding malicious code.



  • The author of the website might have copied some javascript from an untrustworthy source


    • e.g. Web Developer B is searching for a library to convert Celsius to Fahrenheit. They find a script on free.javascriptlib.zz which does the job, but don't notice it contains malicious code because the script itself is obfuscated.



  • The end user might sabotage themselves by using an untrustworthy browser extension or bookmarklet.


    • e.g. Alice has added a button to her browser which gives her an emoji keyboard, but it also inserts malicious code into the current page.



  • The end user might be the victim of DNS spoofing.


    • e.g. Bob's DNS lookup for https://code.jquery.com/jquery-3.3.1.min.js has been compromised, so it now delivers a version of jquery from an unsafe source which has had malicious code added.



  • ... etc. etc.


The other concern with these types of attack is that they can be difficult to detect. Javascript is executed client-side, and so none of these would raise flags about the site being compromised: it's unlikely that affected users would get any warning that their details have been stolen.





Regarding the British Airways vulnerability in particular, the BBC wrote an article speculating on the cause here: https://www.bbc.co.uk/news/technology-45446529



In it, they suggest that it was likely to be a third-party script and cite another example regarding Ticketmaster where "an on-site customer service chatbot was labelled as the potential cause".






share|improve this answer















Direct access to the server is not required



There are a number of ways that malicious javascript could end up on a webpage without the attacker having access to the server.




  • The author of the website might be linking to a library from an untrustworthy source


    • e.g. Web Developer A likes the image carousel on my-site.com and links directly to it - now the owner of my-site.com can modify that script whenever they like, potentially adding malicious code.



  • The author of the website might have copied some javascript from an untrustworthy source


    • e.g. Web Developer B is searching for a library to convert Celsius to Fahrenheit. They find a script on free.javascriptlib.zz which does the job, but don't notice it contains malicious code because the script itself is obfuscated.



  • The end user might sabotage themselves by using an untrustworthy browser extension or bookmarklet.


    • e.g. Alice has added a button to her browser which gives her an emoji keyboard, but it also inserts malicious code into the current page.



  • The end user might be the victim of DNS spoofing.


    • e.g. Bob's DNS lookup for https://code.jquery.com/jquery-3.3.1.min.js has been compromised, so it now delivers a version of jquery from an unsafe source which has had malicious code added.



  • ... etc. etc.


The other concern with these types of attack is that they can be difficult to detect. Javascript is executed client-side, and so none of these would raise flags about the site being compromised: it's unlikely that affected users would get any warning that their details have been stolen.





Regarding the British Airways vulnerability in particular, the BBC wrote an article speculating on the cause here: https://www.bbc.co.uk/news/technology-45446529



In it, they suggest that it was likely to be a third-party script and cite another example regarding Ticketmaster where "an on-site customer service chatbot was labelled as the potential cause".







share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 21 at 17:57

























answered Feb 21 at 16:46









DaveMongooseDaveMongoose

47115




47115








  • 3





    Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors.

    – Andrew Jennings
    Feb 21 at 17:49











  • You left off ads, which is probably the most problematic of attack vectors...

    – Jared Smith
    Feb 22 at 12:45














  • 3





    Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors.

    – Andrew Jennings
    Feb 21 at 17:49











  • You left off ads, which is probably the most problematic of attack vectors...

    – Jared Smith
    Feb 22 at 12:45








3




3





Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors.

– Andrew Jennings
Feb 21 at 17:49





Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors.

– Andrew Jennings
Feb 21 at 17:49













You left off ads, which is probably the most problematic of attack vectors...

– Jared Smith
Feb 22 at 12:45





You left off ads, which is probably the most problematic of attack vectors...

– Jared Smith
Feb 22 at 12:45











13














I agree. Formjacking is not a vulnerability, but a type of attack, that can be executed if the attacker already has write-access to the webroot of the victim, or on the webroot of another site, that has full trust of the victim.



Therefore, Formjacking might also be an issue, if the victims webroot is safe, but they dynamically include third-party code or just try to serve ads, which also frequently leads to malformed trust relation ships.



Formjacking is interesting, as the victim of the attack is the customer of the company, the attacker is targeting and groups like Magecart have already earned quite some money with it.






share|improve this answer



















  • 1





    +1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server.

    – brichins
    Feb 21 at 17:11











  • Is it like sql injection?

    – MarkTO
    Feb 22 at 17:36











  • @MarkTO: No, I don't see much similarities here. Why would you think it is?

    – Euphrasius von der Hummelwiese
    Feb 23 at 9:37











  • Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it.

    – MarkTO
    Feb 25 at 17:04











  • @MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS.

    – Euphrasius von der Hummelwiese
    Feb 25 at 17:19
















13














I agree. Formjacking is not a vulnerability, but a type of attack, that can be executed if the attacker already has write-access to the webroot of the victim, or on the webroot of another site, that has full trust of the victim.



Therefore, Formjacking might also be an issue, if the victims webroot is safe, but they dynamically include third-party code or just try to serve ads, which also frequently leads to malformed trust relation ships.



Formjacking is interesting, as the victim of the attack is the customer of the company, the attacker is targeting and groups like Magecart have already earned quite some money with it.






share|improve this answer



















  • 1





    +1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server.

    – brichins
    Feb 21 at 17:11











  • Is it like sql injection?

    – MarkTO
    Feb 22 at 17:36











  • @MarkTO: No, I don't see much similarities here. Why would you think it is?

    – Euphrasius von der Hummelwiese
    Feb 23 at 9:37











  • Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it.

    – MarkTO
    Feb 25 at 17:04











  • @MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS.

    – Euphrasius von der Hummelwiese
    Feb 25 at 17:19














13












13








13







I agree. Formjacking is not a vulnerability, but a type of attack, that can be executed if the attacker already has write-access to the webroot of the victim, or on the webroot of another site, that has full trust of the victim.



Therefore, Formjacking might also be an issue, if the victims webroot is safe, but they dynamically include third-party code or just try to serve ads, which also frequently leads to malformed trust relation ships.



Formjacking is interesting, as the victim of the attack is the customer of the company, the attacker is targeting and groups like Magecart have already earned quite some money with it.






share|improve this answer













I agree. Formjacking is not a vulnerability, but a type of attack, that can be executed if the attacker already has write-access to the webroot of the victim, or on the webroot of another site, that has full trust of the victim.



Therefore, Formjacking might also be an issue, if the victims webroot is safe, but they dynamically include third-party code or just try to serve ads, which also frequently leads to malformed trust relation ships.



Formjacking is interesting, as the victim of the attack is the customer of the company, the attacker is targeting and groups like Magecart have already earned quite some money with it.







share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 21 at 9:46









Euphrasius von der HummelwieseEuphrasius von der Hummelwiese

49815




49815








  • 1





    +1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server.

    – brichins
    Feb 21 at 17:11











  • Is it like sql injection?

    – MarkTO
    Feb 22 at 17:36











  • @MarkTO: No, I don't see much similarities here. Why would you think it is?

    – Euphrasius von der Hummelwiese
    Feb 23 at 9:37











  • Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it.

    – MarkTO
    Feb 25 at 17:04











  • @MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS.

    – Euphrasius von der Hummelwiese
    Feb 25 at 17:19














  • 1





    +1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server.

    – brichins
    Feb 21 at 17:11











  • Is it like sql injection?

    – MarkTO
    Feb 22 at 17:36











  • @MarkTO: No, I don't see much similarities here. Why would you think it is?

    – Euphrasius von der Hummelwiese
    Feb 23 at 9:37











  • Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it.

    – MarkTO
    Feb 25 at 17:04











  • @MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS.

    – Euphrasius von der Hummelwiese
    Feb 25 at 17:19








1




1





+1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server.

– brichins
Feb 21 at 17:11





+1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server.

– brichins
Feb 21 at 17:11













Is it like sql injection?

– MarkTO
Feb 22 at 17:36





Is it like sql injection?

– MarkTO
Feb 22 at 17:36













@MarkTO: No, I don't see much similarities here. Why would you think it is?

– Euphrasius von der Hummelwiese
Feb 23 at 9:37





@MarkTO: No, I don't see much similarities here. Why would you think it is?

– Euphrasius von der Hummelwiese
Feb 23 at 9:37













Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it.

– MarkTO
Feb 25 at 17:04





Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it.

– MarkTO
Feb 25 at 17:04













@MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS.

– Euphrasius von der Hummelwiese
Feb 25 at 17:19





@MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS.

– Euphrasius von der Hummelwiese
Feb 25 at 17:19


















draft saved

draft discarded




















































Thanks for contributing an answer to Information Security Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203987%2fwhat-is-formjacking%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

mysqli_query(): Empty query in /home/lucindabrummitt/public_html/blog/wp-includes/wp-db.php on line 1924

How to change which sound is reproduced for terminal bell?

Can I use Tabulator js library in my java Spring + Thymeleaf project?