How do hackers make the victim access an XSS attack URL?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
8
down vote
favorite
As I undertand it, the basic idea of XSS is to let the user's browser execute some malicious code created by the hackers. Say, if a page has a vulnerability of loading arbitrary script when user access this URL:
http://www.example.com/apage?filename=malicious.js
Then the browser will load the malicious.js
file without any question, and the user will be hacked.
My question is, how does hackers make the user access such an URL?
As the case above and all other techniques like it, all have one precondition: the user has to do some action that they wouldn't usually do. Ff the hacker has to come to say "hi, there is something funny, take a look!" to everyone, that won't be a very effective attack.
So, are there any tricks to make this happen automatically? Or any real-life cases that cause this?
xss social-engineering
New contributor
add a comment |Â
up vote
8
down vote
favorite
As I undertand it, the basic idea of XSS is to let the user's browser execute some malicious code created by the hackers. Say, if a page has a vulnerability of loading arbitrary script when user access this URL:
http://www.example.com/apage?filename=malicious.js
Then the browser will load the malicious.js
file without any question, and the user will be hacked.
My question is, how does hackers make the user access such an URL?
As the case above and all other techniques like it, all have one precondition: the user has to do some action that they wouldn't usually do. Ff the hacker has to come to say "hi, there is something funny, take a look!" to everyone, that won't be a very effective attack.
So, are there any tricks to make this happen automatically? Or any real-life cases that cause this?
xss social-engineering
New contributor
2
"... the user did some actions that they won't do as usual..." - like, clicking on a link on some web site or in a mail? Or maybe just the usual visit to the same website as before in case of stored XSS. That's all what is needed.
â Steffen Ullrich
8 hours ago
@SteffenUllrich Thanks for comment, "stored XSS" may required some other vulnerability, if there is no way to store this url in the application. what an experienced hacker will do to use this vulnerability? spam email? that not pretty, I think.
â Hetfield Joe
7 hours ago
11
You might also want to check this question which has some more details about XSS in general.
â Christoph
6 hours ago
@Christoph very funny man! ;)
â Hetfield Joe
5 hours ago
add a comment |Â
up vote
8
down vote
favorite
up vote
8
down vote
favorite
As I undertand it, the basic idea of XSS is to let the user's browser execute some malicious code created by the hackers. Say, if a page has a vulnerability of loading arbitrary script when user access this URL:
http://www.example.com/apage?filename=malicious.js
Then the browser will load the malicious.js
file without any question, and the user will be hacked.
My question is, how does hackers make the user access such an URL?
As the case above and all other techniques like it, all have one precondition: the user has to do some action that they wouldn't usually do. Ff the hacker has to come to say "hi, there is something funny, take a look!" to everyone, that won't be a very effective attack.
So, are there any tricks to make this happen automatically? Or any real-life cases that cause this?
xss social-engineering
New contributor
As I undertand it, the basic idea of XSS is to let the user's browser execute some malicious code created by the hackers. Say, if a page has a vulnerability of loading arbitrary script when user access this URL:
http://www.example.com/apage?filename=malicious.js
Then the browser will load the malicious.js
file without any question, and the user will be hacked.
My question is, how does hackers make the user access such an URL?
As the case above and all other techniques like it, all have one precondition: the user has to do some action that they wouldn't usually do. Ff the hacker has to come to say "hi, there is something funny, take a look!" to everyone, that won't be a very effective attack.
So, are there any tricks to make this happen automatically? Or any real-life cases that cause this?
xss social-engineering
xss social-engineering
New contributor
New contributor
edited 12 mins ago
Captain Man
1074
1074
New contributor
asked 8 hours ago
Hetfield Joe
443
443
New contributor
New contributor
2
"... the user did some actions that they won't do as usual..." - like, clicking on a link on some web site or in a mail? Or maybe just the usual visit to the same website as before in case of stored XSS. That's all what is needed.
â Steffen Ullrich
8 hours ago
@SteffenUllrich Thanks for comment, "stored XSS" may required some other vulnerability, if there is no way to store this url in the application. what an experienced hacker will do to use this vulnerability? spam email? that not pretty, I think.
â Hetfield Joe
7 hours ago
11
You might also want to check this question which has some more details about XSS in general.
â Christoph
6 hours ago
@Christoph very funny man! ;)
â Hetfield Joe
5 hours ago
add a comment |Â
2
"... the user did some actions that they won't do as usual..." - like, clicking on a link on some web site or in a mail? Or maybe just the usual visit to the same website as before in case of stored XSS. That's all what is needed.
â Steffen Ullrich
8 hours ago
@SteffenUllrich Thanks for comment, "stored XSS" may required some other vulnerability, if there is no way to store this url in the application. what an experienced hacker will do to use this vulnerability? spam email? that not pretty, I think.
â Hetfield Joe
7 hours ago
11
You might also want to check this question which has some more details about XSS in general.
â Christoph
6 hours ago
@Christoph very funny man! ;)
â Hetfield Joe
5 hours ago
2
2
"... the user did some actions that they won't do as usual..." - like, clicking on a link on some web site or in a mail? Or maybe just the usual visit to the same website as before in case of stored XSS. That's all what is needed.
â Steffen Ullrich
8 hours ago
"... the user did some actions that they won't do as usual..." - like, clicking on a link on some web site or in a mail? Or maybe just the usual visit to the same website as before in case of stored XSS. That's all what is needed.
â Steffen Ullrich
8 hours ago
@SteffenUllrich Thanks for comment, "stored XSS" may required some other vulnerability, if there is no way to store this url in the application. what an experienced hacker will do to use this vulnerability? spam email? that not pretty, I think.
â Hetfield Joe
7 hours ago
@SteffenUllrich Thanks for comment, "stored XSS" may required some other vulnerability, if there is no way to store this url in the application. what an experienced hacker will do to use this vulnerability? spam email? that not pretty, I think.
â Hetfield Joe
7 hours ago
11
11
You might also want to check this question which has some more details about XSS in general.
â Christoph
6 hours ago
You might also want to check this question which has some more details about XSS in general.
â Christoph
6 hours ago
@Christoph very funny man! ;)
â Hetfield Joe
5 hours ago
@Christoph very funny man! ;)
â Hetfield Joe
5 hours ago
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
7
down vote
the user did some actions that they won't do as usual
Clicking on a link does seem like a usual action for most users.
See for example this study, in which 56% of users clicked on links in E-Mails from an unknown sender, and ~40% clicked on links send via Facebook (despite 78% being aware of the possible danger). 50% said that they didn't click the link because they didn't know the sender.
That's already an impressive success rate. If the victim knows the attacker, or if the attacker spoofs the identity of someone they know, this rate could be increased even further.
On social networks, reflected XSS might also be wormable. In addition to the malicious action, the injected script could send messages containing the link to all friends of the victim (something like this eg happened to Twitter).
In addition to E-Mail, links could also be distributed in forums, blogs, issue trackers, and so on. This for example happened to Apache.
Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it?
â Hetfield Joe
5 hours ago
In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
â allo
5 hours ago
@HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
â tim
5 hours ago
@HetfieldJoe And I'm not so sure that social networks necessarily block mass messages (see the twitter example).
â tim
5 hours ago
6
I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious â¦
â CL.
4 hours ago
 |Â
