最近時々Users-MLにメールが流れています。Ultramonky L7（L7：Layer7スイッチ、HTTPプロトコル・Webアプリケーションレベルでの負荷分散機能）はがんばってもらいたいプロジェクトなので転載します。

ultramonkey-l7-usersの皆様へ

こんにちは。
渡丸と申します。

UltraMonkey-L7のSNMP対応版（Ver.0.5.0
）リリースの
公開につきまして、以下の通りお知らせします。
（先ほどSourceForge.jpのUM-L7ニュース欄にも掲載しました。
http://sourceforge.jp/forum/forum.php?forum_id=10716 ）

追加のプロトコルモジュールとして、以下のモジュールを追加した
– l7vs-0.5.0-0
– l7directord-0.5.0-0
を作成しました。

cpassive　…　Cookieパーシステンスpassiveモジュール
　　　　　　　　振分先サーバにてcookie情報を付与することで
　　　　　　　　セッション管理するモジュール
crewrite　…　Cookieパーシステンスrewriteモジュール
　　　　　　　　振分先サーバにて空のcookieを付与し、
　　　　　　　　UltraMonkey-L7でcookie情報を変更することで
　　　　　　　　セッション管理するモジュール
cinsert　 …　Cookieパーシステンスinsertモジュール
　　　　　　　　UltraMonkey-L7でcookie情報を付与することで
　　　　　　　　セッション管理するモジュール
chash　　 …　Cookieパーシステンスhashモジュール
　　　　　　　　振分先サーバにてcookie情報を付与し、
　　　　　　　　UltraMonkey-L7でcookie情報の一部を管理することで
　　　　　　　　セッション管理するモジュール
urla　　　…　URLパーシステンスモジュール
　　　　　　　　HTTPレスポンスのボディ部のURL情報より
　　　　　　　　セッション管理するモジュール

また、追加機能として、以下の機能を追加しました。

閾値による振分回避機能　…　設定している閾値を超えた場合、
　　　　　　　　　　　　　　他のサーバ（Sorryサーバ）へ振り分ける機能

レプリケーション機能　　…　セッション情報を冗長化しているサーバと
　　　　　　　　　　　　　　同期をとる機能

ドキュメント類は、後日修正して、ご連絡させていただきます。
ご要望、コメント等ございましたら、ご連絡願います。

_______________________________________________
Ultramonkey-l7-users mailing list
Ultramonkey-l7-users@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users

SANS TOP20が更新されています。

Cross Platformの一位が「Web Applications」になっています。PHP以外のWebアプリにもセキュリティ上の問題が数多くあることに気が付いたと言うことでしょう。といっても解説はPHPが対象となっています。HTTP Response Splittingは最近のPHPでは不可能になっていますが記載されています。（header関数でCR,LFは送信できないよう仕様変更されている。最近ではPythonで作られているtracにHTTP Response Splitting脆弱性が見付かっている）

PHP以外のアプリでも問題が多い事を示している統計情報もあります。例えば、これなど
http://internet.watch.impress.co.jp/cda/news/2006/07/24/12759.html
対象はJavaのWebアプリが多いと聞いています。

XSSと異なり、SQLインジェクションなどは100%防げるにも関わらずこういった状況のようです…

結構便利そう。

ホーム：
http://www.openqa.org/selenium-core/

デモ：
http://www.openqa.org/selenium-core/demos.html

ダウンロード：
http://www.openqa.org/selenium-core/download.action

備考：前のエントリのコメントに対してこのエントリを作成しました。

セキュリティ対策の3大要素の一つとしてデータの整合性（Integrity）があります。3要素は私が勝手に決めたことではなくISO規格でも決まっています。

個別のアプリでの解釈の問題になりますが、データの整合性に重複送信が含まれない、と考えるのであればコメントされている通り「発想が変」と言う考え方になるかもしれません。重要なデータでなければ（例えばブログへのコメントなど）安全性とは無関係といってもあまり差し支えないです。しかし、注文や送金などのデータでは致命的です。

# 認証システムが無いサイト（必要ないサイト）
# に「認証システムが無い」からといって「セキュリ
# ティ問題だ」と騒ぐ必要がないのと同じでデータ整
# 合性が必要ないサイトではセキュリティ問題になり
# ません。だからと言ってデータ整合性の問題が
# セキュリティ問題でなくなる訳ではありません。

