Jaap Karan Singh es Director de Estrategia de Clientes, Jefe Singh y cofundador de Secure Code Warrior. Tras realizar pruebas de seguridad en BAE Systems en Australia, Jaap pasó de hackear aplicaciones web a educar a los desarrolladores sobre cómo proteger sus propias aplicaciones. Jaap diseña e implementa toda la estrategia de clientes que incluye el éxito de los clientes, las renovaciones, el soporte, las operaciones y el marketing de clientes.
Con sede en Sídney, Jaap ha impartido formación sobre conceptos de seguridad del software y ha dirigido talleres en importantes organizaciones financieras y de telecomunicaciones de todo el mundo. Está especializado en tecnologías Javascript como HTML5, Node, Express y Mongo.
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Cuando tu aplicación web revela demasiada información, puede facilitar que los atacantes entren en ella. jEn este post, cubriremos qué es la exposición de información, por qué es peligrosa y cómo prevenirla.
La gran mayoría de los sitios web utilizan bases de datos XML para realizar funciones críticas, como mantener las credenciales de acceso de los usuarios, la información de los clientes, la información de identidad personal y los datos confidenciales o sensibles, lo que hace que los ataques XQuery tengan una huella de ataque bastante grande.
Los ataques de inyección de código están entre los más comunes, y también los más peligrosos, que muchos sitios web y aplicaciones encontrarán. Hay una gran variedad de ataques, tanto en términos de sofisticación como en el peligro que representan, pero casi cualquier sitio o aplicación que acepte entradas de usuario puede ser vulnerable.
A diferencia de muchas vulnerabilidades, la explotación de los procesos de inclusión de archivos locales y de cruce de rutas con fines nefastos requiere un atacante suficientemente hábil, una buena cantidad de tiempo y quizás un poco de suerte.
Es habitual que los sitios web y las aplicaciones permitan a los usuarios enviar comentarios y otras informaciones diversas a través de una aplicación utilizando el correo electrónico. Y la mayoría de la gente ni siquiera piensa en ello en términos de un potencial riesgo de seguridad.
Pueden surgir problemas cuando usuarios maliciosos pueden manipular una consulta LDAP. Hacer esto puede engañar al servidor receptor para que ejecute consultas no válidas que normalmente no estarían permitidas, o incluso conceder acceso de alto nivel o de administrador a usuarios no válidos o de baja seguridad sin contraseña.
Los atacantes están utilizando la inyección SQL - una de las vulnerabilidades de datos más antiguas (¡desde 1998!) y más molestas que existen- para robar y cambiar la información sensible disponible en millones de bases de datos de todo el mundo.
En muchos sentidos, la vulnerabilidad de inclusión de archivos remotos es mucho más peligrosa, y también más fácil de explotar, que su contraparte de archivos locales. Como tal, debe ser encontrada y remediada tan pronto como sea posible.
Las sesiones son la clave para una buena experiencia de usuario cuando se utiliza la web. Sin embargo, gestionar las sesiones de forma incorrecta puede dar lugar a agujeros de seguridad que los atacantes pueden explotar.
La insuficiencia de registro y monitoreo es una de las condiciones más peligrosas que pueden existir dentro de la estructura defensiva de una aplicación. Si esta vulnerabilidad o condición existe, entonces casi cualquier ataque avanzado realizado contra ella será eventualmente exitoso.
La exposición de datos sensibles se produce cuando la información que sólo está destinada a ser vista por personas autorizadas queda expuesta a una persona no autorizada en un estado no cifrado, no protegido o débilmente protegido.
Incluso si ha asegurado completamente un servidor de aplicaciones y los sistemas de backend que utiliza, las comunicaciones podrían seguir siendo vulnerables al espionaje si no tiene suficiente protección de la capa de transporte.
Cuando construyes una aplicación empresarial, ya sea para uso interno o externo por parte de tus clientes, probablemente no permites que cada usuario realice todas las funciones. Si lo hace, puede ser vulnerable a un control de acceso roto.
Aunque los problemas de codificación pueden ser parte del problema, los errores de lógica de negocio son, con mayor frecuencia, el resultado de defectos de diseño o de suposiciones lógicas incorrectas cuando se crea una aplicación por primera vez.
El cross-site scripting (XSS) utiliza la confianza de los navegadores y la ignorancia de los usuarios para robar datos, apoderarse de cuentas y desfigurar sitios web; es una vulnerabilidad que puede ponerse muy fea, muy rápidamente. Echemos un vistazo a cómo funciona el XSS, qué daño puede causar y cómo prevenirlo.
Codificar un sitio web o una aplicación con la capacidad de procesar redireccionamientos y reenvíos no validados puede ser extremadamente peligroso tanto para sus usuarios como para su organización.
Las bases de datos NoSQL son cada vez más populares. Es difícil negar su rapidez y facilidad para tratar datos no estructurados, pero a medida que su uso se generaliza, inevitablemente afloran más vulnerabilidades.
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
La deserialización insegura puede ocurrir cuando una aplicación trata los datos que se están deserializando como de confianza. Si un usuario es capaz de modificar los datos recién reconstruidos, puede realizar todo tipo de actividades maliciosas como inyecciones de código, ataques de denegación de servicio o elevar sus privilegios.
Vamos a tratar uno de los problemas más comunes a los que se enfrentan las organizaciones que gestionan sitios web, o que permiten a los empleados acceder de forma remota a los recursos informáticos - que es prácticamente todo el mundo. Y sí, probablemente has adivinado que vamos a hablar de la autenticación.
Los ataques de inyección XML son pequeños y desagradables exploits inventados por los hackers para ayudarles a comprometer los sistemas que alojan bases de datos XML. Esto incluye el tipo de cosas que vienen a la mente cuando uno piensa en las bases de datos tradicionales: almacenes detallados de información sobre cualquier cosa, desde medicamentos hasta películas.
Habiendo estado en ambos lados de la valla, conozco muy bien la tensión que puede surgir entre el equipo de desarrollo y los especialistas en seguridad de las aplicaciones cuando se trata de mantener las mejores prácticas de seguridad. Sin embargo, hay un enfoque mejor.
Los ataques CSRF son bastante complejos y dependen de múltiples capas para tener éxito. En otras palabras, muchas cosas tienen que romperse a favor del atacante para que funcione. A pesar de esto, son un vector de ataque extremadamente popular y lucrativo.
Si un atacante puede insertar un código CR o LF en una aplicación existente, a veces puede cambiar su comportamiento. Los efectos son menos fáciles de predecir en comparación con la mayoría de los ataques, pero no pueden ser menos peligrosos para la organización objetivo.
En el ámbito de la ciberseguridad, los atacantes se apresuran a explotar cualquier aplicación o programa al que se le haya permitido cargar archivos sin restricciones. Y los resultados pueden ser devastadores.
Los ataques de inyección de comandos en el sistema operativo pueden ser realizados por hackers de nivel básico y menos cualificados, lo que los convierte en una de las debilidades más comunes que experimentan los equipos de seguridad. Por suerte, hay bastantes formas muy eficaces de evitar que tengan éxito.
Resulta verdaderamente sorprendente que muchos lugares sigan confiando en las aulas, los libros de texto áridos y los vídeos de formación aburridos para conseguir que los mejores y más brillantes se incorporen a las nuevas iniciativas, especialmente cuando hay una forma mucho mejor, más atractiva y más valiosa de aprender: la formación contextual.
Dado que todas las aplicaciones utilizan componentes, la mayoría de los cuales no has escrito, las vulnerabilidades dentro de los componentes que utilizas pueden convertirse en pasivos. Vamos a discutir lo que significa el uso de componentes con vulnerabilidades conocidas, lo peligroso que es, y cómo resolverlo.
