I have an asp.net page i do authentication and authorization of a user and user can make several ajax requests from this page. What i want to ensure is that the request only from this page so i will store some data(or token)(possibly a function of userID + user IP address + current time) encrypted in the page aswell as in the session so the requests that come with this token will only get served. Does anybody have any idea of doing this? Help
You could store it in the ViewState. You will then need to send the value of the ViewState hidden field along with your AJAX request.
Related
I am Looking at the Network activity of this page: https://helm.csod.com/ux/ats/careersite/4/home?c=helm&lang=de-DE.
Specifically at the post request with the Name: "search". Its using an authorization token.
tldr: How is the following authorization token stored on the Client side?
Goal:
I would like to understand how the browser (client-side) stores this authorization token. I dont Need to get the data or know how to scrape with selenium or sthg. I would just be interested in the mechanics behind.
What i tried:
I find the token in the page source: view-source:https://helm.csod.com/ux/ats/careersite/4/home?c=helm&lang=de-DE.
It seems like there is an object csod created in /player-career-site/1.15.4/pages/home.js.
then the key is stored in csod.context.
Finally, csod.player.initialize(csod.context) is called.
Unfortunately, i failed digging in the Code and finding These function as there where too many Matches for initialize and my js are skills too bad.
As storage i am only Aware of the Cookies. It might be transformed / encrypted and stored in the cookies? But how is it then restored to the "original" token, before being added to the request Header?
This seems to be a CSRF prevent method.
The token is created with a key in the back end, it stores the original key in a session and sends the token to the client side.
When the client sends a request, the token is posted with the data as a header or with the data, then the back end gets the stored key in the session, generate the token with the same method and compare it with the posted token. If they are equal there is no problem, access granted.
It is not necessary to restore as you can't decrypt that depending on the algorithm (sha256, md5, etc)
And the browser don't do that, as it can be manipulated, there is no sense to.
The token sent here is JWT(JSON Web Token). This is a widely used standard authentication mechanism.
You can create your own token in any languages like JS, Java, PHP, Python, etc.
I am adding a basic authentication flow:
Let's say a user comes on a form. Enter his email & password.
Now an HTTP request is being sent to the server with credentials. The backend server checks the details and if successful, then returns a response containing the authentication token.
Most of the time this token is stored in localstorage and sometimes in cookies.
Now for every request the token is picked from the stored location and sent in the header.
On the backend, it is checked if the request header has the details or not. And then respond accordingly.
At last, whenever someone logs out then that token is removed from the front end.
I hope it helps! Let me know if you have any queries
Here's the problem...
My backend software sends user an email with a hyperlink that contains data (ie. "?dataName=dataYadaYada").
User receives email and clicks hyperlink
My ASP.NET app gets the request, processes data in queryString, and sends back response page with "THANK YOU" plus links to other pages.
PROBLEM: If user re-posts the page or clicks one of the page links, my ASP.NET gets same request again with same queryString, and mistakenly processes it.
How can my ASP.NET app recognize and skip a request that it has already processed?
The only solution I can think of is backend putting unique sequential number into the email hyperlink, and then ASP.NET storing this into session variable for detection of 2nd request of same queryString.
Is there better way?
Fairly simple - when you receive the request, record in your database that the dataname has been used, and check for it every time you receive a request.
If the dataname on its own is not unique enough then yeah append another parameter containing something which (in combination with the dataname if that makes sense) allows you to identify the specific email from which it originated.
P.S. using session is no good because it's temporary and lost when the browser closes. If the user clicks the email again in a new browser session it won't detect it. You need permanent storage like a database
I'm trying to automate testing of an ASP.NET (not MVC) website that uses Forms authentication.
I want to simulate what happens when a user submits a particular form; to do this, my code can POST to the corresponding URL - but that won't work unless my code can first log in as my test user.
I've tried posting to the LogOn page (supplying a suitable username and password), but this fails - and I think it fails because the website uses ASP.NET event validation. (If I use Fiddler to watch what's sent to and from the browser, there's an __EVENTVALIDATION hidden form item).
I'm guessing that I'll need to visit the login page once, get the __EVENTVALIDATION value, and include that when I post the username and password to the LogOn page?
Is that all I need to do, or is spoofing a Forms-authentication-based website a non-starter?
Well, in case it helps anyone else, I was able to get this working by issuing a GET request to the LogOn page, extracting the values of the __EVENTVALIDATION, __VIEWSTATE and __VIEWSTATEENCRYPTED hidden form fields from the returned HTML, and then POSTing those values back to the LogOn page along with the rest of my form values (user name and password).
I'm using a single instance of HttpClient throughout, so the ASP.NET session cookie is preserved between requests.
I wonder how does ASP.NET check if an anti-forgery token is valid or not? Like where is ASP.NET storing those tokens? And how are they stored?
The short version is that a generated token is stored in 2 places: (a) cookie (b) hidden form value. When the form is submitted, these 2 values are compared against each other to determine if they are valid. For further reading:
http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks
http://www.codeproject.com/Articles/793384/ASP-NET-Anti-Forgery-Tokens-internals
A stepwise explanation that is more clear than the accepted answer imho (from https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/preventing-cross-site-request-forgery-csrf-attacks)
The client requests an HTML page that contains a form.
The server includes two tokens in the response. One token is sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary cannot guess the values.
When the client submits the form, it must send both tokens back to the server. The client sends the cookie token as a cookie, and it sends the form token inside the form data. (A browser client automatically does this when the user submits the form.)
If a request does not include both tokens, the server disallows the request.
The above description is not all what is done, in case of AjaxRequest the antiforgery, specifically in get requests, will not usually send the Form with the hidden value for comparison, instead you will need to set a header value with the same content of the cookie via javascript.. the header name that you should set is by default X-XRF-Token header [related to angularjs] ... of course you will need to disable CORS or enable it for only specific domains to protect the APIs, SAMEORIGIN also need to be set to avoid clickjacking ..
I have an asp.net login page, which when initialized sets some session variables. When the user clicks login, an AJAX request is made which validates the user and sets additional session variables and returns a result to the client. The client is then redirected based on the login result. In the redirected page, I can access the session variables set when the login page was initialized (i.e. before the login) but none are present for those set during the login validation (part of an ajax call).
is this expected behaviour? Why would an ajax call generate a new session and thus cause the data to be lost?
Thanks
Is the location for your ajax call in the same application space as the rest of the application?? If I remember right you can't share session information between applications. That may be what's going on.
Normally the browser sends the sends the session id along with ajax requests. If you use Firebug or something similar you can view the contents of the ajax request and check if the session id is sent along.
The session id is stored in a cookie, which (depending on options) can only be used for the same domain/host name. This could be a reason why it is not sent.
Depending on your code, I guess that if no session id was sent a new one is created.
The session id is stored in a cookie, which is returned in the header of the response. As you are doing an AJAX call, the cookie is just part of the response. If you want to use the same session for another request, you have to get that cookie and send it along in the header of the request.