Seguridad $_POST. ¿Evitar modificaciones?

falotron · #1 (**permalink**) 04/02/2010, 09:03

Ando dándole vueltas a cómo proteger los formularios de mi web de los ataques mediante modificación de los mismos... realmente no sé si es lo que se conoce por ataques CSRF (Cross-Site Request Forgeries), intuyo que no, ya que las soluciones que he leído mediante tokens no me sirven en mi caso, o éso o es que me he perdido algo al aplicarlas

El problema...
Un usuario está logado en mi aplicación web, con su correspondiente variable de sesión llamémosla $_SESSION['user'], llega a una página con un formulario, saca el código fuente, copia el formulario, hace sus modificaciones, lo guarda y lo ejecuta...

Las soluciones propuestas en muchos sitios, por ejemplo...
http://shiflett.org/articles/cross-s...uest-forgeries

No me sirven, ya que en el código fuente queda reflejado el valor de $_SESSION['token']
Únicamente valdría si el atacante no está logado en mi aplicación web, pero supongo que si alguien quiere atacarme es porque está usando mi aplicación, está logado y por tanto en la página de recepción de datos del formulario la variable $_SESSION['token'] existe (se ha creado en la página del formulario) y coincide con $_POST['token']

¿Me estoy equivocando en mi razonamiento?
Si estoy en lo cierto, ¿Hay alguna manera de asegurarse realmente de que el usuario viene de mi formulario y no de uno modificado?

Gracias!

David · #2 (**permalink**) 04/02/2010, 09:07

No entiendo muy bien, ¿de qué modificaciones precisamente estás tratando de protegerte?

Un formulario fácilmente puede modificarse con el protocolo javascript: o con cualquier herramienta como Firebug.

abimaelrc · #3 (**permalink**) 04/02/2010, 09:09

Una forma de que te puedes asegurar que es un usuario que está usando tu formulario es usando el captcha.

Vun · #4 (**permalink**) 04/02/2010, 09:12

Cita:

Iniciado por falotron

Ando dándole vueltas a cómo proteger los formularios de mi web de los ataques mediante modificación de los mismos... realmente no sé si es lo que se conoce por ataques CSRF (Cross-Site Request Forgeries), intuyo que no, ya que las soluciones que he leído mediante tokens no me sirven en mi caso, o éso o es que me he perdido algo al aplicarlas

El problema...
Un usuario está logado en mi aplicación web, con su correspondiente variable de sesión llamémosla $_SESSION['user'], llega a una página con un formulario, saca el código fuente, copia el formulario, hace sus modificaciones, lo guarda y lo ejecuta...

Las soluciones propuestas en muchos sitios, por ejemplo...
http://shiflett.org/articles/cross-s...uest-forgeries

No me sirven, ya que en el código fuente queda reflejado el valor de $_SESSION['token']
Únicamente valdría si el atacante no está logado en mi aplicación web, pero supongo que si alguien quiere atacarme es porque está usando mi aplicación, está logado y por tanto en la página de recepción de datos del formulario la variable $_SESSION['token'] existe (se ha creado en la página del formulario) y coincide con $_POST['token']

¿Me estoy equivocando en mi razonamiento?
Si estoy en lo cierto, ¿Hay alguna manera de asegurarse realmente de que el usuario viene de mi formulario y no de uno modificado?

Gracias!

La prioridad en la seguridad de una web respecto a los formularios NO ESTA en el formulario en sí, sino en el tratamiento de las variables que se envían previo al proceso en sí.

Un ejemplo muy tonto:

-Tienes una web con un campo de lista en un formulario llamado CATEGORIA, y dicha lista tiene 10 valores, de 1 a 10. ¿tienes temor a que puedan copiarte el formulario y enviarte un 11? Pues que lo envien! tu luego en el php donde se recogen las variables haces las validaciones pertinentes para que dicho valor sea un valor entero entre 1 y 10 y listo

Otro detalle es usar la variable reservada: $_SERVER['HTTP_REFERER'] , para controlar desde que pagina llega el envio

paynalton · #5 (**permalink**) 04/02/2010, 09:17

entgre otras cosas, lo que metas en $_SESSION[x...] no será visible para el usuario, solo en el servidor.

Puedes verificar que la URL de origen corresponda con la de tu formulario.

Puedes simplemente hacer dos cosas:

Primero generas dos tokens,

El token uno lo sumas al token 2 y aplicas md5 guardando el resultado en una variable de sesion.
El token 2 lo guardas tambien en una variable de sesion.
El token 1 lo envías en un campo oculto al desplegar el formulario.
Recibes el token de vuelta junto con el formulario, unes el token 1 con el token 2, generas el md5 y lo comparas con el que tenias antes y, si empatan, el formulario es el correcto.

De esa manera el usuario jamas conocera el valor de Token2, aunado a que el formulario solo puede venir de tu URL pues.....

falotron · #6 (**permalink**) 04/02/2010, 09:20

Cita:

Iniciado por Vun

La prioridad en la seguridad de una web respecto a los formularios NO ESTA en el formulario en sí, sino en el tratamiento de las variables que se envían previo al proceso en sí.

Un ejemplo muy tonto:

-Tienes una web con un campo de lista en un formulario llamado CATEGORIA, y dicha lista tiene 10 valores, de 1 a 10. ¿tienes temor a que puedan copiarte el formulario y enviarte un 11? Pues que lo envien! tu luego en el php donde se recogen las variables haces las validaciones pertinentes para que dicho valor sea un valor entero entre 1 y 10 y listo

Otro detalle es usar la variable reservada: $_SERVER['HTTP_REFERER'] , para controlar desde que pagina llega el envio

No conocía ésto del $_SERVER['HTTP_REFERER']
¿Pero ésto no soluciona por ejemplo modificaciones hechas con Firebug, no? No sé exactamente cómo funciona Firebug, pero tengo entendido que hace los cambios 'en caliente'

falotron · #7 (**permalink**) 04/02/2010, 09:22

Cita:

Iniciado por paynalton

entgre otras cosas, lo que metas en $_SESSION[x...] no será visible para el usuario, solo en el servidor.

Puedes verificar que la URL de origen corresponda con la de tu formulario.

Puedes simplemente hacer dos cosas:

Primero generas dos tokens,

El token uno lo sumas al token 2 y aplicas md5 guardando el resultado en una variable de sesion.
El token 2 lo guardas tambien en una variable de sesion.
El token 1 lo envías en un campo oculto al desplegar el formulario.
Recibes el token de vuelta junto con el formulario, unes el token 1 con el token 2, generas el md5 y lo comparas con el que tenias antes y, si empatan, el formulario es el correcto.

De esa manera el usuario jamas conocera el valor de Token2, aunado a que el formulario solo puede venir de tu URL pues.....

mmm...
Suena muy bien, lo probaré

David · #8 (**permalink**) 04/02/2010, 09:22

Vuelvo a la pregunta, ¿qué cambios en realidad temes?

Como ya te explicaron, sólo tienes que validar los datos del lado del servidor. No puedes evitar que cambien los datos del formulario, eso es muy fácil de hacer.

Por otro lado, sólo recordar que no todos los agentes de usuario envían la cabecera HTTP_REFERER (o por lo menos no un dato válido), no es recomendable depender de eso.

paynalton · #9 (**permalink**) 04/02/2010, 09:23

firebug no es el unico, hay muchas aplicaciones que te permiten hacer todo dentro del ambiente de dominio.... ante eso lo unico que te queda es comprobar cada valor recibido y, sobretodo, no confiar en nada que venga del uusario.

abimaelrc · #10 (**permalink**) 04/02/2010, 09:24

Estoy de acuerdo con David, por eso te recomiendan lo de los token o captcha.

sander · #11 (**permalink**) 04/02/2010, 09:26

