セキュリティの仕組み(1)

共通科目情報処理（上級）、インターネットの仕組み、2006年01月31日

                                       電子・情報工学系
                                       新城 靖
                                       <yas@is.tsukuba.ac.jp>

このページは、次の URL にあります。
http://www.coins.tsukuba.ac.jp/~yas/ipe/inet-2005/2006-01-31
あるいは、次のページから手繰っていくこともできます。
http://www.coins.tsukuba.ac.jp/~yas/
http://www.cs.tsukuba.ac.jp/~yas/
http://www.ipe.tsukuba.ac.jp/~yshinjo/

■今日の重要な話

セキュリティ

アクセス制御
(暗号)
悪意のあるプログラム
クロスサイトスクリプティング攻撃
WWW ページに対するアクセス制御

■セキュリティ

セキュリティとは、安全や機密を保持すること。

対策

パタンマッチによる悪意のふるプログラムの検出
アクセス制御
暗号

◆通信路に対する脅威

インターネットの危険性

盗聴、窃盗
改ざん

インターネットでの通信は、暗号を使わない限り、流れるデータを見れば簡単に内容を知ることができる。（１つひとつのデータグラムは、はがきと同じ。）

◆悪意があるプログラム(malicious program)の分類

ローカル
- ウイルス
- トロイの木馬
- ワーム
遠隔のコンピュータ
- 悪意を持つクライアント
- 悪意を持つサーバ

◆コンピュータ・ウイルス(狭義)

コンピュータ・ウイルス(狭義)は、悪意があるプログラム一種で、次のような性質を持つもの。

他のプログラムに寄生する
悪さをする
自分自身のコピーを広げようとする

活動

感染
潜伏
発病

◆トロイの木馬とワーム

トロイの木馬(Trojan Horse)は、単独のプログラムであり、他のプログラムに寄生しない。利用者を騙して実行されるのを待つ。

ワーム(worm)は、他のプログラムに寄生しない。

世の中で「ウイルス」と呼んでいるものの中には、トロイやワームに分類されるものが多い。

◆ウイルス対策プログラム

ファイルや電子メールの内容を調べて、悪意のあるプログラムに特徴的なパタンを探し、削除する。

限界

パタンに含まれていない悪意のあるプログラムを見逃す。
- パタンファイルが古い場合
- 新しいプログラムでパタンファイルに未登録のもの
使っているプログラムのバクには対応できない。

◆バグ、弱点、攻撃

プログラムからバグ（誤り）を全てのバグを取り除くことはできない。バグの一部は、セキュリティ的な脆弱性につながる。

悪意のあるプログラムの多くは、セキュリティ的な脆弱性を攻撃する。

バッファ・オーバーフロー攻撃
クロスサイト・スクリプティング攻撃
DoS (Denial of Service) 攻撃、分散型DoS攻撃

「危険なデフォルト」は、本来の機能を有効にしたものなので、バグではないが、利用者が気が付かないと攻撃の対象になる。

◆バッファ・オーバーフロー攻撃

プログラムの脆弱性をつく攻撃の１つ。

現在のコンピュータは、機械語命令もデータも同じメモリに保存する。データを機械語命令だと解釈して実行することができる。

悪意を持つプログラムが送られて来た場合、本来はデータとして扱わなければならないのに、脆弱性があるプログラムは機械語命令として解釈して制御を移して実行してしまう。

◆DoS (Denial of Service) 攻撃

サーバにある種の要求を送ることで、本来のサーバの機能を停止させてしまう攻撃。サービス運用妨害、サービス拒否攻撃ともいう。

分類

バッファ・オーバーフロー等の脆弱性をついてサーバ・プログラムを終了させてしまうもの
大量に要求をサーバに送ることで、他の正当なクライアントに対するサービスができないようにする。

後者を防ぐことは、難しい。後者で、要求を送るプログラムが１つではなく、複数のクライアントが協調して１つのサーバを攻撃する場合、分散型DoS攻撃という。

攻撃対象としては、サーバ（ＷＷＷサーバ、メール・サーバ）の他に、ルータであることもある。

◆防御

ローカルで働く悪意があるプログラムによる被害をを防ぐには、ローカルへの侵入を水際で止める。

ローカルのプログラム
- 水際で防ぐ。特にトロイの木馬を入れないようにする。一度入られたら対策は難しい。
- リファレンスモニタによりプログラムの実行を監視する。疑わしい活動を検出したらプログラムの実行を停止する。
遠隔のコンピュータから送られてくるメッセージ
- 遠隔からの送られてくるメッセージを疑ってかかる。
- 通信相手のプログラムの場所により権限を変える。
- 通信相手のプログラムに付けられたディジタル署名により権限を変える。

