¿Cómo validar si una biblioteca de JavaScript es segura?

Question

¿Cómo validar si una biblioteca de JavaScript es segura?

#1 de D.W. (18 votos)
#2 de Rory Alsop (5 votos)
#3 de ddyer (1 votos)
#4 de Nick P (1 votos)
#5 de Doran (1 votos)
#6 de Not a machine (-1 votos)

16

Soy el desarrollador principal de una biblioteca de código abierto de JavaScript. Esa biblioteca se utiliza en la empresa para la que trabajo, para varios clientes. De vez en cuando hay un cliente que se siente paranoico con respecto a la implementación de una biblioteca de la que nunca ha oído hablar y me pregunta por qué debería confiar en este código.

Entiendo la preocupación y generalmente los apunto a un repositorio de github donde se encuentra la biblioteca y muestro otros proyectos y clientes que están usando la misma biblioteca. A veces revisan el código en github, y todo funciona sin problemas después de eso.

Pero esta vez el cliente es un poco más paranoico. Me preguntó qué tipo de verificación de seguridad ha tenido la biblioteca y me dijo que sus sistemas están "validados con los 10 mejores controles / exploraciones de OWASP".

Después de algunas investigaciones, lo más cercano que encontré es este documento que enumera las 10 principales vulnerabilidades en aplicaciones web en 2010, por OWASP .

Creo que no se aplican todos estos, ya que no estoy proporcionando una aplicación web, sino solo una biblioteca de JavaScript. Y tengo entendido que la mayoría de las veces, estas vulnerabilidades deben ser revisadas manualmente por un especialista en seguridad en lugar de un análisis automatizado.

Ahora a mis preguntas:

¿Hay alguna forma en que pueda hacer valer los estándares de seguridad en una biblioteca de JavaScript?
¿Existe alguna herramienta que pueda escanear JavaScript en busca de amenazas de seguridad?

ACTUALIZACIÓN 1

Aunque no soy un experto en seguridad, soy un desarrollador web y entiendo las fallas comunes que pueden causar vulnerabilidades en las aplicaciones web. Lo que necesito es alguna forma de probar especialmente para una persona no técnica que esta biblioteca ha sido revisada al menos para detectar amenazas y vulnerabilidades mínimas y, de hecho, es segura para ser utilizada en su sitio web.

Lo que me viene a la mente es tal vez una compañía neutral o un consultor especializado en seguridad web que puede revisar el código y certificar su calidad. ¿Es esta una práctica común?

ACTUALIZACIÓN 2

Imagina que alguien te entrega un archivo javascript grande para incluirlo en tu sitio como parte de una integración. Ese script se ejecutará dentro de su sitio y. Probablemente quiera asegurarse de dónde viene ese archivo y quién fue el desarrollador que lo creó. Imagine que algún desarrollador malintencionado en Facebook decidió inyectar un código malicioso dentro del script del botón "Me gusta" para robar datos o cookies de los sitios donde se ejecuta.

Cuando se incluyen bibliotecas de empresas bien conocidas o proyectos de código abierto que son revisados por varias personas (como jQuery), este es un caso muy poco probable. Pero cuando incluyes un script de una pequeña empresa o un desarrollador en solitario, puedo verlo como una preocupación.

No quiero buscar exploits en mi biblioteca porque sé que no he incluido ninguno. Solo quiero demostrar de alguna manera que el código es seguro, por lo que los usuarios no tienen este tipo de preocupación cuando lo usan.

javascript vulnerability-scanners

pregunta Eduardo Cereto 26.10.2012 - 03:02

fuente

6 respuestas

5

La práctica estándar es que su cliente realice una prueba de seguridad, pero estoy viendo que más desarrolladores contratan evaluadores de seguridad para brindar cierta seguridad al cliente.

Pero no hay manera de decir "este código está garantizado de forma segura", solo hay "este código parece ser lo más seguro posible" o "se ajusta a su propósito"

respondido por el Rory Alsop 26.10.2012 - 09:12

fuente

1

