I need to send an ajax POST request to my server.
I'll need to make sure that the request originated from the script itself, and not from a user writing the request him/her self.
Is there any secure way to do this? Can the script sign or encode the POST request, later to be decrypted by the server's private key? and can I somehow prevent the user from encrypting using my public key?
I'm not doing this just for filtering purposes - so plain old server-side validation just won't do.
Anything you do in Javascript can be seen and analyzed, as it's happening on the client side. So encrypting information securely client side is pretty much impossible. That leaves the server as the only point where you can and need to do validation.
Also, why would you care if an input comes from your script or is hand-crafted by a user? If the input is valid and allowed as defined by your rules, it shouldn't make any difference.
For this kind of situation, when in doubt, you need to see the importance of client/server separation. Your server is your app, it's the one and only critical component that you need to take care of. Every input is generally untrusted, every output must be exactly what you intend to disclose.
The HTML/JS interface you're handing to the user is just a help for the human to communicate with your server, but that doesn't mean it's trustworthy or securable once it has left your server.
The other answers are correct: this is fundamentally impossible. Probably the best you can do from a pragmatic point of view is to look into really nasty ways to obfuscate your JavaScript to discourage people who might try to look at it, but you can be assured that someone motivated can work around this without too much effort. http://en.wikipedia.org/wiki/Obfuscated_code
I'll need to make sure that the
request originated from the script
itself, and not from a user writing
the request him/her self.
From the point of view of your server 'the script' and 'a user' are indistinguishable. What you are asking for is fundamentally impossible.
You can't use public key cryptography in pure JS, because the private key (used for signing data) will be exposed. Generally speaking, what you're trying to do is impossible.
Related
Im writing new app and this time i want to completely separate HTML/JS layer from the PHP layer. Thats because I'll do phonegap version in the future.
I have question about authentication. This time I can't use session variables so i must figure out new way of authentication. Im going to try it this way:
User fills login form and send it via ajax to php file.
Php file checks whether login and password are ok or not, and then create a key-token for that user. Save it on his side (ex. in mysql) and return it to the client side as javascript.
Browser is receiving key-token and save it in session_storage.
Each ajax request is attached by this token and then verified by php.
Is there a hole in that plan?. Maybe there is much easier/better solution. Its inspired by how php session works but with key-token instead of session id. Please help me.
I can't use session variables
What you describe sounds exactly like a session, but you're going to implement itself yourself rather than using the known, tested properties and flexibility of the standard PHP session handler. Hence even if you avoid the inherent design pitfalls, you run the risk of injecting defects in your implementation.
I would strongly urge you to use the standard PHP mechanism (although you might want to consider a more complex save handler, even if it's just enabling the multi-layer function).
Given that what you describe is no different from the PHP handler, then, yes it will work if implemented correctly - is it secure? Not from the information you've provided.
Session storage does offer the possibility of carrying out more secure operations without resorting to SSL (although HTTPS is a must have if security is important) since you can pre-share encryption keys (but the initial key negotiation is highly vulnerable).
OTOH what you describe is vulnerable to sniffing, injection and CSRF.
I have an interactive html5 app that let's people customize products on the client-side. As a user is customizing, the price updates based on individual component prices.
Once this is done, the person hits checkout, I send the customization to the server, and the server takes over the checkout process.
Obviously sending price data to the server is pointless, since anyone could spoof the POST data. So, I tried writing a server side script that will regenerate the price according to the components selected (sent to the server with the customization data), and show that on checkout instead. However, the server side calculation is proving very difficult, due to complex customizations offered; and it seems like I have to rewrite the entire client-side customization logic on the server-side (which is a lot of work).
Before I continue writing the server-side script I wanted to know if it is at all possible to send the price data to the server in a way (asymmetric key auth perhaps) that cannot be spoofed?
Never trust the information clients send you.
To answer your question, it is possible to use encryption to send data from the client to the server. However, the problem here is the data being encrypted can be modified even before the encryption. So, encryption is not really the solution. The client might modify the data before encryption and the server will not know this if there are no server-side checking.
Even with public-private key encryption, this will still be unsafe. There will only be an assurance that your data will not be tampered from the user to the server. It cannot be spoofed by third parties but your user can spoof it, thereby making the encryption pointless. So, do not trust the user to send you valid legitimate information.
You should really double check everything in the server. And you will not need encryption unless privacy is an issue (which probably is based on your description). This can easily be solved by using https.
The client-side javascript you created can serve as immediate feedback to the users, they see prices as they make changes to the forms. This is good because they do not need to wait for the server to process the information, which the server should upon submission of the form.
You should never never never trust client-side code. If you want to spare yourself the headache of rewriting your client-side code, you could just put the relevant JavaScript on the server and call it from your server code (Not that I'm suggesting you should do that). Another thing I would recommend doing is recalculating the price based on the contents of a full postback once the user is done with their customization, and then displaying the recalculated price to the user in order to allow them to confirm it. That way if any client-side shenanigans have occurred, the user will get the real price anyway, and I'm sure that if it differs even slightly from the previous price, your support people will hear all about it.
I've been attempting to do some research on this topic for a while, and even cite the following Stack Overflow threads :
Javascript Hijacking - When and How Much Should I Worry
JSON Security Best Practices
But my basic problem is this.
When I am building my web applications, I use tools like Fiddler, Chrome Developer Tools, Firebug, etc. I change things on the fly to test things. I can even seem to use fiddler to change the data that gets sent to the server.
What stops someone else from just opening up my webpage and doing this too? All of the jQuery validation in the world is useless if a user can just hit F12 and open up Chrome Developer tools, and change the data being sent over the wire, right?
I'm still relatively new in this field and this just has me very concerned as I see "Open" Protocols become more and more ubiquitous. I don't understand SSL yet (which is on my list of things to begin researching), so perhaps that is the answer and I just haven't dug deep enough. But the level of flexibility I have over manipulating my pages seems very extreme - which has me very concerned about what someone malicious could do.
Your concerns are indeed justified. This is why you should always validate everything on the server. Client-side validation should only be used for UX.
JavaScript's security is, in a nutshell, based around a trusted server. If you always trust what code the server sends you, it should be safe. It's impossible for a third party (like an ad supplier) to fetch data from the domain it's included on.
If the server also sends you user generated content, and in particular user generated code, then you have a potential security problem. This is what XSS attacks focus on (running a malicious script in a trusted environment).
Client side validation should focus on easy of use, make it easy to correct mistakes or guide the user so no mistakes are made. The server should always do validation, but validation of a more strict nature.
Validation should always happen Server Side, Client Side Validation is only valuable to make for a more convenient experience for the user. You can never trust a user to not manipulate the data on their end. (Javascript is ClientSide)
Next if you are wanting to secure your service so that only user1 can edit user1's profile you'll need to sign you JSON request with OAuth (or similar protocol).
yeah nothing can stop anybody from interfering the data that is being sent from the browser to your server and that's the reason you shouldn't trust it
always check the data from the user for authenticity and validity
also with it you can check and interfere with the data that big sites like google and microsoft send back and you might get an idea.
You have to assume that the client is malicious-- using SSL does not prevent this at all. All data validation and authorization checking needs to be done server side.
Javascript isn't going to be you only line of defense against hackers, in fact it shouldn't be used for security at all. Client side code can be used to verify form input so that users trying to use the page can have faster response times, and the page runs nice. Anyone who is trying to hack your page isn't going to care if your page works or not. No matter what, everything coming into your server should be verified and never assumed as safe.
We are creating an online service divided like that:
- an API, of course
- full JS/AJAX client, no MVC, it is pure JS
We are experienced developers and we do know that we can't secure the JS client code, however, we are trying to figure way to prevent 3rd parties from creating their own client by analyzing our JS API Call and this way restrict access only from our own client.
Thanks in advance!
We are experienced developers and we do know that we can't secure the
JS client code, however, we are trying to figure way to prevent 3rd
parties from creating their own client by analyzing our JS API Call
and this way only restreint access from our own client.
That is contradiction in terms. If you know that client-side ECMAscript code can never be hidden, it will always be possible for any somewhat experienced developer to analyse your code. Even if heavily obfuscated, minified and uglified.
Use a server-side authentication, by password. Its the only secure way. You just can not prevent that somebody will clone/copy your script.
I don't think you can. Perhaps generate a key or something to authorize requests.
For you and anyone with a similar question, take heed; it is impossible. If you send a user working code that will communicate with your API, there is nothing you can do to stop then modifying or re-writing that code. The only area you can keep secure is the back-end.
Oh, this is the wrong question to ask.
The question you need to ask is "why do I care if someone accesses my server without my client?"
You obviously have a reason. I can think of one reason only - your server trusts the client to behave nicely. Don't do that. Make sure the server can handle any kind of zany client request. It doesn't have to handle it nicely (throwing a 500 Server Error is OK) - as long as rogue clients can't mess with your data or kill your server entirely.
You could try to obfuscate your javascript code to make it hard readable:
a link to an obfuscator
you can find outhers
If you have authentification, you can pass session id to your API to keep user logged in, so if user is not authentificated he won't be able to get data from your API.
In a previous question I asked about weaknesses in my own security layer concept... It relies on JavaScript cryptography functions and thanks to the answers now the striking point is clear that everything that is done in Javascript can be manipulated and can not be trusted...
The problem now is - I still need to use those, even if I rely on SSL for transmission...
So I want to ask - is there a way that the server can check that the site is using the "correct" javascript from the server?
Anything that comes to my mind (like hashing etc.) can be obviously faked... and the server doesn't seem to have any possibility to know whats going on at the clients side after it sent it some data, expept by HTTP headers (-> cookie exchange and stuff)
It is completely impossible for the server to verify this.
All interactions between the Javascript and the server come directly from the Javascript.
Therefore, malicious Javascript can do anything your benign Javascript can do.
By using SSL, you can make it difficult or impossible for malicious Javascript to enter your page in the first place (as long as you trust the browser and its addons), but once it gets a foothold in your page, you're hosed.
Basically, if the attacker has physical (or scriptual) access to the browser, you can no longer trust anything.
This problem doesn't really have anything to do with javascript. It's simply not possible for any server application (web or otherwise) to ensure that processing on a client machine was performed by known/trusted code. The use of javascript in web applications makes tampering relatively trivial, but you would have exactly the same problem if you were distributing compiled code.
Everything a server receives from a client is data, and there is no way to ensure that it is your expected client code that is sending that data. Any part of the data that you might use to identify your expected client can be created just as easily by a substitute client.
If you're concern is substitution of the client code via a man-in-the-middle attack, loading the javascript over https is pretty much your best bet. However, there is nothing that will protect you against direct substitution of the client code on the client machine itself.
Never assume that clients are using the client software you wrote. It's an impossible problem and any solutions you devise will only slow and not prevent attacks.
You may be able to authenticate users but you will never be able to reliably authenticate what software they are using. A corollary to this is to never trust data that clients provide. Some attacks, for example Cross-Site Request Forgery (CSRF), require us to not even trust that the authenticated user even meant to provide the data.