ピーシーとコーシーとその他雑記

2011-01-19

[]クライアントサーバ

ずいぶん偉そうな言い方だが、違う人達に3回ほど同じことを指摘したので4回目以降のためにまとめることにした。

 

俺にこのURLはられた人へ

よくあるミスから、気にしないでおk。

たくさんの人が間違えることだからブログに書いたのです。

でも大事なことだからちゃんと覚えてね。

 

 

本文 

ソフトウェア設計で気を付けないといけないことの一つ。

クライアントリクエストなしにサーバからパケットを受けることはできない」

 

これは大原則。気をつけることというか、「してはいけないこと」かな。

一応言葉定義をしておくと

 

NW的な言い回しに言い換えると、パケットをlistenするのがサーバ

そのlistenしている相手にパケットを送るのがクライアント

 

クライアントプロセスは常駐しないし、ポート監視も行っていないので、いつ来るかわからないパケットを待つことはできない。(リクエストを送ったときのみ、応答を受信するまでポート監視を行う)

一方でサーバは常駐し随時ポート監視しているので、突然リクエストが来ても応答を返送できる

 

言い換えると、リクエストなしにパケットを送りたいのなら、受信側にもサーバとなるプロセスが必要。

それ(受信側へのサーバプロセス配置)を意図していないなら、シーケンス図が間違っていることになる。

 

具体例 その1

Webアプリケーションのシーケンス図の一部。

つまりクライアントWebブラウザサーバWebサーバ

リダイレクトjavascriptによる自動更新で)ユーザ操作なしに画面遷移する場合です。

クライアント操作せず、サーバから更新後の画面がでるので

 |クライアント|                    |サーバ|
   |               |
   |   自動更新された画面   |
   |<-----------------------------|
   |               |

と書きたくなるけれど、これは間違い。

Webブラウザは、サーバプロセスではないのでWebサーバから突然パケットを受けることはできない。

(必ず、対応するリクエスト存在する)

つまりは、裏側で(ユーザに見えないだけで)リクエストを送っているので

 |クライアント|                    |サーバ|
   |               |
   |   画面の自動更新要求   |
   |----------------------------->|
   |               |
   |   自動更新された画面   |
   |<- - - - - - - - - - - - - - -|
   |               |

と、するべき。

具体例 その2

おなじく、Webアプリケーションのシーケンス図の一部。

認証機能で、パスワードを要求する場合

サーバからパスワード要求が行われるので

 |クライアント|                    |サーバ|
   |               |
   |   パスワード入力画面   |
   |<-----------------------------|
   |               |
   |     パスワード     |
   |- - - - - - - - - - - - - - ->|
   |               |
   |      認証結果     |
   |<- - - - - - - - - - - - - - -|
   |               |

と書きたくなるけれど、これは間違い。

この場合の間違いは2点

理由は具体例1と同じ。

クライアントには、要求に応答する機能はないので、入力画面にパスワードを返すことはできない。

また、呼び出しなしに応答があるのはシーケンス図としておかしい。

関数呼び出ししていないのに返り値が帰ってくるようなもん。異次元w)

なので、

 |クライアント|                    |サーバ|
   |               |
   | パスワード入力画面表示要求 |
   |----------------------------->|
   |               |
   |   パスワード入力画面   |
   |<- - - - - - - - - - - - - - -|
   |               |
   |  パスワード認証要求)  |
   |----------------------------->|
   |               |
   |     認証結果      |
   |<- - - - - - - - - - - - - - -|
   |               |

と、するべき。

 

偉い人から見たら、突込みどころ満載&何を今更 かもしれないけれど、現場でこの説明が必要だったのです。ご勘弁を。

 

(でも、有識者による変なところへの指摘は大歓迎です。 よろしくご鞭撻ください)

 

2011-01-16

[]SailFin Sample Applications - Basic3pcc

書かれた手順だけだと若干情報不足なのでメモ

Webと同じ情報

$HOME_SAILFIN/samples/sipservlet/index.html

$HOME_SAILFIN/samples/sipservlet/Basic3pcc/README.html

にあった。

3pccのデモユーザIDドメインがCallSetupと若干違った。

それにより、X-Liteの設定が変わる。

具体的には以下の通り。

 ID: 一文字目が大文字 e.g. Alice, Bob

 Domain: sailfin.org

でもやっぱり動かない。何故だ

[] SailFin Sample Applications - OnlineBank

つのサンプルを動かしてみる。

こっちは手順通りで動いた。

どうも、Registerが正しく受理されないときがある模様。

5xxも4xxも帰らないところを見ると、そもそもSIP処理系パケットが届いていないか処理系バグが潜んでいる気がする。

はいえサンプルコードなので後者の可能性は低い。

厳密に探るならデバッグログ取ったりなんだりする必要があるのだが、ちょっとそこまで手を出す気にはなれないので一旦保留。

2011-01-15

[]glassfish / sailfin install - Eclipse

SIPサーブレット動かしてごにょりたいので備忘録

ちなみにWindowsXP

glassfish

Eclipseはよくわからんのでごった煮パッケージで導入

GlassFish Tools Bundle for Eclipse v1.2 (December 17, 2009)

http://dlc.sun.com.edgesuite.net/glassfish/eclipse/

これでGlassFish設定済のEclipseが入った。

sailfin

jarファイルダウンロード

http://sailfin.java.net/downloads/download_windows.html

今回はv2の多言語版にした。

ここの手順を参考に導入

http://docs.sun.com/app/docs/doc/820-4277/abrat?a=view

jarファイルを実行

java -Xmx256m -jar sailfin-installer-v2-b31g-windows-ml.jar

sailfinディレクトリが出来るので移動して

lib\ant\bin\ant -f setup.xml

ロケール日本語にならなかったモノの、ビルド成功。



samples

Eclipseでsailfinプロジェクトを作ろうとするが

ウィザードの設定項目に何を入れたらよいのか分からず詰まる。

Eclipse自体がよく分からん

サンプルが存在するNetBeansの方がいいのか?

・・・とおもいきや、いかURLを見つけた

http://sailfin.java.net/downloads/sampleinstructions.html

そもそもサンプル動かすだけならコマンドラインでいけそう。


コレの通りにやったら、一点だけ問題(後述)があったものの、成功。

X-Liteが唸った。うるさかった。

とりあえず、sailfinとsip softphoneの連携は問題なさそう。

あとは開発環境か・・・

つぎはこれ動かす予定↓

http://weblogs.java.net/blog/bhavanishankar/archive/2009/09/21/new-basic3pcc-sample-application-addition-sailfin


サンプルを動かしたときに起きた問題

SIPサーブレットが送信する initial-inviteに対して、クライアントが400を返してしまう事象にぶつかった。

エラーレスポンスとしては

400 malformed topmost via header

要するにviaヘッダが異常というレスポンス

そこで中身を見たところ、viaヘッダにIPv6アドレスが載っていた。

どうもこいつをX-Liteがパース出来なかった模様。

そこで、Servletが動作するマシンIPv6アドレス設定を削除して試したところ、解決した。

現状IPv6環境は想定していないので特に問題はないが、一応参考までに。

2010-11-22

[]RubyOnRails 備忘録

Ubuntu 10.10 でRubyOnRailsを動かすまで。

RubyGemsインストール

# aptitude install gems

Rails

# gems install rails

エラーが出た。

% sudo gem install rails

Successfully installed rails-3.0.3

1 gem installed

Installing ri documentation for rails-3.0.3...

File not found: lib

アップデートしてみる

# gem update

結果は同じ。

一応

# rails -v

Rails 3.0.3

インストールは出来ている模様。

docmentsが巧く入っていない模様。

うーむ。。。

その他

# aptitude install apache2 postgresql

[]OAuth

この記事との差分を覚え書き

http://gihyo.jp/dev/feature/01/oauth/0002


aptitude install sqlite3 ruby-dev

aptitude install libsqlite3-ruby

gem install oauth

Ubuntu 10.10

gemだと、sqlite3-rubyが入らないのでaptで代用。

railsバージョン 2.3.4 を

sudo gem install -v=2.3.4 rails

2010-11-21

[][]OAuthを悪用したspam? shoppybag の概要

昨日、勉強会仲間のエンジニア集団で飲んでいたらこんな話題が上がりました。

 

「shoppybagというサービスの招待メールが知りあいから来たので、

 試しに登録してみたらgmailアカウントが乗っ取られ、アドレス

 帳のアドレス勝手に招待メールを送信された」

 

とりあえずの疑問点は2つ

・どうやってグーグルアカウント情報不正取得したのか

・どうやって乗っ取ったアカウント自動操作したのか

 

んで、これらを共通して解決できるのが

Google Mail API + OAuth

な気がしてきた。

 

そんなところから調査開始。

 

[][]OAuthを悪用したspam? shoppybag のへの対策

詳細は後で。まずは結論だけ。

 

技術

  • パスワードの変更は不要(というか、OAuthの使用上、パスワードは盗めない。理由は後述)
  • アクセストークンの無効化手続きは必要かも(有効期限が分からないので、調査中)

 

精神

  • 知りあいからの招待でも、本人から言及がなかった場合は疑って掛かる(普通なら、招待したよーとか言ってくるよね?)
  • 明らかに必要なとき (e.g. Twilogでのtwitterタイムライン取得)以外、むやみにAPIの利用許可をクリックしない

 

なぜパスワードの変更が不要なのか

ここ一番誤解が多そうなので敢えて解説。

乗っ取り=ID/パスワード盗難 ってのは確かに一般的な認識だし、間違ってはいない。

ただ、ID/パスワードが無くても最近は乗っ取りが可能だったりする。

それはOAuthの考え方を悪用すると出来るようになる。

 

OAuthは乱暴に言うと

アカウントの持ち主が許可したんだから俺もやっていいだろ?」

という申請を出すための仕様

例えで言うと、

 委任状を持って他人の転出届をしに行く感じ。

1)本来なら、転出届は本人確認(=認証)が必要。

2)だが、正式な委任状があれば、本人以外でも手続きできる。

3)正式な委任状作成するには本人確認が必要(ex押印する)

4)手続きする人はあくまで「本人確認を経て作成された委任状」しか持っていない(=押印された書類は持っているが、印鑑は持っていない)

 

本件では、役所=google、委任された人=shoppybagに該当する。

印鑑ID/パスワードと読み替える感じ。

3')ID/パスワード入力委任状作成時にしている(これはUser-google間で行う)

5')shoppybagはID/パスワードを知り得ない

と読み替えられる。

 

まあ結論として、ID/パスワードを知らなくても乗っ取りが出来ますよってことです。

パスワードを変える必要はないけれど、パスワード秘密にして安心していてもらっちゃ困ると。そういうことです。

(あ、もし理解違いがあったら指摘してください。おねがいします)

 

[][]OAuthを悪用したspam? shoppybag の動作内容 仮説編

おそらくは、このTwitterスパムと同系統

http://www.itmedia.co.jp/news/articles/0908/10/news015.html

 

実際にshoppybagのサイトに行ったら、

招待制なんだゴメンね。」

と言われて登録できなかった。

 

しかたないので、ついったーで誰かそのspam転送してくれと頼みつつ、机上で調査。

 

勝手メールを送られるまでの流れはこんな感じらしい。

1)ShoppyBagに登録したら、Google APIOAuth 認証が掛かる

2)ユーザGoogle アカウント認証する

3)Google API の利用許可画面が出る

4)許可してしまうと、ShoppyBagがGmailAPI経由で制御可能になる

5)後は自由にspam送信。

 

何故こんなコトが出来るのかは、まず、OAuth について知らないとダメ

で、OAuthについては以下のURLが参考になります

http://ja.wikipedia.org/wiki/OAuth

http://gihyo.jp/dev/feature/01/oauth/0001

http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth01.html

 

まあ、要するにOAuth自分アカウントに関する権限を他者にも付与するための仕様です

で、今回は 他者=shoppybag アカウントに関する権限=アドレス帳の閲覧、メール送信 だったのかなと。

それを、ユーザ意図せず(理解せず)許可してしまったことが問題だったのではないかと。

 

先の流れをOAuthにあてはめて書き起こすとこんな感じ。

Service Providerがgoogle

ConsumerがShoppyBagね。

1)ShoppyBag に登録したら、Google APIリクエストトークンが発行される

2)ユーザGoogleリダイレクトされ、認証を要求される

3)認証後、リクエストトークンの認可画面が表示される

4)許可すると、ShoppyBag は認可済みリクエストトークンをアクセストークンに変換する。

5)後はアクセストークンを使って、自由にspam送信。

 

ちなみに、上記手続きはまともなアプリケーションと全く違わないので、google側でこれを見分けるのは不可能。

ユーザが許可している時点でgoogleはその意志を受け入れないといけない)

これからは、「OAuthの認可画面はパスワード入力画面と同じぐらい危険だよ」っていう啓蒙が必要になるのかもね。

[][]OAuthを悪用したspam? shoppybag の動作内容 検証編

非リアでボッチなので、招待メール待ち