Google Developers Conference参加申し込みで 出題された問題。OAuthの公開鍵を使った3-legged認証ではなく、 共有鍵を使って鍵つきダイジェスト認証をする、著者不在の 2-legged(足)な認証をする。devquizという比較的簡単な問題 なのだけれども、いままで使ったことがないので練習のつもりでやってみた。 自分でGoogle Apps premierを使っていれば、利用したかもしれないが、 そうでもないし。3-legged OAuthを見て、あーめんど、と思って 敬遠していたのもある。

自分の理解のために、手でseed作成とHMAC-SHA1ダイジェスト作成を コーディングしていたが、どうもうまくいかない。しかたなく PythonのコードやPHPのコードを探してみると、いくつかあるが 今回のGoogleのdevquizのようにPOSTで、realmをつけて、Authorization ヘッダで認証する、というコードがない。Pythonのマニュアルの 読み方を調べる直前で、PerlのOAuth::Liteがいい、というのを見て やってみると、関数に引数を与えるだけであっさり認証が完了した。

#!/usr/bin/perl 

use 5.0.8;
use strict;
use warnings;

use Data::Dumper;
use OAuth::Lite;
use OAuth::Lite::Consumer;

my $consumer = OAuth::Lite::Consumer->new(
  consumer_key		=> 'YOUR_CONSUMER_KEY',
  consumer_secret	=> 'YOUR_CONSUMER_SECRET',
  realm			=> 'devquiz',
);

my $response = $consumer->request(
    method  => 'POST',
    url     => 'http://gdd-2010-quiz-japan.appspot.com/oauth/YOUR_CONSUMER_KEY',
    params  => {
        hello => 'world'
    });

if ($response->is_success) {
    print Dumper($response->decoded_content);
} else {
    warn $response->status_line;
}

PerlのOAuth::Liteは、nonceを自動的に生成し、time()も自動的につけてくれる。 デフォルトはPOSTのAuthorization:ヘッダの、HMAC_SHA1でそろっている。

というわけで、手でコーディングしていたダイジェストの問題は以下のとおりだった。

• seedにはPOSTの送信データであるhello=worldを含めること
• Digest::HMA_SHA1のb64digest()メソッドは、Base64エンコードらしきことを するが、文字列の末尾のパディングをしないため、認証が通らない。
• MIME::Base64のencode_base64()メソッドは、Base64エンコードをするが、 より大きなデータの処理を想定しているため、デフォルトで文字列の 末尾に改行コードを追加する。末尾の改行が不要なときは encode_base64($digest, "")のようにしなければならない。
• realmはoath_なんとかのseedには入れない

mixiの説明は、Googleの説明資料の日本語訳になっていてわかりやすい。 が、PerlのOAuth::Liteを使えば、seedに関連する半分以上の説明は理解しなくてもよい。

部屋に置き去りにされていた1歳と3歳の子供が、インターホンごしに 『ママー、ママー』と呼ぶ声が聞こえたという件。そういうこともある のか。悲惨。児童相談所の大阪市こども相談センターに通報したというが 相談センターは効果ある対策をとれなかったか、とらなかったらしい。

“クルマ渋滞の緩和を狙ったクルマへの課金である。市中心部に乗り入れると監視カメラが自動的にナンバーを読み取り、後日、請求書が送られてくる。主に対象となるのはガソリン車。エコカーは減免される。

これができるならディーゼル車の排ガス規制もできるはず。

国外退去処分というものがいかに意味がないか。ネットを使えばどこででも、 ソーシャルエンジニアリングさえ 犯罪は可能、とすれば国外退去処分は無罪釈放そのものか。

Yahooの選挙ページは東京選挙区の立候補者一覧ページまで3クリックぐらいで たどりつけたので、たいへんわかりやすかった。

■httpd.conf

# 持続的接続を有効化
KeepAlive On
# IE は除外
SetEnvIf User-Agent ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
# HTTP ヘッダの表示を抑制
ServerTokens Prod
# エラーページの表示を抑制
ServerSignature Off
# TRACE メソッドを無効化
TraceEnable Off

■php.ini

; HTTP ヘッダの表示を抑制
expose_php = Off

今こそケータイID問題の解決に向けては背景説明のスライドもあり 資料豊富。

サイトごとに実行を制限したり許可したりする機構は、ベースとして 必要なのはわかるが、簡単に追加削除ができるNoScriptのような ユーザインタフェースがないと、使えない。サンドボックスを持つ Chrome本体にもJavaScriptの実行を制限または許可するACL(Access List)機能があるが、 ACLを提供するということは、やはりサンドボックスとはいえ充分ではないためか？

Google Analyticsのようにサイトへのアクセス集計や、Google Syndication のような広告の露出集計も、JavaScriptで処理されている。このへんは そのまま脆弱性につながる場合もあるし、常にプライバシの問題につながる。 特に問題なのは、あるサイトにアクセスしただけのはずが、何の断りも 表示もなく、そのサイトにアクセスしたブラウザがクッキーなどで識別されて、 へたをするとそれ以前にアクセスした有名サイトの一部のアクセスの有無も 収集されてしまうところ。