Mira en si no explicas bien cual es el problema que te crea el usuario, pero desde ya te digo que si quieres que los formularios solo lleguen desde tu pagina pues hay muchas formas de controlar eso pero la mas facil y la que te recomiendo es que uses captchas asi el formulario servira una sola ves.

Ahora no importa si el se crea su formulario ya que tu al momento de recoger las variables tienes que validar los campos que te envian para aceptar solo lo que tu quieras sea texto, numeros , etc. no te preocupes en que si el se crea un formulario ya que los spamers son mucho peores tienen programas especialmente para rellenar formulario a la mala y si no validas lo que recoges pues tendras muchos mas problemas a futuro.

Saludos.

maycolalvarez · #12 (**permalink**) 04/02/2010, 09:35

aquí te explican muy bien que es un CSRF: http://www.eslomas.com/index.php/arc...icaciones-web/

puedes verificar la existencia de firebug, con este simple código:

Código Javascript:

Ver originalif(window.console && window.console.firebug){
            alert("El sistema no puede funcionar si la consola de depuración se encuentra activada");
            window.location='error.php';
        }

pero eso no garantiza ni protege contra modificaciones directas por otros componente, suerte!

falotron · #13 (**permalink**) 04/02/2010, 09:43

Cita:

Iniciado por David

Vuelvo a la pregunta, ¿qué cambios en realidad temes?

Como ya te explicaron, sólo tienes que validar los datos del lado del servidor. No puedes evitar que cambien los datos del formulario, eso es muy fácil de hacer.

Sí sí... los datos siempre los valido

Entonces, ¿tan sencillo es de modificar los datos de un formulario 'en caliente', aparte de Firebug?
Quiero decir, si consigo asegurarme de que los datos vienen exclusivamente del formulario de mi página (por ejemplo mediante el sistema de tokens posteado por arriba, y con lo cual evitaría modificaciones 'en frío') y consigo deshabilitar Firebug, como he visto que han posteado... ¿Aún quedarían maneras de modificar mis formularios 'en caliente'?

David · #14 (**permalink**) 04/02/2010, 09:46

Créeme, intentar impedir que cambien los datos del formulario es perder el tiempo.

Como ya indiqué, ni siquiera necesitas más que el protocolo javascript: para hacerlo.

La solución práctica es validar todos los datos que recibas del formulario, comprueba que realmente tengan los tipos de valores que esperas recibir.

maycolalvarez · #15 (**permalink**) 04/02/2010, 09:47

Cita:

Iniciado por falotron

Sí sí... los datos siempre los valido

Entonces, ¿tan sencillo es de modificar los datos de un formulario 'en caliente', aparte de Firebug?
Quiero decir, si consigo asegurarme de que los datos vienen exclusivamente del formulario de mi página (por ejemplo mediante el sistema de tokens posteado por arriba, y con lo cual evitaría modificaciones 'en frío') y consigo deshabilitar Firebug, como he visto que han posteado... ¿Aún quedarían maneras de modificar mis formularios 'en caliente'?

Sí, tal como dice david

paynalton · #16 (**permalink**) 04/02/2010, 09:48

Si, por ejemplo yo uso esto:

http://chrispederick.com/work/web-developer/

Para ayudarme en el desarrollo, pero muchas cosas puedesn ser empleadas para modificar formularios en caliente y atacar de la forma en que describes.

Además estan los expertos que son capaces de crear su propio navegador que ignore distintas políticas de seguridad que tienen los navegadores comunes (como las políticas crossDomain).

Al final no puedes confiar en nada que provenga desde fuera de tu servidor (y a veces nisiquiera desde dentro)

falotron · #17 (**permalink**) 04/02/2010, 09:54

Cita:

Iniciado por David

Créeme, intentar impedir que cambien los datos del formulario es perder el tiempo.

Como ya indiqué, ni siquiera necesitas más que el protocolo javascript: para hacerlo.

La solución práctica es validar todos los datos que recibas del formulario, comprueba que realmente tengan los tipos de valores que esperas recibir.

Pues todo mi gozo en un pozo

