Como o elemento de hash faz um login seguro na estrutura do Zend?

Question

Eu vi um exemplo para o login do mesmo código de sopro

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');

    }
}

e na submetação

um código de peça mesmo abaixo

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');
        }

Agora, minha pergunta, qual é o motivo do uso do elemento hash? Como esse elemento de hash é o login seguro?

Alguém pode ajudar a explicar isso?

obrigado

Answer 1

A Wikipedia tem uma página (falsificação de solicitação de site cruzado). Só para entender sua redação da pergunta. Não torna seguro, apenas protege contra um tipo de ataque.

Em suma, alguém pode alterar o estado no servidor sem que o usuário tenha que visitar a página, fazendo com que o navegador carregue um URL (em um quadro oculto ou com uma tag de imagem) sem o conhecimento dos usuários.

Nesse caso, está protegendo contra o Login CSRF. Um exemplo seria que você poderia registrar uma vítima em uma conta do Google personalizada. Então, quando eles pesquisaram usando esta conta, você teria acesso ao histórico de pesquisa.

A falha em ambos os métodos é que eles não têm como acessar a página em que o formulário real está ativado. A proteção é, portanto, atribuir um hash ao usuário para garantir que eles visitem a página de login e enviem o hash correto junto com outros valores.

Uma maneira indiscutivelmente melhor de se defender contra o Login CSRF é verificar o Referer Cabeçalho e rejeite -o se não estiver correto ou não estiver presente.

Answer 2

Veja a descrição no Manual da estrutura do Zend para Zend_Form_Element_Hash:

Esse elemento fornece proteção contra ataques de CSRF aos formulários, garantindo que os dados sejam enviados pela sessão do usuário que gerou o formulário e não por um script desonesto. A proteção é alcançada adicionando um elemento de hash a um formulário e verificando -o quando o formulário é enviado.

Um script de força bruta poderia tentar adivinhar senhas no site se não houvesse um token, apenas publicando combinações aleatórias de credenciais. Mas como o hash é armazenado na sessão, a solicitação falsificada também teria que conter o cookie da sessão, aumentando assim a dificuldade de atacar o site.

Portanto, a página de login contém o hash/token quando é chamado. Este token é armazenado na sessão por uma certa vida. Se o usuário efetuar login e o token não faz parte das credenciais de login, supõe -se que a solicitação venha de um servidor diferente e negada.

Veja também Wikipedia no CSRF