「OAuth」を含む日記 RSS

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

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-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

2016-10-22

増田ぐらいのレベル掲示板なら1週間ぐらいで作れると思うけど、どんだけ人くるかな〜

ランニングコストがペイできるぐらいならやろうかな〜

はてなOAuthつかっていけるよね

2016-09-10

標的型攻撃の訓練がうざい・・・

最近会社で標的型攻撃の訓練が多くて非常にうざい。


で、両方引っかかった。

また、両者のセキュリティリスクはさほど高くないと思ってる。


のよう認識している。

自分の中で気を付けるべき行為だと思ってる行為としては、下記のような感じ。

他の人は、どの辺をリスクだと思って、何を気を付けているか気になった次第。

■補足

インテルcpuデータ実行防止で、現状バッファーオーバーフロー的な問題は非常に起こりにくなっているのだろうか?

開いただけで任意コードを実行する画像ファイルを作れるか?

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

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

2015-07-19

Facebookアカウント

アーリーアダプター自称する私がFacebookを始めたのは2011年の秋。

その頃は知り合いも全然いなくて、見知らぬ中国人アカウントから友達申請が来た時に、友達の候補が中国人だらけになったのは懐かしい思い出だ。

知り合いも少ない中ちょびちょびと投稿する日々が続いた。

しかし今は私のFacebookアカウントはもはやOAuthのためのアカウントに成り果ててしまった。Google+も同様。

もはや何も投稿しなくなった。掲載したいと思うような私生活がない。「いいね」もいらない。コメントもいらない。

自分誕生日は非公開にした。Facebook誕生日を祝われたくない。コメントを返すのが面倒。

それから他人誕生日の通知もやめた。興味のない人の誕生日の通知はいらない。

加えて、顔写真の「タグ付け」も拒否するようにした。自分の顔をマウスカーソルクリックされるなんて不愉快まりない。絵踏じゃないんだから

ちなみにFacebookと同時期にアカウントを取得したTwitterだが、こちらはちょびちょびととぅぶやきを続けている。

2014-06-02

はてサーの姫とかよくわかんないけれど

代わりに、はてな内外で有名なギーク女子を挙げてみるよ。(※はてなユーザーとは限らない)

……意外と思いつかなかった。他にもいろいろ居そう。

そもそもどこからどこまでをギーク女子定義すべきかという問題があるな。WEBデザイン方面ですごく有名だけど、プログラミングPHPがちょこっとかじれる程度みたいな方もいるし。

2014-04-12

ツイッター始めました。つぶやき内容から自動フォローするコードを書きました。

 

ツイッターアカウント作りました。 → 凍結されましたwwww

 

ツイッターを久しぶりに始めました。

昔よりUIが変わってしっかり動作してる!

エラー全然出ないし使いやすい!

優秀なプログラマーが集まっている感じがしますね。すごい!

 

twiiter API 1.1 を調べて

自動フォローするコードを書きました。

 

1人だけというのはツイッターから怒られないようにするためと、

怒られない程度はcronで調整すればいいや。。と思って。(´・_・`)


	require_once("twitteroauth.php");

	// -------------------------------------------------------------------------
	// love2av_info
	// -------------------------------------------------------------------------
	$consumerKey		= "";
	$consumerSecret		= "";
	$accessToken		= "";
	$accessTokenSecret	= "";

	$oAuth = new TwitterOAuth($consumerKey, $consumerSecret, $accessToken, $accessTokenSecret);

	$q = "抽出するつぶやき";

	// 指定語が含まれるつぶやき検索
	$tweets = $oAuth->get('search/tweets', array("q" => $q));

	// ツイート一覧からID一覧を取得
	$arrayIds = array();
	foreach ($tweets->statuses as $tweet) {
		$arrayTmp[] = $tweet->user->id;
	}

	// そのID一覧と自分関係を取得
	$users = $oAuth->get('friendships/lookup', array("user_id" => implode(",", $arrayTmp)));

	// フォローしていないIDだけを抜き出して配列に格納する
	$arrayNotYetFollow = array();
	foreach ($users as $user) {
		if (!in_array("following", $user->connections)) {
			$arrayNotYetFollow[] = $user->id;
		}
	}

	// 検索したツイートを調査する
	foreach ($tweets->statuses as $tweet) {

		// botっぽいのは除外する
		if (strpos($tweet->user->description, "bot" !== false)) {
			continue;
		}

		// フォローしていなければフォローする
		if (in_array($tweet->user->id, $arrayNotYetFollow)) {
			$oAuth->post('friendships/create', array("user_id" => $tweet->user->id));
			// 1回の起動で 1人だけフォローする
			break;
		}
	}


これを

php -f this.php

みたいな感じに cron に登録すると、起動する毎に 1人フォローが増えます

フォロワーは増えないけどね (´・_・`)

運用では自動フォロー返しも入れてるんだけどな.. チラッ

追記

一瞬でアカ凍結されてワロタ

ツイッターめっちゃ厳しくなってるじゃないですか Σ(°□°;)



http://anond.hatelabo.jp/20140411231521

2013-03-14

それでもWEBサービスが作りたいんだ!

WEBサービスを作ったけれど全然からない!

そんな声を最近よく聞きます

僕もいくつかWEBサービスを作ってきたので分かるのですが

収益アフィリエイト広告であげようとしているWEBサービスは相当なアクセスがないと全く儲からないです。

少なくとも継続して1日あたり数千アクセスないと厳しいかなと思います。内容にもよるかもしれませんが。

僕が運営しているエロいWEBサービスの1つだとけっこうアクセスはあるのですが月間の利益はせいぜい3、4千円。

制作に費やした時間学習コストを考えるとコンビニアルバイトでもした方が何十倍も稼げるレベル

というかサーバー代を考えるとひょっとしたら赤字・・・

http://anond.hatelabo.jp/20130124122021

この日記の人も書いているけど特にはてな経由のアクセスからは売り上げは全く上がらないと思います

