カテゴリー
Security

サーバシグニチャは隠さないのが当たり前?

yohgaki’s blog – サーバシグニチャは隠すのが当たり前
http://blog.ohgaki.net/index.php/yohgaki/2007/09/04/a_ma_fa_a_ma_da_a_a_pa_me_na_a_ra_af_a_a

に対するコメントを見つけました。このブログに対するご意見は探したことがないので、たまたま見つけたこのブログが初めてくらいだと思います。「サーバシグニチャは隠さないのが当たり前」とするご意見です。

なぜサーバのバージョン情報を公開する必要があるのか。それは、クライアント側で、サーバのバグや規格解釈の相違に起因する問題を回避するためです。

「当たり前」とするには理由が弱いと思います。サーバ側はサービス提供者が自由にコントロールできる要素です。サーバがオプションとして送信する特定のヘッダを送信しようとしまいと正しく処理できるようにするのはブラウザの責任です。最悪の場合、サーバは攻撃用のヘッダを送信してくるかも知れません。サーバシグニチャが100KBもあるヘッダなどが送信されても問題が発生しないようにするのはブラウザ側の責任であるのと同じです。

クライアント側で「サーバのバグや規格解釈の相違に起因する問題を回避」している場合があるは知っていまたが決定的と言える問題ではありません。Pipelineは使えないと多少効率が落ちるだけです。(サーバ側では別にPipelineをサポートしないからといって、負荷が軽減するものでもありません。)Pipelining以前に、より多くのクライアントに安全にデータを送信するためにKeepAliveさえ無効に設定しているサイトもまだまだ多いでしょう。(i.e. HTTP Response Splitting) Pipeliningは一例かと思いますが、これを持って「サーバシグニチャは隠さないのが当たり前」とするには不十分だと思います。もしかすると私が知らない決定的な問題があるのかも知れませんが、その場合は教えていただけると有難いです。

クライアント側がユーザエージェントヘッダを「送信するのが普通」だと思いますが、送るのが「当たり前」だとは思いません。それはユーザの自由です。同じように「JavaScriptを無効」にするのもユーザの自由です。「最近JavaScriptが有効なのが当たり前」なサイトが増えていますが、全てのWebサイト開発者はWCAGをよく読むべきです。WCAGはJIS規格にも採用されています。ユーザビリティだけの問題でなく、より安全にWebを利用するためにJavaScriptを無効にするのはずいぶん当たり前になりつつあります。

画像を表示できないテキストブラウザでWebサイトを参照するのも自由で有るべきです。文字を表意しない音声ブラウザでWebサイトを参照するのも自由で有るべきです。たとえ十分に利用できない可能性があっても「あなたのブラウザでは参照できません」と門前払いをすべきではありません。

とにかく、サーバシグニチャを隠すのも、インストールされている全てのモジュールのバージョンまで含めて隠さないのもサーバ管理者の「自由」です。

http://memo.hirosiki.jp/article/54026897.html

結論:
サーバシグニチャを出さないことでは確かにウノウの言うようなセキュリティレベルの向上は“それほどは”得られないが、だからといって出さないことがクソだのタコだの言うのはバカ。

多少言葉は悪いですが、両方の意見に対してかかれたこのブログのメリット・デメリット、結論は理解できます。

サーバシグニチャに詳しいサーババージョンを書かないのはセキュリティレベルを向上させると言うよりは「犯罪者のデータベース作成に協力しない」ことが私としては1番目の目的です。この対策は役に立たないかも知れませんが、役に立つかも知れない、といった対策です。採用するかしないかは管理者(またはセキュリティポリシー)次第です。攻撃され辛くする対策は根本的なセキュリティ対策とは言えないかもしれませんが、多くの場合それで十分である事も事実です。例えば、家の玄関ドアの鍵を2つにする、割れにくい窓ガラスにする、などは泥棒(攻撃)対策に有用であるとされています。完璧なセキュリティ対策でなくても十分有効に機能する例は多くあります。

ちょっと脱線します。UserAgentを参照し、IE, Fireforxの各バージョンの脆弱性に合わせた攻撃を行い、脆弱性がないUserAngetの場合攻撃を行わないWebサイトも実存します。ブラウザのUserAgentを送信しない、または正しいUserAgentを送信しないのは普通とは言えませんが、実際にこうした攻撃が有る以上、「送信するのが当たり前でしないのはNG」とするのは問題があると思います。余計(?)なヘッダ情報は実際に攻撃に利用されているのです。

クライアント(ブラウザ)を作る人、Webアプリを作る人、はそれぞれサーバ、クライアントには「十分な自由度」があるように作らなければならないと考えています。

