「リダイレクト」を含む日記 RSS

はてなキーワード: リダイレクトとは

2017-11-14

anond:20171114175656

逆に、ぜんぜん可換じゃないものを「同じ商品」だと認識されて雑なリダイレクトをされることも時々ある

たとえばある翻訳書が絶版になってしばらく経ったら、その本へのリンクを踏むと黙って洋書リダイレクトされて「在庫ありますよ!」って言われる状態になってしまった

似たパターンで、洋書電子化されてるが和書は紙の本しか出てないっていう状態なのに「Kindleで今すぐ読めます!」と案内されるようになったこともある(=もはやこの和書電子化リクエストするボタンは押せない)

電化製品なんかでもよくある

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-09-03

うんこのようなものをもらした

うんことは何か。Wikipediaで「うんこ」を調べると「糞」にリダイレクトされる。Wikipediaでは「糞」の説明

糞(くそ、ふん、くそは「屎」とも表記)とは、動物の消化管から排泄される固体状の排泄物屎尿)。糞便(ふんべん)、大便(だいべん)、俗にうんこ、うんち、ばばや、大便から転じ大などとも呼ばれる。しかし、硬さや大きさ、成分などの違いで呼び名を使い分けている訳ではない

とされている。

Wikipediaの項目「糞」に記載説明に従えば、以下の要件を全て満たすものうんこであると考えられる。

  1. 動物から排泄された
  2. 消化管から排泄された
  3. 固体である

一応、他の資料にも当たってみた。三省堂大辞林には「大便」について以下のように説明されていた。なお、三省堂大辞林検索結果は、Weblio経由で得られたものである

人間肛門から排泄する食物のかす。くそ。糞(ふん)。便。うんこ

ここで、「食物」は、三省堂大辞林には「食べ物」と説明されていた。「食べ物」は、同辞典には「①食べるもの食用品。しょくもつ。食いもの。②(飲み物に対して)かんで食べる物」と説明されていた。すなわち同辞典では、食べ物(=食物)は飲み物と対比されるものとされていた。してみれば、同辞典における大便の説明で「飲食物」ではなく「食物」とわざわざ記載されているのは、大便という概念を、固体である食べ物に由来するもの限定する意図があると推定された。

従って、三省堂大辞林の項目「大便」に記載説明に従えば、以下の要件を全て満たすものうんこであると考えられる。

  1. 人間から排泄された
  2. 肛門から排泄された
  3. 固体である食物のかすである

両者の間には、若干の表現差異がある。三省堂大辞林は、主体的要件を、「動物」より狭い概念である人間」に限定している。また、三省堂大辞林は、経路要件を「消化管」ではなく、消化管の末端である肛門」に限定している(消化管から排泄されながら肛門を経由しないという状況が想定できないので、実質的に経路要件は同一であるとも言えるが)。さら三省堂大辞林は、客体的要件を「固体」より狭い概念である「食物のかす」に限定している。もし、「食物」が「飲み物」も含む概念であると解されるならば、「食物のかす」は「液体」を含む広い概念であることになるが、上述のように三省堂大辞林は「食物」に「飲み物」を含めていない。

しかしいずれの説明採用するにしろ、「うんこ」が固体であるということには疑いがないと考えられる。

ここで、人間という動物である私は昨晩、消化管の終端である肛門から液体を漏らした。

私は、昨日の夕方から下痢気味だった。夕方から21時頃にかけて、私は3回くらいトイレで排泄行為をしたのだが、その結果、液体の中に食物のかすが混じったもの便器にあった。これら3回の排泄行為の結果、私の便意は収まった。そして23時頃、私は自宅最寄り駅にたどり着き、自転車に乗り換え、自宅に向けて自転車を漕いでいた。踏切に引っかかったので、私は両足を地に着け、腰を上げた。その瞬間、おならではない何かが肛門を通り抜ける感触を私は感じた。

おそらく、腰を上げる際に下腹部に僅かに力を入れたことが、この通り抜け現象の引き金になったのだと思われた。しかし、前触れは何もなかった。その時、私は何ら便意を催していなかった。なので、私は肛門に突然生じた感触驚愕した。「うんこだ!」 私の頭は、突然ひらめいたうんこという単語で満たされた。

反射的に、私は括約筋を閉ざした。肛門付近の状況は全くわからなかった。肛門で感じられた漏出量は僅かだったので、大惨事には至っていないだろう。しかしある程度の被害パンツに生じていることは疑いないように思われた。幸い、周囲は暗いので、万が一うんこ衣服の外部に染みていても、通行人うんこ漏れたことが露見することは無いだろう。私は自転車サドルに腰を下ろすことなく家に急いだ。

帰宅後、私はすぐにトイレに駆け込んだ。肛門からは、液体の中に食物のかすが混じったものが出た。それから私はパンツを確かめた。すると、奇妙なことに、紫色の私のパンツには一見異常が認められなかった。どういうことだ? あの感触は、おならにはない独特の存在感があったのだ。無いわけがない。私は目を凝らした。すると、パンツの、丁度肛門と接触するあたりに、濡れた箇所があるのを私は発見した。食物のかすは付着していなかった。布地の色のせいで、パンツを濡らした液体の色はわからなかったが、かなり透明度が高いように見受けられた。

ここで、私が濡らしたものが上述のうんこの3要件を満たすか否か検討すると、以下の通りとなる。

  1. 主体的要件について
  2. 経路要件について
  3. 客体的要件について
    • 私が漏らしたもの実質的に透明の液体であり、食物のかす等の固体はここに一切含まれなかった。従って、客体的要件は満たされない。

してみれば、私が漏らしたものうんこ3要件を全て満たすものではないのでうんこではない。私はうんこを漏らしていなかった!

ただし、ここで別の問題があるように思われた。私は何を漏らしたのだろうか。

肛門から漏れる気体はおならと称される。肛門から漏れる固体はうんこと称される。しかし、上述の検討から導かれたように、「うんこ」は液体を含まない概念である肛門から漏れる液体はうんこではないとわかったが、これの名前が私にはわからなかった。慣例的には、私が漏らしたものは水様便、又は下痢便と呼ばれるものなのであろう。しかし、「水様便」及び「下痢便」のいずれの表現からも、私は、液体の中に食物のかすが混じったものを想起する。液体のみからなるものを「水様便」又は「下痢便」と称することは、厳密には誤りではないか

ここで、私はWikipediaで「下痢」を検索した。ここには、以下に引用する記載があった。

下痢(げり、英: diarrhea)は、健康時の便と比較して、非常に緩いゲル(粥)状・若しくは液体状の便が出る状態である。主に消化機能の異常により、人間を含む動物が患う症状であり、その際の便は軟便(なんべん)、泥状便(でいじょうべん)、水様便(すいようべん)ともいう。

Wikipediaは「液体状の便」について言及しているが、「液体*状*」という表現は、完全な液体ではないことを示唆している。上述のように、三省堂大辞林及びWikipediaのいずれにおいても「便」は「固体」である。「液体状の固体」は、液体に近いが液体になりきっていない固体であると考えられる。Wikipediaは「液体状の便」が「軟便」「泥状便」「水様便」である説明しているが、してみれば、液体のみからなる私の排泄物は、「軟便」「泥状便」「水様便」のいずれにも当たらないように思われる。

しかし、Wikipedia下痢」には、さらに以下の説明があった。

東洋医学では泄瀉(泄は大便が希薄で、出たり止まったりすること。瀉は水が注ぐように一直線に下る)とも呼ばれる。

「瀉」は、水が注ぐように一直線に下るものであるとされる。私の排泄物は、これに近いように思われる。私は瀉を漏らしたのか。

ここで私は「泄瀉」についてWebで調べてみたが、あまり情報がなかった。一番詳しいように見える、群馬漢方薬局の方がやっておられるBlog(https://ameblo.jp/hideo3355/entry-12163635334.html)には、以下のように説明されていた。

泄瀉(せっしゃ):「泄」とは排便時に希薄な大便が緩やかに排出される症状を指し、「瀉」とは排便時に清稀な大便が水のようにまっすぐ流れ注ぐもの。両者をあわせて泄瀉と呼ぶ。

「瀉」は、「清稀な大便が水のようにまっすぐ流れ注ぐものであるとされる。「清稀」は日本語ではないようだが、Google翻訳中国語日本語翻訳にかけると「クリア」と翻訳された。「瀉」はクリアな大便。私は「クリアな大便」という表現からはどんな物体も想起することができなかった。ここから先は、漢方医学の専門書などにあたらなければ正確なことはわからないように思われたが、疲れた私は「私はうんこをもらさなかった」という確信と「私は何を漏らしたのかわからない」という不安を抱えたままシャワーを浴びて寝た。

2017-06-16

anond:20170616085536

サーバ側が301リダイレクトを返すならキャッシュして当然じゃん。

301は恒久的な移転なんだから

そうなってほしくない場合

まともなサーバサイド開発者なら302だの306だの使い分ける。

あと .htaccess設定ファイルであって仕様のことではないからな。

君もエンジニアなら用語は正しく使おう。

htaccess最大の失態は

リダイレクトの設定を履歴記憶させることだよね。ここ増田最近常時SSL対応したけど、その前にhttpsアクセスしたユーザーはてなトップに飛ぶわけじゃん。その設定は履歴を消さない限りずっと残り続ける。(まあそんなこと試すのはweb開発者しかいないだろうし、対処法知ってるだろうから危惧する必要もないと思うけど)

なぜキャッシュに残すようにしなかったのか。これがわからない

2017-06-13

いまやバナー広告ひとつやふたつは気にしなくなったと思うんだよね。というかそれはもう広告だとすら認識されてない。

アドブロック使ってるような層が「広告」と言ってるのって、

ポップアップするやつ、スクロール追従するやつ、フェードインしたりスライドしたりするやつ、

リダイレクトで中継されるやつ、背景をジャックするやつ、動画のやつ、あとはステマ、あたりでしょ。

そのあたりを広告業界がやめればアドブロックを使う奴は激減すると思う。

2017-05-03

フリーブックスだけではない違法エロシンジケート

さきほど、フリーブックスが閉鎖した。

しかし、フリーブックスは氷山の一角にすぎない。

フリーブックスとドロップブックスの運営者が同じ可能性が高いという指摘は既になされているが、その2サイト以外にも同じグループによって今現在運営されている違法サイト複数あり、過去運営していた無数のサイトも含めれば、巨大な違法エロシンジケートとでも言うべきもの形成しているといえる。

ここでは彼ら全てが滅びることを願い、調べることができた限りの情報提供する。

フリーブックスに関しては前もって以下の記事を読んでおいてほしい。

http://anond.hatelabo.jp/20170501041533

「フリーブックス」についてもう少し踏み込んで書く – 無能ブログ

無数の違法アダルトサイト

上で挙げた無能ブログ(0chiaki)の記事で指摘されているように、フリーブックスの運営元はドロップブックス含め複数サイト運営している。

いずれもエロコンテンツ違法かつ大量に転載しているサイトだが、それぞれ住み分けがなされている。

(adultcity.toが同グループ運営という情報もあるが根拠確認できなかった)

(5/3 17:15訂正:同グループと断定してよさそう。詳しくは末尾に追記)

これだけでも驚くべき規模だが、このエロシンジケート過去運営して既に閉鎖したサイトは少なくとも数十はある。

たとえば以下は16年5月11月存在したピュアラブ purelove.infoという、女性向けAV違法転載していたサイトである

ベースドロップブックスなど男性向けサイト共通だが、デザインライティングなど需要に合わせて高度にカスタマイズされていることがわかる。

ピュアラブは胸キュンアダルト動画が楽しめる女性のためのアダルトサイトです♥

女性だって時にはエッチ妄想を楽しみたくなりますよね?!

だけどエッチものを見たり、リアル友達エッチな話しをするのは恥ずかしい…。

そんな恥ずかしがり屋な女性がこっそりアダルト動画を見て楽しんだり、

本音を共有したりできるサイトを作ってみました。

みんなのちょっとエッチな憩い(?)の場になるといいなと思うので

ぜひどんどん利用してくださいね♥(´ε`*)

https://web-beta.archive.org/web/20161014030014/purelove.info

SHAREMOVIEとその前身サイトたち

彼らの出発点はどこにあるのか。

調べた限りでは彼らは2011年から複数アダルト動画サイト運営していた形跡がある。

現在運営されているSHAREMOVIEは15年2月ごろに登場したようだが、15年から16年に渡って複数アダルト動画サイトが、以下のような告知を残して閉鎖している。

サイトは閉鎖をさせていただくことになりました。

ご利用ありがとうございました。

人気動画投稿サイトSHAREMOVIE (注: SHAREMOVIEへのリンク)

これだけでは別の運営からサイトを買収し誘導しただけとも考えられるが、

しかデザインサーバーなどを見る限りいずれも以前から彼らエロシンジケート運営していたと思われる。

詳しく見てみよう。

奥様は熟女 okujuku.jp 05年11月1111月管理者変更)~1211月

https://web-beta.archive.org/web/20120208010840/okujuku.jp

調べた中ではこのサイトが一番古くからの記録をInternet Archiveに残している。

当初は他の管理者による量産型エロサイトだったが、1111月エロシンジケートが買収したようだ。

管理者変更の告知や、投稿ボタンの追加などデザインの変更などからそう推測できる。

.jpドメイン+国内サーバーでは匿名性に不安があったのか、1211月に.tvドメイン+海外サーバーへと移転する。

奥様は熟女 okujuku.tv 1211月~15年8月

Internet Archiveによると、15年8月2日から3日の間に、上述のSHAREMOVIEへの誘導を残して閉鎖した。

以下、その他同様にSHAREMOVIEへの誘導を残して閉鎖したサイトを列挙する。

これらのサイトについての記録から、彼らについての情報を得ることが可能かもしれない。

広告を剥がす

これを書いている最中フリーブックスが閉鎖したが、以上のようにフリーブックスは氷山の一角に過ぎない。全てを叩き潰す必要がある。

しかし既に指摘されているように、彼らは防弾ホスティングによって守られているので、サーバー所有者に対処を望むことは期待できない。

たとえばdropbooks.tvについての申し立てCloudflareに行い、もしCloudflareサーバー情報を開示したとしても、おそらく本体サーバーオランダあたりにあり、ホスティング業者は苦情を黙殺するか、開示するとしても業者はそもそも利用者ビットコインアドレスくらいしか知らないだろう。

したがって資金源(広告)を断つことが一番有効方法となる。こうした場合はしばしば「不適切サイト広告を出すな」という苦情申し立て広告主に対して行われるが、今回はもっとよい方法がある。

SHAREMOVIE(3次元AV)にはmaist.jp、aspm.jpを経由してDMM同人作品アフィリエイトが表示されている。

ドロップブックス(同人)にはプレステージなどのブランドを持つMGS www.mgstage.comのアフィリエイトが表示されている。

当然のことながら、DMMコンテンツフリーブックス・ドロップブックスに転載され、MGSコンテンツはSHAREMOVIEに転載されている。

違法コピーを間接的に助長するどころの話ではなく、自分商品を盗んでいる本人に金を払っているのである

このことにDMMMGSなどの広告主側を気付かせさえすれば、広告を減らすことができるはずだ。

(他にワンクリック詐欺業者広告もあるが、これについてはどうしようもない)

その他

以下では今回調べている最中に気がついた細々したことを書いていく。詳しく追いたい人向け。

フリーブックスはどうやって稼ごうとしていたか

フリーブックスのベータ版のようなサイト、fpc.isには次のように書いてあった。

https://web-beta.archive.org/web/20161203115444/fpc.is

ルピースは月額900円〜であらゆるコミック雑誌小説動画が見放題になるサービスです。

話題の新作も過去の名作もより取り見取りで見放題。月額見放題制だから手間なく見れて、本屋レンタルショップに行くよりも断然手軽でお得です♪ぜひ下記ページよりご登録ください♪

お支払いにはVISA/MasterCard/JCB/AMEX/DINNERS/DISCOVERがご利用いただけます。「Vプリカ」でもご登録可能

最初から有料化するつもりだったようだ。

DINERSやDISCOVERが取り扱いに入っていることから予定していた決済代行業者がある程度絞れるかもしれない。

2DBOOK系列との関係

16年5月から開始されたANIMELEAXにも前身と思われるサイト存在する。

2Dアニメローダー 2anime.net 1211月~16年??月

https://web-beta.archive.org/web/20160422140541/2anime.net

一見してエロシンジケートではなく2DBOOK系列デザインである

しかし16年6月7月、同一のGoogle Analyticsトラッキングコード使用され、16年10月にはanimeleax.comへの301リダイレクトが設定されている。

これだけだと16年に2DBOOK系列エロシンジケートサイトを売却しただけのように思えるのだが

それ以前に2015年の一時期、上記のokujuku.tv中出しeyezなどとIPアドレスを共有している。

このあたり関係がはっきりしない。

いずれにせよドロップブックスと2DBOOK運営者の間に何らかの関係があるのは確かだと思われる。

異説

フリーブックスの運営についてこのようなことを書いている人もいる。

http://anond.hatelabo.jp/20170502045025

しかし「奥様は熟女」などの発生がHやその周辺サイトよりも古いこと、ホスティング業者Whoisプロテクト業者の選定が異なることなからフリーブックスの運営をHと同じ人間が行っているわけではないと思う。

はい2DBOOK系列との関係が疑われるように、トップより下のレベルでの交流はあってもおかしくない(というかあるだろう)

id:ssig33などのTorrentに無い→自炊、という推測が不正確だという指摘は正しい。

動画エロゲソフトウェア以外、要するに本や音楽など、違法コピーのために技術も太い回線必要ないものの一次放流元は現在圧倒的にWebである

GMOクラウドを利用している?

既に書いたとおり彼らは防弾ホスティングを利用しているのだが、それも完璧ではない。

これを書くために調査している最中、興味深いもの発見した。

dropbooks.tvでnslookupを行うと当然CloudflareIPアドレスが返ってくるのだが、mail.dropbooks.tvでnslookupを行うと192.249.79.248というIPアドレスが返される。

このIPアドレスCloudflareのものではなくGMO-Z.com USA, INC.すなわちGMOグループ会社のものである

主要グループ会社一覧 - GMOインターネット株式会社

アメリカ会社ではあるが、彼らが普段使う業者と比べてこのサーバーの「防弾性」は格段に落ちる。このサーバー情報ミスによって公開されてしまっている、隠しておきたいはずのものだと思う。

したがって、GMOインターネット株式会社ドロップブックス運営者の情報を握っている可能性が高い。

追記

5/3 17:15追記

アダルトティ投稿ティエロシンジケート系列と断定して良さそう。

192.249.79.248に以下のメールサーバーが同居している。

mail.dropbooks.tv
mail.examplekanai.com
mail.lecielblue.net
mail.toukoucity.to
mailserver.smv.to
smtp.lecielblue.net
mail.noah-i.net

@Mnowben にもいくつか根拠が挙げられている。

系列なのはわかったけど随分毛色が違うのでこれはこれでふしぎ。

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

2017-04-17

増田スパム対策って

単にアルファベットしか入力しなかったらバリデーションエラーリダイレクトバックするだけなのね。手抜きか

2017-03-23

weblio マジウザイ

英語を調べるときに高確率で上位に来るが、用例がイケてないことが多く、正直言って不正確、というか使えない。

英単語意味を調べるているときでも、意味を載せずに、単語のものしか載せてないページにも多く出くわす。

また、単語のものだけでないにしても、ローマ字変換した結果しか載せてないケースも有る。

これはひどい

下記はweblioSEOスパム痕跡 (元ページはレイバンサイトリダイレクトされるようになっていた)。

これから調べ物するときは "-site:weblio.jp" することにしよう… (それすら面倒い)

2017-02-11

これと同じ理由FireFox使ってるが、Chromeに戻りてえなー俺もなー

https://productforums.google.com/forum/#!topic/chrome-ja/VAyWwZ98bjk;context-place=topicsearchin/chrome-ja/category$3Aandroid%7Csort:relevance%7Cspell:false

AdNetwork経由で紛れたリダイレクトChromeブロックできないだけ

わざとかどうかは知らないが

2016-12-02

DeNAキュレーションサイト

本当に検索上位占めてるんね。

今革製品の手入れの事検索したら上位5つ中2つ消えてた。

消すのはいいんだけどトップリダイレクトじゃなくてちゃんと404出せよって感じ。

2016-07-15

Google alert spamサイトは dcvb.sytes.net から asjh.ddns.net に移行した

dcvb.sytes.netというspamサイトで報告していたGoogle alert spamサイトだが、その後変化があった。

まず、このサイトGoogle八分あいGoogle検索で一切引っかからなくなった。徳丸さんが報告しているこのあたり。

https://twitter.com/ockeghem/status/753359665971367936

https://twitter.com/ockeghem/status/753360671287283712

そして、dcvb.sytes.netDNSがひけなくなり、閲覧できなくなった。

しかし、このまま終わるはずもないと思っていたところ、少し形を変えて同様のspamサイトが出現した。違いは、こうだ

例えば、下記のドメインからCNETニュース引用したページにリダイレクトする

dvkyhl.rv.uhaskzzfw.xyz

こちらのサイトも報告しておこうと思うが、おそらく叩いても叩いても復活するモグラたたきの状況になるだろう。

2016-07-10

dcvb.sytes.netというspamサイト

私はネットウォッチャーとして様々なサイトを漁っている一介の増田である面白いサイトを見つけるためにGoogle alertを利用しているのだが、少し前からGoogle alertを狙うと思われるspamサイトに苦しめられているので紹介したい。

一例を示そう。xyzドメインで、「LIGO 重力波」で検索する。

google:site:.xyz LIGO 重力波

検索結果は以下のURLで示すように、dcrwns.it.xzuvdspcp.xyz というドメインが表示される。

画面キャプチャ: http://www.fastpic.jp/images.php?file=3101744883.png

しかし、このサイトアクセスすると、以下のように http://dcvb.sytes.net/dcrwns.it.xzuvdspcp.xyz魚拓)にリダイレクトされるのだ。

画面キャプチャ: http://www.fastpic.jp/images.php?file=0078597575.png

このサイト、主要なコンテンツYahoo!知恵袋から引用で、「続きを読むクリックすると、以下の質問リンクしている。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10158380025]

まり、この dcvb.sytes.net というサイトは、Yahoo! 知恵袋をパクったspamサイトなのだが、なぜかこのサイト上のページには以下のように検索避けがしてある(タグ文字は全角で表記した)。

<meta name="robots" content="noindex,nofollow" >

すなわち、この dcvb.sytes.net 自体検索ではたどり着くことはできず、必ずリダイレクトによりたどり着くように設計されているのだ。

そして、Googleで表示された dcrwns.it.xzuvdspcp.xyz というサイトだが、単にアクセスするとリダイレクトするだけなので、Googleロボットキーワード収集されるはずがない。

ここから増田の推測だが、リダイレクト用のサイトは、次のように、Google botか否かで表示を変えているのではないか

なんとかしてGoogle botと同じ内容を見てみたいと思い、Googleキャッシュ確認しようにも、キャッシュは表示されない。noarchive設定がされているのだろう。細かいところまでよく考えられている。

リダイレクトに用いられているドメインだが、以下のように非常に多数だ。

これだけで18ドメインある。お名前.comだと一つ99円で大安売りしているので、漏れているものをいれても 2000円位だろう。それだけ費用と手間を掛けても、それを上回る広告収入が入るのだろう。

どうもお手上げだ。誰か助けてくれ。

2016-06-10

はてブ登録されている毎日新聞のcheck_cookie_set.php挙動を調べてみた

はてブの人気カテゴリーに、ごくまれ毎日新聞の以下のようなURLピックアップされる。

おそらく解析のためのもので悪意はないんだろうけど、これを踏むのは何となく気持ちが悪いし、自分はこれを開くことはない。

ただ、何故このURLを用意してるのか気になったので、以下の2つのURLアクセスして保持しているクッキーの違いを比較してみた。(後者は、リダイレクトクッキー書き込みPHPという前提)

結果、以下のことが分かった。

URL/クッキーの値 →ckcheck=(年月日)PHPSESSID=(セッションID?)
http://mainichi.jp/ないある
http://mainichi.jp/auth/check_cookie_set.php?url=%2Fあるない

これ以外のクッキーは、値の違いはあれど、AWSELBや_gaなどの名前クッキーがどちらにも存在していた。

まぁ、そもそも誰が何でこのURLはてブしてんだって話にもなるんだけど。

2016-06-06

anond:20160606151215

NHKYahoo!ニュースブクマしてないか読み返しもしてないんだろうなぁ。

そこらへんのリンク先、半年後には消えるのがほとんど。

既に他の増田が指摘してるが、元増田でもちゃんと言及があるだろ。

Impressと言えば新聞社等のニュース配信と異なり、過去記事も削除されることな


それに今回のインプレスの件は、ニュースサイトのような
記事ブクマページのリンククリック → 記事が消されてて読めない」
というのとは逆のケース。




例:はてななどの各社担当者自作サーバーノウハウを紹介 -BB Watch


記事の旧URL
bb.watch.impress.co.jp/docs/news/20091126_331459.html


……の、ブクマページ (※現時点で471ブクマ
b.hatena.ne.jp/entry/bb.watch.impress.co.jp/docs/news/20091126_331459.html


……の、リンククリックすると、リニューアル後のURLリダイレクトされる
bb.watch.impress.co.jp/docs/news/331459.html


……ので、旧ブクマページから記事を読む際には不便は生じない。




問題は「記事のページからブクマページへ移動したい場合」。

記事リニューアル後のURL
bb.watch.impress.co.jp/docs/news/331459.html


……をブクマしようとすると飛ばされるのは、新たなURLブクマページ (※現時点で0ブクマ
b.hatena.ne.jp/entry/bb.watch.impress.co.jp/docs/news/331459.html


ブクマページのURLも変わってしまったことで、過去の多数のブコメへの動線が途切れてしまった。
また、ひとつ記事複数ブクマページが存在することで、ブコメ散逸が起こってしまう。




ブコメデータが削除されてしまったわけではないので「資産が失われた」は大袈裟かと思うけど、不便ではある。

以下のような例があるので、技術的には対応可能なようだけど…




Google ウェブマスター向け公式ブログ
googlewebmastercentral-ja.blogspot.jp/


……をブクマしようとすると、
b.hatena.ne.jp/entry/googlewebmastercentral-ja.blogspot.jp/

このエントリーには、他のブックマークエントリーページが存在します。以下のリンクから、別のコメントなどの情報も参照できます
Webmaster Central 日本版 公式ブログ 481 users
http://googlewebmastercentral-ja.blogspot.com/

と表示される。

無視してそのままブクマしようとしても、実際には『このエントリーには~』で示された「blogspot.com」の方がブクマされる。

http://anond.hatelabo.jp/20160606164811

実質的にはリンク先を辿れなくなってるんだから一緒でしょ

辿れるんだってリダイレクトされるんだから、古いURLアクセスすれば自動的に新URLに飛ばされるの

扱いとしてはネット上に代替記事が残っているのとなんら変わりない

サイト内に残してるのと、外部に残ってるのは違うでしょうが

サイト内に記事が残ってて、ブクマボタンも変わらずあるなら、ブコメも引き継がれてるほうが、サイト提供者にとってもほんとは望ましいはずでしょうが

ブコメが引き継がれるのが嫌でわざとURL変えた、なんて可能性、無いでしょ?

自分記事削除してるサイトとは違うんだよ。

膨大なブコメ資産が失われた問題

Impress Watchリニューアル(http://www.watch.impress.co.jp/20th/)した。

サイトの見辛さ等は既に語られている事なので割愛するが、

記事URL構造過去記事も含めて変わってしまった事はあまり知られていない。

例えば、以下の記事は次に示すURLリダイレクトされる。

はてななどの各社担当者自作サーバーノウハウを紹介 -BB Watch変更する

http://bb.watch.impress.co.jp/docs/news/20091126_331459.html

http://bb.watch.impress.co.jp/docs/news/331459.html

上記の記事は471usersを集めているが、

リダイレクト先は勿論0user、つまりブクマ無しとなってしまう。

せっかく記事を見つけてブコメも閲覧しようにも見られないのだ。

ではImpress Watchの全過去記事が新URLになっているかと言うとそうではなく、

調べるとPC Wacthでは2009/04/08の記事から変更されているようだ。

リダイレクトされない

富士通フロンテック「FLEPia」試用レポート

http://pc.watch.impress.co.jp/docs/2009/0407/fujitsuf.htm

リダイレクトされる

Acer、初のNVIDIA IONベースの超小型デスクトップAspireRevo

http://pc.watch.impress.co.jp/docs/2009/0408/acer.htm

http://pc.watch.impress.co.jp/docs/news/110556.html

まり2009/04/08〜2016/06/01の7年2ヶ月のブコメ簡単に参照できなくなった。

これは膨大なブコメ資産が失われたと考えている。

同様の問題Wikipediahttps化の時も発生している。

Impressと言えば新聞社等のニュース配信と異なり、過去記事も削除されることな

長期保存(最古は96年4月:http://pc.watch.impress.co.jp/docs/article/960417/index.htm)されているので

その事実にはただただ感謝するしかなく、今回のURL変更に文句を言うつもりもない。

ただWikipediahttps化の時と同様の話ではあるが、

比較的規模の大きなサイトURL構造を変更してリダイレクト対応を行った際には、

はてなブックマーク運営側においては別URL提示を示す等の対応を行って頂きたい。

(詳しく知らないが、これは過去はてブデータベースに対して何らかの書き換えや追記等の作業が発生するかもしれない)

はてな運営要望しても無駄なのは知ってるけど。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで 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 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

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

他の選択肢

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

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

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

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

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

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

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

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

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイル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/

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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

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

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