Cómo eludir un 403 Forbidden: cabeceras, métodos, rutas

Introducción

¿Y si eludir los errores 403 pudiera descubrir vulnerabilidades ocultas? Este artículo explora técnicas avanzadas para eludir estos errores y exponer posibles fallos de seguridad. Profundizamos en métodos como el fuzzing de cabeceras de solicitud, que puede revelar configuraciones incorrectas del servidor, la modificación de métodos HTTP para probar distintos tipos de solicitud, la manipulación de parámetros de solicitud para eludir restricciones, el uso de la Wayback Machine para encontrar archivos antes accesibles, y mucho más. Estas técnicas pueden aportar información clave para las pruebas de penetración y las evaluaciones de seguridad.

Técnicas implementadas para eludir errores 403

Para lograr este objetivo, pueden utilizarse numerosas técnicas. Entre ellas, cambiar las cabeceras de host para probar configuraciones incorrectas, crear solicitudes con distintos user agents para descubrir puntos de acceso alternativos, ajustar los parámetros de la solicitud para encontrar vulnerabilidades, generar rutas de solicitud mediante fuzzing para eludir los controles de acceso, y utilizar la Wayback Machine para descubrir contenido antes accesible. Cada uno de estos métodos, y otros más, desempeña un papel fundamental para burlar los errores 403 y revelar fallos de seguridad ocultos.

Cambiar la cabecera Host

Manipular las cabeceras HTTP suele revelar vulnerabilidades o permitir eludir restricciones.

Solicitud/respuesta original:

GET /admin HTTP/1.1  
Host: redacted.com

HTTP/1.1 403 Forbidden  
Access Denied

Solicitud/respuesta modificada (evasión):

GET /admin HTTP/1.1  
Host: google.com

HTTP/1.1 200 Ok  
Admin Panel Login Page(Source Code)

Eliminar la cabecera Host

Excluya la cabecera host para probar las respuestas del servidor cuando el host no se especifica, lo que a veces puede dar lugar a comportamientos predeterminados o a configuraciones incorrectas.

Solicitud/respuesta original:

