¿Es la seguridad en AEM un problema de plataforma o implementación?

Publicado por: Andrey Pinchuk | Desarrollador Certificado AEM Senior

Imagine la situación: duerme tranquilo y ve su tercer sueño, cuando de repente suena un teléfono: un cliente insatisfecho se queja de que todo el sistema no está disponible. De acuerdo, tales eventos son incómodos para la vida del desarrollador de AEM, todo el equipo y el proveedor de la solución. No hay nada que hacer, un aumento temprano y una búsqueda de una solución por delante.


Para que en tu vida profesional no haya momentos tan alegres, te contaré sobre los problemas de seguridad típicos y cómo asegurarte mejor contra ellos.



Me adheriré a dicho plan:


  1. Seguridad a nivel de autor;
  2. Publicar nivel de seguridad;
  3. Seguridad del despachador
  4. Protección del marco CSRF;
  5. Ataques DDoS.


Consejos básicos para proteger Adobe Experience Manager


El mundo de los proyectos de AEM será aún mejor si cada desarrollador tiene una comprensión común de cómo se puede proteger toda la plataforma de la fuga de datos. Según el diagrama a continuación, tenemos un autor, varios editores y dos o más despachadores (los llamados equilibradores). De hecho, vale la pena prestar atención a estos tres niveles en primer lugar en términos de protección de datos. Estas son las reglas clásicas de trabajo que generalmente se aceptan en la comunidad AEM de todo el mundo.




1. Use HTTPS . AEM está evolucionando rápidamente, proporcionando la flexibilidad para crear un autor en otro protocolo más seguro. Es suficiente generar la clave "Asistente SSL", crear una ruta hacia ella y, por lo tanto, utilizar un protocolo más seguro. En las recomendaciones de Adobe, este paso es precisamente la primera prioridad en seguridad.


2. Instale paquetes con las últimas actualizaciones. El proceso estándar del desarrollador se reduce al hecho de que cuando se trabaja en componentes y servicios, debe buscar soluciones en Google. El objetivo de este paso es monitorear regularmente Service Pack y Hot Fixes. Luego desaparecen muchos problemas, incluidos los relacionados con la seguridad de los datos. Aunque esto no es una panacea, lo importante es mantener el sistema actualizado.




3. Crear páginas ordenadas con mensajes de error. Si inicialmente realiza una página con una breve descripción del error, el cliente verá de inmediato que no está funcionando, mientras que el desarrollador ya estará en el proceso de resolver el problema. Es lógico que esta información no le pase por alto, pero evitará el pánico del cliente y los evaluadores, la confusión en las tareas.


4. Negarse a establecer una contraseña e iniciar sesión en "admin-admin". No sería divertido, pero el problema con el inicio de sesión y la contraseña de baja calidad es bastante común incluso en AEM. Como resultado, en pos de la velocidad u otras consideraciones, obtenemos el sistema más vulnerable. Una vez que encuentre que los detalles de inicio de sesión primitivos están configurados, intente convencer al equipo / superiores y cámbielos por otros más confiables lo antes posible.


Seguridad a nivel de autor


Primero, use vpn . Usar Virtual Protected Network es el trabajo de una red privada segura para establecer una conexión segura entre usted y el servidor. Esta es una herramienta simple e importante: dado que su tráfico estará encriptado, es imposible saber desde dónde está enviando sus datos. Resulta que con vPn nadie podrá acceder a su instancia.


Este enfoque es adecuado para desarrolladores remotos y todos aquellos cuyo trabajo se lleva a cabo desde diferentes lugares con una conexión a Internet inestable.


En segundo lugar, su "autor" siempre debe estar cerrado, incluso de Google . Por lo tanto, puede elegir una contraseña y piratear el sistema: por negligencia, el autor puede ser indexado. Para verificar su vulnerabilidad en un motor de búsqueda, escriba en su línea su dominio y autor y la ruta a crx. Sí, puede contactar a Yandex o Google con una solicitud para eliminar dicha línea en el SERP. Pero, mientras se resuelve el problema, el sistema ya estará disponible públicamente.




En tercer lugar, no subestime los privilegios del usuario "administrador" , que a menudo tiene la capacidad de realizar cualquier operación disponible.


Esto es especialmente crítico en el momento en que un empleado se despide de la empresa. De hecho, para la mayoría de las empresas, el acceso a la instancia no es personal, sino a través de una cuenta de administrador. Es más lógico para hacer lo contrario y para ser conscientes de los cambios específicos en el sistema de un autor particular.


AEM 6.1 introdujo un nuevo enfoque en el que puede establecer derechos específicos para un paquete o servicio de usuario. Pero es mejor hacer un perfil personalizado: es agradable para el empleado y es más fácil para la empresa rastrear quién tiene qué niveles de acceso al sistema. Este enfoque es relevante para los niveles de autor y editor.


Publicar seguridad


Como regla general, solo después de un largo tiempo en el proyecto notan que no verificaron al usuario anónimo. Y aunque un usuario común puede tener restricciones en las operaciones, un usuario anónimo, a menudo sucede, tiene muchos más derechos para realizar operaciones.




