2010年12月15日水曜日

サルでもわかるOAuthとXAuthの仕組みと違い


APIやWEBサービスを利用する際によく見かけるのがOAuth(オーオース)とxAuth。



しかし、OAuthは仕組みがやや複雑であるため、詳しく解説されると逆に混乱し簡易すぎるとよくわからない仕組みと理解されがちです。



そこで、自分なりにイイ感じにスッキリまとめたので紹介します。



前書き


近年Webサービスが爆発的に普及してきました。



代表的なサービスではGoogle Yahoo mixi Twitter Facebookなどでしょうか。



これらのWEBサービスを利用又は開発する際に問題になるのがユーザ管理です。



IDやパスワードを預かるWEBサービスではユーザ登録の手間やセキュリティの強化など、利用する側も開発する側にも少なからず煩わしい手続きと思われてきました。



そこで登場したのがOpenIDです。



OpenIDとは


OpenIDはWebサービスごとにIDを作成しなくても予め所有しているIDがOpenID対応であればOpenIDに対応したサービスを利用する際にユーザ登録などの手間を省くことができます。



OpenIDの基本は認証を行うためのシステムなので機能的な制限を与えることはできません。



例えば「HogeサービスがTwitterの情報を取得できるようにしたい。ただし読み込みだけで書き込みの権限をHogeサービスには与えたくない。」といったような事はOpenIDでは実現できません。



そこで特定の機能のみのアクセスを認可する仕組みとしてOAuthが登場しました。



OAuthとは



特定の機能のみ認可するシステムがOAuthですがいくつかのデメリットがあります。



  • 実装が複雑(支援するライブラリーがたくさんある)

  • 基本的にWebサービス向け

  • デスクトップアプリケーションには不向き


OAuthはWebサービスで利用される事を想定しているため、デスクトップアプリケーションでOAuthを利用する場合は



ブラウザを経由するかアプリケーションに搭載した独自のブラウザを利用する必要があります。



簡単な図を書いてみました。


f:id:koujirou6218:20101214185715j:image


背景

Hoge解析でTwitterの情報を取得してHoge解析したい



  1. [ユーザ]Hoge解析でTwitterを利用する意志を示す(リンクをクリックするなど)

  2. [Hoge解析]ユーザからTwitter連携の意志を受け取ったのでTwitterに移動

  3. [ユーザ]Twitterにログインする

  4. [Twitter]Hoge解析が必要としている機能を許可するとTwitterはHoge解析にアクセストークンを渡す

  5. [Hoge解析]TwitterからもらったアクセストークンでTwitterの情報を取得する

  6. [ユーザ]Hoge解析を楽しむ



今後Hoge解析は6を繰り返して情報を取得する。



OAuthのメリット



  • Hoge解析にIDやパスワードを渡す必要がない

  • 必要な権限のみHogeサービスに渡せる

  • Hoge解析が権限を悪用してもTwitter側で拒否できる(パスワードやIDを変える必要がない)

  • 悪用時の被害を最低限に抑えられる



xAuthとは



xAuthはTwitterAPI認証時に以前はBASIC認証を利用していたのですがその代わりとして準備された物です。



xAuthはOAuthの簡易版というよりもBASIC認証にかなり近い物です。



これも簡単な図を書いてみました。


f:id:koujirou6218:20101214185716j:image



  1. [ユーザ]Hoge解析にTwitterで利用しているIDとパスワードを渡す

  2. [Hoge解析]渡されたIDとパスワードを利用してTwitterにアクセストークンを求める

  3. [Twitter]Hoge解析にアクセストークンを渡す

  4. [Hoge解析]TwitterからもらったアクセストークンでTwitterの情報を取得する

  5. [ユーザ]Hoge解析を楽しむ


(適当なタイミングHoge解析はIDとパスワードを破棄する)


このように一度WebサービスにIDとパスワードを渡さなければいけない点がOAuthと大きく異なります。



デメリット



  • Hoge解析がIDとパスワードを本当に破棄いているのかがユーザはわからない



メリット



  • 開発時にOAuthよりも認証方法が簡単

  • デスクトップアプリケーションでもブラウザなしで認証できる



OAuthとxAuthの違い



既にお分かりだと思いますが、xAuthはベーシック認証の拡張でありOAuthのようなセキュアなプロトコルではない点です。



OAuthは認証の過程で署名などがありアクセストークンの自体も保護されいるので非常にセキュアなプロトコルです。



しかしxAuthはIDとパスワードが平文で流れる可能性があり、Webサービスが確実にIDとパスワードを破棄したことを確認できません。



xAuthに限らず最近はOAuthを利用してあたかも通常のサービスに見せかけたSPAMや乗っ取りなどが発生しているのでOAuthを許可する時はどの権限を



渡そうとしているのかをよく確認してください。特に書き込み(write)のアクセス権を渡す場合は注意してください。



2010年12月9日木曜日

Googleが開発した脆弱性診断ツールを使ってみた


ratproxyはWebアプリケーションの脆弱性を“受動的”に検査するためのツールです。



動作的にはratproxyがプロクシサーバとなり、ブラウザでratproxy経由で診断サイトにアクセスすることで診断します。



脆弱性診断ツールの種類


脆弱性診断を行うツールは、WebScarab、Paros、Burp、ProxMonなどがあります。



これらのツールは“能動的”に脆弱性を探し出します。



能動的とは、予め脆弱性となりうるパラメータやパターンなどを診断サイトに対し実行します。



これらは機械的に実行されるので、診断サイトに大きな負荷がかかったり大量のログが出力されます。



ratproxyのインストール


OSはCentOS 64bitです。


openssl-develがインストールされていないとエラーがでるので予めインストールしておきます。



yum install openssl-devel





ratproxyのダウンロード


ダウンロード後解凍し、makeします。



wget http://ratproxy.googlecode.com/files/ratproxy-1.58.tar.gz


tar -zxvf ratproxy-1.58.tar.gz


cd ratproxy


make



これでratproxyを利用する準備が整いました。



起動


r:リモートアクセスを許可


w:ログを出力


lextifscgjm:ログを詳細に表示するためのオプション群(ドキュメント参照)



ratproxyドキュメント



特にrオプションは、ratproxyをVMにインストールしホストマシンからratproxy経由で診断サイトをアクセスする場合は必須です。


デフォルトでポート8080が利用されますが、pオプションでポート指定も可能です。



./ratproxy -r -w test.log -lextifscgjm




VMをNATで構築している場合はポートフォワーディングを行うことを忘れないでください。



ブラウザにプロキシを入力


各ブラウザのプロキシ設定でratproxyのIPとポート番号を入力します。


そして、診断対象のサイトにアクセスします。



ログ解析


起動時にwオプションで指定したログを解析することでHTMLとして出力できます。




./ratproxy-report.sh test.log >report.html




ログの細かい見方については、messages.listにて記載されています。



結果


ratproxyはログ解析結果を見ていただければわかるのですが、ratproxy経由でアクセスすることで通過する通信を監視しそこから発見できる脆弱性を表示するだけのツールなのでWebScarabのように大量に解析結果が表示されるわけではありません。



逆にratproxyで発見できるHIGHなどの脆弱性は安易に実行される可能性があります。



最後にratproxyのドキュメントを読んでわかったのですが“能動的手法”を補う物であるのでratproxyとWebScarabなどの能動的脆弱性診断ツールを使うとより効果的でしょう。



2010年12月4日土曜日

eAcceleratorはAPCより速いのか


eAcceleratorはAPCより速いのか


PHPはプログラムを実行前に中間形式にコンパイルし実行します。



この作業はプログラムが呼び出される度に行われるので多くのファイルのIncludeしているプログラムやいわゆる重たいプログラムなどには非常にコストの高い作業になります。



今回紹介するAPCやeAcceleratorは中間形式にコンパイルする作業をキャッシュし保持します。そのため、呼び出される度にコンパイル作業を大幅に高速化する事ができます。



これらのキャッシュ機能を提供するのがAPCとeAcceleratorです。



APCとeAcceleratorの違い


APCとeAcceleratorは殆ど同じ動作をしますがeAcceleratorの方がやや機能が上回っています。


eAcceleratorの機能


  1. キャッシュ圧縮(圧縮レベル調整可能)

  2. 共有メモリキャッシュ、ディスクキャッシュの選択




前回書いたさくらVPSで一日6万PVを処理するためにしたことで書いた後にコメントでもいただいたのですがeAcceleratorの方が速いという噂をよく聞きます。



ベンチマーク方法



  • OS:CentOS 64bit

  • メモリ:512M

  • CPU:2992.510Mhz

  • APC:3.1.6

  • eAccelerator:0.9.6.1

  • アプリケーション:ApacheBench

  • スレッド数:100

  • リクエスト数:1000

  • 対象サイト: PukiWiki 1.4.7_notb (デフォルト設定)

  • ページ:index.php 

  • PHP:モジュールモード


正確なキャッシング能力を測るために10回実行してから、計測しました。


必ずローカル環境で試してください



ベンチマーク結果


アクセレーターなし















アクセレーターなし(ms)
1回目13003
2回目16107
3回目13787
4回目14540
5回目12691
6回目12253
7回目12452
8回目10731
9回目12714
10回目12718
平均13099.6
Failed requests合計12回

APC















アクセレーターAPC(ms)
1回目1086
2回目1019
3回目1027
4回目1018
5回目1031
6回目1016
7回目1029
8回目1015
9回目1016
10回目1021
平均1027.8
Failed requests合計0回

eAccelerator


















アクセレーターeAccelerator(ms)
キャッシュ方式ディスク&メモリ
圧縮有効
1回目1051
2回目1034
3回目1054
4回目1022
5回目1028
6回目1016
7回目1037
8回目1072
9回目1056
10回目1110
平均1058
Failed requests合計0回


















アクセレーターeAccelerator(ms)
キャッシュ方式ディスク&メモリ
圧縮無効
1回目1011
2回目1048
3回目1036
4回目1043
5回目1086
6回目1038
7回目1044
8回目1451
9回目1577
10回目1055
平均1148.9
Failed requests合計0回


















アクセレーターeAccelerator(ms)
キャッシュ方式メモリ
圧縮有効
1回目1073
2回目1082
3回目1917
4回目1070
5回目1044
6回目1038
7回目1024
8回目1036
9回目1032
10回目994
平均1131
Failed requests合計0回


















アクセレーターeAccelerator(ms)
キャッシュ方式メモリ
圧縮無効
1回目1837
2回目1182
3回目1187
4回目1028
5回目1529
6回目1044
7回目1026
8回目1366
9回目1061
10回目1024
平均1228.4
Failed requests合計0回


















アクセレーターeAccelerator(ms)
キャッシュ方式ディスク
圧縮有効
1回目1047
2回目1032
3回目1034
4回目1043
5回目1059
6回目1029
7回目1083
8回目1035
9回目1493
10回目1058
平均1091.3
Failed requests合計0回


















アクセレーターeAccelerator(ms)
キャッシュ方式ディスク
圧縮無効
1回目1156
2回目1088
3回目1033
4回目1019
5回目999
6回目1018
7回目1007
8回目993
9回目996
10回目1002
平均1031.1
Failed requests合計0回


結果


APCが最も高速で比較的安定した値を出していました。



eAcceleratorではキャッシュモードをディスクにして圧縮を有効にした方が速い結果には驚きでしたが、APCと4ms程度の差でしたので殆ど差がないと言ってもいいと思います。



ただ、これらのベンチマークは動作するプログラムなどによって大きく異なる可能性が高いのでプログラムごとにベンチマークを取った方がいいでしょう。