0

ログインフォームと同じブローコードの例を見ました

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

    }
}

そしてsubmitActionで

以下同じ部品コード

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

さて、私の質問ですが、ハッシュ要素を使用する理由は何ですか? このハッシュ要素はどのようにして安全なログインを行うのですか?

誰かがこれらを説明するのを助けることができますか?

ありがとう

4

2 に答える 2

3

ウィキペディアにはページがあります (クロス サイト リクエスト フォージェリ)。質問の言い回しを拾うだけです。安全にするわけではなく、ある種の攻撃から保護するだけです。

つまり、ユーザーがページにアクセスしなくても、ブラウザーに (非表示のフレーム内またはイメージ タグを使用して) Url を読み込ませることで、ユーザーの知らないうちに誰かがサーバーの状態を変更できます。

この場合、Login CSRF から保護しています。たとえば、被害者をカスタム Google アカウントにログインさせることができます。次に、このアカウントを使用して検索すると、検索履歴にアクセスできます。

これらの方法の両方の欠点は、実際のフォームがあるページにアクセスする方法がないことです。したがって、保護は、ユーザーにハッシュを割り当てて、ユーザーがログイン ページにアクセスし、他の値と共に正しいハッシュを送信することを保証することです。

ログインCSRFを防御するためのおそらくより良い方法は、Refererヘッダーをチェックし、正しくないか存在しない場合は拒否することです.

于 2010-03-16T10:15:49.263 に答える
2

Zend_Form_Element_Hashの Zend Framework マニュアルの説明を参照してください。

この要素は、フォームに対する CSRF 攻撃からの保護を提供し、悪意のあるスクリプトではなく、フォームを生成したユーザー セッションによってデータが送信されるようにします。保護は、フォームにハッシュ要素を追加し、フォームの送信時にそれを検証することによって実現されます。

ブルート フォース スクリプトは、トークンがない場合、資格情報のランダムな組み合わせを POST するだけで、サイトのパスワードを推測しようとする可能性があります。ただし、ハッシュはセッションに保存されるため、なりすましのリクエストにはセッション Cookie も含まれている必要があり、サイトへの攻撃が難しくなります。

そのため、ログインページには、呼び出されたときにハッシュ/トークンが含まれています。このトークンは、一定の期間、セッションに保存されます。ユーザーがログインし、トークンがログイン認証情報に含まれていない場合、リクエストは別のサーバーからのものと見なされ、拒否されます。

CSRF に関するウィキペディアも参照してください。

于 2010-03-16T10:07:34.990 に答える