Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Separation of query string

tkishiya Feb 08, 2015 06:50AM UTC

Hi,

When I access a URL like following Burp recognizes one parameter its name="JSESSIONID", value="foo?bar=baz".

http://localhost/;JSESSIONID=foo?bar=baz

Screenshots:
http://imgur.com/OY9NkvU (Raw tab)
http://imgur.com/sO1HAaE (Params tab)

Burp Suite v1.6.10
Windows 7 64bit


Dafydd Stuttard Feb 10, 2015 11:25AM UTC Support Center agent

This application is using a non-standard query string format. There isn’t currently a way to configure custom query string separators, sorry.

You can do this manually when using the Intruder or Scanner tools. If you send a request to Intruder, you can position the payload markers wherever is appropriate based on the custom query string separator, and then use the “Actively scan defined insertion points” from the Intruder menu.


tkishiya Feb 10, 2015 02:54PM UTC
Thank you Dafydd, but which character is "non-standard"?

I expected burp to parse in this way:
- Path parameter (starts with ";") : JSESSIONID=foo
- Query parameter (starts with "?") : bar=baz

Dafydd Stuttard Feb 11, 2015 12:40PM UTC Support Center agent

Normally, the query string starts with ? and parameters are separated with &. A very small number of apps use ; after the URL file part to indicate the start of query string-like data. In this case, the app is doing both, with two sets of parameters, the first preceded by ; and the second by &. Burp is treating the query string as starting at the ; and then splitting what comes next on the & character to identify individual parameters. It isn’t recognizing the ? as a parameter separator.

It’s possible we could provide an ad hoc fix for this precise case, but there are various edge cases like this where apps don’t follow query string conventions and where it isn’t possible to automatically decide what is the most appropriate interpretation.


tkishiya Feb 12, 2015 01:45PM UTC
Thank you Dafydd,

OK, I understood your explanation. But IMPO ignoring "?" is somewhat odd. It's clearly specified as a delimiter of the query part in http://www.ietf.org/rfc/rfc3986.txt and https://www.ietf.org/rfc/rfc2616.txt. Needless to say, Many J2EE web applications use both ";" and "?" in their URL (Google this: inurl:JSESSIONID). I don't need an ad hoc fix because of course I can avoid this manually, but please consider this.

vollkorn Mar 28, 2017 10:00AM UTC
I'm having the same problem. My URL is somepage.xhtml;jsessionid=foo?bar=baz as well. But I need the jsessionid to be replaced as part of a macro with about a dozen requests to get my session back during active scanning. I don't see how I can do this with the Intruder whenever my session rule detected a run out session.

When looking at https://tools.ietf.org/html/rfc3986 I would argue like tkishiya that Burp's behaviour is non-standard. The ABNF at page 48 and 49 are hard to read, but to me it seems clear that from these rules follows that the above URL is standard conform, albeit uncommon.

URI-reference = URI / relative-ref
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
path-noscheme = segment-nz-nc *( "/" segment )
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

So going from top to bottom I can construct a valid URL like this:
1. from URI-reference I chose relative-ref
2. from relative-ref I substitute relative-part with path-noscheme
3. segment-nz-nc could be ;jsessionid=foo
4. Putting 3 in 2 yields ;jsessionid=foo and then I add the optional ? from rule relative-ref to form ;jsessionid=foo?bar=baz

Dafydd, I indeed agree with your assessment that ? always introduces the query part, but ; can be used as part of the segment before and it is valid. Granted, only on relative URLs.

So, I would love to have a standard conform parsing as described in rfc3986 as well.

Dafydd Stuttard Mar 28, 2017 10:23AM UTC Support Center agent

Thanks for this feedback. We do plan to provide a generic way of handling tokens anywhere within HTTP requests, and this capability would deal with unusual / nonstandard query string markers. We don’t currently have an ETA for this feature, sorry, and in the meantime the best option might be to write an extension to perform custom modifications to the request based on an executed macro.


Frederik Oct 24, 2019 07:37AM UTC
Has this issue been resolved yet in way that can be managed via configuration settings?
(Current Burp version 2.1.04)

Mike Eaton Nov 01, 2019 08:23AM UTC Support Center agent

Frederik, unfortunately, this is still unsupported in Burp Suite.

We are currently working on improving the embedded browser within Burp Suite which we will use in combination with the crawler for added benefits, one of which should include this feature as it should be handled automatically by the browser. So once that is released this should not be an issue anymore. Unfortunately, we cannot provide an ETA for this.


Post Your public answer

Your name
Your email address
Answer