Saltar al contenido principal
Version: 4.7.0

Seguridad en aplicaciones realizadas con Awe

Seguridad AWE

Arquitectura

Awe es un framework de servidor, donde toda la lógica de su aplicación, negocio y interfaz de usuario reside en el servidor. A diferencia de los frameworks orientados a cliente, las aplicaciones Awe nunca exponen su código al navegador donde las vulnerabilidades pueden ser aprovechadas por un atacante.

Utiliza Spring Security para gestionar y configurar todos los aspectos relacionados con este tema.

Bibliotecas de terceros

AWE actualiza constantemente las dependencias a librerías de terceros cuando se liberan parches de seguridad para ellas. Cuando es necesario se crean nuevas versiones de mantenimiento de Awe para aplicar parches. Además, AWE tiene un servidor público SonarCloud para ser auditado y adaptado constantemente para evitar las vulnerabilidades emergentes. Puedes consultar aquí sobre el estado de serguridad de Awe.

Protección contra ataques CSRF

Todas las peticiones entre el cliente y el servidor incluyen un token CSRF específico de sesión de usuario. Awe maneja toda comunicación entre el servidor y el cliente, por lo que no necesitas recordar incluir los tokens CSRF manualmente.

Security request headers
Authorization: f910520d-28b8-4a2b-6e98-f32822bb1677
Sec-Fetch-Site: same-origin
X-XSRF-TOKEN: faad4d18-035a-4394-ab5f-be3bae2a1a09
Cookie: XSRF-TOKEN=faad4d18-035a-4394-ab5f-be3bae2a1a09; JSESSIONID=7177A217096E0BF9E4D47C967C74431D

Cross-Site Scripting (XSS)

Awe tiene protección integrada contra ataques de cross-site scripting (XSS). Awe convierte todos los datos para usar entidades HTML antes de que los datos se procesen en el navegador del usuario.

El filtrado está habilitado por defecto, así que al añadir el encabezado normalmente solo asegura que está habilitado e indica al navegador qué hacer cuando se detecta un ataque XSS.

X-XSS-Protection=1; mode=block

Autenticación y autorización

Awe te permite elegir qué sistema de autenticación y autorización quieres usar, en lugar de definir uno específico. Awe es totalmente compatible con las soluciones de seguridad más utilizadas en el ecosistema de Spring Boot como En memoria, Base de datos, LDAP, OAuth, Oauth2, ...

You can visit this for more info.

Spring Security en Awe

Awe proporciona beans de configuración para gestionar la seguridad en su aplicación. Puede usarlos o sobrescribirlos y crear su método de autenticación personalizado. La configuración de seguridad está en las clases SecurityConfig y AWEScreenSecurityAdapter, donde puede seleccionar el método de autenticación que desee.

Configuration properties
################################################
# Authentication
################################################
# Authentication mode (ldap | bbdd | in_memory | custom)
awe.security.auth-mode=bbdd

################################################
# Custom authentication
################################################
#Provider class beans, separated by comma for multiple providers.
awe.security.auth-custom-providers=

Siempre puede crear su propia clase de configuración de seguridad web extendiendo WebSecurityConfigurerAdapter.

Custom Http security configuration
@Configuration
public class CustomSecurityConfig extends WebSecurityConfigurerAdapter {

/**
* Spring security configuration
*
* @param http Http security object
* @throws Exception Configure error
*/
@Override
protected void configure(HttpSecurity http) throws Exception {
// Your custom configuration
}
}

SSL y HTTPS

Awe recomienda siempre a los desarrolladores que establezcan endpoints seguros y ejecuten toda la comunicación exclusivamente bajo HTTPS. Awe funciona directamente con HTTPS sin necesidad de que el desarrollador deba configurar nada en su código de aplicación. Por favor, consulte la documentación de su contenedor servlet para obtener detalles sobre cómo configurar HTTPS en su servidor.

Validación de datos

En las aplicaciones desarrolladas con Awe, el API de enlace de datos soporta la validación de datos en el servidor, que no puede ser sobrepasado por ataques en el lado del cliente. Sin embargo, Awe tiene una acción de validación en el lado del cliente para hacer una doble comprobación y aumentar la capacidad de respuesta de la aplicación, pero el desarrollador debe ser consciente de que estas acciones deben ser utilizados exclusivamente para conveniencia, ya que son fácilmente eludidos en el navegador. Además, el desarrollador es libre de usar cualquier API de Java para validar los datos, incluyendo la conexión a servicios externos. También hay una integración con el estándar de validación de Bean de Java (JSR 303).

Inyección SQL

Awe es un framework de IU de backend-agnóstico, no trata directamente con acceso backend; en cambio, utiliza un framework backend (e.. Spring Data) para gestionar esto. Awe proporciona mitigación para inyección SQL usando técnicas como Consultas Parameterizadas con QueryDSL. Utilizar internamente PreparedStatementy limpieza de datos de entrada.

QueryDsl Example
QCustomer customer = new QCustomer("Foo");

SQLTemplates dialect = new HSQLDBTemplates(); // SQL-dialect
SQLQuery query = new SQLQueryImpl(connection, dialect);
List<String> lastNames = query.from(customer)
.where(customer.firstName.eq("Foo"))
.list(customer.lastName);
SELECT c.last_name FROM customer c WHERE c.first_name = 'Foo'

Autenticación de dos factores (2FA)

Recientemente, hemos desarrollado un nuevo sistema de autenticación de dos factores basado en aplicaciones de autenticación como Google Authenticator.

Hay tres maneras de gestionar esta autenticación de dos factores en AWE basada en la propiedad awe.totp.security.enabled:

  • disabled: La autenticación de doble factor está deshabilitada y no pedirá un código temporal de acceso.
  • optional: El usuario puede habilitar autenticación de doble factor en la pantalla de configuración y el código temporal será preguntado al iniciar sesión.
Settings screen
Pantalla de configuración de seguridad
TOTP Code screen
Pantalla de código TOTP
  • force: Al iniciar sesión, si el usuario no ha habilitado la autenticación de dos factores, aparecerá una pantalla con el código QR para forzar al usuario a habilitar la autenticación de dos factores. Después de esa pantalla, se pedirá al usuario el código temporal basado en el código secreto previamente generado.
Force two-factor authentication screen
Pantalla de seguridad de dos factores forzada