「うちのサイトはIEのみでVBScriptが有効なブラウザしか使えない仕様」にするのもサイト運営側の自由です。万人向けでは無いサイトを作るのも自由ですが、広く一般に公開しているサイトであるにも関わらず万人向けサイトではない無い場合、そのことを明記するべきです。特に責任ある企業のサイトなら尚更です。

話を戻しますが、Webサーバとモジュールの安全性に100%の自信があれば詳しいサーバ構成を記述したヘッダを送信することに異論はありません。 安全性に不安を持っている(100%の信頼を持っていない)システム管理者であれば「(特に懇切丁寧な)サーバシグニチャは送信しないのは当たり前」だと思っているだけです。私のブログからも分かるように私の立場は「100%信用していないのでシグニチャは隠すのが当たり前」と考えています。

最近は攻撃の高度化、ステルス化が進んでいます。昔のように手当たり次第で直ぐ分かるような攻撃は少なくなり、システム管理者が気が付かない方法で攻撃してきます。仮に自分が犯罪者でWebサーバやそのモジュールの脆弱性を利用して乗っ取れる0Day攻撃手法を発見した場合、手当たり次第に攻撃するのではなく、できるだけサーバ管理者に気づかれないように細心の注意を払って攻撃します。その攻撃に利用する重要な情報の一つがサーバシグニチャです。サーバを乗っ取った後、カーネルレベルルートキットをインストールするためにフィンがープリンティングでサーバが利用しているOSとそのバージョンも調べるでしょう。カーネルレベルルートキットをインストールすれば、ルートキットのファイル・プロセス・ネットワーク接続が参照できなくなるのでIDS/IPSをゲートウェイなどにインストールしていなければ検知するのは極めて困難になります。水際で攻撃を防止する重要性はますます増加しています。

ほとんど全てのセキュリティ対策にはメリットとデメリットがあります。セキュリティポリシーはそのバランスをどこに設定するのか決めるものです。便利なシステムを利用している以上、リスクは受け入れなければなりません。どのリスクを受け入れ、どのリスクを軽減し、どのリスクを排除するかはセキュリティポリシーで決めます。

# 正しくリスクを識別すること(リスクアセスメント)がセキュリティ対策
# では非常に重要です。リスクを識別できなければ、組織やサービスが必要
# としているセキュリティポリシーは策定できません。

# Pipelineとかは本来はプロトコルバージョンで判別できれば良い機能だと
# 考えています。現実的にはHTTP/1.1.1とかすると誤作動するソフトウェアが
# 山ほど有るので無理ですが。サーバソフトの種別で判別するべき機能ではあ
# りません。時間が解決するのでそれまでpipelineは使わなければ良いだけの
# 機能です。ブラウザにはそういった機能は山ほどあります。E4X、CSS、DOM
# とか。

# そういえば最近Citrixのおかげで筒抜けになっているサイトが多数ある、と
# 話題になっていましたね。別問題と言われるかもしれませんが、べつにどう
# でもよいサーバシグニチャを隠すくらいの気遣いをする管理者であれば、
# こんな間違いは起きなかった可能性が高かったのではないか、と思っています。

#「JavaScriptを有効にしておくくらい当たり前」とユーザに強制するのであれ
# ば「100%安全なWebサイトを提供するのが当たり前」と言われても仕方ありま
# せん。100%安全性は絶対に保証できないので「どのようなクライアントでアク
# セスしても、必要最小限はナビゲーションできて当たり前」と考えています。
# 少なくとも「このサイトはJavaScriptを利用しているのでJavaScriptを有効
# にしてください」とメッセージを表示すべきです。noscriptタグを入れるの
# が面倒だとは思えません。

「あたり前」論には少なからず主観が含まれます。「あたり前」とか「常識」は主観無しにはあり得ないからです。従って、一つの「あたり前」には反対の「あたり前」もあります。どれを「あたり前」とするか、もしくはしようとするかは個人のセンスだと思います。

書かない日記のはずがつい書きすぎてしまいました。書きたい事は山ほどある
のですが、今日はこの辺で。

カテゴリー
Security

いろいろ変わったXSSがありますが…

私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、ECMAScriptにXML機能を追加したのはどうなんでしょうね…. 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。

<script>
123[”+<_>ev</_>+<_>al</_>](”+<_>aler</_>+<_>t</_>+<_>(1)</_>);
</script>

好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。

日本語訳
http://www.ne.jp/asahi/nanto/moon/specs/ecma-357.html

原文
http://www.ecma-international.org/publications/standards/Ecma-357.htm

しかし、E4Xのアッタクベクタは色々ありそうですね。

カテゴリー
Security

JavaScript文字列のエスケープ

 

追記:新しくより安全なバージョンはこちらです。

hoshikuzuさんのページに書いてあるJavaScript文字列のエスケープ方法です。(元ネタのメールアーカイブは文字が欠落)

