¡La versión 2.0 de Play ya está lista! Ayúdanos a traducir la documentación de la útlima versión y sigue nuestro progreso.

Manuales, tutoriales & referencias

Consulte

Contenidos

Elija la versión

Buscar

Busque con google

Libros

Guía de Seguridad

El framework Play ha sido diseñado pensando en la seguridad – pero ningún framework puede evitar que los desarrolladores arruinen todo y abran brechas de seguridad. Esta guía describe los problemas de seguridad comunes en las aplicaciones web y cómo evitarlos en las aplicaciones Play.

Sesiones

Con frecuencia usted necesita guardar información asociada a un usuario, particularmente conocer si está registrado o no. Sin una sesión, el usuario necesitaría proporcionar sus credenciales con cada petición.

Para eso son las sesiones: un conjunto de cookies almacenadas en el navegador del usuario que lo identifican ante el sitio web, y proporcionan otra información que su aplicación posiblemente decidió alamcenar allí y no en la capa de datos; como por ejemplo el idioma.

Mantega su clave secreta… secreta

La sesión es un conjunto de pares clave/valor, firmadas pero no encriptadas. Esto signifca que en la medida que su clave secreta esté segura, no es posible que terceras personas falsifiquen la sesión.

La clave secreta se almacena en el archivo conf/application.conf. Es muy importante mantenerla en privado: no la grabe (commit) en un repositorio público, y cuando instale una aplicación desarrollada por otra persona cambie la clave secreta por una propia. Puede hacer esto con el comando play secret.

No guarde datos importantes

Sin embargo, debido a que no está encriptada, no debería guardar datos importantes en la sesión. Los mismo pueden ser vistos revisando la cookie del usuario, monitoreando la conexión en una red de área local o por wifi.

La sesión se almacena en una cookie, y las cookies tienen un límite de 4 KB. Adicionalmente, solo se pueden guardar cadenas de texto (strings).

Cross-Site Scripting

El Cross-site scripting es una de las vulnerabilidades más comunes en las aplicaciones web. Consiste en la inyección de código JavaScript malicioso en las páginas web usando los formularios de su aplicación.

Digamos que está escribiendo un blog, y cualquier persona puede agregar un comentario. Si usted incluye directamente lo escrito por los comentaristas en su página HTML, estará abriendo su sitio a diversos ataques. Tales como:

  • Mostrar una ventana emergente (popup) a sus visitantes
  • Redireccionar sus visitantes a un sitio controlado por el atacante
  • Plagiar información que supuestamente solo es visible por el usuario actual, y enviarla al sitio del atacante

Por lo tanto es muy importante protegerse de esos ataques.

El sistema de plantillas de Play automáticamente escapará las cadenas de texto (strings). Si verdaderamente necesita insertar texto HTML sin escapar en sus plantillas, puede hacerlo usando la extensión Java raw() sobre la cadena de texto. Pero si el texto fue proporcionado por el usuario desde un formulario, primero debe asegurarse de que está limpio (sanitized), es decir escapar cualquier código javascript para que no sea ejecutado por el explorador web del usuario.

Cuando limpie los textos introducidos por los usuarios, siempre utilice una ‘lista blanca’ (permitir solamente una lista de tags seguros) en vez de una ‘lista negra’ (prohibir una lista de tags inseguros y permitir todos los demás).

Más sobre cross-site scripting

Inyección SQL

La inyección SQL es un exploit que consiste en usar los campos de los formularios para introducir y luego ejecutar consultas SQL no contempladas por el desarrollador. Esto puede ser utilizado para destruir los datos, u obtener acceso a datos que no deberían ser visibles por el usuario actual.

Al utilizar los métodos “find” de alto nivel, debe protegerse de las inyecciones SQL. Y cuando construya sus propias consultas manualmente, debe tener cuidado de no concatenar cadenas de texto con el operador + sino utilizar los placeholders ?.

Esto está bien:

createQuery("SELECT * from Stuff WHERE type= ?1").setParameter(1, theType);

Esto está MAL:

createQuery("SELECT * from Stuff WHERE type=" + theType;

Cross-Site Request Forgery (Falsificación de petición)

El ataque CSRF puede ser verdaderamente problemático para las aplicaciones web:

Este tipo de ataque consiste en la inclusión de código malicioso o un enlace en una página que accede a una aplicación web haciéndole creer que el usuario ha sido autentificado. Si la sesión para esa aplicación web no tiene tiempo de expiración, un atacante puede ejecutar comandos no autorizados.

Para prevenir este tipo de ataques, lo primero que debe hacer es usar apropiadamente los métodos GET y POST. Es decir, que solo debería ustilizar el método POST para cambiar el estado de la aplicación.

Para las peticiones POST la única manera de proteger adecuadamente las acciones importantes es usar una clave (token) de autenticidad. Play ya tiene incorporado unos métodos helpers para manejar esto:

  • un método checkAuthenticity() disponible en los controladores, que verifica la autenticidad del token de los parámetros de la petición y devuelve una respuesta de ‘prohibición’ si algo está incorrecto.
  • el método session.getAuthenticityToken() genera un token de autenticidad solamente válido para la sesión actual.
  • el tag #{authenticityToken /} crea un campo input oculto que puede agregar a cualquier formulario.

Ejemplos:

public static destroyMyAccount() {
    checkAuthenticity();
    …
}

Esto solamente funcionará cuando sea llamado por un formulario que incluya un token de autenticidad correcto, tal como este:

<form method="post" action="/account/destroy">
    #{authenticityToken /}
    <input type="submit" value="destroy my account">
</form>

Para peticiones POST, el tag form de Play genera automáticamente el token de autenticidad:

#{form @destroyMyAccount()}
    <input type="submit" value="destroy my account">
#{/form}

Por supuesto usted puede agregar la llamada al método checkAuthenticity() como un filtro before si quiere proteger todas las acciones de una jerarquía de controladores.

Más sobre cross-site request forgery

Próximos pasos

Continúa con: Módulos de Play.