従ってデータの整合性が必要でないサイトやアクセシビリティを気にしないサイトであればREFERERでCSRF対策したサイトでも、2重送信対策をしていないサイトでも問題ないといえるでしょう。データの整合性がセキュリティ問題でないサイトも多くありますが一般的にはセキュリティ問題といっても差し支えないと考えています。（認証の問題がセキュリティ問題であると同じように、データの整合性もセキュリティ問題ということです）

# REFERERを送ってこないクライアントからは
# 接続を受け付けなければアクセシビリティ
# の問題になります。

安全性が低いサイト、アクセシビリティが低いサイトを作ることは自由です。しかし、お勧めできるサイトでないと考えています。完全なCSRF対策（と2重送信対策）を施したサイト作っても手間はほとんど変わりません。これらの理由からREFERERを利用したCSRF対策、ハッシュ値等を利用した2重送信対策は不完全・不適切な対策であると考えています。

フォームにランダムで一意なIDを割り当てる方式も十分簡単だと思いますがREFERERでCSRF対策を行っているサイトが結構あるようですね…

FlashでREFERERが書き換えられる問題は別次元の問題だとしても、REFERER自体ブラウザが送信するデータであるため元々信頼できるデータでは無いです。随分前からクライアントレベルのセキュリティ対策ソフトウェアの中にはREFERERヘッダを削除する物もあります… 社内サーバから外部リンクをクリックした場合に社内サーバのURLが外部に洩れないようにREFERERヘッダを削除するプロキシもあります…

一般的な環境からなら使えるから(ある程度安全)といってセキュリティ対策にREFERERを使用するのは良くない考え方です。

ところでREFEERERでCSRF対策を行っているサイトは同じフォームの重複送信対策はされているのでしょうか?送信されたデータのハッシュを取って同じだったら重複とみなすとか?(この手のサイトは「2回以上送信ボタンを押さないでください」と設計ミスが明記されていることが多いです…書いてないサイトも多いと思います)

IBMが更にDojoを支援するらしいです。

Dojo Toolkit enabling internationalization of applications and making them fully accessible to persons with disabilities through a variety of assistive technologies,

Ajaxを使うとアクセシビリティが問題になりますが、アクセシビリティも考慮すると言うことらしいです。デモはなかなか良くできています。この近いうちにこのツールキットを使ってなにか作ってみよう。

問題：以下のコードはセキュリティ上大きな問題となる脆弱な処理が含まれています。セキュリティ上のベストプラクティス、他の自動ログインの実装方法と比較し、以下のコードの脆弱性を詳しく述べよ。

if (serendipity_authenticate_author(
  $serendipity['POST']['user'], 
  $serendipity['POST']['pass'], false, $use_external)) {
  if (empty($serendipity['POST']['auto'])) {
    serendipity_deleteCookie('author_information');
    return false;
  } else {
    $package = serialize(
               array('username' => 
                        $serendipity['POST']['user'],
                     'password' => 
                        $serendipity['POST']['pass']));
    serendipity_setCookie('author_information', 
                           base64_encode($package));
    return true;
  }
  // Now try login via COOKIE data
}

解答：次のブログエントリで解説します。（解説の必要は無いかもしれませんが）

備考：実際のブログアプリケーションのコードの一部です。このブログ（b2evolution）のログインコードも問題がありますが上記コードよりはましです。

追記：serendipity_setCookieがどのように定義されているかが分からないと正確に答えられないので張り付けます。このブログアプリケーションの開発元には適切な自動ログインの実装方法と共にレポートする予定です。

/**
 * Set a Cookie via HTTP calls, and update $_COOKIE plus $serendipity['COOKIE'] array.
 *
 * @access public
 * @param   string      The name of the cookie variable
 * @param   string      The contents of the cookie variable
 * @return null
 */
function serendipity_setCookie($name,$value) {
  global $serendipity;

  setcookie("serendipity[$name]", $value, 
            time()+60*60*24*30, 
            $serendipity['serendipityHTTPPath']);
  $_COOKIE[$name] = $value;
  $serendipity['COOKIE'][$name] = $value;
}