Skip to content
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

Additional invalid request #1

Open
irsdl opened this issue Feb 8, 2016 · 5 comments
Open

Additional invalid request #1

irsdl opened this issue Feb 8, 2016 · 5 comments

Comments

@irsdl
Copy link

irsdl commented Feb 8, 2016

This extension sends an invalid additional request per each valid request. This can be monitored using Logger++ or other extensions in front of Burp.
Problems in the additional request are as follows:

  • it adds the OAuth header twice
  • it adds the header before the HTTP verb
@irsdl
Copy link
Author

irsdl commented Feb 8, 2016

This especially happens when using Proxy.

@dnet
Copy link
Owner

dnet commented Feb 8, 2016

I haven't really used this with proxy, maybe that's the reason why I haven't seen this yet. :)

@dnet
Copy link
Owner

dnet commented Feb 8, 2016

Could you send an example? Right-click the original request in the Proxy > HTTP History tab, select Save item and make sure to have [x] Base64-encode requests and responses checked on the bottom of the file picker dialog before saving it. You can either include the contents of the file here, or send me a mail with this attached.

@irsdl
Copy link
Author

irsdl commented Feb 8, 2016

It really just sends it in the middle of requests in proxy when they have "Authorization" header. My website uses Basic Authentication for areas that are not accessible using OAuth.

@dnet
Copy link
Owner

dnet commented Feb 9, 2016

So what should be the desirable behavior?

  • No authorization header: add OAuth header?
  • Authorization/OAuth header: replace with OAuth header?
  • Authroization/Basic header: do nothing?

You see the library I used (Signpost) is for signing requests that has no authorization header at all (see the first item in the above list), hence the weird behavior in case of having these already present. The original scope of the plugin was enabling requests for Repeater, Intruder and Scanner. I'm not saying we shouldn't implement what you wrote, but this functionality should be extended, and the first step would be specifying behavior in the scenarios detailed in the above list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants