Awesome Application Security Checklist

Lista de comprobación de seguridad de la aplicación impresionante

Si está diseñando, creando, probando su aplicación web/móvil con seguridad en mente, esta lista de verificación de contramedidas puede ser un buen punto de partida

Sistemas de autenticación (registrar/firmar/2 factor/restablecer la contraseña)

• Use https en todas partes.
• Almacene los hash de contraseña usando Bcrypt (no se necesita sal - Bcrypt lo hace por usted).
• Destruye el identificador de la sesión después logout .
• Destruya todas las sesiones activas en la contraseña de restablecimiento (u ofrece).
• Debe tener el parámetro state en OAuth2.
• No hay redireccionamientos abiertos después de un inicio de sesión exitoso o en cualquier otra redirección intermedia.
• Al analizar la entrada de registro/inicio de sesión, desinfectar para JavaScript: //, Data: //, CRLF caracteres.
• Establezca cookies seguras y httponly.
• En la verificación móvil basada en OTP móvil, no envíe el OTP nuevamente en la respuesta cuando se llama generate OTP o Resend OTP .
• Límite de los intentos de Login , Verify OTP , Resend OTP y generate OTP para un usuario en particular. Tenga un conjunto exponencial de retroceso o/y algo como un desafío basado en Captcha.
• Verifique la aleatoriedad de restablecer el token de contraseña en el enlace correo electrónico o SMS.
• Establezca un vencimiento en el token de contraseña de reinicio por un período razonable.
• Expire el token de reinicio después de que se haya utilizado con éxito.

Datos de usuario y autorización

• Cualquier acceso de recursos como my cart , my history debe verificar la propiedad del usuario del usuario utilizando la identificación de la sesión.
• Se debe evitar en serie la identificación de recursos en serie. Use /me/orders en lugar de /user/37153/orders . Esto actúa como una verificación de cordura en el caso de que haya olvidado verificar el token de autorización.
• Edit email/phone number debe ir acompañada de un correo electrónico de verificación al propietario de la cuenta.
• Cualquier función de carga debe desinfectar el nombre de archivo proporcionado por el usuario. Además, por razones generalmente aparte de la seguridad, cargue a algo como S3 (y el procesamiento posterior con Lambda) y no su propio servidor capaz de ejecutar código.
• La función Profile photo upload debe desinfectar todas las etiquetas EXIF ​​también si no es necesario.
• Para ID de usuario y otras ID, use UUID de RFC en lugar de enteros. Puede encontrar una implementación para esto para su idioma en GitHub.
• JWT son increíbles. Úselos si es necesario para su aplicación/API de una sola página.

Base de datos

• Use el cifrado para datos que identifican a los usuarios y datos confidenciales, como tokens de acceso, direcciones de correo electrónico o detalles de facturación.
• Si su base de datos admite el cifrado de bajo costo en reposo (como AWS Aurora), habilite que asegure datos en el disco. Asegúrese de que todas las copias de seguridad también estén encriptadas.
• Utilice un privilegio mínimo para la cuenta de usuario de acceso a la base de datos. No use la cuenta raíz de la base de datos.
• Almacene y distribuya secretos utilizando una tienda clave diseñada para el propósito. No codifique en sus aplicaciones.
• Evite completamente la inyección de SQL solo usando declaraciones preparadas SQL. Por ejemplo: si usa NPM, no use NPM-MYSQL, use NPM-Mysql2 que admite declaraciones preparadas.

Aplicación Android / iOS

• salt de las pasarelas de pago no debe estar codificada.
• secret / auth token de terceros SDK no debe ser codificado.
• Las llamadas de API destinadas a realizar server to server no se deben realizar desde la aplicación.
• En Android, todos los permisos otorgados deben evaluarse cuidadosamente.
• En iOS, almacene información confidencial (tokens de autenticación, claves API, etc.) en el llavero del sistema. No almacene este tipo de información en los valores predeterminados del usuario.
• La fijación del certificado es muy recomendable.

Encabezados y configuraciones de seguridad

• Add el encabezado CSP para mitigar XSS y ataques de inyección de datos. Esto es importante.
• Add el encabezado CSRF para evitar la falsificación de solicitud de sitio cruzado. También agregue los atributos de samesite en las cookies.
• Add el encabezado HSTS para evitar el ataque de despojo de SSL.
• Add su dominio a la lista de precarga de HSTS
• Add las opciones X-Frame para proteger contra Clickjacking.
• Add el encabezado X-XSS-Protection para mitigar los ataques XSS.
• Actualice los registros de DNS para agregar el registro SPF para mitigar los ataques de spam y phishing.
• Agregue las verificaciones de integridad de Subresource si carga sus bibliotecas JavaScript desde un CDN de terceros. Para obtener seguridad adicional, agregue el requerimiento-SRI-por CSP-Directive para que no cargue recursos que no tengan un SRI SAT.
• Use tokens CSRF aleatorios y exponga las API de lógica comercial como solicitudes de publicación HTTP. No exponga los tokens CSRF sobre HTTP, por ejemplo, en una fase de actualización de solicitud inicial.
• No use datos o tokens críticos en los parámetros de solicitud GET. La exposición de los registros del servidor o un procesamiento de máquina/pila los expondrían los datos del usuario a su vez.

Desinfectación de la entrada

