「Referer」を含む日記 RSS

はてなキーワード: Refererとは

2016-04-26

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2015-08-25

IT関係ないサラリーマンコミュニティサイト作っちゃいました。

私ごとですが、この度コミュニティサイト作成いたしました。

私の持てる知識を絞り出してなんとか完成しました。

**************************************************************************************

完成したサイトがこちらです。

LapyNetニュース

http://lapynetz.net/

**************************************************************************************

私は普段webとは関係ない仕事してます。なんとか休日を利用して、

webサービス作成しました。

メインのコードはこんな感じ

----------------------------------------------------------------------------------------------------------------------



App::uses('Sanitize', 'Utility');
class RssfeedsController extends AppController {

public $helpers = array('Html','Form','Session','Number','Cache');

public $uses = array(
'Rssfeed',
'Tweet',
'Wadai',
'Rank',
'Oracle'
);
 **************************************************************************************
public function index() {

$title_for_layout = "LapyNetニュース";
$content = "Hello World!!";

$this->set(compact('title_for_layout','content'));
if(date("G")>0 and date("G") < 7){
$today = date("Y-m-d", strtotime('-1 day'));
}else{
$today = date("Y-m-d");
}

$params = array(
'conditions' = > array(
'and' = > array(
'Rssfeed.time' = > $today,
)),
'order' = > 'tweets desc',
'limit' = > '50'
);
$this- >set('posts',$this- >Rssfeed- >find('all',$params));

$paramz = array(
'order' = > 'Rssfeed.id desc',
'limit' = > '10'
);
$this->set('posts2',$this->Rssfeed->find('all',$paramz));

$paramz = $this- >Rssfeed- >query('SELECT id,title FROM rssfeeds order by id desc limit 10');

$this->set('posts2', $paramz);

$parapara = $this- >Oracle- >query('SELECT id,title FROM oracles order by id desc limit 10');

$this- >set('postx', $parapara);

$funking = $this- >Rank- >query('SELECT id,frank FROM ranks where creation=(select max(creation) from ranks)');

$this- >set('funking', $funking);


}

 **************************************************************************************
public function mizuno() {
$parapara = array(
'order' => 'Oracle.id desc',
'limit' => '30'
);
$recent_posts = $this->Oracle->find('all',$parapara);
return $recent_posts;

}


 **************************************************************************************
public function wadai() {
if(date("G")>0 and date("G") < 7){
$today = date("Y-m-d", strtotime('-1 day'));
}else{
$today = date("Y-m-d");
}

$params = array(
'conditions' => array(
'and' => array(
'Rssfeed.time' => $today,
'Rssfeed.kubetu' => 4
)),
'order' => 'tweets desc',
'limit' => '100'
);
$this->set('posts',$this->Rssfeed->find('all',$params));





$this->set("title_for_layout","2CHニュース-LapyNetニュース");


$paramz = array(
'order' => 'Rssfeed.id desc',
'limit' => '10'
);
$this->set('postyy',$this->Rssfeed->find('all',$paramz));

$parapara = array(
'order' => 'Oracle.id desc',
'limit' => '10'
);


$this->set('postyx',$this->Oracle->find('all',$parapara));

$funking = $this->Rank->query('SELECT * FROM ranks where creation=(select max(creation) from ranks)');

$this->set('funking', $funking);



}
 **************************************************************************************
public function hot() {
if(date("G")>0 and date("G") < 7){
$today = date("Y-m-d", strtotime('-1 day'));
}else{
$today = date("Y-m-d");
}

$params = array(
'conditions' => array(
'and' => array(
'Rssfeed.time' => $today,
'Rssfeed.kubetu' => 3
)),
'order' => 'tweets desc',
'limit' => '20'
);
$title_for_layout = "LapyNetニュース";
$this->set("title_for_layout","ニュース-LapyNetニュース");
$this->set('posts',$this->Rssfeed->find('all',$params));

$parapara = array(
'order' => 'Oracle.id desc',
'limit' => '10'
);
$this->set('postxx',$this->Oracle->find('all',$parapara));

$paramz = array(
'order' => 'Rssfeed.id desc',
'limit' => '10'
);
$this->set('postsxxx',$this->Rssfeed->find('all',$paramz));

$funking = $this->Rank->query('SELECT * FROM ranks where creation=(select max(creation) from ranks)');

$this->set('funking', $funking);


}

