Javascript Los comentarios son un riesgo de seguridad?
security comments (5)
Durante una auditoría PCI de recient, el auditor dijo que teníamos riesgos de seguridad importantes porque
- Fue posible descargar recursos estáticos de nuestro sitio web, como imágenes css y javascript sin autenticación previa.
- Nuestro javascript tenía comentarios en ella.
Personalmente creo que esto no es un riesgo de seguridad en absoluto. Las imágenes css y javascript no se crearon dinámicamente y no contenían datos sobre nuestro backend, los detalles de nuestros clientes y sobre los mecanismos.
Los comentarios dentro del javascript simplemente explicaban lo que hacían los métodos en el archivo javascript. Que cualquiera que lea JS podría haber descubierto de todos modos.
¿Cómo se muestra eso " fuga de información "?
¿Son los comentarios dentro de javascript realmente un riesgo de seguridad?
Depende del contenido del comentario. Debido a que no hay forma, sin la intervención humana, de examinar el contenido de los comentarios para determinar si son riesgosos, la forma más eficiente de auditar esto es declarar que todos los comentarios en el código fuente orientado al cliente son riesgosos.
Los siguientes son ejemplos de comentarios potencialmente riesgosos.
// doesn''t really authenticate, placeholder for when we implement it.
myServer.authenticate(user,pass);
o
// don''t forget to include the length,
//the server complains if it gets NaN or undefined.
function send_stuff(stuff, length) {
...
}
o
function doSomething() {
querystring = ""
//querystring = "?TRACING_MODE=true&"
...
//print_server_trace();
}
Otro ejemplo podría ser si incluye un encabezado histórico del código fuente, alguien podría encontrar alguna debilidad de seguridad al examinar los tipos de errores que se han solucionado. Al menos, un cracker podría ser capaz de atacar mejor sus ataques, si sabe qué vectores de ataque ya se han cerrado.
Ahora, todos estos ejemplos son malas prácticas de todos modos (tanto los comentarios como el código), y la mejor manera de evitarlo es tener revisiones de código y buenos programadores. El primer ejemplo es particularmente malo, pero las advertencias inocentes a sus compañeros de equipo, como el segundo ejemplo, o el código de depuración comentado, como el tercero, son los tipos de agujeros de seguridad que podrían deslizarse a través de la red.
Dependiendo de qué tan estricta sea la auditoría, la descarga de imágenes, etc. sin autenticación, PODRÍA ser vista como un riesgo de seguridad (piense en diagramas, tablas, gráficos ...).
Eliminar comentarios en el javascript es como ofuscar el código: lo hace un poco más difícil, pero aún así no es imposible entender lo que está pasando. JavaScript debe verse como solo mejora, de todos modos, toda su seguridad debe estar (duplicada) en el lado del servidor. Que alguien entienda lo que hace el JS no debe considerarse un riesgo .
Los comentarios de JavaScript pueden ser. depende de su lógica, pero ciertamente, como está disponible públicamente, le está dando más visibilidad al funcionamiento de su código.
También existen otras razones para eliminar esto, como el tamaño del archivo y, como resultado, el tamaño de la descarga.
Herramientas como, por ejemplo, JSMin pueden ayudarlo a eliminar los comentarios y realizar una ofuscación burda del código.
No si solo revelan cómo funciona el código. Cualquier persona suficientemente determinada podría descubrirlo de todos modos.
Dicho esto, probablemente sea una buena idea minimizar el JavaScript; no por seguridad, sino porque reducirá los tiempos de descarga y, por lo tanto, hará que su sitio sea un poco más receptivo.
Sin entrar en si son un riesgo de seguridad o no, minimice su JS en el entorno de producción, esto evitará la "fuga de información" y ayudará (de alguna manera al menos) a proteger la información de su sitio web.
con respecto al riesgo de seguridad, no creo que los comentarios de JS sean un riesgo en absoluto, todo el contenido del sitio web (estático) se puede descargar sin autenticación. (a menos que se defina lo contrario)