2011-01-19
■[PC]クライアントとサーバ
ずいぶん偉そうな言い方だが、違う人達に3回ほど同じことを指摘したので4回目以降のためにまとめることにした。
俺にこのURLはられた人へ
でも大事なことだからちゃんと覚えてね。
本文
「クライアントはリクエストなしにサーバからパケットを受けることはできない」
これは大原則。気をつけることというか、「してはいけないこと」かな。
NW的な言い回しに言い換えると、パケットをlistenするのがサーバ。
そのlistenしている相手にパケットを送るのがクライアント。
クライアントのプロセスは常駐しないし、ポートの監視も行っていないので、いつ来るかわからないパケットを待つことはできない。(リクエストを送ったときのみ、応答を受信するまでポートの監視を行う)
一方でサーバは常駐し随時ポートを監視しているので、突然リクエストが来ても応答を返送できる
言い換えると、リクエストなしにパケットを送りたいのなら、受信側にもサーバとなるプロセスが必要。
それ(受信側へのサーバプロセス配置)を意図していないなら、シーケンス図が間違っていることになる。
具体例 その1
(リダイレクトやjavascriptによる自動更新で)ユーザの操作なしに画面遷移する場合です。
|クライアント| |サーバ| | | | 自動更新された画面 | |<-----------------------------| | |
と書きたくなるけれど、これは間違い。
Webブラウザは、サーバプロセスではないのでWebサーバから突然パケットを受けることはできない。
つまりは、裏側で(ユーザに見えないだけで)リクエストを送っているので
|クライアント| |サーバ| | | | 画面の自動更新要求 | |----------------------------->| | | | 自動更新された画面 | |<- - - - - - - - - - - - - - -| | |
と、するべき。
具体例 その2
|クライアント| |サーバ| | | | パスワード入力画面 | |<-----------------------------| | | | パスワード | |- - - - - - - - - - - - - - ->| | | | 認証結果 | |<- - - - - - - - - - - - - - -| | |
と書きたくなるけれど、これは間違い。
この場合の間違いは2点
理由は具体例1と同じ。
クライアントには、要求に応答する機能はないので、入力画面にパスワードを返すことはできない。
また、呼び出しなしに応答があるのはシーケンス図としておかしい。
(関数呼び出ししていないのに返り値が帰ってくるようなもん。異次元w)
なので、
|クライアント| |サーバ| | | | パスワード入力画面表示要求 | |----------------------------->| | | | パスワード入力画面 | |<- - - - - - - - - - - - - - -| | | | パスワード(認証要求) | |----------------------------->| | | | 認証結果 | |<- - - - - - - - - - - - - - -| | |
と、するべき。
偉い人から見たら、突込みどころ満載&何を今更 かもしれないけれど、現場でこの説明が必要だったのです。ご勘弁を。
(でも、有識者による変なところへの指摘は大歓迎です。 よろしくご鞭撻ください)
2011-01-16
2011-01-15
■[PC]glassfish / sailfin install - Eclipse
ちなみにWindowsXP
glassfish
GlassFish Tools Bundle for Eclipse v1.2 (December 17, 2009)
http://dlc.sun.com.edgesuite.net/glassfish/eclipse/
sailfin
http://sailfin.java.net/downloads/download_windows.html
ここの手順を参考に導入
http://docs.sun.com/app/docs/doc/820-4277/abrat?a=view
java -Xmx256m -jar sailfin-installer-v2-b31g-windows-ml.jar
sailfinディレクトリが出来るので移動して
samples
http://sailfin.java.net/downloads/sampleinstructions.html
そもそもサンプル動かすだけならコマンドラインでいけそう。
コレの通りにやったら、一点だけ問題(後述)があったものの、成功。
X-Liteが唸った。うるさかった。
とりあえず、sailfinとsip softphoneの連携は問題なさそう。
あとは開発環境か・・・
つぎはこれ動かす予定↓
サンプルを動かしたときに起きた問題
SIPサーブレットが送信する initial-inviteに対して、クライアントが400を返してしまう事象にぶつかった。
400 malformed topmost via header
そこで中身を見たところ、viaヘッダにIPv6アドレスが載っていた。
どうもこいつをX-Liteがパース出来なかった模様。
2010-11-22
■[PC]RubyOnRails 備忘録
Ubuntu 10.10 でRubyOnRailsを動かすまで。
# aptitude install gems
# gems install rails
エラーが出た。
Successfully installed rails-3.0.3
1 gem installed
アップデートしてみる
# gem update
結果は同じ。
一応
# rails -v
Rails 3.0.3
インストールは出来ている模様。
docmentsが巧く入っていない模様。
うーむ。。。
その他
# aptitude install apache2 postgresql
2010-11-21
■[PC][セキュリティ]OAuthを悪用したspam? shoppybag の概要
昨日、勉強会仲間のエンジニア集団で飲んでいたらこんな話題が上がりました。
「shoppybagというサービスの招待メールが知りあいから来たので、
試しに登録してみたらgmailのアカウントが乗っ取られ、アドレス
とりあえずの疑問点は2つ
んで、これらを共通して解決できるのが
な気がしてきた。
そんなところから調査開始。
■[PC][セキュリティ]OAuthを悪用したspam? shoppybag のへの対策
詳細は後で。まずは結論だけ。
技術面
精神面
- 知りあいからの招待でも、本人から言及がなかった場合は疑って掛かる(普通なら、招待したよーとか言ってくるよね?)
- 明らかに必要なとき (e.g. Twilogでのtwitterのタイムライン取得)以外、むやみにAPIの利用許可をクリックしない
なぜパスワードの変更が不要なのか
ここ一番誤解が多そうなので敢えて解説。
乗っ取り=ID/パスワードの盗難 ってのは確かに一般的な認識だし、間違ってはいない。
ただ、ID/パスワードが無くても最近は乗っ取りが可能だったりする。
それはOAuthの考え方を悪用すると出来るようになる。
OAuthは乱暴に言うと
「アカウントの持ち主が許可したんだから俺もやっていいだろ?」
という申請を出すための仕様。
例えで言うと、
委任状を持って他人の転出届をしに行く感じ。
1)本来なら、転出届は本人確認(=認証)が必要。
2)だが、正式な委任状があれば、本人以外でも手続きできる。
3)正式な委任状を作成するには本人確認が必要(ex押印する)
4)手続きする人はあくまで「本人確認を経て作成された委任状」しか持っていない(=押印された書類は持っているが、印鑑は持っていない)
本件では、役所=google、委任された人=shoppybagに該当する。
3')ID/パスワードの入力は委任状作成時にしている(これはUser-google間で行う)
と読み替えられる。
まあ結論として、ID/パスワードを知らなくても乗っ取りが出来ますよってことです。
パスワードを変える必要はないけれど、パスワードを秘密にして安心していてもらっちゃ困ると。そういうことです。
(あ、もし理解違いがあったら指摘してください。おねがいします)
■[PC][セキュリティ]OAuthを悪用したspam? shoppybag の動作内容 仮説編
http://www.itmedia.co.jp/news/articles/0908/10/news015.html
実際にshoppybagのサイトに行ったら、
「招待制なんだゴメンね。」
と言われて登録できなかった。
しかたないので、ついったーで誰かそのspamを転送してくれと頼みつつ、机上で調査。
1)ShoppyBagに登録したら、Google API の OAuth 認証が掛かる
4)許可してしまうと、ShoppyBagがGmailをAPI経由で制御可能になる
5)後は自由にspam送信。
何故こんなコトが出来るのかは、まず、OAuth について知らないとダメ。
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にリダイレクトされ、認証を要求される
4)許可すると、ShoppyBag は認可済みリクエストトークンをアクセストークンに変換する。
ちなみに、上記手続きはまともなアプリケーションと全く違わないので、google側でこれを見分けるのは不可能。

