2011-06-25 16 views
12

Migramos nuestra aplicación de JBoss 5 a JBoss6 y una de las principales razones para esto es hacer uso de las nuevas características de servlet 3.0. Todo funciona bien, aparte de una nueva característica de JBoss 6 y servlet 3.0: configurar la cookie de sesión para que solo se transfiera a través de un canal seguro, incluso si la solicitud se realizó a través de HTTP simple. Esta es una característica de seguridad muy importante para nosotros y se logra agregandoProblema con la característica de seguridad de sesión de JBoss 6 usando servlet 3.0

<secure>true</secure> 

en web.xml. Esta es parte de nuestra web.xml:

<session-config> 
<session-timeout>25</session-timeout> 
<cookie-config> 
    <http-only>true</http-only> 
    <secure>true</secure> 
</cookie-config> 
<tracking-mode>COOKIE</tracking-mode> 

Cuando eliminamos la

<secure>true</secure> 

todo funciona bien. Cuando está allí, se genera una nueva jsessionid para cada solicitud incluso cuando se encuentra en una página segura (HTTPS) o en una página no segura (HTTP). Además, el inicio de sesión no funciona, ya que después de iniciar sesión con credenciales seguras, el usuario es redirigido a la página de inicio de sesión.

Supongo que esto también podría ser un problema con Tomcat 7 ya que también utiliza la especificación de servlet 3.0. Cualquier consejo sería muy apreciado.

Saludos

+3

Perdóneme, pero en mi humilde opinión, JBoss AS 6 es casi tan defectuoso como 5. Tenga cuidado. Solo mire las entradas de JIRA con estado 'cerrado' y' no arreglará'. ¿Por qué no JBoss AS 7? –

+2

@GrzesiekD gracias por su comentario. De hecho, hemos migrado a 7 ahora. Esta pregunta ahora tiene casi 2 años. – Alex

+0

Sí, tienes razón. Me di cuenta de esto después de publicar un comentario. Mea culpa. –

Respuesta

2

De acuerdo con la HTTP Specification:

Secure

opcional. El atributo Secure (sin valor) dirige al usuario agente a utilizar únicamente (sin especificar) medios seguros para contactar con el servidor de origen cada vez que devuelve esta cookie.

El agente de usuario (posiblemente bajo el control del usuario) puede determinar qué nivel de seguridad que considere apropiadas para "seguro" galletas. El atributo de seguridad debe considerarse seguridad consejo del servidor al agente de usuario, lo que indica que está en el interés de la sesión proteger los contenidos de la cookie en .

Significa que la especificación deja abierto el navegador (agente de usuario) para definir qué es "seguro".

El elemento Secure en el web.xml es una referencia para el HTTP Cookie Secure property, y puede realizar un seguimiento de ese valor con la herramienta de depuración de su navegador.

Si la comunicación no es "segura", el navegador no enviará la cookie recibida al servidor en las siguientes solicitudes.

El problema no es que JBoss siempre devuelva cookies nuevas, sino el navegador que no las envía porque la comunicación no es segura. JBoss luego crea una nueva sesión para cada solicitud.

Está muy claro que para la comunicación no encriptada (no HTTPS) el navegador no enviará la cookie, esto es esperado ya que está marcando la cookie como secure = true.

Pero, incluso si usted está utilizando HTTPS, "segura" es relativa al concepto de navegador de la seguridad, por ejemplo:

  • Certificado puede estar vencida
  • certificado es auto firmado
  • está utilizando un nombre de host diferente a la que firmó el certificado

Estos y otros problemas de seguridad pueden suceder con TLS, lo que significa que la comunicación es no segura.

El problema debe ser con su configuración SSL/TLS o Cookie, lo que significa que debe verificar lo que ha hecho y resolver el problema. No creo que haya ningún error en JBoss o JBossWeb (tenedor Tomcat 6) que lo provoque, y con seguridad no es un error de especificación.

Pude configurar un JBoss 6.1.0 Final con TLS y con su configuración web.xml, y todo funcionó como se esperaba.

Le sugiero que vuelva a verificar su configuración, la depuración del navegador y las alertas.

Cuestiones relacionadas