Hatena::ブログ(Diary)

techlog RSSフィード

理解というものは、つねに誤解の総体に過ぎない
 「スプートニクの恋人」とか「かえるくん、東京を救う 」より

こちらになりました → http://sadah.hatenablog.com/

2012-02-12

[][][]wasbook reading #12 / 「体系的に学ぶ 安全なWebアプリケーションの作り方」を読み終えた

「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」を読了した。けっこう前に。

読み終えるのに半年以上掛かってしまった。それでも id:Kango と一緒に読めて、ひとりで読むよりずっと多くのことを学べた。そもそもひとりだったらいまでも読み終えていなかった気がする。積ん読になって。

というわけで、これは「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」読書会の第12回のエントリ。今回読んだのは以下の範囲。

  • 8章 Webサイトの安全性を高めるために
    • 8.1 Webサーバーへの攻撃経路と対策
    • 8.2 成りすまし対策
    • 8.3 盗聴・改ざん対策
    • 8.4 マルウェア対策
    • 8.5 まとめ
  • 第9章 安全なWebアプリケーションのための開発マネジメント
    • 9.1 開発マネジメントにおけるセキュリティ施策の全体像
    • 9.2 開発体制
    • 9.3 開発プロセス
    • 9.4 まとめ

8章 Webサイトの安全性を高めるために

8.1 Webサーバーへの攻撃経路と対策

この章に書いてあることが理解出来ない人は、WebサイトやWebアプリケーションを公開しないほうがいいと思う。でもそういうサーバはたくさんあって、ちょっと探せばすぐに見つかってしまうけど。

といってもすごく難しいことが書いてあるわけではない。

  • サービス提供に不要なソフトウェアは稼働させない
  • 脆弱性の対処をタイムリーに行う
  • 一般公開する必要のないポートやサービスはアクセス制限する
  • 認証の強度を高める

でもこれらを継続的に実施するのはけっこう大変。だからこそ注意するべきなんだけど。


8.2 成りすまし対策

ネットワーク的な成りすましとして「DNS に対する攻撃」と「ARP スプーフィング」について。

ARPスプーフィングの実例としては、これが有名だと思う。

あとはフィッシングとか、SSLとか。

この章を読んではじめて知ったんだけど、無料で証明書を作ってくれるところがあるみたい。自分でなにかを公開するときには使ってみたい。やっぱりSSLがあると、安心できるし。

サーバー証明書のうちドメイン認証証明書は比較的価格が安く、購入のハードルが低いものですが、ド メイン認証証明書には無料のものもあります。イスラエルのStartComという企業は、無料のサーバー 証明書を発行しています。IE、FirefoxGoogle ChromeSafariOperaの最新版で証明書エラー なく使用できます。IE6でもアップデートが当たっていれば使用できます。 ドメインの認証および暗号化の目的には支障なく使用できるので、証明書費用がネックでSSLを導入で きないケースや、正規でない証明書(自己署名証明書、いわゆるオレオレ証明書)を用いている場合は、無 料サーバー証明書の導入を検討するとよいでしょう。 StartCom社のサーバー証明書は、日本の携帯電話には対応しておらず、携帯電話のブラウザから接続 するとエラーになります。携帯電話からのHTTPSアクセスが必要な場合には、StartCom社のサーバー 証明書では対応できません(2010年12月1日確認)。

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践

8.3 盗聴・改ざん対策

いろいろあるけど「中間者攻撃(Man in the Middle Attack)」で、去年のこれは衝撃的だった。

最近ではスマートデバイスのアプリケーションが、勝手に情報を送ってしまうケースが問題になっている。これも盗聴のひとつと言えるかもしれない。


8.4 マルウェア対策

Webサーバが感染しないように、Webサーバからマルウェアをばらまかないように気をつけよう。


8.5 まとめ

セキュアな状態を保つためには、継続的に対応していくことが大切だと思う。あと、常に対応し続けるのも難しいので、WAF(Web Application Firewall)を入れるなり、IDS(侵入検知システム)を入れるなりして、運用を楽にすることも大切だと思う。


第9章 安全なWebアプリケーションのための開発マネジメント

9.1 開発マネジメントにおけるセキュリティ施策の全体像

このあたりのことは、情処のセキュリティスペシャリストに出てくる内容に近い。上流からちゃんと考えましょう、という感じ。


9.2 開発体制

wasbookを読んだことのある人達でチームを組めたらいいな、と。


9.3 開発プロセス

発注側としてはこちらも参考になるかも。僕は読んでいないけど。


9.4 まとめ

セキュリティについて、しっかり考えてやりましょう。


まとめ

開発者としてのメインはやっぱり4章だったので、最後のほうは軽めに。

こんな本がでてくれて、ほんとうに助かる。僕は書籍版を買って、そのあと電子書籍版(PDF)も買った。それくらい価値があるし、よく使うと思った。家に書籍があって、普段使うMacBook AiriPadと会社のPCに電子書籍版がある。気になったらすぐに見れるし、PDFを検索できる。

これを読み終えるのは、正直けっこう大変だった。それでもエンジニアとして最低限知っておかなくてはいけないことばかりだった。

この本ではセキュリティを「体系的」に学べる。ま、読み終えてゴールでは全然なく、これを読み終えてある程度理解したところが、スタートなんだけど。セキュリティは難しい。でも避けては通れない。


wasbookに関するものは、こちらのタグで。


これまでののメモはこちら。


体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩
ソフトバンククリエイティブ
売り上げランキング: 3997


電子書籍版はこちら。

2012-01-20

[][]wasbook reading #11

「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」読書会の第11回。

今回読んだのは以下の範囲。

  • 7章 携帯電話向けWebアプリケーションの脆弱性対策
    • 7.1 携帯電話向けWebアプリケーションの技術的特徴
    • 7.2 携帯ブラウザの技術仕様
    • 7.3 かんたんログインの問題
    • 7.4 URL埋め込みのセッションIDによる問題
    • 7.5 その他の問題
    • 7.6 まとめ

7章 携帯電話向けWebアプリケーションの脆弱性対策

7.1 携帯電話向けWebアプリケーションの技術的特徴

携帯からのアクセスの場合、キャリアのゲートウェイからインターネットに接続される。ゲートウェイはプロキシのように動作し、WebサーバにはゲートウェイのIPアドレスが記録される。

ゲートウェイでは携帯IDの付与、クッキー保持、絵文字の変換などが行われる。

携帯のブラウザには機能制限がある。クッキーやJavaScriptが使えなかったり、いくつかのヘッダが制限されていたり。

携帯電話からのリクエストには、携帯ID(契約者固有ID、端末固有ID、個体識別ID、ケータイIDなどをまとめて携帯IDと記載する)が付く場合がある。


7.2 携帯ブラウザの技術仕様

キャリア毎にJavaScriptの制限が違っていて大変そう。

キャリア毎にCookieの制限が違っていて大変そう。


7.3 かんたんログインの問題

一定周期で話題になっているような気がする「かんたんログイン」。かんたんログインとは以下のような方法で実装されることが多いみたい。

  • 携帯電話からのアクセスであることを確認する
  • 利用者登録の際に携帯 ID を記録しておく
  • ログイン時には、携帯 ID を調べ、登録済み利用者が見つかれば認証成功とする

先に書いておくけど、携帯IDを利用したかんたんログインを安全に実装するのはすごく大変なので、やめたほうがいいと思う。


かんたんログインを安全に実現するには、「携帯電話からのアクセスであることを確認する」必要がある。これ、すごく難しい。

携帯IDを確認しても、それは偽装されているかもしれない。かんたんログインは携帯IDのみで認証成功とするので、携帯IDを偽装されるとなりすましができてしまう。

そのためにはリモートIPアドレスで確認する必要がある。

でもテザリング(携帯電話経由でのPCのインターネット利用など)している場合も携帯か判別する必要があるし、リクエストヘッダをJavaScript書き換えられる可能性もある。

じゃあどうするかというと、パスワードによる認証にして、ログイン状態の保持にはCookieを利用するのがよい。つまり普通の認証と同じように実装するということ。ユーザとしても、かんたんログインはなるべく利用しないようにしたい。


7.4 URL埋め込みのセッションIDによる問題

iモードではCookieが使えない時代がけっこう長かった。そんなわけで、URLにセッションIDを埋めこんだりすることもあったけど、これも危ない。

セッションIDの固定化や、セッションID付きのURLをだれかに教えてしまったりと。そうすると、意図せずなりすましになってしまうこともある。

対策としては、できる限りはCookieを使う、外部リンクにはクッションページをはさむ、ログイン後にセッションを開始する、といった方法がある。


7.5 その他の問題

普通のWebサイトと同様に、脆弱性対策を行う必要がある。


7.6 まとめ

Cookieに対応していない端末の対処が煩雑になりがちで、Cookieが使えないと認証とセッション管理に大きな影響があるので注意する必要がある。


まとめ

かんたんログインについては、こちらも読んでおきたい。

携帯電話のJavaScriptについては、こっちも読んでおきたい。

携帯(ガラケー/フィーチャーフォン)向けシステムの構築は難しい。僕がこれから新しく作ることはあまりなさそうだけど、こういった問題があることは十分に意識しておきたい。


wasbookに関するものは、こちらのタグで。


体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩
ソフトバンククリエイティブ
売り上げランキング: 3997


電子書籍版はこちら。

2012-01-15

[][]wasbook reading #10

「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」読書会の第10回。

今回読んだのは以下の範囲。


6章 文字コードと セキュリティ

6.1 文字コードとセキュリティの概要

僕はJavaを使う上で、何度か文字コードについて勉強したけど、ちょっと複雑でややこしい。まずはこれを意識する必要がある。

文字字コードとは、以下の2つの概念を合わせたものと考えられます。


6.2 文字集合

文字集合は、そのままだけど文字を集めたもの。厳密には、さらに符号をつけた文字集合のことを符号化文字集合という。本ではあわせて「文字集合」という用語で統一されている。

具体的にはASCIIとかISO-8859-1とかJIS X 0213とか。

そして文字に割り当てられたコードが、文字集合によってことなる場合がある。

ISO-8859-1およびUnicodeでは、0xA5の場所に円記号「\」が割り当てられていますが、日本 では歴史的にバックスラッシュの位置0x5Cに円記号「\」を割り当てていました。

¥や\は、プログラムで特別な意味を持つことがある。そこでエスケープ処理などが抜けると、脆弱性になってしまう可能性がある。


6.3 文字エンコーディング

次に文字エンコーディング。文字集合には符号がついているけど、いろいろな文字集合がある。そのため複数の文字集合を併用する必要がある。それをなんとかするために「文字エンコーディング」がある。

具体的にはShift_ JISやEUC-JP、UTF-16UTF-8とか。

繰り返しになってしまうけど、Unicode文字集合UTF-8は文字エンコーディングになる。

6.4 文字コードによる脆弱性の発生要因まとめ

文字コードごとに、それぞれ問題があるけど、まとめるとこんな感じ。


6.5 文字コードを正しく扱うために

以下のポイントが紹介されていた。

  • アプリケーション全体を通して文字集合を統一する
  • 入力時に不正な文字エンコーディングをエラーにする
  • 処理の中で文字エンコーディングを正しく扱う
  • 出力時に文字エンコーディングを正しく指定する

そもそも上記のようなことを意識しないと、文字化けに悩まされそう。最近はUTF-8に統一することが多くなってきたのでだいぶ楽になった。


6.6 まとめ

基本的に、文字列の入出力があるところでは、文字コードを意識する必要がある。開発では早めに文字コードを意識し、決めておく必要がある。


まとめ

サーバのOS、Webサーバで扱う文字コード、APサーバで扱う文字コード、DBサーバで扱う文字コードなどを確認し、統一できないのであれば早めに動作確認を行う。

wasbookの文字コードの章は、とてもよくまとまっていると感じた。分量がほどほどで、細かすぎることもなく、わかりやすかった。

あわせてこちらも読んでおくと、理解が深まると思う。(wasbookと使っている用語が異なるので、ちょっと混乱するかもしれないけど。)


wasbookに関するものは、こちらのタグで。


体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩
ソフトバンククリエイティブ
売り上げランキング: 3997


電子書籍版はこちら。

2011-12-24

[][]wasbook reading #9

「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」読書会の第9回。

年内の読了は絶望的に…。今回読んだのは以下の範囲。

  • 5章 代表的なセキュリティ機能
    • 5.2 アカウント管理
    • 5.3 認可
    • 5.4 ログ出力

5章 代表的なセキュリティ機能

5.2 アカウント管理

アカウントの管理は、セキュリティに直結する。そして面倒。以下のような注意点が挙げられていた。

  • メールアドレスの受信確認
  • ユーザ ID の重複防止
  • ユーザの自動登録への対処(任意)
  • パスワードに関する注意

最近だとメールアドレスを登録して、確認のメールが来て、そこにあるURLをクリックして、メールアドレスの確認を行うことが多い。

パスワードの変更は特に注意が必要だと思う。現在のパスワードを確認し、パスワードを変更した場合はメールで通知する必要がある。またパスワードを忘れるひとは必ずいるので、その場合もパスワードを変更する必要がある。正しい変更方法を考えるのは難しい。本書ではいくつかの方法が紹介されているので、実装することがあれば参考にしたい。これ、気を使うよね。


5.3 認可

認可によって、権限が与えられる。この画面を表示できるか、この機能を利用できるか、といったことは権限の有無で決まってくる。

やってはいけないのは、画面や機能へのリンクの表示を切り替えるだけのもの。権限によってリンクの表示/非表示が変わるけど、直接アクセスしてみるとちゃんと利用できてしまうようなもの。もちろん直接アクセスして使えないはずの機能が使えてしまうのはまずい。

というわけで、ちゃんとそれぞれの機能や画面で制御を行う必要がある。まずは以下の内容を確認することが重要になる。

  • このスクリプト(画面)を実行してよいユーザであるか
  • リソースに対する操作(参照、変更、削除など)の権限はあるか

5.4 ログ出力

なにか起きた時のために、ログは大切。でもあまり多く出てきても困るし、少なくても困る。

ここからさきは個人的な見解。

Webシステムであれば、アクセスログはしっかりだして、アプリケーションのログは少なめでもいいかなと。障害が発生した時、ピンポイントで原因のわかるログがでていたら嬉しいけど、そんなことはあまりないし、だったら少なめでいいかなと。

# 障害対応だと、日常的にスタックトレースがでているようなシステムも…

個人的には、ログ出力のレベルを簡単に切り替えられることが、けっこう重要だと思っている。なにか起きたら、多めにログをだすようにさくっと変えられる、とか。

そしてなにより、ちゃんとログの設計を行なっていることが大事だと思う。後回しにされていたり、適当になっていることも多そうなので。


まとめ

最近はOAuthやOpenIDで、認可や認証が行われることが多いけど、やっぱりユーザ管理を実装しなくてはならないこともある。ひとつ間違えると、非常に大きな問題になるので、しっかり設計して実装する必要がある。

また開発者の視点で考えると、どうやって実装するかも大事だけど、どうやってテストするかというのも大事だと思う。単純にログイン出来るかというだけでなく、アカウントロックされるか、パスワードはしっかり保護されているかといったことを十分に確認する必要がある。

ま、簡単には覚え切れないので、実装するときには読み返そうとおもう。


wasbookに関するものは、こちらのタグで。


体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩
ソフトバンククリエイティブ
売り上げランキング: 3997


電子書籍版はこちら。

2011-11-22

[][]wasbook reading #8

「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」読書会の第8回。

なんとか年内には…。今回読んだのは以下の範囲。

  • 5章 代表的なセキュリティ機能
    • 5.1 認証

5章 代表的なセキュリティ機能

5.1 認証

認証は、めんどう。正直あまり作りたくない。

認証に必要な機能って、認証だけじゃなくて、いろいろ必要になる。最低でもこれくらい。

  • ログイン
  • アカウントロック
  • パスワード保存
  • パスワード再発行
  • ログアウト

これらを正しく実装するのは大変。

  • ログインできないと認証機能ではない。
  • アカウントロックできないと、ブルートフォース攻撃で不正にログインされる可能性が高まる。
  • パスワードの保存にはソルトとストレッチングが必須。
  • パスワードの再発行(パスワードの変更)は、次回の部分で解説されているので割愛。
  • ログアウトではちゃんとセッションを破棄しなくてはならない。

総当り攻撃もいろいろあって、こんな感じ。

  • 辞書攻撃
  • ジョーアカウント探索(IDとパスワードが同じアカウント)
  • 逆総当たり攻撃(パスワードを固定して、IDを変えてアタック)
  • 変形総当たり攻撃への対策

パスワードは通常はハッシュ化されて格納されている。平文で入っているのは論外。

単純にハッシュ化されているだけでは、総当たりで解析されてしまう可能性が高いので、ソルトやストレッチングを行う。ソルトはパスワードに文字列を追加してからハッシュ化すること。ストレッチングはハッシュ化を複数回繰り返すこと。ソルトとストレッチングは実装が簡単で非常に効果的なので、パスワードを保存する場合には必ず実施したい。

自動ログインについては、難しいからちゃんと本文を読みましょう。

レインボーテーブルについては、いまひとつ理解しきれていない。レインボーテーブル自体は知っている、仕組みもなんとなくわかった。レインボーテーブル - Wikipedia も読んだ。

でもレインボーテーブル自体の実装と、検索方法がいまひとつ理解しきれていない。特定のハッシュが、どうやって見つかるのかがわからない。特に還元関数が実際にはどのような関数なのか、ぴんとこない。ハッシュ関数はなんとなくわかるんだけど。

このあたりは id:Kango が調べてくれるので、楽しみに待つ。


まとめ

最近はOAuthやOpenIDで、認可や認証が行われることが多いけど、やっぱりユーザ管理を実装しなくてはならないこともある。ひとつ間違えると、非常に大きな問題になるので、しっかり設計して実装する必要がある。

また開発者の視点で考えると、どうやって実装するかも大事だけど、どうやってテストするかというのも大事だと思う。単純にログイン出来るかというだけでなく、アカウントロックされるか、パスワードはしっかり保護されているかといったことを十分に確認する必要がある。

ま、いっぺんには覚え切れないので、実装するときには読み返そうとおもう。


wasbookに関するものは、こちらのタグで。


体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩
ソフトバンククリエイティブ
売り上げランキング: 3997


電子書籍版はこちら。