共通科目情報処理（上級）、インターネットの仕組み、2004年02月02日
電子・情報工学系
新城 靖
<yas@is.tsukuba.ac.jp>
このページは、次の URL にあります。
http://www.coins.tsukuba.ac.jp/~yas/ipe/inet-2003/2004-02-02
あるいは、次のページから手繰っていくこともできます。
http://www.coins.tsukuba.ac.jp/~yas/ipe/
http://www.coins.tsukuba.ac.jp/~yas/
http://www.ipe.tsukuba.ac.jp/~yshinjo/
個人では、自刎のファイルのモード(ls -l の rwxrwxrwx の表示)に気を付け る。
電子メールなど、たとえ自分でしか読むことができないように設定されている ファイル(モードが 600 (rw-------))であっても、サーバの管理者ならば、見 ようと思えば見える状態になっている。バックアップ（器機の故障に備えてコ ピーを作る）のため。
コンピュータの内部では、様々な操作のログ(log、航海日誌)が取られている。
インターネットの危険性
インターネットでの通信は、暗号化されていない。 （１つひとつのデータグラムは、はがきと同じ。） 流れるデータを見れば簡単に内容を知ることができる。
インターネットで通信する時には、通信相手に IP アドレスが渡されている。 （電子メールを送る時、ＷＷＷでページを見る時など）
電話でいうと、発信者番号(caller ID)が相手に伝わっている状態である。
IP アドレスから、コンピュータの名前（ドメイン名）を調べることができる （逆引）。
普通は、利用者の名前までは、わからない。しかし、ユーザ名とパスワードを 打った時にはログと付き合わせると、利用者が特定可能である場合が多い。
インターネットの仕組みの基本：どのコンピュータとコンピュータも通信できる。
防火壁では、そのような本来の仕組みに制限を設け、特定のコンピュータとし か通信できないようにしたり、特定のサービスしかつかえないようにする。
攻撃の対象となるコンピュータの数を減らし、集中的に侵入対策を施すことで、 セキュリティを高める。
防火壁構築は、様々な技術の集合：
2000年5月1日に、筑波大学の入り口でパケット・フィルタを行うようになった。
壁を越える時には、壁の上で WWW Proxy を動かすことがある。
活動
ワーム(worm)は、他のプログラムに寄生しない。
世の中で「ウイルス」と呼んでいるものの中には、トロイやワームに分類され るものが多い。
危険性
技術者や管理者に求められていること。
協調して動作しているプログラムの間で、ある一連の作業を識別するための数 を意味する。
ＷＷＷ（World Wide Web）では、１回のデータ転送ごとに通信路が切断される ので、通常はＷＷＷのブラウザ（クライアント）とＷＷＷサーバの間では、途 中経過を保持することができない。
途中経過を保存したい時：
ＷＷＷで途中経過を保存するためには、cookie が使われる。
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.
普通のＷＷＷサーバでは、要求を送ってきたコンピュータのＩＰアドレスを記 録しているので、コンピュータ単位でのアクセス状況を記録することはできる が、個人を特定することはできない。
クッキーを利用することにより、コンピュータではなくどの個人がアクセスし てきたかを記録することができる。
クッキーから電子メールのアドレスや氏名まで調べることはできない。 しかし、インターネットをサーフしている間にどこかでそれを打ち込んだが最 後、クッキーと電子メール・アドレスや氏名との対応が記録されてしまう危険 性がある。
参考
RFC2965 HTTP State Management Mechanism
Netscape社によるＷＷＷにおけるクッキー実現の案
http://wp.netscape.com/newsref/std/cookie_spec.html
ブラウザで実行される。
JavaScript は、文法こそ少し Java に似ているが、Java とはまったく別の 言語である。WWW ページの中の Javaアプレットは、 「実行可能なインライン・イメージ」に似ているが、JavaScript の記 述は、「実行可能なインライン・テキスト」に似ている。たとえば、次 の例を考える。
<SCRIPT LANGUAGE="JavaScript">
<!--
for( i=0 ; i<10; i++ )
document.writeln("<P>hello,world</P>");
//-->
</SCRIPT>
これで、<P>hello,world</P> を 10 回書いた
のと同じ効果がある。<!--と
//->は、JavaScriptを知らないブラウザにはコメント
として扱われる決まり文句である。関数定義などは、ヘッダ部分
<HEAD></HEAD>に書くという方法もよく使われる。
JavaScript は、CGI と似ているところもあるが、JavaScript でないとで
きないものに、ブラウザの制御がある。たとえば、次の例では、ブラウザ
の(戻る)ボタンと同じ動きをさせることができる。
<A HREF="javascript:history.back();">戻る</A>戻る
ブラウザを制御する仕組みが、悪用される。
JavaScrit は、信頼しているサイトから送られたときだけ有効にする方法がある。
CGI のプログラムをつくる時には、クロスサイトスクリプティング攻撃 (cross-site scripting atack, XSS atack)に気をつける。これは、クライア ントが送られてる文字列の中に<SCRIPT>のようなタグが含まれて いた場合、それをそのままクライアントに送り返すと、 クライアントで JavaScriptなどの ブラウザ上で動作するスクリプト言語が実行されることがある。 自分自身のサイトにあるフォームにはそのような問題がないとしても、 別のサイト（クロスサイト）に仕組まれたフォームからスクリプトが 含まれていることもある。
利用者が信頼していると設定しているホストにクロスサイトスクリプティング 攻撃への脆弱性があると、悪意をもった別のサイトから危険なスクリプトを実 行させることができる。
このような脆弱性があると、そのサイトの信頼性がなくなる。 利用者のクレジットカード番号などが盗まれることになる。
クライアントから送られてきた文字列は、必ず検査してから使う。
クライアントから送られてきたデータの中に「<>」のようなタグ がないかどうかを調べる。不用意に同じ文字列をクライアントに送り返しては いけない。特に次のような文字は、送り返す時には、必ずエスケープする。
---------------------------------------------------------------------- 画面表示 代りに送りだす文字列 & & < < > > " " ----------------------------------------------------------------------場合によっては、大事なデータを送信する前に、そのサイトにクロスサイトス クリプティング攻撃に対する脆弱性がないかどうか調べる。
他のプログラムを実行する時には、execve() のようなシステムコールを使い、
かつ、限られたプログラムしか実行しないようにすると安全性が高くなる。ク
ライアントから送られてきた文字列をsystem() や popen() に渡してプログラ
ムを実行する時には、必ず検査する。特にシェルが解釈する特殊な文字
「| & ; && || `」などが含
まれていた場合、意図しないプログラムが実行されることがある。
もし、user にchar *user ; ... snprintf(cmd,BUFSIZE,"finger %s",user ); f = poepn(cmd,"r");
";" や "|" が含まれていたら、、、
f = poepn("finger yas; /bin/sh","r");
perl の open() には、危険性がある。 C 言語のライブラリ関数 popen() と同じ動きをすることがある。
Perl の危険な関数、式、open(FILE, "|cmd")
アクセス制御(access control) ユーザ(アクセスの主体) が、ファイルやWWWページなどの資源をアクセスする時、どんな アクセスの仕方なら正しいということを定義して、それがきちんと守られてい ることをということを保証すること。
WWW ページのアクセス制御は、次のような情報がよく使われる。
アクセス制御は、基本的には、
WWWサーバの管理者の仕事。
WWWサーバ (httpd) の設定ファイル
(
/usr/local/etc/httpd/conf/httpd.conf,
/usr/local/etc/httpd/conf/access.conf
)
に記述される。
個人のページについては、
.htaccess
というファイルを作れば、個人で変更できるようになっている場合がある。
.htaccess: ---------------------------------------------------------------------- order deny,allow deny from all allow from 130.158.0.0/16 133.51.0.0/16 192.50.17.0/24 ----------------------------------------------------------------------
例：パスワード・ファイル
/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 user1Adding password for user1. New password:user1のパスワードを打ち込む
----------------------------------------------------------------------
-c オプション付で実行する。passwd コマ
ンドと同様に、打ち込んだパスワードは、画面には表示されず、また、確
認のために２回打つ必要がある。
htpasswd コマンドの結果、次のようなファイルが作られる。
ユーザ名と暗号化されたパスワードから構成される。---------------------------------------------------------------------- user1:1fjr1tHIgoG7U user2:qXaeA9Zge7Yqc ----------------------------------------------------------------------
パスワードによるアクセス制御の例:
設定ファイル .htaccess
---------------------------------------------------------------------- AuthType Basic AuthName "restricted stuff" AuthUserFile /home1/yshinjo/etc/passwd-doc1 require valid-user ----------------------------------------------------------------------このアクセス制御が有効なファイルを 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ブラウザ)は、 ウインドウを開いて ユーザにユーザ名とパスワードを要求する。 そして、次のような YHM_GET() 要求をもう一度送る。
GET /dir1/file1.html HTTP/1.1
Authorization: には、ユーザが打ち込んだユーザ名とパスワードが
Base64 (64進数)で符合化されて含まれている。
これを受け取ったサーバは、
AuthUserFile で指定されたファイルを開いて、ユーザ名とパスワー
ドパスワードを照合して、正しければアクセスを許する。
Base64 は、暗号ではないので、簡単に元にもどせる。このアクセス制御の方 法では、パスワードがそのままネットワークを流れてしまう。盗聴に弱い。
% echo QWxhZGRpbjpvcGVuIHNlc2FtZQ== | openssl base64 -d
産業技術総合研究所 グリッド研究センター セキュアプログラミングチーム
http://securit.etl.go.jp/
)
IPA セキュア・プログラミング講座
http://www.ipa.go.jp/security/awareness/vendor/programming/
