come fa elemento di un hash fare un login sicuro su Zend Framework?

Question

ho visto un esempio per il modulo di accesso di codice stesso colpo

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 in submitAction

un codice parte stessa di seguito

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

Ora, la mia domanda, che cosa è la ragione per l'utilizzo di elemento di un hash? come questo elemento hash fare login sicuro?

Qualcuno può aiutare a spiegare questi?

grazie

Answer 1

Wikipedia ha una pagina su di esso (Request Forgery Cross Site) . Giusto per riprendere la sua formulazione della questione. che non si rendono sicura , solo protegge contro un tipo di attacco.

In breve, qualcuno può cambiare lo stato del server, senza che l'utente debba visitare la pagina ottenendo il browser di caricare un URL (o in un frame nascosto o con un'immagine tag) senza la conoscenza degli utenti.

In questo caso si protegge contro Accesso CSRF. Un esempio potrebbe essere che si potrebbe registrare una vittima in un account Google personalizzato. Poi, quando hanno cercato di utilizzare questo conto si dovrebbe avere accesso alla loro storia di ricerca.

Il difetto in entrambi questi metodi è che non hanno modo di accedere alla pagina del modulo attuale è acceso. La protezione è quello di assegnare quindi un hash per l'utente al fine di garantire che visita la pagina di login e presentare l'hash corretto insieme ad altri valori.

Un modo forse migliore per difendersi login CSRF è di controllare l'intestazione Referer e respingerla se non è corretto o non è presente.

Answer 2

Si veda la descrizione nel manuale di Zend Framework per Zend_Form_Element_Hash :

  

Questo elemento assicura la protezione da attacchi CSRF sulle forme, garantendo i dati sono presentata dal sessione utente che ha generato la forma e non da uno script canaglia. Protezione è realizzata aggiungendo un elemento hash ad una forma e la verifica quando il modulo viene inviato.

Uno script forza bruta potrebbe cercare di indovinare le password sul sito se non ci fosse un segno, proprio con la pubblicazione di combinazioni casuali di credenziali. Ma poiché l'hash viene memorizzato nella sessione, la richiesta di spoofing dovrebbe contenere il cookie di sessione e, aumentando così la difficoltà di attaccare il sito.

Quindi, la pagina di accesso contiene l'hash / gettone quando viene chiamato. Questo token viene memorizzato nella sessione per una certa durata. Se l'utente accede e il token non fa parte delle credenziali di accesso, la richiesta si presume provenire da un altro server e negato.

Wikipedia su CSRF