how does hash element make a secure login on zend framework?

Question

hello all

i saw a example for login form same blow code

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

    }
}

and in submitAction

a part code same below

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

now , my question, whats the reason for use of hash element? how this hash element make secure login?

anybody may help explain these?

thanks

Answer 1

See the description in the Zend Framework manual for Zend_Form_Element_Hash:

This element provides protection from CSRF attacks on forms, ensuring the data is submitted by the user session that generated the form and not by a rogue script. Protection is achieved by adding a hash element to a form and verifying it when the form is submitted.

A brute force script could try to guess passwords on the site if there wasn't a token, just by POSTing random combinations of credentials. But because the hash is stored in the Session, the spoofed request would have to contain the Session Cookie as well, thus raising the difficulty to attack the site.

So, the Login page contains the hash/token when it is called. This token is stored in the session for a certain lifetime. If the user logs in and the token is not part of the login credentials, the request is assumed to come from a different server and denied.

Also see Wikipedia on CSRF

Answer 2

Wikipedia has a page on it (Cross Site Request Forgery). Just to pick up on your wording of the question. It doesn't make it secure, it just protects against a type of attack.

In short, someone can change the state on the server without the user having to visit the page by getting the browser to load a Url (Either in a hidden frame or with a image tag) without the users knowledge.

In this case it is protecting against Login CSRF. An example would be that you could log a victim into a custom google account. Then when they searched using this account you would have access to their search history.

The flaw in both of these methods is they have no way to access the page the actual form is on. The protection is to therefore assign a hash to the user to ensure they visit the login page and submit the correct hash along with other values.

An arguably better way to defend against login CSRF is to check the Referer header and reject it if it isn't correct or isn't present.