 **************************************************************************************
public function newnew() {
if(date("G")>0 and date("G") < 7){
$today = date("Y-m-d", strtotime('-1 day'));
}else{
$today = date("Y-m-d");
}

$params = array(
'conditions' => array(
'and' => array(
'Rssfeed.time' => $today,
'Rssfeed.kubetu' => 2
)),
'order' => 'tweets desc',
'limit' => '20'
);
$this->set("title_for_layout","エンタメニュース-LapyNetニュース");
$this->set('posts',$this->Rssfeed->find('all',$params));

$paramz = array(
'order' => 'Rssfeed.id desc',
'limit' => '10'
);
$this->set('postszz',$this->Rssfeed->find('all',$paramz));

$paramz = $this->Oracle->query('SELECT id,title FROM rssfeeds order by id desc limit 10');

$this->set('postszz', $paramz);

$parapara = $this->Oracle->query('SELECT id,title FROM oracles order by id desc limit 10');

$this->set('postzy', $parapara);


$funking = $this->Rank->query('SELECT * FROM ranks where creation=(select max(creation) from ranks)');

$this->set('funking', $funking);



}
 **************************************************************************************
public function top() {
if(date("G")>0 and date("G") < 7){
$today = date("Y-m-d", strtotime('-1 day'));
}else{
$today = date("Y-m-d");
}
$params = array(
'conditions' => array(
'and' => array(
'Rssfeed.time' => $today,
'Rssfeed.kubetu' => 1
)),
'order' => 'tweets desc',
'limit' => '20'
);
$this->set('posts',$this->Rssfeed->find('all',$params));

$param = array(
'conditions' => array('times > current_timestamp + interval -600 minute and Kubetu = 4'),
'order' => 'tweets desc',
'limit' => '30'
);
$this->set('posts2',$this->Rssfeed->find('all',$param));
}


 **************************************************************************************
public function view($id = null ) {
$this->Rssfeed->id = $id; //驥崎ヲ√↑荳譁・i縺励>
$user = AuthComponent::user();

$TwimStatus = ClassRegistry::init('Twim.TwimStatus');


$TwimStatus->getDataSource()->setToken(AuthComponent::user());

$statuses = $TwimStatus->tweet();
$rairai = $this->Rssfeed->read(title,$id);
$alcol = $this->Rssfeed->read();
$this->set('post', $alcol);

$this->set('post2', $user);
$this->set('post3', $statuses);
$this->set("title_for_layout",$rairai[Rssfeed][title]."-LapyNetニュース");

$paramz = array(
'order' => 'Rssfeed.id desc',
'limit' => '20'
);
$this->set('postszz',$this->Rssfeed->find('all',$paramz));

$parapara = array(
'order' => 'Oracle.id desc',
'limit' => '30'
);
$this->set('postzy',$this->Oracle->find('all',$parapara));

}
 **************************************************************************************
public function add() {

if($this->request->isPost()){
if($this->Tweet->save($this->data)) {
$this->Session->setFlash('seikou');
$this->redirect(array('controller'=>'rssfeeds','action'=>'view',$contents11));

}else{
$this->Session->setFlash('sipai');
$this->redirect(array('controller'=>'rssfeeds','action'=>'view',$contents11));
}
}
}
 **************************************************************************************
public function delete($id = null) {
$this->Rssfeed->id = $id; 
$this->set('set', $this->Rssfeed->read());
$this->redirect(array('controller'=>'tweets','action'=>'delete',$this->data['tweet']['rssfeed_id']));


}
 **************************************************************************************
public function oracle() {
if($this->request->is('post')) {

$user = AuthComponent::user();

$TwimStatus = ClassRegistry::init('Twim.TwimStatus');


$TwimStatus->getDataSource()->setToken(AuthComponent::user());

$contents1 = $this->request->data['Rssfeed']['contents'];
$contents2 = $this->request->data;
$statuses = $TwimStatus->tweet($contents1);


if($this->Rssfeed->save($contents2)) {
$this->Session->setFlash('成功です。');
$this->redirect(array('controller'=>'rssfeeds','action'=>'view',$contents11));
$this->redirect($this->referer());
}else{
$this->redirect(array('controller'=>'rssfeeds','action'=>'view',$contents11));
$this->Session->setFlash('失敗です。');
}
}


}
 **************************************************************************************
public function makelist() {
$rssfeeds = $this->paginate();
if ($this->request->is('requested')) {
return $rssfeeds;
} else {
$this->set('rssfeeds', $rssfeeds);
}
}

}

