「モーニングコール」を含む日記 RSS

はてなキーワード: モーニングコールとは

2019-07-11

仕事はできるけど結婚はできない女

になると思ってたら逆になってしまった。

婚活ブログが刺さる。

結婚仕事を入れ替えたら私と同じ辛さを抱えてる気がする。

彼氏いない歴=年齢で、一生結婚どころか彼氏も出来ないだろうと心の底から思ってた。

男女問わずいじめられて気持ち悪がられていた。

誰の誘いも告白も断ってないのに、女として一番価値があるであろう高校時代までに告白された事はなく、彼氏セフレもできなくて処女のままだった。

長所絶望的に無い、年齢と共に価値が落ちていくだけの自分は一生喪女だと思ってた。

一生独身なら自分自分を養わなくてはいけない。

老後支えてくれる人はいいから、65歳までに自分老人ホームに入れるくらいのお金を貯めなければと思った。

その為には良い会社就職して高収入を得る必要がありそうだと思い、就活について調べた。

働いて、対価としてお金を得るのは楽しそうだと思った。

就活用に化粧を学び、真面目に授業を受けて上位20%の成績を取り、学生コンペで優勝し、インターンシップ複数参加し、そして就活は全滅した。

書類はほぼ全部通るが面接が通らない。最終面接まで行けた会社は2社だった。落ちたけど。

ブラックで有名な会社も構わず面接した。

卒業式の次の日まで面接を入れ続けたがダメだった。

面接で落ちるということは、人間性ダメということだ。

自分には価値が無いということを思い知らされた。

派遣社員になった。

その頃趣味のつながりで縁があり、人生初の彼氏ができた。

趣味が同じで優しくて、絶対怒らなくて頼めば毎日モーニングコールをしてくれて、実家が太くて親も優しい彼氏だ。

同棲して結婚もできた。

結婚生活は大変なこともあるけれど、毎日楽しい

が、派遣社員のままだ。

転職活動は数社落ちて心が折れた。もう受けたくない。もう拒否されたくない。

でも受けないと正社員にはなれず、一生給与は上がらない。

契約なんて、いつ切られるかわからない。

実家の近い父に会うたびに「仕事はどうなんだ」と聞かれる。したいよ。けど、私はいらないんだって

母には孫を聞かれるけど子供を育てるより仕事お金を稼ぎたい。

受けなきゃ受からない、少し休みたい。しかし休んでいる間にも年齢を重ねて転職市場価値は低くなっていく。ろくなキャリアが無くて、私には年齢しかないのに。

婚活ブログが刺さる。

結婚仕事が逆なだけで同じことを言ってる。

2019-06-08

お礼!ブクマカがススメたラジオ~日曜~

以前おすすめラジオ教えてって聞いたらたくさん教えてもらい楽しくラジオ聞いてます

教えてもらった番組をまとめたのでよければどうぞ。

自分用にまとめたものなのでチャンネル関東圏になってますがご了承ください。

調べがつかなかったものは載ってません。教えてくれたのにごめんなさい。

番組

曜日

時間24時間表示)

チェンネル

出演者

URL

-------------------------------------------


天使モーニングコール
土or日
6:00
ラジオ日本
1422

ttp://tenshi-call.com/stations/


三宅裕司サンデーヒットパラダイス

9:00
ニッポン放送
93
三宅裕司江口ともみ
ttp://www.1242.com/program/chart/


日曜天国

10:00
TBSラジオ
90.5
安住紳一郎
ttps://www.tbsradio.jp/nichiten/


NHK子ども科学電話相談

10:05
NHK第一
AM)594
山田敦子石山智恵、山本志保
ttps://www4.nhk.or.jp/kodomoq/


Flow

11:30
東京FM
80(86.6)
木村拓哉
ttps://www.tfm.co.jp/flow/


のりこの週刊おばさん白書

13:00
IBC岩手放送
radiko
後藤貴子
ttps://www.ibc.co.jp/radio/684/obasan/


爆笑問題の日曜サンデー

13:00
TBSラジオ
90.5

ttps://www.tbsradio.jp/nichiyou/


