Toxssin :-- A POST-XSS exploitation tool

 Toxssin:-- A POST-XSS exploitation tool.

Toxssin is an open-source penetration testing tool that automates the process of exploiting Cross-Site Scripting (XSS) vulnerabilities. It consists of an HTTPS server that works as an interpreter for the traffic generated by the malicious JavaScript payload that powers this tool (toxin.js).

Capabilities

By default, toxssin intercepts:

• cookies (if HttpOnly not present),

• keystrokes,

• paste events,

• input change events,

• file selections,

• form submissions,

• server responses,

• table data (static as well as updates)

Most importantly, toxssin:

• attempts to maintain XSS persistence while the user browses the website by intercepting http requests & responses and re-writing the document,

• supports session management, meaning that, you can use it to exploit reflected as well as stored XSS,

• supports custom JS script execution against sessions,

• automatically logs every session.

Installation & Usage

git clone https://github.com/t3l3machus/toxssin

cd ./toxssin pip3 install -r requirements.txt

To start toxssin.py, you will need to supply ssl certificate and private key files.

If you don’t own a domain with a trusted certificate, you can issue and use self-signed certificates with the following command (although this won’t take you far):

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

It is strongly recommended to run toxssin with a trusted certificate (see How to get a Valid Certificate in this document). That said, you can start the toxssin server like this:

# python3 toxssin.py -u https://your.domain.com -c /your/certificate.pem -k /your/privkey.pem

XSS Exploitation Obstacles

In my experience, there are 4 major obstacles when it comes to Cross-Site Scripting attacks attempting to include external JS scripts:

1. the “Mixed Content” error, which can be resolved by serving the JavaScript payload via https (even with a self-signed certificate).

2. the “NET::ERR_CERT_AUTHORITY_INVALID” error, which indicates that the server’s certificate is untrusted / expired and can be bypassed by using a certificate issued by a trusted Authority.

3. Cross-origin resource sharing (CORS), which is handled appropriately by the toxssin server.

4. Content-Security-Policy header with the script-src set to specific domain(s) only will block scripts with cross-domain src from loading. Toxssin relies on the eval() function to deliver its poison, so, if the website has a CSP and the unsafe-eval source expression is not specified in the script-src directive, the attack will most likely fail (i’m working on a second poison delivery method to work around this).

References 

https://securityonline.info/toxssin-post-xss-exploitation-tool/ https://professionalhackers.in/toxssin-an-xss-exploitation-command-line-interface-andpayload-generator/ 

https://kalilinuxtutorials.com/toxssin/