¿Usar base64 para evitar inyecciones de SQL?

Utiliza variables de enlace para evitar la inyección de SQL, como:

UPDATE users SET JOB=?, SALARY=?, BONUS=?, COMM=? where id=someId 

A continuación, pasa la entrada de usuario JOB , SALARY , BONUS , COMM como parámetros de enlace.

¿Qué quieres hacer es codificar la entrada del usuario en base64 y luego colocarla en la base de datos como base64? Eso significaría consultar la base de datos, tendrías que decodificar las cosas.

Otra opción es codificar la entrada del usuario en base64, descodificar y luego almacenar en la base de datos. Eso le dará nada más que gastos generales y no impedirá la inyección de SQL.

ADVERTENCIA : Almacenar contraseñas en base64 de codificación en una base de datos es un delito, ni siquiera consideres hacerlo, también podrías almacenar las contraseñas en texto sin cifrar. Contrate a un experto en seguridad de datos, ¡no querrá terminar en los titulares de la larga lista de compañías violadas! NB: NO SOY un profesional de seguridad de datos por profesión.

Suponiendo que el atacante usa lo siguiente:

something'; drop table users; ---

la codificación base64 de eso sería

c29tZXRoaW5nJzsgZHJvcCB0YWJsZSB1c2VyczsgLS0t

Todo bien hasta ahora, sin embargo, si tuviera que consultar este valor, tendría que codificar / decodificar base64 en su consulta / conjunto de resultados.

Por ejemplo, suponiendo que desea seleccionar todas las filas donde UINPUT comenzó con algo , haría esto cuando el valor no esté codificado en base64:

select USERS.* from USERS where UINPUT like 'something%'

y esto si estuviera codificado:

select USERS.* from USERS where UINPUT like 'c29tZXRoaW5n%'

Donde c29tZXRoaW5n por supuesto es la codificación base64 para something , esto es tedioso. Peor aún, la codificación base64 tiene relleno para cadenas que no tienen múltiplos de caracteres 3 , como = , lo que significa que something funciona, aquí, pero somethin ( c29tZXRoaW4= ) no!

Dado que la codificación base64 no puede tener espacios / comillas, no puede inyectar, sin embargo, usar esto es tedioso, las declaraciones preparadas con variables de enlace son MUCHO mejor.

Esto podría "funcionar" en un sentido muy estrecho de la palabra. Si codifica en base64 todas las entradas de usuario destinadas a consultas SQL, no puedo ver cómo sería posible realizar un ataque SQLi, ya que el alfabeto base64 no contiene muchos caracteres útiles.

Pero clavar un clavo en un trozo de madera golpeando repetidamente la frente contra él probablemente también "funcionará", pero te causaría mucho sufrimiento innecesario. Hay una herramienta para eso, se llama martillo. Y hay una herramienta para prevenir la inyección de SQL: se llama declaraciones preparadas.