弱い権限で動作させると、万一の時の被害を最小にできる。

遠隔のコンピュータ

悪意を持つクライアントからサーバを守る
悪意を持つサーバからクライアントを守る
第三のサーバ（クロスサイトスクリプティング攻撃）からクライアントを守る

◆個人で身を守る方法

技術者や管理者に求められていること。

技術、知識
倫理、道徳
甘く見ない

技術が未熟な現在、各個人は、ある程度、技術を知る必要がある。

キャッシュ
cookie
クロスサイトスクリプティング攻撃
サーバ上のファイルのアクセス権に気を付ける。
よいパスワードを使う
暗号を使う
大事なデータを、インターネットに接続されたコンピュータには置かない。
大事なデータを、電子メールで送らない。

対策

自分が使っているプログラムを最新のものにする。知られている脆弱性をつぶす。
付加的な追加プログラムを適切に使う。ただしそれだけに頼ってはいけない。
- ウイルス対策プログラム
- 防火壁

◆防火壁(ファイアウォール(firewall))

防火壁とは、外部のネットワークと内部のネットワークの間に設置し、内部のネットワークのセキュリティを高めるための仕組み。

インターネットの仕組みの基本：どのコンピュータとコンピュータも通信できる。

防火壁では、そのような本来の仕組みに制限を設け、特定のコンピュータとしか通信できないようにしたり、特定のサービスしかつかえないようにする。

攻撃の対象となるコンピュータの数を減らし、集中的に侵入対策を施すことで、セキュリティを高める。

防火壁構築は、様々な技術の集合：

パケット・フィルタリング: IPアドレスやポート番号を使ってTCP/IP の特定のサービスを特定の方向について遮断する。アクセス制御の一種。
例：ファイアウォールの内側から外側への電子メールの送信は許すが、逆方向は許さない。
プライベート・アドレスの利用: 壁の内側で、プライベート・アドレスと呼ばれる、インターネット上では決して利用されないことが保証されているIPアドレスを用いる。プライベート・アドレスを使うと、インターネットの外から直接攻撃されることはない。壁の外側をアクセスする時に、「壁の上」で、外でも通じるIPアドレスに付け変える。
電子メールのフィルタリング: 電子メールの内容をパタンマッチ等で検索し、悪意があるプログラムを発見したら削除する。

壁の上：壁の内側のコンピュータも壁の外側ののコンピュータも、両方にアクセスできる場所。

壁を越える時には、壁の上でWWW Proxy を動かすことがある。

■アクセス制御と認証

◆認証

認証とは、情報の正当性や完全性を確保する技術。

利用者認証: アクセスしている人物が本当にその人本人であるかを確認する。パスワードがよく使われる。
ディジタル署名: (人間を確認するのではなく、)送られてきたメッセージが送信者本人が出したものかを確認する。

◆利用者認証の例

顔パス
写真付きＩＤ
キャッシュカードと暗証番号
クレジット・カード番号と有効期限
ユーザ名とパスワード

◆アクセス制御

アクセス制御とは、ある主体（利用者）が、あるオブジェクトをいろいろな方法でアクセスする時、どんなアクセスの方法なら許されるかを決定し、それを強制的に守らせることである。

主体が人間の場合、利用者認証を済ませた後、それで得られた利用者の情報を使ってアクセス制御を行う。

図? アクセス制御における主体とオブジェクト

アクセス制御の３つの概念

主体(principal, subject(主語))。
- 利用者
- プロセス
- （クライアントの）ホストの名前、ＩＰアドレス
オブジェクト(object(目的語))
- ファイル
- ディレクトリ
- メールボックス
- WWW ページ、URL
- ・・・
操作(動詞)
- 読み
- 書き
- 実行
- 印刷
- リストの表示
- 削除
- 追加
- ・・・

アクセス制御の設定は、多くの場合、オブジェクト側で行う。

◆サーバ上のファイルに対するアクセス制御の設定

インターネット用のソフトウェアのセキュリティを守る場合、ネットワークを流れるデータだけでなく、サーバにたまっているデータにも気を付ける。

アクセス制御
バックアップ、特権ユーザ
アクセス・ログ

個人では、自刎のファイルのモード(ls -l の rwxrwxrwx の表示)に気を付ける。

電子メールなど、たとえ自分でしか読むことができないように設定されているファイル(モードが 600 (rw-------))であっても、サーバの管理者ならば、見ようと思えば見える状態になっている。バックアップ（器機の故障に備えてコピーを作る）のため。

◆ログ・ファイル

コンピュータの内部では、様々な操作のログ(log、航海日誌)がファイルに保存されている。

WWW でアクセスされた URL、接続元のIPアドレス、(Basic認証のユーザ名)
電子メールの送り手、受け手
ログインの時刻、接続元
実行したプログラムの名前

ログを保存する目的

トラブル対策
証拠保全
従業員の監視

ログのアクセス権に注意する。ログにアクセスできる人は、ログから他人の活動を知ることができる。

■WWWページにアクセス制御

WWWは、もともと大勢の人にメッセージを伝えるための仕組みだが、後付けでアクセス制御の仕組みを入れた。あるページは、ある特定の人（同じ研究室・部署の人）だけにしか見えないように設定することもできる。

WWW ページのアクセス制御では、主体としては、次のような使われる。

クライアントが動作しているホストの IP アドレス
ユーザ名とパスワード
(公開鍵暗号系で特定の秘密鍵を所有している利用者)

オブジェクトは、URL で指されるもの

Webページ
CGIのプログラム

アクセス制御の設定は、普通は、オブジェクト側でなされる。

WWWサーバの管理者
- /usr/local/etc/httpd/conf/httpd.conf
- (/usr/local/etc/httpd/conf/access.conf)
個人のページ
- .htaccess

access.conf は空で、全部 httpd.conf に書くことも多い。サーバの管理者は、.htaccess を無効にもできる。

◆IPアドレスやドメイン名によるアクセス制御

httpd.conf や .htaccess に次のように記述する。

order deny,allow
deny from all
allow from 130.158.0.0/16 133.51.0.0/16 192.50.17.0/24

主体

IP アドレス
ドメイン名

オブジェクト

ファイル
ディレクトリ
URL (location)

操作

GET
POST
その他(WebDAV などの拡張で他の命令がある)

◆WWW Basic認証

WWW ブラウザが１つのページをアクセスするたびに HTTP のヘッダにユーザ名とパスワードを含める。

◆WWW Basic認証の設定

例：パスワード・ファイル /home1/yshinjo/etc/passwd-doc1 に登録されているユーザだけが、 .htaccess があるディレクトリ以下にあるファイルをアクセスできる。

.htaccess:

AuthType Basic
AuthName "restricted stuff"
AuthUserFile /home1/yshinjo/etc/passwd-doc1
require valid-user

このパスワード・ファイルは、サーバ上で htpasswd というプログラムで作。

% /usr/local/apache/bin/htpasswd -c /home1/yshinjo/etc/passwd-doc1 user1 
Adding password for user1.
New password:user1のパスワードを打ち込む
Re-type new password:user1のパスワードを打ち込む
% /usr/local/apache/bin/htpasswd /home1/yshinjo/etc/passwd-doc1 user2 
Adding user user2
New password:user2のパスワードを打ち込む
Re-type new password:user2のパスワードを打ち込む
%

一番最初は、-c オプション付で実行する。passwd コマンドと同様に、打ち込んだパスワードは、画面には表示されず、また、確認のために２回打つ必要がある。

htpasswd コマンドの結果、次のようなファイルが作られる。

user1:1fjr1tHIgoG7U
user2:qXaeA9Zge7Yqc

ユーザ名と暗号化されたパスワード（正確にはパスワードのハッシュ値）から構成される。

パスワードによるアクセス制御の例: 設定ファイル .htaccess

AuthType Basic
AuthName "restricted stuff"
AuthUserFile /home1/yshinjo/etc/passwd-doc1
require valid-user

◆WWW Basic認証の動作

このアクセス制御が有効なファイルを GET したとする。

GET /dir1/file1.html HTTP/1.1

次のようなエラーが返る。


HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm="restricted stuff"
Content-Type: text/html

<HTML><HEAD>
<TITLE>401 Authorization Required</TITLE>
</HEAD><BODY>
...
</BODY></HTML>

.htaccess の AuthType と AuthName の内容が、HTTP の応答の WWW-Authenticate: に現れる。

このページをアクセスするには、クライアント(WWWブラウザ)は、ウインドウを開いてユーザにユーザ名とパスワードを要求する。そして、次のような GET() 要求をもう一度送る。

GET /dir1/file1.html HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Authorization: には、ユーザが打ち込んだユーザ名とパスワードが Base64 (64進数)で符合化されて含まれている。これを受け取ったサーバは、 AuthUserFile で指定されたファイルを開いて、ユーザ名とパスワードパスワードを照合して、正しければアクセスを許する。