• Sanitize todas las entradas del usuario o cualquier parámetros de entrada expuestos al usuario para evitar XSS.
• Siempre use consultas parametrizadas para evitar la inyección de SQL.
• Desinfecta la entrada del usuario si la usa directamente para funcionalidades como la importación CSV.
• Sanitize la entrada del usuario para casos especiales como robots.txt como nombres de perfil en caso de que esté utilizando un patrón de URL como CoolCorp.io/Username.
• No entregue el código ni construya json por la concatenación de cadena, sin importar cuán pequeño sea el objeto. Use sus bibliotecas o marco definidos por el idioma.
• Desinfecta las entradas que toman algún tipo de URL para evitar SSRF.
• Desinfectación de salidas antes de mostrar a los usuarios.

Negación de protección de servicio

• Asegúrese de que los ataques de DOS en sus API no paralen su sitio. Como mínimo, tenga limitadores de velocidad en sus rutas de API más lentas como las rutinas de inicio de sesión y generación de tokens. Considere Captcha en API front-end para proteger los servicios de fondo contra DOS.
• Haga cumplir los límites de cordura en el tamaño y la estructura de los datos y solicitudes enviados por el usuario.
• Utilice la mitigación de la denegación de servicio distribuido (DDoS) a través de un servicio de proxy de almacenamiento en caché global como CloudFlare. Esto se puede activar si sufre un ataque DDoS y de lo contrario funciona como su búsqueda DNS.

Operaciones

• Si es pequeño e inexperto, evalúe el uso de AWS ElasticBeanStalk o un PaaS para ejecutar su código.
• Use un script de aprovisionamiento decente para crear máquinas virtuales en la nube.
• Consulte las máquinas con open ports públicamente no deseados.
• Verifique las contraseñas no/predeterminadas para databases , especialmente MongoDB & Redis.
• Use SSH para acceder a sus máquinas; No configure una contraseña, use la autenticación basada en la tecla SSH en su lugar.
• Instale actualizaciones oportunas para actuar sobre vulnerabilidades de cero días como Heartbleed, Shellshock.
• Modifique la configuración del servidor para usar TLS 1.2 para HTTPS y deshabilite todos los demás esquemas. (La compensación es buena).
• No deje el modo de depuración encendido. En algunos marcos, el modo de depuración puede dar acceso a reples o caparazones completos o exponer datos críticos en las pilas de mensajes de error.
• Esté preparado para los malos actores y DDoS: use un servicio de alojamiento que tenga mitigación DDOS.
• Configure el monitoreo de sus sistemas y registre cosas (use una nueva reliquia o algo así).
• Si se desarrolla para clientes empresariales, adhiera los requisitos de cumplimiento. Si AWS S3, considere usar la función para cifrar datos. Si usa AWS EC2, considere usar la función para usar volúmenes cifrados (incluso los volúmenes de arranque se pueden encriptar ahora).

Configuración de nube

• Asegúrese de que todos los servicios tengan puertos mínimos abiertos. Si bien la seguridad a través de la oscuridad no es protección, el uso de puertos no estándar lo hará un poco más difícil para los atacantes.
• Host Backend Datab Base and Services en VPC privados que no son visibles en ninguna red pública. Tenga mucho cuidado al configurar grupos de seguridad de AWS y ver a los VPC que pueden hacer que los servicios sin darse cuenta sean visibles para el público.
• Aislar los servicios lógicos en VPC y VPC de pares separados para proporcionar comunicación entre servicios.
• Asegúrese de que todos los servicios solo acepten datos de un conjunto mínimo de direcciones IP.
• Restringir el tráfico saliente de IP y puerto para minimizar APT y "botificación".
• Siempre use los roles AWS IAM y no las credenciales raíz.
• Utilice un privilegio de acceso mínimo para todos los OP y el personal de desarrolladores.
• Gire regularmente las contraseñas y las claves de acceso de acuerdo con un horario.

CI y CD Auditar su diseño e implementación con cobertura de pruebas de unidad/integración. Use un proceso de revisión de código y no tenga en cuenta la auto-aprobación. Asegúrese de que todos los componentes de sus servicios sean escaneados estáticamente por AV Software antes de presionar a la producción, incluidas las bibliotecas de proveedores y otras dependencias. Diseñe una solución de reversión para implementaciones.

GENTE

• Configure un correo electrónico (por ejemplo, [email protected]) y una página para que los investigadores de seguridad informen vulnerabilidades.
• Dependiendo de lo que esté haciendo, limite el acceso a sus bases de datos de usuario.
• Sea educado con los reporteros de errores.
• Haga que su revisión de código sea realizada por un compañero desarrollador desde una perspectiva de codificación segura. (Más ojos)
• En el caso de un hack o violación de datos, verifique los registros anteriores para el acceso a los datos, solicite a las personas que cambien contraseñas. Puede necesitar una auditoría de agencias externas dependiendo de dónde se incorpore.

Infraestructura

• Asegúrese de que pueda realizar actualizaciones sin tiempo de inactividad. Asegúrese de actualizar rápidamente el software de manera totalmente automatizada.
• Cree toda la infraestructura utilizando una herramienta como Terraform, y no a través de la consola de la nube. La infraestructura debe definirse como "código" y poder recrearse al presionar un botón. Tener tolerancia cero para cualquier recurso creado en la nube a mano: Terraform puede auditar su configuración.
• Use el registro centralizado para todos los servicios. Nunca debe necesitar SSH para acceder o recuperar registros.
• No se sienta en los servicios, excepto por el diagnóstico único. Usando SSH regularmente, generalmente significa que no ha automatizado una tarea importante.
• No mantenga el puerto 22 abierto en ningún grupo de servicio de AWS de forma permanente. En su lugar, considere permitir que solo las IP autorizadas se ssh en la caja.
• Cree hosts inmutables en lugar de servidores de larga vida que parche y actualices. (Ver infraestructura inmutable puede ser más segura).
• Use un sistema de detección de intrusos como SensedEP o Service para minimizar los APT.