このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

フォームからの書き込みのセキュリティ対策について

発言者:junnama
( Date Tuesday, April 11, 2000 22:44:39 )


Quid Pro Quo+MacOS9+ファイルメーカーでWebサーバーを構築中です。

この中に、フォームを使った書き込みを行なうcgiをいくつか動かす予定
なのですが、書き込むユーザーはあらかじめ決まっています。
閲覧は誰でも行えるようにします。

ファイルメーカーのWebコンパニオンは使いません。
Quid Pro Quoは1.0.2でadmin-pluginは外しています。

ファイアーウォールでhttpのポート80と8080に穴を空けており、いずれも
Quid Pro Quoで使用します。
又、SMTPでサーバーからメールを送信できるようにしています(送信のみ
で受信はできない)。

FTPやメールサーバー、DNSは動かしません。

cgiは全てAppleScript又はREALbasic製で、ファイルメーカーとのデータ
のやりとりはAppleScriptかAppleEventで(同じか...)行ないます。

それで、書き込みに関するセキュリティ対策として、以下のものを考えてい
ます。

1.書き込こみ関係のフォーム及びcgiがあるディレクトリへのID/Password制限
 (Quid Pro QuoのRelamの設定)

2.クライアント側のIPでの書き込み制限(クライアントはダイヤルアップ環
 境であるので、プロバイダーのIPでチェック。これはcgiの中でチェック。)

3.時間帯(夕方5時以降翌朝9時まで等、クライアント側の営業時間中に制限)
 の書き込み制限(cgiの中でチェック)

4.書込みのロック機能
 (書込み後、確定するcgiを実行すると、例えばファイルメーカーのフィー
  ルドがロックされる等のしくみ)

5.ID/Passwordの定期変更
  cgiでランダムに作成したID/PasswordをファイルにしてStaffIt
  でPassword制限を付けてメールに添付、クライアントへ送る。
  同時にAppleScriptでQuid Pro QuoのRelamの設定を変える

このうち、1,2,3は持たせる予定です。4,5については検討中なのですが、
他に何か見落としていることはないでしょうか。

また、この運用でセキュリティ的にはどの程度のレベルといえるのでしょうか。
(StaffItのPassword制限付きファイルの安全性はいか程のものなのかどな
 たか御存じありませんか?)


当然データベースはWeb公開領域の外に置きますし、パスワードファイルの
生成も Web公開領域外で行ないます。Macのファイル共有も動かしません。


田中求之 さんからのコメント
( Wednesday, April 12, 2000 00:08:41 )

何に対するセキュリティを最重視していますか?

1:特定の決められたメンバー以外は絶対に書き込みが行えないこと

2:書き込んだデータは絶対に他人に書き換えられないこと

この2つのどちらを重視するのか、あるいは両方なのか、によって
話は変わってきます(もちろん、他にも考えられます)。

セキュリティと言っても、色々なものに対するセキュリティがあるわけで、
何をポイントにするかをきちんと考えることが重要なわけですね。

石津@RJC さんからのコメント
( Wednesday, April 12, 2000 00:23:22 )

かなりセキュリティに配慮する必要があるシステムなのですね?

基本的には上記の内容であれば比較的安全だと思われます。
敢えて指摘するならば以下のような追加対策をするとより不正書き換えなど
セキュリティを強化するという意味では望ましいと思います。

1 WebサーバのREAMではなくCGIそのものに認証機能を組み込む。
2 認証機能で認証できたユーザにセッションIDを発行し、IPアドレスと
  セッションIDを一対にしてアクセス状態管理を行う。(CGIでやります)
3 NetBarrierを導入しIPspoofingなどの対策を行う。
4 レコード単位に編集削除権のためのパスフレーズ機能を組み込む。
5 定期変更機能はCGI認証機構の一部として組み込みにし、ファイルによる
  誤送信や複製の可能性を避ける。
6 WebStarサーバを利用して、デジタルIDを取得、SSL機能を利用する。

結局費用や使い勝手、開発期間との兼ね合いになるとは思いますが、ここまで
やればクラッキング対象にもならないでしょうし、なってもかなり安全だと
思います。1・2・4・5なんかはTango for FileMakerが利用できるととて
も簡単に機能追加できるんですけどね...。さすがに流通在庫も見なくなりま
したねぇ(T-T)。

