Separation of query string
When I access a URL like following Burp recognizes one parameter its name="JSESSIONID", value="foo?bar=baz".
http://imgur.com/OY9NkvU (Raw tab)
http://imgur.com/sO1HAaE (Params tab)
Burp Suite v1.6.10
Windows 7 64bit
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.
I expected burp to parse in this way:
- Path parameter (starts with ";") : JSESSIONID=foo
- Query parameter (starts with "?") : bar=baz
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.
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.
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-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.
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.
(Current Burp version 2.1.04)
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.