Sta usando 'file_get_contents' su un URL con parametri concatenati sicuri?

Question

Sta usando 'file_get_contents' su un URL con parametri concatenati sicuri?

#1 da (1 voti)

3

Sto verificando qualche codice PHP per un amico e ci sono un paio di% di% di utilizzo per GETting URL in cui i parametri forniti dall'utente sono concatenati senza alcuna escaping, ad esempio:

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);
    // ...
}

Considerando che il prefisso del "nome file" passato a file_get_contents è già stato risolto (cioè, l'autore dell'attacco non può utilizzare file_get_contents ), c'è un modo per abusare di questa funzione passando valori dannosi a file://... e latitude argomenti?

php

posta Daniel Serodio 22.05.2018 - 00:02

fonte

1 risposta

Leggi altre domande sui tag php

Come trovare gli elementi CAPEC relativi a un CVE C'è un modo per bypassare le intercettazioni SNI?

score 1 · Answer 1

Ci sono due vantaggi (dal punto di vista della sicurezza):

Iniziando con un URL hard-coded si assicura che nulla venga caricato localmente (anche se sarebbe difficile sfruttarlo ancora ancora a seconda di cosa succede ai dati dopo viene decodificato da json ).
L'input dell'utente viene iniettato nei parametri dei dati (ad esempio dopo il punto interrogativo).

Ciò limita un utente malintenzionato a modificare solo i parametri della richiesta inviati all'API di geocoding di google. Osservando le opzioni disponibili, non sembra che ci siano molti danni da fare lì.

È comunque consigliabile filtrare l'input dell'utente. Il concetto qui è difesa-in-profondità. Al momento il rischio sembra essere molto basso, ma cosa succederebbe se una modifica successiva del codice modificasse ulteriormente il modo in cui i dati vengono utilizzati, determinando una vulnerabilità? Ad esempio, è che latitude e longitude dall'utente sono persistiti in un database più avanti lungo la linea? Presumo di no (o lo hai trovato se è così) dal momento che stai audendo e controllando questi problemi meno ovvi. Tuttavia, il mio punto è che questa funzione nasconde il fatto che sta funzionando con input non salvati e quindi le modifiche successive potrebbero inavvertitamente introdurre una vulnerabilità.

Quindi sì (come sai), la migliore pratica è quella di disinfettare / validare l'input dell'utente prima di fare qualsiasi altra cosa. Tuttavia, qui non sembra esserci una vulnerabilità immediata a seguito di tale controllo.

Ovviamente, puoi sempre usare semplicemente il fatto che questo endpoint è collegato direttamente all'API di google maps per inviare spam alla pagina in modo costante, con conseguente a) una parte DOS della loro app più grande del previsto b o b) perché Google limita le loro ricerche geoip.