¿Es seguro usar 'file_get_contents' en una URL con parámetros concatenados?

Question

¿Es seguro usar 'file_get_contents' en una URL con parámetros concatenados?

#1 de Conor Mancone (1 votos)

3

Estoy auditando algo de código PHP para un amigo, y hay un par de file_get_contents usages para obtener URLs donde los parámetros proporcionados por el usuario se concatenan sin ningún escape, por ejemplo:

function getLocation($latitude='', $longitude='') {
    $geolocation = $latitude . ',' . $longitude;
    $request = 'http://maps.googleapis.com/maps/api/geocode/json?latlng=' . $geolocation . '&sensor=false';
    $file_contents = file_get_contents($request);
    $json_decode = json_decode($file_contents);
    // ...
}

Ya que el prefijo al "nombre de archivo" pasado a file_get_contents ya está arreglado (es decir, el atacante no puede usar file://... ), ¿hay alguna forma de abusar de esta función pasando valores maliciosos a latitude y longitude argumentos?

php

pregunta Daniel Serodio 22.05.2018 - 00:02

fuente

1 respuesta

Lea otras preguntas en las etiquetas php

Cómo encontrar elementos de CAPEC relacionados con un CVE ¿Es seguro usar window.history.back ()?

score 1 · Answer 1

Hay dos ventajas (desde un punto de vista de seguridad):

Comenzar con una URL codificada de forma rígida garantiza que no se cargará nada local (aunque sería difícil aprovecharla incluso dependiendo de lo que suceda con los datos después de que se haya descifrado a json ).
La entrada del usuario se inyecta en los parámetros de datos (es decir, después del signo de interrogación).

Esto limita a un usuario malintencionado a solo modificar los parámetros de solicitud enviados a la API de geocodificación de Google. Mirando las opciones disponibles, no parece que haya mucho daño por hacer allí.

Todavía es una buena práctica filtrar las entradas del usuario. El concepto aquí es la defensa en profundidad. En este momento, el riesgo parece ser muy bajo, pero ¿qué sucede si un cambio de código posterior modifica aún más la forma en que se utilizan los datos, lo que resulta en una vulnerabilidad? Por ejemplo, ¿ese latitude y longitude del usuario persisten en una base de datos más adelante? Supongo que no (o lo ha encontrado, si es así) ya que está auditando y verificando estos problemas menos obvios. Sin embargo, lo que quiero decir es que esta función oculta el hecho de que funciona con información no autorizada y, por lo tanto, los cambios posteriores pueden introducir inadvertidamente una vulnerabilidad.

Así que sí (como saben), la mejor práctica es sanear / validar las opiniones de los usuarios antes de hacer cualquier otra cosa. Sin embargo, no parece haber una vulnerabilidad inmediata como resultado de esa supervisión aquí.

Por supuesto, siempre puede usar el hecho de que este punto final está conectado directamente a la API de Google maps para enviar spam a la página constantemente, lo que resulta en a) una factura más grande de lo esperado o b) DOS parte de su aplicación porque la tasa de Google limita sus búsquedas de geoip.