고객 전략 이사. 수석 싱 과 공동 설립자.
야프 카란 싱
Jaap Karan Singh는 고객 전략 책임자이자 싱 수석 이사이며 Secure Code Warrior . 호주 BAE Systems에서 보안 테스트를 마친 Jaap은 웹 응용 프로그램을 해킹하는 것에서 개발자에게 자체 응용 프로그램을 보호하는 방법에 대한 교육으로 옮겼습니다. Jaap은 고객 성공, 갱신, 지원, Ops 및 고객 마케팅을 포함하는 전체 고객 전략을 설계하고 구현합니다.
시드니에 본사를 둔 Jaap은 소프트웨어 보안 개념에 대한 교육을 제공하고 전 세계 주요 금융 및 통신 조직에서 워크샵을 운영하고 있습니다. 그는 HTML5, 노드, 익스프레스 및 몽고와 같은 자바 스크립트 기술을 전문으로합니다.
야프 카란 싱은 보안 코딩 전도자, 수석 싱 및 공동 설립자입니다 Secure Code Warrior .
Cuando una aplicación web revela demasiada información, puede facilitar que los atacantes accedan a ella. En esta publicación, analizaremos qué es la exposición de la información, por qué es peligrosa y cómo evitarla.
La gran mayoría de los sitios web utilizan bases de datos XML para realizar funciones críticas, como almacenar las credenciales de inicio de sesión de los usuarios, la información de los clientes, la información de identidad personal y los datos confidenciales o sensibles, lo que deja a los ataques de XQuery con una huella de ataque bastante grande.
Los ataques de inyección de código se encuentran entre los más comunes, y también los más peligrosos, con los que se encontrarán muchos sitios web y aplicaciones. Abarcan toda la gama, tanto en términos de sofisticación como del peligro que representan, pero casi cualquier sitio o aplicación que acepte la entrada de los usuarios podría ser vulnerable.
A diferencia de muchas vulnerabilidades, la explotación de los procesos de inclusión de archivos locales y recorrido de rutas con fines nefastos requiere un atacante lo suficientemente hábil, una cantidad considerable de tiempo y quizás un poco de suerte.
Es común que los sitios web y las aplicaciones permitan a los usuarios enviar comentarios y otros datos a través de una aplicación mediante el correo electrónico. Y la mayoría de las personas ni siquiera piensan en ello en términos de un posible riesgo de seguridad.
Pueden producirse problemas cuando usuarios malintencionados pueden manipular una consulta LDAP. Esto puede engañar al servidor receptor para que ejecute consultas no válidas que normalmente no estarían permitidas, o incluso para que conceda acceso de administrador o de alto nivel a usuarios no válidos o de baja seguridad sin contraseña.
Los atacantes utilizan la inyección SQL, una de las más antiguas (¡desde 1998!) and the vulnerabilities of data more molestas que existen: robar y cambiar la información confidencial disponible en millones de bases de datos de todo el mundo.
En muchos sentidos, la vulnerabilidad de inclusión remota de archivos es mucho más peligrosa, y también más fácil de explotar, que su homóloga de archivos locales. Por lo tanto, debe detectarse y solucionarse lo antes posible.
Las sesiones son clave para una buena experiencia de usuario al usar la web. Sin embargo, la administración incorrecta de las sesiones puede generar brechas de seguridad que los atacantes pueden aprovechar.
La falta de registro y supervisión es una de las condiciones más peligrosas que pueden existir dentro de la estructura defensiva de una aplicación. Si existe esta vulnerabilidad o condición, casi todos los ataques avanzados que se lancen contra ella acabarán teniendo éxito.
La exposición de datos confidenciales se produce cuando la información que solo está destinada a la visualización autorizada se expone a una persona no autorizada en un estado no cifrado, desprotegido o con una protección débil.
Incluso si ha protegido completamente un servidor de aplicaciones y los sistemas de backend que utiliza, las comunicaciones podrían seguir siendo vulnerables a la intromisión si no cuenta con una protección de capa de transporte suficiente.
Cuando crea una aplicación empresarial, ya sea para uso interno o externo por parte de sus clientes, es probable que no permita que todos los usuarios realicen todas las funciones. Si lo hace, puede ser vulnerable a que se interrumpa el control de acceso.
Si bien los problemas de codificación pueden ser parte del problema, los errores de lógica empresarial suelen ser el resultado de defectos de diseño o suposiciones lógicas incorrectas cuando se crea una aplicación por primera vez.
Las secuencias de comandos entre sitios (XSS) utilizan 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. Veamos cómo funciona el XSS, qué daño puede causar y cómo evitarlo.
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 los usuarios como para la 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 salen a la luz más vulnerabilidades.
Una referencia directa a un objeto se produce cuando se hace referencia a un registro específico (el «objeto») dentro de una aplicación. Por lo general, adopta la forma de un identificador único y puede aparecer en una URL.
La deserialización insegura puede ocurrir cuando una aplicación considera que los datos que se están deserializando son confiables. Si un usuario puede modificar los datos recién reconstruidos, puede realizar todo tipo de actividades malintencionadas, como inyecciones de código, ataques de denegación de servicio o la elevación de sus privilegios.
Vamos a tratar uno de los problemas más comunes a los que se enfrentan las organizaciones que administran 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 hayas adivinado que vamos a hablar de la autenticación.
Los ataques de inyección de XML son pequeños exploits desagradables inventados por piratas informáticos para ayudarlos a comprometer los sistemas que alojan bases de datos XML. Esto incluye el tipo de cosas que se nos vienen a la mente cuando pensamos en las bases de datos tradicionales: almacenes detallados de información sobre cualquier tema, desde medicamentos hasta películas.
Al haber estado en ambos lados de la valla, sé muy bien la tensión que puede surgir entre el equipo de desarrollo y los especialistas de AppSec cuando se trata de mantener las mejores prácticas de seguridad. Sin embargo, existe un enfoque mejor.
Los ataques CSRF son bastante complejos y dependen de múltiples capas para tener éxito. En otras palabras, hay muchas cosas que tienen que fallar a favor del atacante para que funcione. A pesar de ello, 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, en ocasiones 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.
Si una aplicación no cuenta con suficientes controles antiautomatización, los atacantes pueden seguir adivinando las contraseñas hasta que encuentren una que coincida. A continuación, te explicamos cómo detenerlos.
En el ámbito de la ciberseguridad, los atacantes pueden aprovechar rápidamente cualquier aplicación o programa al que se haya permitido subir archivos sin restricciones. Y los resultados pueden ser devastadores.
Los ataques de inyección de comandos del sistema operativo pueden ser realizados por piratas informáticos principiantes y menos expertos, lo que los convierte en una de las debilidades más comunes a las que se enfrentan los equipos de seguridad. Afortunadamente, existen bastantes formas muy eficaces de evitar que tengan éxito.
Realmente sorprende que muchos lugares sigan confiando en las aulas, los libros de texto aburridos y la abrumadora formación en vídeo para sacar lo mejor de sí mismos a las nuevas iniciativas, especialmente cuando hay una forma de aprender mucho mejor, más atractiva y más valiosa: la formación contextual.
Como todas las aplicaciones usan componentes, la mayoría de los cuales no ha escrito, las vulnerabilidades dentro de los componentes que usa pueden convertirse en responsabilidades. Analicemos qué significa usar componentes con vulnerabilidades conocidas, qué tan peligroso es y cómo resolverlo.
Vea bajo demanda para obtener información sobre cómo capacitar a los administradores de AppSec para que se conviertan en facilitadores de la IA, en lugar de en bloqueadores, mediante un enfoque práctico que prioriza la capacitación. Le mostraremos cómo aprovechar Secure Code Warrior (SCW) para actualizar estratégicamente su estrategia de AppSec para la era de los asistentes de codificación basados en la IA.
.avif)