Creo que lo que quieres es fundamentalmente imposible: decir que un programa hace o no hace algo malicioso (no especificado) es equivalente al problema de la detención. Especialmente considere que javascript es parte de un complejo ecosistema de software que interactúa. Los exploits no son necesariamente tan simples como escribir una función llamada steal_cookies_and_send_to_bad_guys.

Entonces, como es imposible, lo mejor que puede hacer es hacer que el código sea inspeccionado por alguien que debería ser capaz de detectar algunas "especies conocidas" de malware, y tal vez formen una opinión de que, de lo contrario, está por encima del tablero y está bien escrito.

respondido por el ddyer 26.10.2012 - 09:20

fuente

1

Una opción es sandboxing o reescribir el javascript. Aquí hay algunas cosas en esa dirección.

enlace

Google JSand Sandboxing del lado del cliente de javascript

Aislamiento basado en el idioma de Google de javascript no confiable por maffeis

respondido por el Nick P 04.06.2013 - 04:36

fuente

1

La mayoría de los escáneres de códigos comerciales (IBM, HP Fortify, Checkmarx, Veracode, etc.) analizan JavaScript. Personalmente, solo he usado Checkmarx y funciona bien, pero no he hecho ninguna comparación.

respondido por el Doran 22.07.2013 - 09:49

fuente

-1

@ edwardo-cereto He utilizado varias aplicaciones, incluida Appscan Source, que proporciona una cobertura de código JavaScript muy profunda. Desafortunadamente, la mayoría de las aplicaciones para JavaScript son comerciales. La sugerencia jslint es buena. Puede que no cubra el filtrado de entradas de usuarios y más casos de uso específicos de aplicaciones web, pero es un buen comienzo.

Miré a Ratproxy hace un tiempo, pero aún era una aplicación madura y no fue útil para lo que estaba buscando.

respondido por el Not a machine 20.03.2017 - 19:45

fuente

Lea otras preguntas en las etiquetas javascript vulnerability-scanners

Criterios para evaluar herramientas de análisis estático ¿ECDSA es rompible por las computadoras cuánticas?

score 18 · Accepted Answer

Para evitar problemas de seguridad del lado del cliente, debe conocer los requisitos de seguridad para el código del lado del cliente y los errores comunes. OWASP tiene buenos recursos. Asegúrese de leer sobre XSS basado en DOM, ya que es uno de los errores de seguridad más comunes.

En cuanto a las mejores prácticas de seguridad, tengo varias sugerencias:

Para evitar XSS, respete las reglas que se encuentran en Adam Barth en Tres reglas simples para construir XSS- aplicaciones web gratuitas .
Evita setInnerHtml() y .innerHtml = . En su lugar, use setInnerText() o las operaciones basadas en DOM (para asegurarse de no introducir etiquetas de script, es decir, para evitar XSS basado en DOM). Evita document.write() .
Evita eval() . Su uso tiende a estar correlacionado con fallas de seguridad. De manera similar, evite otras API que convierten una cadena en código y ejecútela, como setTimeout() con un argumento de cadena, setInterval() con un argumento de cadena, o new Function() .
Activar Javascript "modo estricto" . Ayuda a evitar algunas áreas sutiles de Javascript que han sido responsables de problemas de seguridad anteriormente.
Asegúrese de que su código sea compatible con una estricta Política de seguridad de contenido (aquí hay un tutorial ), como script-src 'self'; object-src 'self' .

Consulte también Preocupaciones de seguridad en el lado del cliente (Javascript) , que trata sobre un tema relacionado.

No conozco ninguna herramienta de análisis estático para escanear Javascript y buscar problemas de seguridad.

Si sigue las recomendaciones de Doug Crockford sobre cómo usar Javascript (por ejemplo, según su libro, Javascript: The Good Parts), puede usar JSLint . Es una herramienta de pelusa bastante agresiva. Si su código es JSLint-clean, eso es una marca positiva. Pero JSLint no se centra principalmente en la seguridad. Y, si toma el código heredado y ejecuta JSLint en él, probablemente se verá inundado con un montón de advertencias.