I'm testing a application that uses OAuth2 with bearer tokens to authorize requests. The problem I'm having is that the access token expires after 600 seconds (10 minutes) and then all requests become 401 Unauthorized. The problem occurring now is that the scanner can continue to run with a bad token and not refresh the token automatically.
What I would like to do in this case is that the application automatically logs back in.
What I have tried is to go to Project options -> Session handling rules -> Add -> Rule Actions -> Check session is valid with options Issue current request. While there I check the response body for "Authorization denied" which is always sent on a HTTP 401. After this happens I have a macro that issues a request to get me a new access token. However I need to map the new access token to the Authorization: Bearer-header. Has anyone done this? It can be easily done with cookies from this view but I can't find how to do it with tokens.
Using Burp Suite Professional v1.7.14
Since burp doesn't treat (non-cookie) headers as session identifiers, it's difficult to do this within Burp Suite, although you may be able to use macros, those fire every request and are very inefficient.
I recommend using this burp extension, which is designed to solves this problem: https://github.com/alexlauerman/UpdateToken
Related
When we are accessing Asana API we are using the Asana node client v0.15.0 together with an Tampermonkey script. The Api is responding with an 401 (Unauthorized).
This worked a couple a days ago. I have tried with new Personal Access Tokens but still get the same error.
While fiddling the request I tried to change the auth-header Bearer to be lower cased.
Authorization: Bearer my-personal-access-token ->
Authorization: bearer my-personal-access-token.
This seems to work fine, that indicates that something changed on Asana's side.
The node-asana js client lib does not let me modify the request before sending it to Asana API.
According to Asana API support it is on stackoverflow that I should ask about help on this matter.
EDIT
By some further investigation it seems that when we send in the cookie
auth_token=My auth token we do get the 401 error. But If removing the cookie and reissue the request in fiddler it works fine.
Another note is that now we do not get any custom_fields in the response from e.g https://app.asana.com/api/1.0/tasks/TaskId
I'm a Developer Advocate at Asana. You've caught something that is a known issue and we're working on a fix :) We're rolling out a new version of our API. It's intended to be backwards-compatible with the older implementation, but giving us multiple forms of authentication is one of those cases where we do something different between the two.
For security purposes, we initially implemented this in the new version to not allow requests with multiple forms of authentication, but it turns out that in-browser integrations were affected in precisely the way you're seeing: being logged into Asana, which causes your browser to send your authorization credentials for requests to asana.com automatically, and also authorizing "the right way" for our API with OAuth or a Personal Access Token will end up breaking. We're working on a fix that will allow this to work for the case when both the logged in (cookie) user and the API (access token) user are the same.
If this is an urgent issue and you want to force the old behavior to happen while we roll out the fix in our newer API implementation, you can set a header as described in that link --^ to force your requests on to the old API. Once we get the new API fully deployed and stable, though, we'll deprecate that header, so please be cautious in relying on it for a long-term solution.
Sorry that this has caused issues for you, and thanks for creating this question to let us know!
I'm writing a desktop application in Delphi and trying to sync it with Google calendar (windows only, win 7 and newer). I've registered a custom uri schema in my system registry, so eu.myapp:test will run my program or pass a message to an already running instance of the program.
I've managed to get the first step of authentication going - I open the default browser, asking the user for permission to modify their calendars, I get the authentication code back into my software without a hitch. The oauth client is registered as an iOS app,
However when I try to request an actual token, the request is denied (400 - Bad request) with the following response body:
{
"error": "invalid_request",
"error_description": "Invalid parameter value for redirect_uri: Missing scheme: eu.myapp",
"error_uri": ""
}
My request body looks like this:
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
code=XXX&
client_id=YYY&
redirect_uri=eu.myapp&
grant_type=authorization_code
According to the documentation, I am supposed to include the redirect URI obtained from the API Console, but I found no such URI there. Found some older answers, but the developer console has apparently been changed since they were given so they are no longer relevant. What am I missing?
Edit: Added some more information
I built a simple nodejs server and put it up with a SSL certificate and nginx, so I could see what actually gets sent across. I then used both my app and the example C# app to send the token request to it and monitor the request body.
The only discernible difference was that delphi url encoded the code automatically (4%2Fhky... instead of 4/Fhky... for example). Other than that they seemed identical.
I also tried rewriting the app to listen to a localhost port but ended up with the same results. There is a delphi demo where they demonstrate the use of google api by using an embedded browser for the user to log in (and it works), but according to the api documentation, it's deprecated and will go away soon. Besides, it seems like I can manage the first redirect just fine, but getting the actual tokens fails.
Found my error. I noticed that the parameters were getting encoded automatically by the delphi component responsible for making the requests. I manually encoded the redirect uri before setting it as a parameter on the token request. Then the component encoded it again, which caused it to be different to the url given on the code request, which caused the uri_mismatch error.
The uris also need to be identical on both requests, as even though the second request does not redirect, it still uses the redirect_uri as a validation parameter.
I am using the implicit client in the identity server, in the other hand there is a native android app,
My security concerns is:
1- App reverse engineering: if the attacker get access to the client_Id
, redirect_uri and/or response_type, he will be able to mimic the login request.
by doing this he is impersonating the original client
2- Man in the middle: those client_id,... is send to the identity server through the https URI which is not encrypted, why not hiding them in the Header?
3- Browser will resend the token in the URI revealing it to the man in the middle if the redirect URI is not oob or localhost, the browser default behavior is redirecting to the Location, so can we force the developers when they register a client to use oob,
You can say ohh no the app is reading the token and close the browser so fast, before the browser sends the request,
Can we really rely on the app speed of closing the browser, this is sounds squishy?
Which question is legitimate concerns and which is not, also how to solve the legitimate concerns.
About point 1: how google is protecting it's services like google Map, the client Quote is vital and it has to be very secure, Right !!?
Edit
if we pass the client_id in the header to encrypt it, we will violate the http 1.1 spec and oauth2 spec, still we didn't do much, because the client_id is reside inside the handset, by small reverse engineering you can get it
Regarding point number 3:
The token response after a successful authentication will be something like this:
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
The user-agent will redirect to the URL provided in the location parameter. Here there is no need to worry about MiTM attacks because the access-token is included in the URL hash fragment & hash fragments are not sent in the HTTP request messages, in other words the hash fragment will not leave the client machine.
Yes, but the token service will only return the user to the pre-registered callback uri for the client.
2 & 3. You should use HTTPS for most everything on the web these days.
Trying to add twitter login using OAuth and it has been a nightmare to get the first step of requesting the token, which results in 401 error as always.
I used twitter's Test OAuth tool to compare the http request that my scala server sends.Curl request works while my server request fails. Pasting them below for comparison.
Curl Request
curl --request 'POST' 'https://api.twitter.com/oauth/request_token' --data 'oauth_callback=http%3A%2F%2F0.0.0.0%3A8081%2Fweb' --header 'Authorization: OAuth oauth_consumer_key="wRflKWWomJ9jKeK8wbTk0Jck3", oauth_nonce="46ef029600fcc2a6cbe068eb9711401c", oauth_signature="3ptB%2B6%2Fv9QYGgyQjO9DhuD7pmzA%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1422879905", oauth_version="1.0"' --verbose
Scala server Request
HttpRequest(POST,https://api.twitter.com/oauth/request_token,List(Authorization: OAuth oauth_consumer_key="wRflKWWomJ9jKeK8wbTk0Jck3", oauth_nonce="70449464359328", oauth_signature="yEni23tuzEveIMtDm7%2F8N2anU%2FM%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1422879900", oauth_version="1.0"),HttpEntity(application/x-www-form-urlencoded,oauth_callback=http%3A%2F%2F0.0.0.0%3A8081%2Fweb),HTTP/1.1)
Things I tried:
Made sure timestamp is within 5 minutes
Made sure "Allow this
application to be used to Sign in with Twitter" is set in twitter
settings.
Callback url is set - http://0.0.0.0:8081/web (even tried
proxy names for localhost by changing ip table)
Tried generating request token using Saclaj
Used custom OAuth signature request primarily using OAuth.scala
This 401 twitter request token seems to be a recurring theme for many folks, complicated by various failure points. Any help is much appreciated.
For anyone else facing this issue, I am listing down few things that you could benefit from.
After excruciating attempts of permutations and combinations,
oauth_token had to be a part of the signature (even if its value is
empty string). I am not sure if it is mentioned anywhere and particularly ironic that you had to remove access token and secret while using Twitter's OAuth testing tool (for the Curl command to work properly which took some bloody lot of time to figure out.)
It is good to validate your basestring - Tool
Validating if your signature process is correct - Check point (f)
Another possible scenario
In my Twitter client app settings screen, I set an option "Enable Callback Locking (It is recommended to enable callback locking to ensure apps cannot overwrite the callback url)" and this caused me getting 401 unauthorized error on trying to get request token.
I'm working on an application that integrates with GitHub and am having issues "logging out" a user that was previously authenticated. When I attempt to revoke the authorization token for the user, I get a 404 Not Found response from the API.
According to the documentation, it looks like I should just be able to make a DELETE request to https://api.github.com/authorizations/[authTokenId]. I have tried a couple of different things including:
Ensuring the Authorization header is set with the current auth token
Ensuring the UserAgent header is set with what I use for the rest of the API calls
Nothing seems to result in anything but a 404 though. I have validated that the token is valid and has that the Id matches with what is expected (id property from the authorization response and from the "check an authorization" response as well). Anyone have another thought on something I could be missing?
Looks like currently you need to include a basic authentication header (including a base64 encoded string of your username/password).
Not ideal for my purposes since I want to revoke the token when a user "logs out" of my application and I don't want to store their username/password. I've sent GitHub support an email about it to see if they have any other ideas.
Update 6/12/2013
GitHub support has stated that the above is expected at this juncture, but they are considering updating to allow revoking an authorization using the authorization as the means of authentication.
For now I'm going to require the user to enter their username/password a second time to revoke the authorization.