GET /reach%2fsip.svc HTTP/1.1
Host: lyncdiscover.microsoft.com
User-Agent: curl/7.79.1
Accept: */*
Connection: close


HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Content-Type: text/html
X-MS-Correlation-Id: fd2fe958-0683-4bb6-8ac6-36637ce86b81
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:25:58 GMT
Connection: close
Content-Length: 1233

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
            <title> 
                403 - Forbidden: Access is denied. 
            </title>
            <style type="text/css">
...

Solicitud/respuesta modificada (evasión):

GET /reach%2fsip.svc HTTP/1.0
<deleted_host_header>


HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-MS-Correlation-Id: c989aa79-e7d7-4855-9937-67a51a548435
x-ms-client-request-id: c30a03fa-dce8-4a8c-b34f-c5f6a11d47d0
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:45:40 GMT
Connection: close
Content-Length: 3058

Crear solicitudes con distintos user agents

Utilice distintos bloques específicos de user agent para alterar las características de la solicitud y eludir los bloqueos basados en el user agent.

• Por ejemplo, usar user agents de distintos navegadores o dispositivos puede producir respuestas diferentes.
• Puede encontrar una lista extensa de User-Agents en este enlace.

Crear solicitudes con distintas cabeceras de proxy

Añada cabeceras de proxy para ver si el comportamiento del servidor cambia según la IP de cliente percibida.

• Por ejemplo, use cabeceras como:

X-Originating-IP,
X-Forwarded-For,
X-Forwarded,
Forwarded-For,
X-Remote-IP,
X-Remote-Addr,
X-ProxyUser-Ip,
X-Original-URL,
Client-IP,
True-Client-IP,
Cluster-Client-IP

• Con valores como:

10.0.0.0 
10.0.0.1
127.0.0.1
127.0.0.1:443
127.0.0.1:80
172.16.0.0
localhost

Añadir cabecera de puerto

Añada números de puerto a la cabecera X-Forwarded-Port para comprobar si el servidor tiene reglas específicas por puerto. - Ejemplo: - X-Forwarded-Port: 443 - X-Forwarded-Port: 80

Añadir cabeceras de esquema

Incluya cabeceras específicas del esquema para modificar la solicitud, indicando por ejemplo que la solicitud es HTTP o HTTPS. - Ejemplo: - X-Forwarded-Proto: http - X-Forwarded-Proto: https

Cambiar el método HTTP

Alterne entre métodos como GET, POST, PUT, DELETE, etc., para ver si los distintos métodos se gestionan de forma inconsistente.

Cambiar la mayúscula/minúscula del método HTTP

Pruebe variaciones como GET frente a get para ver si el servidor distingue mayúsculas de minúsculas. - Por ejemplo, usar get /admin HTTP/1.1.

Cambiar el método HTTP mediante una cabecera

Use cabeceras como X-HTTP-Method-Override para eludir las restricciones de método. - Por ejemplo, incluir X-HTTP-Method-Override: PUT en una solicitud POST. - Otros métodos: - X-Original-Method - X-Method-Override

Crear solicitudes con parámetros editados

Modifique los parámetros existentes de la solicitud para probar distintos escenarios de entrada.

Solicitud/respuesta original:

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=9999&access=restricted

HTTP/1.1 403 Forbidden 
Content-Type: application/json 

{ 
    "error": "Access denied" 
}

Solicitud/respuesta modificada (evasión):

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=1&access=granted

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

{
    "message": "Access granted",
    "data": {
        "id": 1,
        "role": "admin"
    }
}

Advertencia:

Esta técnica puede producir falsos positivos si la respuesta del servidor depende del contexto o si los parámetros modificados no se gestionan como se espera. Asegúrese de que los cambios que realice sean pertinentes para los controles de acceso o las condiciones concretas que está probando. Interpretar mal las respuestas debido a un comportamiento no estándar del servidor puede llevar a conclusiones incorrectas sobre la presencia de vulnerabilidades.

Incrementar los valores de los parámetros

Aumente los valores de los parámetros de forma incremental para probar errores de desplazamiento por uno o condiciones límite. - Por ejemplo, id=1, id=2, id=3, etc.

Advertencia:

Incrementar parámetros para probar condiciones límite puede dar lugar a falsos positivos, especialmente si la aplicación gestiona los parámetros de forma no estándar o tiene una lógica de validación extensa. Asegúrese de analizar los resultados en el contexto del comportamiento esperado y considere probar con un rango de valores para identificar con precisión posibles problemas. Interpretar mal las respuestas debido al diseño de la aplicación o a restricciones de datos puede llevar a conclusiones engañosas.

Añadir parámetros

Introduzca parámetros adicionales en la solicitud para ver si el servidor los procesa de forma incorrecta.

• Por ejemplo, añadir isAdmin=true.
• Otros ejemplos:

- ("isAdmin", "true")
- ("order", "desc")
- ("sort_by", "date")
- ("limit", "100")
- ("debug", "true")
- ("admin", "true")
- ("verbose", "true")
- ("user_id", "10")
- ("mode", "admin")
- ("user", "admin")
- ("role", "admin")

Eliminar parámetros

Elimine parámetros para probar el comportamiento predeterminado o si los parámetros obligatorios se exigen realmente. Por ejemplo, eliminar un token de la solicitud.

Invertir el orden de los parámetros

Cambiar el orden de los parámetros de una solicitud a veces puede ayudar a eludir errores 403 Forbidden si el servidor procesa los parámetros en un orden concreto o tiene una lógica que depende de dicho orden. Por ejemplo, si un servidor comprueba los parámetros en una secuencia determinada para el control de acceso o la validación, invertir su orden podría engañarlo para que conceda acceso. Esta técnica resulta especialmente útil cuando la lógica del backend del servidor asume un orden fijo para los parámetros, y alterar ese orden puede revelar vulnerabilidades ocultas.

Por ejemplo, cambiar id=1&name=John por name=John&id=1.

Añadir parámetros extremos

Añadir parámetros de casos extremos puede ayudar a identificar vulnerabilidades al llevar al límite la gestión de entradas del servidor. Valores extremadamente grandes, caracteres especiales o formatos de entrada inesperados pueden desencadenar comportamientos no previstos o revelar debilidades. Esta técnica puede utilizarse para comprobar si el servidor valida o depura correctamente la entrada, y si es susceptible a casos extremos que podrían permitir eludir restricciones de seguridad, incluidos los errores 403.

Por ejemplo, id=0 o name=-99999999999999999999999999999.

Inyección SQL en parámetros

Intente ataques de inyección SQL para probar vulnerabilidades.

Solicitud/respuesta original:

Solicitud/respuesta modificada (evasión):

Parámetros vacíos

Use valores de parámetro vacíos para ver cómo gestiona el servidor los datos ausentes.

• Por ejemplo, id=.

Invertir valores

Invertir los valores de los parámetros consiste en intercambiar los valores de los parámetros para probar si el servidor los trata de forma distinta según su contenido. Esta técnica puede usarse para descubrir vulnerabilidades o inconsistencias en el modo en que se procesan los datos.

Cómo funciona

Algunas aplicaciones pueden procesar los valores de los parámetros de una forma concreta o esperar que se ajusten a un formato determinado. Al invertir o alterar estos valores, puede comprobar si los mecanismos de validación o procesamiento de entradas de la aplicación son robustos.

Ejemplos

• Valores numéricos: cambiar «1» por «0» o «0» por «1».
• Valores booleanos: cambiar «true» por «false» y «false» por «true».
• Valores de cadena: cambiar «yes» por «no» y «no» por «yes», o «Yes» por «No» y «No» por «Yes».

Contaminación de parámetros

La contaminación de parámetros se refiere a la técnica de introducir parámetros duplicados o en conflicto en solicitudes HTTP para alterar o manipular el modo en que un servidor procesa la entrada. Esto puede confundir al servidor, dando lugar potencialmente a un comportamiento no previsto o exponiendo vulnerabilidades.

Así es como funciona:

1. Parámetros duplicados: Al incluir el mismo parámetro varias veces con valores distintos, como id=1&id=2, puede comprobar cómo gestiona el servidor dicha entrada. Los servidores pueden procesar estos duplicados de varias formas:
   • Primera aparición: Algunos servidores pueden tener en cuenta solo la primera instancia del parámetro e ignorar las siguientes.
   • Última aparición: Otros pueden usar el último valor proporcionado y descartar los anteriores.
   • Combinación: En algunos casos, los servidores pueden intentar combinar o fusionar los parámetros duplicados, lo que puede dar lugar a resultados inesperados.
2. Gestión de conflictos: Los servidores pueden gestionar de forma distinta los parámetros en conflicto. Por ejemplo, si una solicitud incluye sort=asc&sort=desc, la forma en que el servidor resuelve este conflicto puede revelar inconsistencias o debilidades.
3. Elusión de restricciones: La contaminación de parámetros a veces puede eludir restricciones de seguridad o comprobaciones de validación. Por ejemplo, un servidor puede tener reglas de validación estrictas para un parámetro que se eluden si se introducen varias instancias de ese parámetro.

Cambiar mayúsculas/minúsculas en la ruta

Modifique las mayúsculas y minúsculas de los caracteres de la ruta para probar la sensibilidad a este aspecto. - Por ejemplo, cambiar /admin por /Admin.

Añadir extensión a la ruta

Añada extensiones a la ruta para ver si los distintos tipos de archivo se tratan de forma diferente. - Por ejemplo, cambiar /admin por /admin.php.

Variaciones de ruta

Pruebe distintas codificaciones y variaciones de ruta: - /path (bloqueado) → /%2e/path, /%252e/path. - Evasión con Unicode: /%ef%bc%8fpath. - Variaciones de mayúsculas/minúsculas y barras finales: /secret, /SECRET, /secret/, /secret/., //secret//, /./secret/.. - Caracteres adicionales: ;/secret, /.;/secret, //;//secret.

Solicitud/respuesta original:

Solicitud/respuesta modificada (evasión):

Cambio de versión de la API

Alterne entre distintas versiones de la API para probar vulnerabilidades específicas de cada versión. - Por ejemplo, cambiar /v1/users por /v2/users.

Codificar la primera letra de la URL

Codifique en URL el carácter inicial de la ruta para probar si se gestionan incorrectamente los caracteres codificados. - Por ejemplo, cambiar /admin por /%61dmin.

Consultar la Wayback Machine

Usar la Wayback Machine puede ser un enfoque estratégico en las evaluaciones de seguridad para descubrir recursos antes accesibles que ahora están restringidos. Al consultar instantáneas históricas de una URL objetivo, se obtiene visibilidad sobre cómo era una página o un endpoint en distintos momentos. Esto puede resultar especialmente útil para:

1. Identificar URL anteriores: Los registros históricos pueden revelar URL o rutas de recursos que antes eran de acceso público pero que ahora están restringidas o se han eliminado. Esto puede ayudar a descubrir endpoints obsoletos que todavía podrían ser vulnerables.
2. Descubrir recursos ocultos: Recursos como directorios, archivos o API que estaban expuestos en versiones anteriores del sitio podrían estar ocultos ahora. La Wayback Machine puede ayudar a identificar estos recursos, permitiendo realizar más pruebas para determinar si siguen siendo accesibles en determinadas condiciones.
3. Analizar cambios en el contenido: Revisar versiones anteriores de una página puede poner de relieve cambios en los controles de acceso o en la lógica de la aplicación. Esto puede aportar información sobre cómo ha evolucionado la postura de seguridad de la aplicación y si se han introducido nuevas vulnerabilidades.

Por ejemplo, si una página que ahora devuelve un error 403 Forbidden era accesible en instantáneas anteriores, la Wayback Machine puede mostrar su estructura y contenido previos. Este contexto histórico puede revelar posibles rutas de acceso o vulnerabilidades que ya no son evidentes en la versión actual.

Cambiar versiones de protocolo

Al probar distintas versiones del protocolo HTTP —como HTTP/1.1, HTTP/1.0, HTTP/2.0 y HTTP/3.0—, es importante tener en cuenta que no todos los servidores ni todas las pilas admiten cada versión. Algunos servidores pueden tener una compatibilidad limitada o inconsistente con los protocolos más recientes, lo que puede afectar al modo en que se procesan las solicitudes. Por ejemplo, un servidor puede gestionar las solicitudes HTTP/2.0 de forma distinta a las HTTP/1.1, o puede no admitir en absoluto HTTP/3.0. Esta inconsistencia a veces puede dar lugar a comportamientos inesperados, lo que podría permitir que ciertas solicitudes eludan restricciones o revelen vulnerabilidades que no serían evidentes con la versión de protocolo predeterminada. Por tanto, probar distintas versiones puede ser útil, pero conviene tener presentes las limitaciones de compatibilidad de la pila que pueden afectar a los resultados.

Ejemplo: cambiar HTTP/1.1 por HTTP/1.0

Solicitud/respuesta original:

Solicitud/respuesta modificada (evasión):

Conclusión

Empleando técnicas como el fuzzing de cabeceras de solicitud, la experimentación con métodos HTTP, la modificación de parámetros de solicitud y la alteración de rutas de solicitud, podemos descubrir posibles vulnerabilidades ocultas detrás de los errores 403. Además, consultar la Wayback Machine en busca de contenido archivado y probar distintas versiones del protocolo HTTP puede revelar fallos de seguridad pasados por alto. Estos métodos, en conjunto, ayudan a eludir los errores 403 y a identificar debilidades críticas en las aplicaciones web.