Qualsiasi vulnerabilità di sicurezza che utilizza i nomi file generati dal database?

Question

Qualsiasi vulnerabilità di sicurezza che utilizza i nomi file generati dal database?

#1 da (4 voti)

3

Ok, per esempio, dì che hai le impostazioni memorizzate in un database in cui l'utente seleziona la lingua del sito.

Ad esempio, supponiamo che la lingua scelta sia Inglese e ora abbia un'impostazione di en .

Quindi all'interno del tuo linguaggio di scripting come PHP puoi generare il percorso del file e includerlo come al solito, ad esempio:

<script type="text/javascript" src="<?=$home_url?>/languages/<?=$lang?>.js"></script>

So che questo valore dovrebbe essere sicuro e davvero se qualche utente malintenzionato ha in qualche modo ottenuto l'accesso al database, probabilmente ci saranno problemi più grandi di cui preoccuparsi, ma suppongo che sia possibile un difetto di sicurezza da qualche parte è possibile essere in grado di corrompere il valore di questo campo e inserire dati imprevisti e dannosi.

Anche se presumo che non potrebbero fare nulla di troppo brutto visto che l'inclusione di <?=$home_url?> dovrebbe impedire a chiunque di includere qualsiasi file da un server remoto?

php web-application attacks directory-traversal

posta Brett 21.11.2016 - 20:06

fonte

1 risposta

Leggi altre domande sui tag php web-application attacks directory-traversal

Una pagina di ricerca vulnerabile a XSS interesserà altri utenti? I miei amici Skype mi stanno inviando link [chiuso]

score 4 · Accepted Answer

Anche se sono solo a metà d 'accordo con te su un utente malintenzionato che ha accesso al DB che non merita di essere protetto, direi comunque che questo non è un grosso problema per un paio di motivi:

Poiché l'inclusione è lato client e non lato server, non rischi di esporre file sensibili che non sono già esposti. Se fosse stato un% di condivisione in PHP, avresti rischi maggiori, dato che può raggiungere file che non possono essere raggiunti tramite HTTP.
Probabilmente solo i file sul tuo dominio possono essere inclusi (ma l'utilizzo di include() potrebbe consentire a un utente malintenzionato di passare ad altre directory). Ma se hai una vulnerabilità di reindirizzamento aperta dalla tua parte, potrebbe essere utilizzata per includere file di altri domini. Sarebbe pericoloso.
A quanto ho capito, l'utente può solo impostare la propria lingua. Quindi, anche se fosse sfruttabile sarebbe difficile "consegnare" l'exploit ad altri utenti.

Ma comunque, non c'è motivo di correre rischi inutili anche se sono piccoli. Questo può essere facilmente difeso contro:

Convalidare i dati nel livello applicazione, in modo che l'utente non possa impostare una lingua che non sia nell'elenco delle lingue. Quindi, se provano a impostare /../ , falliranno.
Assicurati che solo i codici Paese possano essere archiviati in quella colonna del database, ad es. utilizzando una chiave esterna per una tabella ../evil_javascript.js o forse un vincolo di controllo. In questo modo, sai che un utente non può intrufolarsi in strani valori anche se la convalida nel livello dell'applicazione dovesse in qualche modo fallire.
Quindi convalida i dati mentre escono dal tuo DB. Potresti fare un check in questo modo (ma forse con una gestione degli errori migliore):
```
if(!in_array($lang, $language_list)) die("Unknown language!");
```
O facendo questo basterebbe togliere i denti da qualsiasi attacco:
```
<script src="<?=$home_url?>/languages/<?=substr($lang, 0, 2)?>.js">
```

Potrebbe sembrare un po 'esagerato per una cosa a basso rischio. Ma almeno il primo e il secondo punto sono comunque delle buone pratiche, anche se non prendi in considerazione la sicurezza.