http://d.hatena.ne.jp/hoshikuzu/20071011#p1

1. 「¥」を「¥¥」に置換する
2. 「”」を「¥”」に置換する
3. 「’」を「¥’」に置換する
4. 「/」を「¥/」に置換する
5. 「<」を「x3c」に置換する
6. 「>」を「x3e」に置換する
7. 「0x0D(CR)」を「¥r」に置換する
8. 「0x0A(LF)」を「¥n」に置換する

SmartyのJavaScirpt文字列のエスケープ方法です。

CVS版:2007/10/12

case ‘javascript’:
// escape quotes and backslashes, newlines, etc.
return strtr($string, array(‘\\’=>’\\\\’,”‘”=>”\\'”,'”‘=>’\\”‘,”\r”=>’\\r’,”\n”=>’\\n’,'</’=>'<\/’));

strtrで置換しているので元々文字エンコーディング攻撃に脆弱ですが、クローズタグだけ考慮している部分、/、<、>の取扱いが異なります。<, >はHEXで表記した方が安全ですね。

文字エンコーディングの問題は随分前から気づいていましたが、この手の修正は受け入れられる可能性が低いですからね…(文字エンコーディングが壊れていなければほとんどの文字エンコーディングで大丈夫なはず。例外はSJISかな)いずれにせよJavaScriptをダイナミックに生成するのはお勧めしません…

JavaScriptはクライアントサイドなので、確実かつ安全なエスケープ方法、は簡単ではありませんから。

カテゴリー
Windows

IEの脆弱性

CVE-2007-3896は例のIEのバグでなくて呼び出し側のFirefoxの問題云々の件です。

The URL handling in Windows XP and Windows Server 2003, with Windows Internet Explorer 7 installed, allows remote attackers to execute arbitrary programs via invalid “%” sequences in a mailto: or other URI handler, as demonstrated using mIRC, Outlook, Firefox, Adobe, Skype, and other applications. NOTE: this issue might be related to other involving URL handlers in Windows systems, such as CVE-2007-3845.

結局、mIRC、Outlook(これ以外のMS製品もあったはず)、Firefox、Adobe(Readerの事だと思います)、Skypeなどあまりにも多いのでIEの脆弱性にしてしまおう、と言うことなのだと思います。

基本的には呼び出し側が問題なく動作するデータを送るようにするべき、つまりIEの脆弱性でなく他のアプリの問題である可能性が高いと思います。(確信するにはリサーチが必要)

Cとバッファオーバーフローの関係と似ていると思います。余計分かり辛い??
基本的にはデータのセキュリティ対策の責任はCalleeでなく、Callerにある。SQLにヘンな文字列が入っていてSQLインジェクションされないようにする対策はDBサーバ(Callee)でなく、プログラム(Caller)にあるのと同じ事だと思います。

ただし、DBサーバ側(Callee)でも簡単に不正なデータであることがチェックできるような入力(例えば、壊れた文字エンコーディング)であっても処理してしまうと問題の責任はCalleeにあります。

どっちなんでしょうね。

カテゴリー
Computer Linux Other

MomongaLinux4でCanon iP7500を使う

Canon iP7500をMomongaLinuxから利用するには

http://www.canon-sales.co.jp/drv-upd/bj/bjlinux260.html

に掲載されているフィルタをインストールしてCUPSのプリンタ設定ページからドライバを選択すれば利用できるようになります。

バイナリrpmを入れても良いのですが、以前にうまく動作しなかった事があるのでSRPMからインストールすることにします。

このcnijfilter-commonはlibxml(obsoleteなパッケージです)が必要なので、どこかから適当なSRPMを拾ってきます。rpmbuildコマンドでビルドするとlibtoolでエラーが発生するので/usr/sbin/libtoolで上書きします。書き換えていれば問題無くビルドできました。

次にcnijfilterのビルドですが、まずcups-devel, gtk+1-develをインストールしておきます。他にも必要な開発用パッケージがあるかもしれません。必要な物はインストールします。

%installセクションの

