Pregunta

vi un ejemplo de formulario de acceso código mismo golpe

class Form_Login extends Zend_Form {
    //put your code here
    public function init($timeout=360){

        $this->addElement('hash', 'token', array(
             'timeout' => $timeout
        ));
        $this->setName('Login');
       $username = $this->createElement ( 'text', 'username' );
        $username->setLabel('user name:')
                ->setRequired();
                $this->addElement($username);
        $password=$this->createElement('password','password');
        $password->setLabel('password:');
        $password->setRequired();
        $this->addElement($password);
        $login=$this->createElement('submit','login');
        $login->setLabel('Login');
        $this->addElement($login);

        $this->setMethod('post');
        $this->setAction(Zend_Controller_Front::getInstance()->getBaseUrl().'/authentication/login');

    }
}

y en submitAction

a código de pieza mismo más adelante

if (!$form->isValid($request->getPost())) {
            if (count($form->getErrors('token')) > 0) {
                return $this->_forward('csrf-forbidden', 'error');
            }    
            $this->view->form = $form;
            return $this->render('login');
        }

Ahora, mi pregunta, ¿cuál es la razón para el uso de un elemento de hash? cómo hacer que este elemento hash de inicio de sesión seguro?

Alguien puede ayudar a explicar estos?

gracias

¿Fue útil?

Solución

Wikipedia tiene una página en el mismo (Cross Site Request Falsificación) . Sólo para recoger en su enunciado de la pregunta. No hace que sea seguro , que sólo protege contra un tipo de ataque.

En resumen, alguien puede cambiar el estado en el servidor sin que el usuario tenga que visitar la página por conseguir el navegador para cargar una URL (ya sea en un marco oculto o con una imagen de etiqueta) sin el conocimiento del usuario.

En este caso se está protegiendo contra Login CSRF. Un ejemplo podría ser que usted podría registrar una víctima en una cuenta de Google personalizado. Luego, cuando se realizaron búsquedas utilizando esta cuenta que tendría acceso a su historial de búsqueda.

El defecto de ambos métodos es que no tienen forma de acceder a la página de la forma real está activada. La protección es, por tanto, para asignar un hash para el usuario para asegurarse de que visiten la página de inicio de sesión y enviar el hash correcto junto con otros valores.

Un posiblemente mejor manera de defenderse contra CSRF entrada es comprobar la cabecera Referer y rechazar si no es correcta o no está presente.

Otros consejos

Vea la descripción en la manual de Zend Framework para Zend_Form_Element_Hash :

  

Este elemento proporciona protección contra ataques CSRF en los formularios, asegurando los datos se presentan en la sesión de usuario que genera la forma y no por un script sin escrúpulos. La protección se logra mediante la adición de un elemento hash para un formulario y verificar que cuando se envía el formulario.

Una secuencia de comandos de la fuerza bruta podría tratar de adivinar las contraseñas en el sitio si no había una razón, simplemente mediante la publicación de combinaciones aleatorias de credenciales. Pero debido a que el hash se almacena en la sesión, la solicitud falsa tendría que contener la cookie de sesión, así, aumentando así la dificultad de atacar el sitio.

Así, la página de inicio de sesión contiene el hash / ficha cuando se le llama. Este distintivo se almacena en la sesión durante un cierto tiempo de vida. Si el usuario se conecta y el token no es parte de las credenciales de inicio de sesión, la solicitud se supone que provienen de un servidor diferente y negado.

También vea de Wikipedia sobre CSRF

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top