----------------------------------------------------------------------------------------------------------------------

rssフィードはこんな感じです。
----------------------------------------------------------------------------------------------------------------------

#!/usr/bin/php
<?php

header('Content-type: text/html; charset=UTF-8');


require_once ('/var/www/html/s/magpierss/rss_fetch.inc');


define('MAGPIE_CACHE_AGE', 60*5);

define('MAGPIE_CACHE_DIR', '/var/www/html/s/cache/');

define('MAGPIE_OUTPUT_ENCODING','UTF-8');


$urls = array(
'*********************************');

$items = getRssList($urls);

echo '<ul>';
foreach ($items as $item) {

$href = mb_convert_encoding($item['link'], "UTF-8", "auto");

$title = mb_convert_encoding($item['title'], "UTF-8", "auto");
$description = mb_convert_encoding($item['description'], "UTF-8", "auto");
$megami = mb_convert_encoding($description, "UTF-8", "auto");

 

 **************************************************************************************


$all = 'http://urls.api.twitter.com/1/urls/count.json?url='.$href;
$Rits = file_get_contents($all);
$Olfe = mb_convert_encoding($Rits, 'UTF-8', 'auto');
$data = json_decode($Olfe);
$tweets = $data->count;

 **************************************************************************************

$checkman = db_check_urls($href);
$checkman2 = db_check_pr($title);

$nowtimes = date('Ymd');

 


if($checkman == 0 && $checkman2 == 0){
#$hrefs = urlencode($href);
db_put_urls($nowtimes,$href,$title,$description,$tweets);
echo "<li><a href=$href>$title</a><br>$megami<p>$tweets</p><p>$checkman</p></li>";
}else{

}


}
echo '</ul>';

 

 

 **************************************************************************************
function getRssList($urls)
{
$rssitems = array();
foreach ($urls as $url) {
$obj = fetch_rss($url);
$rssitems = array_merge($rssitems, $obj->items);
}
return $rssitems;
}

 **************************************************************************************
function db_check_pr($japanese){

$moji = mb_substr($japanese,0,2);
if($moji == 'PR'){
return 1;
}else{
return 0;
}
}
 **************************************************************************************

function db_check_urls($href){

require '/var/www/html/s/database_conf.php';

try {

$db = new PDO($dsn, $dbUser, $dbPass);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);


$sql = 'SELECT count(*) AS count FROM rssfeeds WHERE urls = :language';
$prepare = $db->prepare($sql);


$languages = array($href);
foreach ($languages as $language) {

$prepare->bindValue(':language', $language, PDO::PARAM_STR);
$prepare->execute();

$result = $prepare->fetchColumn();
if ($result > 0) {
return true;
}else{
return false;
}
}

} catch (PDOException $e) {
echo 'エラーが発生しました。内容: ' . h($e->getMessage());
}

function h($var) 
{
return htmlspecialchars($var, ENT_QUOTES, 'UTF-8');
}
}

 **************************************************************************************
function db_put_urls($nowtimes,$href,$title,$description,$tweets){
require '/var/www/html/s/database_conf.php';
try {

$db = new PDO($dsn, $dbUser, $dbPass);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sikibetu = 5;
$moto = "アニゲー速報VIP";

$sql = 'insert into rssfeeds (id, time,urls,title,contents,tweets,times,kubetu,teikyo) values (?, ?, ?, ?, ?, ?, ?, ?, ?)';

$prepare = $db->prepare($sql);

$prepare->bindValue(1, 0, PDO::PARAM_STR);
$prepare->bindValue(2, $nowtimes, PDO::PARAM_STR);
$prepare->bindValue(3, $href, PDO::PARAM_STR);
$prepare->bindValue(4, $title, PDO::PARAM_STR);
$prepare->bindValue(5, $description, PDO::PARAM_STR);
$prepare->bindValue(6, $tweets, PDO::PARAM_STR);
$prepare->bindValue(7, 'cast( now() as datetime)', PDO::PARAM_STR);
$prepare->bindValue(8, $sikibetu, PDO::PARAM_STR);
$prepare->bindValue(9, $moto, PDO::PARAM_STR);
$prepare->execute();

} catch (PDOException $e) {
echo 'エラーが発生しました。内容: ' . h($e->getMessage());
}
}
?>

---------------------------------------------------------------------------------------------------------------------

**************************************************************************************

参考にした書籍

CakePHP2 実践入門 (WEB+DB PRESS plus)

CakePHP2 実践入門 (WEB+DB PRESS plus)

作者: 安藤祐介,岸田健一郎,新原雅司,市川快,渡辺一宏,鈴木則夫

出版社/メーカー: 技術評論社

発売日: 2012/09/29

メディア: 単行本ソフトカバー

購入: 5人 クリック: 165回

この商品を含むブログ (9件) を見る

Webアプリ開発を加速する CakePHP2定番レシピ119

Webアプリ開発を加速する CakePHP2定番レシピ119

作者: 長谷川智希,デジタルサーカス

出版社/メーカー: 秀和システム

発売日: 2013/09/28

メディア: 単行本

この商品を含むブログ (1件) を見る

**************************************************************************************

一番難しいところはtwitterログインwebサイト連結でした。

cakephp直感できに操作できていいです。

素人のわたしでも操作できましたので。

cakephpを使用しています

webからニュース収集してきます

ツイート数でランキングしてますネット話題を見つけられます

twitterアカウントログインできます

ニュースに対するコメントもできるし、

自分記事投稿できます。(画像も可)

デザインはよくわからないので、

ホームページビルダーを使用しています

今のホームページビルダーは昔と違って高機能ですね。

テンプレートも何種類もあって今はすごいです。

アマゾンawsを使用してます

サーバーWebサーバーデータベースサーバmysql)

に分かれています

今更cakephpを使っている人は少ないかもしれませんが、

データベースとの接続などは楽でした。

twitterアカウントあるといつでも参加できますので、

ニュースを通してコミュニケーション目的としたサイトを目指します。

2014-04-15

予約専用番号がウザイ

さいきん食べログぐるなびの予約専用番号がうざくてたまらん。

あれでreferer取られるかと思うとキモイ

2011-05-16

はてブコメントページをWebApp版へ飛ばすProxomitronフィルタ


公式 Chrome ウェブアプリ はてなブックマーク」でコメントページを表示すると、旧UIのようにコメントだけを一覧表示できていい感じ。
というわけで訓練されたはてブ民の間ではuser.jsなどで飛ばしたりアレするのが流行るものと思われるが、グリモンだかなんだかに馴染みのない私は、今さら誰も触れないであうProxomitronを使った転送方法を記しておく。
適当ながらメタブ対策を盛り込んでみたのがチャームポイント

  1. 公式 Chrome ウェブアプリ はてなブックマーク」を導入する
  2. Proxomitronに「URL: URLControl」フィルタか「URL: Control URLフィルタを導入する
  3. 上記フィルタ対応するリストに以下のmatchを書き込む

