WebGoat el servidor tipo HoneyPot pero con fines educativos resulta bastante útil para real-mente entender cómo funcionan los ataques en la web. Para esta práctica, la cual inicialmente me había centrado en la Lección “Injection Flaws”, se me complicaron un par de ejercicios, le que me obligo a ver los videos en dos ocaciones, por esa razón opte por realizar algunas lec-ciones más.

1. Por: Héctor Garduño Real
Máster en Dirección e Ingeniería de Sitios Web
Seguridad en la web
03 de mayo de 2015 Página 1 de 6
Práctica con WebGoat: HTTP Splitting, DoS, Mali-
cious Execution e Injection Flaws
Introducción
WebGoat el servidor tipo HoneyPot pero con fines educativos resulta bastante útil para realmente
entender cómo funcionan los ataques en la web. Para esta práctica, la cual inicialmente me había
centrado en la Lección “Injection Flaws”, se me complicaron un par de ejercicios, le que me obligo a
ver los videos en dos ocaciones, por esa razón opte por realizar algunas lecciones más. A continuación
detallo cada una de ellas.
1. HTTP Splitting
Para resolver esta “simple”
lección de la cual no conocía,
comencé a investigar qué eran
los caracteres %0d y %0a, y
pronto di que tienen relación
con las cabeceras HTTP (de
ahí su nombre), ya que cada lí-
nea o mensaje de la cabecera
HTTP se separa con /r/n, es
decir, es el delimitador para
indicar una nueva línea, de-
pendiendo la codifica-
ción/lenguaje a usar serán
como se tendrán que escribir
el retorno y salto de línea, que
para este caso es %0d y %0a respectivamente. Al hacer esto en una web, uno de los posibles ataques
que se pueden hacer es se forzá al navegador a entregar solo una parte del mensaje (split o separar),
con ello el servidor solo responderá con un mensaje 200, que significa que la petición del cliente fue
correcta. Así pues, para resolver éste ejercicio solo bastó con escribir %0d%0a%0d%0a<h1>hec-
tor</h1>.
Esta es solo es una prueba básica, pero las posibilidades van más allá, y es posible realizar diversos
tipos de ataques al sobrescribir las cabeceras. Con el ejercicio de la práctica aparentemente no hay
problema en ello, sin embargo si un atacante lo hace en una red donde hay un proxy y además sobres-
cribe la cabecera para cargar un script malicioso, lo que sucederá es que el proxy cacheará la página
para luego producir un ataque de “cache poising” el cual haría que el resto de los usuarios que solici-
tarán dicha página, el proxy al tenerla en caché la entregaría, con lo cual los usuarios cargarían un
script malicioso.

2. Por: Héctor Garduño Real
Máster en Dirección e Ingeniería de Sitios Web
Seguridad en la web
03 de mayo de 2015 Página 2 de 6
La siguiente fase de esta práctica
pide hacer el splitting, es decir, se-
parar con los caracteres /r/n para
escribir una nueva cabecera mani-
pulada, en este caso se resolvió
con %0d%0d%0a%0a
HTTP/1.1%20304%20Re-
ply%0d%0a que quitando los ca-
racteres codificados (/r, /n, espa-
cio) quedaría un HTTP/1.1 304
Reply.
2. Denial of Service (DoS)
Este ataque resultó bastante
sencillo, ya que simple-
mente hubo que inyectar
primero código SQL para
obtener la lista de usuarios,
posteriormente se hicieron
los inicios de sesión nece-
sarios para lograr el ataque
DoS. La primera instruc-
ción introducida fue ' or
'1'='1 y posteriormente se
emplearon los datos de los
usuarios legítimos para ini-
ciar múltiples sesiones.
3. Malicious File Execution
También fue una práctica muy fácil de resolver, ya que cualquier desarrollador web con un poco de
experiencia debe conocer este tipo de amenazas, en lo personal, cuando en proyectos hago carga de
archivos verifico el MIMEType con el fin de evitar la ejecución de código no deseado. Esta práctica
se resolvía tan solo creando un archivo que simulara un ejecutable (exe, php, asp, etc.).

3. Por: Héctor Garduño Real
Máster en Dirección e Ingeniería de Sitios Web
Seguridad en la web
03 de mayo de 2015 Página 3 de 6
4. Injection Flaws
La principal de las amenazas del top ten de OSWAP son precisamente las inyecciones en sus diferen-
tes variantes, por lo que está Lección abarca varios ejercicios de los cuales algunos están restringidos
para la versión de desarrolladores de WebGoat, por lo que no fueron hechos. Adicionalmente también
fue requerida una herramienta para capturar y reenviar las peticiones HTTP, para lo cual se empleó
Tamper Data.
El primer ejercicio, bas-
tante simple, consistió
en reescribir y reenviar
las cabeceras HTTP,
para introducir la inyec-
ción SQL, ello debido a
que la página no contaba
con una caja de texto,
sino con un option select
desde el cual no se puede
escribir.
El segundo ejercicio consistía en loguearse como administrador, sin embargo al intentar varias formas
de inyección SQL pero al no lograrlo opte por pedir pistas (hits) y rápidamente entendí que debía
crear nuevas líneas, por lo que la solución era usar %0d y %0a. La solución fue ingresar ad-
min%0d%0a.
El siguiente ejercicio también me costó varias pruebas, y requerí de las pistas para ayudarme a resol-
verlo pues nunca había hecho inyección para XPath, de hecho no sabía que eso se podía, después de
investigar en internet un poco di con la solución que era ' or 1=1 or '1'='1.

4. Por: Héctor Garduño Real
Máster en Dirección e Ingeniería de Sitios Web
Seguridad en la web
03 de mayo de 2015 Página 4 de 6
El siguiente ejercicio fue una sencilla inyec-
ción de SQL, cuya respuesta era smit' or
'1'='1.
Sin embargo, el siguiente ejercicio, aunque era
bastante simple también, comencé a desespe-
rarme porque no quedaba, hasta que me di
cuenta que el campo de password tenía un
maxlength que limitaba los caracteres, por lo
que la solución fue simple, reescribiendo y re-
enviando las cabeceras HTTP usando como
password smit' or '1'='1.
La fase 2 de este ejercicio no se pudo
realizar debido a su restricción para
desarrolladores.
El siguiente ejercicio fue el que no pude resolver, por lo que tuve que recurrir a ver la respuesta, y lo
que sucedia es que no era difícil, sino que el primer paso era iniciar sesión con un usuario normal y
posteriormente ejecutar la inyección para ver la información del administrador, mientras que todos
mis intentos se inyección los hice para intentar iniciar sesión. Analizandolo después, pensé, ¡tiene
lógica! este formulario es para iniciar sesión, no para mostrar datos consultados.
Así pues, una vez que se iniciaba sesión bastaba con ordenar los cantidades de salarios, ya que solo
se muestra un resultado, entoces el que mostrará será el más alto, es decir el del jefe.

5. Por: Héctor Garduño Real
Máster en Dirección e Ingeniería de Sitios Web
Seguridad en la web
03 de mayo de 2015 Página 5 de 6
La fase 4 también estaba restringida a desarrolladores por lo que no se resolvió
Finalmente las siguientes in-
yecciones resultaron relati-
vamente fáciles, pues impli-
caban ejecutar dos senten-
cias SQL, tanto para modifi-
car datos como para insertar,
por ejemplo el siguiente im-
plicó hacer un simple update
para cambiar el salario de
jsmith, lo cual implicaba se-
parar la nueva sentencia
usando punto y coma.
jsmith'; update salaries set salary=5 where userid='jsmith
Posteriormente se necesitó inserter un
nuevo registro, y de igual manera debía
separarse la nueva instrucción con punto
y coma, sin embargo el primer intento
dio error porque estaban mal cerradas las
comillas, por lo que se añadieron al final
dos guiones, los cuales indican que se fi-
nalice la sentencia. La instrucción em-
pleada fue jsmith'; insert into salaries
values('hector',999999)--

6. Por: Héctor Garduño Real
Máster en Dirección e Ingeniería de Sitios Web
Seguridad en la web
03 de mayo de 2015 Página 6 de 6
Los dos ultimos ejercicios re-
sultaron también fáciles, sin
embargo el último en el cual
se empleaba un lanzador, me
resultó algo confuso, pensé
que no debía usar triggers,
pero después de un par de fa-
llos intente con el trigger, y
ello fue correcto, y la adver-
tencia que se mostraba era
solo para indicar que
WebGoat no usa triggers en su
SGBD.
Así pues las sentencias y resultados para cada caso son los siguientes
101';update employee set salary=999999 where userid=101
101’;CREATE TRIGGER
myBackDoor BEFORE IN-
SERT ON employee FOR
EACH ROW BEGIN UPDATE
employee SET email =
'john@hackme.com' WHERE
userid = NEW.userid