install -c -s -m 755 ${PR_ID}/database/* ${RPM_BUILD_ROOT}%{_libdir}/bjlib

の-sオプションを削除します。ライブラリでもないファイルに-s(stripオプション)が付いているのでエラーになります。後はrpmbuildでビルドして出来上がったrpmを全部インストールします。

CUPSは再起動しないと新しいドライバを読み込まないので再起動します。その後、プリンタメーカでCanonを選択するとcnijfilterがサポートするプリンタ(Canon PIXUS iP4200 / PIXUS iP6600D / PIXUS iP7500 / PIXUS MP500)が一覧に表示されるようになります。

サポートディストリビューションはSUSE Linux 10.0、Turbolinux FUJIとなっていますが同じ手順でFedoraなどにもインストールできると思います。ここにRedHat系のOSが載っていないのはサポート負荷軽減の為?と勘ぐりたくなります。Libxml2を使うように書き換えればもっと簡単に多くのディストリビューションで使えるようになると思います。

Canonのページを見るとUSBからの接続しかできないような記述になっていますがネットワークプリンタとして接続できればLPDでもIPPでも印刷できます。

MomongaLinux3以来のインストールでしたが以前よりインストールが簡単になっていました。以前はインストール済みのライブラリ(確かlibpngとか)を強制的に別バージョンに見せてインストールしたと思うのですが今回はそのような荒技を使わなくても普通にインストール出来ました。

Mac OSXにはiP7500用のドライバがあるのですがこのドライバはMacのUSBポートに直接iP7500が刺さっていないと動作しない代物です。OSXもCUPSを使っています。CUPSのフィルタならOSXでも使えるはずなので余裕があるときにインストールしてみたいと思います。

追記:
とりあえずビルドした物を公開しました。よろしければどうぞ。
http://wiki.ohgaki.net/index.php?Momonga%20Linux%2FCanon%20Printer

カテゴリー
Development

PRGパターンって不必要…

PRGパターンって不必要…というより有害な気がします。

追記/訂正:
普通に実装するとこの後に書いている問題は発生しないので、別の実装が「戻る」ボタンで戻れない原因の様です。普通にリダイレクトすれば302でブラウザに返すので前のページまで戻ります。態々別のリダイレクトをしているPRGパターンが有害と言う事なのかも知れません。今度戻れないページにあったら調べてブログに書きます。(あまり突くと攻撃と見なされるかもしれないので問題ですけど… 役に立つ対策ではないですがもしかすると重複ポスト対策なのかも知れません。不特定多数向けアンケートなどだと安直にリダイレクトで制限だけしてOKとしているのかも知れません。幾つかのパターンがありそうなので調べてみる価値はありそうです)私はデータのやり取りが増え、かつGETを利用することにより汎用性が劣るこの方法でなく普通(?)に内部で処理をルーティングしています。この方法でStrutsでMVCを奇麗に書くと言うのも理解できない事は無いです。微妙な気がしますが、少なくとも普通のPRGパターンは有害、とまでは言えないです。

フォームをポストしてリダイレクトさせ、結果をGETで取得させるのでPRGパターンだそうです。

* First a user-filled form is sent to the server using either POST or GET method. Server stores the information, updates the database and business model data, and replies with REDIRECT response for a View page.
* Browser loads View using GET, no user data is sent to the server at this point.

「え?」と思わせる実装に出会う事があります。PRGパターンもその一つです。ざっと斜めよみなので勘違いしているかもしれないですが。

はっきり言って不親切な実装だと思います。リロードしたら「送信済みです」と表示され、「戻る」で普通に前のページに戻れる方が直感的でわかりやすくユーザビリティが高いと言えると思います。戻るやページのリロードでデータの再送信が行われないようにする事が目的らしいですが、別の方法でごく普通にこのように動作させることが出来ます。重複送信問題もなくCSRFを気にする必要もない実装で可能です。
# 2003年の記事なので割り引いて考えても優れた方式とは言えません。
# 私は2000年の頃からフォームに予測不能な一意なIDを付ける実装を
# 行っています。
# そもそもリンク先のページでは、重複とかCSRFの事を書いていない
# ので、これらは別に対処(or 全く考慮してない)と言うことだと思いま
# す。MVCが綺麗に書けるより、ユーザが使いやすい方が重要だと思い
# ます。

PRGパターンを利用していると思われるWebサイトで「戻る」で戻れなくてフラストレーションが溜まった経験があるのは私だけとは思えません。「戻る」を連続クリックしたり、ヒストリーからしか前の方のページに戻れないサイトが多いのもこの「PRGパターン」のせいなのかな?

カテゴリー
Security

Webサイト改竄の新傾向? AdSenseの乗っ取り。

リンク先のフォーラムによるとページ改竄が可能なWebサイトのAdSenseを自分のIDに改竄してしまう、という直接的な攻撃が行われ始めたようです。

小規模なサイトなら「自分の広告が表示されている、と思っていたら他人の広告だった」と気がつくまでには1カ月くらいは必要かもしれないので多数のWebサイトに仕掛ければ小銭稼ぎくらいはできるかも知れません。実際、実験用にこのブログにもAdSense広告を張り付けていますが、広告収入がどれくらいなのかほとんどチェックしていません。(というよりチェックしたくなるほどの広告収入にはなりません)

小銭、といっても月数万円にほどになれば発展途上国ではクラックする十分な動機になります。日本の場合、言語障壁が高いので欧米に比べればリスクは高くは無いと考えられます。

日本でもこの手の被害は発生しているのかな?