あ、ちなみに書き換えについてはかなり安全だと思いますが、MacOSを利用し
ているという点で既に高負荷攻撃やDoS/DDoSに対してはぜい弱ですので、そ
の点は停止時間を短くするためのサーバの多重化やトラフィックディレクタ
の導入などの外的対策が必要ということもあるかもしれません。

junnama さんからのコメント
( Wednesday, April 12, 2000 01:06:43 )

田中先生のコメント

>1:特定の決められたメンバー以外は絶対に書き込みが行えないこと

まさにこれですね。書き込み(情報発信)の容易さとセキュリティの問題
はトレードオフの関係にあるわけで、書き込みやすければそれだけ甘くな
りがちだという認識は当然あります。

石津@RJC さんからのコメント
> 1 WebサーバのREAMではなくCGIそのものに認証機能を組み込む。
Quid Pro Quoでも可能でしょうか、というより Quid Pro Quoの REAM
には何か問題があるのでしょうか。

>3 NetBarrierを導入しIPspoofingなどの対策を行う。
これについては勉強してみます。

>6 WebStarサーバを利用して、デジタルIDを取得、SSL機能を利用する。
これはコストと時間の制約で難しそうなのですが、最終的には WebStar
(+SSL)を使いたいと思っています。

>Tango for FileMakerが利用できるととても簡単に機能追加できるんです
けどね...。

Tango は使ったことはありませんが、AppleEvent でやりとりしている限り
わりと安全だろうという認識を持っています。私にはAppleScriptがネイテ
ィブな言語ですから、これについてはただ頑張ってみようと思っている次第
です。

> 高負荷攻撃やDoS/DDoSに対してはぜい弱ですので

高負荷攻撃は考えないことにします。落ちることより書き換えられる方が恐
いというのが本音です。

石津@RJC さんからのコメント
( Wednesday, April 12, 2000 10:29:27 )

>Quid Pro Quoでも可能でしょうか、というより Quid Pro Quoの REAM
>には何か問題があるのでしょうか。

QPQだけでなくREAMの潜在的な問題なのですが、REAMでアクセス制限した
場合には認証後、全てのアクセスのhttpヘッダにUSER名が含まれてしまいま
す。httpのストリームは極めて読みやすいですし、それが1度だけでなく継
続したアクセスの最中ずっと含まれているならば、読み取られる可能性を高く
するということになります。logに残す設定をされている可能性もありますし。
IDとパスワードで制限している片方が既知となるならば、パスワードアタック
を容易にしてしまいますね。ですので、重要なセキュリティ案件であればREAM
を利用することはお勧めしません。

>これはコストと時間の制約で難しそうなのですが、最終的には WebStar
>(+SSL)を使いたいと思っています。

コストは確かに大きいんですよね...。以前は日本ベリサインしかデジタルIDの
選択肢がありませんでしたが、現在はSECOMがEntrustのデジタルIDの発行
代行サービスを行っており、ベリサインよりも20〜30%低価格でサービスを
行っていると記憶しています(ややうろ覚えですが...)。残念なのはWebStar
に対応していないことなのです。こうした選択肢がもっと増えてSSL利用が普
及するといいと思うのですが、なかなか難しいですね。

Tangoに限らずデータベースセッションをTCP/IPでない方式で行うというの
はセキュリティ上重要な方法のようです。IBMなどでも重要な案件ではデータ
ベースへの接続にSNAを使う方法をとっているようです。こうしたケースでは
データベースへアクセスするCGIやToolにセキュリティ上の問題がなければ
データベース単体ではほぼ完璧なリモート安全性が期待できると思います。
AppleEventを利用することは最も低価格で活用可能なデータベースアクセス
へのプロトコル変換技術だと思いますので、もっとこうした点は評価されても
いいのではないかと思っています。

>高負荷攻撃は考えないことにします。落ちることより書き換えられる方が恐
>いというのが本音です。

うちもこうした方針でやってきました(^^)。落ちることより、データを盗まれ
たり改竄されることの方が問題だと思ってきたのです。USArmyの事例のおか
げで理解を得られやすくはなりましたが、まだまだMacをサーバにするという
ことについては偏見はいっぱいありますね(苦笑)。
がんばってください。