¿Qué prácticas de seguridad debo tener en cuenta durante el desarrollo? [cerrado]

1

Estoy empezando a desarrollar aplicaciones para Android e iOS que hacen llamadas a la API a una aplicación web PHP que estaré desarrollando. Los usuarios deberán registrarse con un nombre de usuario, contraseña y número de teléfono (opcional) y correo electrónico, y tengo la intención de mantener estos datos en una base de datos SQL. Los usuarios podrán registrarse desde las aplicaciones del teléfono, así como en el sitio web donde se aloja la API basada en PHP. Sé que muy a menudo los desarrolladores de aplicaciones no priorizan la seguridad y me gustaría asegurarme de que lo hago.

En cuanto a la seguridad del servidor web, ¿qué puedo hacer para asegurarme de que los datos de mis usuarios se mantengan seguros? Al desarrollar, ¿qué tipos de prácticas de seguridad debo implementar para mantener mi aplicación lo más segura posible? (por ejemplo, la eliminación de la entrada de nombre de usuario / contraseña para evitar la inyección de SQL, SSL para llamadas a API desde las aplicaciones al servidor web, no hacer llamadas a API con contraseñas de texto sin formato, etc.)

Sé que la pregunta es amplia, pero creo que cualquier respuesta representa la posibilidad de una mayor protección en la que no he pensado.

    
pregunta jstrieb 28.07.2015 - 21:44
fuente

1 respuesta

5

Desde la parte superior de mi cabeza:

  • la seguridad del servidor API, lo que significa que es posible que deba contratar un administrador de sistemas competente para que se encargue de ello si no tiene experiencia con la administración del sistema. Cualquier seguridad que implemente sobre eso (autenticación de API, etc.) se vuelve discutible si su servidor está comprometido. Tenga en cuenta que cada software instalado en él es una responsabilidad y solo instala lo que realmente necesitará, por ejemplo, no deje una instancia de PhpMyAdmin instalada en caso de que la necesite.
  • separe el servidor que aloja la API del que aloja su sitio web público; idealmente, su sitio web público puede verse comprometido sin ningún riesgo para los datos de la aplicación, ya que reside en una máquina separada.
  • huir de alojamiento compartido. Puede ser tentador inscribirse en un plan de alojamiento compartido (son muy baratos y no parecen requerir ningún tipo de mantenimiento) pero su seguridad es desastrosa (incluso más si están usando este cPanel mess como servidor de alojamiento) probablemente ya comprometido) y un exploit de ejecución de código en el sitio de otra persona puede aprovecharse para usar un exploit de kernel, obtener acceso de root y comprometer su API y sus datos.
  • endurece su pila web para no ejecutar archivos PHP arbitrarios: si está usando un marco (debería), el único archivo que debe ejecutarse es el punto de entrada del marco (generalmente index.php ), de esa manera, incluso si un archivo PHP falso de alguna manera encuentra su camino en su servidor, no se ejecutará y seguirá siendo un tanto seguro (asegúrese de verificar cómo llegó el archivo en primer lugar y si hay algún otro código). se produjo la ejecución). Lea mi respuesta algo relacionada de mi cuenta anterior.
  • por supuesto, asegúrese de manejar la entrada del usuario correctamente, las contraseñas hash correctamente y revise OWASP.
  • cada pieza de datos personales que recopile es una responsabilidad en caso de que su servidor se vea comprometido (es solo una cuestión de cuándo ). ¿Realmente necesita los números de teléfono del usuario? (El envío de mensajes SMS no deseados no es una respuesta correcta, y tampoco lo es la autenticación 2FA, ya que se puede hacer completamente fuera de línea utilizando TOTP / HOTP sin requerir números de teléfono)
  • refuerce la configuración TLS del servidor: permita solo los cifrados más fuertes que admita su mercado objetivo, por ejemplo, si apunta a dispositivos iOS7, permita solo los cifrados más fuertes compatibles con iOS7 y versiones posteriores. Si los objetivos de iOS8 hacen lo mismo pero solo permiten los que son compatibles con iOS8, ignore los cifrados más débiles, ya que no le importa si los dispositivos más antiguos no los admiten. Implemente el secreto hacia adelante si los cifrados que eligió lo permiten. Use su propia CA para firmar sus certificados de servidor de API e incruste ese certificado CA en su aplicación para evitar que cualquier otra CA se haga pasar por su servidor (¿recuerda DigiNotar?).
  • agregue algunos captchas fuertes y limitadores de velocidad para acciones repetidas para frustrar la fuerza bruta y los spammers.
  • evite incluir código analítico de terceros en su aplicación; no solo es una falta de respeto para el usuario (el hecho de abrir su aplicación no debería hacer ping al servidor de análisis de terceros, sin importar cómo seguro es) pero eso también puede obstaculizar la seguridad, ya que pueden tener vulnerabilidades o requisitos de seguridad más bajos (permitiendo cifrados TLS más débiles, etc.).
respondido por el Anonymous 28.07.2015 - 22:39
fuente

Lea otras preguntas en las etiquetas