we have to set cookie-secure directly in weblogic server instead of giving weblogic.xml
<session-descriptor>
<cookie-http-only>true</cookie-http-only>
<cookie-secure>true</cookie-secure>
It sounds like you are trying to have http-only cookies as a default. This is not possible in WebLogic. You could try to add a custom filter class, but you would have to insert this into every web.xml which is just as much of a hassle.
The better option would be to configure this in a web server or layer 7 load balancer that proxies traffic to WebLogic. For a crude example, insert the following in an Apache virtual host config to add the HttpOnly and Secure flags to every set cookie.
Header edit Set-Cookie (.*) "$1; HttpOnly; Secure"
Related
My website is running under HTTPS protocol and I use only 1 cookie (PHPSESSID). My server is Apache 2.2.22. I noticed that my cookie doesn't have the "HttpOnly" and "Secure" headers, then I tried to set it via my .htaccess :
Header set Set-Cookie HttpOnly;Secure
By the way, the .htaccess works perfectly (url rewriting, deflate, expire headers, Etags etc...). But now... my website generates 4 cookies and PHPSESSID seems not to be secure :
Am i missing something ?
.htaccess is the wrong way to go about this.
PHP has session configuration options for this, you can either set them in your PHP configuration in the usual way (php.ini, ini_set, …), or via a dedicated function call.
session.cookie_httponly and session.cookie_secure are the relevant options here.
See http://php.net/manual/en/session.configuration.php and http://php.net/manual/en/function.session-set-cookie-params.php for additional details.
I've successfully configured Apache to listen over SSL/443 and proxy Tomcat listening on HTTP/8080. I have also set up basic authentication in Apache.
Once the user connects to my Tomcat servlet, will the HttpServletRequest.getRemoteUser() be populated or null. If null, how might I get the remote user?
The simplest solution may be to use mod_proxy_ajp, which in addition to proxying requests also transfers a variety of metadata to Tomcat, including authentication information such as REMOTE_USER.
These docs for Alfresco discuss this configuration, which includes changes on both the Tomcat side (so that it knows to trust the forwarded authentication) and the Apache side.
If you're using a generic http proxy like mod_proxy, you would need to arrange for Apache to add the value of REMOTE_USER to the request (possibly as an X- header), and then arrange for your Tomcat application to recognize and trust that header (and you would obviously need to arrange for your front-end proxy to strip that header from any incoming requests).
I don't know how you would do this on the tomcat side, but this post seems to have some suggestions.
I needed to add
<Location />
Order allow,deny
Allow from all
RequestHeader unset Authorization
</Location>
to the wrapping location, the RequestHeader being the specialty that fixed it.
I found this (again) via http://codeblow.com/questions/remove-fundamental-authentication-header-with-apache-mod-proxy/ - don't know where I originally found it last year, it was a last measure for some security issue.
My Apache Tomcat is running behind an Apache httpd web server connected via mod_jk.
When a browser requests https page (rather than http) as its first session request, Tomcat sends a session cookie with secure flag which makes user's logged in session unavailable for http pages later.
How can I remove session cookies' secure flag using mod_header?
I already tried to add an option into web.xml like below.
<session-config>
<cookie-config>
<secure>false</secure>
</cookie-config>
</session-config>
However, it doesn't work. I guess this option doesn't make servlet request not secure, and Tomcat will put the secure flag on session cookies unless both context's session config and servlet request are not secure.
Here is my own solution added to httpd-vhost.conf for now:
Header edit* Set-Cookie "(JSESSIONID=.*)(; Secure)" "$1"
I have a webapp deployed in Tomcat server with Apache in front of it. One of the requirements, is that the webapp has to be accessible using two different paths. For example:
http://domain.com/aa/bb/v1/*
and
http://domain.com/cc/v1/*
My webapp is configured with the first URL, so any request to /aa/bb/v1/* is handled correctly by Tomcat.
Then, to be able to "forward" the calls to the second URL to the first one, I've used mod_rewrite in apache, like this:
RewriteEngine on
RewriteRule /aa/bb/v1/(.+) cc/v1/$1 [NC,L,P]
This works fine! Except when I activate the digest authentication in Tomcat. In digest, the password sent by the browser is some more or less complex hash value calculated including the username, the realm and among other things, the URI. The URI of the browser, is not the URI of the webapp (I've modified it with mod_rewrite) so the authentication fails.
Any ideas in how to solve this?
Finally I've found one easy solution. One of the configurable values of the Tomcat's Digest valve is to do not validate URIs. This can be done by adding the digest valve configuration in the context.xml file:
<Context>
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Valve className="org.apache.catalina.authenticator.DigestAuthenticator" validateUri="false" />
......
I'm not sure if somebody will say that this is insecure... however, for my case is enough.
I'm a bit out of my depth here and nothing I have found quite addresses my problem. Si any and all suggestions are most welcome.
I've got tomcat6 running on CentOS 6.5 hidden behind an apache server (v2.2.15) and I am using Apache's mod_proxy to expose the tomcat webapps, which are running on port 8080. The tomcat hosts one production application and several development applications. On the apache side, both a Drupal site and the aforementioned tomcat production application are on the same domain and, thanks to rewrite rules, all requests to this domain are changed to https. The development sites are reached via subdomains and do not get re-written as https requests.
For the most part, this arrangement works fine. But parts of the tomcat apps are AJAX (calling a Java Struts 1.2 backend). Most of those requests are handled OK. But a few AJAX requests result in redirects (i.e., forward.setRedirect(true)) and that redirect is http (I guess because the container itself is not secure). As a result, I run into cross site scripting issues. I imagine I can use CORS headers to avoid the problem. But that seems like a hack. Is there a relatively painless way I can use to have tomcat send redirects back as https without making tomcat handle ssl directly?
Cris
You could configure the RemoteIpValve in Tomcat:
Another feature of this valve is to replace the apparent scheme
(http/https) and server port with the scheme presented by a proxy or a
load balancer via a request header (e.g. "X-Forwarded-Proto").
To configure Apache to forward the original protocol in the X-Forwarded-Proto header, add a RequestHeader directive in your Apache config, e.g.:
<VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
...
Note that in Tomcat 7, there is also a RemoteIpFilter.
You don't need to do anything special. It already works. Make sure you set the "redirectPort" in server.xml to Apache's HTTPS port, usually 443, and add the following to your <security-constraint> sections for resources you want secured by HTTPS:
<user-data-constraint>
<description>HTTPS</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
Late to the game here but others may find this-- we had a similar setup and issue where everything worked fine until the application started using ajax posts which did redirects for the response. The fix was to use mod_header in apache to rewrite redirects using "Header edit Location"
http://httpd.apache.org/docs/current/mod/mod_headers.html
Header edit Location ^http://www.example.com/ https://www.example.com/
This went unnoticed prior to the ajax redirects because the browser has no problem doing page level redirects to http (which apache would then redirect back to https). But the ajax cross-site prevention halts at the initial http missing out on that would then be redirected to https by a subsequent request.