Verificar datos de Base64 no es malicioso en PHP

Question

Verificar datos de Base64 no es malicioso en PHP

#1 de Rápli András (3 votos)
#2 de symcbean (0 votos)

0

Estoy enviando algunos datos a través de un parámetro GET usando urlencode(base64_encode()) en PHP. ¿Hay alguna manera de verificar que los datos no sean maliciosos antes de usarlos en el otro lado? Me preocupa que si el usuario envía eval(malicious_code) en la cadena, se ejecutará automáticamente cuando lo descodifique. ¿Algún pensamiento?

Tal vez podría enviar un token en la URL y verificarlo en el otro lado, si es que tengo alguna idea al respecto, mi mente se ha quedado en blanco en ese frente.

php injection

pregunta Liam Bailey 19.01.2017 - 16:41

fuente

2 respuestas

Lea otras preguntas en las etiquetas php injection

¿El tráfico cifrado mediante IPSec interceptado en tránsito a través de Internet público, es hackeable? ¿Qué sistema operativo / proveedor de smartfone son los seguros en lo que respecta a las vulnerabilidades? [cerrado]

score 3 · Answer 1

Si ejecuta urldecode(base64_decode($input)) , no se ejecutará, solo se decodificará. En su ejemplo, si una entrada es eval(...) , obtendrá la cadena eval(...) después de la decodificación. A menos que lo ejecute explícitamente, no se ejecutará.

Por cierto, si el único punto de aplicar la codificación base64 es aumentar la seguridad, como en cualquier otra codificación, no lo hará.

score 0 · Answer 2

Como dice Rapli, el final de la recepción solo ejecutará el código si se ha configurado explícitamente para hacerlo.

Aunque no veo ninguna razón para intercambiar código ejecutable de esta manera (a menos que estemos hablando de implementación de código en un sistema remoto que es una conversación muy diferente), puede haber buenas razones para garantizar la integridad de los datos de esa manera .

Como es habitual, TLS hace que la CIA sea mucho más simple pero, en ausencia de un certificado de cliente, no resuelve todos los problemas.

Un enfoque complementario sería (por ejemplo) utilizar un mecanismo de firma simple para crear un hash seguro usando un salt conocido por ambos extremos y enviarlo con el mensaje. Pero esto no protege contra los ataques de repetición. Para eso necesitas contraseñas de un solo uso o transacciones numeradas secuencialmente. Una alternativa que simplemente reduce la ventana de oportunidad sería acordar un TTL e incluir una marca de tiempo en la carga útil (firmada).

Pero tenga en cuenta que si va por el camino de un secreto compartido, especialmente si no está usando TLS, entonces obtendrá el beneficio adicional de confidencialidad al usar ese secreto como una clave de cifrado en lugar de solo una sal para el hash.