ホーム >> 左脳Script >> linux >> Webサーバへの攻撃とは?

Webサーバへの攻撃とは?


自作のWebサーバ(mattowsレベル)を外向けに公開出来るレベルにするには、どのような攻撃に備えておくべきなのか、調査してみました。

Web開発におけるセキュリティというと、大変広範囲で山ほどの事例、山ほどの対策が必要になってしまいます。しかし、その中で「実際にWebサーバがやらなければならない対策」はどの程度なのでしょうか。

Webサーバが対処すべき攻撃

ここでは「Webサーバ」が直接係わり対策しなければならないものに限定してみます。
Webサーバ以外に穴は無い理想的な環境を想定し、Webサーバが対策すべき事を挙げてみました。

Source Disclosure問題
「URLに対して特定のパスや文字列を追加すると、Webアプリケーションのソースファイル自体がWebブラウザに送信され、許可されていないユーザーがプログラムを参照することができてしまうという問題である。」
→引用:http://www.atmarkit.co.jp/fsecurity/rensai/web02/web01.html

Unicode Decode問題
URLに不正なUnicodeを含めることで、本来の動作とは異なる動作を起こさせる問題である。
→引用:http://www.atmarkit.co.jp/fsecurity/rensai/web02/web01.html

バッファオーバーフロー攻撃
とても長いURLリクエストで、Webサーバのコマンドバッファを溢れさせ、不正な動作を誘うものである。
→参照:http://www.atmarkit.co.jp/fsecurity/rensai/handling01/handling01.html

ディレクトリトラバーサル
HTTPリクエストで要求するhtmlファイルやCGIファイルのパスに、相対指定(「../」等)、絶対指定などで、 本来公開されていない、システムクリティカルなファイルの閲覧を狙うものである。
前述の「Source Disclosure問題」に似ているが、動作原理が異なる。

ディレクトリトラバーサルにはthe ../ (ドットドットスラッシュ) 攻撃、 ディレクトリクライミング、およびバックトラッキングのような別名がある。
→参照:ディレクトリトラバーサル - Wikipedia

  • 「クロスサイトスクリプティング」「SQLインジェクション」などは、WebサーバではなくWebアプリケーション(CGI)での対策で回避するものなので、除外する。
  • 「OSコマンドインジェクション」は、どちらかと言うとCGIでの対処になるのだろう。
    →参照:http://www.atmarkit.co.jp/fsecurity/rensai/handling01/handling02.html
    ヘッダから値を取得する環境変数(HTTP_REFERER等)は、CGI利用の際には注意すべきである。
  • DoS攻撃、それに準ずるものは、カーネルレベルでの対応になるので、除外する。
    →参照:カーネルのセキュリティ
こうして見ると、Webサーバの本来の基本動作に準ずる「クライアントに要求されたファイルを、クライアントへ送る」動作に係わる部分のみにしぼる事が出来そうです。


対策

Webサーバでなければ出来ない、Webサーバでの対策は実はそれほど多くないようです。
HTTPリクエストに関するバリデーションを厳密にする事で、Webサーバを公開レベルに出来ると思われます。

  1. バッファオーバーフロー攻撃
    バッファサイズを厳密に設定し、それを越えるリクエストを全て「HTTP400」等を返すよう対応。 HTTPリクエストヘッダでは、行の終わりは「\r\n」の改行になるので、これで行が終わっていない場合はバッファを溢れたと判断出来ます。
    
    if(fgets(buf,sizeof(buf),req))
    {
        int len = strlen(buf);
        if(buf[len-1]!='\n')
        {
            /*  buffer over flow!   */
        }
    }
    
    バッファを溢れていなくとも、'\n'で終わらない行はHTTPリクエストヘッダとしては異常なので、エラー扱いに出来ます。

  2. Unicode Decode問題
    リクエストのURIをアドレスとパラメータークエリーに分解。クエリーのデコードはCGIの問題なのでタッチしません。
    アドレスのデコードでは、そもそもファイル名にUTF-8が使えない(ファイル名にUTF-8を使えるLinuxは極?一部)ので、単純に「ASCIIに変換できない文字が現れた時点でエラー扱い」とし、「HTTP400」等を返すように。

    UTF-8 のファイル名が使えるシステムでの運用に対応したい場合は、真面目に「デコード?正規化」をする必要があります。

  3. ディレクトリトラバーサル
    エンコードされたURLから相対記述を正規化し、絶対パス形式に変換。そのパスが、Webの公開領域を超えていれば、「HTTP400」等を返す。

    この対処が出来ていれば、よほど意図的にファイルを配置しない限り「任意のコマンドが CGI として実行されてしまう」事は無いでしょう。Web 公開ディレクトリ内に、実行可能なバイナリやリンクが無ければ、実行は出来ないと考えて良いでしょう。

  4. Source Disclosure問題
    ファイルパスとして正しいかどうか厳密にチェック。不正なパスだった場合、「HTTP400」等を返す。

    thttpd のように「ファイルに実行属性が付いている場合は、内容を閲覧できない」ようにするのも良いかもしれません。CGI ソースファイルの公開抑制には、仕組が単純な割には効果があるでしょう。



方針決定

Webサーバ開発のセキュリティ対策は、HTTPリクエストに関するバリデーションを厳密にする事で、なんとかなる。タブン。

完全と言い切る事は難しいですが、これらで十分実用に耐えうると思います。
実際には、Webサーバだけでなくファイアーウォール等の設定を組合せる事が必須です。 「iptables DoS攻撃」等で検索すると、有用な情報を得ることが出来るでしょう。

とりあえず、この方針で mattows ベースにコードを改良して行こうと思います。



トラックバック(0)

トラックバックURL: http://n-yagi.0r2.net/sanoupulurun/mt-tb.cgi/258

コメントする

ホーム >> 左脳Script >> linux >> Webサーバへの攻撃とは?

アーカイブ

このブログ記事について

このページは、n-yagiが2010年6月22日 18:00に書いたブログ記事です。

ひとつ前のブログ記事は「mattows の POST 対応への道」です。

次のブログ記事は「Adobe AIR 2.0」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Creative Commons License
このブログはクリエイティブ・コモンズでライセンスされています。