vrd********

2016/10/4 10:38

55回答

phpにセッションというものがありますが、多くの利用者がいる、大量のセッションIDが発行されているサイトで、セッションIDに対して総当たり攻撃を仕掛けた場合、その中の一つを割り出すより、

phpにセッションというものがありますが、多くの利用者がいる、大量のセッションIDが発行されているサイトで、セッションIDに対して総当たり攻撃を仕掛けた場合、その中の一つを割り出すより、 そのどれかなら楽にヒットさせることができそうに思うのですが、このような攻撃は成功し得るものでしょうか。 ネットを調べていたところ、セッションIDをアクセスの度に変える、というのがありましたが、どのIDでもいい、とした攻撃に対して無意味じゃないかと思うのですが・・・。 ただの素人の勘繰りですが対策があるなら是非教えて頂きたいです。。

PHP | ネットワークセキュリティ・2,980閲覧・xmlns="http://www.w3.org/2000/svg">50

1人が共感しています

ベストアンサー

このベストアンサーは投票で選ばれました

mpyw

2016/10/5 8:17

自著です↓ [PHP] リクエストパラメータ・セッションに関するまとめ - Qiita http://qiita.com/mpyw/items/7852213f478e8c5a2802 ブルートフォース攻撃に関しては，waian_346さんが仰るように「大量の不正通信があった場合通信を遮断しブロックする」機能がかなり重用になってきます．IPアドレスを高頻度で変えられたら無意味ではないか？という疑問もありますが，IPアドレスの変更は時間コストがかなり大きいので，ブルートフォースを成功させるには足枷になります．またフリーProxyやTorのExitノードは公開されているので，そういったIPアドレスに対して軒並み先手ブロックをかましておくのも良案です． セッション固定攻撃に関しては，PHPバージョンが5.3以降であれば，Cookie以外のPHPSESSIDをデフォルトでは受け入れないようになっているので，XSSでも存在しない限り誘導は不可能です．さらに保険として「ログイン情報を受け取った直後の画面で必ず session_regenerate_id(true); を実行する」という処理を行っていて且つCookieがhttponly属性を持っていれば，XSSがあったとしてもセッションIDは抜かれなくなります．

この回答はいかがでしたか？ リアクションしてみよう

mpyw

2016/10/5 8:21

waian_346さん >> 暗号化通信はハイジャックしても鍵を持たないので解読不能です 少しこれは語弊があると思います．トランスポートレベルでのハイジャックはまさに「通信の盗聴」そのものであるので，解読不能というのは正しいです．但し，PHPに関連する文脈でセッションハイジャックといえば，アプリケーションレベルでのものを指す方が一般的です．その場合の手段は盗聴ではなく「罠を踏ませる」であって，解読は必要ありませんね．

その他の回答（4件）

不適切な内容が含まれている可能性があるため、非表示になっています。

投稿内容に関する注意
wef********

2016/10/10 21:56

ネットで調べてその程度？お前みたいなヤツがネット使いこなせるわけねえだろ！ 結局他人頼りだねいつもさぁ。早く病院いけば？

waian_346

2016/10/4 21:12

そのような攻撃はちゃんと名前がついていて、セッションハイジャックと言います。 過去には実際にそのようなことが行われて事件になったことがあります。 セッションIDの払い出しにある一定の規則性があって、それによって次のセッションIDを類推できたりしました。 もちろん相当昔の話です。 今ではランダム性が向上し類推することは不可能に近いレベルになりました。またSSLの暗号化機能も一般化し、暗号化通信はハイジャックしても鍵を持たないので解読不能です。 セッションIDはWebサーバが設定したセッションタイムアウト時間で破棄されます。銀行とかでは5分とか10分とかですのでその間に総当たりをするのは不可能だし、大量の不正通信があった場合通信を遮断しブロックする機能もちゃんと実装されてます。

ID非表示

2016/10/4 13:27

ご質問には二種類の異なる攻撃方法が含まれています。 まず「総当たり」攻撃は「ブルートフォース攻撃」といって、銀行の暗証番号で言えば「0000」～「9999」をすべて入力するような攻撃を言います。 PHPのセッションIDはデフォルトのままだと26桁の数字・英小文字の混在文字列なので、総当たりだと結構な回数を試行しなければヒットしそうにありません。 しかしご提起のように「大量のセッションIDが発行されているサイト」であればヒット確率の分子が大きくなるため、ヒット率が上昇するのはご指摘のとおりです。 このヒット確率はたとえ毎回セッションIDを変更する措置を施していても変わるものではないので、「セッションIDをアクセスの度に変える」のはブルートフォース攻撃には無意味、というご指摘もそのとおりです。 分母が36の26乗というように非常に大きいので、多少アクセス数が多いサイトであっても影響はない、というような意見もありますが、個人情報を扱うサイトでは無視できません。 そういった場合にはセッションIDの桁数を増やすとか、英字は小文字だけでなく大文字も混ぜるとかの措置で対応します。 「セッションIDをアクセスの度に変える」の方ですが、これは「セッションID固定攻撃」に対する対策です。 この攻撃は、あらかじめ攻撃者がサイトで取得したセッションIDを貼り付けたリンクが用意されていて、被害者となるユーザがそのリンクをクリックしてサイトに遷移した際、「攻撃者の知っているセッションID」を被害者に使わせる、という攻撃です。 こうすると被害者がサイトにアクセスしている間、攻撃者は同じセッションIDでアクセスすることで入力中の個人情報を盗み見できる可能性があります。 この時、毎回セッションIDを変更する措置が施されていれば被害者がリンクを踏んでアクセスした瞬間にそのセッションIDはもう無効化されてしまいますので、攻撃者がそのセッションIDでアクセスしても情報が盗まれる心配はなくなります。 実は「セッションID固定攻撃」にはもうひとつ別の対策が必要なケースがあって、それはたとえば攻撃者が用意したセッションIDがどこかの会員サイトの攻撃者のマイページ画面のものであるような場合、だれかがそのセッションID付きリンクを踏んでしまうと攻撃者のマイページにアクセスさせられてしまう、というものです。 一見、被害者側には何の不利益も発生しないように見えますが、仮に会員情報入力画面に誘導され、そこで被害者が個人情報を登録してしまうと、その後で攻撃者がログインして被害者の個人情報を盗み見することができてしまいます。 この攻撃に対応するためには、セッションIDとは別にCookieにユニークな乱数を埋め込んでおいてセッションIDの所有ブラウザと一致しているかどうかをチェックする、などの対策が必要になります。 いずれの攻撃も成功するための前提条件がかなり限定的なので、実際に成功するかどうかはかなり怪しいのですが、個人情報を扱うサイトでは「やりすぎ」はないので、今後もさらにいろいろと対策が増えて行くものと思われます。

jam********

2016/10/4 10:51

例えば簡単な対策の1つとして、IPアドレスが変わったらセッションを破棄するようにしていたら、それだけで実現不可能です。 もっと高度なハッキングを仕掛けないといけなくなります。