Как хеш-элемент делает безопасный вход в Zend Framework? - PullRequest
Новая
       10

Как хеш-элемент делает безопасный вход в Zend Framework?

0 голосов
/ 16 марта 2010

я видел пример для формы входа тот же код удара 

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

    }
}

и в действии

код детали ниже 

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

теперь мой вопрос, в чем причина использования хеш-элемента? как этот хеш-элемент делает безопасный вход?

Кто-нибудь может помочь объяснить это?

спасибо

Ответы [ 2 ]

3 голосов
/ 16 марта 2010

На Википедии есть страница (Подделка межсайтовых запросов) .Просто чтобы подобрать формулировку вопроса. Это не делает его безопасным , оно просто защищает от типа атаки.

Короче говоря, кто-то может изменить состояние на сервере без необходимости посещать страницу, получивбраузер для загрузки URL-адреса (либо в скрытом фрейме, либо с тегом изображения) без ведома пользователя.

В этом случае он защищает от входа CSRF.Примером может быть то, что вы можете войти в жертву в пользовательский аккаунт Google.Затем, когда они будут выполнять поиск с использованием этой учетной записи, вы получите доступ к их истории поиска.

Недостаток обоих этих методов заключается в том, что у них нет возможности получить доступ к странице, на которой находится фактическая форма.Поэтому защита состоит в том, чтобы назначить пользователю хэш, чтобы он посетил страницу входа и отправил правильный хэш вместе с другими значениями.

Возможно, лучший способ защиты от CSRF входа - проверить Refererзаголовок и отклонить его, если он неправильный или отсутствует.

2 голосов
/ 16 марта 2010

См. Описание в Руководстве Zend Framework для Zend_Form_Element_Hash :

Этот элемент обеспечивает защиту от CSRF-атак на формы, обеспечивая передачу данных сеансом пользователя, который сгенерировал форму, а не мошенническим сценарием. Защита достигается путем добавления элемента хеша в форму и проверки его при отправке формы.

Скрипт грубой силы может попытаться угадать пароли на сайте, если токена не было, просто отправив произвольные комбинации учетных данных. Но поскольку хэш хранится в сеансе, подделанный запрос также должен содержать cookie-файл сеанса, что повышает сложность атаки на сайт.

Итак, страница входа в систему содержит хеш / токен, когда он вызывается. Этот токен хранится в сеансе в течение определенного времени. Если пользователь входит в систему и токен не является частью учетных данных для входа, предполагается, что запрос поступил с другого сервера и отклонен.

Также см. Википедия по CSRF

...