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.
Related
I am a newbie in Javascript and Vue.js. Try to learn more about it. Now I will be facing a problem when calling an API login that will display a password in the request payload.
I was wondering it does not secure, right? And if it was correct. How to hide it from the browser?
Anyone please help or suggest to me.
This is a pretty heavy topic and the question is not very specific, so I'll make some assumptions along the way.
calling an API login that will display a password in the request payload
I suspect you mean that if you're looking into the requests in the browser dev toolbar, the password is seen.
If this is the case, this is expected and can't be 100% mitigated. I've known people to assume that this means that this means that the data is not encrypted and develop custom solutions to obscure the sensitive data. The thing to keep in mind though is that the browser already does the encryption for you as long as you use https. The encryption happens after the request leaves your browser, so you're not seeing it as encrypted, but it travels to the designated server in a way that hides the content for anyone in the middle. If you add some additional encryption system, you're adding complexity and as long as you're passing the key as-well, the "man in the middle" has access to that too. The endpoints within the target server are also encrypted, so you could even use GET to pass sensitive information without anyone between your browser and server knowing what it is, but don't use GET, since POST has additional benefits like not storing the values in your url cache and the server is less likely to be storing the data in the logs.
When using https properly, your data will be encrypted between browser and server.
You should be using POST requests for sending sensitive data
Avoid adding custom encryption on top of https. It will add more complexity than security.
There's also some considerations around storing the token in LocalStorage vs cookies. The final decision on which is better is inconclusive, but as long as proper precautions are taken, they can both be secure (though I think cookies can be more secure, but only if you make them inaccessible by js, so it makes working with them in context of an SPA harder)
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 don't want to leave any chance for hackers to see what I put in URI apart form the domain. For example,
http://www.mynewwebsite.com/ (some text or webpage.html)
In the above, I want to make '(some text or webpage.html)' secure
Now I am confused between two approaches.
1) Should I add a custom http header whose value is "(some text or webpage.html)" and on the server, I read the header to address the request.
2) Should I simply switch to https?
What are the pros and cons of each? (Forget about additional money i need to pay to use https)
Thanks in advance.
Switching to https is simple solution if you don't want hackers to sniff your network and read request params
With HTTPS, the request and headers are encrypted, this should prevent prying eyes as per your requirements. Depending upon your setup, the SSL certificate may be free using Let's Encrypt.
If you simply add a custom header to an HTTP request, you may hide your intentions from a cursory glance but the data could still be accessible to a 3rd party.
1) Should I add a custom http header whose value is "(some text or
webpage.html)" and on the server, I read the header to address the
request.
I think you misunderstood how http works. The header content are sent before the body content. The hacker could simply read the entire stream and focuses on just the header to extract information.
2) Should I simply switch to https?
Switching to HTTPS is a must (to me) if you are going to do user authentication or wanting to keep something secret. It encrypts the information so unintended recipients cannot understand. The recipient have to decide that information with their private key.
There are a number of SSL options that you have.
lets encrypt
It's the biggest free ssl certificate provider. However their certs only have a 3 months life so you need to renew it every now and then. Perhaps you can look up cron job and use it to check with let's encrypt server and renew when expire date near.
Other paid ssl provider
Although both has no differ in encryption level. But features that standout between the two that lets encrypt yet to have is wildcard ssl on *.yoururl.com. This offers the entire sub domain not just a single url as well as in an event of breach, insurance will cover for the damage.
HTTPS encrypts your payload (including headers and URL via SSL/TLS) along the route from point A to point B, preventing hackers from seeing your data if they intercept it between these two points. It's the only way to achieve the security you're looking for.
However if the potential hacker legally sits at point B, HTTPS will not help you. Regardless if the information is tucked away in the header or part of the URL, it will be visible. Anyone can see the headers. If you want to hide specific information from the end-user, manually encrypt it.
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.