セキュリティ勉強会に参加しました 2

2回目分のメモの続きです。

内容

• 徳丸本読書会
  • 開発者のセキュリティに関する責任
    • 裁判のガイドラインがIPA
    • 個人情報保護法はどこから適用されるのか
  • HTTPについて
    • URIとスキーム
    • DNSというスキームは無い
  • ベーシック認証の流れ
• 上記以外で知らなかった用語
  • セッションIDの固定化攻撃
  • クッキーモンスター
  • 別人問題
  • ゼロデイ攻撃
  • Gumblar
  • リスクの受容

徳丸本読書会

1章から読んでいきました。このあたりは、まだついていけている感じなので薄めです。

開発者のセキュリティに関する責任

セキュリティには機能要件とバグに分類できるものがありますが、昨今ではある程度の標準を満たさないと開発者は裁判で負けます。

裁判の基準は https://www.ipa.go.jp/security/vuln/websecurity.html https://www.ipa.go.jp/files/000017316.pdf などに準じているらしい。 簡単なSQLインジェクション対策くらいは言われなくてもしましょう。

例が具体的でこれからの季節涼しくなれそうです。図解で分かりやすいですし。 フレームワークの利用である程度先回りして守られているとはいえ、知らないと踏み外していそうで怖いんですよね。。

個人情報保護法はどこから適用されるのか

個人情報保護法によって、セキュリティ対策を義務づけられるのは5000件を超えたラインからだそうです。

そもそも件数によって義務づけるラインがあることすら知らなかったのですが、案外少ないですね。 事業者である場合は、運営しているサービス全体だそうだとか。

HTTPについて

3章に入って、実際にアプリケーションを起動させて動かしながら...やろうとしたのですが、その場のメンバーが電子版orCD忘れ(私です)だったので、 即席でセキュリティ部署の方が作ってくださったサイトや適当なサイトにアクセスしながら進めました。

電子版に演習用データが入ってないのはちょっとした罠ですね。

URIとスキーム

URIのスキームとプロトコルの違いがよく分からなかったので質問しました。

URIで指すリソースを取得、ないしはアクセスする手段をスキームの部分にプロトコルの名称の形で入れる。

HTTP通信のようにURIでリソースを指定するプロトコルでなければ、 スキームのところに入っているのを見かける事は無い(dnsスキームは見た事が無い...)。

リクエストメッセージとレスポンスメッセージ

その、生のメッセージを見て、ボディとヘッダの区切りって空行なんだ、HTTP平文飛んでるんだということを改めて実感しました。

え、空行って、空行の文字コードいくつかありそうだけど大丈夫？ だから文字コードってヘッダに入ってるのか!?

みたいな、どうでもよさそうなことを思いました。

HTTPリクエスト文にUTF-8の文字列を入れるためには、パーセントエンコーディングをする必要があるのですが、Burpでインターセプトして書き換えるときちょっと面倒ですね...。

GETとPOSTについて

副作用を伴うリクエストの場合、ユーザに記録されたら困る秘密情報を送信する場合、送信するデータの総量が多い場合以外は、GETを使おうという話でした。

逆に、検索条件等でお気に入りする、みたいな使い方が想定される場合、多少条件が多くてもGETで..みたいなのもある気がします(Backlogとかクエリパラメータの部分がとても長かった気がする)。

hidden要素とセッションのどちらに値を置くか

利用者自身によっても書き換えられては困る認証や認可に関する情報はセッション情報に保存すべきですが、それ以外の情報は、まずはhiddenパラメータに保存することを検討するとよい

ふむふむ。 というか、各種確認の要素はユーザから書き換えられても仕方ない、という感じなのでしょうか。

ベーシック認証

ちょっとメモを表にしてみます。

	サーバ側	クライアント側
クライアント側から認証の必要なページにリクエストを送る	認証が必要な事を知っている	認証が必要な事を知らない
サーバ側は認証に必要な情報が送られて来なかったので401を返す	最初の認証にこけた事を知ってる	401でブラウザが認証のフォームの準備をする
ブラウザに表示されたフォームへの入力、またはCurlなどからユーザIDとパスワードを送る	--	所定の形式ならブラウザに表示されたフォーム以外から送っても良い。プロキシでこのリクエストをインターセプトしてユーザIDとパスワードを変えて別のユーザとしてアクセスしたりできる
パスワードが合っていれば200とAuthorizationヘッダが送られる	サーバ側はシステムのアカウントと比較して調べて送る。サーバ側からのレスポンスをインターセプトして、パスワードは合っていないけど、200とAuthorizationヘッダを送ってやるとブラウザはフォームを出さず処理を前に進める？(*)	Authorizationヘッダを受け取ると処理を受け取る

Basic認証のAuthorizationヘッダはIDとパスワードをBase64で暗号化したもので、デコーダを使って復号できる。

• ここから先の処理がどうなるかは来週分の内容...か？

勉強会で出てきた用語で知らなかったもの

分かるかどうかはともかく、とりあえず調べてみる。

セッションIDの固定化攻撃

https://www.ipa.go.jp/files/000017316.pdf の16ページから図解があります。

セッションIDの固定化というのは、攻撃者が自分の接続用のセッションIDをサーバ上に用意しておいて、 そのセッションIDを利用者に何らかの手段で使わせる形でログインさせ、 自分のセッションIDと対応しているアカウントを利用者のアカウントに変更します。

その後で、あらかじめ用意していたセッションIDで攻撃者がサーバにアクセスすると、 サーバは攻撃者の閲覧できるデータではなくて、利用者の閲覧できるデータを返してしまう(なりすまされる)、 というものです。

これは、セッションを定期的に書き換えるものにしたらいいのかな。 後、ログイン処理の度に都度発行するとか...。

書いてあったものの１つが上記で、他にはセッションIDの管理に利用するCookieはHTTPS + secure属性を付与して、 HTTP通信の盗聴を防ぐ、既存のセッションIDに加えてログイン事に発行するページを用意して、 ページ毎に値を確認するようにする、など。

クッキーモンスター

参考: http://blog.tokumaru.org/2011/10/cookiedomain.html http://securityblog.jp/words/cookie_monster_bug.html http://security.srad.jp/story/11/09/28/0629244/

クッキーは何も指定しなければホストごとに発行されます。 ドメイン属性を指定すると指定のホストおよびそのサブドメインのホストに対して発行されます。

ドメイン属性が正しく指定されていない場合、そのドメインの意図しないホストでもクッキーを利用できる事があります。 (例えばaaa.xxx.comで設定したつもりが、xxx.comに対して設定しており、bbb.xxx.comでもaaa.xxx.comで使う値が見える)

具体的な例は自信がありませんが、普通は広すぎるドメイン指定は無視されます。

ですが、IE8など過去の古いブラウザの一部で.co.jpなどのドメイン設定を許可していたので、 地方自治体等のサイトが狙われる事があったそうです。

別人問題

http://www.slideshare.net/ockeghem/phpcondo

サイト上のキャッシュ等を利用した事により、本来閲覧できないはずの情報をユーザーが見てしまう問題。

たとえば、すごく単純な例をあげてみる。

ログインしているユーザが入力したコメントをクッキーに保存しておいて、 リロードしても表示されてるね、みたいなことをしようとしたとする。

ログアウトしたときに、コメントのクッキーを削除するのを忘れたとすると、 次にログインした別のユーザは前のユーザのコメントが見える。

見たくもないし、見られたくもないのに、みたいな問題。

上のスライドショーに例が詳しいので今度読みましょう。

ゼロデイ攻撃

http://e-words.jp/w/%E3%82%BC%E3%83%AD%E3%83%87%E3%82%A4%E3%82%A2%E3%82%BF%E3%83%83%E3%82%AF.html

ゼロデイアタックとは、ソフトウェアにセキュリティ上の脆弱性（セキュリティホール）が発見されたときに、問題の存在自体が広く公表される前にその脆弱性を悪用して行われる攻撃。

Gumblar

https://ja.wikipedia.org/wiki/Gumblar

Gumblar（ガンブラー）とは「Webサイト改ざん」と「Web感染型ウイルス（Webサイトを閲覧するだけで感染するウイルス）」を組み合わせて、多数のパソコンをウイルスに感染させようとする攻撃手法（手口）のことである

流行したのは2009年頃だそうです。

攻撃の流れは以下のようになる。

1. 攻撃者が攻撃対象のサイトを運営しているユーザがアクセスするサイトに、何らかの不正アクセスをしてJavaScriptなどによる攻撃スクリプトを埋め込む。この攻撃スクリプトは、埋め込まれたサイトの閲覧者のコンピュータにマルウェアを感染させる。マルウェアを感染させる際には、Adobe Reader・AcrobatやFlash Player、Java、Windows、Microsoft Officeなどの脆弱性を利用している。
2. 感染させたマルウェアで攻撃対象のサイトを運営しているユーザのコンピュータのFTP通信を監視し、FTPアカウントの情報を攻撃者のサーバに送信させる。この情報を元に、攻撃対象のサイトのファイルを改竄したりする。
3. 改竄する際に1のコードを仕込んでいけば、改竄できる範囲はどんどん広がっていく事になる。

必要な対策等はwikipediaを参照の事。

リスクの受容

費用対効果に見合わないという事で、バグに入らないようなセキュリティ対策は後手になっても仕方ないと判断する事。

Gumblar調べてて、あ、ちょっと出来るんじゃない？という気持ちに一瞬なりましたが、Adobe Reader・AcrobatやFlash Player、Java、Windows、Microsoft Officeなどの脆弱性を利用できないし、その前に一回改竄が必要な手法なのでした。

つまり、広い範囲やセキュリティの高そうなところを攻撃するには、そこを管理する権限のある人が見るようなサイトで、セキュリティが薄いサイトを見つければ良いんですね(違います)！

あと、Webサイトの閲覧に使う各種ソフトはこまめにバージョンアップしようと思いました。