Como usuario de un sitio web o aplicación, a menos que tenga una copia del código fuente que pueda revisar en detalle, no hay forma de que sepa qué tan seguro (o inseguro) es el código.
Incluso si tenía el código fuente frente a usted, se necesita cierto conocimiento y experiencia en programación para saber si se han seguido o ignorado / descuidado las mejores prácticas de codificación segura. ¿El código está escrito de una manera para evitar desbordamientos del búfer (para evitar que fragmentos de código arbitrarios se inyecten en la memoria y luego se ejecuten)? ¿Se borran los datos confidenciales de la memoria tan pronto como ya no se necesitan? (Contraseñas, claves de cifrado / descifrado, texto sin formato). ¿Cómo se almacenan las contraseñas (para la autenticación del usuario en el sitio web o la aplicación) en la base de datos? En texto sin formato? (muy mal) ¿Como simples hashes? (un poco mejor, pero aún mal) ¿Como papitas saladas? (bueno) ¿Utiliza el sitio web o la aplicación solo protocolos cifrados para comunicarse con sistemas / recursos externos a través de la red? (Transport-Layer-Security (TLS) para cualquier tráfico de red que ingrese a nuestro sitio web o aplicación, o si no está disponible, entonces tal vez usando un túnel SSH).
Cada vez que utiliza un sitio web llamado “seguro” (uno accesible a través de una URL “https”), puede ser engañado fácilmente para creer que el sitio web está bien escrito de acuerdo con las mejores prácticas de seguridad porque su navegador web le muestra el icono de candado cerrado de color verde, que indica que es un sitio web “confiable”. Sin embargo, todo lo que realmente le dice es que el tráfico de red entre su navegador web y el servidor web está encriptado y no puede ser inmovilizado o secuestrado por un ataque “man-in-the-middle”. No dice absolutamente nada sobre cómo se manejan los datos detrás de escena en el servidor. No hay forma de que sepa si almacenan correctamente las contraseñas como hashes salados, o si utilizan conexiones TLS seguras a sistemas externos en lugar de simplemente enviar datos confidenciales por correo electrónico (números de tarjetas de crédito, información médica, etc.) de un lado a otro. las escenas. No hay forma de saber si es posible o no hackear el servidor web y obtener una sesión de shell raíz enviando datos de entrada inesperados / mal formados al servidor web, lo que hace que ejecute el código arbitrario de su elección.
- ¿Cuáles son los requisitos para un trabajo en el campo de la seguridad cibernética?
- ¿Cuál es la mejor historia sobre la guerra cibernética indio-paquistaní que has escuchado?
- Cómo cifrar código de software
- ¿Qué solución WAF es la mejor para detectar los ataques de aplicaciones web más rápido, aprender nuevas reglas de forma más dinámica y ofrece un mejor ROI?
- ¿Por qué el cifrado y descifrado GPG es bastante rápido?
La mayoría de las veces, las personas descubren que un sitio es realmente inseguro de la manera difícil, después de que los datos confidenciales para miles (o millones) de usuarios ya se han visto comprometidos, y es noticia en los titulares.
