14
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

ログイン時のCSRF対策は必要か

Posted at

CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん!(Hatena)

を読んでの噛み砕きです。

「ログイン済みの人に何か操作させる」ってイメージが強くて、
対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。
例えば、勝手に日記に投稿させないように対策する、みたいな。

まさにイメージがこれだったので。

結論

(結論) ログインのフォームもCSRF対策したほうがいいよ。

  • 被害が出るかはユーザーの気を付け方次第。
  • 被害の大きさはサービスの性質・ユーザーのアウトプットの内容次第。

「閲覧専用」のようなサービスにはほぼ影響が無く、
体感、発生率・被害度は他の攻撃と比べてとても低そうではあるものの、
一律で言ってしまえばCSRF対策を施したほうがよい。

調べたことからの理解

のまえの前置き

  • ログインページ以外のログイン後ページにもCSRF対策をしていないのは問題外とします。
  • ログインさせるサイトも攻撃者が作ってしまえば知らない内に知らない操作をさせられて不正請求…とか考えられますか?やはり本題とは外れそうですけれど。 
  • 合わせて他の脆弱性、詐欺との合わせ技も深く考えないこととします(知識不足)

  • CSRF対策を施していないと、攻撃者のページを閲覧するだけで、そのページと関係がないサービスの、攻撃者が事前にログインできることを確認できているアカウントに知らないうちに強制ログインさせられます。
  • ログイン後のページにはCSRF対策が施されている前提なので、それ以上、攻撃者は利用者が意図しないリクエストでのログイン後操作を行うことはできません。
  • 強制ログインさせられるサイトが、利用者が普段使用しているサイトだった場合、自分のアカウントと間違えて強制ログインさせられたアカウントで手動で操作を行ってしまう可能性はあります。
  • フィッシング詐欺とは異なるため、ユーザーがフォームに入力するは必要なく、ページを閲覧するだけで攻撃者が持っている情報でログインが行われます。
  • ログイン先が攻撃者が用意したアカウントであれ、漏洩した第三者のアカウントであれ、他者のアカウントにログインする(させられる)ことは不正アクセス禁止法にふれる可能性がありそう。
    • ユーザーの入力によるログインかCSRFを利用したログインかを判別できる方法はある?攻撃者の旨味は?1

総じて、
「強制ログイン後に利用者が気づかないままそのサービスで個人情報が残るような利用をすることを期待する」
程度の比較的のんびりした定置網漁のような攻撃?

CSRF対策が施されていないようなマイナーなサイトでは利用者自体も少なく、ログインしたサイトで誤操作してもらえる可能性が低く、
メジャーなサイトではそもそもCSRF対策がされている可能性が高い。

なんてことが起きそう。
(2012年の記事ではメジャーどころもしていないという話なんですが)

攻撃者が任意の操作を行えずユーザーのうっかりに期待するということで、
たとえばQiitaならいいね・ストックはまだ良いとして、秘密の情報を限定共有投稿にしてしまうことは危険と言えます。

でもProgateなら起きそうなことと言えば勝手に学習率を進められてしまう。ぐらいでしょうか?

プライベートなことを扱わないWebサイトの場合は大きな被害はなさそうです。

通常のCSRF攻撃と異なり、第三者のアカウントが使われる
ということが特徴的かなと思いました。
ただし、これは参照記事では「攻撃者のダミーアカウント」としか書かれておらず1対1の関係で終始しており、
第三者のアカウントの話ははてブの不正アクセスから私が広げた話なので、ホンシツ的な話ではないかもしれません。


ユーザーとしての対策は「気をつける」なんですが、記事でもある通り、どちらかと言えばバックグランドでの連携で知らぬ間にアカウントが切り替わっていると気づくのは難しいのかなあと思います。

ログアウトはどうなの?

勝手にログアウトさせられる以上の被害はない。
徳丸氏いわく、攻撃者への威嚇程度にはなればいいな?(もう8年前の話ですけれど)

ログアウトの CSRF 対策は本当に必要なのか? | Webセキュリティの小部屋

どうしてもCSRF対策したくなかったら?

既ログイン中のログイン処理はアカウントを切り替えない処理を入れる?
→ログアウトからのログインという攻撃には無効→ログアウトにCSRF対策入れるならログインに渋る理由がわからない。
ので、あまりよくなさそう。

Twitterのようにユーザーごとに画面をカスタマイズできてユニーク感を出す→他サービスとの連携機能があればメイン画面を見ないこともあるので切り替わりに気づきにくい。

うーん、あまりいい案はなさそう。

参考




ログインした利用者が罠にかかり悪意あるリクエストを行ってしまうことを「CSRF攻撃」というならば、今回の話題はそもそもCSRFとは言えない? 「CSRFの脆弱性」とは言える?

  1. 「踏まされた」なら処罰はないと思いますが、それがわかるのか?という疑問。
    普通のCSRF攻撃なら踏まされた人=操作されるアカウントなのでややこしくない気がしますが。
    普通のCSRF攻撃で発生した第三者への危害で踏まされた人が処罰されないなら、やはり不正アクセスにはならない?

14
9
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?