  |
はてなキーワード: httpsとは
最近Opera11をインストールしてみたんだけどOpera上でEvernoteのブックマークレット(Webクリッパー)を実行するたびに毎回毎回サインインを求めてくる。毎回ユーザー名とパスワードを入れる必要があるのでストレスがたまる。他のブラウザではそんなことは起こらないのに。
Evernoteは今の自分にとって重要サービスの一つなので、これは非常に困る。何とかするためにEvernote Webクリッパーのソースを眺めてみた。
↓こんな感じ
javascript:(function(){EN_CLIP_HOST='http://www.evernote.com';try{var x=document.createElement('SCRIPT');x.type='text/javascript';x.src=EN_CLIP_HOST+'/public/bookmarkClipper.js?'+(new Date().getTime()/100000);document.getElementsByTagName('head')[0].appendChild(x);}catch(e){location.href=EN_CLIP_HOST+'/clip.action?url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title);}})();
とりあえずEN_CLIP_HOST='http://www.evernote.com'の部分をhttpsに変えてみたら、ちゃんとサインインが保持されるようになりました。めでたしめでたし。
↓改変後
javascript:(function(){EN_CLIP_HOST='https://www.evernote.com';try{var x=document.createElement('SCRIPT');x.type='text/javascript';x.src=EN_CLIP_HOST+'/public/bookmarkClipper.js?'+(new Date().getTime()/100000);document.getElementsByTagName('head')[0].appendChild(x);}catch(e){location.href=EN_CLIP_HOST+'/clip.action?url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title);}})();
同じ問題が起こる人がいれば試してみてください。
Twitter の OAuth 許可ページがあまりにも酷い => 応急処置 - リタマス
これのGreasemonkey スクリプトが危険だったので修正したよ！
このスクリプトは、本文中にupdate（または更新）が入っている時に警告を出すようになっていたんだけど、これだとチェック漏れのバグがあるとwrite権限を要求しているのに警告が出ないのでread onlyのように見えてしまう
人間が本文読めばわかるから大丈夫だろと思うかもしれないけど、このスクリプト使い続けていたら警告が出ない＝read onlyだと判断して本文読まなくなるはず
read onlyの時にも色を変えて警告を出すようにした（writeなら赤、read onlyなら黄）
これで警告表示の色を見れば赤ならwrite黄ならread onlyだとすぐにわかるし、警告がでなかったらなんかおかしいとすぐに気づくはずだ
危険なものと安全なものが混ざってる中から危険なものを選り分けても安心はできないけど、安全なものを選り分けたんなら安心できるよね！（これなんか専門用語ありそうだけど僕は知らない
最初のスクリプトだと https://twitter.com/oauth/authorize?* と https://twitter.com/oauth/authenticate?* で動くようになってたけど、
twitterのOAuthの認証ページは他にもhttpsのかわりにhttpを使ったものとか、twitter.comのかわりにapi.twitter.comとかがあるから、それらのページでは警告が出なかった
気がついたら、ホールとか、気がついたらワームとか、気がついたらトロイ
ってのは、この業界 少なくないからさ、それ自身は 仕方が無いと思うんだよ。
事故はしょうがない。
でもなぁ、
ウイルスだったら、ウイルス対策ソフトを入れてるかどうかは、事故なのか過失なのかの大きな分岐点になるよな。
今回みたいなサービスだったら、セキュリティーの試験をしたかどうか？は、事故なのか過失なのかの大きな分岐点になると思うんだよ。
で、どう考えても、これ、まともには試験されてない。
なんだろうな、チェックリスト作ればいいのかね？
最低限このぐらいは・・・リスト
＞パスワードを平文で保存しない
保存する場合は、特別な手段をとらないと社員でもパスワードを読めないようにする。
保存する場合は、ユーザーに電子的な手段でパスワードを回答しない。かならず、受取人指定の郵送とする。
ユーザーのパスワードが必要な場合は、無人システムに投入する等する
ただ一般的には、住所氏名電話番号生年月日で代用することがほとんど
＞パスワードを暗号化する場合は、暗号化ではなくハッシュ化する。
暗号化とハッシュ化の違いが分からないなら、勉強させる。知らない人間を担当者にしてはいけない。
GETのパスワードはログに残るため。ログからパスワードが流出する
ユーザーの代わりに管理者アカウントでその操作を行い、だれが、いつ、その操作を行ったかはシステムで記録する
よく管理者アカウントが１つでだれだか操作したわからないというシステムがあるがナンセンス。
かならず、いつ、だれが、というのはシステムで明確にログを取る。
＞URLの後ろに、ユーザー毎 取引毎 セション毎のランダムなセッションキーが付いていると良い
COOKIEも併用すること。URLはキャッシュ等の対策のため
＞セッションキーを他のユーザーの物に変えてログイン出来ないことを十回以上は確認する
又は、何らかの理由でセッションキーのみでログインする場合は、十分に長い文字数にすること。
数字を１つ２つ変えても他人のログがみられないように、十分にセッションキー同士を離れさせ
機械的に、総当たりでログインが試みられて場合検出して遮断する機能を入れること。
遮断装置が無いのに、セッションキーのみでのログインは、ガードしていないのと同じ。
＞ユーザー パスワードを適当に変えて、他のユーザー名で同一パスワード などの組み合わせが通らない事を１０組み以上は確認する。
＞一定時間以上操作がない場合は、自動ログアウトする機能をつける
漫画喫茶など対策
＞クレジットカードなど課金情報は同一サーバーに持たない。可能な限り記憶しない
普通にURLにユーザーIDとパスワードをgetリクエストに埋め込むなんてやり方はしねーよ。
2000年前後ですらそんなクソな事をしてるサイトを作ったら普通に馬鹿だと思われるわ。
別にchromeなんてどこでも使われてるが、他のサイトの会員情報が筒抜けになってないだろ？
そこをブラウザのせいにするなんてただの風説の流布だからヤメロ。
httpsもきちんと使われてるかどうかも怪しいし、どうあがいてもサイトを作る側のミス
認証するならpostで送るべきだし、
セッション管理も出来てない上にurlで適当にIDとパスワード入れただけで見れるようならそのサイトが悪い。
プロキシ犯人説でもいいんだが、相当強固にリクエストを無視するプロキシがあったとして、
セッションハイジャックができたらまずいんじゃねーか？
そういう企業プロキシが存在している事は周知の事実なんだから、楽天ほどの商業サイトで決済からんでるんだし
ログイン直後は302で1度飛ばすとか、ランダムなセッションキーをURLのけつにつけるとか、Cache-Control ちゃんと入れるとか、複数の手を使ってプロキシのキャッシュすり抜けようとしたあげく、
どうしても無理そうならjsでランダムハッシュ付きURLから情報取得してセションと一致しないようならhttpsへ逃げるなど多重の手段を講じてもおかしくないだろ？
企業のプロキシをすり抜けられなくて、セッションハイジャックです。でも、それはプロキシが悪いんですは、言いたいことはわかるが、決済系のWebサイトのセリフじゃない。
コメント見る限り、他の企業のプロキシからも同じ現象は再現しているみたいだし、プロキシーのCache-Control を無視する設定のプロキシ対策を忘れたんじゃなかろうか？というのに1票入れとく。
状況がわからんが、もし、Cache-Control を無視するプロキシー対策忘れなら、一般サイトならセーフだが、課金系サイトなら、サイト側のマネージャークラスの責任。
「機能的には問題ない」って言うのは、「そのサイトが提供したい機能は提供できている」って意味かな？
それはその通り。
ぱっと思いつく問題は2つ。
・証明書の配布方法が安全でないので、ユーザが正しい証明書（そのサイトが提供している証明書）をインストールしているか判らない
で、秘密鍵を持ってる証明書さえインストールさせてしまえば、そのユーザに対してはhttpsアクセスであらゆる偽サイトが作れる。
追記：
・「ルート証明書をインストールしろと言われたら、セキュリティの警告を無視してインストールして良い」と言う間違った認識を広める
ある意味、これが一番たちが悪い。
その後の報道を見るに、セッションをhttps基本に変更してるので
google.cnサーバーへのgmail接続を全監視してたんだろ
エッジルーターかなにかで
国外の人がたまたまgoogle.cnをホストとして使ったgmailのメールの内容を全部検閲するのはワケが違うだろうと。
言い方を変えると日本からgoogle.cnを使った場合、日本人の行動内容も全部中国政府に筒抜けで
かつigoogleなど個人が特定できるサービスだとそれが全部筒抜けになる。
というのを危惧したんじゃね？
google.cnへの接続をすべて中国政府が監視できるというのが、国内だけでなく、国外もだったということで、
の２つ。
サーバー側がクライアントの証明書不要の設定ならば、そして、たいていそうだが、クライアントの証明書は不要
サーバーが正しいことを証明する必要性があるのであれば信頼できる証明書がクライアント側に必要。
クライアントは、サーバーが送ってきた証明書が、信頼できる証明書から派生した証明書であるか確認して、確認できたら通信する。
他方、サーバーが正しいことを証明する必要性がなくて、単に暗号化されていれば良いというシステムであれば、
クライアント側にサーバーの証明書は一切不要で、サーバーが送ってきた証明書を盲目的に信じれば良い。
要するにシステム要件しだい。
仕事でHTTPSのJavaクライアントの作成が必要になった。
本当に本当に暇でしょうがなくて、
そんなのすぐ実装できるぜ」って、
ググった結果＆コメント。
(01)Java Tip 96: Use HTTPS in your Java client code
http://www.javaworld.com/javaworld/javatips/jw-javatip96.html
英語なので読むキがしない後で読むかも？
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=7497&forum=12
よー、わからん。
http://ibiblio.org/java/slides/iw2000/whatsnew/04.html
サンプルコード。
Keytoolとかルート証明書とかはいらないのか？
(04)■[Java]証明書無視のHTTPSクライアント 1.3 & JSSE
http://d.hatena.ne.jp/stdcall/20060805/1154761291
ちょっとびっくりしたので書いておく。
例の「Google 日本語入力」のインストール手順ですが、http://www.google.com/intl/ja/ime/ から「Google 日本語入力をダウンロード」をクリックして、利用規約をよんで「同意してインストール」を選ぶ事になるわけですが、chromeユーザーはここでちょっと心構えをして下さい。
なぜかというと、「同意してインストール」ボタンを押すと、それでインストールが開始し、ほっておけば完了します。
確認や警告などは出ません。
いや、本当は出ています。もう一度良くアドレスバーを確認してください。エクスクラメーションマークが出ていますね？
「このページには安全でないコンテンツが含まれています」
インストールには関係ないですけどね。
この仕様は、
からなんでしょうか。IEもFirefoxも、確認ダイアログくらいは出るんですが。
[追記]ダウンロード履歴にも残らないですね。
ところで、陸運局別にページを用意しているけれど、これって陸運局名も入力orプルダウンさせる方法じゃダメなの？
(たとえば、 http://eco.cev-pc.or.jp/search/akita.html )
しかも、httpsにしないのはクソとまでは非難しないけど、中身が丸見えの設定って、イマドキのwebサイトとしてどうよ？
( http://eco.cev-pc.or.jp/search/ )
ちなみに私、10万円の補助金の方で６月末日に購入・７月上旬にディーラーで申請書を記入しましたが、
「申請受付」 ・・・ 申請書を販売会社団体で受け付けました。
申請書に不備などがなければ、申請受付の後、通常１ヶ月（注）程度で審査機関に
自動車販売会社団体から申請書類及び申請データが送付されます。
（注：現状では２ヵ月程度かかっています）
だ、そうで。すでに１～２か月ってレベルじゃないんですけど。
これがそうでもなくてね。
たとえば、yaho.comとかyahooo.comとかyaafoo.comとかtypoや勘違いする人はいるだろうし、
smbc smdc sbmc msbcとかhatena.jp？hatena.co.jp？hatena.ne.jp？とか。
（ログインリンク）https://api.login.yahoo.co.jp/WSLogin/V1/wslogin?appid=hoge&appdata=choix&send_userhash=1&done=http%3A%2F%2Fwww.choix.jp%2Fyahoo&ts=hoge&sig=hoge （ログイン画面）https://login.yahoo.co.jp/config/login?.src=ba_choix&.done=https%3A%2F%2Fapi.login.yahoo.co.jp%2FWSLogin%2FV1%2Fwslogin%3Fappid%hoge%26appdata%3Dchoix%26send_userhash%3D1%26done%3Dhttp%253A%252F%252Fwww.choix.jp%252Fyahoo%26ts%3Dhoge%26sig%3Dhoge%26.scrumb%3D0 （注意事項画面）https://api.login.yahoo.co.jp/WSLogin/V1/wslogin?appid=hoge&appdata=choix&send_userhash=1&done=http%3A%2F%2Fwww.choix.jp%2Fyahoo&ts=hoge&sig=hoge&.scrumb=hoge （新規登録画面）http://www.choix.jp/yahoo?appid=hoge&token=hoge&appdata=choix&userhash=hoge&ts=hoge&sig=hoge
参照：http://yuichirou.g.hatena.ne.jp/Yuichirou/20060401