ミキ兄弟でんぱ!

13:00
KBS京都
radiko
ミキ
ttps://www.kbs-kyoto.co.jp/radio/miki/


sundaysongbook

14:00
JFN PARK
アプリ

ttps://www.tatsuro.co.jp/sunday/


きらクラ

14:00
NHK-FM
82.5
ふかわりょう遠藤真理
ttps://www4.nhk.or.jp/kira/


気象通報
月火水木金土日
16:00
NHK第二
693

ttps://www4.nhk.or.jp/P2590/


Jazz ain't Jazz

16:00
インターFM897
89.7
沖野修也
ttps://www.interfm.co.jp/jaj/


あ、安倍礼司

17:00
東京FM
80(86.6)

ttps://www.tfm.co.jp/abe/


ワールドロックナウ

17:00
NHK-FM
82.5

ttps://www4.nhk.or.jp/wrn/


Tokyo Moon

17:00
インターFM897
89.7
松浦俊夫
ttps://www.interfm.co.jp/moon/


競馬LIVEGO!
土日
1710、9:00
ラジオNIKKEI
radiko

ttp://www.radionikkei.jp/keibalivego/


村上ゆきのスローリビング

18:00
TBSラジオ
90.5

ttps://www.tbsradio.jp/slow/


ショーアップナイター
火水木金土日
18:00
ニッポン放送
93

ttps://baseballking.jp/showup


ラジオチアーズ

18:00
ABCラジオ
radiko
浜端ヨウヘイ小塚舞子たつを
ttps://www.abc1008.com/cheers/


有吉弘行SUNDAY NIGHT DREAMER

20:00
JFN PARK
アプリ
有吉弘行
ttp://park.gsj.mobi/program/show/27400


ラジオ寄席

20:00
TBSラジオ
90.5

ttps://www.tbsradio.jp/yose/


BARAKAN BEAT

20:00
インターFM897
89.7
PETER BARAKAN
ttps://www.interfm.co.jp/barakanbeat/


草野マサムネロック大陸漫遊記

21:00
東京FM
80(86.6)

ttps://www.tfm.co.jp/manyuki/index.php?catid=3350


イマラジ

21:00
FM京都
radiko
Imaginary Line
ttp://fm-kyoto.jp/blog/imaginary_line/


南海放送(愛媛県):痛快!杉作J太郎のどっきりナイト
月火水木金土日
21:00、19:00
南海放送
radiko
杉作J太郎
ttps://www.rnb.co.jp/radio/j-taro7/


ニューヨークニューラジオ?

22:00
Youtube


ttps://www.youtube.com/playlist?list=PLDCx5WcWNkqpmyT4EGdKe4xTZxiB9m_oU


高橋みなみ朝井リョウ ヨブンのこと?

22:30
ニッポン放送
93

ttp://www.allnightnippon.com/yobunnokoto/


ラジオ深夜便
月火水木金土日
23:05
NHK第一
AM)594

ttps://www4.nhk.or.jp/shinyabin/


オールナイトニッポン
月火水木金土日
25:00
ニッポン放送
93
パーソナリティ(月:菅田将暉、火:星野源、水:乃木坂46、木:岡村隆史、金:三四郎、土:オードリー大倉くんと高橋くん、日:WANIMA(月1回))
ttp://www.allnightnippon.com/


