Consider I'm having >5KB size cookies, Which is a confidential data generating on client side which no one else can see that data.
So I'm trying to restrict that data to send with request. Is there any way to tell that do not send this cookies with request ??
As per cookies spec
When it sends a request to an origin server, the user agent includes a Cookie request header if it has stored cookies that are applicable to the request.
What is giving hope is in spec is stored cookies that are applicable to the request.
How to make it un- applicable to the request ??
So is this impossible ? Is there any way to configure web.xml in such a way like we set http-only?
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>
The limit for cookies per domain is about 4KB, which you already exceed. Therefore, you ought to put all the confidential information into a session table instead of a cookie.
The HTTP specification states, that all cookie data need to be send with each request, because probably the server needs it. If you do not want that, then do not store data inside cookies, but use a different method of storing this sensitive information.
There is as well a good chance, that this sensitive information ends up in the access logs of the target server, another reason to not use cookies for that case.
Related
I was wondering what kind of metadata is important to save on incoming http request.
Beside headers, Cookies and Session ID, is there more metadata that is important to log?
I was wondering what kind of metadata is important to save on incoming HTTP request.
It depends on your needs, but you always can log the HTTP method, the URL and the headers (it includes Cookie and Authorization headers).
You also may want to log the IP address of the caller and the request date/time.
I'm implementing a temporary and very simple token-style authentication mechanism for an application.
The idea is very simple. Whenever a user logs in to the application, a token is returned to the client, which stores it in the sessionStorage data structure of the browser.
Now, whenever I do a request through AJAX I can send the token with the request and the server can verify if this token is associated with an authentication or username. If it is, it parses the request normally, if not, a error page or the initial page is returned or displayed.
I'm not sure if this is the way that token-style authentication and authorization is implemented in real or serious applications, but I've now no idea how to send the token when doing GET requests by just clicking on the link of a view.
My only idea would be to intercept the get requests so that I can fill them with the token, but this all seems to be quite odd, and I've already a lot of links and views.
Search for Json Web Tokens and for implementations on java. This is exactly what you need.
If you want to send to the user some sensitive data inside the jwt, use Json Web Encryption.
You can send that token on each request header or as a request parameter
You can set a cookie, ensure to set it httponly (ans secure if you are on an https site) and read the cookie on every request that reach the server.
You can use JWT token (see https://jwt.io/introduction/). JWT is basically a JSON data structure. Usually, the token is passed along in the authorization http header.
I have a legacy Java webapp that does MANY redirects and forwards. I'm trying to find a way in a ServletFilter to differentiate GET requests from those server side redirects and GET requests that come from the client side.
I was hoping to do that by adding an attribute as a flag, to the header before the redirect/forward is sent and then read it in the ServletFilter to route it accordingly.
I tried request.setAttribute("myflag", "yes") before the redirect and request.getAttribute("myflag") in the ServletFilter. All I got were null values.
Can I modify headers server side and read those modifications server side?
Thanks in advance for any tips.
You can use a HttpServletRequestWrapper, there is a comprehensive tutorial on how to do that here:
http://vangjee.wordpress.com/2009/02/25/how-to-modify-request-headers-in-a-j2ee-web-application/
don't use request.setAttribute()/request.getAttribute() , it's scopes on forwards.
you can use Cookies.
If your application sets a request attribute and then forwards the request, the filter (if executed) on the forwarded URI will see the request attribute values.
In contrast, if the application sets a request attribute and then issues a redirect on the response, the browser issues a new HTTP request to the next URI - so previous request object attributes are not persisted and you'll get null values.
You could use this technique to determine which requests were redirects vs forwards.
For example:
Servlet A executed at URI /webapp/a calls request.setAttribute("forward", Boolean.TRUE) and then response.sendRedirect("/webapp/b")
If you have a servlet filter mapped to /webapp/b, in the scenario above, request.getAttribute("forward") will be null.
If, however, /webapp/a asks RequestDispatcher to forward to /webapp/b, then the call to request.getAttribute("forward") within the servlet filter's doFilter() will yield Boolean.TRUE because the request object is the same. It can then deduce that the request was forwarded (or included) and not a redirect OR a direct GET request to /webapp/b.
My initial code generated tokens for the requests that could alter state of my database, like CRUD operations. The token was generated for each request. Sent to client side in JSON-format along with other data and I expected this token to be returned with the request and changed it after completion of the request. But, as I implemented it to only parts of my code (CRUD operations), I was told to redo it and make it web-app wide. I think the best way to do this is with filters.
My problem is, how do I make the client send "the token" for each request? Do I set it in cookies? What are my options? Please advice.
best way is , all links should be GET request, and within get requests no modification should be made to application state. So for GET requests there will be no need for CSRF tokens.
For POST request s which make modifications in application state you have to generate, csrf hidden fields in your forms and validate the token in server during form submit.
I have found a strange behaviour (strange for me, a novice :D) in my project.
Basicly after an action I create or update a cookie (if it exists or not) and send it to the client. The strange thing is that in the jsp I can read the cookie ONLY when I update its value (and I get the updated value, not the old one) but not the first time, when I create it (I can see the cookie using a browser tool but seems that the jsp can't read it).
Is this a normal behaviour? If yes, what do you suggest to do in order to have the cookie information available also at the first time?
Thanks very much!
Roberto
If you create or update a cookie, it will be stored in the response header. If you request a cookie, it will be requested from the request header.
I think your problem is that you're forwarding the same request from servlet to JSP and that you expect that the new cookie is already available in the request header. This is not true. The new cookie is only available in the subsequent requests.
You have 2 options:
Redirect to JSP. A redirect will create a new request.
Store the data of interest as request attribute and let EL in JSP access it.
By the way, I saw in one of your comments that you're using plain Java code to read cookies in a JSP. I would only say that using scriptlets in JSP is a bad practice. You can access cookie values easily in EL as follows:
${cookie.cookiename.value}
[Edit] oh my, now I see that this is an old topic. Hopefully my effors weren't all for nothing :/
Cookies are stored on client, and so if the response doesn't gets to the client yet, its value is not updated, but it should be available on the next requests.
cookies are used to identify clients when they send you any requests. here's what you are doing when you set the cookie up. you are sending the cookie to the client along with response. And when that client send his next request the cookie that you set comes along with it. so, in the jsp page where you are setting up the cookie, you don't have a request from the client with cookie! so you can't read it. but what you can do like what jerjer has said above. (i.e use a temp and store cookie's value in it and don't try to retrieve cookie. just read the temp value). And i see you say you can read the cookie only when you update. You will be able to read cookie's value from future reqests after cookie is set even if you don't update it. Hope this helps.