show 1 more comment
up vote
4
down vote
That's what I've always wondered as well, and when asking I was usually told that "users don't take care and click everything". Which said that way makes it sound like reflected XSS isn't really a vulnerability of software, but a vulnerability of users. All this sounded strange to me because I'm the kind of person who usually checks the link preview (hovering with the mouse on the link in the browser), and if somebody tells me to click on this question on StackExchange and I spot the weird format (see the path), I am not going to click.
However I have to say that there are ways to make reflected XSS more dangerous than it seems at first. Consider the following points:
- Automatic clicks, redirects, or similar tricks: you don't have to click, all you have to do is land on a malicious website that will redirect automatically to the target website and execute the malicious javascript. If you are logged in on the target website, the attacker will make you execute arbitrary javascript and perform malicious actions (send or delete stuff, etc.)
- Websites that typically have long or complex URLs (not user-friendly) and that the user tends to trust anyway. I tend to see this on Amazon, the links are unreadable anyway.
- Browsers that don't let you see a preview easily, like on mobile browsers or other software where it's not as simple as just hovering. I have to admit that I don't take the time to verify links on mobile, I just tap, although on mobile I only try to use a restricted selection of trusted websites.
- The attacker knows the victim, knows how to convince them to click on a link or visit a page, and the victim in some cases might even trust the attacker. A random email from a total stranger is not the same as a Facebook private message from a (malicious) acquaintance.
- Boobs and lols: pictures with boobs, lolcats, etc. can make you lose your consciousness temporarily, and you might feel like you have to click on it at once like it's a law of physics.
So as you can see the risks associated with reflected XSS can vary a lot, depending on the user, the trust given to the affected website, the possible actions on the target website, etc. Nevertheless it still remains a software vulnerability in any case, because by definition it allows arbitrary javascript execution by exploiting a weakness in input sanitization.
add a comment |Â
up vote
1
down vote
There are two main types of XSS, Reflective and persistent. Persistent XSS is when it is stored on the server, affecting other users, while reflective is not stored, but can still affect other users.
One method I've seen is to store something like a redirect is in a comment that has poor sanitising. This way, the code is stored server-side, and when someone requests the page, the code is loaded along with the comments, which then triggers the block of code. This can then redirect the victim to the attackers website, where other malicious things could be occurring, e.g. Fake login pages for credential harvesters, stacks of ads, etc.
If you need more info let me know, I can edit when I'm back at the PC and add more details.
EDIT:
For example, if a site was susceptible to this type of attack, a comment could be left that redirected all users that visited that page to a new site, this new site could be a near identical copy of the original site, designed to get you to log in again, and then steal credentials. Because people tend to use the same passwords on multiple sites, these credentials could then be used to log in elsewhere, etc.
Basically
Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used?
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
0
down vote
For some attacks the victim needs to visit the attacker's page. There are a couple of ways to do that:
- Phishing. Send the victim an email, Facebook page, LinkedIn invitation with a link pretending to be something else. The success rate of this depends on how much effort goes into the campaign, but success rates above 50% are not uncommon. Especially because the domain name matches: you try to trick users of somegoodsite.com to click on a somegoodsite.com link, and this can generally be trusted.
- Inclusion from within the site itself. Sometimes the site permits to add user content. If the attacker can add an iframe to their profile page, anyone who accesses their profile will be attacked. However, it is pretty uncommon to be able to add an iframe to any site.
- Man-in-the-middle attack. In a man-in-the-middle attack the attacker can modify unencrypted data. Even if somegoodsite.com uses HTTPS, the attacker can inject an iframe in a webpage that doesn't use HTTPS and cause your browser to visit the URL.
- Advertisements. Some sites run intrusive advertisements that load a page in an iframe or even a new window. I sometimes get these with the message that I have won a free iPhone, but you could also run them with an XSS payload. However, I think sites that allow advertisements this intrusive are pretty rare.
Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it.
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
0
down vote
The example you have given is very trivial. There are plenty of applications that have dozens of GET parameters in the URL being shared. All the attacker needs is for one of these to be vulnerable to reflected XSS in order for this to succeed. If the link someone is expecting is long and complex, and what they get is long and complex, then they may not look into each parameter.
Also, they could use a URL shortener.
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
the user did some actions that they won't do as usual
Clicking on a link does seem like a usual action for most users.
See for example this study, in which 56% of users clicked on links in E-Mails from an unknown sender, and ~40% clicked on links send via Facebook (despite 78% being aware of the possible danger). 50% said that they didn't click the link because they didn't know the sender.
That's already an impressive success rate. If the victim knows the attacker, or if the attacker spoofs the identity of someone they know, this rate could be increased even further.
On social networks, reflected XSS might also be wormable. In addition to the malicious action, the injected script could send messages containing the link to all friends of the victim (something like this eg happened to Twitter).
In addition to E-Mail, links could also be distributed in forums, blogs, issue trackers, and so on. This for example happened to Apache.
Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it?
â Hetfield Joe
5 hours ago
In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
â allo
5 hours ago
@HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
â tim
5 hours ago
@HetfieldJoe And I'm not so sure that social networks necessarily block mass messages (see the twitter example).
â tim
5 hours ago
6
I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious â¦
â CL.
4 hours ago
 |Â
show 1 more comment
up vote
7
down vote
the user did some actions that they won't do as usual
Clicking on a link does seem like a usual action for most users.
See for example this study, in which 56% of users clicked on links in E-Mails from an unknown sender, and ~40% clicked on links send via Facebook (despite 78% being aware of the possible danger). 50% said that they didn't click the link because they didn't know the sender.
That's already an impressive success rate. If the victim knows the attacker, or if the attacker spoofs the identity of someone they know, this rate could be increased even further.
On social networks, reflected XSS might also be wormable. In addition to the malicious action, the injected script could send messages containing the link to all friends of the victim (something like this eg happened to Twitter).
In addition to E-Mail, links could also be distributed in forums, blogs, issue trackers, and so on. This for example happened to Apache.
Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it?
â Hetfield Joe
5 hours ago
In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
â allo
5 hours ago
@HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
â tim
5 hours ago
@HetfieldJoe And I'm not so sure that social networks necessarily block mass messages (see the twitter example).
â tim
5 hours ago
6
I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious â¦
â CL.
4 hours ago
 |Â
show 1 more comment
up vote
7
down vote
up vote
7
down vote
the user did some actions that they won't do as usual
Clicking on a link does seem like a usual action for most users.
See for example this study, in which 56% of users clicked on links in E-Mails from an unknown sender, and ~40% clicked on links send via Facebook (despite 78% being aware of the possible danger). 50% said that they didn't click the link because they didn't know the sender.
That's already an impressive success rate. If the victim knows the attacker, or if the attacker spoofs the identity of someone they know, this rate could be increased even further.
On social networks, reflected XSS might also be wormable. In addition to the malicious action, the injected script could send messages containing the link to all friends of the victim (something like this eg happened to Twitter).
In addition to E-Mail, links could also be distributed in forums, blogs, issue trackers, and so on. This for example happened to Apache.
the user did some actions that they won't do as usual
Clicking on a link does seem like a usual action for most users.
See for example this study, in which 56% of users clicked on links in E-Mails from an unknown sender, and ~40% clicked on links send via Facebook (despite 78% being aware of the possible danger). 50% said that they didn't click the link because they didn't know the sender.
That's already an impressive success rate. If the victim knows the attacker, or if the attacker spoofs the identity of someone they know, this rate could be increased even further.
On social networks, reflected XSS might also be wormable. In addition to the malicious action, the injected script could send messages containing the link to all friends of the victim (something like this eg happened to Twitter).
In addition to E-Mail, links could also be distributed in forums, blogs, issue trackers, and so on. This for example happened to Apache.
edited 7 hours ago
answered 7 hours ago
tim
21.4k55589
21.4k55589
Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it?
â Hetfield Joe
5 hours ago
In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
â allo
5 hours ago
@HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
â tim
5 hours ago
@HetfieldJoe And I'm not so sure that social networks necessarily block mass messages (see the twitter example).
â tim
5 hours ago
6
I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious â¦
â CL.
4 hours ago
 |Â
show 1 more comment
Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it?
â Hetfield Joe
5 hours ago
In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
â allo
5 hours ago
@HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
â tim
5 hours ago
@HetfieldJoe And I'm not so sure that social networks necessarily block mass messages (see the twitter example).
â tim
5 hours ago
6
I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious â¦
â CL.
4 hours ago
Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it?
â Hetfield Joe
5 hours ago
Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it?
â Hetfield Joe
5 hours ago
In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
â allo
5 hours ago
In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
â allo
5 hours ago
@HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
â tim
5 hours ago
@HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
â tim
5 hours ago
@HetfieldJoe And I'm not so sure that social networks necessarily block mass messages (see the twitter example).
â tim
5 hours ago
@HetfieldJoe And I'm not so sure that social networks necessarily block mass messages (see the twitter example).
â tim
5 hours ago
6
6
I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious â¦
â CL.
4 hours ago
I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious â¦
â CL.
4 hours ago
 |Â
show 1 more comment
up vote
4
down vote
That's what I've always wondered as well, and when asking I was usually told that "users don't take care and click everything". Which said that way makes it sound like reflected XSS isn't really a vulnerability of software, but a vulnerability of users. All this sounded strange to me because I'm the kind of person who usually checks the link preview (hovering with the mouse on the link in the browser), and if somebody tells me to click on this question on StackExchange and I spot the weird format (see the path), I am not going to click.
However I have to say that there are ways to make reflected XSS more dangerous than it seems at first. Consider the following points:
- Automatic clicks, redirects, or similar tricks: you don't have to click, all you have to do is land on a malicious website that will redirect automatically to the target website and execute the malicious javascript. If you are logged in on the target website, the attacker will make you execute arbitrary javascript and perform malicious actions (send or delete stuff, etc.)
- Websites that typically have long or complex URLs (not user-friendly) and that the user tends to trust anyway. I tend to see this on Amazon, the links are unreadable anyway.
- Browsers that don't let you see a preview easily, like on mobile browsers or other software where it's not as simple as just hovering. I have to admit that I don't take the time to verify links on mobile, I just tap, although on mobile I only try to use a restricted selection of trusted websites.
- The attacker knows the victim, knows how to convince them to click on a link or visit a page, and the victim in some cases might even trust the attacker. A random email from a total stranger is not the same as a Facebook private message from a (malicious) acquaintance.
- Boobs and lols: pictures with boobs, lolcats, etc. can make you lose your consciousness temporarily, and you might feel like you have to click on it at once like it's a law of physics.
So as you can see the risks associated with reflected XSS can vary a lot, depending on the user, the trust given to the affected website, the possible actions on the target website, etc. Nevertheless it still remains a software vulnerability in any case, because by definition it allows arbitrary javascript execution by exploiting a weakness in input sanitization.
add a comment |Â
up vote
4
down vote
That's what I've always wondered as well, and when asking I was usually told that "users don't take care and click everything". Which said that way makes it sound like reflected XSS isn't really a vulnerability of software, but a vulnerability of users. All this sounded strange to me because I'm the kind of person who usually checks the link preview (hovering with the mouse on the link in the browser), and if somebody tells me to click on this question on StackExchange and I spot the weird format (see the path), I am not going to click.
However I have to say that there are ways to make reflected XSS more dangerous than it seems at first. Consider the following points:
- Automatic clicks, redirects, or similar tricks: you don't have to click, all you have to do is land on a malicious website that will redirect automatically to the target website and execute the malicious javascript. If you are logged in on the target website, the attacker will make you execute arbitrary javascript and perform malicious actions (send or delete stuff, etc.)
- Websites that typically have long or complex URLs (not user-friendly) and that the user tends to trust anyway. I tend to see this on Amazon, the links are unreadable anyway.
- Browsers that don't let you see a preview easily, like on mobile browsers or other software where it's not as simple as just hovering. I have to admit that I don't take the time to verify links on mobile, I just tap, although on mobile I only try to use a restricted selection of trusted websites.
- The attacker knows the victim, knows how to convince them to click on a link or visit a page, and the victim in some cases might even trust the attacker. A random email from a total stranger is not the same as a Facebook private message from a (malicious) acquaintance.
- Boobs and lols: pictures with boobs, lolcats, etc. can make you lose your consciousness temporarily, and you might feel like you have to click on it at once like it's a law of physics.
So as you can see the risks associated with reflected XSS can vary a lot, depending on the user, the trust given to the affected website, the possible actions on the target website, etc. Nevertheless it still remains a software vulnerability in any case, because by definition it allows arbitrary javascript execution by exploiting a weakness in input sanitization.
add a comment |Â
up vote
4
down vote
up vote
4
down vote
That's what I've always wondered as well, and when asking I was usually told that "users don't take care and click everything". Which said that way makes it sound like reflected XSS isn't really a vulnerability of software, but a vulnerability of users. All this sounded strange to me because I'm the kind of person who usually checks the link preview (hovering with the mouse on the link in the browser), and if somebody tells me to click on this question on StackExchange and I spot the weird format (see the path), I am not going to click.
However I have to say that there are ways to make reflected XSS more dangerous than it seems at first. Consider the following points:
- Automatic clicks, redirects, or similar tricks: you don't have to click, all you have to do is land on a malicious website that will redirect automatically to the target website and execute the malicious javascript. If you are logged in on the target website, the attacker will make you execute arbitrary javascript and perform malicious actions (send or delete stuff, etc.)
- Websites that typically have long or complex URLs (not user-friendly) and that the user tends to trust anyway. I tend to see this on Amazon, the links are unreadable anyway.
- Browsers that don't let you see a preview easily, like on mobile browsers or other software where it's not as simple as just hovering. I have to admit that I don't take the time to verify links on mobile, I just tap, although on mobile I only try to use a restricted selection of trusted websites.
- The attacker knows the victim, knows how to convince them to click on a link or visit a page, and the victim in some cases might even trust the attacker. A random email from a total stranger is not the same as a Facebook private message from a (malicious) acquaintance.
- Boobs and lols: pictures with boobs, lolcats, etc. can make you lose your consciousness temporarily, and you might feel like you have to click on it at once like it's a law of physics.
So as you can see the risks associated with reflected XSS can vary a lot, depending on the user, the trust given to the affected website, the possible actions on the target website, etc. Nevertheless it still remains a software vulnerability in any case, because by definition it allows arbitrary javascript execution by exploiting a weakness in input sanitization.
That's what I've always wondered as well, and when asking I was usually told that "users don't take care and click everything". Which said that way makes it sound like reflected XSS isn't really a vulnerability of software, but a vulnerability of users. All this sounded strange to me because I'm the kind of person who usually checks the link preview (hovering with the mouse on the link in the browser), and if somebody tells me to click on this question on StackExchange and I spot the weird format (see the path), I am not going to click.
However I have to say that there are ways to make reflected XSS more dangerous than it seems at first. Consider the following points:
- Automatic clicks, redirects, or similar tricks: you don't have to click, all you have to do is land on a malicious website that will redirect automatically to the target website and execute the malicious javascript. If you are logged in on the target website, the attacker will make you execute arbitrary javascript and perform malicious actions (send or delete stuff, etc.)
- Websites that typically have long or complex URLs (not user-friendly) and that the user tends to trust anyway. I tend to see this on Amazon, the links are unreadable anyway.
- Browsers that don't let you see a preview easily, like on mobile browsers or other software where it's not as simple as just hovering. I have to admit that I don't take the time to verify links on mobile, I just tap, although on mobile I only try to use a restricted selection of trusted websites.
- The attacker knows the victim, knows how to convince them to click on a link or visit a page, and the victim in some cases might even trust the attacker. A random email from a total stranger is not the same as a Facebook private message from a (malicious) acquaintance.
- Boobs and lols: pictures with boobs, lolcats, etc. can make you lose your consciousness temporarily, and you might feel like you have to click on it at once like it's a law of physics.
So as you can see the risks associated with reflected XSS can vary a lot, depending on the user, the trust given to the affected website, the possible actions on the target website, etc. Nevertheless it still remains a software vulnerability in any case, because by definition it allows arbitrary javascript execution by exploiting a weakness in input sanitization.
answered 5 hours ago
reed
1,5251316
1,5251316
add a comment |Â
add a comment |Â
up vote
1
down vote
There are two main types of XSS, Reflective and persistent. Persistent XSS is when it is stored on the server, affecting other users, while reflective is not stored, but can still affect other users.
One method I've seen is to store something like a redirect is in a comment that has poor sanitising. This way, the code is stored server-side, and when someone requests the page, the code is loaded along with the comments, which then triggers the block of code. This can then redirect the victim to the attackers website, where other malicious things could be occurring, e.g. Fake login pages for credential harvesters, stacks of ads, etc.
If you need more info let me know, I can edit when I'm back at the PC and add more details.
EDIT:
For example, if a site was susceptible to this type of attack, a comment could be left that redirected all users that visited that page to a new site, this new site could be a near identical copy of the original site, designed to get you to log in again, and then steal credentials. Because people tend to use the same passwords on multiple sites, these credentials could then be used to log in elsewhere, etc.
Basically
Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used?
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
1
down vote
There are two main types of XSS, Reflective and persistent. Persistent XSS is when it is stored on the server, affecting other users, while reflective is not stored, but can still affect other users.
One method I've seen is to store something like a redirect is in a comment that has poor sanitising. This way, the code is stored server-side, and when someone requests the page, the code is loaded along with the comments, which then triggers the block of code. This can then redirect the victim to the attackers website, where other malicious things could be occurring, e.g. Fake login pages for credential harvesters, stacks of ads, etc.
If you need more info let me know, I can edit when I'm back at the PC and add more details.
EDIT:
For example, if a site was susceptible to this type of attack, a comment could be left that redirected all users that visited that page to a new site, this new site could be a near identical copy of the original site, designed to get you to log in again, and then steal credentials. Because people tend to use the same passwords on multiple sites, these credentials could then be used to log in elsewhere, etc.
Basically
Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used?
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
There are two main types of XSS, Reflective and persistent. Persistent XSS is when it is stored on the server, affecting other users, while reflective is not stored, but can still affect other users.
One method I've seen is to store something like a redirect is in a comment that has poor sanitising. This way, the code is stored server-side, and when someone requests the page, the code is loaded along with the comments, which then triggers the block of code. This can then redirect the victim to the attackers website, where other malicious things could be occurring, e.g. Fake login pages for credential harvesters, stacks of ads, etc.
If you need more info let me know, I can edit when I'm back at the PC and add more details.
EDIT:
For example, if a site was susceptible to this type of attack, a comment could be left that redirected all users that visited that page to a new site, this new site could be a near identical copy of the original site, designed to get you to log in again, and then steal credentials. Because people tend to use the same passwords on multiple sites, these credentials could then be used to log in elsewhere, etc.
Basically
There are two main types of XSS, Reflective and persistent. Persistent XSS is when it is stored on the server, affecting other users, while reflective is not stored, but can still affect other users.
One method I've seen is to store something like a redirect is in a comment that has poor sanitising. This way, the code is stored server-side, and when someone requests the page, the code is loaded along with the comments, which then triggers the block of code. This can then redirect the victim to the attackers website, where other malicious things could be occurring, e.g. Fake login pages for credential harvesters, stacks of ads, etc.
If you need more info let me know, I can edit when I'm back at the PC and add more details.
EDIT:
For example, if a site was susceptible to this type of attack, a comment could be left that redirected all users that visited that page to a new site, this new site could be a near identical copy of the original site, designed to get you to log in again, and then steal credentials. Because people tend to use the same passwords on multiple sites, these credentials could then be used to log in elsewhere, etc.
Basically
edited 3 hours ago
answered 7 hours ago
Connor J
79519
79519
Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used?
â Hetfield Joe
6 hours ago
add a comment |Â
Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used?
â Hetfield Joe
6 hours ago
Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used?
â Hetfield Joe
6 hours ago
Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used?
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
0
down vote
For some attacks the victim needs to visit the attacker's page. There are a couple of ways to do that:
- Phishing. Send the victim an email, Facebook page, LinkedIn invitation with a link pretending to be something else. The success rate of this depends on how much effort goes into the campaign, but success rates above 50% are not uncommon. Especially because the domain name matches: you try to trick users of somegoodsite.com to click on a somegoodsite.com link, and this can generally be trusted.
- Inclusion from within the site itself. Sometimes the site permits to add user content. If the attacker can add an iframe to their profile page, anyone who accesses their profile will be attacked. However, it is pretty uncommon to be able to add an iframe to any site.
- Man-in-the-middle attack. In a man-in-the-middle attack the attacker can modify unencrypted data. Even if somegoodsite.com uses HTTPS, the attacker can inject an iframe in a webpage that doesn't use HTTPS and cause your browser to visit the URL.
- Advertisements. Some sites run intrusive advertisements that load a page in an iframe or even a new window. I sometimes get these with the message that I have won a free iPhone, but you could also run them with an XSS payload. However, I think sites that allow advertisements this intrusive are pretty rare.
Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it.
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
0
down vote
For some attacks the victim needs to visit the attacker's page. There are a couple of ways to do that:
- Phishing. Send the victim an email, Facebook page, LinkedIn invitation with a link pretending to be something else. The success rate of this depends on how much effort goes into the campaign, but success rates above 50% are not uncommon. Especially because the domain name matches: you try to trick users of somegoodsite.com to click on a somegoodsite.com link, and this can generally be trusted.
- Inclusion from within the site itself. Sometimes the site permits to add user content. If the attacker can add an iframe to their profile page, anyone who accesses their profile will be attacked. However, it is pretty uncommon to be able to add an iframe to any site.
- Man-in-the-middle attack. In a man-in-the-middle attack the attacker can modify unencrypted data. Even if somegoodsite.com uses HTTPS, the attacker can inject an iframe in a webpage that doesn't use HTTPS and cause your browser to visit the URL.
- Advertisements. Some sites run intrusive advertisements that load a page in an iframe or even a new window. I sometimes get these with the message that I have won a free iPhone, but you could also run them with an XSS payload. However, I think sites that allow advertisements this intrusive are pretty rare.
Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it.
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
For some attacks the victim needs to visit the attacker's page. There are a couple of ways to do that:
- Phishing. Send the victim an email, Facebook page, LinkedIn invitation with a link pretending to be something else. The success rate of this depends on how much effort goes into the campaign, but success rates above 50% are not uncommon. Especially because the domain name matches: you try to trick users of somegoodsite.com to click on a somegoodsite.com link, and this can generally be trusted.
- Inclusion from within the site itself. Sometimes the site permits to add user content. If the attacker can add an iframe to their profile page, anyone who accesses their profile will be attacked. However, it is pretty uncommon to be able to add an iframe to any site.
- Man-in-the-middle attack. In a man-in-the-middle attack the attacker can modify unencrypted data. Even if somegoodsite.com uses HTTPS, the attacker can inject an iframe in a webpage that doesn't use HTTPS and cause your browser to visit the URL.
- Advertisements. Some sites run intrusive advertisements that load a page in an iframe or even a new window. I sometimes get these with the message that I have won a free iPhone, but you could also run them with an XSS payload. However, I think sites that allow advertisements this intrusive are pretty rare.
For some attacks the victim needs to visit the attacker's page. There are a couple of ways to do that:
- Phishing. Send the victim an email, Facebook page, LinkedIn invitation with a link pretending to be something else. The success rate of this depends on how much effort goes into the campaign, but success rates above 50% are not uncommon. Especially because the domain name matches: you try to trick users of somegoodsite.com to click on a somegoodsite.com link, and this can generally be trusted.
- Inclusion from within the site itself. Sometimes the site permits to add user content. If the attacker can add an iframe to their profile page, anyone who accesses their profile will be attacked. However, it is pretty uncommon to be able to add an iframe to any site.
- Man-in-the-middle attack. In a man-in-the-middle attack the attacker can modify unencrypted data. Even if somegoodsite.com uses HTTPS, the attacker can inject an iframe in a webpage that doesn't use HTTPS and cause your browser to visit the URL.
- Advertisements. Some sites run intrusive advertisements that load a page in an iframe or even a new window. I sometimes get these with the message that I have won a free iPhone, but you could also run them with an XSS payload. However, I think sites that allow advertisements this intrusive are pretty rare.
answered 7 hours ago
Sjoerd
15k73554
15k73554
Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it.
â Hetfield Joe
6 hours ago
add a comment |Â
Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it.
â Hetfield Joe
6 hours ago
Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it.
â Hetfield Joe
6 hours ago
Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it.
â Hetfield Joe
6 hours ago
add a comment |Â
up vote
0
down vote
The example you have given is very trivial. There are plenty of applications that have dozens of GET parameters in the URL being shared. All the attacker needs is for one of these to be vulnerable to reflected XSS in order for this to succeed. If the link someone is expecting is long and complex, and what they get is long and complex, then they may not look into each parameter.
Also, they could use a URL shortener.
add a comment |Â
up vote
0
down vote
The example you have given is very trivial. There are plenty of applications that have dozens of GET parameters in the URL being shared. All the attacker needs is for one of these to be vulnerable to reflected XSS in order for this to succeed. If the link someone is expecting is long and complex, and what they get is long and complex, then they may not look into each parameter.
Also, they could use a URL shortener.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
The example you have given is very trivial. There are plenty of applications that have dozens of GET parameters in the URL being shared. All the attacker needs is for one of these to be vulnerable to reflected XSS in order for this to succeed. If the link someone is expecting is long and complex, and what they get is long and complex, then they may not look into each parameter.
Also, they could use a URL shortener.
The example you have given is very trivial. There are plenty of applications that have dozens of GET parameters in the URL being shared. All the attacker needs is for one of these to be vulnerable to reflected XSS in order for this to succeed. If the link someone is expecting is long and complex, and what they get is long and complex, then they may not look into each parameter.
Also, they could use a URL shortener.
answered 4 hours ago
Richard
21018
21018
add a comment |Â
add a comment |Â
Hetfield Joe is a new contributor. Be nice, and check out our Code of Conduct.
Hetfield Joe is a new contributor. Be nice, and check out our Code of Conduct.
Hetfield Joe is a new contributor. Be nice, and check out our Code of Conduct.
Hetfield Joe is a new contributor. Be nice, and check out our Code of Conduct.
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f194037%2fhow-do-hackers-make-the-victim-access-an-xss-attack-url%23new-answer', 'question_page');
);
Post as a guest
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
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
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
2
"... the user did some actions that they won't do as usual..." - like, clicking on a link on some web site or in a mail? Or maybe just the usual visit to the same website as before in case of stored XSS. That's all what is needed.
â Steffen Ullrich
8 hours ago
@SteffenUllrich Thanks for comment, "stored XSS" may required some other vulnerability, if there is no way to store this url in the application. what an experienced hacker will do to use this vulnerability? spam email? that not pretty, I think.
â Hetfield Joe
7 hours ago
11
You might also want to check this question which has some more details about XSS in general.
â Christoph
6 hours ago
@Christoph very funny man! ;)
â Hetfield Joe
5 hours ago