What is formjacking?
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:
- The attacker “injects” malicious JavaScript into the targeted webpage
- The user fills out the form on that webpage
- 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
add a comment |
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:
- The attacker “injects” malicious JavaScript into the targeted webpage
- The user fills out the form on that webpage
- 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
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
add a comment |
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:
- The attacker “injects” malicious JavaScript into the targeted webpage
- The user fills out the form on that webpage
- 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
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:
- The attacker “injects” malicious JavaScript into the targeted webpage
- The user fills out the form on that webpage
- 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
web-application javascript
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
add a comment |
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
add a comment |
3 Answers
3
active
oldest
votes
The Symantec article you are referring to is like this one.
Looking at the 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?
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
|
show 3 more comments
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".
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
add a comment |
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
The Symantec article you are referring to is like this one.
Looking at the 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?
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
|
show 3 more comments
The Symantec article you are referring to is like this one.
Looking at the 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?
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
|
show 3 more comments
The Symantec article you are referring to is like this one.
Looking at the 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?
The Symantec article you are referring to is like this one.
Looking at the 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?
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
|
show 3 more comments
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
|
show 3 more comments
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".
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
add a comment |
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".
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
add a comment |
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".
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".
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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