1

I was looking into bWAPP. In the HTML GET Injection section, I entered

%25%33%63%25%36%38%25%33%31%25%33%65%25%36%31%25%37%30%25%37%30%25%36%63%25%36%35%25%33%63%25%32%66%25%36%38%25%33%31%25%33%65 

as payload and it worked on burp suite.

This was the result: enter image description here

On the other hand, I submitted the encoded html payload in the form field and the exploit didnt work on the browser.

Here is the output: enter image description here

Also, I right-clicked burp repeater window>Request in browser>In original session and it worked.

I am really not able to understand why it is so.

5

When using Burp, you are injecting the code directly to the server without the browser-side javascript or tools.

When you enter the payload on the browser, it is processed by the browser-side javascript and tools.

So, what you are seeing is the potential that the browser is sanitising the input before sending to the server. That's why tools like Burp are so useful for testing.

  • 2
    OP says they "submitted the encoded html payload in the form field". So as I understand it, they entered %3c in the form field which will be sent to the server as %253c and therefore just gets URL-decoded back to %3c without triggering XSS. So instead of putting %3c in the form field they should enter an unencoded <. So to me this seems to be about OP misunderstanding that form submissions are URL-encoded, not about input sanitization. – Arminius Dec 26 '18 at 15:47
  • 2
    That could also be true. Sanitizing or encoding. Or any other pre-submission handling. – schroeder Dec 26 '18 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.