どうも、エンジニアのやまぐちです。 GW、終わってしまいましたね。
先日の社内勉強会で「安全なWebアプリケーションの作り方」を題材に基礎的なところを発表させていただいたのでその内容を少しだけ書かせていただこうと思います。
http://www.amazon.co.jp/%E4%BD%93%E7%B3%BB%E7%9A%84%E3%81%AB%E5%AD%A6%E3%81%B6-%E5%AE%89%E5%85%A8%E3%81%AAWeb%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9-%E8%84%86%E5%BC%B1%E6%80%A7%E3%81%8C%E7%94%9F%E3%81%BE%E3%82%8C%E3%82%8B%E5%8E%9F%E7%90%86%E3%81%A8%E5%AF%BE%E7%AD%96%E3%81%AE%E5%AE%9F%E8%B7%B5-%E5%BE%B3%E4%B8%B8-%E6%B5%A9/dp/4797361190www.amazon.co.jp
脆弱性とは
バグは常に発生しうるものですが、アプリケーションにバグがあると様々な悪影響が生じてしまいます。 その中でも悪用することのできるバグを脆弱性、またはセキュリティーバグと呼びます。 この脆弱性をついた攻撃をうけると個人情報の流出やWEBサイトの改ざん、ウィルス感染、なりすましといった悪用をされてしまいます。
脆弱性があると
では脆弱性を攻撃され悪用されるとどのような問題となるのでしょうか？
経済的損失
第一に考えられることとしては経済的な損失です。 損失内容としては利用者が損失した金額の補償や迷惑料などの費用、WEBサイトの停止による期間損失と信用失墜による売上の減少などが挙げられます。
- 利用者が損失した金銭の補償
- Webサイトの停止に伴う機会損失
- 信用失墜による売上の減少
法的問題
WEBサイトの安全対策を要求している法律として個人情報保護法というものがあります。 5,000件を超える個人情報を保持する事業者は個人情報取扱事業者として扱われますが、安全管理措置が義務づけられています。
第二十条 個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又はき損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。
当然5,000件未満の個人情報を保持している場合は適用されませんが、個人情報の漏えいに対するリスクが消えるわけではありません。
※ ここでの5,000件という数はあくまで目安だそうで詳しくは各省庁に聞くことをおすすめします
ボットネットワーク構築に荷担することにも
ボットネットワークとはボット(マルウェアの一種で、PCに感染すると外部から遠隔操作され様々な悪用に使われる)に感染したPCに外部から司令をだして一斉に攻撃を行わせるネットワークのことです。 つまり感染すると悪用の片棒を担がされる可能性があるということです。 仕掛けかたとしては脆弱性のあるサイトのコンテンツを改ざん、サイトを閲覧したユーザのPCにボットを感染させるよう組み込んでいます。
受動的攻撃と同一生成元ポリシー
悪意のある攻撃には能動的攻撃と受動的攻撃の2種類があります。
能動的攻撃
能動的な攻撃とは攻撃者がWEBサーバーに直接攻撃する手法です。 主な代表例としてはSQLインジェクションが挙げられます。
受動的攻撃
受動的な攻撃とは攻撃者がWEBサイトに罠を仕掛け、閲覧したユーザを通じてアプリケーションに攻撃する手法です。
受動的攻撃手法にはいくつか種類があります。
単純な攻撃
単純な攻撃手法としては怪しいサイトを閲覧してマルウェアに感染してしまうことですが、こちらはブラウザやプラグインに脆弱性がなければ成立しません。
罠による攻撃
正規サイトに罠を仕掛けるといった攻撃手法もあります。
手順としては攻撃者が予め正規サイトのコンテンツに罠を仕掛け、利用者が仕掛けを含むコンテンツを閲覧するとマルウェアに感染するという流れとなります。
こちらは単純な攻撃と違い手間はかかりますが、罠への誘導や被害の拡大化など攻撃者にとって大きなメリットがあるためよく使われます。
また、罠サイトを閲覧した利用者に仕掛けを施し正規サイトに攻撃のリクエストを送信するといった攻撃手法もあります。 こちらはログイン状態であればログインした状態での攻撃が可能となります。
ブラウザ側の対策
受動的攻撃にはWebサイトとブラウザそれぞれで対策が必要です。 Webサイトだけ脆弱性の対策してもブラウザ側に問題があれば安全は確保できません。 ブラウザ側では悪意のあるプログラムを動作させないように、安全性を高めるための機能を提供しています。 基本的な考え方はこの2種類になります。
- 利用者に配布元を確認させたうえで許可した場合のみ実行する
- プログラムを制限するサンドボックスという環境を用意する
前者はアプリケーションに用いるのに利用者の負担が大きいということからプラグイン提供に使われます。後者はサンドボックスという環境では制約があるため悪意のあるプログラムにより利用者へ被害が及ばないようになっています。
サンドボックス
サンドボックスとは外部から受けた司令を安全に動作させることで不正操作を防止するセキュリティのことで、以下の制限があります。
- ローカルファイルへのアクセス禁止
- 資源利用の禁止
- ネットワークアクセスの制限
ネットワークに関しては完全な禁止ではないですが厳しい制約があります。 この制約を同一生成元ポリシーと呼びます。
同一生成元ポリシー
サンドボックスに用意された制限の一つでJavaScriptによるサイトをまたがったアクセスを禁止する制限です。 異なるホスト間でJavaScriptアクセスができるとセキュリティ上問題となるので同一生成元ポリシーによりアクセスを拒否します。 同一生成元であると判断される条件は以下になります。
- ホストが一致
- プロトコルが一致
- ポート番号が一致
アプリケーション側の脆弱性による回避
上記で説明してきた様にブラウザ側には厳しい成約が設けられていますが、アプリケーション側に脆弱性があるとセキュリティを回避されてしまう可能性があります。
これはクロスサイト・スクリプション(XSS)など何らかの手法で内部からプログラムを実行されることで同一生成元であると判断され回避ができてしまうということです。
そのためブラウザ側もアプリケーション側にもセキュリティ対策は必須といえます。
まとめ
今回はセキュリティに関する基本的な内容でしたが、次回の勉強会で発表した際はもう少し内容のあるものを掲載したいと思います。
UUUMではエンジニアを絶賛募集中です。
我こそはという方、是非履歴書をUUUMまでお送りください。
※毎月29日は肉が食べ放題です