El filtro Apache Sling Referrer es un mecanismo conveniente y efectivo para hacer que su aplicación sea segura. Por ejemplo, envíe métricas a AEM, verá información sobre el envío de datos en la Bandeja de entrada. Si excede el valor predeterminado, un sistema de terceros puede enviar esta solicitud. Esto significa que nadie podrá enviar una solicitud. Ingresa el dominio en la configuración; en el momento de la solicitud, lo compara con los datos ingresados ​​originalmente y, si todo coincide, se lleva a cabo la integración.


Resultará llevar a cabo una configuración más flexible con el filtro: puede especificar la solicitud, método, host. También hay un valor vacío o un asterisco para consultas más detalladas.




Seguridad en el nivel Dispatcher


Los desarrolladores enfrentan disputas en el 10% de los casos. Entonces, este es el archivo de configuración principal, donde establecemos el tipo de URL (prohibir / permitir).



Por lo general, los desarrolladores realizan una pequeña tarea, crean una regla y olvidan que agregará vulnerabilidad. Para que nadie intente atacar su instancia, debe verificar la URL con los selectores en el momento de la disponibilidad.


A través del archivo de configuración, puede especificar el procesamiento de encabezados. Debido a que con mayor precisión especifica el zag, método, etc., una configuración tan detallada definitivamente no romperá nada. Estos son ejemplos elementales. ¿Qué pasa si hay cientos de tales reglas y navegarlas es más difícil?


La forma más fácil es habilitar el registro. Dependiendo de la versión de Apache, el mecanismo de trabajo puede cambiar ligeramente. Pero va a resaltar el sistema de inmediato, en cualquier dirección URL de una norma específica que se trabaja y lo que aún necesita ser corregido.


También puede especificar dominios en las reglas: esto es una referencia a la integración.
Una vez que se utiliza el despachador para el almacenamiento en caché, las solicitudes se ejecutan muchas veces más rápido: no necesita ir a ningún lado y verificar, y puede entregarlo inmediatamente al cliente. Además, este método mejora en gran medida la seguridad de su aplicación.


Cross Site Request Falsificación - Solicitud de falsificación.



Principio general de CSRF: suponga que usa su cuenta en el sitio web del banco. Después de la autorización, tiene una sesión estándar con cookies en el navegador, recibe un correo electrónico y sigue el enlace a un sitio sospechoso. En él, un atacante incrustó un formulario, al finalizar el cual sus datos se envían al sitio web del banco.


El punto está en el protocolo HTTP. Un atacante no necesita muchos datos: esta solicitud es suficiente. El servidor del banco verá: ha llegado una solicitud, hay cookies y una sesión, todo está bien. Así es como funcionan los ataques típicos.


¿Qué puede dar AEM para evitar la falsificación de consultas?
Un ejemplo clásico de protección es la generación de un "secreto" en una cadena. Cuando se genera el formulario, este token secreto se agrega desde el campo oculto. Si va al sitio del atacante, el sistema detectará la ausencia de un token o su invalidez y se negará a enviar datos. A veces protegen de los propios usuarios.


Ahora tiene un ajack normal, en el que no puede agregar un campo oculto. En la etapa de autorización, el servidor le devuelve una cookie con un nombre con SCRF, la transfiere al encabezado y la envía al servidor. Entonces firmaste la solicitud.


AEM hará todo por usted: generará claves, tokens, verificará el envío del formulario


Hay casos en que una aplicación está escrita en React y hay un momento difícil con la integración. AEM tomó en cuenta esta situación: solo vaya al punto y firme para la verificación. Adecuado cuando se usan componentes y bibliotecas no estándar.



¿Qué más se puede hacer para proteger el sistema?

  • Bibliotecas responsables de esto. No tiene sentido agregar hasta que rompa algo.
  • En el nivel bajo puedes ver todos los "secretos". Este es un tipo de validación de sus datos.
  • Es simple: hay una API preparada y ya estás protegido de este tipo de ataque.


Ataque DDOS: el segundo ataque más popular


El objetivo es agotar las capacidades físicas del servidor. Se están haciendo millones de solicitudes en algún host. Cuando se convierten en infinitos, el sistema comienza a no hacer frente físicamente. Como regla, atacan poderosamente desde varias fuentes y usan una VPN. El 100% de esto no está asegurado; pero no los ayudemos.



En cuyo caso el sistema es vulnerable:

  • Configure el sistema con el sufijo incorrecto;
  • Hay muchas solicitudes de avs, el despachador en el público no puede reenviarlas;
  • Cuando no está prohibido mostrar un número ilimitado de nodos de contenido. En particular, el renderizador JSON, que puede cruzar la estructura de árbol en varios niveles.
  • localhost : 4502 / .json puede volcar todo el repositorio en formato JSON.


Para que su trabajo en AEM sea más seguro, concéntrese en las capacidades de usuarios específicos.


No olvide pasar por la Lista de verificación de seguridad de Adobe y deje que todo sea estable con su proyecto en AEM.

Source: https://habr.com/ru/post/468231/


All Articles