(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI 設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)

「普通の実装における」OAuth の代替品

適切な OAuth ベースの設計とはどのようなものか

ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

ユーザが自分のアカウントに直接アクセストークンを生成できるようになっており、そのトークンを自分の統合したいソフトウェアに自分で施すことができるので、ばかげた要求や危険な転送やリダイレクトを回避できる。
client_secret が、一般的なパスワードのように平文のまま渡されるデータとして機能するのではなく、それ自体では暗号学的な共通鍵であり、そこから認証コードを生成するようになっているシステムなので、ばかげた要求や危険な転送やリダイレクトを回避できる。この種のシステムでは一般的に、ユーザが自分の認証情報さえ持っておらず、SSO (シングル・サインオン) の仕組みを使うだけである。

とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。

Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。

ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。

JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。

これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

Permalink | 記事への反応(2) | 15:03

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

必要以上のアクセス権をサードパーティに与えることになる。
認証情報を格納する場所が増えるということは、盗まれる危険が増える。
パスワード等を変更したときに API 利用者側でも更新が必要になる。
ひとつのアプリだけでアクセス権を破棄することが難しく、全アプリで破棄することになりやすい。
特別な認証要素を使っていると、制限が多すぎる。

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

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

ユーザがサードパーティのアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
EVS は、その指定したアクセスレベルをユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の 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 がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:

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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

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

前掲のセキュリティ文書は、 Permalink | 記事への反応(3) | 12:44

2013-03-03

■RailsとTwitterBootstrapでエロ 動画 ソーシャルブックマーク Webサービス作った

Rails + Twitter bootstrapでエロ動画ソーシャルブックマーク Webサービス、ソーシャルオナニー＝ソシャニーを作りました。

こちらです　http://www.socianie.com

【なにこれ？】

かっこつけた言い方をすると、

「いっぱいエロ動画あるけど結局みんなどんなお宝動画で抜いてるの？という日常的な疑問への答え」

とかでしょうか。

実際どんな事が出来るサービスかというと、基本的には、はてなブックマークのようにエロいページをブックマークする（その時に、コメントを付記することができる）というものです。

サイト内の他のユーザーをフォローすることができ、TwitterのようにTimelineのようなものがあってそこにフォローしている人がブックマークしたページが表示されます（そのページが、xvideos,fc2などの有名サイトならば埋め込みプレーヤーですぐ再生出来ます。）

つまり、フォローしてる人の最新お気に入りエロ動画がチェックできます。

ブックマークされたページはそれぞれが固有のページを持っており、タグを付ける事ができます。

全ユーザーのブックマークしたものは動画一覧で横断的に見ることができ、並び替え・検索などが出来ます。

ブックマーク数で今日のランキング今週のランキングなどが見れます。

あと、累計ブックマーク数によってユーザーのランクが上がったりします。

TwitterのOAuth認証でログインが出来ます（Twitterにツイート投稿などはしません。また、サイト内の名前アイコンもTwitter のものを流用するかどうかも自分で決められます。）

他のエロサイトとの違いは、３つあると思っています。

①ソーシャルな機能。他にも世の中に色々素晴らしいエロサイトがありますがそれらはソーシャル機能を持つものが少ない。

②上記の話とちょっと被ってますが、他のサイトは基本コンテンツ自体を自動クローリングするけれどソシャニーはそこをユーザー自身に委譲しているため、集まってくる動画の質はそれに比べて上がるんじゃないかというのと、

③エロサイトにありがちな出来るだけごちゃっと感を無く広告も無しでTwitter bootstrap使って小綺麗な感じ

【作成後記】

Webサービス作るならRailsかな楽で便利らしいしというざっくりとしたイメージから Railsで作り始めましたが、

ネットの情報や入門書に取り組んでもサンプルと同じモノは作れても実際自分が作りたいモノになると、で、どうやるの？となりなかなか進みませんでした。

Railsは色々と勝手によろしくやってくれる機能が多すぎて実際何が起きてんの？というのがわかりづらいというのが第一印象でした。

色々試行錯誤した結果、一番参考になったのはRails tutorial( http://ruby.railstutorial.org/ruby-on-rails-tutorial-book )でした。

英語ですがバージョンは新しいしBootstrapの使い方もわかるしサンプルがTwitter クローンサービスを作ろうというなかなかおもしろいものなので途中で飽きること無く取り組めました。

何かを学ぶ時は、モチベーションが続く形の学び方が一番いいと思いました。

僕はエロ動画が大好きなので、エロサイトというのもモチベーションの1つです（ただ、作業中に脱線して気づいたらキーボードではなく下半身に手が伸びているという事もありました。）

また、上記のチュートリアルはテスト駆動開発なのでSpecのテストをモリモリ書いているのですが、とりあえずはテストに関しては何をやってるのかざっと眺める程度で精読しませんでした。

まずは全体像を把握して何が必要か把握したかったからです。結果的に最後までやりきれたので良かったと思います。

あとは、Rails固有の知識ではなくWebサービス全般の知識で足りないな、と思ったときはネット上や本屋の立ち読みで済ましました。

ネットで細切れにお勉強している場合、本屋で体系的にまとまっている本をざっと読むと意外に抜けてる知識が保管されたり脳内にインデックスが作れるのでいいと思いました。

バージョン管理はgitを使いました。

理由はみんなが良い良いというので乗っておくかという安易なものです。

実際のところgitの良い所を使い倒せているのかというと全くそんな事ないですね。

せいぜいstash位でしょうか。あとbisectとか。

リポジトリは最初はDropBoxに作ってたのですが、途中から Bitbucketを使いました。

GitHubを使わなかった理由はBitbucketはプライベートリポジトリが無料で持てるからです。

また、恥ずかしがり屋なのでGithubで公開は敷居が高いと感じたからです。

初のRails プロジェクトというのもありソースがイケてないので恥ずかしいのです。

いつかイケメンなコードをGithubで公開してオレツエーしたいものです。

サーバーはエロOKのところを探すのがなかなか難しく結局海外のVPSを使いました。

Linodeというところですが、他との違いを挙げるとiPhoneアプリ経由で再起動などが出来たりします。あまりこの機能使ってないですが。

OSはベタにCentOSです。

構成はpassenger+apacheで、DBはSQLiteで特にLBなどはないです。

諸々構築後に人気が出た時困らないように負荷分散のお勉強なんぞもやりかけましたがまずは不要かなということで辞めました。

ちなみにサーバーがUS西海岸なのでSSHで作業するとエディタがちょっともっさりすることがありました。

プロジェクト管理は、会社でも使ってるのでRedmineかなと思ったのですがどうせ一人だしRedmineのUIすきじゃないのでTrello（ https://trello.com/ ）を使いました。

TODO,Doing,Done,Bug,Suspendのリストを作ってやること忘れないように管理しました。

ふと出先で思いついた機能とかをiPhoneでスイっと追加など出来て便利でした。

正月に公開してお友達界隈で見てもらったんですが、よかれと思って作ったChrome 拡張にCSRFの対策が不備あり結局ブックマークレットにしたり、

ソースを見てもらったら設計がRestfulじゃないとかControllerがfat過ぎるModelに押しこめなどアドバイスをもらえたり無知な僕には色々とお勉強になりました。

出来たものはしょぼいものですが、「Webサービス作ったことないコンプ」は少し解消出来た気がします。

以上、月19ドルも払ってるのにお友達だけで使われてるのも寂しいので増田でまとめついでに宣伝してみました。

叩かれるんでしょうか。怖いです。いじめないで。

Permalink | 記事への反応(1) | 02:31

2011-08-04

■独学のプログラムでエロ 動画 検索を作ってみた！

【お知らせ】2011/09/07

新しいエロ WEBサービス作りました。

http://d.hatena.ne.jp/uniqueweb/20110906/1315285545

プログラムは全く得意じゃないけれど最近よく見かけるようになったエロ動画検索を自分でも作ってみたくて頑張ってみました。

近年、インターネットの普及によりエロ動画が自宅で簡単に見れるという素晴らしい時代になりました。

自分が若い頃はインターネットなんてものはなくエロビデオが主流でドキドキしながらレンタルビデオ屋に行き、可愛い女の子がレジにいない隙を見計らってお兄さんにパッケージを伏せて空箱を渡しビデオを借りたものでした。

お兄さんにビデオの空箱を渡そうとした時に可愛い子がレジに戻ってきて焦って渡すのをやめてものすごく変な動きをしながらエロビコーナーに引き返していくなんてことも多々ありましたｗ

僕のお気に入りといえば「白石ひとみ」や「あいだもも」といった女優でよく借りてました。エロビを借りるということがものすごく恥ずかしい時代？年頃？でカモフラージュに普通のビデオと一緒に借りるということもしていました。それはそれは大変な思いでオナニーしてたんです！

しかも、ビデオデッキ自体が貴重な時代でリビングに一台しかないのが当たり前でした。

深夜家族が寝静まってからヘッドフォンとビデオを抱えリビングに行き暗がりの中でヘッドフォンをテレビに差し込んでビデオの再生ボタンを期待に胸をふくらませながら押したものです。いいシーンを何回も見るためにビデオを巻き戻すんですが、ビデオを巻き戻すガチャンガチャンという機械音で家族が起きてこないか？とかそれはそれはドキドキしながら見てました。一仕事終えたあとヘッドフォンを外したらジャックが外れていて大音量で喘ぎ声が響き渡っていたなんてこともありました。誰も起きてこなかったのは優しさなんでしょうか？ｗ

さて、大分前置きが長くなりましたがエロというものはものすごい技術発展させるものだと思います。エロのおかげで日本でビデオは普及しエロのおかげで日本でインターネットはものすごく普及したと言っていいと思います。自分もエロを通して技術の発展に貢献し自分自身のスキルアップになれば。という高い志を持ってこのサイトを制作しました。決して自らのオナニーライフの充実と性癖を充たすため作ったわけではありません・・・ｗ

※2011.08.07 利用中のサーバーに障害が発生しているようで現在サーバーに接続できない状態となっています・・・

※2011.08.07 23:53 復帰した模様です。

サイト名：ヌキネーター

サイト名の由来は抜きネタからきています。抜きネーター、ヌキネーターという感じですｗ

エロサイトの制作工程を日記にしてみたんで良かったら読んで下さい。そしてこのサイトを使って夜いろいろと励んでくれたら嬉しいです。

では制作日記を書いていきたいと思います。

サーバー選び

まず前提条件としてお金をほとんどかけたくない。アダルトサイトであるということから

サーバー選びからはいりました。

月の予算は5000円以内で考えていたのでけっこう探すのが大変でした。

日本でアダルトサイトを許可している所はかなり限られていてさらにやりたいことができるのは

専用サーバーかVPS しかないのでそうなると専用サーバーは予算オーバーなので

VPSで探すことになり検索しまくってはじめに見つけたVPSはKAGOYAのVPSだったのですがβ版で募集を締め切っていて泣く泣く諦めました。

KAGOYAはかなり評判がいいみたいなので使ってみたかった。

次に見つけたのが○○○VPS。海外サーバーで日本語サポートがあり転送量の制限なしディスク容量100G

月1300円程度で借りれるということで初期設定費用に5000円程度かかりましたが借りてみました。

結果、ここは最悪でした。

通信が頻繁に切れる
激重
借りて一ヶ月もしないうちにサービスの継続が困難になりそうなのでIPが変わるとかメールがくる
あまりに通信環境が悪すぎるとメールすると環境調査に協力してくれとメールがくる
時間をかけて沢山の項目を調べて返信するも全く返答がない。

あまりの酷さに1ヶ月で解約。

よく調べてみたら評判がものすごく悪い某VPSの再販らしいです。

お金と時間をドブに捨てました・・・

もう失敗したくないと思い今度は比較的有名な海外サーバー LINODE。

日本語サポートはないけれど抜群のサポートです。

iptablesの設定でどうしてもうまくいかなくて拙い英語でメールしてみたら

10分しないうちに返信がきました！

メールに書かれているとおりにコマンドを入力したらあっさり解決。

素晴らしい！はじめから LINODEにすればよかった。

担当のブライアンはなぜか分からないけどとてもフレンドリーで親切に感じましたｗ

サーバー設定

LINODEは複数のディストリビューションから好きなものを選択できるので

とりあえず、64bit版を選択。

サーバー設定はほんとに面倒ですね。

一番面倒だけど重要だということで

Tripwire

その他各種監視ツールの導入をしました。

ほんとに面倒でした。

データベース

はじめはmysqlにストレージエンジンgroongaを使おうと思ったのですが

初めに借りた最悪なVPSはOSが32bit版だったのでgroongaがのソースが見つからずなぜかと思っていたら

どこかで見つけた記事で32bit版ではgroongaの性能を発揮しきれないということで32bit版の提供をやめてしまったらしいと書いてたので

じゃあ、sennaにするかということで最悪VPSでsennaをインストール。

その後LINODEに変更したのでOSに64bit版を選択し念願のgroongaをインストール。

しかし、調べてみると

マルチセクション機能に対応していない（複数カラム一発で無駄なく全文検索したい）
boolean modeの挙動が若干おかしい

などが理由で、結局sennaに戻して2度手間に・・・

プログラムもそれに合わせてその都度書き換えたので2度手間どころか3度手間4度手間でした・・・

senna導入はrpmでさくっといけるので簡単ですが

依存関係で少しはまりました。

まず
# rpm -qa | grep -i mysql
でmysqlがインストールされてたら削除
perl-DBIが必要なのでインストール
# yum install perl-DBI
そして下記の順番でインストール
rpm -ivh mecab-0.98-tritonn.1.0.12a.x86_64.rpm
rpm -ivh mecab-ipadic-2.7.0.20070801-tritonn.1.0.12a.x86_64.rpm
rpm -ivh senna-1.1.4-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-shared-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-client-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-server-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-devel-5.0.87-tritonn.1.0.12a.x86_64.rpm
my.cnfの設定をして終了

で肝心の全文検索ですがデータ件数が5万件程度で少ないせいなのか、あいまい検索と比べてそれほど速さを実感できなかったです・・・

でもきっとすごく速くなったはず！

ちなみに「麻美ゆまおっぱい」で検索した場合、0.01 secで結果が返ってきました。

動画 データの作成

さて、動画データの作成ですがいくつかのエロサイト等制作記事でもあるようにスクレイピングということをします。

スクレイピングとはWEBサイトから特定の情報だけを取得することでネット上にあるサイトをクロールして必要なデータだけを拾ってデータを作るといった感じでしょうか。

スクレイピングのプログラム自体は以前にTidy 関数を使って為替データを10分おきに取得するような物を作ったことがあったのでそれほど時間はかからないかなと思ったのですがけっこう時間かかりました。

スクレイピングにはTidyとhtml SQL、それにPHP Simple HTML DOM Parserを使いました。

下記のサイトを参考にしました。

phpによるスクレイピング処理入門

SQL みたいな文法で HTML を抽出する PHP のライブラリ

htmlSQLよりアツい!?jQueryみたいにセレクタでHTMLをparse(解析)する「PHP Simple HTML DOM Parser」

３つの中で抜群に使えるのはPHP Simple HTML DOM Parserだったんですが

ループ処理させるとメモリがすごいことになって今回のようなスクレイピングに向いてないみたいで

結局、html SQLとTidyの両方を使ってスクレイピングしました。

両方ともPHP Simple HTML DOM Parserに比べるとうまくデータの取得ができないことが多く残念な感じなんですが他に選択肢がないので・・・

使える順に並べると

PHP Simple HTML DOM Parser

html SQL

Tidy

といった感じかもしれません。

おおまかにデータを取得して正規表現で特定データを抜き出しました。

広告との連携

広告にはDMM アフィリエイトを利用しています。

http://affiliate.dmm.com/link.html

利用可能な物はパッケージ画像、サンプル画像（縮小）と書かれていたのでそれに従い画像を利用。

注記に※ユーザーレビューは引用いただけません。とだけ書かれているのでそれ以外は引用ありと判断して説明文とタイトルなどを利用

女優データとジャンルデータ、DVD データ、を紐付けたデータベースを作成し検索ワードに応じて検索結果に関連する商品を表示させるようにしました。

現状、売り上げ0で意味があるのか分かりませんけどｗ

負荷対策とか転送量とかDOS攻撃対策とか

エロサイトということで多少はチューニングとか設定とかしないとまずいかもと思い色々調べて設定しました。

やったこと

iptablesで攻撃してきそうな国からのアクセスを遮断
mod_evasiveの導入で一定時間での連続的なアクセスを遮断
httpd.confの設定 KeepAlive等

KeepAlive On

MaxKeepAliveRequests 60

KeepAliveTimeout 3

&lt;IfModule prefork.c>
StartServers       7
MinSpareServers    5
MaxSpareServers   10
ServerLimit       30
MaxClients        30
MaxRequestsPerChild  4000
&lt;/IfModule>

mod_expiresでキャッシュ設定

様子見ということで2日間で設定してみました。

mysql クエリーキャッシュの設定

query_cache_limit=1M

query_cache_min_res_unit=4k

query_cache_size=16M

query_cache_type=1

APCの導入

とりあえずこんなところを設定してみましたが、爆発的なアクセスがあるわけでもないので有効なのか今のところ分かりません(-_-;)

Apache Benchでテストはしてみましたけど問題はない感じですが実際にチューニングができているか分かりません。

サイト デザイン

プログラマーとして有名なゆうすけさんのサイトとgoogleを参考にしました。

シンプルで使いやすいようにしようと思いこのデザインにしました。

3カラムの中央可変となっています。

クロスブラウザはIE7、firefox3、chromeで行いました。

可変ものって作ったことなかったんですがけっこう面倒なんですね。

サイト 機能

ブックマーク機能とメニューの折りたたみ機能、検索結果の表示方法切替を作りました。

まず、ブックマーク機能ですがログインなしで気に入った動画をブックマークできるようにしました。

ブックマークに追加した動画はブックマークページで確認できるようにしました。

cookie 機能を利用したらいけると思い色々調べてjquery.cookie.jsを利用。

保存したクッキー情報を呼び出してphpに渡して処理し指定要素にブックマーク一覧をloadメソッドで表示させるという感じです。

$(function(){
$("#youso").load("xxx.php");
});

メニューの折りたたみ機能は人気AV女優やAV女優別、人気タグなどをそのまま表示させるとずらっと長くなって邪魔だったのでつけました。

これには同じくjquery.cookie.jsを利用しました。

参考サイト：http://blog.caraldo.net/2009/03/newjqqookiemenu.php

検索結果の表示方法切替にはZoomer Galleryを利用しました。

参考URL：http://phpjavascriptroom.com/?t=ajax&p=jquery_plugin_zoom#a_zoomergallery

検索結果ページで表示される

[ここの画像]
××× の検索結果
44件中 1～10件目を表示

ここの画像の部分をクリックするとgoogle イメージ検索みたいに一覧でイメージ表示できるようにしてみました。

動画表示ページ

基本的に動画の埋め込みを許可しているサイトのみプレイヤー表示をしそれ以外は画像を表示し動画データへリンクするようにしました。

埋め込み部分はあらかじめそれぞれのサイトに対応したプレーヤー部分のコードを記述しVIDEOIDの部分に置き換えるような形にしました。

XVIDEOSを例にすると

XVIDEOSの場合かならず動画のurlがhttp://www.xvideos.com/videoXXXXXX/のようになりますのでXXXXXXの部分を

VIDEOID部分に置き換えるようにプログラムを組みました、

埋め込み部のソース

>||<object width="510" height="400" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" ><param name="quality" value="high" /><param name="bgcolor" value="#000000" /><param name="allowScriptAccess" value="always" /><param name="movie" value="http://static.xvideos.com/swf/flv_player_site_v4.swf" /><param name="allowFullScreen" value="true" /><param name="flashvars" value="id_video=VIDEOID" /><embed src="http://static.xvideos.com/swf/flv_player_site_v4.swf" allowscriptaccess="always" width="510" height="400" menu="false" quality="high" bgcolor="#000000" allowfullscreen="true" flashvars="id_video=VIDEOID" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /></object>
||<

その他の動画サイトもURLの一部分のデータを使っているので同様の処理をしました。

まとめ

実際の作業は２、３週間ですが色々調べる時間が多くて制作に2ヶ月くらいかかりました。

自分でエロ動画検索を作ってみて有名プログラマーさん達がいかに優秀なのか思い知らされました。

皆さん思いついて数日で作ってしまうのでびっくりです。

全くWEBの知識がない人で４、５ヶ月ですごいの作っちゃう人とかもいるみたいですし世の中広いな～と思います。

しかし、エロサイト作りで勉強になりますね～

大分、色んな知識を得ることができました。

これからプラグラムを勉強しようと思う人はぜひエロサイトから入ってみて下さい。

きっと楽しいですよ！

そんなこんなで？頑張って作ってみたエロ動画検索、良かったら使ってみて下さい。

これで少しは技術の発展に役立てたでしょうか？ｗ

アダルト動画検索ヌキネーター

P.S エロサイトを作っていてはじめは楽しくて興奮しながら作ってたのですが最後の方はエロい物を見ても全く反応しなくなりましたｗ

　　不能ではないんですけど・・・今現在も性欲が著しく減退しております・・・

　　そしてスーパーpre 記法がうまういかないのはなぜ？はてな匿名ダイアリー初投稿で全然分からない・・・

　　そしてそしてプログラマーさんとかデザイナーさんとかエロい人とかお気軽にお声をおかけ下さい。

【お知らせ】2011/09/07

新しいエロ WEBサービス作りました。

http://d.hatena.ne.jp/uniqueweb/20110906/1315285545

Permalink | 記事への反応(9) | 02:13

2010-12-19

■ヌケるWebサービスを作ったのでeHubインタビューズっぽく宣伝してみる

あなたのウェブ アプリケーション/サービスは何ですか?

【エロ注意】eroino http://eroino.net/

eroinoは毎日更新される大量のアダルト動画を、AV女優やキーワードで分類して表示したり、お気に入りリストにクリップできるサイトです。現在の動画数は、約28万件。

このプロジェクトを始めた理由は?

今や、無料サンプル動画を、騙しリンクの先から発掘して来る時代ではありません。大量のアダルト動画をザップ＆クリップするのに適した、快適なWebサービスが必要だったのです。個人的な意味で。

製作にかかった時間は?また、本業がありますか?

仕事が終わった後、自宅で毎日4時間前後。公開まで2ヶ月弱という所です。無駄に細部に時間を費やしました。

チームの規模はどれくらいですか?また、あなたの素性および経歴は?

チームはメンバーは一人。
40歳、妻子持ち。
IT関係の仕事をしていますが、コンピューター・サイエンスのバックグラウンドはありません。プログラミングは独学です。

現在使用しているインフラ、技術は何ですか?

linodeの1GBのプラン（$39.95/month）を利用しています。
OSには、ubuntu、ミドルにはRuby on Rails、nginx、Passenger、Ruby Enterprise Edition、PostgreSQL、textsearch_jaなどを利用させて貰っています。
内部では、Wikipedia から取得した AV女優一覧はオブジェクトをFileCacheすると同時に、MeCabのユーザ辞書を生成しています。この辺りの処理は、ゆーすけべーさんのライブラリを参考にしました。

技術的な特徴があれば、紹介してください。

「お気に入り リスト」

ソータブルなお気に入りリストを、ログイン無しで利用できます。
AjaxではHTML フラグメントではなく、軽量なJSONのみを通信しています。jQuery-Haml便利。
解説動画はこちらに置いてます。

開発の際に気を付けたことはありますか?

「データの取得元、動画投稿サイトに迷惑をかけない」

クロウラーは5秒sleepして次のリクエスト。更に、pidっぽい仕組みで、クロウラープロセスの二重起動を回避しています。

プロジェクトは次の半年でどこへ向かうと思いますか?

「アクセス増への対策」

ある程度、チューニングしているのつもりなのですが、遅くなったら、その都度対策します。

「広告」

良いコンテンツマッチ広告があれば、利用したいのですが...あまり期待していません。

「機能追加」

まったくの白紙です。まずは安定稼働。

自分でWebサービスを作りたいと思っている人に向けて何かありますか?

簡単なマッシュアップサイトなら、初心者でも3ヶ月で公開できると思います。
アフィは儲からないけど、転職には役に立つ気がします。（30代前半まで?）
受託で煮詰まっている人は、ストレス解消に良いですよ。時間が取れれば...

利用者に向けて何かありますか?

自分では、かなり実用的だと思っているのですが、実際の所、どうなんでしょう。使ってみて、ダメ出しでも何でも良いので、感想を聞かせてもらえると嬉しいです。

元ネタ

自分でWEBサービスを作りたいと思っている人へ

http://anond.hatelabo.jp/20101203150748

eHub Interviews

http://emilychang.com/ehub/app/category/ehub-interviews/

eHub インタビューズ - Last.fm（翻訳）

http://d.hatena.ne.jp/brazil/20051102/1130901002

Permalink | 記事への反応(3) | 18:54

2010-12-13

■[VPS][Cloud][クラウド][サーバー][server][ruby][rails]

Heroku | Ruby Cloud Platform as a Service

http://heroku.com/

Amazon Elastic Compute Cloud (Amazon EC2)

http://aws.amazon.com/jp/ec2/

Virtual Dedicated Servers - Highly Configurable Plans Low Prices

http://www.godaddy.com/hosting/virtual-dedicated-servers.aspx

Linode - Xen VPS Hosting

http://www.linode.com/

Slicehost - VPS Hosting

http://www.slicehost.com/

Dedicated Server, Managed Hosting, Web Hosting by Rackspace Hosting

http://www.rackspace.com/index.php

SoftLaye r® Technologies - About CloudLayer

http://www.softlayer.com/cloudlayer/

BULK SERVER｜全プラン初期費用0円最低利用期間1ヶ月月額費用5,800円からの専用サーバ〜 Atom プラン〜

http://bulkserver.jp/service/atom

専用サーバーレンタル|即席サーバー - プラン案内 - サービス - 専用サーバレンタルならメガファクトリー

http://www.megafactory.com/html_service/s_sokuseki.htm

【基本構成】ライトプラン : マイティーサーバーの専用サーバー

http://www.mtsv.jp/server/light/

専用サーバー・ヘリオスアルファ特徴・料金｜専用サーバー・VPSのSaaSes

http://www.sa ases.jp/hosting/hos_001.html

さくらのVPS｜VPS（仮想専用サーバ）はさくらインターネット

http://vps.sakura.ad.jp

http://server.sakura.ad.jp/dedicated/index.html

クラウドならニフティのパブリック型コンピューティングサービス

http://cloud.nifty.com/

IIJ クラウド(クラウドコンピューティング)サービス - IIJ GIO

http://www.iij.ad.jp/GIO/

共用サーバー（VPS）｜専用サーバー・VPSのSaaSes

http://www.sa ases.jp/vps/index.html

カゴヤ・クラウド/VPS｜カゴヤ・クラウド

http://www.kagoya.jp/cloud/vps/

prgmr http://prgmr.com/xen/

RapidXen http://www.rapid xen.net/

RapidKVM http://www.rapidkvm.net/

Arpnetworks http://www.arpnetworks.com/vps

Quickweb http://quick web.co.nz/

NordicVPS http://nordic vps.com/

Thrust::VPS http://www.thrust vps.com/

Curlhost http://www.curlhost.com/

BudgetVM http://www.budgetvm.com/

neosurge http://www.neosurge.com/

NFOservers http://www.nfoservers.com/order-virtual-dedicated-server.php

EliteDataHosting http://www.elitedatahosting.com/vps.html

PhotonVPS http://www.photon vps.com/

http://www.webhostingtalk.com/

http://hibari.2ch.net/hosting/

Permalink | 記事への反応(0) | 15:02

2008-09-15

■[ruby][rails][vps][ubuntu][slicehost][価格][料金]Slicehost入門

Slicehost

Slicehost VPS Hosting is now Rackspace Cloud Servers hosting

Slicehost Article Repository - VPS setup, servers, Ruby on Rails, Django, PHP, DNS, Slicemanager and more

Slicehost Articles: IP failover - High Availability explained
All requests for the website come to the front end Slice.
That Slice then proxies the request to larger Slices running in the backend of the network.

Slicehost Articles: IP failover - Slice setup and installing Heartbeat
sudo aptitude install heartbeat

sudo apt-get install ubuntu-xen-server
sudo apt-get install dnsmasq

wiki [Slicehost]

Monitoring Ubuntu Services Using Monit | Ubuntu Geek

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo tasksel
$ sudo apt-get install build-essential

google:Slicehost Ubuntu

Slicehost Articles: Ubuntu Hardy setup - page 1

Slicehost Articles: Ubuntu Hardy setup - page 2

Automatic Rails on Ubuntu 8.04 LTS « Enjoying Rails

joerichsen's gist: 16225 — Gist

Setting up Ubuntu Jaunty for Ruby and Rails development | Joe Ocampo's Blog

5-minutes to Rails // Slicehost VPS Hosting is now Rackspace Cloud Servers hosting

slicehostでRails2.2.2を動かすまで - なんとなく日記

Slicehost Articles: Ubuntu Hardy - Ruby on Rails

Slicehost Articles: Ubuntu Gutsy - Django installation

UbuntuにLAMPサーバを手早くインストールする方法 - builder

LAMP（Linux、Apache、MySQL、PHP）サーバを手早くインストールする最も簡単な方法

google:Slicehost CentOS

cat /etc/redhat-release

Slicehost Articles: CentOS setup - page 1

Slicehost Articles: CentOS setup - page 2

CentOSのPHPにはマルチバイト対応入ってませんのであとから入れましょう (技術メモ)

タグ「slicehost」を含む新着エントリー - はてなブックマーク

naotaka blog » Blog Archive » Slicehostに申し込み

slicehostでUbuntu8.04の設定1 初期設定 - delab

Slicehost : Tag Archives - delab

ホスティングサービス Slicehost のドキュメントがすばらしい : 僕は発展途上技術者

SlicehostへのRedmine導入手順（Ubuntu Gutsy)

rootでsshできないように設定する

つくるぶガイドブログ: 失敗しない Rails が動かせるホスティングサービス選びと環境構築
具体的にどこがおすすめかという質問を受けた場合、共用サーバーならば海外の Slicehost、専用サーバーならさくらインターネット
Slicehost には、OS を一度まっさらに戻し、
OSの種類やバージョンを
用意されているものの中から
簡単に選択し直すことができる機能が管理メニューに付いています。

naotaka blog » Blog Archive » Slicehostに申し込み
再インストールも、やはり２分以内で完了しますから、
好きなだけインストールし直しましょう。

なげやり日記: Slicehost
[Rebuild] でOSを簡単にリストアできるのも、試行錯誤のためには便利だったりします。

Slicehost に移行しました - milk1000cc
Web 管理画面で、OS 再起動・再インストール、コンソール操作、DNS 設定などができます。
あと、プラス $5 で毎日、自動でイメージごとバックアップ
バックアップ入れても月額 $25、
さくらと違って OS インストール直後は最小構成になっている、設定ミスってもすぐに OS 再インストールできる

「LINODE」を含む日記

■なんか定期的に出るんだね

■【開発】アンテナサイトのジェネレーターを作った

サービスの説明

■anond:20160426145507 の続き