Burp upstream proxy settings and setHttpService
I was wondering if you can help me with a few questions.
I'm trying to dynamically set the upstream proxy depending on the current request and modify incoming response based on a set of rules. In that regards, I've a few questions.
1. Based on this answer (https://support.portswigger.net/customer/portal/questions/17143574-project-configuration-changes-aren-t-picked-up-during-current-ihttplistener-processhttpmessage-call), it looks like one can only use the processProxyMessage to set the upstream proxy dynamically. Now, where are all the config path strings present for saveConfigAsJson and loadCondfigAsJson? Burp API doesn't seem to provide them. Is this documented somewhere I can find? If not can you let me know here?
1a. It also looks like project_options is mentioned as part of the config string path in the API doc for IBurpExtenderCallbacks. I was wondering if you also provide the config path for user_options and so on?
2. In the answer mentioned in question 1, you also say I can proxy a request by setting a new HttpService using setHttpService. This way of proxying would be neat (depending on proxying needing to be visible or not in project/user options' upstream proxy settings) if it actually works to forward to another proxy. My question is, if it works, will the response show up in processProxyMessage so that I can intercept using Burp API? As opposed to the response being intercept-able only if it is received using a set upstream proxy?
Please let me know if my questions are clear. I can clarify further if needed.
To see all the JSON config strings, save the project options. Burp menu > Project options > Save project options. Open that in a text editor to see all the config strings. User options are not available through saveConfigAsJson.
I think the problem with the setHttpService approach is that it doesn’t work for HTTPS. I know the person who asked the question you linked did not end up using that approach. processProxyMessage applies to messages passing through Burp’s proxy listener; it is not affected by having an upstream proxy.
Please let us know if you need any further assistance.
I can confirm that setting using setHttpService() does proxy the request as expected. I think this will do for now. Thanks for the help!
I'm having issues forwarding modified requests using using setHttpService().
I'm modifying incoming requests in processProxyMessage() replacing the GET /resource with GET <full-request-URI> and sending it to an upstream HTTP proxy which is Burp.
I'm doing this by copying all headers except the first and copying back the body, constructing a new request and sending it.
For reason unknown to me, the upstream Burp proxy complains of "Invalid client request received: First line of request did not contain an absolute URL". However, the same works if the upstream proxy is something else like mitmproxy where I can see the request.
What am I doing wrong?
It sounds like the upstream proxy is receiving a request like “GET /path” instead of “GET http://host/path”.
I suggest you install the Logger++ extension so you can see exactly what Burp is sending. I expect that it’s slightly invalid, and that mitmproxy is a bit more forgiving in its parsing.
If you can’t spot what’s wrong, send me a screenshot of a request/response captured in Logger++
Not sure what went right, it seems to be working fine now!
I have a follow-up question - when you change the incoming request to suit an upstream proxy request, the new request shows up as "Edited Request" in proxy. I understand that this is the expected behaviour. I believe if I want such a request to not show up as edited, then I need to edit the upstream proxy settings in the project options correct?
Good to hear it’s working!
Yes, if you change the message in IProxyListener it will always show in the UI as an edited request. If you change it in IHttpListener, it won’t show as edited – although I’m not sure if you can proxy by that point.