アカウント名:
パスワード:
何が問題だったのか、記事を読んでもすっきり書いてないので、自分なりに脆弱性の所在と今回の手口をまとめてみる。
脆弱性の所在:認証と認可をきっちり分けてなくて、認証だけで全部の資源へのアクセスを認可してしまってること。認証というのは Apache のモジュールでいうと mod_authn_* であり、認可は mod_authz_* 。あるいは「認証領域」という言葉で議論することもあるかもしれない。
手口:という脆弱性があるため、自分のカード以外でも番号が分かっていれば、その情報にアクセスできてしまう。番号が分かってなくても、総当たり的にカード番号をとっかえひっかえしてアクセスすれば当たるものには当たる。しかし、はずれも多いわけだから、ログチェックをきちんとやっていればもう少し被害の小さい段階で発見できたはずでもある。
#だと、思ったんだが、違うかな?
類似の脆弱性:よくあるのが、../ で上のディレクトリをたどれたりすると、 /usr1/../user2 で user1 の認証を通っていると user2 へアクセスできてしまうみたいなやつ。某オープンソースの Web システムで実際にあった話。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
authn と authz (スコア:2)
何が問題だったのか、記事を読んでもすっきり書いてないので、自分なりに脆弱性の所在と今回の手口をまとめてみる。
脆弱性の所在:
認証と認可をきっちり分けてなくて、認証だけで全部の資源へのアクセスを認可してしまってること。
認証というのは Apache のモジュールでいうと mod_authn_* であり、認可は mod_authz_* 。
あるいは「認証領域」という言葉で議論することもあるかもしれない。
手口:
という脆弱性があるため、自分のカード以外でも番号が分かっていれば、その情報にアクセスできてしまう。番号が分かってなくても、総当たり的にカード番号をとっかえひっかえしてアクセスすれば当たるものには当たる。しかし、はずれも多いわけだから、ログチェックをきちんとやっていればもう少し被害の小さい段階で発見できたはずでもある。
#だと、思ったんだが、違うかな?
類似の脆弱性:
よくあるのが、../ で上のディレクトリをたどれたりすると、 /usr1/../user2 で user1 の認証を通っていると user2 へアクセスできてしまうみたいなやつ。某オープンソースの Web システムで実際にあった話。
Re: (スコア:0)
単に、口座番号に紐付けられたクレジットカードの情報を確認したり修正したりする画面が用意されていて、
その画面へのアクセス手段が http://example.com/tourokujouhou.cgi?kouzabangou=0123456 みたいな感じだったという話だと読んだのですが。