A Day In The Boy's Life -188ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

そういう経験ないでしょうか。


もちろん、Webサイトをデザインするには、サイトのコンセプトをイメージどおりに作り上げるデザイナーという職業の人がいて、そこにも様々な技術や才能がいることはわかっているので、一介のプログラマがデザインという言葉を簡単に口にしてしまうと、「お前にできるの?」とか「デザインの何が分かってるの?」って目で見られる事はなんとなく分かります。

そして、一介のプログラマが作ってみせるデザインというのは、本物のそれとは程遠く、技術的な側面に偏った多少独りよがりなものが多い事もわかります。


ですが、特に業務系のアプリケーションが中心の、社内のシステム構築などでは「デザインをする役割の人」がいないことが往々にしてあります。

そして何よりも問題なのは、そもそもデザインというのはシステムを作り上げていく上で、必要不可欠な要素なのにそれを担当する人がいないことを良いことに、誰もその言葉を口にしない事がまかり通ってしまっているという

ことです。


結果、アプリケーションの使い勝手は全部ばらばら、画面レイアウトや色使い、ボタン配置やその役割が異なっていることは当たり前で、メッセージのフォーマットすら統一されていない、というシステムたちができあがってしまいます。

デザインを気にしていない人の多くは、ユーザーの声を意識していません。

ですので、ユーザーが自分の期待通りに動かせないシステムを使う事のイライラを理解しようともしていません。


※ ユーザーインターフェースの重要さについては、「Joel on Software 」に詳しく掲載されています。


なので、プログラマがデザインという言葉を口にした時に、「お前にできるの?」という冷ややかな目で見るのではなく、その要素をどう築き上げるのかという問題提起だと捉えて、適任者にその役割を与える事をしなければなりません。


少なくとも、このデザインという要素を無視するという事で起こっている、多くの弊害というものをもう少し周りは意識すべきだと感じます。
例え、デザイナーというそれに特化した役割の人をいなくとも、それを多くの人が意識する文化を作る必要性はあります。


プログラマだろうとシステム運用者だろうとヘルプデスク担当者だろうと、デザインという言葉を口にすることはむしろよい傾向だと捉え、利用者にとっての最善のデザインというものが何なのかということを、もっと議論するべきではないのかと感じます。





WebサーバーのTRACメソッドを何故受付けなくしなければならないのかについては、XST(Cross Site Tracing)について、説明する必要があります。

XSTについては、以前に書いた「セキュリティ診断ツール「Nikto」を使ってサイトをチェックしよう 」の中で紹介した用語「Cross Site Tracing」@鳩丸ぐろっさり (用語集) に書かれています。


簡単に言ってしまうと、HTTPのTRACEメソッドのリクエストを通して、Basic認証のパスワードが盗まれてしまう恐れがありますよ、というものです。
余談ですがBasic認証のパスワードは、サーバー上のファイルに暗号化して保存されていますが、認証する際の通信には平分で流れます。

HTTPヘッダを見ると暗号化しているように見えるのですが、単にBase64で符号化しているだけなので、簡単に元に戻すことが出来ます。


例) HTTPヘッダ情報の中身

Authorization: Basic aG9nZTpmb28=

上記をPHPを通して、元に戻してみます。


# php -r 'echo base64_decode("aG9nZTpmb28=");'
hoge:foo

「hoge」ユーザーを使い、パスワードは「foo」である事がわかりました。

TRACEメソッドのリクエストを行えば、そのBasic認証時のパスワードを取得できてしまうわけです。


何故、TRACEメソッドがまずいのかというと、TRACEメソッドのその振る舞いです。

TRACEメソッドは、HTTPステータス200(OK)のレスポンスの内容をそのままクライアントに返します。

つまり、Basic認証が済んだ後(HTTPステータス200を受け取った後)に、TRACEメソッドのリクエストを発行すればそのBasic認証時の内容(IDとパスワードが含んだもの)が取得できてしまいます。


セキュリティ診断ツール「Nikto」を使ってサイトをチェックしよう 」の中で、HTTPのTRACEメソッドのリクエストが許可されている事にアラートが出たのはそういう理由からです。


ここでは、Apacheに対してTRACEメソッドのリクエストを受付けない設定を行ってみます。

まずは、本当にTRACEメソッドを受付けているのかどうか、チェックしてみます。

PHPのスクリプトを使って、該当のWebサイトにTRACEメソッドのリクエストを発行してみます。

PEARのHTTP_Request を使って、Basic認証を行うサンプルスクリプトです。


<?php
require_once "HTTP/Request.php";

// 対象のWebサイト(Basic認証がかけられている)
$req =& new HTTP_Request("http://192.168.0.100/login");

// Basic認証のIDとパスワード
$req->setBasicAuth("hoge", "foo");

// TRACEメソッドのリクエストを発行
$response = $req->setMethod(HTTP_REQUEST_METHOD_TRACE);

$response = $req->sendRequest();

if (PEAR::isError($response)) {
    echo $response->getMessage();
} else {
    echo $req->getResponseBody();
}
?>

上記コードを実行してみると・・・


# php auth.php
TRACE /trac/trac-test/login HTTP/1.1
Host: 192.168.0.100
User-Agent: PEAR HTTP_Request class ( http://pear.php.net/ )
Connection: close
Accept-Encoding: gzip
Authorization: Basic aG9nZTpmb28=


リクエストが返ってきましたね。


では、具体的にApacheのTRACEメソッドのリクエストを受付けなく設定します。

Apacheのバージョン2.0.44以降であれば、設定ファイル(httpd.conf)に下記の1行を書けば、それで済むようになっています。


TraceEnable off

しかし、バージョンがそれより古い場合、またはApacheの1系を使っている場合は、下記のようにmod_rewriteモジュールを使った記述をする必要があります。


RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE$
RewriteRule .* - [F]

当然、mod_rewriteモジュールをApacheに組み込んでおく必要があります。

この場合、厳密にTRACEのリクエストを受付けなくしているわけではありません。

TRACEのリクエストがあった場合、mod_rewriteで排除しているという動きになります。


TRACEメソッドの受付を無効にした後に(要Apache再起動)、もう一度先ほどのPHPスクリプトを実行してみます。


# php auth.php
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /login on this server.</p>
</body></html>

HTTPステータスコード403の画面のレスポンスが返ってきており、Apache側で受付けていない事がわかります。

管理するWebサーバーがあるのであれば、一度チェックしてみてはいかがでしょうか。




少し前から、現象を確認していたのですが、自分だけかなぁとか、IEを再起動したらなおったり、そもそもIEじゃなくていいや、なんて事でほったらかしにしていたのですが、ヘルプデスクに問合せが入ったので、調べてみたら意外と多くの情報が載っていました。


現象の詳細はというと、IE7を起動してテキストボックスやテキストエリアに日本語を入力しようとしても、何のキーを押しても反応しなくなるというものです。

(さらに細かく言うと、英数字なら入力可能なパターンと、何の文字も一切入力不可能という2パターンがあります)


この現象の原因ですが、IMEが悪いみたいですね。

以前に書いた「WindowsXP上のInternetExplorer7でファイルのダウンロードが行えない件 」でも、IMEが悪さをしてファイルのダウンロードが行えないという現象が発生していました。

そもそも、InternetExplorer7日本語版のMicrosoftUpdateによる配布日が遅れたのも、このIMEとの関係のバグを

修正していた為、とどこかで聞いたような・・・。

現に、アジア圏のIE7の配布は揃って遅れていましたしね。

結局はその辺を最終的に修正をしていないのに、配布を開始したというような感じでしょうか。


で、このIE7で日本語入力が突然出来なくなる件ですが、下記にその対処方法が載っていました。


IEで日本語が入力できなくなったら試したい5つの方法 @ ITmedia Biz.ID


一番の方法は、IMEの設定で「詳細なテキストサービスを使用しない」と設定しておく事でしょうか。


そういえば、私はIEエンジンを使っているLunascape をよく利用していますが、これでは同現象は起きた事がありません。

原因の詳細はよくわからないのですが、パッチが出る事はあるのでしょうか・・・。

Vistaに搭載されている、IME-2007だと同現象はでないという情報もあるので、Vistaへ移行させたいMSとしては特に対策を打ちそうに無いような気がしますが・・・。