Un nuevo sitio web dinámico que genera ingresos está apareciendo en Internet cada 1 minuto. ¿Sabes cuántas líneas de código escritas en un día? ¡Más de 500 millones de líneas de código! Si verdad. Millones de líneas de código de seguridad de aplicaciones web se escriben todos los días en todo el mundo.
¿Con qué seguridad está codificando su equipo entonces? Esta es la cosa más importante. ¿Su equipo conoce las mejores prácticas simples a seguir para asegurar su aplicación web? Aquí hay una lista de verificación que puede ayudar a su equipo a crear aplicaciones sólidas y seguras.
Suscríbase a nuestra lista de correo para comprender más sobre las mejores prácticas.
- ¿Cuál es el concepto de cifrado / descifrado de clave privada y clave pública?
- Si uso la misma clave gpg para el trabajo y la personal, ¿puede mi trabajo obligarme a renunciar a la clave privada?
- ¿Por qué IdenTrust cruzó el certificado raíz de Let's Encrypt? ¿Esto no mata sus negocios?
- ¿Puedo seguir aprendiendo piratería ética con conocimientos básicos / sin programación?
- ¿Cómo dice el captcha que es solo una casilla de verificación si eres humano?
- Desinfecte las entradas tanto en el lado del cliente como en el lado del servidor. No debe permitir caracteres especiales, caracteres nulos y guiones divertidos. Este paso debería evitar que los atacantes utilicen XSS y varias inyecciones como SQL, etc. No puede simplemente desinfectar al cliente y pensar que está protegido. Cualquiera siempre podría desactivar JavaScript o cambiar los valores y enviarlos a su servidor. Utilice Escape Contextual Estricto (SCE), la mayoría de los Javascripts en estos días lo ayudan con este escape. Esto ayuda a evitar los principales ataques XSS y SQL.
- Siempre codifique la solicitud / respuestas. Especialmente, la respuesta que se envía desde el servidor al cliente debe estar codificada, de modo que el navegador no la ejecute si es una carga útil. Esto evitará XSS y otros ataques basados en secuencias de comandos.
- Utilice siempre HTTPS para todas las entradas de dominio. La entrada del dominio en la url debe considerarse y redirigirse correctamente, es decir, el usuario puede intentar de cualquiera de las siguientes maneras: Ingresar la url en cualquiera de las formas mencionadas anteriormente debe redirigirse a https: //www.example.comhttp: // ww …
- No utilice algoritmos de cifrado y hashing obsoletos como MD4, MD5, SHA1, DES.
- Configure el servidor web para no permitir el listado de directorios.
- No almacene datos confidenciales como nombres de usuario y contraseñas dentro de las cookies. Nunca use nombres predeterminados para sesiones como PHPSESSID, ASP.NET_SessionId, etc., sino que use nombres personalizados.
- Verifique la aleatoriedad de la sesión y asegúrese de que caduque después de cerrar sesión y en uso inactivo. Las sesiones caducadas ya no deberían ser útiles para futuras transacciones de cliente a servidor.
- Siempre configure banderas seguras y HttpOnly en las cookies.
- Utiliza TLS. No use SSL. Simplemente deshabilite SSL en el servidor y siempre use TLS 1.2 para los certificados.
- Establezca siempre una política de contraseña segura y también implemente medidas de seguridad como captcha para mitigar los ataques de fuerza bruta. La aleatoriedad con la que genera la contraseña predeterminada y el contenido relacionado con el usuario debe ser absolutamente aleatorio.
- Los campos ocultos del formulario no deben contener información confidencial. Asegúrese de que no se recopile información confidencial a través de campos ocultos.
- La funcionalidad de carga de archivos debe verificarse correctamente, no solo en el lado del cliente sino también en el lado del servidor porque la verificación del lado del cliente por sí sola no es suficiente. El atacante puede interceptar el tráfico y cambiar el tipo de archivo o el contenido. Verifique las extensiones y el tamaño del archivo correctamente. No acepte archivos zip / pdf protegidos con contraseña. Ponga un captcha en cada página de carga de archivos.
- Utilice los siguientes encabezados de respuesta en cada respuesta: seguridad-transporte-estricta: max-age = 7776000x-content-type-options: nosniffx-frame-options: SAMEORIGIN x-xss-protection: 1; modo = bloque
- Asegúrese de que las bibliotecas o complementos de terceros que se utilizan dentro de la aplicación estén libres de vulnerabilidades notadas. Para obtener información sobre los CVE existentes, visite https://cve.mitre.org/.
- No se recomienda mostrar la información del servidor web en los encabezados de respuesta.
Para más detalles: ¿Ha realizado esta lista de verificación de seguridad simple de 15 puntos para su aplicación web?
La mejor metodología para la seguridad de aplicaciones web: estudio de caso de logística
