¿Qué puedo hacer para aumentar la seguridad de una pequeña aplicación de código abierto [cerrado]

0

He estado desarrollando una pequeña aplicación CRUDish Ruby on Rails en mi tiempo libre para una organización sin fines de lucro. La aplicación ya se está ejecutando a pequeña escala en Heroku.

Últimamente he estado pensando en abrir la fuente de la aplicación. Hay muchas ventajas para esto, por ejemplo. Ya conozco un par de posibles contribuyentes, e incluso mi empleador ha mostrado interés en apoyar el proyecto de varias maneras si fuera de código abierto.

Normalmente, no dudaría en absoluto en este tipo de posibilidad, pero el problema aquí es que la aplicación almacena al menos información algo sensible sobre las personas que la usan. Me temo que, dado que el proyecto es pequeño y, después de todo, siempre tendrá una cantidad limitada de tiempo y recursos para el desarrollador, la fuente abierta atraerá a más piratas informáticos maliciosos que a los colaboradores reales. No quiero hacerle daño a nadie, y especialmente a los usuarios específicos de la aplicación, por lo que incluso el ligero aumento en la propensión a una fuga de datos me preocupa.

Cuando pienso con sensatez, entiendo que

  • Como la aplicación es muy pequeña, existe una posibilidad muy limitada de que alguien intente atacarla
  • RoR me brinda un entorno bastante bueno y probado en la vida real para construir sobre
  • La seguridad a través de la oscuridad se considera en su mayoría como algo sin sentido
  • Los profesionales de IMHO del abastecimiento abierto superponen las desventajas

No quiero que esto se convierta en otra discusión sobre Open Source vs Closed Sistemas fuente . Sin embargo, para aliviar mi mente, me gustaría saber qué puedo hacer de forma realista para minimizar la posibilidad de un ataque . Hasta ahora, al menos estas cosas se han preguntado en mi mente:

  • Use la última versión de Rails y aplique todos los arreglos de seguridad lo más rápido posible
  • Compre un certificado SSL y haga cumplir las conexiones HTTPS para que todos los datos que ingresen los usuarios se transfieran cifrados
  • Cifre los datos en la base de datos con una clave almacenada en las configuraciones de Heroku. Sin embargo, no estoy seguro de esto, porque después de todo, tengo que confiar en Heroku y, por lo que tengo entendido, esto solo ayudaría en los casos en que la base de datos real se vea comprometida. ¿O me equivoco aquí?
  • Pida a una empresa de seguridad que realice una auditoría de la aplicación de forma gratuita (ya que no hay $$ involucrado)

¿Qué más podría / debería hacer?

    
pregunta cido 14.04.2014 - 20:39
fuente

3 respuestas

1
  • Encripta la base de datos con una clave y solo almacena la clave en la memoria
  • Agregar encabezados de seguridad comunes. Puede ver qué usan otros sitios (por ejemplo, kraken.com) y usar los mismos encabezados HTTP después de leerlos (lista corta: HSTS, nosniff, protección XSS, XFO, CSP)
  • Prueba de XSS
  • Asegúrese de que la protección RoR XSRF funcione
  • Trate de encontrar una compañía pentest para hacer una revisión de seguridad gratuita. Muchas empresas lo hacen, por ejemplo cure53.de
respondido por el fel1x 24.07.2014 - 21:51
fuente
1

Busque el Top 10 de OWASP (que es el recurso más relevante para su pregunta) propuesto por edvinas.me y la lista de ataques orientados a la web cubiertos por fel1x.

No tengo un buen consejo para la seguridad del servidor web porque no lo he hecho en mucho tiempo, pero asegúrese de mantener sus servidores actualizados y que se ejecuten solo con los privilegios que necesitan (cuenta separada del sistema operativo, no el acceso de escritura fuera de sus propias carpetas temporales, y todos los demás servicios en su máquina deben tener una cuenta privada, / directorio tmp y así sucesivamente). Utilice conexiones encriptadas para todos los usuarios registrados en cualquier lugar de su sitio, y almacene las contraseñas correctamente.

Puedes mejorar la calidad de tu código asegurándote de que :

  1. Validación de entrada: usted verifica el dominio de todas las posibles entradas del usuario. Debe verificar la longitud, el tipo y la estructura, p. Ej. para cadenas que intenta analizar más adelante. ¡Tenga especial cuidado con las inyecciones de SQL y los ataques XSS! Consulte esta página para obtener algunos consejos. Asegúrese de utilizar consultas parametrizadas para su base de datos.

  2. Control de acceso: verifica que cada vez que se use algún tipo de información del usuario para acceder a los datos, haya enganches de control de acceso para verificar que estos datos están dentro del alcance de los privilegios del usuario . Mucho de esto se hace implícitamente (es decir, su usuario tiene una ID asociada con su sesión actual y esa ID se usa para recuperar entradas en una base de datos), por lo que no siempre es obvio ver qué podría salir mal. Piense en términos de cómo los usuarios pueden crear su entrada para acceder a diferentes ramas de datos / códigos, y cómo puede asegurarse de que esto no suceda.

  3. Búsqueda de errores: intenta activamente bloquear tu servidor mediante el uso de pruebas fuzz . Debería buscar fuzzers HTTP genéricos y realizar ambos fuzzing ingenuos (el fuzzer inyectará errores al azar en sus solicitudes) y fuzzing más estructurados (el fuzzer sabe qué paquetes deben aparecer en su aplicación y creará parámetros, por ejemplo, el tamaño anunciado de un paquete , algunos parámetros POST, etc.)

  4. Revisiones de código: realmente debería tener un pentesting de terceros, pero entiendo que no tiene el presupuesto para hacerlo. Puede pedir a los contribuyentes y usuarios potenciales que revisen secciones específicas del código y mantengan un registro de qué código aún no se ha revisado en su proyecto. Las personas que administran extensiones de Shell de GNOME pueden tener una buena experiencia de esto para compartir con ustedes. Tenga en cuenta que las revisiones no solucionarán las instalaciones incorrectas y los problemas del servidor, y probablemente no tendrán defectos de diseño, generalmente solo errores obvios ...

  5. Documentación: ya que está proporcionando una aplicación como software libre, describa cómo configurarla de manera segura en cierta documentación y distribúyala junto con sus fuentes. Sea abierto a las críticas y la ayuda de otros administradores de sistemas y desarrolladores que piensan que está haciendo algo mal o que no está dando el mejor consejo.

respondido por el Steve DL 23.08.2014 - 22:58
fuente
-2

Principalmente puede seguir las pautas de prueba de OWASP. Hay muchas compañías que ayudan a las pruebas de seguridad de código abierto. Uno de los ejemplos de SecureLayer7, pruebe el programa pentest de código abierto.

    
respondido por el user6289857 21.05.2016 - 11:59
fuente

Lea otras preguntas en las etiquetas