Comment configurez-vous les cookies HttpOnly dans les applications Web tomcat / java?

Question

Après avoir lu le blog de Jeff sur Protégez vos cookies: HttpOnly . J'aimerais implémenter les cookies HttpOnly dans mon application Web.

Comment dites-vous à Tomcat d'utiliser uniquement des cookies HTTP pour les sessions?

Answer 1

httpOnly est pris en charge comme de Tomcat 6.0.19 et Tomcat 5.5.28.

Voir le changelog entrée pour les corrections de 44382.

Le dernier commentaire de bug 44382 états-unis, "ce qui a été appliquée à 5.5.x, et sera inclus dans 5.5.28 partir." Cependant, il ne semble pas que 5.5.28 a été libéré.

Le httpOnly fonctionnalité peut être activée pour tous les webapps dans conf/context.xml:

<Context useHttpOnly="true">
...
</Context>

Mon interprétation est qu'il fonctionne aussi pour un contexte particulier, en mettant sur le Contexte de l'entrée en conf/server.xml (de la même manière que ci-dessus).

Answer 2

Mise à jour: Le JSESSIONID trucs ici est uniquement pour les conteneurs. Veuillez utiliser jt est actuellement accepté de répondre à moins que vous êtes à l'aide de < Tomcat 6.0.19 ou < Tomcat 5.5.28 ou un autre récipient qui ne prend pas en charge HttpOnly JSESSIONID cookies comme une option de configuration.

Lors de la configuration des cookies dans votre application, utilisez l'

response.setHeader( "Set-Cookie", "name=value; HttpOnly");

Cependant, dans de nombreux webapps, le plus important témoin est l'identifiant de session, qui est défini automatiquement par le conteneur comme le cookie JSESSIONID.

Si vous n'utilisez que ce cookie, vous pouvez écrire un ServletFilter à re-régler les cookies sur le moyen de sortir, forçant JSESSIONID à HttpOnly. La page d' http://keepitlocked.net/archive/2007/11/05/java-and-httponly.aspx http://alexsmolen.com/blog/?p=16 suggère d'ajouter la ligne suivante dans un filtre.

if (response.containsHeader( "SET-COOKIE" )) {
  String sessionid = request.getSession().getId();
  response.setHeader( "SET-COOKIE", "JSESSIONID=" + sessionid 
                      + ";Path=/<whatever>; Secure; HttpOnly" );
} 

mais notez que cela va écraser tous les cookies et seulement ensemble que vous dites ici, dans ce filtre.

Si vous utilisez d'autres témoins pour le cookie JSESSIONID, alors vous aurez besoin d'étendre ce code pour définir tous les cookies dans le filtre. Ce n'est pas une bonne solution dans le cas de plusieurs témoins, mais est peut-être acceptable quick-fix pour le JSESSIONID seule installation.

Veuillez noter que votre code évolue au fil du temps, il y a un méchant bug caché vous attend pour vous lorsque vous oubliez ce filtre et d'essayer de régler un autre cookie quelque part dans votre code. Bien sûr, il ne sera pas en jeu.

C'est vraiment un hack. Si vous utilisez Tomcat et peut le compiler, puis prendre un coup d'oeil à Shabaz de l'excellente suggestion de patch HttpOnly soutien dans Tomcat.

Answer 3

Veillez à ne pas écraser l'indicateur de cookie "; sécurisé" dans https-sessions. Cet indicateur empêche le navigateur d’envoyer le cookie via une connexion http non chiffrée, ce qui rend fondamentalement inutile l’utilisation de https pour les demandes légitimes.

 private void rewriteCookieToHeader(HttpServletRequest request, HttpServletResponse response) {
    if (response.containsHeader("SET-COOKIE")) {
        String sessionid = request.getSession().getId();
        String contextPath = request.getContextPath();
        String secure = "";
        if (request.isSecure()) {
            secure = "; Secure"; 
        }
        response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid
                         + "; Path=" + contextPath + "; HttpOnly" + secure);
    }
}
 

Answer 4

Pour les cookies de session, il ne semble pas être pris en charge dans Tomcat encore. Voir le rapport de bug Besoin d'ajouter le support pour HTTPOnly cookie de session paramètre. Un peu impliquées travail autour de peut maintenant être trouvé ici, qui se résume essentiellement en manuellement les correctifs de Tomcat. Ne peut vraiment pas trouver un moyen facile de le faire en ce moment, à ce point, je suis peur.

Pour résumer le travail, il consiste à télécharger le 5.5 source, puis modifier la source dans les endroits suivants:

org.apache.catalina.connector.Request.java

//this is what needs to be changed
//response.addCookieInternal(cookie);

//this is whats new
response.addCookieInternal(cookie, true);
}

org.apache.catalina.connectorResponse.addCookieInternal

public void addCookieInternal(final Cookie cookie) {
addCookieInternal(cookie, false);
}

public void addCookieInternal(final Cookie cookie, boolean HTTPOnly) {

if (isCommitted())
return;

final StringBuffer sb = new StringBuffer();
//web application code can receive a IllegalArgumentException
//from the appendCookieValue invokation
if (SecurityUtil.isPackageProtectionEnabled()) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run(){
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(),
cookie.getValue(), cookie.getPath(),
cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
return null;
}
});
} else {
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(), cookie.getValue(),
cookie.getPath(), cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
}
//of course, we really need to modify ServerCookie
//but this is the general idea
if (HTTPOnly) {
sb.append("; HttpOnly");
}

//if we reached here, no exception, cookie is valid
// the header name is Set-Cookie for both "old" and v.1 ( RFC2109 )
// RFC2965 is not supported by browsers and the Servlet spec
// asks for 2109.
addHeader("Set-Cookie", sb.toString());

cookies.add(cookie);
}

Answer 5

De plus, il convient de noter que l'activation de HttpOnly cassera les applets qui requièrent un accès avec état au jvm.

les requêtes http de l'applet n'utiliseront pas le cookie jsessionid et peuvent être affectées à un autre tomcat.