Cómo defenderse de ataques desde Iframe

[obeiix]

Hola muy buenas!:

Se que este tema estará tratado muchas veces, pero no doy con las palabras clave y por tanto no hallo nada con el buscador.

El problema de seguridad es el siguiente:

Tengo una página .php que se encarga de configurar algunos detalles de los usuarios del sitio. está página comprueba que el usuario este registrado y realiza los cambios solicitados.

Ahora bien, nada impide que se cargue la página desde un iframe por ejemplo llamando a ejemplo.com/configuracion.php?micolor=rojo y modificando el color del usuario.

Como defenderse de un ataque de ese estilo ?? Todas las entras GET POST Y COOKIES están protegidas, pero de este tipo de ataque no se como protegerme.

Ya que mientras el usuario tenga la cookie de sesión, si visita cualquier página maliciosa que carge esa dirección desde un iframe se modificará la configuración.

En un primer momento había pensado en evitar que mi sitio pueda ser cargado dentro de un iframe, ( según he visto se hace mediante javascript ) pero y si el usuario tiene 'apagado' javascript ??

Leí hace algún tiempo que con php se crea una especie de valor aleatorio cada vez que se quiera realizar una modificación de este estilo para evitar esto... pero ni recuerdo donde lo leí ni como se llamaba.

( El problema no es sólo por un iframe, un enlace directo también engañaría al usuario ). Por supuesto podría poner que micolor se reciba por método POST ¿ pero eso es realmente una protección ?


Muchas gracias!!

[pidoayudaenphp]

un ejemplo de ataques mediante iframes es el gumblar.cn qe lo tengo en mi web, cdtmweb.com.ar
y que no se como hacer para que no cargue... :(

[obeiix]

Pongo un ejemplo para que se vea más claro:

Código PHP:

  <?php 
session_start(); 
 
mail('[email protected]','Ataque XSS',"Si aqu&iacute; puedes ver mi email  mala cosa : ".$_SESSION['valid_user'],"Content-type: text/html; charset=utf-8\r\nFrom: [email protected]"); 
 
 ?>   

Si cargamos esta web desde un iframe, cuando el usuario esta logueado en ejemplo.es mandará el email y en $_SESSION['valid_user'] aparecerá el email de usuario.

Aquí no hay ni siquiera variables GET O POST.

[GatorV]

Lo que debes de hacer es comprobar que el formulario venga desde tu sitio, ve la variable $_SERVER['HTTP_REFERER'].

Otra forma es pasar los datos por POST, y usar un formulario CAPTCHA o algo por el estilo.

Saludos.

[obeiix]

Hola GatorV:

Muchas gracias por la respuesta.

Mirando las especificaciones de dicha constante dice:

'HTTP_REFERER'
La dirección de la página (si la hay) la cual refirió al agente de usuario a la página actual. Este valor es definido por el agente de usuario. No todos los agentes de usuario lo definen, y algunos proveen la capacidad de modificar HTTP_REFERER como una característica del software. En resumen, no se puede confiar realmente en este valor.

Lo de captcha no me sirve, ya que por cada acción que quiera hacer el usuario no puedo pedirle que se coma la cabeza con las letritas.
Y el metodo POST no te da una seguridad real, podrian enviar las variables post dentro del iframe igualmente.

Buscando en google a través de HTTP referer he encontrado el nombre que buscaba:

Cross Site Request Forgery (CSRF) No me deja poner enlaces así que si alguien puede poner la dirección de una página que explica muy bien todo este tema:
Buscar en google --> eslomas.com CSRF y el primer resultado es la URL.

Básicamente dice que la solución que aporta un buen nivel de seguridad es un Token, un número aleatorio generado a partir del login, y que se incluye en todos los formularios como variable oculta para validar que se hace desde el propio sitio. Para evitar que esa clave pueda difundirse a otros sitios se recomienda enviar los formularios por POST.
Y por último y muy IMPORTANTE:

Comprobación del Referer: una técnica habitual para evitar ataques CSRF es comprobar que la cabecera HTTP_REFERER coincide con la que se esperaría para esa acción. Esto que a primera impresión puede parecer buena idea no lo es tanto ya que esta cabecera se puede manipular de forma trivial, haciendo que contenga lo que se desee y permitiendo saltar fácilmente este control.

Mil y una gracias!!

[GatorV]

Si implementas Zend_Form ya incluye un elemento para agregar ese tipo de seguridad usando un token oculto, para prevenir eso.

Saludos.