JUNK
月火水木金土日
25:00
TBSラジオ
90.5
パーソナリティ(月:伊集院光、火:爆笑問題、水:山里亮太、木:おぎやはぎ、金:バナナマン、土:エレ片
ttps://www.tbsradio.jp/tag/%EF%BD%8A%EF%BD%95%EF%BD%8E%EF%BD%8B/


思春期が終わりません!

25:30
超!A&G+
ネット配信
ttps://ch.nicovideo.jp/shisyunki
ttp://www.agqr.jp/topics/archives/ag482530.php


村瀬くんと八代くん

26:30
超!A&G+
ネット配信
村瀬歩八代
ttps://agonp.jp/programs/view/12

2019-03-21

ネットでなんでも言うこと聞く女を作った

SNS他人イケメン画像に釣られて連絡してきた女なんだが、当然俺はブサメンw

その女にモーニングコールさせたり

ゲームプレイ手伝わせたり

欲しいチケットの予約とか並ばないと買えないもの買わせたり

ホワイトデープレゼント送らせたり会ってできること以外のこと全部やらせてる

当然、エロイプもつき合わせてる

会いたがるがそもそも相手地方住みだし、会いに来ると言っても暇じゃねーんだよで切り捨てるw

かなり生活楽になったわ

イケメンならこれを会って何かやるまで拡大してできるんだもんな

本当羨ましいわ

2018-12-10

職場からモーニングコールがかかってくるアットホーム会社って

世の中にはどのくらいあるのだろう。

弊社の場合寝坊助な社員の為に私が始業二十分前に電話をかける事になっている。

その寝坊助な社員は以前、職場モーニングコール全然出なかった事があって、そのとき社長がわざわざその人を家まで迎えに行き、部屋まで突撃したという。

一人暮らしならわかるが、実家暮らしなのである実家の、個人の部屋に社長が起こしに現れるってすごくない?

2018-12-09

anond:20181208203002

私は弊社の寝坊助若手社員モーニングコールをする役を割り当てられた者だけど、電話したら寝坊助若手社員ちゃんと起きてた時はつい、「わー、今日ちゃんと起きてたんだね!えらい!」って言いそうになるんだけど、それだけは言ったらまずいんじゃないかと思ってこらえている。

2018-12-07

080で始まる電話番号

って、契約したのがずっと昔とかそういう事だと思ってたけど違う?

弊社に猛烈に寝坊助な社員(20代前半)がいて、先日そいつモーニングコールする役を上司から仰せつかったんだけど、教えて貰った番号が080からだった。

080って最近あんまり見ないよなぁ。この子小学生の頃から携帯持ってたんかなぁ、と思いながらモーニングコールしたらガチャ切りされた。

会社から電話即切りするとかすごい度胸だね!おらびっくり!

というか一寝坊社員モーニングコールしてくれる弊社って、アットホーム過ぎないかしらん。

求人には「アットホーム職場です!」って書いてあったけど。

2018-07-30

もっとのろけてくれよ

彼氏のここが嫌~ここが無理~

という話を女友達とよくする。

私はそこまで彼氏に不満はなくて、あっても最近モーニングコールを所望しやがったくせに電話かけても寝こけてたとか

一歩間違えれば惚気にしかならない内容なんだけど。

まりそういう愚痴大会に入るとあんまり語るネタもないからひたすら聞き役になってしまう。つまらん。

大体惚気るのがなんかダメ空気になるのが意味からないんだよ。

不満はあって当たり前、無いよ~なんつったら「今が一番楽しい時期だからね」「いい子ちゃんぶらなくていいよ」

はあ?その「今が一番楽しい時期」とかいう謎の上から目線やめーや。

それで何とか不満ひねり出して言ってもどーせ「それただのノロけじゃん」とか言い出すんだろ。

そうだよ惚気だよ。好きな人悪口言いたくないからな!

そんで友達から聞く彼氏の話でしか私はその人のことを判断できないので、愚痴ばっかり聞かされるとなんでそんな奴と付き合ってるの?

っていう無意味な怒りしかわいてこない。

先輩風吹かすくらい長く付き合っているんならそれなりにいいところあるんだろうからそういう話すればいいじゃん。

ないなら別れろ。そして私に幸せな話をさせろ。

2018-07-05

モーニングコール

キャバで、君はかわいいなあ声も凛としていいねモーニングコールで起こしてもらいたいなあ、なんてこぼしたら、部下キャバ嬢ともにモーニングコールってなんですかって言われた。ものを知らないのかと思ったが、その後若い世代20人くらいに聞いてみたら、知らないのが7割くらいで残りは聞いたことはあるが昭和遺産、名残り、スマホを使えない老人向けサービスと言われショックが大きかった。モーニングコールロマンは失われてしまったのだろうか……

2017-10-27

ふと昔モーニングコールをくれてたことを懐かしく思い出したが

あれって冷静に考えると俺に女がいないかチェックしてたんだな

そういう仕掛けをしてくるとこがある女だった

2017-09-28

anond:20170928031116

逆にお聞きするが

今の私生活に不満が無い状態にしてから(政治を)語らないとねと元増田は念を押される訳だが

そのような私生活に不満が無い状態でなされるあるいは語られる政治を想定(!)することは果たして

散々現況で行われているそれなりに問題そして疑獄そして汚職と腐敗そのなかで逮捕逃れすら権力安倍利用をする云わば

しみったれたどこかのだれかさんのグループの行っているようななんちゃって貴族制とたいして違いが無いように思われて仕方ありません

これはモーニングコールではありません

議員宿舎エッチなことばかりしている議員たちへのそして分譲戸建て住宅ニッチなことばかりしている公務員たちへの脅迫であります

2017-09-27

anond:20170927195726

分かったよそこまで言うなら朝のモーニングコールやめてやるよ静かな増田見せてやんよ

2017-09-21

anond:20170921064448

90分眠れるじゃん

運が良ければ同僚のモーニングコールもらえるじゃん

2017-08-01

女子高、女子大の女が苦手

性格わがまますぎ

女子高、女子大出身者の多くは学内で男と出会わないので異性の知識マンガであったり恋愛ドラマ映画に影響されることが多いと思う。

概ねそういったもの女性ターゲットとしているので世の中のオスは自分が多少わがままを言っても許されると勘違いして恋愛観がひん曲がる。私のことを大好きな彼氏なら毎朝モーニングコールもしてくれるだろう。私のことを大好きな彼氏なら毎日送り迎えしてくれるだろう。私のことを大好きな彼氏なら毎日連絡をくれるだろう。そういった理想妄想けが膨らんで、彼氏旦那に対する期待度が高くなって実際に付き合ったときに期待をぶちまけて彼氏はその期待に応えられなくて離れていく。

また、女子中や女子高は私立学校が多いので優しい親が可愛い娘を甘やかしすぎて性格わがままになってしまうのもあるだろう。

僕の知っている女子から女子大まで過ごした女はもれなくわがままであった。自分が何を言っても周りが世話をしてくれると勘違いしていた。例えばマック食事をしても手を伸ばせば届く範囲にある紙ナプキンをとってくれないと勝手に不機嫌になる。彼氏とは毎日深夜まで電話する。彼氏社会人なのにそんな時間あるのか?本当に働いてるのか?と疑うくらいだ。内容は無いらしい。その女が話したければ一方的言葉を発する。感情ラリアットだ。無言の時間が平気で何時間も過ぎる。

別の例を出すと、その女の同級生女は去年僕の知り合いと結婚したのだが、みんながあの女だけはやめとけと言ったのを「これが最後のチャンスなんだ」と言って結婚した。最近は風の噂で離婚したがっているのを聞いた。どうやら束縛が激しいらしい。社会人なのに門限が21時。たとえ男だけの飲み会でも禁止家事は全て旦那にやって欲しい。LINEの女の連絡先は全部削除しろ。妹の連絡先も消せ。僕が知っている限りでもこんなにある。これは離婚時間問題だと思う。仕事などで門限に遅れた場合は連絡の有無にかかわらず問答無用で締め出される。家の鍵さえ持たせてもらえないので車中泊はザラであることも知っている。「私の大好きな旦那なら仕事なんて早く終わらせて構って欲しい。それができない罰だ」という奥さん側の意見らしいが、いくらなんでも自己中心的わがまますぎる主張で酷いと思う。

・手当たり次第に色目を使ってくる

これは女子高、女子大からいきなり男と共存していく環境に移ったときに起こる現象である。それまで全くチヤホヤされない環境生活していたので環境が変わった瞬間からチヤホヤされ始め、「私って実はモテるんじゃね?」「男ってちょろいんじゃね?」という残念な勘違いを起こす。そして初めてモテるという感覚に味をしめる。さらに男もバカなので女子高、女子大と聞いただけでお嬢様だの処女だの言っておだてる。男の僕から見ても正直エロゲのしすぎなんじゃないかと思う。そういった行動は同性の女からも嫌われる。実際、僕の大学にいた女子出身の女は入学してから手当たり次第に色目を使って10人以上から告白されて全員フッていた。告白されて自分ステータスを上げて他の女をマウンティングしているようだった。僕にもアプローチをしてきたっことがあったが、僕はそれとなく断ったので被害を免れた。フラれた哀れなオス共はどうなったかと言うと、あんな安くて軽い女にすぐ乗せられるアホ男として女子からの冷めた目線を受けるハメになった。こういう人種は身近にいるし、最近言葉で呼ぶならば「サークルクラッシャー」が適当である

女子高、女子大出身の女はTHE・女のネチネチした性格か、そういったネチネチした世界に嫌気がしてサバサバした性格になるかの二極化が発生する。概ねサバサバした性格の女は学生時代に同性からモテ告白されたりキスされたりの経験がある。

こういった経験から女子高、女子大の女は警戒が必要であると僕は学んでいる。ちょっと話しただけで、女子高、女子大出身だと分かるときもある。もちろん女子高、女子大出身の女が全員こういう女だけではないことは分かっている。

以上、女子出身の姉がいる弟から見た「女子高、女子大出身の女」でした。

2017-07-07

知り合いが不倫しているんだが

自分アラサー♀、知り合いアラサー♀(以降、A)

Aとは会社の同期。

Aの不倫相手スポーツジムで知り合ったという30半ばの会社員。(前彼は出会い系サイトで知り合ってるから、本当かは知らん)

不倫相手の嫁とはデキ婚小学生の子供もいる。

自分不倫理解できないため、当初はやめなよと忠告してたが、Aは一向に聞かない。奥さんが冷たいから仕方ないんだ、とかいって聞かず、何度はなしても伝わらないため、自分も諦めて不倫否定するようなことは言わなくなった。

Aは不倫相手職場に押しかけたり、朝早くにモーニングコールかけたり(不倫相手は嫁のいる家で寝ている)、不倫相手が嫌気をさして相手にされなかった時期にピンポンダッシュしたり、かなりアホ。

不倫相手不倫相手で、Aの親に挨拶に言ったと思いきや(さすがにその時点で不倫とは言ってないが)、職場や嫁にばれそうになったとたん別れを切り出して一方的に縁を切ろうとしている。

ただ、Aは彼女自身曰わく、大学時代アメリカ留学して自己主張ははっきりすべきとの信念から自分が納得行かないととことん詰め寄るタイプ

なんだかんだで、連絡とりあって会ったりしてるらしい。

4月から異動して、Aと同じビルになったんだが、毎週ランチ誘ってきたり、帰り道(同じ社宅で会社~社宅は1時間以上の道のり)私の姿を見つけると捕まえてひたすら不倫相手のことを愚痴ってくる。

会っても不倫相手は余計なことするだの、もう別れるだの言われる(だが、A曰わく不倫相手自分の家に居場所がなく、結局あっちから連絡も来たりするらしい)、ひどいよねーの愚痴

知らんわ、アホ。一生やってろ、と思ってしまう。

Aとは、アラサーながらに自分のことを名前で呼んだり、「だってだってだってー」とかいえる神経からして合わないと思っているんだが(少なから自分の態度や言動にも出ている)、構わず近寄ってくる。

最近は頻繁な接触に、コンタクトがあるだけでストレス

無駄なとこにエネルギー使うの嫌なのに。

ただでさえ異動してストレスなのに、アホな不倫話とかどうでもいい。

不倫、マジ理解できない。

2017-02-16

http://anond.hatelabo.jp/20170215202351

私も夢の中で目覚まし時計の音を(音楽,BGMとして)聴いたり夢の中で朝の支度をしたり夢の中で授業を受けたりする人間です。

ベッド横のテーブルに置いてある目覚まし時計の音は全く聞こえない(目覚ましとしてではなく、夢の中の音楽としても)けど、枕元のスマホで設定したアラームの音は辛うじて聞こえるし、(よく失敗するけど)目を覚ませる人間です。

そんな私が起きられる方法、起きられない方法メモ代わりに置いておきます

参考にもならないと思いますが…

1.目覚まし時計(ピピピ…という電子音

ダメです。全く聞こえません。聞こえなさすぎてこれを聞いた家族が声を掛けに来るという使われ方をしています

ベッド横のテーブルに置いてあるため、距離が悪いのかもしれません。枕元に置いたらどうかな。

2.枕元のスマホアラーム睡眠サイクルに合わせて起こしてくれるやつ、好きな音楽

辛うじて目は覚める。起きられるかどうかは別。

音楽を変えられるのが良い。音に慣れてくると起きられなくなりますからね。

3.カーテンを開けっ放しにする

朝日で起きようなんて甘い考えをした私が悪かった。

このレベルになると光で起きようなんて戯言ですね。

4.照明付き目覚まし時計(鳥のさえずりで起こしてくれる)

こいつは我が家電気をいたずらに消費しているだけなのでは…?と思います

寝過ごして目が覚めるとこいつが誰にも気づかれることなく優しく(と言ってもLEDの白ーい眩しいライト)光っているので虚しくなります

起きれる人向けのインテリアだったんや。

5.家族に起こしてもらう

100%二度寝します。家族への申し訳なさが募り、家族辟易、良いこと無し。

6.友人にモーニングコールを頼む

学生のうちしか使えないだろうなと思いますし、学生でも休み間中などは使えませんが、家族が声を掛けに来るよりずっと起きれます

家族以外に迷惑かけたくない、そもそも家族以外と会話するのが億劫だ、という性格からかな。

モーニングコールサービス等で代替可能だと思います。私みたいな性格の人におすすめ

今思い出せるのはこのくらいかな。

かい方法があれば教えてください。睡眠外来とか行ったほうがいいのかな。

あと、今は設定した時間振動する枕が気になっております

http://anond.hatelabo.jp/20170215202351

帰宅→即寝る→起きる→出勤時間まで時間をつぶす

でどうよ

あとは有料モーニングコールサービスとか?

2016-11-25

モーニングコール強要

いや、しょーもない話なんだけど、

60手前の部長から

「朝起きるの苦手だから電話でお越してくれ」

と頼まれて困っている。

「いやー、私も朝が苦手でして…はは、」

ごまかしているが、何より、こんなリスクだけあることを引き受けたくはない。

知ってか、知らずしてか、部長は、

『朝が苦手なら、早起きしてワタシも起こしてくれればいいじゃない?』

笑顔で突っこんでくる。

増田部長、何時起きですか?私、その時間帯はもう電車に乗っているから無理ですよ、はは」

『いや、別にしゃべらなくってもいいんだ。ただ、電話をかけてくれればいいんだ。難しくないだろ?』

「これって業務命令ですか?」

『いや、これは君が好意的に行ってくれる慈善行動だよ』

「は、はぁ、でもかけなかったからって、責任もてませんよ?」

『当たり前だろー。お前、どれだけワタシをひどく見ているんだ(笑)

「そ、そーっすよねー、たはは。」

----------

というのが、昨日の話で、さっそくモーニングコールを忘れたところ、

昼前に、頭がぼっさぼさのままで部長が出社してきた。

2016-09-03

Zくんがもし女だったらはてなーもっと同情したんだろうな

BuzzFeed記事を読んだ。

LINEでのアウティング正当化しないが、それでもZくんには大変同情した。

振った相手から、前と変わらずモーニングコールを頼まれたり食事に誘われたりボディタッチされたらストレスだと思う。でもはてなーがZくんに厳しくて驚いた。

もしZくんが女性だったら、Aくんの距離の取り方がおかしいし恐怖を感じて当然って意見が大半だったと思うよ。

2016-06-19

うわー

から街宣車走ってるよ。

いくら8時半といっても、清々しい麻に街宣車モーニングコールはないでしょ。勘弁してよ。

空気読めない時点で、お前ら日本人じゃねーよ。

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

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

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

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