-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Param Digger Tracker #7694
Comments
There are some exceptions when using the header guesser, e.g.:
|
That shouldn't have happened tho. Will check again why its happening.
…On Fri, Apr 21, 2023, 10:24 PM thc202 ***@***.***> wrote:
There are some exceptions when using the header guesser, e.g.:
[ZAP-ParamGuesser-0-thread-2] ERROR org.zaproxy.addon.paramdigger.HeaderGuesser - java.lang.NullPointerException
java.lang.NullPointerException: null
at org.zaproxy.addon.paramdigger.HeaderGuesser.checkFirstRequestPoisoning(HeaderGuesser.java:320) ~[?:?]
at org.zaproxy.addon.paramdigger.HeaderGuesser.forwardTemplate(HeaderGuesser.java:218) ~[?:?]
at org.zaproxy.addon.paramdigger.HeaderGuesser.forwardingHeaderGuess(HeaderGuesser.java:182) ~[?:?]
at org.zaproxy.addon.paramdigger.HeaderGuesser.startGuess(HeaderGuesser.java:164) ~[?:?]
at org.zaproxy.addon.paramdigger.HeaderGuesser.run(HeaderGuesser.java:132) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
—
Reply to this email directly, view it on GitHub
<#7694 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AN6F3GM7M3ZE3VN5JQYHMQLXCK3SXANCNFSM6AAAAAAT4ZMZEE>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
You can reproduce with the following server (extender script), e.g.: var address = "0.0.0.0"
var port = 9000
var HttpResponseHeader = Java.type("org.parosproxy.paros.network.HttpResponseHeader")
var extensionNetwork = control.getExtensionLoader().getExtension("ExtensionNetwork")
var server
function messageHandler(ctx, msg) {
ctx.overridden()
msg.setResponseHeader(new HttpResponseHeader("HTTP/1.1 200\r\nConnection: close"))
}
function install(helper) {
server = extensionNetwork.createHttpServer(messageHandler)
server.start(address, port)
}
function uninstall(helper) {
server.stop()
} |
You need to specify the method and wordlist right? :) |
It's using the defaults, GET and Predefined. |
While the patch for this is underway... I noticed a miss in my detection but couldn't pinpoint why it is happening..
Response with no seeming reflection:
But when I send the same using the requester tab/ manually. I get a reflection (
Edit: I forgot to mention I did find a reflection on the same tag with the Host Header successfully with the add-on :). Don't know if it can be exploited tho. |
I think I'm missing some configuration for |
Re: Edit 2, so it did work in the end? Or you think you’ve identified the potential discrepancy? |
Working out a fix to the rookie mistake. The cache controller needs a Fastly/Varnish Caching patch :) which I'm incorporating into the fix. |
I had a "PURGE" and "FASTLYPURGE" logic which is interfering in the detection :) |
More context:
Response (No
After this, I'm stupidly checking for caching... :) |
It's been four years since I wrote that lab, if you want any changes so you
can test things I can see what I can do but can't promise.
…On Sun, 23 Apr 2023, 16:34 Arkaprabha Chakraborty, ***@***.***> wrote:
More context:
Request:
PURGE https://005a3c92.poison.digi.ninja:2443/basic.php?fcbz=1 HTTP/1.1
Host: 005a3c92.poison.digi.ninja:2443
Response (No X-Varnish Header and no Age Header as well):
HTTP/1.1 200 OK
Date: Sun, 23 Apr 2023 15:04:32 GMT
Server: Apache
Strict-Transport-Security: max-age=63072000
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer-when-downgrade
content-length: 1038
After this, I'm stupidly checking for caching... :)
—
Reply to this email directly, view it on GitHub
<#7694 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA4SWMS75ARY32E6HNJMLDXCVDYPANCNFSM6AAAAAAT4ZMZEE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thanks @digininja! But your 4-year-old work isn't that bad tho :). |
Fixed... all it needed was some sleepy time to detect the caching :P |
The requests used by paramdigger are missing a lot of headers from the original request. Original request:
paramdigger request:
On a bug bounty I'm working, the missing headers are triggering cloudfront to deny the requests. |
You're missing the headers that are generally present when a request has
been generated by a browser.
Configuring ZAP to have these headers for every request might help.
Thanks
Arka
…On Thu, Feb 15, 2024, 8:19 PM Patrick Double ***@***.***> wrote:
The requests used by paramdigger are missing a lot of headers from the
original request.
Original request:
GET http://manager.htb/search.html HTTP/1.1
host: manager.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Upgrade-Insecure-Requests: 1
paramdigger request:
GET http://manager.htb/search.html?zap=123 HTTP/1.1
host: manager.htb
On a bug bounty I'm working, the missing headers are triggering cloudfront
to deny the requests.
—
Reply to this email directly, view it on GitHub
<#7694 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AN6F3GKXROUGY4FASKP53K3YTYN7DAVCNFSM6AAAAAAT4ZMZEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBWGI2DQOJQGU>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
When using the context menu on a request to attack using paramdigger, it seems reasonable for the user to expect the attack requests will look as much like the original request as reasonable. Configuring these headers before running paramdigger isn't the best experience, especially if they include things like session cookies. Is there a reason why the original request headers aren't included? |
@ArkaprabhaChakraborty had there been a reason for removing all the request headers? |
Yes. One of the reasons is that Header brute force supplies a list of
headers from a wordlist. Secondly it helps in detection of caching
mechanism for web cache poisoning.
That being said, I think I should provide an option to preserve the
original request headers.
Thanks
Arka
…On Sun, Feb 18, 2024, 2:42 AM Rick M ***@***.***> wrote:
@ArkaprabhaChakraborty <https://github.com/ArkaprabhaChakraborty> had
there been a reason for removing all the request headers?
—
Reply to this email directly, view it on GitHub
<#7694 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AN6F3GNI3ESMLB633RV5RW3YUEMMXAVCNFSM6AAAAAAT4ZMZEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQGMZTSNZVHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thanks, I'll look at adding a button or something. |
This is the list of tasks underway for the Param Digger add-on for ZAP
The text was updated successfully, but these errors were encountered: