I need to test whether or not a click-through is valid by using some javascript client-side tests (e.g., browser window dimensions).
However, I would like the original click referrer to remain the same. Is there a way I can do a redirect, execute some javascript, capture the browser details and then continue the click-through while keeping the original referrer value the same?
If there isn't, then simply include the referrer as one of the "browser details" that you capture and send back with the redirection instruction. The referrer probably isn't available on the client automatically, so it will work like this:
Client sends initial request, presumably including a referrer.
Server dynamically generates the client-side-testing page, including the referrer in a Javascript variable.
Client collects client attributes, including the referrer value stored in step 2.
Client sends collected attributes to server with new redirection request.
Server records referrer parameter somewhere, although not in the HTTP logs since the Referer header won't have the same value as what the Javascript request sent.
Of course, you realize none of this is reliable anyway because it all depends on the client including the Referer header in step 1, and there's no guarantee that will happen, or if it does happen, that the value you get is accurate. I also question the wisdom of doing client-side checks (especially of something as arbitrary as window dimensions) to determine the validity of a navigation request.
Related
I have read about the relayState parameter in SAML SSO, and how the SP can redirect the user back to the original incoming URL by making use of relayState, but to my knowledge HTTP redirect only works for GET requests.
I am wondering if the same can be done for POST, PUT and DELETE requests, considering these requests usually come with data in the request body as well. I thought of returning a self-submitting form for POST requests, but this won't work for any other HTTP verb, and the original request must be a form based request too, unless the framework supports treating all types of parameters (query string, form field, json element) similarly. I also thought of making the frontend reconstruct the original request and sending it back to SP with AJAX, but I'm not sure if AJAX can actually update the browser's current page address.
My compromise solution in the end was to only relay URLs that result in a whole new page rendering with a GET verb only, and for any other requests, use the referrer URL for relaying instead. This means for the latter, the user will have to perform the task manually again after landing on the page he last saw before the SSO flow.
Not sure what the common practice in the industry is.
Thank you!
you would to maintain / save the POST data on the SP end and re-use them after SAML flow succeed. SAML as such does not provide any mean to achieve this.
This is a theoretical question. For some APIs, user need to authenticate themselves and we have authentication token for a user. I feel using GET api is not good idea due to this token.
/get_data/?user_token=hshhlj8979kjhk&dataid=87979
Indeed it's not a good idea, but not due to GET in itself. The real problem is the token as part of the URL and the security problems it creates.
The URL portion of a request is very often cached and logged for auditing or debugging purposes, and having the token there causes it to leak unintentionally.
For example, browsers save your browsing history, and the main portion they record is the URL, so there goes your password to your history, a place it doesn't belongs and is easily exposed accidentally.
Most web servers by default also log the URLs they receive, so again there goes your token. It's quite common for it to end up in logs on web servers, load balancers, intermediate routers and so on, again leaking all over the place.
The solution to this is to strip the token from the URL portion, leaving there only data that's not security-critical. The most common place to put it is in the request's headers. Those are well respected by the HTTP standard and almost never logged or accidentally dumped like the URL.
Of course, all other methods suffer the same. POST, PUT, DELETE, OPTIONS for example, none of them should be ever called with secret data in the URL. Headers provide a "safer" place for that available across all methods. The request body is another common place, but you can't have one in GET, making a header the best alternative.
Steps:
Hitting the website- It is being redirected to an URL which contains parameters such as STATE, NONCE and CLIENT-REQUEST-ID which are dynamic.
So, in JMeter, I am unable to fetch those values as those are coming directly in a HTTP request.
Any Idea, how to fetch it?
While clicking on sign in with credentials, authentication process is happening which is generating a token id.
Then in next request, redirects occur and same kind of URL is achieved (as in step1). Again same parameters are passed.
And with this request, Access token is generated.
I am unable to fetch those parameter (nonce, state, client request id). Is there anything we can do?
According to Microsoft, client-request-id is optional (so you can probably just leave it off) and if I read this right is generated by the client. So you may be able to just generate a random GUID in JMeter.
If you're being redirected to an URL which contains the parameters you're looking for you should be able to capture them from the sub-sampler
using a suitable Post-Processor like Regular Expression Extractor
Also some values like consumer key are static and never change and some values like nonce are random
If you don't need to load test the OAuth login challenge itself you can ask developers or administrators to provide you a permanent token which you can send in the Authorization header using HTTP Header Manager
Yes, you are correct but in my case I am not getting any sub-sampler(s).
That's where trouble lies!
Also, those parameters are coming from 3rd Party which is hosting the site(not in the hands of Devs)..
The whole process I am doing is for load testing.
So, any thing you wanna add for this?
I'm just getting started in HTTP POST requests. So much so that I've got no idea if this is even going to solve my problem, but it seems like an interesting thing to learn about either way. Anyway, I currently do the following with a webbrowser control:
Navigate to a page
Enter username and password
Click the 'login' button
Enter some text into textboxes
Click another button (which loads a confirm page)
Click the confirm button
My question is does the HTTP POST request thing allow for the webclient to stay logged into the webpage, does it allow for posting to the page and then posting again once the update page has been received (steps 4, 5 and 6).
So you want to scrape some web content or manipulate a site from a program or script, but you're having a hard time. No, just switching to a POST will not help you here. Often, the problem has to do with authentication. What you need to do is preserve your session across more than one HTTP request, whether the requests are POST, GET, HEAD, DELETE, PUT, UPDATE, etc.
As mentioned in a comment, HTTP requests are stateless, where each request is independent of the others. However, web servers will still maintain some information for individual sessions, and so you usually still need more than one request. However, I find that much of the time, exactly two requests are enough to accomplish an action on a web site.
The first request will POST your login information to the site. At this point, the web site will issue a response. You need to analyze this response, because somewhere in there will be a session key. Now when I tell you to analyze the response, I don't mean that you write code to do this... that will come later. You need to actually send a sample request record the response, and read through it with your own eyes to find the session key. You also need to know how the web server expects to find the session key on future requests.
In this process, it's important to remember that a response consists of more than just HTML. In fact, the most common location for this key is in a cookie. Once you know how to get the session key, you need to make sure your next request includes that session key as part of the request. This is how the web site will know who you are, that you are authorized to perform the desired action, and what information to return.
The second request will actually perform the desired action. This could be a simple GET request, if all you want to do is retrieve some information from the site. It may also be POST, if you need to tell the site to perform some action.
To know what your requests need to look like, you can use a special kind of http proxy. Fiddler is a popular choice. You install the proxy to your computer, and then perform the desired action from a regular web browser. Fiddler will then tell you what requests and responses were sent. Even if you need to view a number of pages to complete your action via your web browser, often you still only need the final request to actually accomplish your goal. You use the information provided by fiddler to find and duplicate the required requests.
In the .Net world, the best tool for sending these requests and evaluating the responses is generally not the WebBrowser control. Instead, take a look at the System.Net.WebClient class, or look at System.Net.HttpWebRequest/System.Net.HttpWebResponse.
Some Web Browser have extension/Add-ons, eg. FireFox with Modify Header or Tamper Data, that can modify HTTP Header for GET/POST method before send it to Server.
So, How I can check Header is modified by user from server side?
Since all of the headers come from the client as part of the HTTP request, in essence they are all modified by the client. You cannot tell which headers were added/modified by plugins, at least not with any certainty. The best you could do is try to gather some heuristic data and try to identity known modifications from specific plugins (e.g. Plugin "Foo" always adds a "XYZ" header that looks like "Foo bar baz"), but even then you're bound to get plenty of false positives or negatives.
The question is, why do you want to know this? If you are relying on information in the header (cookies, etc), you can encrypt that data server-side. That will protect it from client-side modifications.
You can't unless the header values are invalid. If they are editing the header values during a session you could check the browser and other header fields and store them in a session, then check that these haven't changed. i.e. if during the course of a session the $_SERVER['HTTP_USER_AGENT'] which is gathered from the header changes then the header has been tampered with.
However if the header values are valid and not unexpected, i.e. if you are receiving requests for values that the page does not use looping through the $_GET[''] array will bring you back all the information that is sent via GET and if you are recieving too many or values that are not needed then you could call die or log it.
Please bear in mind I am aware these examples are all PHP but you have not mentioned what language you are wanting to check this in, all languages have equivalent methods.
You cannot reliably guess what happened to a request before it reached your server, it may even have been crafted manually.
If you are trying to make sure clients never send cookies that your application didn't set (or something like that) you musn't make any such assumptions. Always assume that data sent from a remote user is malicious and use it with caution. You could instead sign your cookies with an HMAC to make sure nobody can create a valid cookie without your secret key.