Base64 は、暗号ではないので、簡単に元にもどせる。このアクセス制御の方法では、パスワードがそのままネットワークを流れてしまう。盗聴に弱い。


% echo QWxhZGRpbjpvcGVuIHNlc2FtZQ== | openssl base64 -d 
Aladdin:open sesame% 
%

■cookie

cookieは、コンピュータ・サイエンス（情報学類）の専門用語。

協調して動作しているプログラムの間で、ある一連の作業を識別するための数を意味する。

ＷＷＷ（World Wide Web）では、１回のデータ転送ごとに通信路が切断されるので、通常はＷＷＷのブラウザ（クライアント）とＷＷＷサーバの間では、途中経過を保持することができない。

途中経過を保存したい時：

パスワードを打って利用者を確認した
買い物かごの中身
ＩＰアドレスが毎回違うような場合、前回アクセスしてきた人を確認する

ＷＷＷで途中経過を保存するためには、cookie が使われる。

ＷＷＷサーバが、最初にアクセスした時に利用者ごとにクッキーを生成し、ブラウザに返す。
ブラウザは、返されたクッキーをファイルに保存しておく。
ブラウザは、次に同じサーバに要求を送る時に、ファイルに保存してあるクッキーを読み出して要求とともにサーバに送る。
要求を受け取ったサーバは、要求に含まれているクッキーから、そのブラウザを使っていた人が前回どのページを訪れたかを知ることができる。

サーバは、その情報を利用して、適切なページ（たとえば前回最後に訪れたページ）を表示させるようにすることができる。

◆WWW cookieの例

RFC2965より。以下の User Agent は、WWW ブラウザと思ってよい。

4.  EXAMPLES

4.1  Example 1

   Most detail of request and response headers has been omitted.  Assume
   the user agent has no stored cookies.

      1. User Agent -> Server

        POST /acme/login HTTP/1.1
        [form data]

        User identifies self via a form.

      2. Server -> User Agent

        HTTP/1.1 200 OK
        Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"

        Cookie reflects user's identity.

      3. User Agent -> Server

        POST /acme/pickitem HTTP/1.1
        Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
        [form data]

        User selects an item for "shopping basket".

      4. Server -> User Agent

        HTTP/1.1 200 OK
        Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
                Path="/acme"

        Shopping basket contains an item.

      5. User Agent -> Server

        POST /acme/shipping HTTP/1.1
        Cookie: $Version="1";
                Customer="WILE_E_COYOTE"; $Path="/acme";
                Part_Number="Rocket_Launcher_0001"; $Path="/acme"
        [form data]

        User selects shipping method from form.

      6. Server -> User Agent

        HTTP/1.1 200 OK
        Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme"

        New cookie reflects shipping method.

      7. User Agent -> Server

        POST /acme/process HTTP/1.1
        Cookie: $Version="1";
                Customer="WILE_E_COYOTE"; $Path="/acme";
                Part_Number="Rocket_Launcher_0001"; $Path="/acme";
                Shipping="FedEx"; $Path="/acme"
        [form data]

        User chooses to process order.

      8. Server -> User Agent

        HTTP/1.1 200 OK

        Transaction is complete.

   The user agent makes a series of requests on the origin server, after
   each of which it receives a new cookie.  All the cookies have the
   same Path attribute and (default) domain.  Because the request-URIs
   all path-match /acme, the Path attribute of each cookie, each request
   contains all the cookies received so far.

◆cookieとプライバシ

現在の cookie の実現では、利用者のプライバシーを犯す危険性が高いという問題が指摘されている。

普通のＷＷＷサーバでは、要求を送ってきたコンピュータのＩＰアドレスを記録しているので、コンピュータ単位でのアクセス状況を記録することはできるが、個人を特定することはできない。

クッキーを利用することにより、コンピュータではなくどの個人がアクセスしてきたかを記録することができる。

クッキーから電子メールのアドレスや氏名まで調べることはできない。しかし、インターネットをサーフしている間にどこかでそれを打ち込んだが最後、クッキーと電子メール・アドレスや氏名との対応が記録されてしまう危険性がある。

参考

RFC2965 HTTP State Management Mechanism
Netscape社によるＷＷＷにおけるクッキー実現の案
http://wp.netscape.com/newsref/std/cookie_spec.html

◆JavaScriptによるクッキーのアクセス

クッキーは、JavaScript のプログラムからアクセスできる。悪意のある JavaScript を実行してしまうと、クッキーが盗まれる。

■JavaScriptとクロスサイトスクリプティング攻撃

◆JavaScript

JavaScript は、 WWW ページを作る時に使われるスクリプト言語である。

ブラウザを制御する仕組みが、悪用される。 JavaScrit は、信頼しているサイトから送られたときだけ有効にする方法がある。

◆クロスサイトスクリプティング攻撃

WWWブラウザでは、信頼しているサイトから送られてくるJavaScriptのプログラムだけを実行するようにし、攻撃サイトから送られてくるJavaScriptのプログラムを実行しないようにしたい。

図? JavaScripの送信元サイトの区別

脆弱性があるサイトでは、攻撃サイトから送られてきた JavaScript のプログラムを中継してしまう。

図? JavaScripの送信元サイトの区別

これがクロスサイトスクリプティング攻撃(cross-site scripting atack, XSS atack)である。

CGI のプログラムをつくる時には、クロスサイトスクリプティング攻撃に気をつける。これは、クライアントから送られてる文字列の中に <SCRIPT>のようなタグが含まれていた場合、それをそのままクライアントに送り返すと問題がある。

さらに、%hhにも気をつける必要がある。送られてくるパラメタの中に漢字、 (&自身)、 URLで使えない文字が含まれていた場合、「%hh( hh は2桁の16進数)」という形になっている。

◆基本的な対策

クライアントから送られてきた文字列は、必ず検査し、安全な状態にして (sanitize)から使う。「<>&"」のようなタグが含まれている場合には注意する。このような文字列を受け取った場合、不用意に送り返してはいけない。送り返す時には、必ずエスケープする。

----------------------------------------------------------------------
画面表示	代りに送りだす文字列
&		&amp;
<		&lt;
>		&gt;
"		&quot;
----------------------------------------------------------------------

◆Phishing

フィッシング(phishing)とは、インターネット詐欺師がインターネット・ユーザから疑似餌を使ってユーザのパスワードやクレジットカード番号等をつり上げる行為を指す。

もとは、fishing の意味だが、 f を ph と綴る。これは、 crackerの伝統。

http://www.antiphishing.org/word_phish.html

クロスサイト・スクプリィング攻撃に対して脆弱性があるＷＷＷでは、フィッシング詐欺に対して弱い。

ヤフーからの通知を装った日本語フィッシングで何が起きていたか

■CGIの注意事項

クロスサイト・スクリプティング攻撃に対する脆弱性がないようにする
意図していないプログラムを実行しないようにする。

他のプログラムを実行する時には、execve() のようなシステムコールを使い、かつ、限られたプログラムしか実行しないようにすると安全性が高くなる。クライアントから送られてきた文字列をsystem() や popen() に渡してプログラムを実行する時には、必ず検査する。特にシェルが解釈する特殊な文字「| & ; && || `」などが含まれていた場合、意図しないプログラムが実行されることがある。

char *user ;
...
snprintf(cmd,BUFSIZE,"finger %s",user );
f = poepn(cmd,"r");

もし、user に ";" や "|" が含まれていたら、、、　

f = poepn("finger yas; /bin/sh","r");

◆他のプログラムの実行(Perl言語)

Perl には、バッファ・オーバーフローの問題はない。

perl の open() には、危険性がある。 C 言語のライブラリ関数 popen() と同じ動きをすることがある。

open(FILE, "|cmd")

Perl の危険な関数、式、

open
system, exec, ``(バック・クォート)
glob, <>
eval

■参考

産業技術総合研究所グリッド研究センターセキュアプログラミングチーム
http://securit.gtrc.aist.go.jp/ )

IPA セキュア・プログラミング講座
http://www.ipa.go.jp/security/awareness/vendor/programming/

■実習

◆WWW ブラウザの cookie の状態

WWW ブラウザが、cookie をどのように扱う状態になっているかを調べなさい。 cookie を受け付けないように設定してみなさい。

Netscape/Mozillaの場合

「編集」メニューの「設定」項目を選ぶ。
「プライバシーとセキュリティ」の三角を選んで項目を展開する。
「Cookie」項目を選択する。ここで受入れ方法の設定が変更できる。
「保存された Cookie を管理」で「Cookieマネージャ」を実行できる。あるいは、「ツール」メニューから「Cookieマネージャ」を選ぶ。

ブラウザを終了しても残るクッキーは、プロファイルの下の cookies.txt というファイルに保存される。Windows の場合、次のような名前になっていることが多い。 C:\Documents and Settings\name\Application Data\Mozilla\Profiles\profname\random\cookies.txt \ は、「＼」、または、「￥」と表示される。