My application is on SSL(https). If user tries to the url with http , webserver(weblogic) redirects automatically to https.
With secure flag true, cookies will be passed on site is accessed with https.
Will adding secure flag as true makes sense here as my site is not entertaining http request and internally redirecting it to https ?
As per mine understanding , whether i add secure flag true does not make any difference as even i access the site with http cookies not be passed.
It will be passes only when my webserver redirecting to https. So i do not see any vulnerability even without adding this configuration.
Is that correct?
What if your user accesses via HTTPS, gets the cookies, and then later mistakenly accesses via HTTP? The cookies will get sent from browser to server in the clear, the server will redirect, and then everything will be secure again... but that cleartext transmission? That's why you want to mark them as secure.
Related
Current to set the cookies in SpringWebFlux web client, I am manually adding cookies with the equal sign like name1=value;name2=value;name3-value and adding it to the header with Cookie key.
webclient.get().header("Cookie",name1=value;name2=value;name3-value);
But I don't know how to add HttpOnly or Secure flag for these cookies being added.Please let me know how to add these flags while making REST calls to the Https URL using spring webclient ? I couldn't find a way to add these flags. Adding these flags mandatory if the connection is over HTTPS ?
I am manually adding cookies with the equal sign like name1=value;name2=value;name3-value and adding it to the header with Cookie key.
This is a very odd way of doing things - you can add cookies directly with WebClient by using webclient.get().cookie().
But I don't know how to add HttpOnly or Secure flag for these cookies being added.
You can't, and you don't need to - these are flags sent by the server to the client to detail restrictions that the browser should enforce in handling these cookies. It therefore makes no sense to set those flags when sending the cookies to the server - there's no useful behaviour the server would be able to take based on those flags.
I am trying to create a cookie with SetSecure as true. This is creating problem in save or update methods and systems redirect to error page/ throw 403 error. If I remove SetSecure then it's working fine.
Cookie ck= new Cookie("key",value);
ck.setsecure(true);
response.addCookie(ck);// HttpResponse
Q1) Is it okay to just set secure flag to true? Or do I have to take care of some more changes in my webapp?
Q2) I am using http to connect to my webapp. Is this SetSecure flag works with http protocol? Or it has to be Https?
Thanks in advance.
A cookie with the secure flag to true only means that the browser in the other side won't send it to the server if the connection is unencrypted (eg. in http protocol)."The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text."
So in you're case, the cookie will never be sent back to the server after being created, that's why you are getting an error. If you really need to use this flag for whatever reason, you should use an https server.
I'm developing an environment with 2 webapps deployed in Tomcat 7. One authenticate users using form, openid, remember me cookie or x509 cert. This one works as expected and use the Remember me cookie to authenticate properly when generated.
The problem resides in the second one (the client):
When the login request comes back to the client from the first one, I don't see any cookie. I'm pretty sure they are in the same domain (localhost) and the cookie path is "/" but the browser (firefox) is not sending the cookie to the client.
If I want to use the generated remember me cookie to authenticate in the client, do I need to include all remember me cookie stuff from Spring's security?
Is the remember me cookie a good approach? Do I need something like siteminder or other better approaches?
Thanks in advance. Answers will be voted
Check the cookie information when it is sent back from the server (use Firebug to monitor the network traffic if you're using Firefox).
Check the domain and path, and also whether the cookie is flagged as secure. If the remember-me cookie is issued over a secure connection it will be marked as secure and the browser won't send it over HTTP.
If this is the case, you have to explicitly override it (though you're better to use HTTPS throughout). There's a use-secure-cookie attribute in the remember-me namespace element which you can set.
I have a GWT appilcation in which the client makes a request to another domain.
I wrote the request using RequestBuilder in GWT.
On executing the code, I get an error in my browser :
No 'Access-Control-Allow-Origin' header is present on the requested resource.
So I google and I found that the domain to which I am making the request should add this header in the response that it sends. Now I dont't have control over the other domain's server, so I can't do any modification there.
My question is, can I intercept the response and the Access-Control-Allow-Origin header to the response that is being sent by the other domain's server at my server, before I send it to my client?
I tried using Filters but the Filter doesn't get called for responses coming from another domain.
Is this possible to do, am I missing something or is it just not possible?
Vivek's answer that cross domain requests aren't allowed by the browser is true, except for the CORS mechanism, whereby newer browsers that support it can try in a cross origin way to servers that also support it.
However, unless that remote server support it itself, there is nothing you can do. If I server my app from A, and want to connect to B, only B can authorize that. If A were allowed to permit my app to connect to B via some filter or servlet, then I could write an app that makes calls to gmail or facebook or twitter and read/write your settings and personal data at those other urls.
So instead, it is the cross origin server that you are contacting that must approve the connection with the header you mentioned. In lieu of that, you can still use your own server as a proxy for the cross origin server.
Cross-domain requests are forbidden by web browsers as per the same origin security policy. These restrictions are limited to browser based applications and hence you can definitely use your own server application as a filter between the GWT based client side application and the external server.
I am trying to login and retrieve status information from a HTTPS URL via Java programming. I login through /login.cgi, providing the username and password with a POST request to that script.
The script then verifies the credentials and creates a specific cookie (with session information, user name, etc.) and then immediately calls a Location response header to /home.cgi. Which, I'm guessing, the /home.cgi script verifies the cookie information before continuing to load. Otherwise, it just reverts back to the /login.cgi page.
All of this works fine within a browser because of the way browser's handle cookies/sessions correctly. However, within Java, this is very tricky because I can not get the appropriate cookie to send as a request to subsequent pages. I can not get the correct cookie because I am unable to get the HTTP response back (which holds the correct "Set-cookie" value) in between /login.cgi creating the specific cookie and it calling Location /home.cgi.
Is there something I'm missing or is there a better way that Java can handle cookies similar to a browser? (is there a cookie store, etc?)
Thanks for the help,
Steve
Cookie management is by default not enabled in the java.net HTTP API. If you don't need any specific handling or cross-application cookie persistence (the cookies will be deleted when your application terminates), you can simple enable it with
CookieHandler.setDefault(new CookieManager());
How are you making the HTTP connections and managing cookies?
I would recommend just using commons-httpclient rather than managing this yourself. It will automatically manage cookies for you.