から、これからWEBサービスを作ろうと思っている人に言いたい。

利益を得ることを目的WEBサービスを作るというのは間違っていないと思うけれど

アフィリエイト広告収益モデルとした場合、悲しい結末が待っている可能性が高いです。

僕は収益をあげること以外の目的も作った方が良いと思います

お金が儲からないのなんか分かってる。


それでもWEBサービスが作りたいんだ!

そんな熱い気持ちで作ってほしいです。

もし、WEBサービスで沢山のアクセスを集めることができたなら

お金以外の貴重な経験を得ることができます


例1)はてな経由やニュースサイトなどに取り上げられ爆発的なアクセスがあった場合

1、ベンチマークテストなどでは得られない生の負荷が経験できます。
↓
2、想定外アクセスにあわわわわわ状態になります。
↓
3、アラートメールがしこたま来ます。
↓
4、サイトが表示されなくなります。
↓
5、パニックになりながらもsshサーバー接続して原因を調べようとします。
↓
6、sshサーバー接続できない状態に呆然します。
↓
7、気持ちを落ち着かせるためXVIDEOSに行きます。
↓
8、賢者になります。
↓
9、再度サーバー接続します。重いながらなんとか接続成功します。
↓
10TOPで探ります。
↓
11、いろいろ調整します。場合によってはサーバーを上位プランに変更します。
↓
12トラブルを乗り越え落ち着きます。
↓
13、FC2アダルトに行きます。
↓
14、大賢者になります。
↓
15、おもむろにメーラーを起動します
↓
16、件名:** PROBLEM Service Alert
↓
17、ふぁああぁあぁぁぁあぁぁぁぁぁぁぁぁぁ )゜д゜(

上記をループします。

例2)自分の作ったサービスに対するなんらかのアクションがある(特にはてな経由の場合


見ず知らずの人からメールやらコメントやらがもらえます。

・すごくいい

・すげー

・便利

・無言ブクマ

・俺もこんなの作りたい

・後で試す

・使えない

・しね

・ゴミ

など、悦に入ることができたり、精神的なダメージを受けたりします。

例3)彼女ができて同棲できます

http://razokulover.hateblo.jp/entry/2013/01/23/220418

WEBサービスで得られたわずかなアフィリエイト収入を使ってアドワーズ彼女を募集したら

綺麗なお姉さんと同棲できます

例4)話題になることで色んな人と仲良くなれたりします。

人脈ができて素晴らしいことになります

女の子モテします。

どうです?けっこうすごくないですか?

特に例3が!

まさにプライスレス!!!

WEBサービスってすごいんです!

こんな素敵な経験ができるかもしれないんです。

から、今回、僕も熱い気持ちでWEBサービス作りました

二番煎じだろうが二匹目のどじょうだろうがどうでもいいです。


彼女が欲しい!


僕は彼女が欲しいんだ!

ではどうやって彼女を作るか?

例3の場合アドワーズを使ってたよな?


・・

・・・これだ!!!


自分WEBサービス彼女募集広告載せようwww

そんなわけで一生懸命作ってみました。



サイト名:nweet

http://nweet.net/

・どんなサイトか?

お気に入りエロ動画ブックマークしているとサイドバーに表示しているブックマーク欄が肥大化しすぎてうざい

そんな人におすすめです。

XVIDEOS、FC2アダルト、RedTubeでまた見たいと思った動画再生ページのURLツイートしておけば

後でnweetにログインするだけでツイートした動画を直近100件のツイートから抽出ブログします。

月別、日別、ハッシュタグ別で見れます

埋め込みプレイヤー表示可能な物はサイト内でプレイヤー表示しています

ツイートした動画からキーワード検索可能。お気に入り機能あり。スマホ対応

・使い方

例)XVIDEOSの場合

XVIDEOSの動画再生ページにはツイッターボタンがついてます

shareツイッターマークを選んでクリック再生ページのURL入力されているツイートボックスが表示されるのでそのままツイート

動画を分類したい場合ハッシュタグをつけてツイート(#巨乳 など)

その他のサイト再生ページにツイートボタンがついています

後はnweetにログインするだけ

一瞬でブログ化完了です。

nweetではツイッターOAuthを利用したログイン機能を実装しています

ツイッターアカウントをお持ちであれば誰でもご利用頂けます

で、作ってから気付いたんです。

これ、エロサービスじゃん・・・

・・・エロサービス彼女募集してどうする!!!

てか、女の子エロサービスってほとんど使わないじゃん!?意味がね~!!!

どうしよう・・・諦めたくない・・・

俺も可愛い女の子と仲良くなりたいんだよ!!!

う~ん・・・


・・

・・・

・・・・これだ!!!



もう一個、同じ機能普通の作ればいいじゃん!

というわけで彼女募集用サイト作りました

サイト名:atodemiru

http://atodemiru.com/

機能的にはnweetと同じです。

抽出対象URLyoutubeニコニコ動画FC2動画Nosub、B9DM、anitube、Dailymotion、veoh、pandora、56.com、clip.vnとなっています

同じく直近100件のツイートの中から上記の動画再生ページのURLを含むツイート抽出ブログします。

これで、もう彼女ができたも同然です!

アドワーズ男の早川さんに続く伝説WEBサービス男の幕開けになるはずです!

書籍化されたら印税がっぽりかな~

うひょ~!!!!!!!!


とここまできて、冷静になったんですが

ネット彼女募集なんて怖いよね・・・

応募する人って変な人しかいないんじゃないのか?

まあ、おっさんなのにこんなWEBサービス作ってる僕の方が相当あれですがw

そんなわけで、ひっそりとカムフラージュして募集しようかと思います

ええ、本当はこの年でこんなことしてるのが恥ずかしい。

というかいい大人で常識ある人間はこんなことしない。

こんなことして許されるのはせいぜい大学生くらいまでだ。

けど、彼女は欲しい・・・どうしよう・・・

という葛藤の末に考えた方法カムフラージュだっただけですw

見つけた~!!!といういう女子20歳以上)の方は応募してみないか

