Open ldionmarcil opened 10 months ago
Thanks for the feedback. We'll pass this on and register your interest in this feature to help us decide what we should focus on with BChecks in the future.
In the meantime would 'send request (raw)' help? https://portswigger.net/burp/documentation/scanner/bchecks/bcheck-definition-reference
Thanks for your response, no it would not help, because the use case is to inject payloads in injection points (parameters, for example) without encoding.
As far as I can tell from the documentation, raw requires you to write the whole HTTP request from scratch.
@ldionmarcil - Sorry that's not going to help. We've got this request logged so we can review it as we look at what features to add next.
Thanks for the feedback. We'll pass this on and register your interest in this feature to help us decide what we should focus on with BChecks in the future.
In the meantime would 'send request (raw)' help? https://portswigger.net/burp/documentation/scanner/bchecks/bcheck-definition-reference
I have a case some character in my payloads get coded. My case : i passed this payload "%0Aexpr 1337 * 1337" the result the character "%" get encoded which makes the payload useless in my case, i hope if there's a function (i.e ignore_coding('%')) that return the character without encoding.
regards
Thanks for the update. We'll pass on that example use case too :)
:+1 For this, payload automatically encoded cause it didn't work.
We've added your vote for this, too.
+1 for this too. hopefully Burp will update soon.
Thanks for getting in touch. We've added your vote. I'm afraid we can't make any promises just yet.
@ldionmarcil @ayadim @Michelle-PortSwigger My friend just found another way, use send request called
instead of send payload
the payload would use the original payload (doesn't encoding).
Thanks for sharing that :)
Hi all, while writing a "given insertion point then" BCheck, I noticed that my appended payloads would automatically get URL encoded in GET parameters. Any plans on making this optional? For example, this would make finding some SSI injections and ESI injections impossible.
ie:
Expected behaviour, the vulnerable app would echo & the web server would evaluate the SSI tag. request:
GET /?param=foo<!--#echo var=\"HTTP_USER_AGENT\" -->
response:foo<!--#echo var="HTTP_USER_AGENT" -->
Observed behaviour, the vulnerable app receives an URL encoded payload, the server does not see the SSI tag because it is URL encoded, thus we get a false negative: request:
GET /?param=foo%3c!--%23echo%20var%3d%22HTTP_USER_AGENT%22%20--%3e
response:foo%3c!--%23echo%20var%3d%22HTTP_USER_AGENT%22%20--%3e