Controlla Base64 Data non è dannoso in PHP

Question

Controlla Base64 Data non è dannoso in PHP

#1 da (3 voti)
#2 da (0 voti)

0

Sto inviando alcuni dati attraverso un parametro GET usando urlencode(base64_encode()) in PHP. C'è un modo per controllare che i dati non siano dannosi prima di usarli dall'altra parte? Sono preoccupato che se l'utente invia eval(malicious_code) nella stringa, verrà eseguito automaticamente quando lo decodifico. Qualche idea?

Forse potrei inviare un token nell'URL e controllarlo dall'altra parte - se così fosse qualche idea per quello - la mia mente è diventata vuota su questo fronte.

php injection

posta Liam Bailey 19.01.2017 - 16:41

fonte

2 risposte

Leggi altre domande sui tag php injection

Come archiviare in modo sicuro le credenziali in variabili bash? Quale sistema operativo / fornitore smartfone è sicuro quando si tratta di exploit? [chiuso]

score 3 · Answer 1

Se esegui urldecode(base64_decode($input)) , non verrà eseguito, solo decodificato. Nel tuo esempio se un input è eval(...) , otterrai la stringa eval(...) dopo la decodifica. A meno che tu non lo esegui esplicitamente, non verrà eseguito.

A proposito, se l'unico punto di applicazione della codifica base64 è aumentare la sicurezza, come per qualsiasi altra codifica, non lo sarà.

score 0 · Answer 2

Come dice Rapli, il destinatario riceve solo il codice se è stato esplicitamente configurato per farlo.

Anche se non vedo alcun motivo per lo scambio di codice eseguibile in questo modo (a meno che non si parli di implementazione del codice su un sistema remoto che è una conversazione molto diversa) potrebbero esserci buone ragioni per garantire l'integrità dei dati in questo modo .

Come al solito, TLS rende la CIA molto più semplice ma, in assenza di un certificato client, non risolve tutti i problemi.

Un approccio complementare sarebbe (per esempio) l'uso di un semplice meccanismo di firma che crea un hash sicuro usando un sale conosciuto da entrambe le estremità e inviandolo con il messaggio. Ma questo non protegge dagli attacchi di replay. Per questo è necessario avere password monouso o transazioni numerate in sequenza. Un'alternativa che riduce semplicemente la finestra di opportunità sarebbe quella di concordare un TTL e includere un timestamp nel payload (firmato).

Ma tieni presente che se stai seguendo la strada di un segreto condiviso, in particolare se non utilizzi TLS, otterrai il vantaggio aggiuntivo della riservatezza utilizzando quel segreto come chiave di crittografia piuttosto che un semplice sale per hash.