Estoy probando una aplicación y me encuentro con algunas páginas de javascript que son de acceso público. Anteriormente también encontré algunos sitios web que permiten el acceso público a las páginas .js.
Por mi parte, esto se puede considerar como un problema de seguridad, ya que una de las páginas ngapp.js contiene la lógica completa de la página angularjs.
Y si quiere asegurar estas páginas después de la autenticación, ¿es posible?
¿Puede alguien aclarar esto?
Entonces, supongo que el motivo de su pregunta aquí no es si los archivos JavaScript están ofuscados o no, sino si son accesibles antes de la autenticación.
Si ese es el caso, entonces diría que no debería ser un problema, ya que el JavaScript se envía del lado del cliente y, por lo tanto, no debe incluirse información confidencial en él.
Dicho esto, como medida de refuerzo, generalmente recomiendo no proporcionar ninguna información a un atacante que no tenga que hacerlo, por lo que restringiría el acceso a la autenticación posterior siempre que sea posible. Cosas como las aplicaciones angulares pueden revelar mucha información como rutas de aplicación válidas, lo que es útil para los atacantes que intentan encontrar otros problemas.
En términos de cómo lograr esto, sugeriría que se puedan separar las plantillas del sitio, de modo que se pueda acceder a la aplicación principal Angular (o similar) solo después de la autenticación.
Este es el diseño previsto y no un problema, excepto cuando los autores del sitio olvidan que este es el diseño previsto.
En una aplicación web, Javascript debe ser legible por el navegador, ya que es donde se analiza y ejecuta. Y cualquier cosa que el navegador pueda leer es legible para un atacante. Por lo tanto, la seguridad del sistema no puede depender del secreto de Javascript.
En cambio, puede estar pensando en las reglas de los scripts CGI. Una secuencia de comandos CGI se ejecuta en el servidor, no en el cliente, y por lo tanto, no es necesario que el cliente necesite . Además, no es inusual que la información "secreta" (como cadenas de conexión de base de datos con nombres de usuario y contraseñas) esté incrustada en el script CGI, lo que significa que tener que ser legible para el cliente es muy malo. Y debido a que es un error de configuración del servidor web algo común (para permitir que el cliente descargue la fuente de script CGI), existe un problema de seguridad.
Por supuesto, algunos autores web prefieren que su Javascript no sea fácil de leer. Esto generalmente es un problema de propiedad intelectual en lugar de seguridad, aunque los autores de malware en particular usarán varias técnicas de ofuscación ( aquí hay un ejemplo ) para dificultar que el atacante lea su código. Esta no es una verdadera medida de seguridad, pero aumenta el costo para el lector para determinar qué está haciendo el Javascript.
A veces los autores olvidan que su Javascript no es secreto. BMC Remedy solía tener una "medida de seguridad" para proteger las credenciales cuando la conexión se realizaba a través de HTTP sin cifrar. El código de Javascript "codificaría" la contraseña del usuario antes de que fuera enviada a través de la red desde el navegador al servidor. Desafortunadamente, el "cifrado" estaba en la línea de "Reemplazar A con Q, reemplazar B con G, ..." y cualquier atacante que leyó el JavaScript y capturó el tráfico no cifrado invirtió fácilmente.
Lea otras preguntas en las etiquetas javascript angularjs