I've been working with jQuery and *.asmx web services lately, and I'm trying to be security-conscious in doing so.
I figure it would be possible to submit an AJAX request -- even when logged-out -- to a resource that should only be accessible while logged-in.
Thus, I include special keys and hashes with each of these AJAX requests in order to validate the user's state before performing certain server-side actions.
HOWEVER
I always assumed that Postbacks were safe in that regard. That .NET would throw an error if it received a request that had been tampered with.
Is that a safe assumption? Or should I validate ALL requests, whether they're received via AJAX or a non-AJAX HTTP POST?
I suppose both are technically HTTP POSTs, but the AJAX one only submits what you explicitly pass, whereas a normal ASP.NET one includes all viewstate values. Is that correct?
You shouldn't trust anything that comes in over HTTP - it's trivial to manufacture a GET or POST request.
Related
I wish to implement an Auth handler for requests that handles authentication with an OAuth Authorization server to allow the following:
import requests
requests.get(url, auth=KeycloakAuth())
What I've done so far is to apply a response hook when KeycloakAuth is called, so that when the client redirects the caller to Keycloak, the hook will see the Keycloak login page, post the credentials to Keycloak and get redirected back to the client.
However, this does not work for a POST, as requests makes a POST to Keycloak's login page instead of a GET due to the redirect. Keycloak doesn't return the login form in response to a POST and this fails.
I considered checking for the redirect in the response hook so that I can modify the redirect to do a GET to Keycloak instead, but it seems like requests' implementation of redirects bypasses all the hooks.
After poking into this a bit more, I believe this may be the wrong question to ask.
I was seeking a solution where, regardless of the original HTTP method used on the client (GET, POST, HEAD, etc), the library would automatically login to Keycloak, and then "replay" the original request to the client and make it effectively transparent to the user of the library.
However, this can't possibly work with OAuth 2.0 without further state management on either the part of the library or the client, due to the redirecting.
Suppose the original request was a POST, with some data. After finding that the user is not logged in, the User-Agent will be redirected to the Authorization Server for authentication.
This means that the original request's POST data will be lost, removing the opportunity for any replay, upon the User-Agent being redirected back to the client after authentication.
With some state management, the POST data could be stored for replay - it doesn't make sense to store the data on the server side since the data could be arbitrarily large, which leaves us with the user of the library to do the state management.
However, that amount of state management should probably not belong in a library, since the library will have to handle lots of cases to guarantee only-once delivery of the request, for example, which would be expected by the user of the requests library.
As such, this Auth handler is probably not something we can implement in a library.
I'm trying to implement antiforgerytokens to an angular application's ajax requests.
Is there a lifetime attached with the antiforgerytoken? If I have the app open for a long while in a web browser whithout touching it, say for a month. Will the ajax requests fail due to a stale token?
Can the token be reused for multiple calls? Can I keep one token somewhere in the page and retrieve it for all ajax calls?
Indeed API are supposed to be consumed by 3rd parties, but what's regarding Single Page interfaces with AFT?
I'm concerned they still require AFT in order to prevent CSRF atacks. And here is a good way to use them in Ajax requests.
Antiforgery token is generated per Session, and remains in session data till it's expired. For new session new token will be generated. And yes, single token can be reused multiple times within the same session.
Please check the link I've added, there is example of how token might be obtained for Ajax requests.
Will the ajax requests fail due to a stale token? Yes
Can the token be reused for multiple calls? No
However, the better question to ask yourself is why are you using antiforgery tokens with AJAX in the first place. If you're using AJAX, you're using an API, even if you haven't formalized it as such (just a collection of actions/controllers that are using for AJAX/other headless communication). Antiforgery tokens don't work well with APIs because 1) APIs typically allow third-party access and 2) even if they don't, there's better ways to secure them.
If you want to ensure that only your site can access your "API", then implement HTTP authentication or some other scheme to authenticate your requests to your "API". That is how you allow long running sessions that will not fail.
I'm using forms authentication in my current asp.net web forms application "not MVC" and wondering if Global.asax [Application_AuthenticateRequest] and [Application_PostAuthenticateRequest] invoked on every request to the server or Not? i mean does ajax calls count for Global.asax handling or some bugs might occur! because i found in this link conflict:
http://channel9.msdn.com/forums/TechOff/256322-Strangeness-between-ASPNET-AJAX-and-Globalasax/
so please advice if its good or bad to handle custom authentication for ajax calls through Global.asax
thanks,
AJAX calls back to your application are just the same as hitting the site with the browser so yes these events will be fired.
The article you link to concerns the scenario where you have more than one request made within the same session.
http://msdn.microsoft.com/en-us/library/ms178581.aspx
Access to ASP.NET session state is
exclusive per session, which means
that if two different users make
concurrent requests, access to each
separate session is granted
concurrently. However, if two
concurrent requests are made for the
same session (by using the same
SessionID value), the first request
gets exclusive access to the session
information. The second request
executes only after the first request
is finished.
So if you made two requests back to your application from ajax code running in the browser they would be executed one after the other, not in parallel.
There is no way to turn this feature off.
In ASP.NET MVC3 it is possible to create sessionless controllers that do permit multiple ajax requests in the same session to be serviced at the same time by decorating the controller with this attribute:
[SessionState(SessionStateBehavior.Disabled)]
I have little experience with web programming and I am implementing an interface where I sent a HTTPS POST Request (with user/password), receive a XML, then I send another HTTPS POST Request (with an additional "passcode" dependent on the XML), receive a XML, (then I am logged in) then I send a HTTPS GET request and get an XML (the data I actually want).
The documentation says: The following cookies are sent to the application ... and then it says: "the application must be able to store cookies".
I wondered why I should store cookies if I am never asked for it. I just started programming that protocol but I saw in a response that I was sent a cookie. Now I wondered whether I need to store the cookie (and worry about it) if I am never asked for it?
I wondered why I should store cookies if I am never asked for it.
Asked by who? User? User should not care. Cookies are part of protocol that you must implement to be able to communicate with that server.
That protocol spec says that you should store cookies - where you like, and send with each request.
can I make role based authorization when sending requests to an ASP.NET MVC backend system. I am calling action methods and expecting JSON results, however, some action methods are decorated with the [Authorize] attribute, others require some role privileges to be present. I certainly hope that passing authorization data with every request is possible
Unless the methods are designed to accept login information as parameters, you would typically have to login to the system by posting a form to the "login" action -- typically /account/login -- and from then on send the authorization cookie that you receive back with each new request to validate who you are. There are a lot of ways to configure the backend, though what I've described is the typical way. Fortunately, URLRequest has a way to specify that you want the HTTP stack to manage cookies for you, so this should be reasonably seamless from your end. NOTE: I've never used FLEX, I'm just going by the documentation.