Validar el tipo de datos, limpiarlo y demás siempre lo hago

Lo que quería ahorrarme es todo el porrón de comprobaciones, consultas a DB y demás, que podría ahorrarme si supiera a ciencia cierta que los valores recogidos vienen de mis formularios...

morior · #18 (**permalink**) 04/02/2010, 10:09

Yo creo que por ahí arriba te han dado ya la respuesta. Si lo que temes es una inyección (porque lo que comentas se refiere a ese tipo de cosas) siempre puedes hacer diferentes comprobaciones. Recuerda que como bien comentan no te puedes fiar de lo que viene de fuera, pero sí te puedes fiar de lo que hace tu programa.

Un ejemplo, si sabes que sólo vas a recibir valores numéricos y temes que alguien te pase una inyección mete una condición antes del código.

Código PHP:

  if (!is_numeric($variable)){

//lo envías a otro lado e incluso te puedes guardar su variable de sesión si las tienes para saber quién te está toqueteando el código :)

}else{

 
//ejecutas el programa

 
}

sander · #19 (**permalink**) 04/02/2010, 10:18

Cita:

Iniciado por falotron

Pues todo mi gozo en un pozo

Validar el tipo de datos, limpiarlo y demás siempre lo hago

Lo que quería ahorrarme es todo el porrón de comprobaciones, consultas a DB y demás, que podría ahorrarme si supiera a ciencia cierta que los valores recogidos vienen de mis formularios...

Mira es así de simple:

Si haces poco trabajo en tu código pues poca seguridad tendrás.

Si realizas mas trabajo en tu código pues mas seguridad tendrás.

NADA ES FÁCIL EN ESTA VIDA !!!!!

Cosechas lo que siembras.

Saludos.

falotron · #20 (**permalink**) 05/02/2010, 07:28

Cita:

Iniciado por sander

Mira es así de simple:

Si haces poco trabajo en tu código pues poca seguridad tendrás.

Si realizas mas trabajo en tu código pues mas seguridad tendrás.

NADA ES FÁCIL EN ESTA VIDA !!!!!

Cosechas lo que siembras.

Saludos.

Lógico

La cuestión aquí es...
En mi caso concreto, aparte de validar la integridad de los datos recibidos para corregir posibles ataques a BD tengo otras muchas validaciones que hacer aparte de si un dato es númerico, alfanumérico, etc...

Imaginad esta situación (tremendamente simple)
Vendo un producto, que viene dado por las variables $referencia y $precio
Lo lógico y seguro sería pasar únicamente $referencia por formulario, y después sacar $precio de la BD... pero imaginemos el caso que quiero pasar ambas variables por formulario, si fuera seguro podría ahorrarme la consulta a la BD en el código de recepción de datos. Este ejemplo muestra el día a día de mi aplicación web, pero en lugar de 2 con muchas más variables. Por éso quería intentar asegurar este tema, aunque ya me he dado cuenta que no es posible y que en definitiva lo mejor es pasar lo justo por formularios... cest la vie

svengel · #21 (**permalink**) 22/09/2011, 17:45

Cita:

Iniciado por paynalton

entgre otras cosas, lo que metas en $_SESSION[x...] no será visible para el usuario, solo en el servidor.

Puedes verificar que la URL de origen corresponda con la de tu formulario.

Puedes simplemente hacer dos cosas:

Primero generas dos tokens,

El token uno lo sumas al token 2 y aplicas md5 guardando el resultado en una variable de sesion.
El token 2 lo guardas tambien en una variable de sesion.
El token 1 lo envías en un campo oculto al desplegar el formulario.
Recibes el token de vuelta junto con el formulario, unes el token 1 con el token 2, generas el md5 y lo comparas con el que tenias antes y, si empatan, el formulario es el correcto.

De esa manera el usuario jamas conocera el valor de Token2, aunado a que el formulario solo puede venir de tu URL pues.....

La verdad es que para mi esta es tambien una muy buena solucion

si te pudiera dar puntos te los daría paynalton jeje saludos