Seguridad en código binario

[edward1994]

Hola, hoy estuve escuchando a alguien hablando sobre la seguridad en los códigos PHP en binario hasta dijo que ingresando un código binario en una web puede modificar los parámetros de las consultas a la BD

Es esto cierto? De ser así! existe alguna función en PHP que verifique que lo ingresado es código binario? para así mostrar un error de lo ingresado

O existe alguna otra forma de ingresar esos códigos binarios? y afectar los códigos PHP?

De que forma puedo proteger mis códigos PHP de los códigos binarios?

Gracias!

[Triby]

Código binario?... no lo creo, tal vez hablan de codificar caracteres, ya sea con HTML, hexadecimal u otro.

Tal vez te sirva leer esto: http://www.forosdelweb.com/f18/aport...ar-xss-948577/
y esto: http://www.forosdelweb.com/f18/aport...a-php-1011808/

[edward1994]

Yo también pensé lo mismo! pero no!
hablaba de que con código binario pueden hacer que una introducción sql cambie!
los links que me envias ya los he visto por cierto el primer link de la función por las inyecciones xss lo implemento siempre en mis proyectos!

Como yo siempre soy de los que digo que ningún sistema es 100% seguro!
y que si hablamos de seguridad pongo siempre el ejemplo de las casas, lo normal es entrar por al puerta! allí debes de pasar por "varias validaciones" antes de entrar pero también es valido que entres por la ventana de la casa lo cual es algo nada común y puede que tenga menos "validaciones" pero a la final da el mismo resultado! y ademas que si los sistemas de las grandes empresas fallan como windows que creo q antes de que lo saquen públicamente en el centro de mi ciudad ya lo tienen en su versión pirata!

En conclusión: Debemos ser precavidos con las Inyecciones SQL, Inyecciones XSS

Si me falta alguna otra, pues completemos la lista!

[Triby]

Para poder aclarar mejor el tema, a que te refieres exactamente con "código binario"?

Los navegadores sólo envían texto y/o, en su caso, archivos:
a) Si este texto es parte de un código binario, con algunos filtros (como el de GatorV), validaciones y un escapado correcto para armar la consulta SQL es suficiente para neutralizar (o al menos minimizar) el peligro
b) Si el código binario lo recibes por archivo, la única forma de que cause daños es que se trate de un ejecutable y no tomes las precauciones adecuadas

Estoy de acuerdo en que no hay sistema 100% seguro, pero me gustaría ver un ejemplo de los peligros del "código binario" para saber si estoy equivocado y, si es el caso, tomar las medidas necesarias en mis desarrollos.

[webankenovi]

Hoy estudiando un poquito me tope con lo que el amigo pregunto, aqui dejo un extracto de un libro que lei, me parecio interesante y recordaba este tema.

6.3. IDS Evasion
Todo este proceso de inyectar sentencias en los parámetros vulnerables no es
especialmente sigiloso, por lo que la implementación de un sistema que de-
tecte los parámetros y los evite (IDS, IPS) es relativamente sencilla. Estos siste-
mas normalmente están basados en firmas que en cuanto encuentran partes
sospechosas en las peticiones de URL, como las resultantes de utilizar senten-
cias SQL en los valores de los parámetros, detienen la conexión. También estas
sentencias son fácilmente detectables al consultar los
logs
del sistema.

Las técnicas de evasión tratan de “ocultar” lo que están realizando realmente
las sentencias que lanza el atacante. Al estar los sistemas de detección basados
en firmas, se trata de intentar ejecutar acciones maliciosas modificando la sin-
taxis habitual para que no coincidan con dichas firmas. Para ello, lo mejor es
usar distintas codificaciones. Normalmente los IDS no recodifican las senten-
cias para poder aplicar la comprobación de firmas por una cuestión de eficien-
cia, lo que se puede aprovechar para evitarlos. Existen varias codificaciones
que se pueden utilizar como UTF-8, URL-encoding, codificación hexadecimal,
etc. Todas estas codificaciones suele entenderlas la base de datos a la que llega
la consulta final, pero puede que no el IDS.

Por ejemplo, supongamos que un IDS corte cualquier conexión que contenga
el literal “unión”, de modo que la siguiente inyección no sería efectiva:

idlibro = 1' union @@version -

Un primer intento de evitar el IDS sería cambiando la codificación:

URL-encoding32: 117 110 105 111 110 32 64 64 118 101 114 115 105 111 110 32 45 45
Base 64: encodingIHVuaW9uIEBAdmVyc2lvbiAtLQ==
Hex-encoding20: 75 6e 69 6f 6e 20 40 40 76 65 72 73 69 6f 6e 20 2d 2d

Esta codificación hay que adaptarla para enviarla mediante la herramienta con
la que se realiza la inyección (puede ser un simple navegador). Por ejemplo,
con URL
encoding
hay que introducir el carácter % delante de cada código nu-
mérico, en Hex
encoding
hay que introducir 0x antes de cada valor hexadeci-
mal, etc.

Por otra parte, hay una serie de sentencias que se utilizan habitualmente, como
las que se ven en la parte de inyección ciega, como pueden ser “or 1=1” o
similares. En estos casos, es recomendable utilizar sentencias equivalentes pero
distintas, como puede ser
“or 84847=84847”

supongo (por que no lo he probado) yo que introduciendo imaginemos OR 1=1 en su correspondiente binario este podria ser codificado por la base de datos en la consulta final, a eso es a lo que se refiere la pregunta verdad? yo estuve creando un modulo de seguridad que detecta ataques sql injection y la verdad tengo la lista negra de comandos la tengo hasta en binario por si las moscas , en utf-8 , base64 , hex , urlencode , etc.....

[Triby]

Si recibes un dato que incluya OR 1 = 1 o cualquier otro comando utilizado para inyección SQL, ya sea en ascii, binario, hexadecimal, o lo que sea, basta con que filtres y escapes correctamente antes de colocarlo en una consulta.

De hecho, para proteger tu base de datos, hasta la obsoleta mysql_real_escape_string() es suficiente, pero no filtrar correctamente deriva en riesgos como XSS y, casi siempre (por aquello de que no hay sistema 100% seguro), la función de GatorV se encarga perfectamente de ello.

[webankenovi]

Estoy de acuerdo contigo , lo unico que el modulo que yo hice es parte de un waf , digamos que un developer esta desarrollando su aplicacion y tiene instalado este waf y por error se le olvida escapar alguna parte de alguna consulta , pues bueno este se encarga de protegerle ya que este esta en busca constantemente de comportamientos que comprometan la aplicacion en este caso sql injection, tan solo quise publicar el post por que me parecia interesante el argumento no por discutiros nada, saludos.

[Triby]

webankenovi, los mayores peligros de PHP se han generado por funciones/opciones que buscan facilitar el trabajo del programador, como la directiva register_globals.

Me parece muy buena idea lo de tu módulo, tal vez todos deberíamos considerar crear o instalar uno, pero hay que ver la forma de que los desarrolladores no olviden verificar, filtrar y escapar la información.

[pateketrueke]

¿Código binario?

Yo sin ver no me lo creo, casi suena a falacia.

Un "código binario" es bytecode, de ningún modo puede formar parte de una cadena o expresión.

Si eso fuera posible sería un ejemplo claro de ingeniería inversa, ¡para obtener el código fuente del binario!

[GatorV]

y es por eso que mejor, conviene hacer consultas preparadas, para minimizar totalmente el daño, o en su caso como bien decía gnzsoloyo el otro día, Stored Procedures, así te evitas cualquier problema y realmente queda protegida tu aplicación...