I have read from one of the blog, for security reasons, its suggested to do the
input data validation at the server side not the client side.
From the above statement, My mind started to ask then
1) what kind of validation i can do with JS in the client side.
2) Is there any rule where any programmers can decide where the validation needs to be performed, whether at the client side or the Server side?
I am building Java based web application
You can do any kind of validation on the client, but you must never rely on that validation.
For UI purposes it is often a good idea to validate on the client since the response time is faster. But since the user can always turn off client side validation (e.g. by turning off JavaScript), you must never rely on it to actually have been performed and re-validate your input on the server.
In general, if the checks are critical to security, don't do it on a system the user can control.
Well,What happens when a hacker replaces your javascript with one of their liking, or just plain submit POSTs and GETs as if it were your code?
Validating at the client is a usability issue.
Validating at the point of USAGE is a security issue.
For instance, you validate data against SQL injection before storing in a SQL database -- the library will do that for you if you choose a good one. You validate data against CSS when you display it as HTML. But if you expose the data it as XML, RSS or JSON, then the validation is different -- if you validated it just at input, you wouldn't prevent exploits for the other formats, AND your input routine would be tied to the output formats you choose.
THE RULE:--
Client validation can be circumvented easily. You should always validate sensitive data on server, regardless of client validation. Validating them on client too is just a matter of improved user experience.
If the user disables javascript your validation will not take place on the client side, on the other side having only server side validation means that the user has to wait for the call to end (client to server and then back), it can become frustrating for him.
The client side validation is there to keep the user happy, so that he does not have to wait too much to see that he misspelled the mail address.
I think the main point is that you should be paranoid on the server side, not assuming that data passed to you has been correctly validated by the client. The client may be an older version which does not properly validate something, or validation may be disabled - or the request may be even coming from a cracker, attempting to break the system.
Of course, part (or all) of the validation can be performed on the client side too, to avoid useless network traffic and cut down latency.
Client side validation is only there to save the client time, so when they input and invalid value it says "Bad value" without the page needing to reload.
Client side validation though should be treated as NO validation, as clients can disable this validation and input bad values.
The server should always validate entered data. Client validation is only for usability.
Related
What is the value of using a authentication token when using a REST webservice instead of sending a username, password over HTTPS/Encryption each time you make a request?
I understand that for instance OAUTH has some benefits cause you don't need to give away your password to 3rd parties, you can pass a token to trusted 3rd parties whom you dont want to share the username/password..etc
But other than this special benefits above which I certainly dont need in my case, why would I use tokens instead of sending username/password everytime.
This might be to make life easy for client, and it does not have to send the username/password everytime. Well ok but then now client has to remember my token and send me the token on every request. So instead of remembering/sending username/password now it will do the same for tokens! So client implementation code does not get any less.
So what is the real value here?
It really depends on the scenario - it's hard to tell without knowing more about the API - but usage of "authentication tokens" is far from universal, you're right that many APIs don't need (and don't use) them. Many APIs simply require an API key to be sent with every request (often via HTTPS to prevent it from being intercepted), or require an API key to identify the user and also a digital signature with a "secret key" to prove the user's identity (see When working with most APIs, why do they require two types of authentication, namely a key and a secret? ).
Usernames/passwords are not often used in public APIs because they're not flexible enough and do not provide enough "separation" between the user identity and the application identity. E.g. you register as a developer to use the Flickr API and create an iPhone app that uses that API - would you really want your developer username/password to be built into the app? What if you change your password later? What if you want to develop 5 apps and track usage for them separately and be able to shut off any app at any time without affecting the others?
However, for cases where you truly want to identify a human user only, not an appplication (e.g. a private API back-end that will only serve your own applications, not a public API), in most scenarios I don't see anything wrong with what you suggested, i.e. username/password over HTTPS with every request. Oh, by the way, auth tokens have the added advantage of being "restrictable" (can expire at a certain time, can be restricted to certain actions only, etc), but obviously this is only useful in very specific scenarios.
ALSO: As user "Dan" pointed out above, when designing an API that requires sending the username/password with every request (or with any request really, even if it's just the login request), be careful how you do it. If you're using a technique which browsers support by default (e.g. HTTP Basic Auth), you're preventing yourself from ever exposing the API safely to cross-domain users (i.e. most likely your API can never be safely called directly from the browser, i.e. from AJAX / Flash / Silverlight code).
This is a complex topic which can't be explained fully here, but just remember that if your API is relying on any security credentials that the browser can remember and then "silently" inject in every request (e.g. HTTP Basic Auth, cookies), then it's NOT safe to enable cross-domain access to that API using any cross-domain technique (CORS, JSONP, crossdomain.xml, etc).
The best way I can answer this is to point you to this page describing REST security. It belongs to the restlet wiki, not to Jersey, but it can be applied to Jersey as well as they are both REST implementations.
This is extracted from the link I provided:
"For the most resistance, the server can present the client with an application level authorization token, an opaque value that the server can verify belongs to the right authenticated user.
Such a token should be be difficult for a third party to calculate, e.g. a server-salted MD5 or SHA1 hash of the user's identification credential.
To defeat XSRF, this application-level token needs to be transmitted by means that the user-agent does not automatically return with each request. For example, it can be sent in the HTML of a form as a hidden field, and returned via POST in the encoded form entity."
We need to design a secure web application. I would like to propose a session handling mechanism which does a challenge-response on every request, not only during login using a CRAM method.
The reason is to harden the web application against session hijacking (eg by CSRF) and replay or man-in-the-middle attacks.
Using a nonce is suggested in some places, but in our webapp it seems impractical, as asynchronous requests can go on, or the user could open new windows, hit the back button etc.
Idea: The client and the server have a shared secret (a previously established user password), every subsequent request does again a challenge/response based on that secret, e.g 'response = hash(challenge + hashedPassword)'. The server executes the request only if the response to the challenge matches. Much like during CRAM, but ongoing for every request.
The question: Is this a feasible idea? If so, it surely has been implemented or is even some standard? How would we use this in a java or php based webapp?
The question really comes down to what you want to achieve. If you want to fight CSRF-Attacks, a secret token in addition to the session key is your way to go. However, changing the token in every request will cause problems - not only will the back-button kill the session, but as one webpage usually contains a lot of asynchronously and parallel loaded data (images, css, javascript, etc.), your approach will not enable any additional data to be loaded afterwards, as each additional request will change the required token, thus killing the session.
You may get around this by embedding all resources into the page via BASE64 and other tricks, but that will seriously hinder your possibilities and may have compatibility issues with some browsers.
So, in the end, your approach will not add much security, but will most likely create a whole set of potential problems for your customers. I'd stick to one secret token per session in the URL to fight CSRF and concentrate on securing against other attacks like XSS and user-friendly security measures like two-factor authentication with a smartphone or something similar. After all, the user is the #1 attack vector nowadays.
Update (2012-06-14)
The token will not fight XSS-attacks, but it will defend against basic CSRF-attacks (e.g. by implanting a bogus url call in an image). I've actually had a situation at work today, where I needed to secure a get-request against user modification and worked up some code. The code may be also usable to secure static, session-timeout form- and link-tokens (right your problem).
The idea is to have a server-secret, which is used to generate a hash/AuthToken over data to secure. If a rogue javascript would try to change any of the given data, the AuthToken would not match. In my specific problem, I have one server authenticating a user and have to send his information over to a third party (username, mailaddress, name, etc.). This GET-Request might be easily changed by any user after authentication, so I have to authenticate the GET-Request-Parameters. By rerunning the AuthenticationToken-Process, the third party can compare the resulting AuthTokens, thus validating the incoming data. Without the shared secret, it is (near-to) impossible to forge the data.
On your problem: Having a static token on GET and POST-requests (or a dynamic one like the project of mine) will protect you against simple CSRF-attacks via e.g. links in forums, which a user has to click to get attacked. As the link will never contain the correct token, your webpage is secure. However, if an attacker manages to load a javascript into the webpage via XSS, you're screwed and no technique in the world will help against it, as the javascript can scan the whole DOM-tree of the page to find an capture any tokens whatsoever.
So, it comes down to this:
use tokens on GET and POST-requests to fight CSRF
secure your page against XSS-injections
I find the OWASP cheat sheets are a good resource for such design decisions:
CSRF Prevention Cheat Sheet
XSS Prevention Cheat Sheet
Your scheme sounds similar to the HTTP digest authentication without establishing any kind of session post authentication. Which is probably an improvement over HTTP Basic. And that is assuming both are over TLS!
I am not sure how feasible your scheme might be or how vulnerable to replay attacks or MITM it might be.
If it is an option you might consider the new <keygen> html5 tag which can help establish a two way TLS session. This would be the most secure option..
Can any one explain me the need and scenarios of server-side validation in java. why can't we use the validation at the client-side using javascript?
Because an attacker can bypass client-side validation by simply disabling JavaScript or calling your server with external tools like httpclient or curl. Finally with tools like firebug one can submit virtually anything.
Also it makes your GUI much more responsive as you don't have to reload the page every time a user tries to submit the form (so moreover, it reduces the network traffic and server load).
Client side validation is good for a better user experience, if he made an error, there's no need to send an HTTP request to find that out.
For example - if the user name should be at least 3 characters long, and the user enters 2, you can immediately tell to the user that there's a problem.
Server side validation protect the server from corrupted / malicious requests, that might be sent by dishonest users.
For example - if the user tries to execute a query that he shouldn't using SQL injection, you can prevent it in the server side, since he may not send the query through you web site, but from a different client.
Mainly for security reasons. If somehow, someone manages to modify your client and bypass validation, you could seriously compromise your server.
I am making app, which would send value to php script. Then php script would conncect to Mysql database and return JSON array. And then the app would read it. How to ensure safety? For now I am not using any safety measures.
It depends, this is such a huge topic that a true answer would take a books worth of material.
What 'safety measures' are you asking about?
If you're talking about involving a web server, then you first need to secure your web server and build an API that is smart enough to protect against most common methods of attack. You need to make sure that other people - just by entering something in URL - cannot do the same thing your intended user can do. This means that you need to validate the user before giving them access to API.
Most common method of doing this is sharing a 'secret key' that only the server and client knows. So your user, with a phone, has a specific key and server has a key. Now user sends data to the server and also sends a validation hash (like sha1(KEY+DATA)). Server then receives data and makes sure that the hash is the same. Never send the key itself together with the request.
Another thing you need to test for are replay attacks. If someone listens in on the communication, then you have to limit the damage. This is usually done by you also sending a timestamp with the request and the server checking if the timestamp is within accepted range, so if someone sends that same request again later, it would fail due to timestamp being different. Server checks for this since timestamp is also taken into account for input data validation.
Then you have to make sure that the data returned from server is correct. So server will ALSO build a validation hash that your phone will check, making sure that someone didn't change the data while it was sent back to your phone.
As an added layer, you can also encrypt data that is sent (and received from API) with a heavy cryptography algorithm like AES/Rijndael 256bit encryption. This will encrypt data with a key that is required to open the data. If phone and server know the key and no one else does, then data can be sent securely.
Then the connection should be HTTPS/SSL, which helps protect communication from being listened in. But this does not help if someone already has access to your phone, so it is recommended to use the other mentioned methods as well.
As for your phone, it is pretty secure by itself as long as you don't have apps installed on it that might compromise that security. Also, if you think you can secure your web server less, thinking that since only phones communicate with it that it is safe, then a hacker can easily listen in on communication on their own phone and figure out the basics of your web service API and then open all the doors. So make sure your security layers go from biggest to smallest: web server is by far the biggest entity in your system.
As you can see, this is a MASSIVE topic that can take a long time to learn. But without knowing what exactly you were asking about, I cannot really help you any further.
I'm developing a server component that will serve requests for a embedded client, which is also under my control.
Right now everything is beta and the security works like this:
client sends username / password over https.
server returns access token.
client makes further requests over http with the access token in a custom header.
This is fine for a demo, but it has some problems that need to be fixed before releasing it:
Anyone can copy a login request, re-send it and get an access token back. As some users replied this is not an issue since it goes over https. My mistake.
Anyone can listen and get an access key just by inspecting the request headers.
I can think of a symmetric key encryption, with a timestamp so I can reject duplicate requests, but I was wondering if there are some well known good practices for this scenario (that seems a pretty common).
Thanks a lot for the insight.
PS: I'm using Java for the server and the client is coded in C++, just in case.
I don't get the first part, If the login request is https, how can anyone just copy it?
Regarding the second part, t This is a pretty standard session hijacking scenario. See this question. Of course you don't have the built-in browser options here, but the basic idea is the same - either send the token only over a secure connection when it matters, or in some way associate the token with the sending device.
In a browser, basically all you have is IP address (which isn't very good), but in your case you may be able to express something specific about your device that you validate against the request to ensure the same token isn't being used from somewhere else.
Edit: You could just be lucky here and be able to rule out the IP address changing behind proxies, and actually use it for this purpose.
But at the end of the day, it is much more secure to use https from a well-known and reviewed library rather than trying to roll your own here. I realize that https is an overhead, but rolling your own has big risks around missing obvious things that an attacker can exploit.
First question, just to get it out there: if you're concerned enough about nefarious client-impersonator accesses, why not carry out the entire conversation over HTTPS? Is the minimal performance hit significant enough for this application that it's not worth the added layer of security?
Second, how can someone replay the login request? If I'm not mistaken, that's taking place over HTTPS; if the connection is set up correctly, HTTPS prevents replay attacks using one-time nonces (see here).
One of the common recommendations is - use https
https man in the middle attack aside using https for the entire session should be reliable enough. You do not even need to worry about access tokens - https takes care of this for you.
Using http for further requests seems to introduce some vulnerabilities. Now anybody with a network sniffer can intercept your traffic steal the token and spoof your requests. you can build protection to prevent it - token encryption, use once tokens, etc. but in doing so you will be re-creating https.
Going back to the https man in the middle attack - it is based on somebody's ability to insert himself between your server and your client and funnel your requests through their code. It is all doable i.e. in case the attacker has access to the physical network. The problem such attacker will face is that he will not be able to give you a proper digital certificat - he does not have the private key you used to sign it. When https is accessed through a browser, the browser gives you a warning but still can let you through to the page.
In your case it is your client who will communicate with the server. And you can make sure that all proper validations of the certificate are in place. If you do that you should be fine
Edit
Seconding Yishai - yes some overhead is involved, primarily CPU, but if this additional overhead pushes your server over board, you have bigger problems with your app