  |
はてなキーワード: eXploitとは
ガチで食いたいなら、今からでもセキュリティやるといい。割とガチ目におすすめする。
いまいろんな企業がEDRやXDRを導入しようとしてるけど、まともに運用できる人員がないし、売るほうも知識がない状況がここ1-2年続いてるし、IＴ人材の枯渇によってさらにそれが進むと思う。
セキュリティの知識全然ない人がセキュリティ製品売って歩いて、買ったほうも適当に運用してるのが現状なので、チャンスがある。(Exploitってなんですか？ってレベルの人が普通にいる)
ちゃんと1年勉強して、どこかに派遣でもぐりこんで1-2年実績をつけ、その間に給料の一部をベンダー資格に課金すれば、転職時にまあまあの待遇が待ってると思う。
プログラムなんて今から勉強しても、よっぽどスキルあるか、コード書くのが大好きで苦じゃない感じじゃないと辛いと思う。
俺は高卒で20台で派遣でIT潜り込んで、今は30代後半で正社員年収は平均を二回りぐらい超えたけど、殆ど趣味でセキュリティやってたおかげ。
あと運もあるけど。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
211あとで/1849users ストレスフルな人に知ってほしい図解「アメリカカウンセリング学会推奨『ストレス解消法』100」…「古い友人にメールをする」「猫は神」「まずは楽しめ」など - Togetter
204あとで/1119users 統計の入門講座が無料に、京大メソッドでデータサイエンス関連教員が担当 | Ledge.ai
162あとで/984users 【朗報】3D制作ソフト「blender」の1400ページにも及ぶ解説書が無償公開 勉強中の人には朗報すぎる : まとめダネ！
161あとで/1037users 徳丸 浩 on Twitter: "これは本当にオススメ。トレーニングなので、Linuxのインストールからやるのがよいです。Exploitが刺さるだけで楽しいですが、なぜそれが成立するかまで追いかけるとさらに勉強になります。 https://t.co/tHyQuPSvjw"
161あとで/1587users 青木 晃 - 【長文です】1995年3月20日に起こった地下鉄サリン事件…オウム真理教が起こした未曾有のテロでした。お亡くなりになった方々のご冥福をお祈りすると共に、今もなお、PTSDなどの後遺症で苦しむ方々の症状が少しでも改善しますようお祈り申し上げます。 | Facebook
157あとで/1655users 時間跳躍式完全無劣化転送装置 - 山素 / 【読み切り】時間跳躍式完全無劣化転送装置 | コミックDAYS
156あとで/1192users こういうのが好きなんでしょ…？「変拍子」が超かっこいいおすすめ曲10選+α | Music Lesson Lab
154あとで/988users あなたが行動を習慣化したいと思った時におすすめの記事 | みんチャレブログ
150あとで/1178users 東京〜京都を3度徒歩で移動した話 – 大変だけど素晴らしい、街道歩きの世界にようこそ【寄稿：dekokun】 - KINTOマガジン｜【KINTO】クルマのサブスク、トヨタから
149あとで/918users MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
145あとで/1226users 100日後に退職する47歳 非公式 まとめ - Togetter
140あとで/1396users 業務スーパーデビューする予定なのでおすすめの商品を教えて下さい→で続々と集まった情報がこちら→増量! - Togetter
137あとで/1417users 新型コロナの罹患レポートが分かりやすくて恐ろしい「熱が下がったあとにぶり返し血痰が出て即入院、肺がぐちゃっと潰れている」 - Togetter
129あとで/663users リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ
129あとで/753users 元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL
129あとで/990users 英語の括弧は4種類ある！括弧の使い方を理解して正しく使えるようになろう | English Lab（イングリッシュラボ）┃レアジョブ英会話が発信する英語サイト
125あとで/1881users みずほのシステムについて質問です。 | Peing -質問箱-
122あとで/916users GitHub 英語例文集 | boarwell | Zenn
120あとで/532users JavaScriptはなぜシングルスレッドでも非同期処理ができるのか/Why Can JavaSctipt Invoke Asynchronous in Single Thread? - Speaker Deck
118あとで/833users 個人情報テストデータジェネレーター | User Local,Inc.
116あとで/1394users 「元歯科受付がガチで愛用する『推しデンタルケアグッズ』です」さようなら、全ての黄ばんだ歯と口臭。ド定番8アイテムとは？ - Togetter
116あとで/1051users かおりゅ on Twitter: "とんでもないサイトを知ってしまった。絵描きやデザイナー大歓喜のカラーチャート『Colorbase』https://t.co/CLWprkukt6 色を選ぶと、その色の補色・類似色・同じ明るさを持つ色・白と合わせた時の見やすさ・色相… https://t.co/rOgsnechfT"
115あとで/1493users 記事『ドライフルーツで果実酒を仕込むとすごい』に関して | デイリーポータルZ
107あとで/959users 小鳥の鳴き声は言語だった 文法まで突き止めた日本人研究者：朝日新聞デジタル
105あとで/591users ゲーム開発者へっぽこさん、711ページに及ぶ技術書『Unity uGUI アドバンスド・リファレンス』を無償公開 | ゲームキャスト
105あとで/1575users 皆さんの声を聞かせてください。皆さんの力を貸してください。 #ねえねえ尾身さん｜コロナ専門家有志の会 | COVID-PAGE
105あとで/791users ついに、Webアプリでの帳票印刷のベストプラクティスを編み出しました💡 | Takashi Kanemoto | Speaker Deck
104あとで/595users 「Python」×「株価データ」で学ぶデータ分析のいろは | @IT
102あとで/475users 2021年 – これからFlutterを始める人へ学習方法のススメ | ツルオカ | Zenn
102あとで/820users 自分がどのくらいエコーチェンバーの中にいるのか可視化するシステムを作ってみた｜tori｜note
Togetter多め。
#nmap -sS -A -v www.target.com
見るべきところは相手のサーバーで動いているソフトウェア&そのバージョン
2.exploitを探す
動いているソフトウェア(のバージョン)に該当するexploit(攻撃コード)を探す
ttp://1337day.com/(http://milw00rm.com)
ttp://www.packetstormsecurity.com/files/tags/exploit/
ttp://www.securityhome.eu/exploits/ 等
落としてそのまま使える物もあればコンパイルしたりして使う物もある
3.exploitをターゲットに向けてTails/RDP/VPN(logを保持していないのに限る)上から実行する
侵入できたらあとはページ書き換えるなり、内部データぶっこ抜くなり、フィッシング撒くなり、なんかの踏み台にするなり、Local exploitで権限昇格するなりご勝手に
Lets Karakking!
nmapより先にwhoisとかgoogleハッキングで情報探すナリ
tor越しやVPN越しにnmapで突くとアクセス遮断されてるか警戒されることが多くなるナリ
最近はポート確認用のサイトでIPとポート指定できるサイトとかあるから、そういうサイト使ってポート開いてるか確認するのも良いナリよ
正直nmapは最終手段に近いナリ
38 風吹けば名無し＠転載禁止 2014/11/25(火) 20:28:06 ( tor-exit.server6.tvdw.eu )
プログラミングがたいして出来なかったから、ろくなもんになれないと思ったもんで
まあ攻めより受けは圧倒的に楽なもんだよね
サーバーの運用に関してはセキュリティについて結構書かれてる本多いし
解析する方としては、ハード、OSの基本的なシステムとwebやネットワーク関連を身につけたら、
既存のツール活用するだけでフォレンジックの真似事やマルウェア分析ができる
数万相当で売ってたカランサムウェアもちょっと説明つけて検体送ってやれば、半日で役立たず
多段パッカーとかでワンチャンあるかも分からんし、こういうのはいたちごっこだけど。恒心サポートとか付いてくるんかね？ｗ
Cuckoo Sandbox: Automated Malware Analysis
Malwr - Malware Analysis by Cuckoo Sandbox
ttps://malwr.com
k5zq47j6wd3wdvjq.onion
tom3j5jkjl7327oc.onion
ttps://infotomb.com/mn3u8.png
The Exploit Database
国連の児童ポルノ関連のやつ。「↓の段落危なくない？」というメール。
https://www.ohchr.org/Documents/HRBodies/CRC/CRC.C.156_OPSC%20Guidelines.pdf
The Committee is deeply concerned about the large amount of online and offline material, including drawings and virtual representations, depicting non-existing children or persons appearing to be children involved in sexually explicit conduct, and about the serious effect that such material can have on children’s right to dignity and protection. The Committee encourages States parties to include in their legal provisions regarding child sexual abuse material (child pornography) representations of non-existing children or of persons appearing to be children, in particular when such representations are used as part of a process to sexually exploit children.
要約すると「非実在だろうがなんだろうが、児童ポルノっぽいものを(無理やり・時に虐待の一環として)子供に見せないようにしよう。そのために非実在のものも"児童ポルノ"と法的に認めよう」と言ってるのかな。一見正しそうに聞こえる。
しかし二次エロだって"ポルノ"であるとは既に認められているし、わざわざ"児童ポルノ"と認めるまでもなくそれらを子供に見せるのは虐待だと認められるだろう。わざわざ新たに"児童ポルノ"という属性を付与したがるのは、結局のところ「実在児童を記録した"児童ポルノ"と一括りにして規制したいから」以外の理由があるんだろうか？
https://www.mofa.go.jp/mofaj/gaiko/jido/page23_003064.html
2. 政府としては，本ガイドラインが既存の条約等で規律されている分野・事項に言及する際には，慎重な検討が必要であると考え，本年3月末，児童の権利委員会に対して，本ガイドラインに対する意見（仮訳（PDF）別ウィンドウで開く／英文（PDF）別ウィンドウで開く）を提出していました。にもかかわらず，今般，同委員会が我が国を含む選択議定書の締結国との間で十分な協議を行わないまま，本ガイドラインが公表されたことは残念であると考えます。
3. 本ガイドラインは，選択議定書の実施を導くための手引きとして児童の権利委員会が独自に作成したものであって，本選択議定書の規定を変更・修正するものではなく，我が国を含む締約国に対して法的拘束力を有するものでありません。こうした政府の立場については，累次の機会にOHCHRに対して申し入れを行っており，OHCHRからは，本ガイドラインは締約国に対する法的拘束力を有するものではない旨の回答を得ています。
山田太郎頑張ってくれー。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for Businessは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 サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、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 に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ 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 ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (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 は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
ああ？定時で帰らせりゃデスマ終わるのか？
ばっかじゃねーの？？？
デスマーチで頭をやられたのですね。よちよち。
............
別に定時で帰れば終わるとか言ってないことを読み取られてもなあ......"労働力を投入しているはずなのに進捗しない" という状況を説明しただけですよ。
10 人の開発者で 10 ヶ月かかる (つまり 100 人月) 作業に追加で 10 人開発者を投入しても 5 ヶ月ではおわらないというのが『人月の神話』だけど、いまある開発者を exploit して週 40 時間労働を週 80 時間労働にしてもやっぱり 5 ヶ月では終わらないよね…というのが主題。
http://anond.hatelabo.jp/20141106161928
http://www.google.com/safebrowsing/diagnostic?site=st-hatena.com
st-hatena.com の現在の状況 現在のところ、このサイトは疑わしくないと認識されています。 Google がこのサイトを巡回したときの状況 このサイトで過去 90 日間に Google がテストした 2542 ページのうち 122 ページで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。Google が最後にこのサイトを巡回したのは 2014-11-06 で、このサイトで不審なコンテンツが最後に検出されたのは 2014-11-06 です。 不正なソフトウェアには 110 scripting exploit(s), 19 exploit(s), 6 trojan(s) などがあります。感染先のコンピュータで平均 3 個のプロセスが新たに発生しています。 不正なソフトウェアは 40 個のドメイン（fn84.fr/, wkdjfgka.ddns.me.uk/, javaterm.com/ など）でホストされています。 15 個のドメイン（muramoto.net/, meomore.com/, fn84.fr/ など）がこのサイトの訪問ユーザーに不正なソフトウェアを配布する媒体となっていたようです。 このサイトは 29 個のネットワーク（AS9370 (SAKURA-B), AS701 (UUNET), AS209 (QWEST) など）でホストされていたことが判明しました。 不正なソフトの感染を広げる媒介をしていたかどうか st-hatena.com は、過去 90 日間に 59 個のサイト（vip2ch.com/, blog.goo.ne.jp/nakazato-hitoshi/, netouyomilitary.com/ など）への感染媒体となっていた形跡があります。 サイトで不正なソフトウェアをホストしていたかどうか いいえ、このサイトでは過去 90 日間に不正なソフトウェアのホスティングは検出されていません。
これは、a.st-hatena.com のカウントと一致する。
http://www.google.com/safebrowsing/diagnostic?site=a.st-hatena.com
a.st-hatena.com の現在の状況 現在のところ、このサイトは疑わしくないと認識されています。 Google がこのサイトを巡回したときの状況 このサイトで過去 90 日間に Google がテストした 247 ページのうち 122 ページで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。Google が最後にこのサイトを巡回したのは 2014-11-06 で、このサイトで不審なコンテンツが最後に検出されたのは 2014-11-06 です。 不正なソフトウェアには 110 scripting exploit(s), 19 exploit(s), 6 trojan(s) などがあります。感染先のコンピュータで平均 3 個のプロセスが新たに発生しています。 不正なソフトウェアは 40 個のドメイン（fn84.fr/, wkdjfgka.ddns.me.uk/, javaterm.com/ など）でホストされています。 15 個のドメイン（muramoto.net/, meomore.com/, fn84.fr/ など）がこのサイトの訪問ユーザーに不正なソフトウェアを配布する媒体となっていたようです。 このサイトは 1 個のネットワーク（AS9370 (SAKURA-B) など）でホストされていたことが判明しました。 不正なソフトの感染を広げる媒介をしていたかどうか 過去 90 日間に a.st-hatena.com が他サイトへの感染媒体となっていた形跡はありません。 サイトで不正なソフトウェアをホストしていたかどうか いいえ、このサイトでは過去 90 日間に不正なソフトウェアのホスティングは検出されていません。
a.st-hatena.com はリダイレクト用のドメイン。
例えば http://a.st-hatena.com/go?http://anond.hatelabo.jp/ にアクセスすると http://anond.hatelabo.jp/ に飛ぶ。
はてなアンテナでリンクするときにクッションページの役割を担ってる。
なにかおかしいな、と思って goo.gl ドメインの結果も見てみたら似たような感じだった（後述）。
おそらくリダイレクト先が危険サイトだった場合、リダイレクト元のドメイン（goo.glとかbit.ly、t.coなど）もカウントされるような仕組みになっているんじゃないだろうか？
a.st-hatena.com + b.st-hatena.com + d.st-hatena.com + f.st-hatena.com + ... とすべて足し合わせたものが st-hatena.com の結果になるようだ。
はてなアンテナのリンク先（はてなと関係ないサイト）に危険なサイトがいくつかある、というだけ。
st-hatena.com は現状でウィルスを配信してはいないし被害を被ることもない。
・・・と断定していいだろう。
http://www.google.com/safebrowsing/diagnostic?site=goo.gl
goo.gl の現在の状況 現在のところ、このサイトは疑わしくないと認識されています。 過去 90 日間に、このサイトの一部で不審な動きが 1 回検出されています。 Google がこのサイトを巡回したときの状況 このサイトで過去 90 日間に Google がテストした 5488513 ページのうち 2753 ページで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。Google が最後にこのサイトを巡回したのは 2014-11-06 で、このサイトで不審なコンテンツが最後に検出されたのは 2014-11-06 です。 不正なソフトウェアには 1174 exploit(s), 708 trojan(s), 200 scripting exploit(s) などがあります。感染先のコンピュータで平均 2 個のプロセスが新たに発生しています。 不正なソフトウェアは 594 個のドメイン（shop-corp24.com/, mt.co.kr/, jvvupdate.com/ など）でホストされています。 157 個のドメイン（feedburner.com/, finanstek.net/, padsdel.com/ など）がこのサイトの訪問ユーザーに不正なソフトウェアを配布する媒体となっていたようです。 このサイトは 1 個のネットワーク（AS15169 (GOOGLE) など）でホストされていたことが判明しました。 不正なソフトの感染を広げる媒介をしていたかどうか goo.gl は、過去 90 日間に 990 個のサイト（nudevista.tv/, vporn.com/, acervoamador.com/ など）への感染媒体となっていた形跡があります。 サイトで不正なソフトウェアをホストしていたかどうか いいえ、このサイトでは過去 90 日間に不正なソフトウェアのホスティングは検出されていません。
このサイトで過去 90 日間に Google がテストした 5488513 ページのうち 2753 ページで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。Google が最後にこのサイトを巡回したのは 2014-11-06 で、このサイトで不審なコンテンツが最後に検出されたのは 2014-11-06 です。
もしも「st-hatena.com がウィルスをばら撒いている」と考えた場合、Googleもまた現在進行形でウィルスをばら撒いているということになる。
どちらも似たような結果になっている。
http://www.google.com/safebrowsing/diagnostic?site=bit.ly
http://www.google.com/safebrowsing/diagnostic?site=t.co
はてなブックマークボタンを設置した一部サイトに対するセキュリティ警告に関する調査の経過を報告します
http://bookmark.hatenastaff.com/entry/2014/11/06/101514
で、下記やったけど不明でした。という報告だ。
なのに、この下の段落を入れることで、まるで最近話題のDNSハイジャックでした。みたいな空気にしてる。
一連の調査結果より、JPCERT/CCと日本レジストリサービス（JPRS）は11月5日付で、国内組織が使用する .com ドメイン名の登録情報が不正に書き換えられるドメイン名ハイジャックに関する注意喚起を発表しました。
http://bookmark.hatenastaff.com/entry/2014/11/06/101514
これなら、天下の日経新聞と同じじゃしょうがないと、情強気どってるブクマカをだませる
http://www.nikkei.com/article/DGXLASDZ05H3S_V01C14A1000000/
はてなの件は、DNSハイジャックとは異なる可能性が高い。現在も進行中だ！
はてなの件は、DNSハイジャックとは異なる可能性が高い。現在も進行中だ！
DNSハイジャック被害を受けた日経新聞のセーフブラウジング診断
http://www.google.com/safebrowsing/diagnostic?site=www.nikkei.com
このサイトで過去 90 日間に Google がテストした 19027 ページのうち 0 ページで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。Google が最後にこのサイトを巡回したのは 2014-11-05 で、過去 90 日間にこのサイトで不審なコンテンツは検出されていません。
このサイトは 3 個のネットワーク（AS9593 (NIKKEI), AS15169 (GOOGLE), AS13414 (TWITTER-NETWORK) など）でホストされていたことが判明しました。
Google が最後にこのサイトを巡回したのは 2014-11-05 で、過去 90 日間にこのサイトで不審なコンテンツは検出されていません。
http://www.google.com/safebrowsing/diagnostic?site=st-hatena.com
このサイトで過去 90 日間に Google がテストした 2533 ページのうち 122 ページで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。Google が最後にこのサイトを巡回したのは 2014-11-05 で、このサイトで不審なコンテンツが最後に検出されたのは 2014-11-05 です。
不正なソフトウェアには 110 scripting exploit(s), 19 exploit(s), 6 trojan(s) などがあります。感染先のコンピュータで平均 3 個のプロセスが新たに発生しています。
不正なソフトウェアは 40 個のドメイン（fn84.fr/, wkdjfgka.ddns.me.uk/, javaterm.com/ など）でホストされています。
15 個のドメイン（muramoto.net/, meomore.com/, fn84.fr/ など）がこのサイトの訪問ユーザーに不正なソフトウェアを配布する媒体となっていたようです。
このサイトは 29 個のネットワーク（AS9370 (SAKURA-B), AS701 (UUNET), AS209 (QWEST) など）でホストされていたことが判明しました。
st-hatena.com は、過去 90 日間に 59 個のサイト（vip2ch.com/, blog.goo.ne.jp/nakazato-hitoshi/, netouyomilitary.com/ など）への感染媒体となっていた形跡があります。
Google が最後にこのサイトを巡回したのは 2014-11-05 で、このサイトで不審なコンテンツが最後に検出されたのは 2014-11-05 です。
まったく、違うでしょ。
Google が最後にこのサイトを巡回したのは 2014-11-05 で、このサイトで不審なコンテンツが最後に検出されたのは 2014-11-05 です。
どうでもいいけど、初代iPhoneって 日本じゃ発売されてないだろ。
初代iPod touchでかんべんしてくれ。
サファリにEXIFのExploitという超古典的なバグが残っていて、割られてルート取られてノラアプリマーケットが出来て
本家があとから正式にApp storeだして爆発的に流行ったんだ。
もともと計画はあったのかもしれないが、割られることからスタートしたのがAoo storeだったんだ。
という歴史的系の説明で、当時から注目していたことの証明にはなるか？
あぁ、横だけどな。
ちなみにどうでもいいけど 比較するなら初代 Newtonの間違いだろ。
最後だが、がんがれ
設計段階で考えもつかなかったような使い方のテストなんて、設計を知らないと実はできない。
というわけで、そういう話を聞くと、設計力が低いだろうなぁと思う。
他人のをテストする時って、こういうことを一般的には設計しない＝知らない奴が多いとおもわれるような所を叩くと
たいてい落ちたりする。
本質的には、品質保証ってプロの設計を知ってないと少なくともできない。
たとえば、exploitの確認なんて、exploitが何かを知らないと確認用のコードが書けない。
accomplice共犯者、ぐる L.complex（仲間）に誤ってacが付いた
compliance 順守 一緒に＋L.plicare（折り重ねる）+ance
complicity 共犯、共謀 *一緒に折り重ねる）
deploy 展開する、（軍事）配備する de-＝dis-＝apart [離れて]重ねる
diplomat 外交官
diplomatic 外交の、外交上の 二つに折った紙が公文書
duplicate 複製する、二重にする、二倍にする du-＝duo-(＝two [2])
explicate 明らかにする、説明する、概念を展開する ex-(外に)重ねる＝ unfold(たたんであるものを開く)
explicit 明白な、明白に述べた
exploit (資源などを)開発する、(素材などを)切り開く *外に重ねる
implicit 暗黙の、含みのある *中に重ねる ⇔explicit
plight 悪い状態、苦境 plicare（重ねる、織る）
Digital cameras are made in a wide range of sizes, prices and capabilities. The majority are camera phones, operated as a mobile application through the cellphone menu. Professional photographers and many amateurs use larger, more expensive digital single-lens reflex cameras (DSLR) for their greater versatility. Between these extremes lie digital compact cameras and bridge digital cameras that "bridge" the gap between amateur and professional cameras. Specialized cameras including multispectral imaging equipment and astrographs continue to serve the scientific, military, medical and other special purposes for which digital photography was invented.
Subcompact with lens assembly retracted
Compact cameras are designed to be tiny and portable and are particularly suitable for casual and "snapshot" uses. Hence, they are also called point-and-shoot cameras. The smallest, generally less than 20 mm thick, are described as subcompacts or "ultra-compacts" and some are nearly credit card size.[2]
Most, apart from ruggedized or water-resistant models, incorporate a retractable lens assembly allowing a thin camera to have a moderately long focal length and thus fully exploit an image sensor larger than that on a camera phone, and a mechanized lens cap to cover the lens when retracted. The retracted and capped lens is protected from keys, coins and other hard objects, thus making it a thin, pocketable package. Subcompacts commonly have one lug and a short wrist strap which aids extraction from a pocket, while thicker compacts may have two lugs for attaching a neck strap.
Compact cameras are usually designed to be easy to use, sacrificing advanced features and picture quality for compactness and simplicity; images can usually only be stored using lossy compression (JPEG). Most have a built-in flash usually of low power, sufficient for nearby subjects. Live preview is almost always used to frame the photo. Most have limited motion picture capability. Compacts often have macro capability and zoom lenses but the zoom range is usually less than for bridge and DSLR cameras. Generally a contrast-detect autofocus system, using the image data from the live preview feed of the main imager, focuses the lens.
Typically, these cameras incorporate a nearly silent leaf shutter into their lenses.
For lower cost and smaller size, these cameras typically use image sensors with a diagonal of approximately 6 mm, corresponding to a crop factor around 6. This gives them weaker low-light performance, greater depth of field, generally closer focusing ability, and smaller components than cameras using larger sensors.
Starting in 2011, some compact digital cameras can take 3D still photos. These 3D compact stereo cameras can capture 3D panoramic photos for play back on a 3D TV.[3] Some of these are rugged and waterproof, and some have GPS, compass, barometer and altimeter. [4]
Main article: Bridge camera
Bridge are higher-end digital cameras that physically and ergonomically resemble DSLRs and share with them some advanced features, but share with compacts the use of a fixed lens and a small sensor. Like compacts, most use live preview to frame the image. Their autofocus uses the same contrast-detect mechanism, but many bridge cameras have a manual focus mode, in some cases using a separate focus ring, for greater control. They originally "bridged" the gap between affordable point-and-shoot cameras and the then unaffordable earlier digital SLRs.
Due to the combination of big physical size but a small sensor, many of these cameras have very highly specified lenses with large zoom range and fast aperture, partially compensating for the inability to change lenses. On some, the lens qualifies as superzoom. To compensate for the lesser sensitivity of their small sensors, these cameras almost always include an image stabilization system to enable longer handheld exposures.
These cameras are sometimes marketed as and confused with digital SLR cameras since the appearance is similar. Bridge cameras lack the reflex viewing system of DSLRs, are usually fitted with fixed (non-interchangeable) lenses (although some have a lens thread to attach accessory wide-angle or telephoto converters), and can usually take movies with sound. The scene is composed by viewing either the liquid crystal display or the electronic viewfinder (EVF). Most have a longer shutter lag than a true dSLR, but they are capable of good image quality (with sufficient light) while being more compact and lighter than DSLRs. High-end models of this type have comparable resolutions to low and mid-range DSLRs. Many of these cameras can store images in a Raw image format, or processed and JPEG compressed, or both. The majority have a built-in flash similar to those found in DSLRs.
In bright sun, the quality difference between a good compact camera and a digital SLR is minimal but bridgecams are more portable, cost less and have a similar zoom ability to dSLR. Thus a Bridge camera may better suit outdoor daytime activities, except when seeking professional-quality photos.[5]
In low light conditions and/or at ISO equivalents above 800, most bridge cameras (or megazooms) lack in image quality when compared to even entry level DSLRs. However, they do have one major advantage: their much larger depth of field due to the small sensor as compared to a DSLR, allowing larger apertures with shorter exposure times.
A 3D Photo Mode was introduced in 2011, whereby the camera automatically takes a second image from a slightly different perspective and provides a standard .MPO file for stereo display. [6]
[edit]Mirrorless interchangeable-lens camera
Main article: Mirrorless interchangeable-lens camera
In late 2008, a new type of camera emerged, combining the larger sensors and interchangeable lenses of DSLRs with the live-preview viewing system of compact cameras, either through an electronic viewfinder or on the rear LCD. These are simpler and more compact than DSLRs due to the removal of the mirror box, and typically emulate the handling and ergonomics of either DSLRs or compacts. The system is used by Micro Four Thirds, borrowing components from the Four Thirds DSLR system.
[edit]Digital single lens reflex cameras
Cutaway of an Olympus E-30 DSLR
Main article: Digital single-lens reflex camera
Digital single-lens reflex cameras (DSLRs) are digital cameras based on film single-lens reflex cameras (SLRs). They take their name from their unique viewing system, in which a mirror reflects light from the lens through a separate optical viewfinder. At the moment of exposure the mirror flips out of the way, making a distinctive "clack" sound and allowing light to fall on the imager.
Since no light reaches the imager during framing, autofocus is accomplished using specialized sensors in the mirror box itself. Most 21st century DSLRs also have a "live view" mode that emulates the live preview system of compact cameras, when selected.
These cameras have much larger sensors than the other types, typically 18 mm to 36 mm on the diagonal (crop factor 2, 1.6, or 1). This gives them superior low-light performance, less depth of field at a given aperture, and a larger size.
They make use of interchangeable lenses; each major DSLR manufacturer also sells a line of lenses specifically intended to be used on their cameras. This allows the user to select a lens designed for the application at hand: wide-angle, telephoto, low-light, etc. So each lens does not require its own shutter, DSLRs use a focal-plane shutter in front of the imager, behind the mirror.
Main article: Rangefinder camera#Digital rangefinder
A rangefinder is a user-operated optical mechanism to measure subject distance once widely used on film cameras. Most digital cameras measure subject distance automatically using electro-optical techniques, but it is not customary to say that they have a rangefinder.
[edit]Line-scan camera systems
A line-scan camera is a camera device containing a line-scan image sensor chip, and a focusing mechanism. These cameras are almost solely used in industrial settings to capture an image of a constant stream of moving material. Unlike video cameras, line-scan cameras use a single row of pixel sensors, instead of a matrix of them. Data coming from the line-scan camera has a frequency, where the camera scans a line, waits, and repeats. The data coming from the line-scan camera is commonly processed by a computer, to collect the one-dimensional line data and to create a two-dimensional image. The collected two-dimensional image data is then processed by image-processing methods for industrial purposes.
Further information: Rotating line camera
Many devices include digital cameras built into or integrated into them. For example, mobile phones often include digital cameras; those that do are known as camera phones. Other small electronic devices (especially those used for communication) such as PDAs, laptops and BlackBerry devices often contain an integral digital camera, and most 21st century camcorders can also make still pictures.
Due to the limited storage capacity and general emphasis on convenience rather than image quality, almost all these integrated or converged devices store images in the lossy but compact JPEG file format.
Mobile phones incorporating digital cameras were introduced in Japan in 2001 by J-Phone. In 2003 camera phones outsold stand-alone digital cameras, and in 2006 they outsold all film-based cameras and digital cameras combined. These camera phones reached a billion devices sold in only five years, and by 2007 more than half of the installed base of all mobile phones were camera phones. Sales of separate cameras peaked in 2008. [7]
Integrated cameras tend to be at the very lowest end of the scale of digital cameras in technical specifications, such as resolution, optical quality, and ability to use accessories. With rapid development, however, the gap between mainstream compact digital cameras and camera phones is closing, and high-end camera phones are competitive with low-end stand-alone digital cameras of the same generation.
A Canon WP-1 waterproof 35 mm film camera
Waterproof digital cameras are digital cameras that can make pictures underwater. Waterproof housings have long been made but they cost almost as the cameras. Many waterproof digital cameras are shockproof and resistant to low temperatures; one of them is Canon PowerShot D10, one of the first underwater digital cameras.
These cameras become very popular during the holiday season, because many people want to save the best moments from their holidays at the seaside. Waterproof watches and mobile phones were produced earlier. Most makers of digital cameras also produce waterproof ones and every year they launch at least one new model, for example Sony, Olympus, Canon, Fuji.
Healthways Mako Shark, an early waterproof camera,[8] was launched in 1958 and cost around 25 dollars. It was a huge camera and pictures were black and white.
___________________________
http://www.gobatteryonline.com/canon-nb-9l-digital-camera-battery-gose.html
http://www.gobatteryonline.com/canon-lp-e5-digital-camera-battery-gose.html
http://www.gobatteryonline.com/canon-powershot-sd500-battery-charger-gose.html
東大卒。自分はギリギリで東大理Iに受かったぐらいの大したことのない頭の持ち主だが、東大に入ったおかげで、色々な東大生を見ることが出来た。その結果、論理操作能力というのは極めて遺伝的なものであるという事実を知ることが出来た。東大の中でも頭がイイ奴は、特に、時間あたりに操作できる論理操作の数が常人の数倍は速く、常人より１桁正確だと思う。この事実を知ることが出来たことが、東大に入って最も良かったことの一つだと思っている。
お勉強が出来るだけでは社会に出ても役に立たないというのは、その通りだと思うのだが、論理操作能力が速くて正確なことは社会に出る上で非常に役に立つ。特に、議論で圧倒的に有利になる。議論って言うのは、実は、試験よりも速くて正確な論理操作能力が要求される。その場で返答しなければいけないからだ。試験だったら、その場でとっさに答えを思いつかなくても、「とりあえず置いておいて、試験時間終了間際にもう一度見なおしてみるか」といった戦略が取れるが、議論の場では、相手は何十分も返答を待ってくれない。その場で返答しないと意味が無い。
論理操作能力は遺伝的なものだから、訓練しても高くはならない。だから、論理操作能力が低い（才能がない）我々のような人間が彼らに勝つためには、「論理操作能力が高いヤツとは最初からマトモに議論しない」ということが重要だ。例えば、相手が持っていない情報に基づいて反論する。いくら論理操作能力が高くても、知らないものを知ることは出来ない。それから、論理操作能力が高いヤツの前では、自分のやっている仕事を面白そうに見せない。論理操作能力が高いヤツが自分の仕事を持って行くからだ。
こういう勝つ技術の中でも一番多く使うのは「自分の仕事に関係ないことは黙っておく」という技術だ。会議の中で自分より論理操作能力が高そうな人間がいて、その会議が自分の仕事に直接関係なく、意見することで何か自分に利益がもたらされるのでなければ、黙っておく。論理操作能力が高い人間の意見は高い確率で正論なので、しばらく放っておけば、そういう人間が会議を引っ張っていくようになる。
論理操作能力が低い自分でも、論理操作能力が高い人間が多く集まる東大という環境にいられたおかげで、こういう論理操作能力が高い人間の中で立ち回る技術を身につけることが出来た。人類の大半は、論理操作能力が低い人間だ。みんなで、共闘して奴らを追い落とそう。
追記：最後の文の「奴ら」は、論理操作能力が高い人達の事です。時間がたってから校正しないと、こういう曖昧性に気がつかないのが、僕の論理操作能力が低い証拠です。論理操作能力が高い人達は、即興で曖昧性の低い文章を書くことが出来ます。
また、「情報処理能力」の方が適当ではないかという意見がありましたので、「論理」「操作」能力とした理由を説明します。「論理操作能力」というのは、平たく言えば、「頭の回転の速さ」だと思ってください。
まず、「情報」ではなく「論理」という言葉を使ったのは、「情報」では、人に上手く質問して情報を引き出す能力や、ネットや本で調べる調査能力を含むような誤解を与えると思ったからです。そういう調べ物が得意な人は居ますが、その人の専門にもよりますし、信頼できる情報源をどの程度「知っているか」という知識の問題でもあります。例えば、法学部卒の人が法律に関することについて情報入手能力が高いのは当たり前です。一方、「論理」なら、こういった調査能力を含むかのような誤解は与えません。ですから、「情報」より「論理」の方が適切であると思いました。
次に「処理」ではなく「操作」という言葉を使った理由は、「処理」では、処理した結果何をアウトプットとすれば良いのかが明確に決まっている、という誤解を与えるからです。例えば、漠然と「何かいいアイデアない？」と聞かれた場合は、欲しいアウトプットは定まっていません。このような得たいアウトプットが明確に決まっていない状況でも、与えられた条件から「この条件とこの条件をこう組み合わせれば、こういうことが言えて（＝こういうアウトプットが得られて）、嬉しい！」ということを即興で考えつくことが出来る人がいます。僕は、「論理操作能力の高い人」という言葉で、こういう人たちのことを指したかったのです。
例えば、車を操作する、とは言いますが、車を処理する、とは言いません。「操作」という言葉が、どの方向に進みたいかを決めることをも含んでいるからです。一方、「車をA地点からB地点まで移動するという仕事を処理する」ということは出来ます。処理するためには、アウトプット（目的）が最初から決まっていないといけないのに対し、操作することは、アウトプットを定めることも含んでいます。ですから、「処理」よりも「操作」の方が適当であると思いました。
ところで、この文章では、遺伝的と先天的を同じ意味で使ってしまっています。僕が言いたかったのは「先天的」の方です。先天的だからといって遺伝的であるとは限りません。また、論理操作能力が先天的であるということは、実際に東大にいて、多くの東大生を見てきて、僕が経験的に（帰納的に）知ったことです。また、僕は、論理操作能力の高い人が東大だけに存在するとは思っていません。どの大学でも、名前が知られている大学なら、上位何％かは論理操作能力が先天的に高い人だと思います。東大は、その「何％」が、１～２割程度になっているぐらいです。東大は、一般教養の代わりに、シンフリ制度（最初は全員教養学部に属し、１年～２年前期までの成績で、他の学部学科に転籍する進学振り分け制度）を取っているので、学部・学科によって、論理操作能力の高い人の全体に占める比率は大きく異なります。シンフリ点数の高い学科は、やっぱり、論理操作能力の高い人が多いと思います。シンフリとかシケプリ・シケタイ・シケ長とかいった言葉を知っていることは、僕が実際に東大卒である傍証にはなると思います。
追記２：
言いたいことが伝わってこない、という人が何人かいるのですが、そういう方は、どこが悪いか教えていただけると幸いです。理系出身なので、各段落の1文目をキーセンテンスにして書く点や、曖昧性がないように書く点だけは気をつけて書いているつもりです。文章が長い（冗長性が無駄に高い）のは、校正してないのでしょうがないと思っています。
追記３：
何で「論理操作能力」っていう言葉を定義しただけで、こんなに反論が多いのだろう。とりあえず、「論理操作能力が高い」＝「与えられた前提から、単位時間あたりに論理的な推論を用いて導き出せる有意義な結論の数が多く、また、その推論が精確なこと」と定義しておく。単に論理的な推論がたくさん出来るだけ（＝論理演算能力が高い）では、コンピューターの方が人間より優秀だということになってしまう。論理的な推論を重ねて、「有意義な結論」を見出さなければならないから、「操作」という言葉を使った。また、人間は推論を間違えることも多々あるので（例えば、A→Bが、議論を進めていくうちに、B→Aも成り立つことになっていたり）、推論が精確であることも重要なので、「推論が精確なこと」を定義に含めなければならない。
「コミュニケーション能力」とか「国語力」とか「人間力」とかよりも、ずっと精確に定義できていると思うのだけど、何でこんなに反発を食らうのか分からない。
追記４：
英語を使うと冗長すぎるって言われそうなのでやめておいたのだが、やっぱり、書くことにしてみた。操作は、"operation"の意味で使っています。"operations"のように複数形に出来ることが大事。まぁ、"manipulation"の意味でもよいかもしれない…これも、"manipulations"にできるからね。"control", "exploit"の意味では使っていません。
追記５：
追記： id:le-matin さん（ http://d.hatena.ne.jp/le-matin/20090217/p1 ）より抜粋である事を明記した方がいいと助言を頂きました。ありがとうございます。
これを受けて、明らかな間違いの修正及び説明の追加、変更を加えさせて頂きました（2月17日 20:00）
共同通信とエルサレムポストが一番網羅的ですが、どの記事も講演すべてを収めていないものと思われます。ご留意下さい。
共同通信：
特記すべき点として、戦車・ロケット弾・白リン弾といった具体的な「得物」にふれています。他のニュースソースではまだ確認できていません。
http://www.chugoku-np.co.jp/NewsPack/CN2009021601000180_Detail.html/
http://www.sponichi.co.jp/society/flash/KFullFlash20090216041.html/
http://sankei.jp.msn.com/culture/academic/090216/acd0902161022003-n1.htm/
日テレ：
http://www1.ntv.co.jp/news/wmtram/dw/ng.html?m_url=090216039&n_url=129212/
i chose to come here rather than stay away. rather i chose speak rather than nothing....
フジ：
http://www.fnn-news.com/news/headlines/articles/CONN00149487.html/
i chose to see for myself rather than not to see. ... like novelist opposite....
TBS:
http://news.tbs.co.jp/newseye/tbs_newseye4063622.html/
whether this to create impression i supported one side in the conflict and that i endorsed the policy of a nation that chose to unleash its overwhelming military power...
（はたしてこれが紛争当事者の一方に付く印象を与えるのか、圧倒的な軍事力で苦しめる選択をした国家の政策を裏打ちするものになるのか・・・）
NHK:
http://www3.nhk.or.jp/news/t10014185071000.html/
I asked myself whether travelling to israel at a time like this and accepting a literary prize is a proper thing to do, they can not genuinly trust anything that they haven't seen on their own eyes or touched with their own hands...
http://www.japantoday.com/category/features/view/haruki-murakami-wins-jerusalem-prize/
（村上氏の発言のみ抜粋）
"sometimes takes on a life of its own and it begins to kill us and cause us to kill others coldly, efficiently and systematically."
"We are all fragile eggs faced with a solid wall called the system....To all appearances, we have no hope...the wall is too high and too strong...If we have any hope of victory at all, it will have to come from our utter uniqueness"
"Each of us possesses a tangible living soul. The system has no such thing. We must not allow the system to exploit us"
「時にはそれ自体が自らの生命を受け、私たちを殺し始め、私たちが他者を殺すよう冷酷に、効率的に、システマティックにけしかけます」
「私たちはシステムと呼ばれる堅固な壁を前にする壊れやすい卵です・・・・壁は高く、強すぎます・・・それでも望みを抱くのなら、勝利は私たちがそれぞれ唯一無二である事からやってこなければなりません」
「私たちそれぞれが形ある生きる存在です。システムにはそんな物はありません。システムが私たちを食い物にするのを許すわけにはいかないのです」
Gurdian（イギリス）
賞金が1万ドルであること、親パレスチナグループより受賞を辞退するよう働きかけがあった点についてふれています。
http://www.guardian.co.uk/books/2009/feb/16/haruki-murakami-jerusalem-prize/
Ha'aretz（イスラエル、ヘブライ語新聞メイン、英語と併売）
受賞理由と村上作品について。スピーチ内容については言及なし。
http://www.haaretz.com/hasen/spages/1064160.html/
http://www.jpost.com/servlet/Satellite?cid=1233304788868&pagename=JPost%2FJPArticle%2FShowFull/
（以下記者自身の記述を含め、だいたい訳しています。"the lucid wisdoms in his novels tend to come from acquaintances of the protagonist"の訳については全く自信がありません）
「イスラエルは卵じゃない」
わかりにくい？ 日本のベストセラー作家である村上春樹から聞く事になる説明としてはこれが唯一のものだろう。まさしく村上のスタイルであり、さらにどことなく曖昧である。
時差ボケ、政治的論議、マスコミの群れに逆らって日曜に彼は受賞のためやってきた。
シモン・ペレス大統領とエルサレム市長であるニル・バルカトを脇に従え、落ち着いた態度で彼は賞を受け取った。壇上で一人、フラッシュを浴びる事もなく彼は本題にかかった。
「ついにエルサレムに来ました。小説家として、嘘の紡ぎ手としてここにいます」
「小説家だけが嘘つきなわけではないです。政治家も（大統領、失礼）外交官も嘘をつきます。しかし小説家とその他の人々を分け隔てるものがあります。私たち小説家は嘘つきの嫌疑で訴えられる事はありません。賞賛を受けるのです。嘘が大きければ、またより高い賞賛を受けることになります」
「私たちのつく嘘とその他の嘘の違いとはすなわち、私たちの嘘が真実をもたらすという点です。総体をもって、真実を把握するのは難しい事です。だから私たちは真実を創作の領域に落とし込みます。しかしなによりも、私たちの中に潜む真実がどこにあるのか明らかにしなくてはなりません」
「私は今日、真実を語ります。1年のうちに真実を語るのは数日しかありません。今日がその1日です」
彼の小説は超現実的かつ想像力にあふれたもので、しばしば突拍子もないところまで話が進む。彼の本を読むのはピカソの絵画を見るようなものだ。普通の状態から離れる事を必要とされ、村上の世界では事物や出来事は彼固有のロジックに落ち着きどころを見いだす。
しかし彼の小説の根底にはロジカルなカオスとはまったく対称的な個人がいる。非常に人間的で、自己に目覚めた慎ましやかな個人だ。すなわちその個人の内的格闘は我々のものと同じなのだ。
村上を受賞者に選んだ選考は速やかに満場一致のうちに終わった。普遍的ヒューマニズムと現存する回答困難な問題との取り組みが（受賞理由として）引き合いに出された。しかし審査をめぐる論議はほとんど起こらなかったが、村上自身は受賞について複雑な心境だった。
「受賞の意志を打診されましたが、ガザでの戦闘の件があり、訪問を取りやめるよう警告がありました。私は自問しました。はたしてイスラエルを訪問するのが適切な事なのかと？一方の側を支援する事にならないか？」
「ちょっと考えを巡らしました。で、来ようと決めたわけです。大抵の小説家のように、言われたのとはきっちり反対の事をするのが好きです。それが小説家として、私の根底にあります。自分の目で見ず、自分の手で触れないものを小説家は信用しません。だから私は見る事にしました。なにも言わないよりはここでしゃべることにしました」
「ここに私が来て、言いたかった事があります」
すると村上は主要人物の仮面を脱ぎ捨て、端役へと回った（彼の小説では明確な啓示はしばしば主人公の奪還から立ち現れる）。発言は明快で、再考の余地はなかった。曖昧さのための時間はなかった。
「固く高い壁があり、卵が壁に打ち壊されるなら、壁がどんなに正しく卵がどんなに誤っていても私は卵の側に立ちます」
「どうしてなのか？私たちそれぞれは卵であり、壊れやすい卵にくるまれた唯一無二の存在だからです。私たちそれぞれは高い壁を前にしています。高い壁とはシステムです。それは通常では個人として受け入れがたいものを私たちに強います」
「私が小説を書く理由はただ一つです」続く彼の声音は控えめで、誠実な響きがある。
「すなわち個人が持つ唯一無二の神聖さを描く事です。唯一無二なるものを満足させる事です。システムが私たちをめちゃくちゃにするのを防ぐ事です。だから私は生と愛について物語を書きます。人々を笑わせ、泣かせます」
「私たちは皆人間であり、個人であり、壊れやすい卵です。壁を前にして、望みは失われます。高く、暗く、冷たすぎるのです。暖かみと力のために、私たちの存在を一つにして壁と戦わなくてはなりません。システムが私たちをコントロールするのを許してはいけません。私たちが何者であるか、決めさせてはいけません。システムを作り上げたのはは私たちですから」
村上は読者への感謝の言葉で締めくくった。受賞のために人前に出る習慣のない人物としては、本当に特別な事だ。
「イスラエルの皆さん、私の本を読んでくれて感謝します。意義ある何かを共有できればと願う次第です。あなたが私がここにいる最大の理由なのです」
あきらかに素人さん相手の説明でそりゃーないでしょ。というか、第1の問題点として指摘しているかのように書いてあるし。((○メモリ上にプログラムを自力でロードして、それを関数ポインタに変換して関数コールすると、Exploit系のバグなのか、わざとやっているのかが外部ツールで判別付かない場合があるので、この方式は使わなくなり、現在はＤＬＬ呼び出しやＳＯ呼び出しが一般的。))まぁいいけど。。。
そもそも、まさに動的リンク機能がOSに導入されようとする移行期にそういうexploit監視検出ツールがあったのだっけ？私が知らないだけかもしれないが。それくらい昔ならばせいぜいCPUによる保護とかOSによる保護くらいしかなかったでしょ。
ツールにひっかかるから、ですらないと思う。単にそういう技が必要なくなっただけ。 そもそもexploitに晒されるほどポピュラーでかつOSの動的リンク機能が使えるほど近代的な環境になってさえ、動的コードセグメントを使ってまで最適化スピードアップしなきゃいけないような変態的ケースは今じゃ殆ど無いんじゃねーの。ゲームかPC DEMOくらい？ ひょっとしてケータイでもそういうことをやるのだろうか。 そもそもそれ以前にアルゴリズムの改善とかアーキテクチャの見直しとかできることは山ほどあるような気もするが。 というかツールで監視するくらいならCPUの保護機能でオフにするんじゃないのという気もする。
人工知能的なことをやりたいのであればCは圧倒的に不向きで、そもそもevalがある言語(Python/Ruby/etc..)使えばいいんじゃねーの、という話になる。もちろん Lisp/Schemeもそうだけど。。。
(追記に対してレス…)
void *(*psrc)(void *); void *pdst = (void *)psrc; 究極 printf("%x\n",(int)psrc);
そーいうのは曖昧と呼ぶの？ どちらもC言語的には未定義動作で、単にコンパイラがこういう風にコンパイルしますよということが分かっているから書くのだし、何もambiguousではないよね。
そーいうことはxbyakとか使えば楽にできるとおもう
○メモリ上にプログラムを自力でロードして、それを関数ポインタに変換して関数コールすると、Exploit系のバグなのか、わざとやっているのかが外部ツールで判別付かない場合があるので、この方式は使わなくなり、現在はＤＬＬ呼び出しやＳＯ呼び出しが一般的。
ちゃんとExploit系に使われる関数ポインタはクラックの対象ってExploitというキーワード書いたのに(T_T)。高々、コンパイラが保証してくれる範囲の関数ポインタは安全だから使えばいいと思うよ。
究極
printf("%x\n",(int)psrc);
こういう技が必要になることもあるし。
Cって面白いと思う。
char *prog="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
void *(*psrc)(void *) = void *(*)(void *)prog;
(*psrc)(NULL);
こんな感じで、データ配列のプログラムとしての実行で、昔はあったけど、いまはこういうコードはDLLとかSOとかで書くのがお作法だよねーと
さらにいえばWindwosならCOMで書けと・・・
どうみても、Code Exploitのバグに見えるもの、この手のコードは。
外部ツールがバグとして引っかけちゃうから書かないのが最近の主流だと思う。書く必要もほとんど無いし。
Lispのようにプログラム自身がメモリ上に動的にプログラムを必要に応じて計算しながら書き込んで、それを実行すれば、ある意味人工知能的なプログラムとその美しさが実現できるけど、それは一般的なプログラムの範疇ではバグの検出が複雑になるので、やっちゃダメとはいわないが特殊分野の技法だなぁと思う限り。
