I'm confused by the following problem I experience. We use Windows 2008 R2 machine with IE 8.0 installed. Next I try programmatically to connect to a server with InternetConnect call(auth credentials are provided as an arguments passed to it). It succeeds. Next I call HttpOpenRequest and HttpSendRequest. The calls to HttpOpenRequest and HttpSendRequest are performed using the same connection handle InternetConnect call returned. At some certain point of time HttpSendRequest begins to fail. From traffic capture I see there is auth info missing and it makes server in its turn to return 401 result. InternetSetOption call with INTERNET_OPTION_USERNAME and INTERNET_OPTION_PASSWORD provided doesn't take any effect. After HttpSendRequest fails I call GetLastError and receive at first ERROR_HTTP_INVALID_SERVER_RESPONSE and at second ERROR_INTERNET_INCORRECT_HANDLE_STATE if I try to re-send my request with HttpSendRequest.
Maybe somebody of you experienced similar problem?
I discovered it's a normal way of how client behaves. First it tries to contact resource anonymously and then if it fails it tries to use credentials. Within single function call it's ok to have one 401 result because the very next request comes along with auth credentials.
Related
The Scenario
A Node.js app uses some third-party SDK that makes authorized calls to an API. The authorization mechanism is an access token to be passed alongside the call, and --- if the token has expired -- a response sent to the client code 401.
What I Would Like to Know
How can augment this SDK so that calls containing an expired token automatically retry the original request, after a valid access taken is returned?
In Other Words,
I'm surprised that the SDK doesn't do this by default. It has methods to get and set tokens. If an access token has been set, it places that in the request, but doesn't handle responses. My code, therefore, is left checking each failed request for 401, and manually fetching, then updating tokens, and -- then -- retrying the original call.
DRY
is what this ain't. While I am displeased the SDK doesn't automate this process, I would not be surprised to learn that such a pattern is common. Have backend Node.js developers encountered something along these lines, and -- if so -- how did you approach a solution?
Finally
Thank you.
PS. I tried extending the SDK as a subclass, and re-casting methods that call the API in a thunk'd iteration. I did not get very far.
I am trying to fix the issues in IBM AppScan results and I\m getting the flag:
AppScan identified a password parameter that was received in the query string
with this command showing in the screen
GET /myapp.com/?username=user&password=**CONFIDENTIAL 1** HTTP/1.1
and I’m 100% sure that I'm not sending critical information in query params or even get requests I was thinking the about that the app is sending the request it self and want's me to block it.
Am I right or I'm missing something here?
It's quite common for application vulnerability scanners to misinterpret login forms that use JavaScript to make login requests. I am guessing the HTML form does not explicitly declare the request method as POST. Assuming when a user actually makes a request with a browser, a POST request is made, it's safe to assume that AppScan is generating this request itself.
One more issue to consider, if you make the request to https://myapp.com/?username=user&password=password#123, does that return a session token? This is often considered a vulnerability as well if the server does not reject all GET requests even if a user crafts it manually.
I'm developing a RestFul Apis for a mobile application (Android App). I'm using 2-Step auth using OTP and remember me token. For the remember me token I'm currently using Remember Me (any other similar strategy npm is welcome). The npm basically sets a unique token to a cookie which the App can use to verify itself. According to documentation in the above NPM, it recommended to re-generate the tokens after every request.
However in the event when the mobile App makes multiple parallel requests, all the parallel request use the same token. This undoubted give an auth error. I guess this is common situation. I wanted to know if there is a standard way to handle this ?
Current Workflow
Mobile App request authentication with a given OTP
Upon successful verification, the App is give a token which is
passed back in a cookie
For calls to protected APIs, the App calls
the API with cookie passed back in the previous step.
The server resets the token in the cookie and sends back the response to the App
Issue with the workflow
The App is successfully logged-in and has a valid cookie.
App makes a call to a protected API /protected_api_1
The server has reset the token in the cookie for the above call but has not yet completed the reponse
App makes a second call /protected_api_2, with the old cookies as the App does not have the new cookie with it.
Auth fails for (3)
Ok, checking your update I think of 3 workarounds for this. Let's say we have 3 actions, (a), (b) and (c) that requires the token to consume the API.
Token Store
With this just I mean a class, file, cookie or object where you can save your current token, and you can update with the new token after an action is completed.
The problem with this solution is that if you make (a), (b) and (c) at the same time with the same token, the first one who finishes would update the store, and the other 2 would fail. You would have run them synchronously or concurrently.
If you want to do it this way, maybe it would be a better idea to have a:
Lock: a boolean variable that indicates that the token is being used and that the current request must wait for the token to execute and update the token.
Queue: just a linked list where you push the requests and they are consumed asynchronously when the lock isn't set. You implement a service in another thread that handles the queue, may in a similar fashion to a reactor pattern.
Grouping The Requests
Let's suppose that your application executes (a), (b) and (c) very often. In that case, it would be a good idea to group them in just one action and execute it on the server with just one callback. This could be complicated in your case because it would require to create new resources or think about your modeling of the problem.
Managing token expiration
I've seen this in some projects. You set a soft expiration for the token, let's say 15 minutes (or even less). After the time has passed, you give the client a new token, before that time you keep the same token. (a), (b) and (c) would run at the same time with the same token. Problems would happen when you run the requests near the expiration time, depending on how long it takes to complete them.
I can't give you more details about implementation because I don't know in what language or framework you are implementing the client, and I've never made an Android Application, but I think it would be a good idea to try one of this ideas or a mix of them. Best wishes.
Original
I don't understand what do you mean by parallel in this context.
Try making a Token Store resource in your app which every parallel request consumes and updates after request is done.
If all requests are sent at the send time, maybe it would be a good idea to group them in just one operation, but that would maybe require API endpoint changes.
At work, I have IE8 on XP, calling a .net 4.0 web app on WinServer 2003 with IIS6. IWA is turned on. When I call the page, the initial aspx page call of course will show 3 lines in Fiddler. First is anon request, second has some AUTHORIZATION:NEGOTIATE header, and then the 3rd has a longer value for the same header (probably a token). The first two result in 401 errors, the last is 200 success. But this is expected.
The issue: When the following resource files (CSS, JS, images) get called, mostly all of them (but not all) go through the same 3-step call. The first 2 are 401 errors, then the 3rd gives me the 200 code and the content.
Is this normal? I thought just the first call of the page itself is the only thing needing the 3-step process.
FYI- we had OAM and WebGate on the server, but we uninstalled it and we are still getting this behavior. Is it possibly the app pool doesn't have it's identity/domain ID setup right? I really don't want to turn the style, script and image folders on Anonymous.
This is correct if your server is configured to protect any resource. Since HTTP is stateless, every request has to be authenticated. This can be avoided if a session cookie is used which memorizes the auth. Otherwise this will happen every time.
In IIS I've got:
http://myserver/myapplication
http://myserver/reports
The reports app is reporting services in fact which uses windows authentication. myapplication is an asp.net application that uses forms authentication.
The server is outside the company domain. If I access the reports first and type in the user and password(local credentials created on the server) when prompted I can access the reports page, no problems. If then I go straight to my application's login page and try to login, the login page refreshes without doing anything. This always happen in IE 6. In IE 7 it happens intermittently. Does not happen in Firefox or if Fiddler is running in the background which seems to fix the problem on the fly.
I used wireshark to see what's going on and found that IE 6 send the windows authentication token obtained from the reports app to myapp. That was the only difference between IE and Firefox. IIS seems to freak out and simply interpret my POST to the login page as a GET and return.
If I add windows authentication to myapplication in IIS everything seems to work fine with any browser.
Why is this happening? A bug in IE or am I missing something?
It's sorta a bug in IE, and sorta a bug in the design of NTLM/Negotiate (aka Integrated) authentication over HTTP.
NTLM/Negotiate are connection-oriented auth protocols, which HTTP wasn't really designed for. As a result, when you require this auth mechanism for one page on your server, IE will typically assume that other pages on the server have the same requirement.
Furthermore, for performance and security reasons, if IE expects a Negotiate/NTLM challenge for a given POST request, then it will first send a 0 byte POST, expecting the server to return a HTTP/401 challenge to which it will authenticate and then properly send the POST body.
However, in your case, the folder which doesn't require Integrated auth gets the 0 byte POST and says "Hrm, weird, a 0 byte post. Okay, HTTP/200, here's the page as if you'd used GET."
Because IE never gets the 401 challenge it expects, it never actually sends the POST body.
(Fiddler may confuse you a bit due to how HTTP connection reuse works).
The workaround is to ensure that if you're using Integrated auth on the host, use it everywhere.