WEBセキュリティ

WEBセキュリティ

羽室 英太郎.情報セキュリティ入門.第3版,東京,慶應義塾大学出版会,2014,379p.

1.webサイトのセキュリティとは

非武装地帯

数年前まで

->攻撃が内部まで侵入しないよう非武装地域(DMS:DeMilitarixed Zone)を設けていた
(ここに外部公開用のサーバなどを設置し,内部LANとファイアウォールによって隔離する)

といった物理的方式が一般的だった.

攻撃:サーバやOSを狙ったもの

現在

様々なサービスのポータルとなった今,個人情報などのデータベースとの密接な連携

->webを経由するサービスを処理するwebアプリへの攻撃

-->webサイトへの脅威の中心

脅威への対策

  • 入力データの確認
  • アクセスコントロール
  • セッション管理
  • エラー処理

->個々のwebサイト毎に行い,webアプリケーション全体で十分なチェックが行われていなければ,ファイアウォールすり抜けられる可能性

対策として

  • 攻撃手法や脅威の理解
  • WAF(webアプリケーション・ファイアウォール)の導入
  • 適切なセッション管理
  • 認証技術の高度化

体制の構築

脅威の直接の対象->webアプリ
クラッカーの狙い->データベース

セキュリティ=技術的=企業の営利活動に比較して瑣末なのでは(?)

サイト全体のセキュリティ

情報セキュリティポリシーの策定
それに伴って..基づく体制の確保,対策推進

->サイバー攻撃・ウイルス・DoS攻撃(意図的脅威),自然災害(環境的脅威),アウトソーシングなど事業形態の変化に伴う構造的な脅威(非意図的要因)を考慮

2.webアプリケーションとは

利用環境

端末側のOSの影響を受けない(クロスプラットフォーム)ブラウザとインターネット接続環境が必要

webアプリの高速化

WEB2.0 -> WEB3.0

セマンティック・ウェブ(Semantic Web:webページに有意性を持たせることによる効率化)

マッシュアップ(各種webサービスの融合)

->webページを華麗に彩るだけでなく様々なアプリやクラウドサービスの提供の高度化

->プログラミング技術などの複雑化

基本:webアプリの開発->MVC(Model-View-Controller)フレームワーク

最近:Ajax(Asynchronous JavaScript + XML)やHTML5,DOM(Document Object Model)

セッションとは

セッション:ユーザがリクエストした内容に対応するサーバがリプライを送る一連の流れ

e.g. ~~~~~~~~~
ユーザ:ネットショッピングにおいてログイン(id + pass),注文,支払い手段,届け先->リクエスト
サーバ:リクエスト
~~~~~~~~

ウェブアプリが狙われるのは

セッションをユーザごとに区別するために番号を付して管理

->セッション管理が定型的なら攻撃対象に

3.webに対する攻撃の進化

攻撃対象・手法の進化

現在の攻撃手法 - 従来型のサーバに対する攻撃手法 - セッションハイジャック,SQLiなどwebアプリの設定ミスや不具合を利用 - 会社のサーバを攻撃->ターゲットのサーバに侵入 - 難攻不落のサーバに侵入するよりは..制作会社や保守管理用コンソールをウイルスに感染させ,ターゲットに侵入

->踏み台にしたりクロスサイトからツールを持ってきたり..etc.
-->一般ユーザに実行させるスクリプトを潜ませておいて,誘導されたユーザに攻撃させる
--->ユーザのクッキーやアカウント情報を抜き取ることも可能

検索エンジンの活用

大手検索エンジンを利用して,セキュリティ技術情報を収集したり,脆弱性を有するサイトを抽出する
->Googleハッキングなど
-->見つけたサイトにマルウェアなどをばら撒き,サーバに侵入してバックドアを仕掛けたり,用意したマルウェアの本体を入れたり.
ボットネットもこのような手法を用いてボット化したものが多い

4.セッション管理とは

インターネット上でショッピングをしたり,購入時に必要な一連の画面遷移の流れ->セッション
管理する手法は,サーバとユーザのブラウザが相互に認証する手法でもある.

画面が変わるたびに一連の顧客番号などを入力するのは面倒
->番号に代わる目印をどこかに埋め込み.認証情報を保持する仕組み

  1. hiddenパラメータを活用した方法
  2. 直接URLパラメータとして記入する方法(URLライティング)
  3. Cookieを利用する方法

1. hiddenパラメータを用いる方法

hiddenパラメータ->HTMLの文書の見えない領域に記載する方法

e.g.~~~~~~~~~
<\input type="hidden" name="sessionID" value="0001">\
.~~~~~~~~~~~~~
-> これだとソースで判読されて,コピーされたり,適当な値でセッションが乗っ取られる

2. URLライティング方式

URLに文字列を追加し,セッションIDを記述する方式

JAVAやPHPなどの言語で,その書き換え(リライティング)方法が決められている

e.g.~~~~~~~~~
<\a href="Index.html;sessionID=0001">......<\/a>\
.~~~~~~~~~~~~~

->他人がこのID番号を使ったり,IDを類推することで乗っ取られる

3. Cookieを利用する方法

Cookieは画面表示設定情報などをサーバ側で把握する以外に,webサイトを過去に訪れたことがあるのか,あるならば何回アクセスしたかなど,サーバ側の端末で利用状況を把握するアクセス解析に使用されることが多い.