さて、長くなりましたが

サイト名:nweet

http://nweet.net/

サイト名:atodemiru

http://atodemiru.com/

良かったら使ってみてね。

このサイト技術的なことに興味ある方はこちらをご覧下さい。ツイッターもやってるんでフォローしてね。

http://nante.hatenablog.com/entry/2013/03/14/144250

最後に、僕は自分楽しいから

お金にならなくても彼女ができなかったとしても

それでもWEBサービスが作りたいんだ!

と思っています

そして、これから時間があれば自分楽しいと思えるようなWEBサービスを作っていこうと思います

2012-11-18

アダルト動画を配信するtumblrbotを作ってみました

今回、仕事の外でサイトを公開してみました。

目標としてはとりあえず新しそうなことをやってみるということで作りました


作ったサイトは2つ。

えっちなハイ!ムービー」(通常のアダルト動画サイト

えっちなハイ!ムービー in tumblr」(えっちハイムービーtumblr bot


えっちハイムービー比較普通サイトですが、

えっちハイムービー in tumblrbot作りに挑戦してみたのとtumblrでの動画の配信を試してみました。


技術的にはえっちハイムービーベースLAMP

言語・・・php

フレームワーク・・・codeigniter

スクレイピング・・・Simple HTML Dom

サイトデザイン・・・bootstrap

絞り込み・・・solr

サーバ・・・Apache

データベース・・・mysql

といったところです。


自分が知らなかっただけかもしれませんが、

比較的目新しかったのはtwitterのbootstrapで、

これでcss周りがだいぶ楽になりました。

自然レスポンシブ対応にもなったので

スマホでも見ることができるようになっています


solrはそこまで必要があるわけではなかったのですが、

前にも使っていて割とすぐに実装できそうだったので作りました

絞り込みで使っています


フレームワークcodeigniter特に本を買ったりするわけでもなく

公式サイトマニュアルを見てすぐに使えました。


えっちハイムービー in tumblrの方は

えっちハイムービーにある動画データを読んで

tumblrapiを介して配信しています


技術的にはOAuth必要になります

手順に何通りもバリエーションがあるというわけではないので

なんとかなりました。


今回は仕事などで得た知識や経験のまとめとして一人でどこまで作れそうかやってみました。

今後もまた思いついたものをちょくちょく作ってみたいと思います

サイトは両方とも18禁ですが大人な方はもしよろしかったらご覧下さい。

えっちなハイ!ムービー

えっちなハイ!ムービー in tumblr

2012-04-02

iPadSafariTwitterからログアウト→はまちちゃんTweet一覧に

Twitterの@logoutははまちちゃん(ぼくはまちちゃん!)なのではないかと思われる。なぜかというと、このアカウントで「こんにちはこんにちは!」と発言しており(以下のURLから確認できる)、名前が「Hamachiya2」となっているかである

https://twitter.com/logout/status/85500046010884096

このアカウントで呟かれている内容の全貌が気になるかもしれないが、それを確認するために以下のURLアクセスしても無駄である

http://twitter.com/logout

普通PCから普通Webブラウザを使って上のURLアクセスしても、@logoutの発言内容は表示されず、代わりに「Twitterからログアウトしますか?」と表示される。これではダメだ。

@logoutの発言内容を確認するには、例えばTogetterを介せばいい。

http://togetter.com/id/logout

どうしてこのアカウントお話をしているのかというと、iPadSafari場合は上に示した挙動にならないからであるhttp://twitter.com/logoutアクセスすると、ログアウト確認ではなく、@logoutの発言内容が表示される

これが問題になるのは、TwitterOAuth認証依存しており、頻繁にユーザを変更するWebサービスを開発した時である

ご存知の通り、TwitterOAuth認証の代わりに使用するWebサービスログインする場合、まずTwitterのものログインしなければならない。OAuthは「このWebサービスに、あなた名義でTwitterAPIを叩く権利を与えますか?」と訊きにくるのが肝であるから、当然ながら「あなた」名義で予めログインし、OAuthに訊かれる前にTwitter(と自分Webブラウザ)に「あなた」とは誰かを教えておく必要がある。

残念なことに、この認証方法採用すると、ユーザ切り替えのたびにユーザは「Webサービスからログアウト」と「Twitterからログアウト」の二度手間を強いられることになる。Webサービスからログアウトだけでは不十分で、次に別のユーザログインしようとした際に「どのユーザログインしますか?」と訊いてこなくなってしまう(ついさっきログアウトしたユーザで再度ログインしてしまう)。何故ならTwitterは、既に誰かの名義でログインしている状態だと、「あなたが誰か、私は既に知っていますよ」と言わんばかりにユーザ認証スキップするからである

ユーザストレスを減らす方法は、せいぜいWebサービスからログアウトした直後の画面に「このページからTwitterログアウトできます」というリンクを張っておくくらいのものである。ここでいよいよ、先ほどのURLが登場する。 http://twitter.com/logout へのリンクを張っておけば、ユーザは「ログアウトしますか?Yes/No」に答えるだけで済むはずだ。

この方法はうまくいった…iPadSafariを除いてはiPadhttp://twitter.com/logout を押すと、@logout(はまちちゃんアカウント)のTweet一覧に飛ばされる。ログアウトはできない。

どうしてこのような仕様になっているのか、私にはよくわからない。また、どこにリンクを張れば、どのようなデバイスでもお手軽にTwitterからログアウトできるのか、わからない。ご存知の方がいらしたら、是非とも教えていただきたい。

2011-09-11

ザ・インタビューズで今後起こりそうなこと

ザ・インタビューズというサービス流行ってますが、今後起こりそうなことを考えてみた。すでに起こっていることもあると思う。

なりすまし

これはまあアカウント制のサービスなら基本。ネタなら後述する「なりきり」になるが、ガチで本人になりすますケースが出てくるでしょう。

単に目立ちたいから、ネット住民を騒がせたいから、くらいの理由でやるならかわいいもんですが、なりすます対象に悪意をもって行うケースというのも出てくると思われる。

運営側の対策としては、TwitterFacebookなどの既存SNSアカウントとの連携機能をつけるのが効果的なんじゃないかと。

現在IDのみ設定可能ですがこれは片方向なので、OAuth認証で双方向の連携を。

少なくともTwitterなどで本人であることが確認されていれば、紐づいたアカウントも本人のものであることが明らかになる。

なりきりアカウントの登場

なりすましとは違って、本人ではないことを明記した上で名前を使う場合、あるいは物語の登場人物など実在しない人物の名前を使う場合、なりきりアカウントになる。

Twitterでも結構みかけるので、流行る土壌はあるように思える。

加えてFacebookGoogle+では規約上不可能なので、規約の緩いザ・インタビューズに流れる可能性がある。ていうか規約ってあるの?

元ネタが実在人物の場合はその人物に怒られる可能性は高いです非実在でも版権元に怒られる可能性はありますね。

参考:コナミが「ラブプラス」2次創作規制へ?Twitter「姉ヶ崎寧々」のなりきりに削除依頼 - ゴールデンタイムズ

ザ・インタビューズでは回答に画像を貼れるので、ここに著作権上問題になる絵を貼って、それが問題を大きくしそう。

企業政治家などの公式アカウントの登場

これは、あるのか?

すでにネットでの活動が顕著な有名人アカウントを取る事例は見受けられるので、ないとはいえない

答えたくない質問はスルーできるので、ブログ承認コメント欄くらいのノリで使われるかも。

いろんな意味で緩い系の企業自治体とかは使うかもね。あと某与党の若手議員とか。

内部事情リーク

まあこれはなさそうだけど一応。

リークといえば昔は2ch(「○○だけど何か質問ある?」的な)がほとんどだったけど、今は2chが使われることが減ってる気がする。

理由は色々あるだろうけど単に衰退してオワコンからってのが一番の理由だと思う。

あとアカウント制じゃないのでどれが本人か分かりづらいってのもあるでしょう。IDとかトリップとかは限界あるし。

変な規制が増えたせいで一人が同じスレにたくさん書き込めなくなったってのも大きい。

その点ザ・インタビューズ回答者質問者がはっきり分かれてるし、たぶんまともに回答ができなくなるような制限もない。

ブログYoutubeニコ動なんかと違って双方向コミュニケーションを容易に取れるので、リークも捗るかもしれません。

ただまあ、ザ・インタビューズの運営がどこまで信用されるかにもよるかと。国内サービスからね…

炎上

今まで挙げたようなアカウント特に、当然炎上危険性を大きくはらみます

ただ2chTwitterとかと違って、回答者が答える質問を選べるし、選ばれなかった質問が表に出ることもないので、炎上はある程度コントロールできます

が、ついかっとなって答えなくてもいい質問に余計な回答を入れて炎上というのはありそう。

なんせ質問者匿名なのでどんだけ回答者を煽るようなことを書いても批判を直接受けることはないし完全に安全。ここは2chと同じ。

そしてユーザーは大抵Twitterもやってるので、炎上はよりダイレクトに意思疎通ができるそちらに波及するでしょうね。

燃え尽き症候群

燃え上がると言えばこっちも発生するでしょう。

既出、あるいは同じような質問、心をえぐる質問、やたらと長文を要求する質問、モラルのない質問、質問爆撃(同じ人が同じ人に嫌がらせ目的として無難陳腐な質問を大量投下。これシステム上防がれてるのかな?)、バトン(これ今は多分ないけどそのうち出てくると思う。mixi流行ったアレね)、馴れ合い、等々でだんだん疲れてくるでしょう。

そのうちに質問者ひいては自分の周囲の人物への疑心暗鬼なども生まれることでしょう。

おそらく多くのアクティブユーザー特に質問がたくさんつく有名人アカウントは1年以内に放置、休眠状態になると思います

過疎

これは燃え尽き症候群の逆。要するに誰も質問してくれなくてつまらいからやめちゃうというパターン

このサービスは確かに、誰もが誰もに質問できるサービスではあるけれども、きっと何者にもなれない誰かに質問して楽しいか、という話です

有名人友達がたくさんいる人、ぶっちゃければTwitterフォロワー数が多い人以外はあんまり質問つかないんではないでしょうか。

もちろん面白い回答をつけまくってファンを増やすのはありでしょう。でもそんなことができる人物は大抵すでに他のコミュニティで人気者なんですよ…

といって、システム自分自身に質問はつけられないので自作自演はできない。複垢とってまで自演してもむなしいだけ。

まあバトンみたいな質問量産体制ができたら質問数は増えるかもだけど、mixiと違うのは質問者が誰か分からない点。

誰だかわからない人物の汎用質問なんて答えて楽しくないんじゃないかね。たぶん3つのデフォ質問に回答するのと同じ気分になると思うよ。

【総括】

ザ・インタビューズは3か月~半年くらいは他のSNSがたどった道をたどることで盛り上がるけど、やはり同じようにその後は徐々にさびれるんじゃないでしょうか。

とても普通の結論ですけども。

逆にずっとそれなりに流行った状態を維持するには、いかに良質な質問をうまく分配するかにかかっていると思います

2011-01-15

12時間ほどでTwitter連携webサービスを作った記録

2010年年末から年始にかけて10連休ほどあったので、新しいサイトを作ろうと思い立った。

自分スペック

何を作るか

小遣いを稼げるサイトしたい、とまず思った。

月に1万円だと、毎日コーヒーを飲んでるだけでなくなってしまうので、コーヒー代くらい稼げたらうれしいなあ。じゃあどうする。何を作る?

ということで、まずTwitterを使ったものを作ることにした

テーマ

ひとつジャンルにしぼってツイートをかき集めれば、面白い流れになるんじゃないか。人が来るんじゃないか。そう思った。togetterたいな。で、ジャンルは、個人的に興味がある子育て。ていうか毎日帰宅してから朝まで子どもの寝かしつけや夜泣き対応サイト更新する暇も、俺が寝る暇もあんまりない。ので、手がかからないことが大前提。なんだったら自動更新でもいい。

自動更新かー。と思って「ブログ 自動更新」でググったら、wordpressRSSから更新するプラグインがあるらしいことを知った。はい決定。その瞬間、「TwitterAPIからRSSを引っ張ってwordpress投稿するサイト」に決まった。

やってみた

12時間は実装を初めてから時間になります

1時間

さくらインターネットスタンダードを申し込んだ。14日お試しがあるらしいけど、仮申し込みの時点で住所も入れてコンビニ請求にしたら、数日後に請求書が送られてきてビビった。(同時にドメインも申請しちゃった)

まあ、webで申し込んで、すぐにサーバコントロールパネルという画面に入れるようになった。「クイックインストール」というリンクがあったので見てみたらMovableTypeWordPress自動インストールしてくれるらしかったので、ボタンを押したインストールできましたというので発行されたURLクリックしたけど404だった。1時間くらい404で、その日はもう寝た。

2時間

次の日の夜。これはもう、10連休を利用して毎晩1時間ずつ捻出するしかない、さくらのお試し14日あるから約14時間で作りきるしかねえ、と思った。

サイトアクセスしたwordpressが入ったページが出てきた。おお、サイトができてる!

まずTwitterを調べるか、と思って、「Twitter API」で検索したけどOauth?とかいう面倒なことをしないといけないらしかったのでやめた。じゃあ普通に検索は?と思って「Twitter 検索」で検索したら、search.twitter.comの結果はjsonatomで取得できるし、APIコール制限もないらしいのでこれに決定。検索だけで1時間たった。

3時間

夜も更けて、続けて作業した。「wordpress xml 投稿」で検索していくつか探したらFeedWordpressというプラグインがあったので入れた。あ、事前知識としてMovableTypeでのブログはやったことがあったので、プラグインを入れるみたいな話はスムーズに進められた。

で、twitter検索結果をatomで返した結果を入れてみた。ら、本当に投稿されてた。よっしゃできた、と思った。1ツイートが1エントリになってたし、投稿者もツイートした人になってた。よかった。でも、満足できなかった。

4時間

次の日。同じことを自力でやる方法を探した。「wordpress xml 投稿」で検索して、XMLパースできるようになればいいんじゃないかと思い、simplepieというPHPライブラリにたどり着いた。が、PHPなんてまったく知らないし、憶える気もなかった。actionscriptで書かせてよ、とずっと思ってた。

5時間め・6時間

次の日。「wordpress xml 投稿」でまた検索。どうやらwordpress投稿って、xmlrpcというやり方を使ってるらしかった。ので、「wordpress xmlrpc 自動投稿」で検索したら、なんかサンプルコードが載ってたのでそのまんまコピペ(結局PHPだった)。したらちゃんと投稿されていた。ふむ。ここで何を思いついたのか、「wordpress xml パース」と昨日みたいなことを検索した。simpleXML?というライブラリがあるらしかったので、それを試してみることにした。(たぶんPHPが動いたので気をよくしてたんだと思う)

こういう流れでいけると思った。考え方はactionscriptエディタに書いて、ノリであてにいった。変数に宣言するのはできた。$var1とかで宣言したことになるらしいURLRequestに相当するコードを探したら「file_get_contents」らしいことが分かった。(「PHP 外部ファイル」で検索

で、ゲットしたのはXMLなんだけど、上記検索したかにたまたま書いてあった「simplexml_load_string」というのを使うとXMLパースできそうな気がしたので、ノリで書いたactionscriptでは

var req:String = "http://search.twitter.com/?q.atom=mogemoge";

var r:URLRequest = new URLRequest(req);

var kekka:XML = r.send() as XML; ←いまここ

なので、XMLキャストしたんだろうなみたいな感じだった。E4Xを使えればいいのにPHPって馬鹿ねと思いながら寝た。

7時間

年があけて、3が日が終わりそうだった。年末にやってたこと(上記までのこと)を思い出しながら、XMLの必要な部分だけ抜き出す方法を模索したatomっていってもentryがたくさん入ってたか配列にするんだろうけど、ってんで「php foreach」を検索。なんとなくサンプルコードをまねしながら、記事タイトル、記事本文だけ取得した。あとはxmlrpcのサンプルにあわせて投稿するようにした。できた。寝た。

8時間

次の日の朝、ブログを見た。昨日更新したのしかあがってない。自動じゃねーじゃん。

で、「自動 投稿」で検索したら、クローン(cron)という仕組みを使わないといけないのだった。クローンサーバの仕組みらしく、そういえば俺はPHPをはじめDBサーバという単語を極力さけて仕事してきたので、もう気持ちが悪くなってきた。「さくらインターネット cron php」で検索して、なんとかやり方を見つけて、cronを登録した。(1時間に1回にした。設定は * * * 0)

9時間

仕事から帰ってきて、サイトを見ると、投稿が大量にたまっていた。やった!で、調子に乗ってツイッターアカウントを作った。なんだったらツイッター自動したかったので「twitter bot」で検索した。Easybotterというサンプルボットがあったので使わせてもらった。自動で一行ずつつぶやくようにした

時間外)

サイトテーマを考えてた。通勤電車で悶々とする時間

ツイートを集めることは成功したけど(毎時間100件のツイートを1エントリとして投稿してる)、それを眺めて面白いんだろうか? ボットを動かしてるけど人がくるんだろうか?

そんなとき「trivist」がはてブに載ってた。なんかにたものを感じた。やっぱツイートを引っ張ってきて投稿するサイトはアリなのか?アリなはずだ!

10時間

サイトの体裁を整えた

11時間

trivistをまねて、記事を評価(はてなスターかいいねボタンかにいもの)する仕組みが欲しくなった。「wordpress 評価 プラグイン」で「wp-postratings」というプラグイン発見して、入れてみた。どうやら1エントリーに1評価しかできないらしい。俺のサイトは1エントリーに100ツイートあるから、どのツイートを評価するのかが分からない。

いったん、wordpressの全投稿を削除した。で、cron に登録されてるPHPを、1記事に1エントリーした

12時間

エントリー投稿するついでに、Yahoo日本語解析APIをつかってツイートを分析して、名詞動詞だけを取り出そうと思った。それをタグにすれば、タグクラウドが作れると思った。はてブはずっとずっと昔からやってるからYahoo日本語解析っていうのが2006年くらいに流行ったことをなぜか憶えてたので、やってみた。できた。

なんか俺、PHP書くのが早くなってね?

そして微調整をしながら今に至る

アクセス解析を入れてみた。サイトに来てる人は、俺だけだった。

どうにかして人を増やしたい。サイト広告募集はする気がないしベタベタバナーを貼りたくなかった。みんなが気軽に見に来て、軽い気持ちで評価してくれて、更新を楽しみにしてくれるサイトしたかった。コミュニティサイトじゃないけど、やっぱりサイトコミュニケーション設計をしないと意味がないんじゃないか、見てくれるユーザはどうやったら楽しいんだろう、ということを考え続けて10日ほど経った。Twitter経由で来てくれた人が3人ほどいるようだけど、何がダメなのか分からないので増田にお願い。


ここまで書いて教えてくんじゃねーか、と思われるかもしれないが、ググレカス的な検索は上記で書いたみたいにいろいろやってきた。でも、サイトを作ってみてはじめて、ユーザに向けたサイトってどう作ればいいのかが分からないということに気づいた。

小遣い稼ぎもしたいんだけど、面白いサイトを作るヒントがほしいと思った。

kanzen21やtrivistみたいに、俺も過程を全部さらしたから辛辣意見を求む。そしてはてブされるのを待ってます

http://kosodate-now.com/

2010-09-18

OAuth認証について

このバージョンから今ま

でのBasic認証から、OAuth認証という認証方式になりました。TwitterBasic認証2010年春くらいから非推奨になるそうなので。

具体的には、ファイルの中にユーザー名やパスワードを直接書くのではなく、このサイトからTwitterサイトへ張っているリンクをたどって、Twitterサイト認証してもらって、それで発行されたキー(文字列)を保存して、ファイルに書き込んでもらう、という手順を取ることになります。

ちょっと手順としては面倒だけど、今までの方式より安全だし、Twitter投稿したときに表示されるクライアント名(「webより」などの部分)を変更できるというメリットがあります。

すでにOAuth認証用のキーを持っている人は

すでにOAuth認証用のキーを持っている人は、そのキーをそのまま使うことができます。

setting.phpに書いてある$consumer_key、$consumer_secret、$access_tokenと$access_token_secretの4つのキーを、自分で取得したものに入れ替えてください。

自分で独自のOAuth認証アプリを作れば、つぶやきの「送信元」を自由に変更することができます。詳しくはPHP+OAuthTwitter - SDN Projectなどを参照してください。

このサイトOAuth認証のキーを取得する

まだOAuth認証キーを持っていない方は、ここで取得することができます。その場合つぶやきの「送信元」は「EasyBotter」になります。

以下のリンク先の指示に従って、OAuth用のキーを取得してください。

OAuth認証について

ただし、既にOAuth用のキーを取得している人はそれを使えば大丈夫です。

スポンサード リンク

2010-08-05

http://blog.livedoor.jp/geek/archives/51063186.html

エロゲー殆どやったこと無い(大昔1~2作品触った程度でとても語れる素地はない)し、興味はないんだけど、別の点で一つ。

キチンとTwitter認証を受けて登録されている。

なにがどう「キチンとTwitter認証を受け」てんの?

世間的にはどうでもいいことなのかもしれないけど、こういう書き方では「この機能がTwitterから正式に認可されて公開される」と勘違いするバカが絶対に出てくるんじゃね?

で、なんとか自分勘違いじゃないかと思って掲載意図を考えてみたけど、「キチンとTwitterの(OAuth)認証を受けて登録されている。」の意味だったとしてもそれをここで掲載する理由が全くわからない。今のところTwitterに外部ツールから書き込む方法はOAuthしかないんだから、そんなもの言われなくてもわかってるわけだし。

補足というか

情報強者の皆様ならご存知でしょうけど、Twitter向けアプリケーションは知識とTwitterへの開発者登録さえあれば誰でも作ることが出来ます。そこにTwitterサイドからの審査などは一切ないです。仮に内部的に何かしてるとしても、少なくとも登録時リジェクトはないはず。

2010-08-03

http://anond.hatelabo.jp/20100803163235

横からだけど、LastPassなんかのサーバーパスワード管理ソフト

暗号化されてるとはいえ、Webサービスパスワードを全てサーバーに上げちゃっているわけで

スパコンでマスターパスワード 高々8桁程度を解析してしまえば 全部のパスワードを持って行かれちゃう。

そんな恐ろしい物すら使うユーザーがいるんだから、OAuthぐらい いいよね。と 思わなくもないこともないが 俺は使わない。

そもそも、OAuthどころか、生パスワードを生のまま持って行った、某有名衣料メーカーアプリもあることだし、

ユーザーにとっては・・・まいっか。なんだろうなと。

なる4時擁護してるやつの頭がおかしい

OAuthがどうのとかアイデンティティがどうのとかじゃなくて、

人のもん勝手に使ったらそら怒られるだろ。アホか。

基本的な所すっ飛ばしてなに言ってんの?

 

被害者も悪い」みたいな事いいたいだけのクズだな。

程度の度合いはあれ、加害者が一番悪いんだよ。

他人のからあげに1滴でもレモンかけられたら程度の差はあれ怒られるのが当たり前なの。

バカすぎないかインターネッツの人たち。

http://anond.hatelabo.jp/20100803155332

四時作者の小池です。面倒だからここに書く。

首記の件はどうでもいいのだけど、

「あ、ちなみにOAuth許可してたらモノにもよるけどアプリケーション側からDMとかも取得できるからね。まあホイホイOAuth登録するんだからDMに住所とかメールアドレスとか大事なこと書いてたりしないとは思いますけどね。」

について。この表現だと誤解を招きそうなので。ユーザーから OAuth 経由での API アクセスを許可されたアプリケーションは、そのユーザーが読むことが出来るデータの全てにアクセスできます。書き込みを許可していればアカウント削除以外のことは大体出来る。

DM を「読む」だけなら OAuth 認可を受けたコンシュマーは誰でもできます。

デスクトップアプリケーションであれば通信を監視すればよいけど、 Web アプリケーション場合はそれが出来ない(例えば四時と twitter の間で何か通信をしたとしてユーザーからそれが見られない)です。

何度も言っていることですが、 DM を読まれるとかそういう件については、 OAuthtwitter連携する Web アプリケーションは一律「信用できない」ということになります。 mixi ボイスの twitter 連携だとか HootSuite とかでも、それはそうです。一律ゼロ

だけどそこに提供者の信頼を加算することは、出来るでしょう。それは個々人の価値観の問題だ。

ちなみに僕は自分が作ったアプリケーション以外には、特に Web アプリケーションには、 OAuth を許可しません。他人の住所などを DM で多数受け取っていて、それを暴露させる可能性は少しでも下げたいからです。

「なる四時」と「なる四時」のユーザが何をやらかしたかのまとめ

なる四時の騒動をまとめとく。(追記:ブクマされてるので念のため書いておくが増田素人です。技術的な面に関しては参考までにどうぞ。)

間違ってたらトラックバックなりなんなりで訂正してくれ。

きっかけは小池氏(@ssig33)によるテスト

なるほど白夜じゃねーの #4ji

http://twitter.com/ssig33/status/20179930626

ちょっとしたテストで四時全員で俺の発言と youpy の発言ふぁぼらせる

http://twitter.com/ssig33/status/20179966911

favoritesがどれくらいの速度出るのか試してみたい

http://twitter.com/ssig33/status/20179979441

その結果、以下のpostが大量favされる(favstar参照)

http://favstar.fm/users/ssig33/status/20179930626

http://favstar.fm/users/youpy/status/20124150089

ところがfavが消せない(小池はfavを消すつもりだったと思われる)

っていうか今 fav 消せないの何

http://twitter.com/ssig33/status/20180907486

Web からは fav 消せるなあ

http://twitter.com/ssig33/status/20181045593

もしかして四時の token だけ弾かれてる?

http://twitter.com/ssig33/status/20181057823

(token:OAuthトークンのこと。http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth02.html を参照。分からなければ「アプリから操作を行う権限」とでも思っておけばいいはず。)

四時の token から favorite を消せない

http://twitter.com/ssig33/status/20181132468

そして現状に至る。

何故か8/3の15時頃より急に拡散してるっぽい。

小池氏が悪いとか叩く前によくわからずに「なる四時」を登録しちゃったユーザも悪いと思うんだよね。

登録した人はどうせノリで登録してるでしょ?

あ、ちなみにOAuth許可してたらモノにもよるけどアプリケーション側からDMとかも取得できるからね。まあホイホイOAuth登録するんだからDMに住所とかメールアドレスとか大事なこと書いてたりしないとは思いますけどね。(追記:小池氏本人より訂正がありました。すまん。 http://anond.hatelabo.jp/20100803163235)

favやpostだけなら大したことなくても本来隠匿されているDMアプリ開発者によって自由に閲覧できるわけだよ?

増田はそのあたり良く考えてからOAuth認証したがいいのではないかなと思いますね。

最後に関連ページをリンクしときます。はてな記法良くわからんのでURLそのまま貼る。つーか文中のURLもおかしいけど許してくれ。

http://4ji.ssig33.com/ - なる四時

http://twitter.com/ssig33 - @ssig33(小池 陸)

http://d.hatena.ne.jp/ssig33/20100803 - twitter の速度について(ssig33)

http://syawa.net/t/4ji - なるほど4時じゃねーのを使っているユーザ一覧 しゃわたん(@syawatan)氏作成

http://r.nanapi.jp/2965/ - Twitterなるほど四時じゃねーの」を解除する方法

2010-07-20

http://anond.hatelabo.jp/20100720031816

大企業から、中小企業まで、どんだけ、なんちゃってSIerがいると思ってんだと。

ユニクロ様ですら、twitter事件でOAuth使えなかったんだぜ?

日本のITがどんだけかって話だよなぁ・・・orz すまん、泣きたいよ。

全角半角な・・・某有名Perlの人の全角半角変換が他の文字の中で文字化けする文字があって使えなかったんで

1から書いたことがあるんだが、文字通り50音テーブル書くだけなんで、チャラいよなぁ。なんで、やんねーんだろうな。

日本SIerってそういう、やっても大して稼働食わないところは、断るくせに。

文章で書いたら1行でもテスト工数が莫大でものすごい大変みたいなところをあっさり受けて、デスマってたりするよなぁ。

ほんと、客もSIerもまともに見積もれない人が多すぎるよ。この国・・・こういうと、客が・・・見積りってツッコミがよくあるけど、

やっぱり、客にも客レベルってあるよ。

 

というか、図書館なんて、国レベルで同一システムにして、一括導入しろよ。経費削減。

都道府県自治体ごとで違うシステム使うなよ。

要求仕様的にはまったく同じシステムなんだから。とか思った。

2010-06-02

TwitterOAuth 許可ページがあまりにも酷いのスクリプト危険

Twitter の OAuth 許可ページがあまりにも酷い => 応急処置 - リタマス

これのGreasemonkey スクリプト危険だったので修正したよ!

twitter-oauth-caution.user.js

どこが危険だったのか

このスクリプトは、本文中にupdate(または更新)が入っている時に警告を出すようになっていたんだけど、これだとチェック漏れバグがあるとwrite権限を要求しているのに警告が出ないのでread onlyのように見えてしまう

人間が本文読めばわかるから大丈夫だろと思うかもしれないけど、このスクリプト使い続けていたら警告が出ない=read onlyだと判断して本文読まなくなるはず

どう修正したか

read onlyの時にも色を変えて警告を出すようにした(writeなら赤、read onlyなら黄)

これで警告表示の色を見れば赤ならwrite黄ならread onlyだとすぐにわかるし、警告がでなかったらなんかおかしいとすぐに気づくはずだ

まとめ

危険なものと安全なものが混ざってる中から危険なものを選り分けても安心はできないけど、安全なものを選り分けたんなら安心できるよね!(これなんか専門用語ありそうだけど僕は知らない

おまけ

最初スクリプトだと https://twitter.com/oauth/authorize?* と https://twitter.com/oauth/authenticate?* で動くようになってたけど、

twitterOAuth認証ページは他にもhttpsのかわりにhttpを使ったものとか、twitter.comのかわりにapi.twitter.comとかがあるから、それらのページでは警告が出なかった

2010-05-26

ユニクロtwitter行列って

Basic認証な上にSSL通信でもないからIDパス盗み放題な気がするんですが、大丈夫なんでしょうか?

それ以前に、個人のtwitterアプリならともかく、ユニクロみたいな大企業OAuth認証使ってないことに失望しました。

あれだけBasic認証廃止するって騒がれてるのに、Basic認証使う根性が信じられないです。

2009-11-16

Twitterスパムを撒かせるOAuthって何なのさ

OAuthってなによ?

IDパスワードを教えなくても いろんなサービス自分情報の一部を見せたり書き込みさせたり出来る仕組みの事。

パスワード教えなくてもアカウント乗っ取られるって事?

違う。

Twitter使ってて最悪のパターンって、パスワード変えられて完全にアカウントを乗っ取られ、友人知人関係が壊滅。さらにメアドも抜かれて同じパスワード使ってそうな所も漁られて無茶苦茶されることじゃないか?

パスワードを教えるとそんな事が起きるかも知れない。そこでTwitterは、パスワードを教えなくても「書き込み権」や「読み込み権」を与えられるOAuthってのを用意してる。

書き込みされたら乗っ取りじゃね?

例えばブログ更新したら自動的にTwitterに「ブログ更新したよ! htt...」って書いてくれるサービスなどがある。他にも写真動画を上げたらとかブクマしたらとか。 当然全て「書き込み権」がないとサービス提供できない。

逆に、iPhoneなどでReplyやRTをもらったら通知してくれるアプリもある。 こちらも、この手の情報は基本的に「読み込み権」がないと取得できない。

で、こういうサービスを使う度にパスワードをばら撒くのはヤバすぎだろjk、ってのが Twitter が言ってる事。

(なお、どんなサービスがあるかは纏めてくれてるところ参照で。結構色々あって見てるとwktk出来る。)

でも俺クリックするだけでスパム撒かれたんだが

確かにそのとおり。でも画面をちゃんと見てないあなたも悪い。

今回問題になった「Q&Aなう」というサイト場合このような画面になったはず。太字の所だけ抜き出すと

後はわかるな?

俺が悪いってのか? あーそーですか、悪うございました

Twitter側も、この画面をいつまでたっても翻訳してないし、問題がある。前はもっとわかりにくかったので多少改善はしてるけど。

でも、ある程度日本語化されてるとは言っても、やっぱり海外サービスを使ってるわけで、「拒否 or 許可」とかの場合は少しぐらいは注意した方がいい。

周りにいるだろ? 日本語ですら「OK or キャンセル」とか「はい or いいえ」を読まずに押してパニくってる奴が。あんな風にならないようにだけ気をつければいい。

んじゃその画面が出たら拒否ったらいいのか。

使いたいサービスなら許可すればいい。その代わりそのサービススパムを撒かれたりする可能性はどうしても残る。

ポイント

  • 何というサービスなのか
  • そのサービスは何をしたいのか
  • あなたはそれをさせてもいいと思うのか

今回なら

  • サービス名は「【Q&Aなう】 by qanow」
  • やりたいことは「access and update」(読み書き)
  • 私なら、なぜ書き込み権が必要なのか分からないから許可しない

私も FriendFeed や Boxcar なんかは、信用した上で許可してる。彼らにスパム撒かれたらそれはもう仕方ないと割り切って。正直なところBoxcarはなんで読み書きなのか意味分からんのでかなり躊躇ったけど。

やっぱり拒否したくなったりしたらどうすればいい?

https://twitter.com/account/connections

ここに行けばあなたがこれまで許可したサービスの一覧が出る。よく分からん物とかがあればここから「許可を取り消す」とすればいい。

こういう風に後から個別に許可を取り消せるのも OAuth のいいところ。全部にパスワードを教えてる場合だと、まずパスワード変更して全サービスお断りにしたあと一つずつ再設定していかないといけない

ちなみに

なお、OAuthWeb とかのソースコードを利用者に見られないサービスで主に使われるので、DLするタイプアプリケーションとかではまだまだパスワード認証が主流。最近少しずつ変わってきてるけど。






  • 2009/11/18 わかりにくいと思われる部分を修正
  • 2009/11/19 さらに一項目追加
  • 2010/08/03 今はもう日本語で書いてるんだからちゃんと嫁
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん