Can someone explain a concept from XSS? – Digitalmunition

Home Forums Can someone explain a concept from XSS?

This topic contains 1 reply, has 2 voices, and was last updated by  attcker 1 month, 2 weeks ago.

  • Author
  • #335953


    Hey Folks,

    As the title suggests, I’m a little stuck on an aspect of cross-site-scripting.
    I understand that it may be done by inserting script tags to the page to run Javascript to capture data and other stuff.
    What I don’t get is how this affects other users on other browsers. I understand that you can insert code which will send other users’ cookies and such to your own server and gain access to websites that way. Do these scripts get passed to the server somehow? My understanding of manipulating webpages through the browser is that it only affects content locally.

    I appreciate any insight you can provide.

    Cheers. 🙂

  • #335954


    XSS attacks are client-side attacks. As you mentioned, one can steal cookies of users using XSS. XSS payloads in the stored XSS attacks are injected to the vulnerable webpage in the web server. So, you can steal cookies of the visitors of this webpage. However, since XSS is a client-side attack, it does not directly affect the web server.

  • #335955


    Theres two most popular types of XSS

    Reflected and Stored.

    A Reflected XSS only need the client, like using some exploitable URL (think of a search tool, like /site/products/search=<query>). Instead using a proper query, you can change the URL and inject some JavaScript code there.

    Then, you use a URL Shortner and send a phishing (fake) message to other users. Bang! You are executing malicious code in their browser.

    Using Stored XSS is a bit different. You can think of comments section of a website. What if someone write an JavaScript code instead a normal text? When any other person loads the comments section, the script will be executed too, because its a content of the webpage.

    That way, the XSS is stored at the website and is executed when someone loads the page.

    Thats the ways one can abuse of XSS. If you want to know more, check this out!

  • #335956


    When PHP became popular, a lot of people were templating pages just by adding URL parameters to read a file. Something like []( However, by default there was no check of the file, so you were able to do something like []( to check files on the server and in the worst case: []( <- server executed your code, there was usually a code like this:

    `echo “31337 stream tcp nowait wwwdata /bin/bash bash -i” >> /tmp/config.conf; /usr/sbin/inetd /tmp/config.conf`

    It was executing Inetd running a shell on 31337, nowadays, there will be some code to open reverse shell 🙂

  • #335957


    Imagine a website that’s a forum where users can upload text and images. Let’s say an attacker makes a post on the forum containing some malicious javascript. Everytime another user loads the particular page where the attackers post is located that js will execute in their browser. Does that help at all? Make sure you read up on the different types of xss.

  • #335958


    There is also /r/xss 😉

  • #335959


    The basic concept is this: the code in the page that you load eventually sends a command or request to the server. In XSS, you edit that command or request to try to get elevated access to the server or to get the site to give you information it would not give otherwise.

    It’s “cross-site” because you are using an altered version of their site (living on your computer) to send a command across to their site.

  • #335960


    Here’s an oldie but a goodie from the MySpace days, the “Samy Worm”: [](

    MySpace allowed users to write custom HTML code (and CSS) to affect the look and feel of their profile page (set custom background images, change the colors and fonts, embed YouTube videos that auto-play when you access their page, etc.), it was like a Geocities mixed with social media.

    MySpace would prevent users from writing a “<script>” tag by substituting out the word “<script>” with “..” or so, along with a collection of script-related keywords like getElementById, onload, onerror and so on. But as seen in the above link, you could work around MySpace’s filters and end up embedding a JavaScript on your profile page, which would be stored in the server’s database and be served up to all users who access your page. In the Samy Worm’s case, the script was programmed to make back-end API requests to send Samy a friend request automatically, as well as copy-paste the script payload onto *your own* profile page, so now any of *your* friends who look at your page would also run the XSS script and the worm propagated exponentially.

    This sort of attack was very common on sites which allowed custom user HTML input, and is a very tricky problem to sanitize effectively, as there’s lots of ways that “HTML tag soup” can be interpreted in different browsers. It’s probably a huge reason why sites like Facebook moved away from allowing users to include custom HTML, and on a similar note, is why sites that DO allow custom web pages will put user sites on a different domain name altogether from the company’s main domain (so no cookies are shared and an XSS has lessened impact to cause harm).

You must be logged in to reply to this topic.