nuclei
nuclei copied to clipboard
response discrepancy issue with headless protocol
Nuclei version:
latest, dev
Current Behavior:
headless response with encoded html tags
Expected Behavior:
same as actual dom
Steps To Reproduce:
echo "http://pdteam.amanrawat.in/xss.html?q=test" | ./nuclei -t dom-xss.yaml -headless -debug
id: dom-xss
info:
name: DOM Cross Site Scripting
author: theamanrawat
severity: medium
tags: xss,dom,dast
variables:
first: "{{rand_int(10000, 99999)}}"
headless:
- steps:
- action: navigate
args:
url: "{{BaseURL}}"
- action: waitload
payloads:
reflection:
- "'\"><{{first}}"
fuzzing:
- part: query
type: postfix
mode: single
fuzz:
- "{{reflection}}"
stop-at-first-match: true
matchers-condition: and
matchers:
- type: word
part: body
words:
- "{{reflection}}"
- type: word
part: header
words:
- "text/html"
Another example is where the actual response is HTML encoded and nuclei see it as unencoded.
test2.yaml
id: reflected-xss
info:
name: test
author: test
severity: info
headless:
- steps:
- args:
url: "{{BaseURL}}"
action: navigate
- action: waitload
fuzzing:
- part: query
type: postfix
mode: single
fuzz:
- '"><pwnd>'
matchers:
- type: word
part: body
words:
- "><pwnd>"
nuclei -t test2.yaml -u 'https://activities.marriott.com/berlin-p/things-to-do?query=ID%3A0PG28IPO005H4"><pwnd>' -headless
Original response:
Nuclei headless in debug mode:
Hello @tarunKoyalwar, any update on this?
Hi @ehsandeep. Bumping this to see if there's any update on the progress of this bug.
I don't think this is a bug but rather the standard behaviour of browsers. The code visible within the browser preview of the DOM is a fake version of the raw unescaped one. Under the hoods the real raw code is the same retrieved by nuclei. Still within the code it would be appropriate to change:
html, err := page.Page().Element("html")
if err == nil {
responseBody, _ = html.HTML()
}
to just (ref. https://github.com/go-rod/rod/issues/897)
html, err := page.Page().Html()
This can be verified by manually copying from the browser the expected version and pasting it on any editor (like sublimetext), the copied data should match the nuclei unencoded/unescaped one.
If it is not a bug, then the template is not correct and the match should follow the pattern of this response:
<rnd></rnd>
when input is "><rnd>
In my opinion it is fine like this, the issue seems in the template :)