#はてブコメントページをChrome Web App版に飛ばす 2011/05/17 14:50
(^$OHDR(Referer:http://b.hatena.ne.jp/viewer\?))$URL(http://b.hatena.ne.jp/entry(/|\?mode=more?url=)(s/$SET(#=https://)|(http(s|)://)\#|(^(^[^/]++.))$SET(#=http://))(\#))$SET(9=$UESC(\@))$JUMP(http://b.hatena.ne.jp/viewer?entry=$ESC(\9))
($OHDR(Referer:http://b.hatena.ne.jp/viewer\?))$URL((http://b.hatena.ne.jp/entry/*)\0)$SET(9=$UESC(\0))$JUMP(http://b.hatena.ne.jp/viewer?entry=$ESC(\9))

下の行はメタブのためのmatch。タイトル下のブクマ数カウンタークリックするとメタブページへ飛ぶようになる。不要ならばコメントアウト

不具合があればどこかでid:Falkyidコールするか@Sizukenにmentionを飛ばすかすると直るかも。


UIの好き嫌いが分かれてる感じですが、好き放題CSSを流し込んで左ペインさんに消えていただいたり、jsいじくってインラインプレビューを無効化したり、ちょこちょこいじってやるとそこそこ快適なブコメビューワになりますよ。新UIよりはずいぶんマシな感じですね。http://img.ly/system/uploads/000/993/748/original_PrtSc_000114.png

おまけ

アップローダがかなりドイヒーなので転載http://www42.tok2.com/home/proxo/4.html

<<< URLControlフィルタ >>>

これはURLを扱うヘッダフィルタを1つにまとめるフィルタですime.nuを飛ばしたり、他のサイトジャンプさせたりと、指定の
仕方次第で様々なことが実現出来ますバージョン4.5以上推奨。
4.4以下で動くかは不明。(バージョンアップ推奨)



(インストール方法)

1、オミトロンフォルダ内のListsフォルダの中に URLControl.txt という
  テキストファイルを作る。

2、このテキストファイルを 設定、BlockFile、追加 から URLControl と
  いう名前オミトロンに登録する。

3、下のヘッダフィルタオミトロンに追加する。
  範囲選択で下のフィルタを選択、コピーファイル、設定フィルタの併合、
  クリップボードからデータを併合、ファイルデフォルトの設定に保存。

-----------------------

[HTTP headers]
In = FALSE
Out = TRUE
Key = "URL: URLControl (Out)"
Match = "$LST(URLControl)"

-----------------------

4 URLControl.txt にURLとその処理方法を登録すれば完成。



( URLControl.txt の記述例 )

書き方は

$URL(http://付きのURL)行いたい処理

という感じです。

例、
# ヤフー上のページにアクセスしようとしたgoogleトップページに飛ばす。
$URL(http://www.yahoo.co.jp/)$JUMP(http://www.google.co.jp/)



#------------------------- URLControl.txt -------------------------
# NOADDURL
# 先頭に # がある行は無視されます。

# 2chime広告ページを踏まずに直接リンク先に行く。
$URL(([^:]+:/+)\0(ime.(nu|st)/|pinktower.com/)(\1))$JUMP(\0\1)

# したらばで、広告ページを踏まずに直接リンク先に行く。
$URL(http://jbbs.shitaraba.com/bbs/link.cgi\?url=\0)$JUMP(\0)

# Livedoor ブログ検索
$URL(http://sf.livedoor.com/show\?blog_url=([^&]+)\0)$JUMP(\0)

# 旧tripodアクセスしようとしてたら移転先のinfoseekに飛ばす。(2種類)
$URL(([^:]+:/+)\0(cgi|members).tripod.co.jp/([^/]+)\1\2)$JUMP(\0\1.at.infoseek.co.jp\2)
$URL(([^:]+:/+)\0([^/]++.|)\1tripod.co.jp/)$JUMP(\0\1at.infoseek.co.jp\p\q\a)

# Proxomitron-Jでウェブフィルタを無効にする。
$URL(http://www.pluto.dti.ne.jp/~tengu/proxomitron/)$FILTER(False)

# Proxomitron User's Wikiウェブフィルタを無効にする。
$URL(http://abc.s65.xrea.com/prox/wiki/)$FILTER(False)


### 以下はコメントアウトして無効になっています。
### 有効にした場合コード行の先頭の # を消して下さい。


# local.ptron/以下に接続するときWEBフィルタを無効にする。
# Bypassリストから local.ptron/ を消してこれを使えば
# local.ptron/ にもヘッダフィルタが使えます。
#$URL(http://local.ptron/)$FILTER(False)

# アクセスするときキーボードのSキーを押していたらページのソースを表示する。
#$KEYCHK(S)$URL(([^:]+:/+)\0\1)$RDIR(\0\xsrc..bypass..\1)

# アクセスするときキーボードのDキーを押していたらデバックモードでソースを表示する。
#$KEYCHK(D)$URL(([^:]+:/+)\0\1)$RDIR(\0\xdbug..\1)

# pya! で「18歳以上ですか? はい、いいえ」ページをスキップ。
#$URL(http://pya.cc/pyaimg/han.php\?han=\0)$JUMP(http://pya.cc/pyaimg/spimg.php?imgid=\0)

#------------------------- URLControl.txt -------------------------



※ \k はマッチ欄では動かないのでこのフィルタでは使えません。
  \kを使いたい処理は Kill-a-URL フィルタをご利用下さい。


更新情報2004/4/14 -> 2006/4/18 リスト更新

2010-04-04

http://anond.hatelabo.jp/20100403084111

refererじゃないの? 

あくまで推測だが、「仕事中にcgiアクセス」「そのウィンドウ上でググるなり何らかのgoogleサーバアクセスする」「google鯖のログURLが保存される」「googleBOTが、URLらしき文字列は手当たり次第GETする」「BOTがたまたまショボCGIURLを拾う」みたいな流れ。

そういう意味じゃchromeだろうがIEだろうがfirefoxだろうが取得できうる。

chromeを使うななんて勘違いも良い所で、適切なのは「googleを使うな」。というか、「インターネットを使うな」

本来検索窓なんかからrefererは残らないはずだけど、ツールバーの欠陥やらバグやら特殊なグリモン使ってたやら、そういう事情で見られることを想定していないURLrefererとして相手サーバログに残る、というのは普通によくあることだし。

URLなんていうたかだか数十バイト文字列の、そのものに機密性を求める方がアホ。

2009-09-12

http://anond.hatelabo.jp/20090911114405

自分日記を読み返して、クリックした時に相手に referer が飛ぶから。増田内だったら、リファラは見えないか問題ないけど、ほかのサイトは相手が referer 読める訳だし。誰が書いたかわかって困る内容じゃないけど、そうでない時もあるじゃん。習慣は大事だよ。

2008-12-18

こっそり教えてはてダ中の人

新規投稿・既存変更の上限が1日10KBになってるのは確定?

これは新しい仕様でしばらく変わらない?

----

@2008-12-18 19:16

naoya hatena, diary そんな上限はないですよー。64kb (65,535bytes, EUC-JP日本語で 65,535/2 文字) までいけます。

わあお手数かけまして。…うーん、じゃあなんだろう。

スーパーpre記法シンタックスハイライト使ったときに、表示上でのみいろいろ中身が消えたり途中で切れたりします(1週間くらい前に投稿したときは平気だったと思うのに)。気がついたらどっかに書いたり報告したりするかもしれません。PCメモリ回線の問題だったらやだなあ。

----

やったー消える文章ができたよーみんなメモれコピれー

>|ruby|
agent.get(:url => 'http://example.com/', :referer => referer_uri)
agent.get({:url => 'http://example.com/', :referer => referer_uri})
|

を、

|<

普通に閉じて、d.hatena.ne.jp で投稿またはプレビューする、と、途中で消えます、たぶん…

2008-08-19

Refererなんてとれないシステム

カウンターが急激に回ってると、どこかでさらし者にされてるんじゃないかと思ってしまう。

2007-09-08

http://anond.hatelabo.jp/20070908183418

知っているところだと、JISCがJavaScriptURLを隠蔽しています。cookieとかrefererとかも見ているんじゃないですかね。

Re: ハイパーリンクっていう仕組みは

プロトコル(http)そのものをどうにかして、これを考慮した拡張ってできないものなのでしょうか。

refererじゃ不足ですかね?不足だとしても、どんなリンクだとか、そういう情報を付け加える事自体は簡単です。あとは、それが標準化される(受け入れられる)か否かの話です。

セマンティック・ウェブってその部分が重要になる気がします。

たんなる、HTML文書の論理的な接続だけで語れなくなってきているということは。

この辺はFOAFとかRSS AutoDiscoveryのような例があります。あと、サーチエンジンのクローラーがとってきた方法も参考になるでしょう。ただ、これも標準化される(受け入れられる)か否かが重要ですが。

心理学とか社会科学とかその辺の知見が反映されたWWWの構築が大事かもしれませんね。

結局、その辺の人達が全然動いてない。誰も必要性を理解していないか理解させる事ができていない。ニーズが表面に出てこないから誰も実装しない。標準化しない。できない。

なぜなら、声の大きな人は必要ないし、必要な人は小さいから誰も相手にしないから。

あとは、ニーズ次第でしょう。儲かるほどのニーズがあるか否か。

現状でもおおよその事は出来るし、必要な人は自分で実装したりしてもらったりしています。そういうニーズを汎化してギャズムを越えて儲ける事が出来る、と誰かが確信したら、mixiの様に誰かが立ち上げるんじゃないですか?

2007-09-05

http://anond.hatelabo.jp/20070904222850

>6位:referer画像アクセス制限(Yahoo!ブログ)

> 見るたびにげんなりする。

おれの1位ダントツはヤフー

上記理由が最も大きいけど。

ヤフーブログかいてるやつfc2とかに移動しようよ。

重いし、機能も微妙だし、

メリットよりもデメリットのほうが多いブログシステムなんてそうそうない。

存在自体が障害だよ。

2007-09-04

困ったちゃんなRSSワースト8

8位:spamコメントを配信する(一部のtDiary)
メンテナンスしろ。
7位:0時に大量配信する(ITPro)
一気に未読が増えてうざい。逐次配信にしてくれ。
6位:referer画像アクセス制限(Yahoo!ブログ)
見るたびにげんなりする。
5位:ref=rssパラメータに付ける(CNET)
SEO的にもまずいだろ。せめてリダイレクトしろ。
4位:タイトルが不適切(Impress)
コラムタイトルくらい入れろ。何の記事か分からんだろ。
3位:RSS広告アニメーションGIFを使う(ITPro)
チカチカしてうざい。
2位:著作権保護のため云々のくだりを入れる(アメブロ)
せめて「続きを見る」にしろ。氏ね
1位:負荷軽減のためのお知らせをRSSで配信(アメブロ)
くだらんことするな。503にしろ。氏ね氏ね
番外:全文配信しない(多数)
それほど困ってないがよく話題に上がるので一応書いておく。
番外:タグを入れる(はてブ)
正直うざい。仕方ないのでYahoo!Pipesフィルタした。

2007-08-16

かっこいい俺のOperaとうざいサイドバー

Operaリンクパネルが便利だ。マイミクが300人以上居ても全員の日記がさくさく読める。

だが、俺の素晴らしきOperaライフを妨げるものがある。左側に居座っているカレンダーとか最近の記事とかだ。そいつらのせいで本文の右端が切れてしまって、いちいちスクロールしなければならない。サイドバーの是非はともかく(俺はよっぽどの理由がある場合を除いて非だと思うのだが)、とりあえずこれを右側に表示するか、テーブルレイアウトをやめてCSSにするかのどちらかだけで俺のOperaがもっと素晴らしくなる。

ところで、俺は最近までありとあらゆるウィンドウを最大化する人だったのだが、ウィンドウを最大化しないというのは、実際にやってみるとスタイリッシュだし、想像以上に便利だ。全ての作業をブラウザでやる人は別だが、そうでなければ騙されたと思ってやってみてほしい。横幅を決めていないサイトでは自分にとって読みやすい幅に変えられるというメリットもある。俺のOperaは「戻る」とか「進む」とかのボタンを全部消してしまったから、ますますスタイリッシュだ。もちろんrefererJavaScriptJavaプラグインが1クリックでオン/オフできるのも忘れてはいけない。必要なときだけオンにすれば超セキュアだ。かっこいいぞ俺のOpera

2007-08-07

ニコニコの flv、ニコビデオンでもニコニコポンでも 403 になってダウンロードできないものがあるね。何でだろう……。

  • UA 見て 403 にしているわけではない
  • Referer 見て 403 にしているわけではなさそう
  • というより、ヘッダ関連で分岐しているわけじゃなさげ
  • クッキーで分岐はしているかもしれない

ってところまでは分かったが、はてさて……

2007-05-12

俺がOperaを使う理由

この記事は下書き。

Opera長所は何といっても「軽くて多機能」。「軽い」だけでも「多機能」だけでもなく、「軽くて多機能」。

軽さだけならLynxのほうが上だし、機能は無制限に拡張できるFxが最強だが、そのバランスでいえばOperaが一番優れていると思う。

以下、俺がよく使う機能について。事前に設定が必要なものを含む。

思い出したら追加するかもしれない。

2007-03-26

ブログで何がしたいの?

http://anond.hatelabo.jp/20070326171503

非公開にすればリンクされないよ。

それとも、自分が許可したReferer以外は全部弾く?

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん