「個人情報」を含む日記 RSS

はてなキーワード: 個人情報とは

2016-05-30

犯人に怒るのではなく取締機関に怒れよ

不法行為犯罪が頻発してるってニュースに接したとき

犯人に怒ったってしょうがないだろ。

なんの建設性もない。

犯人実家に怒りをぶつけてもなにも返って来ない。




そうじゃなくて、

子供虐待ニュース見たら児相に怒れよ。怒りの電話メールを送りまくれよ。

現場の奴等だってナマで怒りの声聴けばビビッて身が引き締まるし、

市民からの抗議〇百件」つって上に上げやすくなって組織改革予算増にも繋がる。




ブラック企業ニュース見たら労基に怒れよ。

仕事してるのか」「ブラック企業に金でももらってるのか」って電話メールギャンギャンしろよ。





いじめニュース見たら教育委員会に怒れよ。

責任者ポスト人間達の名前や公開個人情報まとめてネットに掲示しろよ。




業務麻痺する?

どうせいい加減な仕事してる奴等か全然できてない奴等なんだから

変わる切っ掛けになれば安いもんだろ。




知的建設的に、事態への責任改善能力持ってるとこに怒れよ。

役人なんてそうしてもらえないと変われないってとこもある(経験談)。

2016-05-29

http://anond.hatelabo.jp/20160529111004

この増田なら絶対ターゲット個人情報書きそうに無いし精神障害者年金貰ってる方のキチガイかなぁ…

精神病disされて発狂してんのかな?

精神病人間はこういう所が甘い気がする

増田の言う意味ちょっと分かった

2016-05-28

コンビニバイト並みの時給で人雇ったらそりゃやらかす奴も出てくるにきまってるじゃん」…という事なら、

コンビニバイト個人情報流出させても怒らないであげてくださいねっていう

2016-05-23

最近おなじ悪夢を見る。

Togetterを何気なしにみたら俺の鍵付き垢を面白おかし編集したまとめを見つける夢。

「あれ?鍵つけてたはずなのに・・・」と確認したらいつの間にか一般公開されてる。

そこでブラウザ閉じればいいのに夢のなかの俺はそのまとめのコメント欄まで読み始める。

もう誹謗中傷の嵐。ネットだけじゃ知り得ないような俺の個人情報まであげつらって俺を人格攻撃してくるアニメアイコンの群れ。



そんな夢を何回も見る。全く同じシチュエーションで。

唯一違うのは回を重ねるごとにコメント数が増えてるってことだけ。



俺の垢なんて遠くても顔見知りのレベルしかフォロワーがいない細々としたものだ。フォロワー数は100もいかない。

プライベート垢ということもあり、注目されることなんてありえないというのに何故こんな夢を見るのだろう?

嗚呼ツイッターを閲覧することも寝ることも憂鬱になってきた。

2016-05-22

NHKのひとが来た。

ピンポーン♪

N:「ちわー、NHKです、お願いしまーす。」

「はて?どういったご用件でしょうか?」

N:「受信契約の件です。」

テレビもっていません。」

N:「パソコン携帯おもちじゃありませんか?それでも契約頂かないと」

iPhoneテレビ見えませんよね?」

N:「それではご案内だけでもお渡ししたいので扉開けてもらえませんか?」

ポストに入れておいてください。あとで見ておきますので」

N:「個人情報に関することなので手渡しでないとだめです。」

なんだか気持ちわるい。

家電のBigOnion [お知らせ] 2016年5月20日

お客様個人情報入力・表示される「注文画面」、「会員登録画面」、「お問い合わせフォーム」につきまして、最新のセキュリティに強化

しました。

ウイルス対策/スパイウェア対策/スパム対策/不正アクセス対策

家電のBigOnion - 家電卸・格安販売

2016-05-19

電車への飛び込み自殺者は顔と名前と経歴を晒すことにしてはどうか

彼等の殆どメンタル的に自分のことを広く知られるのは嫌がると思う。

自殺者の顔や個人情報が死後広く晒され当人過去に関わった人間他に周知されているのを見たらかなり嫌になって他の自殺法を選ぶだろう。

メディア晒すのが1番望ましいし

次点では指名手配犯の様に紙で駅に貼りだすのがよいが

手間や良識ぶりっ子の抵抗を考えると最初web検索すればいつでも出てくる感じのデータベース収納が望ましいだろう。

プロ市民署名活動はどうにかならないもの

駅前で「憲法九条を護ろう」「戦争法案反対」「アベ政治を許さない」などのテレビでよく見るありきたりなプラカードを掲げたおばさん達が「署名お願いしまーす!」と大声を張り上げていた。

その前を通り過ぎようとすると、おばさんの一人に腕をつかまれて「あなた署名しなさい!戦争したくないでしょ?」と言われたので

「興味ないです」と言うと、それを耳にしたおばさん5、6人に囲まれ日本戦争することになるのよ!」「あなた戦争に行くことになるのよ!」「あなた人殺しになるのよ!」「あなたの愛する家族が殺されるのよ!」と極論を捲し立てられ、「死にたくなかったらあなた署名しなさい!」とボールペン署名用紙を渡されたが署名用紙を見ると氏名と一緒に住所を書かなければならず、こんな団体個人情報知られてたまるかと俺を押さえつける腕を振り払ってなんとか逃げてきた。

いくらバサンでも5、6人に囲まれて押さえつけられたら振り払うの大変だったよ。

どうも、一人で歩いてるような気の弱そうな若者を見つけては極論で脅迫して署名させてるようだった。

この話を以前別サイトに書いたところ、アベ政治を許さないさん達から「そんなことをする訳がない」という否定をたくさん頂いたが、実際されたんだから仕方ない。

アベ政治を許さないさん達も、そういう酷い脅迫署名活動をしている団体もあることは知ってるだろうに、それは知られちゃマズイんだろうなぁ。

まずそういう活動する前に、自分達の振る舞いをどうにかしたらどうか。

よくあんな横暴な振る舞いしてて、駅前活動続けられるな。どうにかならないもんか。

2016-05-18

http://anond.hatelabo.jp/20160518131708

アンタ雑だな・・・

そんな言い方じゃ誰にも信用されないでしょ


まず、Windows10スパイウェアだと言われているのは下記のブログに詳しく書いてあった

http://d.hatena.ne.jp/msystem/20160409/1460127785

引用すると

Microsoft社の契約内容には、次のような一文が含まれています

プライバシーデータ使用への同意お客様プラバシーは、当社にとって重要です。本ソフトウェアの一部の機能については、当該機能使用する際に情報が送受信されます。 』

まり、「Windows 10を使うことで、個人情報Microsoft社に送信されるが、その点を了解した上で、Windows 10を使う事に同意します。」と言うことです。

確かに、この一文だけを見れば、「問題だ !」となりますが、先ほどの文章の後には、次の文が掲載されています

『 これらの機能の多くは、ユーザーインターフェイス無効にするか、使用しないように選択することができます。 』

一応、情報MS送信されるのは利用規約にも明記されているが、その機能オフにできるとも書いてある。

で、その送信する内容ってのは

下記の個人情報が、全てMicrosoft社に渡ってしまうと思います

・連絡先

カレンダー記載した予定

音声認識情報

手書きパターン

入力履歴

位置情報

・利用言

・利用URL

だそうだ。

確かにデフォルトだとスパイウェアと呼ばれてもおかしくはない。



ただ、個人的にはセキュリティサポートが切れた PC ほど脆弱ものはないので、Windows10 あげるなと声高に叫ぶのが良いこととも思えないな

2016-05-12

topisyuさんが夢に出てきて、冷や汗かいて深夜に起きた

小規模のイベントホールで対談という形で顔を合わせた。

topisyuさんはプロジェクタで俺のブログを表示しながら、

いか矛盾に満ちているか」を、とうとうと説明していた。



「これで差別的表現ではない? でもこの画像を選ぶのはフェアではないと思います(笑)

特定の個人を示してない? でもリンク張ってますよね(笑)

「ここで今と4年前の、増田さんのブログ比較して見てみましょう(笑)



こんな指摘を受け続けて、

「そうですね。おっしゃる通りです」

「えー、自覚はしています。ただその頃は思慮が足りなかったというか、はい

ちょっとそこ指摘されると厳しいんですけれども、ええ、言葉がありません」

とぼろぼろな受け答えをしていた。




そこまでならまだよかったのだが、最後にこんな発言があり恐れおののいた。



増田さんが現在ブログを始めた同時期に、更新を止めているあるブログがあります

「関連性については深く調査をすることができませんでしたが、ご想像にお任せしようと思います

「参考までにURLスクリーンショットを載せて、本日は降壇します。ありがとうございました」



それは俺の旧ブログで、書いてある内容もさることながら、

個人情報セキュリティ意識に欠けた記事が多く、

執念があれば個人特定できるようなブログだったのだ。



この旧ブログ問題点自分自身把握しているのだが、

内容も全てが悪いわけではなく、その分野に興味がある人には、今でも楽しんで読んでもらえると思う。

ただ量も膨大なため放置しているのが現状である




戦慄しているとHagex足音が近づいている感覚が俺を襲った。



「あ、俺終わったわ……」



ここで目が覚めた。

汗がびっしょりで布団は湿っていたが、安堵のため息が口から漏れた。

本当に夢でよかった。

2016-05-07

中古hddレコを買った数日後にNHKが来た

http://www.mukaikaze.net/entry/nhk-inuhk

これ見て思い出した事があったので。数年前の話になるが。


秋葉原中古hddレコーダーを買った。

というか箱なし赤カード無しDVDドライブ不良だしほぼジャンクか。

家まで貧相なポリ袋で持ち帰って余ってたカード挿して余ってた液晶つなげて一応映ったーとか思っていたのだが

その数日後にNHKが来た。なぜ来た。



心当たりのある点で言うとこの辺りなのだが、一体なぜなんだろう・・・

2016-05-04

日帰りバス旅行一人旅

かねてより行きたいと思っていた場所へのバス旅行を見つけ一人で申し込んだ

時期もよく、道中のお弁当も晩ごはんもおいしくてお値段以上の内容だったと思う

交通事情にも恵まれ渋滞ほとんど捕まらず快適な運行スケジュールだったのもよかった

同日出発の同社の別ツアー夕方17時で未だ目的地に辿りつけないという有様だったことを考えると

満足と言って良い旅であった




しか一人旅で満了ツアーのため、隣には同じく一人参加の女性が座っていた

78歳のご婦人

連れ合いを早くに亡くし、友人との旅行を楽しんできたが最近はもっぱら一人旅

世界中を飛び回るアクティブなご婦人である

数日前にも立山黒部アルペンルート一泊二日に一人で参加されたらしい




このご婦人がとにかく元気なのだ

往路だけではなく復路でもずーーーーーーーーーーーーーーっと喋り通しで

彼女の生い立ちから結婚、夫との死別子供二人の話に孫の話と78年の年表を作成できるのでは?と

いうくらいに微に入り細を穿ち延々話されるのである

経歴はエリート然としたものばかりなので別に構わないと思ってらっしゃるのかもしれないが

子や孫の経歴にまで及ぶと個人情報とは、と思ってしま




そしてそんなご婦人のパワーに圧倒され、道中寝たいですとアピールできなかった私は

往復一睡もできず疲れを残して帰宅したのであった

ヤフー広告気持ち悪い

ヤフーログインした状態だと表示される「○○市の新規分譲マンション」とか「○○市のローン」などの広告がとても気持ち悪い。

登録した個人情報を使って広告を表示しているのは分かるけれど、年齢や性別、住所などの情報をもとにしている広告を表示させない設定てできないの?

インプットよりアウトプットが尊ばれる状況

一昔前だとクイズ王なるものテレビに出る時代もあったが、この界隈も冷え込んでしまった。

最近ではクイズと言いながら、芸能人が(おそらく台本通りに)茶番を繰り広げる番組ばかりになっている。

それは一般人個人情報云々というのももちろんあるが、情報インフレ化というか、

手元のスマホでググれば大抵のものは出てくる、という今の状況とも無関係ではないと思われる。

情報情報として知っているだけでは、今の時代別にすごくはないし、従って何の価値もない。

ガキの頃から言われていた話だが、本当にそうなったのはつい最近のことのように思える。



もちろん、それ自体技術革新の成果だし、決して悪いものではない。

何かを聞くにあたって、相手の顔色を伺う必要も、余計なうんちくを押しつけられる危険もなく、

安全情報を手に入れることができるなら、そっちの方がいいに決まっている。

そしてそうなれば、情報のもの価値が低下するわけで、相手をいい気分にすることができる人間や、

リテラシーの低い人間にもわかりやす説明できる人間がもてはやされるのは、当然といえば当然の流れだ。



ただ、そういう能力というのは、鍛えようにも鍛えられる部分ばかりではなく、

どうしても顔やら何やらに左右されてしまうわけで、正直気分のいいものではない。

どうにかして、技術でもって、奴らを引きずり下ろす術はないものだろうか。

2016-05-03

http://anond.hatelabo.jp/20160503141942

個人情報は一ミリバイトも流すなときつく教えて使わせるのが一番

身バレしなけりゃどんな暗黒歴史でもバックレられる

2016-05-02

NTT代理店を名乗る電話にご注意ください

NTT代理店を名乗る迷惑電話が多くなってきた。こちらの声色をうかがって電話が切れることも多いので、大変迷惑である。これは想像しかないのだが、その代理店風情の会社新入社員が入って、NTTから渡された名簿を使って上から順番にかけているのだろうと考えられる。かわいそうな状況が想像できる。穏便にやりすごすことを考えてみた。



対策1 まず名乗らない

昨今、ほとんどの電話携帯電話あてにかかってくる。

はい佐藤です」などと、こちらの情報相手に渡す必要はないので、とりあえず「はいもしもし」と受け答えしよう。

知り合いならば、「佐藤さんですか。鈴木です」とコミュニケーションが取れるので、「はいもしもし」で問題ない。声でもわかる。



対策2 留守番アルバイトを装う

電話回線が古いので、光電話に変えませんか」とセールスをしてくる。相手を怒らしても冒頭のような状況でかわいそうなので、決定権がないことをやんわりと伝えよう。

すみません。ここ事務所で、今、社長がいないんですよ」と言ってみる。一般家庭のお年寄り狙いのNTT代理店を名乗る業者は、法人アルバイト相手にしてもしようがないということであきらめてくれるはずだ。最後に「ごめんなさいね」などと言っておこう。穏便に電話を切ることができる。



対策3 「136」にかけて相手電話番号確認する

ナンバーディスプレイを申し込んでいない場合でも、「136」にかけると直前の着信の番号を知らせてもらえる。まともな業者ならば、発信番号通知してくるだろうし、インチキくさいところならば、非通知設定である。面倒でも、何月何日の何時何分という記録は残しておこう。



対策4 「116」に電話してNTT代理店から勧誘を止めてもらう

天下のNTTグループがなんでちんけな代理店を使ってそんなせこいノルマかせぎを繰り返しているのか、はなはだ疑問を感じるのだが、大人の事情があるのだろう。それが民営化というものなのだろうか。あまりにしつこい場合は、「116」に電話して、「4」番その他のお問合せにつないで、「NTT代理店を名乗る業者から勧誘電話が多くて困っている」と伝えよう。すると「代理店へ回る名簿から消すことができますので、…」と話しが進むので、本人確認をして消してもらおう。ここで、話がすんなり進まないときは、対策3のところで作った電話がきた履歴を伝えよう。



ここまでの対応で、穏便に解決されることが望ましい。それでもだめな場合対処法は以下に

対策5 相手会社名と電話番号を聞き出す

NTT代理店がどこのどの会社であるのかを確認したい。存在する会社なのかどうか。「社長が戻ってきたら、あとでかけなおすから電話番号会社名と住所を教えてください」と言ってみよう。たいてい教えてくれない。

対策6 勧誘の内容を書面で送ってくれと依頼する

よく検討したいからパンフレットを送ってくれと頼むと、証拠が残るので、送れませんと言い始めた。引っかける気まんまんである

対策7 個人情報保護担当につないでもらう

名簿が流出していることを個人情報保護担当者に伝えよう。ホームページの片隅に書かれてるいるのだが、代理店への名簿の提供が、正当な個人情報の扱いの範囲内かもしれない。信頼の大手通会社利用者にとって不利な個人情報提供オプトアウト方式であることは由々しき事態だ。





蛇足だが、NTTコミュニケーションズドコモ光に客を取られまいと極秘の勧誘電話をかけてくることもある。顧客とのダイレクトな窓口戦略を巡って、大手通信会社とは思えない泥仕合が展開されている模様。グループ企業内でパイを奪いあうとは意味不明だ。こちらもパンフレットなどの書面は証拠が残るから送らないそうだ。



ということで、ご注意をおねがいいたします。

個人情報保護法

個人情報保護法

・今回の注意点

個人情報プライバシー侵害がどう違うか どう関係するか

どこまでが保護されるのか

義務は誰にある?

二段階の判断 (原則)

個人情報個人情報保護法定義に収まるか?

送信した人はこの法律でいう個人情報取り扱い事業者であるか?

事業者でなければ法律適応されない

個人情報とは? ・・責任を負う人を限定している

生存している特定の個人を識別できるもの

氏名など。

⇒亡くなった人はこの法律では無理


学校社会で名簿を作成して配布することは

個人情報侵害になるのでは?

⇒本人の同意を得て作成することができる

カメラ他人勝手撮影することは、個人情報保護法違反か?

動画写真を撮った人は事業者か?

ならない。ただし肖像権違反にはなるかも

別の法律違反になることになる

(他人権利侵害する場合がある)

個人情報保護する義務のある人は?

個人情報取り扱い事業者

5000件以上の個人情報個人情報データベース等として所持し事業に用いている事業者

個人情報ダメならプライバシーの方が限定がなく範囲が広いのでこちらで罰せられる場合がある。プライバシー限定がない。

個人情報保護法個人情報範囲保護義務主体限定している

テストに出すと言っている

Googleストリートビューは個人住宅など プライバシー侵害でないのか、どうなのか なる?ならない?⇒考えて欲しい

肖像権 パブリシティ研修

報道被害・・誇張によって誤認してしまう内容

報道の自由 国民知る権利 VS 被報道者のプライバシー

個人情報プライバシーの違い←テストに必ず出る

一般人プライバシー芸能人プライバシーの違い


肖像権パブリシティ権試験出る

写真家モデル撮影

モデル肖像権 写真家著作権

肖像権・・写った人の権利

原則 期末出る。

肖像権・・自分肖像他人勝手に使わせない★人格権利★のこと

パブリシティ権・・★顧客吸引力★がある肖像名前の利用を専有する権利のこと(有名人芸能人商業的な価値がある人のみ持っている。

人に備わっている顧客吸引力を中核とする経済的価値(パブリシティ価値)を保護する権利プライバシー権と同じく人格権に根ざ




顧客吸引力を利用するものであればパブリシティ権侵害

自分文章にまとめよう

とうこう

2016-04-28

名刺の一部を第3者に公開!?クラウド名刺管理のSansan、やばいだろ...

ポイントサイトモッピーっていって、この手のポイントサイトでは、大手で、結構稼げるとか書いてある。

という情報をいろんなアフィリエイトサイトでみて、モッピー登録してみた。

本当に稼げるのか?(←結局ねずみ講みたいな

結局アフィリエイトで、稼いでいるということがわかった。

そんなことはどうでもよくて、ミニゲームの画面にクラウド名刺管理会社のSansanのロゴが。

Sansanは最近CMをしているので、ご存知の方もいると思うが、あのクラウド名刺管理サービス会社である

で、このモッピーミニゲームヤバイ

タイピングゲームなんだけれど、画像をみて、タイピングするもの

お金になるけど、まじで換金率は終わっているレベル時間無駄

そんなことはどうでもいい。

で、このゲーム、左の画像をみて、右の画面の入力欄にタイピングするもの

その画像が実際に使われているやつ。

分断されているけれど、氏名や住所、メールアドレス電話番号FAX番号などが画面で表示されている。

氏名は氏と名でわかれているし、メールアドレスも@前後で分断されているから、個人情報には直接はあたらない。

でもさ、Sansanのロゴが書いてあるから、実際の名刺で、画像認識自動入力できなかったやつだぜ。

電話番号なんてひどいもので、11桁を入力するんだ。

から、このまま電話することもできちゃうんだよ。

いいの?

こんなことして。

Sansanって名刺管理会社なのに、こんな第三者お金欲しいよ、稼ぎたいよとか言っているやつらに

画像公開しているんだよ。

誰かの名刺をそのままスキャンしているから、

その名刺の持ち主が、Sansanでスキャンしていること知らないから

自分情報が、一部だけれど、勝手インターネット上で第三者のところに画像が送られているんだよ。

結局、自分のところの画像認識技術の確度さえ上げればいいんだろ?

ヤバいんじゃないかな。

2016-04-27

残業却下するなら、代わりに仕事を片付けて

仕事は増える一方なのに、人員を増やさず、残業はするなってどうすればいいんだよ?

時間内にこなせる仕事量にも限度がある。

好きで残業してるんじゃないんだぞ!

却下される残業申請

認められないサビ残

持ち帰れない個人情報

山積みの仕事

迫りくる締切。

鳴り止まない催促の電話

毎日少し残業させてもらえれば楽なのに。

残業却下するなら、代わりに仕事を片付けておいてほしい。

2016-04-26

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

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

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

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

OAuth とは

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

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

おことわり

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

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

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

記事の構成

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

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

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

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

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

責任ある情報公開

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

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

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

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

想定する利用形態

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

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

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

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

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

問題点

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

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

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

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

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

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

前掲のセキュリティ文書は、Permalink | トラックバック(3) | 12:44

2016-04-25

おいおいsql漏れてるやん

挑戦ボタンを押したらsql漏れ漏れ

いい加減すぎるだろ・・・

個人情報とか漏れそうで怖い

http://www.kentei-uketsuke.com/kaigi-kentei/practice_guide.html

2016-04-21

ネットモラル低下はやっぱり低年齢化が問題だった

googleマップとある地点のレビューに、☆1という最低評価が付いている。

私も伺ったことがあるが、注意点はあるものの概ね良い評価を述べることができる場所だ。

現に不自然な☆1評価以外を見ると、しっかりとしたコメントとともにまあまあ平均以上の評価が付けられている。

その☆1評価には、短くコメントが付けられていた。

「まだ行ったことがないから

評価をつけるに値しない人間評価をしているという事がここでわかった。この人間は、訪れたことがないのに評価をつけているのだ。

そして、自分体験にない=評価なし=☆1だと判断しているのだった。

さて、このレビュアーだが、少ないながらも他に評価を残している。

先に断っておくが、こういったレビューレーティングは、一般的に誰でも利用できる施設商店に対して評価をするもので、公に開かれていない場所に対して評価をすることは事実上意味が無い。

企業クローズド社員食堂評価など需要が無い上に個人情報漏洩に繋がるのだ。

話は戻り、この不自然な低評価をつけたレビュアーの他の投稿を見ると、小学校評価をつけていた。☆5の最高評価と共に、ご丁寧に「楽しいよ♪」というコメント付きだった。

前述の(言っては角が立つが)無教養な振る舞いとこの小学校への評価コメント鑑みるに、無自覚小学生レーティング荒らしているのだ。

ネットの低年齢化は盛んに取り沙汰されてきたが、コミュニティを越えて開かれた場所に現れたのを見て恐ろしくなった。子供には社会常識モラルも通用しない。

パブリックサービス年齢制限必要になる時代がやって来たのだと実感した。

2016-04-20

http://anond.hatelabo.jp/20160420135151

あん悪魔ツールに慣れておまえに良いことなんて何もない

慣れたが最後、発してはならない言葉個人情報を漏らしてお前は社会的死ぬ

あれは馬鹿を殺すマシン

なにがいちばんしんどいって

誰にも悪意や攻撃意志はまったくないのがしんどおおおおい

現状ただわたし勝手自動的に傷ついてる状態なのがしんどおおおおおい

相手が悪すぎて少なくとも職場関係者には相談できなあああい

しか職場でせめてなんかアクションないと二の舞三の舞舞わされることは確定的に明らかあああああ既に次の飲み会セッティングされてるぽいしいいいいい

そもそもこの件自体ある意味二の舞だしいいいい

別件で別の役職者が別の社員のなかなかシャレにならない個人情報を「こんな人もいるんだから元気出して」的文脈普段職業上の接点ほぼ完全にゼロわたしに(結果的に)バラしたりとかしてるしいいいいい

今回だってたまたまだが職場情報(笑)が同席してるしいいいいいいいいいギイイイイイイイイイイ

前々から業界的にも「今どきねーよwww」がまかり通るようなところあったけど流石に嫌気が差しまくりすぎるううううう

ああああああああ一昨日の自分ビンタしたいその出席メール今すぐ取り消せ送信すんなと言いたあああああい



http://anond.hatelabo.jp/20160420073120