I am designing a web application front end I am making use of HTML and at back-end I am using a servlet.At front end side I am storing some values in cookies that are to be used on the server side (i.e in servlet)
Now my question is : How do I get the values of cookies in servlets.
Please help me with this.
HttpServletRequest has method getCookies(), it will return you array of cookies, so just look for your cookie. I assume you already know how to set cookie using servelt response.
Cookies are sent with every request to the web app, and should thus be used very rarely. You should probably use request (get/post) parameters, and store values that must persist for a whole user session in the HttpSession object.
Now, to answer your specific question: everything coming from the client browser is stored in the HttpServletRequest object. Browse the javadoc for this class (part of the Java Enterprise Edition - Java EE javadoc), and you'll find a method named getCookies(). Follow the links, and you'll find how to extract the cookies you're interested in, and get their value.
Related
I've recently started using modern front end technologies like React/Angular and as a result have started using tools like JSON Server to recreate dummy restful db interactions.
My understanding is that most rest api's authenticate via some kind of token and secret that is either passed as part of the url or as a header. This seems fine for retrieving data, but is it not risky exposing these login credentials in a front end language like JS when writing is possible?
My thinking is that all it would take is a simple view source for somebody to steal my token/secret and potentially start populating my db with data.
In the problem that you describe the client (browser) has the login credentials because the server provide them. There is no "exposing" as the credentials are already exposed. Exposing your credentials to every client means that there is no security.
When we talk about security we consider as a client the browser not the real person that operates the browser. As you said, the real person can access all the browser's data.
To secure your API the secret key must be kept secret. This means that each client has a different key and uses it to get their data/services from your RESTfull server.
In a simple senario this key can be used/managed like the session id.
The client should first pass through an authorization process (login maybe) and then a temporary key can be generated for the client's session.
Generally, a key is converted to rights. If every client by default has the key, everyone has the default rights, so you may also remove the key and set the default rights to every request.
A client that you don't want to have full access to your db should have a key that gives him limited access to your db.
On the other hand, if the client provides the key, this is secure. For example a php code on a server that uses the secret key for accessing your API.
We have an application which is destined for https so the data being transmitted is protected (or should I say as protected as need be) I would like to know about protecting/hiding (or similar) queryString values. Its a jQuery/Javascript front end which communicates using a mixture of GET and POST with the database via classic ASP web services. The web services sends JSON back to the client.
I realize the front end code could be changed so everything is passed using POST however the application is finished and tested ready to deploy. There are some key values that are being passed in the querystring which should not have been. Is it possible to make it so the querystring values can not be inspected or sniffed. The URL and querystring together will provide a direct link to the raw JSON. We would like to prevent this. Perhaps there is some jQuery/AJAX feature which can be explored. Perhaps some server IIS level tactic? I guess the sniffing occur before the request gets the the server where the webservice sites therefore some server/IIS level tactic is not an option.
Any ideas/advice would be great, thank you.
You can use HTTP headers to send data to the server that is slightly less visible, but can still be detected using more advanced developer tools and loggers. For example, this answer descibes using jQuery/Javascript (as you've asked) to send data without using QueryString.
You can't really prevent the client from being able to trace these details though.
The solution I personally suggest to you is to look into session state. By scoping a valid data response to a certain session state, and returning null when the state is invalid or expired, you can limit access to the data. This could be after just 1 time its been retrieved. This strategy would involve a generation of a token or code that is passed out from your server at an earlier stage, and used when asking for the data in question.
Another alternative is to either use SSL or encrypt your data and drop it into a posted control such as a text input box. Microsoft adopted a similar process for their VIEWSTATE within ASP.NET.
Following this question: Can a cookie that was generated with Javascript (not send in the header by the server) be stolen / used by an attacker?
This is driving me crazy.
How can one ever keep state at the client using a FB access token?
One should use it to access resources on one's own server, and also from the FB server. Assuming that one uses a js framework (Backbone / Marionette) and REST authentication.
It cannot be encrypted as such, and yet there is no other way than to use a cookie to keep state at the client.
I have done plenty of research.
Every source mentions to keep state at the client, to avoid server sessions, yet I can't find a single source that explains how to do it safely.
If you know the answer, please share.
Thanks.
You can store information on the client safely if the server is delivering it.
You can encrypt or sign the data using a secret key which only the server knows and decrypt/validate the information using it.
However, by definition, you cannot store information safely which is also generated on the client itself. It's just the client playing with itself. Anyone can inspect what exactly is going on, so you can't sign or encrypt anything using any secret key, because by definition the key ceases to be secret if you give it to every client. You can also not trust any information the client is sending to the server because the client is free to send anything to the server it wishes. You cannot trust any code running on the client because it is entirely out of your control.
This is probably a generic security question, but I thought I'd ask in the realm of what I'm developing.
The scenario is: A web service (WCF Web Api) that uses an API Key to validate and tell me who the user is, and a mix of jQuery and application on the front ends.
On the one hand, the traffic can be https so it cannot be inspected, but if I use the same key per user (say a guid), and I am using it in both then there's the chance it could be taken and someone could impersonate the user.
If I implement something akin to OAuth, then a user and a per-app key is generated, and that could work - but still for the jQuery side I would need the app API key in the javascript.
This would only be a problem if someone was on the actual computer and did a view-source.
What should I do?
md5 or encrypt the key somehow?
Put the key in a session variable, then when using ajax retrieve it?
Get over it, it's not that big a deal/problem.
I'm sure it's probably a common problem - so any pointers would be welcome.
To make this clearer - this is my API I have written that I am querying against, not a google, etc. So I can do per session tokens, etc, I'm just trying to work out the best way to secure the client side tokens/keys that I would use.
I'm being a bit overly cautious here, but just using this to learn.
(I suggest tagging this post "security".)
First, you should be clear about what you're protecting against. Can you trust the client at all? A crafty user could stick a Greasemonkey script on your page and call exactly the code that your UI calls to send requests. Hiding everything in a Javascript closure only means you need a debugger; it doesn't make an attack impossible. Firebug can trace HTTPS requests. Also consider a compromised client: is there a keylogger installed? Is the entire system secretly running virtualized so that an attacker can inspect any part of memory at any time at their leisure? Security when you're as exposed as a webapp is is really tricky.
Nonetheless, here are a few things for you to consider:
Consider not actually using keys but rather HMAC hashes of, e.g., a token you give immediately upon authentication.
DOM storage can be a bit harder to poke at than cookies.
Have a look at Google's implementation of OAuth 2 for an example security model. Basically you use tokens that are only valid for a limited time (and perhaps for a single IP address). That way even if the token is intercepted or cloned, it's only valid for a short length of time. Of course you need to be careful about what you do when the token runs out; could an attacker just do the same thing your code does and get a new valid token?
Don't neglect server-side security: even if your client should have checked before submitting the request, check again on the server if the user actually has permission to do what they're asking. In fact, this advice may obviate most of the above.
It depends on how the API key is used. API keys like that provided by Google are tied to the URL of the site originating the request; if you try and use the key on a site with an alternate URL then the service throws and error thus removing the need to protect the key on the client side.
Some basic API's however are tied to a client and can be used across multiple domains, so in this instance I have previously gone with the practice of wrapping this API in server side code and placing some restrictions on how the client can communicate with the local service and protecting the service.
My overall recommendation however would be to apply restrictions on the Web API around how keys can be used and thus removes the complications and necessity of trying to protect them on the client.
How about using jQuery to call server side code that handles communication with the API. If you are using MVC you can call a controller action that can contain the code and API key to hit your service and return a partial view (or even JSON) to your UX. If you are using web forms you could create an aspx page that will do the API communication in the code behind and then write content to the response stream for your UX to consume. Then your UX code can just contain some $.post() or $.load() calls to your server side code and both your API key and endpoint would be protected.
Generally in cases like this though you proxy requests through the server using 'AJAX' which verifies the browser making requests is authorized to do so. If you want to call the service directly from JavaScript, then you need some kind of token system like JSON Web Tokens (JWT) and you'll have to work out cross-domain issues if the service is located somewhere other than the current domain.
see http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx for more information
(How to do API Key Verification for REST Services in .NET 4)
I need to get some data from Site B into Site A's server side. In order to make the request to Site B to retrieve the data, there are cookies associated with Site B's domain which need to be present. I assume I therefore need to do this in javascript with JSONP?
My ideas was to use JavaScript to make the request to B and then capture the result and stick it a cookie on As domain such that subsequent requests to A would carry the cookie with the returned data (it doesnt matter that it takes two requests to A to get the information to A's serverside). This would work fine, except its completely hackable.
The data itself isn't secret but I need to prevent request forgery or people on Site A calling the JSONP callback function manually, or setting the A cookie manually with stolen or otherwise faked data. Also, is there any other loophole for hacking? This would also need preventing!
The only way I can think of doing this is:
Site A generates a random token and stores it in the session. It then appends this token to the querystring of the JSONP request to Site B. Site B then responds but encrypts the usual data along with the token using digital signing. Site A then sticks this value in a cookie on A. In the next request to A, As server side can capture the cookie, get the value, decrypt it, check the token and if it matches the value in the session, trust the rest of the data.
Does this sound sensible? Is there an easier way? My goal is to reduce the complexity at As end.
Thanks
The way to avoid it being hackable is to have the sites communicate with each other directly, rather than using client-side JavaScript. Write a small light-weight REST API which allows the data to be transferred behind the scenes, server to server.
When linking to Site A, include an authentication token in the URL which can then be checked using the behind-the-scenes call to Site B. This call can transfer any additional required information. The token should probably be IP-bound, and expire after use. Upon success, you can set up your cookie information in Site A, to avoid the need for further round trips.
You could use easyXDM to communicate between the domains. With it you have two javascript Programs, one on the consumers domain, and one on the providers, which can assert the domain of the consumer. Both these Programs can interact with the user, and the user can authenticate itself to both parties. With the providers Program knowing who the user is, and knowing who the consumer is, the provider can pass whatever data it wants to the consumer.
This is what big companies like Twitter, Disqus and LinkedIn use for their API's.