I am calling a Azure API app from JavaScript. I need to send a parameter to backend via API based on the domain that application executes under (mydonain.org parameter1, for mydomain.com parameter2). However I need to hide this parameter from the users (when users right click and view JavaScript code, they will not be able to see the parameter).
How can I send this parameters from JavaScript to backend via API app and make in invisible for users?
$.getJSON("api/searchItems/" + myparam,
function (Data) {
...
});
myParam has different values based on where the application executes. if it executes on mydomain.com it is 1 and if it executes on mydomain.org it is 2 etc.
but this code is not approved because you can find out what the parameter is and call the api directly.
This request breaks the golden rule: if it's located at the client then no matter how much you try the client will be able to find it, period.
You do have a couple options and this is subjective since not a lot of detail has been given.
First you can hash the domains though clients will still be able to easily inject their own JavaScript code and determine what domain you're hashing.
Secondly are you validating the client data at the server? Do you have way to associate a domain with something such as a session (which is not effectively a 100% guarantee itself) and reject spoofed domain requests?
I'm not sure offhand what, if any, security concerns there may be with passing a domain name as a string. I presume this is not in conjunction with a form (perhaps viewing data on a specific domain out of a list).
Lastly whatever server side programming language you're using should have a method of allowing you to know what the domain name is, presuming you're not requesting information for domain A from domain B.
Related
I want my app to append query parameters to a given base URL such that when I share the URL with someone outside the app he won't be able to see the query parameters.
When this person clicks on the link leading him to my website I want to deploy a script that using these query parameters. These parameters are specific to a single share. Different link shares will contain different query parameters.
For example: if I send to someone the link "mywebsite.com/?uid=xyz" then I want him to see "mywebsite.com" only. In the client-site I want to be able to fetch the uid value.
Is there a way to hide the query parameter in Android when constructing the URL?
If the answer is no then how can I encode the query parameters in Android and decode them in the client-side in my website, assuming my website contains a one "Contact Form" static page ?
If you want to be sure that query parameters in a URL are not snooped, don't send the URL over an unencrypted channel.
Fortunately, there is an easy way to do this. Use "HTTPS".
See Are HTTPS URLs encrypted?
The caveats:
It is common practice to put Java web services behind a reverse proxy. In this case, the secure endpoint for the connection is typically your front-end web server (e.g. Apache, Nginx, etc). The back-end connection to your actual web service (e.g. Tomcat, Glassfish, etc) uses HTTP and is not encrypted. If someone / something can snoop that network traffic, they can see the URL. Typically this is addressed by using a "loopback" network connection, or similar so that the packets never leave the host that runs the front-end and back-end web services.
Your web browser may need to do a DNS lookup to find the web server's IP address. This interaction happens before an SSL/TLS connection is establish, and could lead to the hostname in your URL leaking. And if it doesn't leak that way, it it is likely to leak because of SNI in the TLS negotiation.
A comment implies that it is better to use POST and put the query parameters into the request body. In fact, that would makes little difference. If you don't use HTTPS, query parameters in a body can be snooped. The only advantage is that request bodies are typically not logged on the server side.
Ah. You have updated your question as follows:
For example: if I send to someone the link "mywebsite.com/?uid=xyz" then I want him to see "mywebsite.com" only. In the client-site I want to be able to fetch the uid value.
That is not possible. The only way you could do that would be to convince the user's browser to hide the characters in the URL. There is no standard mechanism to do that.
You would be better off using a different mechanism to pass the "secret"; e.g. cookies.
If the answer is no then how can I encode the query parameters in Android and decode them in the client-side in my website, assuming my website contains a one "Contact Form" static page ?
Anyway you want! Base64, ROT-13, a decent encryption scheme. However be aware that if your web form (in the user's browser) needs to decrypt the information then the page needs to include the code to do the decrypting AND the decryption key. That means that a resourceful user can figure out what is going on.
I want some content of my website to be dynamically loaded after login. A $.post(...) interacts with a servlet which validates the user's credentials, and then a $.load(url) loads the content from a separate page into a <div>. I noticed that, as long as I know where to fetch the content from, I can force this behavior from the chrome javascript console, bypassing validation.
How can I prevent a user from doing this?
You can't.
Once a document has been delivered to the user's browser it is completely under the control of the user. They can run any JS they like.
The URLs you present on your webserver are the public interface to it. Anyone can request them. You can use authentication/authorization to limit who gets a response, but you can't make that response conditional on the user running specific JavaScript that you supply.
The server needs to authorize the user each time it delivers restricted data. You can't do it once and then trust the browser to enforce it.
You can add a secret parameter to the url you load. By defining a random variable in the users session (server side) or in the database, and then return this variable once the validation is successful so your javascript code can use the variable in the next load call. In the load url you can check at the server side if the secret parameter had the correct value or not.
Hope its clear.
The simple answer is: You Can't.
JavaScript runs within the browser and therefore a user or application can run their own code whenever the feel like. This could be as simple as adding new CSS or running their own JS codes.
The main thing you can do to disable this is to ensure all of the requests are validated on your server side before being run as well as allowing only entry for certain types of information (like only allowing integers as numbers to stop strings coming through).
Something close to this sort of problem is XSS or Cross-Site Scripting. A 3rd party will try to inject some malicious code to a trusted website, usually some form of POST, to affect different users. Here is some more information on the matter
Cross-Site Scripting - Wikipedia
CSS - OWASP
I have a question regarding cross-origin policies.
I have a web app that gets data, usually in JSON format, via ajax.
When the web app initialize, a unique 'key' or 'token' is created from the server via ajax and is sent to the client, as a mean to identify it. The token is sent back on every ajax call for validation purposes. If it is not validated within two hours, a PHP script deletes it, and the user is required to authenticate him/herself again.
If the user sends another ajax call (i.e. if there is activity with the associated token), the token sets its expiration for another 2 hours.
On every call, I validate the token and then process the request. Everything works well but my issue is security-oriented.
Since the token is stored client-side (very crudely, like window.token = 'YTM0NZomIzI2OTsmIzM0NTueYQ==';), won't it be possible for malicious users to inspect the code, copy the JavaScript including the token, and create another app that will access the same data?
Since the token is stored client-side (very crudely, like window.token = 'YTM0NZomIzI2OTsmIzM0NTueYQ==';), won't it be possible for malicious users to inspect the code, copy the JavaScript including the token, and create another app that will access the same data?
Yes.
And possibly even more disturbing to you may be this: it doesn't even matter how your token is stored client-side - they'd even be able to login using the same API you expose to your users for logging in. (And if you think you don't have a login API because it's a form-post or something similar, you're fooling yourself - a form post is just as much an "API" as anything else... and can easily be replicated elsewhere).
The cross-domain stuff has very little to do with anything - as that's a client-side restriction of a browser - intended for the user's protection - not yours. I can make any HTTP request I want from a desktop or a server. I can even setup a service which allows me to proxy all requests made to my service over to your service... so the cross-domain security in browsers is of no help to you.
I am using some global variables on a web application, built on Html/Javascript. I am using these variables across pages (or portions of them), and sometimes they are used as post data for ajax calls. My question is: how secure is this? surely i can set different values for these variables (using a console for example) and then, the calls that rely on this var are made. Imagine the user sets some Id that corresponds to something that he even doesn't have access to..
How should this be done?
Thanks in advance
There is nothing different about this from any web application, from a point of view of security.
Anything sent from the browser must be treated as untrusted by the server. This includes URL parameters, form post data, cookies, http headers and anything controlled by javascript. All these items can be manipulated by an attacker.
Essentially, it doesn't matter what the values are in the client, you only need to worry about them when they hit your server in the form of a new HTTP request (this includes XHR). Until that point, variables with bad values can't do any damage.
Ensure your server can correctly authenticate the current user and only allow them access to data and actions that they are authorised to perform. Ensure that all data received from the browser is checked to be correct (if known) or of the correct datatype and within expected limits, rejecting the data and aborting the action if it is not.
if you use jquery, you can use
$.data()
With this, you can associate the data with an element, thus a unauthorized user will not be able to access it
Javascript has runtime type identification (everything is a var like visual basic), its a loosely typed language.
Javascript has its own security model though
User cannot access files (r/write)
It cannot access or look at user location, files, open windows without demand etc
It is not possible to protect the source of your javascript file either or even pwd protecting it as this is better done server side.
Even encryption or decryption doesnt work because somehow you need to tell your users the key
Worse, JavaScript can self-modify at run-time - and often does. That means that the security threat may not be in the syntax or the code when it's delivered to the client, but it might appear once the script is executed.
There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well.
Is it possible to obtain data from user open id (for example such google one https://www.google.com/accounts/o8/id) via pure JS calls (not using server side at all)?
If you'd be able to send XHR requests to other domains, it would be theoretically possible.
However, since browsers generally enforce same-origin policy, it's not. Also, if you do manage to send a request to another domain, you'd need to be able to parse both the returned content, and response headers (especially the Location and X-XRDS-Location).
However, it's pretty much pointless to try to implement OpenID in javascript, unless you are sure that your users don't have access to a debugger. If they do, they can modify the value of any variable, including the one where you store the user's identity, effectively making the system insecure.