長い有効期限が設定されている固定値のCookieをセッション管理に利用すると,盗聴などによる「なりすまし」や「セッションハイジャック」が行われる可能性

->セッションIDには単純な番号や日時,IDなどを利用したものを使用せず,有効期限もログアウト時にはきちんとクリアされ,適切なログアウト処理が行われなかった場合でも速やかに破棄するように設定しておく必要性

2038年問題

セッションに関する攻撃

  • セッションハイジャック
  • セッションフィクセーション
  • XSS
  • CSRF

5.セッションハイジャックとは

以上のような手法で得たセッション番号をそのまま使用したり,生成番号を類推することで「セッション」の乗っ取りを行うこと

盗聴対策

適切な暗号化などにより通信路が保護されていないセキュアでない場合,クラッカーが通信路を盗聴すれば,Cookieや個人情報を入手することは容易

SSLを用いて通信路を保護することが必要.


SSL 以下6章16 SSL

SSL ->Secure Socket Layerの略.
コンピュータの処理において,異なるアプリケーション(プロセス)間の通信(ソケット層)を,暗号化手法などを活用してセキュアに行うもの.
IPアドレス,プロトコル,ポート番号を指定して利用する.

e.g.~~~~~~~~~
http(Hypertext Transfer Protocol)-> 80番ポート

https(Hypertext Transfer Protocol over SSL/TLS)-> 443番ポート
.~~~~~~~~~~~~

公開鍵により共通鍵を暗号化して配送する仕組み

共通鍵と公開鍵の暗号方式の原理について

共通鍵->秘密鍵, 対称鍵とも

暗号化と復号化に使用する鍵が同じもの

->これを利用した暗号方式->慣用暗号方式
 ->送受信相手が固定されていて同じ"鍵"を保有している場合, 簡単でわかりやすい暗号化手法
 ->鍵を入手すれば第三者でも容易に暗号文が解読可能

一方, 公開鍵

公開鍵

「錠前と鍵」のように一対の"鍵"の組み合わせを作り, 暗号化と復号化の役目を分担させている暗号化手法

公開鍵の数学的理論については後にまとめる

->公開鍵を公開しても容易には秘密鍵を求められない
->乱数発生方法, パスフレーズなどが既知であれば, 公開鍵から秘密鍵を算出することが可能

鍵の配送について

SSLでは, 基本的には共通鍵により暗号化を行い通信を行うが,
その共通鍵を安全に配送(通信相手と共有)するために, セッション毎に
サーバ側の公開鍵を用いて暗号化を行ってサーバ側に配送することで
当該ユーザとサーバのみが解読可能な共通鍵(セッション鍵)でデータを暗号化して通信を行う

この際, サーバ側が適切な暗号化措置を行っていることを証明するために,
公開鍵が含まれている「サーバ証明書」をユーザに送付する

SSLに関する規格(IETF)は - TLS(Tranceport Layer Secrity)1.0 -> RFC2246 - TLS1.1 -> RFC4346 - TLS1.2 -> RFC5246

で規程されているが, 用語的には"SSL"や"SSL/TLS"と呼ばれる.


しかし, SSL(HTTPS)を用いているからといって安心できるわけではない
Cookieの発行時にはセキュアという属性をセットすることが可能
->この設定を怠るとCookieが流れる(非暗号(HTTP)通信も)

->属性をsecureに設定

HTTPSとHTTP両方でCookieを使う場合, それぞれ別のCookieを使う

Cookieを見る

Firefox -> Live HTTP Headers

最近のサイトはサーバと端末側で複数回往復して複雑な演算等を行わせて認証を行う
->チャレンジ・アンド・レスポンス方式
-->USBメモリやSDカードなどのトークンを用いないトークンレス認証の一種.サーバ側から投げられた質問(チャレンジ)に対し,適切な回答(レスポンス)を行うことで正当なユーザと認めてもらう

->盗聴されても簡単にセッションIDが類推されない

プログラムに備わるセッション番号を発生させる関数を古い状態のまま使うとダメ
->暗号号理論に基づいてハッシュ値を生成させているもののMD5などの古い暗号化アルゴリスムを使用してたりすると危険

6.セッションフィクセーション

ハイジャックとの違い

fixation = 固定
->セッションが固定されているために攻撃される

サーバとクライアント間でセッションが確立された状態で,盗聴やセッション番号の類推により横入り
->セッションハイジャック

セッション番号を攻撃者が用意してそれを利用者に使わせる
->セッションフィクセーション

攻撃の仕組み

攻撃者があらかじめセッションIDを用意
本物のサイトに似たサイトを用意
HTMLメールなどを被害者に送付
リンクを踏むとセットされていたセッションを奪われる
偽サイトから発行されたセッションIDを真正サイトが受理してしまうと攻撃者が被害者になりすましてアクセスできるように

->他ドメインのセッションIDを受理する,セッションの有効期限が長い・ログインした後に変化しない,ことが攻撃の背景

  • 自ドメインが発行したセッションID(Cookie)かどうかチェックして,他のものを受け取らない
  • 有効期限を短く設定
  • 二重ログインの禁止

セッションリプレイ

盗聴やXSSにより正当なユーザのセッションIDが再利用されることがある.

7.XSS

Go Top