¿Cuáles son los riesgos de seguridad cuando los usuarios cargan su HTML y javascript en AWS S3 y el contenido se usa en una aplicación web?

No, no pueden "piratear el sistema central" con HTML / JS (y definitivamente no CSS). Si les dio acceso a PHP, debe tener cuidado, pero el HTML / JS / CSS normal es inofensivo para su servidor. Aunque no tanto para los visitantes. Un cargador malicioso puede hacer cosas que dañen a visitantes en el sitio.

Hay una cosa de la que deberías tener cuidado al respecto. Realmente depende de tu configuración.

Supongamos que el código proporcionado por el usuario está alojado en www.mydomain.com . Digamos que www.mydomain.com también tiene una función de inicio de sesión en el mismo servidor. Como ejemplo del mundo real, digamos que usted es propietario de Facebook y está permitiendo a las personas alojar archivos HTML / JS en un subdirectorio (por ejemplo, www.facebook.com/username/index.html o algo similar). Ahora, si visito www.facebook.com/eviluser/index.html , su JS tiene acceso a mi cuenta. Usando AJAX, él puede causar estragos en mi cuenta. Si hay otros sitios web con Access-Control Allow-Origin para www.facebook.com , y También he iniciado sesión en esos, su JS puede causar estragos (a través de AJAX) allí también.

Básicamente, debes estar seguro de que todos los AJAX escritos por el usuario no pueden hacer daño a un visitante. La forma más sencilla de hacerlo es alojarlo en un dominio donde no hay ninguna funcionalidad de "inicio de sesión"; Así que JS malicioso no tiene sesión de abuso. O prevenga el AJAX del mismo origen (que probablemente no sea posible ).

Otra cosa de la que debes tener cuidado es que tus usuarios usan clickjacking / etc y bloquean tu sitio.

Realmente no podemos ofrecerle una garantía de seguridad, ya que todo depende de lo que su implementación sea a nivel de código.

Lo que siempre debe tener en cuenta al aceptar y ejecutar código de fuentes no confiables es, ¿cuáles son los riesgos si este código es malicioso? Para ayudar a reducir las posibilidades de explotación de su código, que podría deberse a que el usuario pueda "escapar" de su sistema de plantillas y, en su lugar, ejecutar el código como lo haría el analizador de plantillas para ejecutar el sistema en un entorno limitado.

En un sistema Linux típico, esto generalmente se logra ejecutando un chroot . Debe implementar esto cuando analice los códigos cargados de su usuario.

Que trata de explotaciones de nivel inferior, el siguiente problema es: ¿está alojando el código generado? Si es así, debe estar consciente de cosas como las vulnerabilidades de XSS. Si está permitiendo que los usuarios alojen contenido de JavaScript de un dominio desde el cual está aceptando los inicios de sesión, esto es un problema porque podrían escribir fácilmente una función JS que robe sus tokens de autenticación. Por lo tanto, pueden pretender ser el usuario que ha iniciado sesión en el sitio y tener acceso sin restricciones, ya que no tienen control del dominio. Puede leer más sobre esto buscando el control de acceso Permitir origen.