#1 初回なのでヌルヌルやったけどいい感じだった回

ポッドキャストの開始

こんばんは。

えっと、Replay.fmです。第1回ですね、第1回。

めちゃくちゃヌルッと始めちゃった。

やり直す?

いや、いいよ、もう多分何回やり直してもね、変わんないから、このままいかせていただきたいってことです。

まああれですね、初回なんで何をするFMというか、まあFMなのかって感じなんですけど、

きっかけは僕が、とある日にツイートしたことではあるんですけど、

結構なんかセキュリティ系の仕事になって、1,2年ぐらい経って、いろんな情報をキャッチアップするようになって、

思ったこととしては、情報量がめちゃくちゃ多くて、結構なんか記事の紹介が、フィードとか読んでも追いつかねえなみたいなことを思っていて、

なんで毎週読むとかしても、1週間サボると一瞬で溜まっちゃったりとか、

またなんか読む、これは読む価値ある、読む価値ない記事があるわけじゃないですけど、なんか相対的にこれ読んでおきたいよねみたいな、

なんかそういう色分けみたいなのもあるよねっていうところを、なんか誰かとワイワイしながら、

この記事で、これが面白いよねとか、まあそういうのができたらいいなーっていうのをふんわり思ってて、

そこにまんまと釣られたヤギハシ君が来てくれたので、

まあまずは2人でというか、ゆるっと始められればなという気持ちでございます。

記事の読み上げのルール

何かコメントありますか。

ヤギハシです。

コメントか、なんか僕もちょっとインプットが最近足りてないなっていう風に思ってたところだったので、

渡りの船っていうことでやろうよっていうので、

ちょっとさせてもらってます。

ちょっとね、個人的にはね、キャリアとスキル的には僕からギブできるものがね、あるのかっていうところが怪しいんで、

まあワイワイがかりとして。

もはや本業でセキュリティーやってないから、どっちかっていうとそうかっていうか、強いんじゃないかな。

強いかなー、いいな。

ワンチャンあるよ。

まあ、頑張ります。

頑張らないけど、頑張らないけど、まあまあ精進しますって感じですね。

で、これなんか記事読んでいく中で、いちいち音読とかさすがにできないんで、

どの記事を読んだとかは、その記事のリンクとかは後でまとめてNotionでパブリックページで巻こうかなと思ってるんで、

まあ気になる人は見てくれればいいし、

まあなんかそもそも視聴者いんのっていう話はありますけど、

まあまあ気にせずやっていこうかなっていう感じですね。

誰も聞いてない精神でやらないと精神持たないからね。

別に自己承認欲求を満たしたいわけではないので。

これは話しながら読んでいく感じなんですかね。

そうだね、やり方というか簡単なルールとしては、

あらかじめこのフィード読みたいねっていうのは当たりをつけてあって、

そのフィードで前回の収録から追加された記事をバーッと並べて、

そのうちセキュリティに関連したり、

事前に時間があって目を通せる場合は読みたいよねみたいなタグをつけといて、

上から順番に時間が許す限り読んでいけばいいという感じかな。

内容はその場で頑張って読む感じかな。

なんか読むのに1時間かかるような記事があったらちょっと、

まあそれは次回までの宿題とかにするか、

その辺の運用もちょっとおいおい考えようか。

なんか今ちょっと思ってるのは、このNotionで記事を今一覧化してるけど、

Weekでグループにすると、これ月曜始まりになってるよね。

これは月曜始まりになってるね。

今撮ってるのが木曜だから、なんかうーんってなっちゃうね。

一番いいのが。

これでも今Weekがあれか、

グループ化する時に使ってるのがそもそも追加した日付だから、

技術的な話題の共有

そんなにバグらないのか。

そうだね、これ手動で変えられちゃうから、

なんかこれWeekじゃなくて、

なんか収録日みたいにしちゃえばいいんじゃないかな。

収録日。

まあでも別にCreatedでいいんじゃない?

Createdは、まあCreatedでもいいか。

でもCreatedだと明日追加し…

本当は、

本当は月曜に全集文を読めるといいんだ。

ああ、そうだね。

だから収録日の方をなんか調節した方が本当はいいのかもしれない。

けど、まあいっか。

まあちょっと後で、月曜はね、

私、固定でパーソナルジムに行ってるから、

通うかな。

だいたい毎回なんか休日も被るしね。

そうだね。

通うあたりでいいかもね。

確かにね。

まあおいおい調整しつつ。

まあ事前に読みたいものを付けてるやつがあるんで、

まあ一番上からちょっとつらつら読んでいきますかね。

これ俺が追加したのかな?

覚えてないけど、

なんなら別の場所でシェアしてくれて、

一応目は通してる案件であるんですけど、

これ、個人の記事かな?

個人の記事か。

記事っぽいけどね。

J…

ああ、そうだね。

読んだ?これ、読んだよね?

読みました。

ああ、なんか僕の理解だと。

いやでもちょっと、

この記事を要約し直そうってなると、

やっぱ自分の理解が試されるかもなって、

口が止まるな。

まあ結構何を、

まあ割と人々を安直にHTTPからHTTPにリダイレクトしてるような話と、

まあ今はHSTSとかがあって、

なんならHSTSのプリロードとかもあるから、

まあ通常のウェブブラウザーとかで見てみれば、

それで結構通信の大部分、

現実に保護できてあるけれども、

これがAPI、

必ずしもそれがベストなプラクティスではないと、

書いてくれる感じですかね。

で、なぜかという話がまあつらつら書いてあるんだけど、

なんだっけな。

あれだね。

読んでから記憶が新しいうちに、

この収録やらないとダメだね。

確かに。

まあでも読み直すいい機会ということで。

えっと、

クライアントのアプリケーションによっては、

なんだっけ、

HSTSとかをそもそもサポートしてないっていうのがあったりするね、

っていう話を書いたりとか、

あとはなんか、

つまりリダイレクトは大体のケースにサポートしてるよね、

書いてくれてたような気がするんだけど、

えっと、

every single one of our business 絶対のケースは。

ビルトインのフェッチは、

えっと、

リダイレクトは普通にやってくれるよう、

従ってくれるよう。

まあでもここは結局クライアント側の実装は、

サーバー側ではコントロールできないから、

どの言語の何のライブラリ使ってるかとか、

思うと、

何でアクセスされても、

安全なように作っていく感じでは。

全くなんか担保できてない。

要は仮に毎回httpからhttpsにリダイレクトしてたとすると、

えっと、

仮にそのシングルな、

シングルのその1回の単発のリクエストで、

APIのコールが完結する場合だったら、

100回APIコールすると、

毎回リダイレクト挟むので、

実際には200位取りして、

かつ、

そのうち半分が平文、

httpという話。

その辺の回数の話とか書いてないけど、

何を書いてるかっていうとそういう話。

そうだね。

理解理解理解。

で、

それに対して、

API側でやれることがあるんじゃないの?

って言ってくれてる。

リダイレクトさせる。

フェイルファーストの原則で、

そもそもhttpでコールされたら、

リクエスト次第は失敗させるっていうのが、

要は、

なんていうか、

httpのURLでハードコードされてる場合とかには、

そういう形にしてあげることで、

開発者が早く気づいて、

書いてくれてたりとか、

あるいは、

これ誰かからのコメントなんか、

コメントっていうか、

誰かからの指摘を引用して、

追記してくれてるんだと思うけど、

そもそもhttpで通信に乗っかった、

APIのシークレット、

アクセストークンとかは、

その場でリボークするべきなんじゃないか、

インバリデートするべき指摘を、

追記で乗せていって、

確かに感じ、

要はヒラブンで流れた以上は、

それはもう露出したもの、

漏えいしたものとして扱うべき、

漏えいしたのであればそれは、

サービス運営者としては、

それを把握した時点でするべきだよね、

っていうような話かな。

確かに確かに。

ここに書いてあるね、

Hacker News UZEPT。

確かに、

これ、

自分が実装者だった時に、

確かにこれやってくれないと、

タイポでhttpずっと叩いてても動いちゃってたら、

多分直すタイミングないから、

確かにだね。

あとこれ1回、

もう既に今、

なんか有名どころのAPIで、

リダイレクトしてる、

リダイレクトしてないやつと、

してるやつと並べてるの。

ちょっとその辺はね、

もう別に、

ただの実例並べてるだけだから、

個人的にあんまり興味がなくて、

そっから読んでないんだけど。

これもう既にさ、

リダイレクト実装してるAPIが、

確かにと思って直そうと思ったら、

結構悩ましいよね。

めっちゃ大変だけど、

段階的にやるしかないから。

もうリダイレクトしてたものを、

やめますってなると、

それまでにリダイレクトしてた、

ケースを洗い出せるんだったら、

洗い出してもいい。

アクセスログでは、

300万台の、

httpレスポンスが返ってるのは、

残ってる可能性があるから、

そういうとこから頑張って拾って、

個人的には、

もう一回全部、

リボークするしかないんじゃないっていう気は。

愚直に、

この日に、

仕様変えるぞって言って、

メール送ったり、

GUIの画面にアナウンスを表示したり、

頑張らなきゃいけない。

結局、

仕様、

まあね、確かに、

振る舞い自体を変えることによって、

いろんなものが壊れるっていうのもあるけど、

それまで使われてたシークレットが、

全部、

使えなくなるっていう影響も、

多分、

でかくて、

非常に悩ましい。

なるほどね。

愚直に、

もう何とかするしかない。

一応、不特定多数のクライアントが、

アクセスするっていう前提があるので、

別に、

自社で作る。

これをそこまで気にしなきゃいけないような、

規模のサービスを運用してる人は、

そんなに多くは、

いないわけじゃないから、

そんなに多くはない気はするな。

でもなんか、

言われてみればそうなんだけど、

これをその、

素の状態から自分で、

考えて、

そこにたどり着けるかっていう。

面白い記事でした。

これちなみにどっから流れてきた?

誰かの、

誰かがツイート。

フィードに頼らずとも、

タイムラインに勝手に流れてくるの。

みんなありがとう。

この辺は多分、

もともとセキュリティタイム、

タイムラインにいた、

利点が、

出てる部分。

逆にだから、

開発畑の方、

全然流れてこない。

じゃあその辺で、

面白記事があったら、

俺が頑張ってキャッチするわ。

確かにあるだろうな。

次。

これね、薄々記事出てくるよね。

いや、あんまりにすごい数ないな。

読めなかったよね。

シンクドで、

フィッシング攻撃の増加

次は、

これ何て読むんだろう?

ZDNetじゃないの?

ZDNetの、

日本はフィッシング攻撃の標的として、

世界第3位。

Zscaler調査。

Zscalerって誰?

気になるランキング上位になりましたけど、

Zscalerは、

サイバーセキュリティ系の会社ですかね。

日本の会社か。

フィッシングレポート発表しました。

それによると、

2023年のフィッシング攻撃が

前年比で60%増加し、

日本への攻撃も

全員700万件を超えました。

日本はアジア太平洋地域で、

インド、オーストラリアに次ぐ

標的国となります。

インド、オーストラリア、

アジア太平洋域で

3位ってこと?

世界で3位。

だよね。

フィッシング攻撃増加の主要要因は、

生成薬用による音声フィッシングや

ディープフェイクフィッシングの増加要因だと

言いますよと。

日本ではサービス業34%、

ツイーディ製造業が最も攻撃を受けたと。

最も模倣されるブランドは

マイクロソフトで

フィッシング攻撃の

43.1%を占める。

この調査は、

この会社が

2023年の

1年間でブロックした

2兆億件の

マイクロソフトの影響

トラフィックトランザクションを

分析したものですよと。

あれ、でも本当に

フィッシングなのかな?

そうだね。

いわゆるフィッシングっていうよりは

フィッシングはフィッシング。

どっちかっていうと

不特定多数のユーザーを

企業ユーザーとかを

引っ掛けに

起こしてるのが

マイクロソフト。

それが一番多いってこと。

そうだね。

この企業自体が

多分企業向けのサービス

提供してそうだし。

なんかそんな感じっすよ。

なんか普通に

コンシューマー向けの

そのサービスを

提供してる

側の身としては

ちょっと

肌感とズレがあるという。

そうだよね。

こういうのと比べたら

実はそういうのは

2Cのサービス

ビビタルものなの。

このグラフの

すごい細かーい色が

分かれてる

細いところに

入るだけなのかもしれないけど

そこは分かんないけれども。

でもフィッシングの標的となった

業界って出してるぐらいだから

どっちかというと

エンタープライズ向けの

なんか

レポートなのかな

きっと。

フィッシング

マイクロソフトアカウント

社内のアカウントがあるような

会社に

何かで理由つけて

ログインせいって言って。

なんかあんま分かってないのが

そのパブリック

大手って言い方あれだけど

マイクロソフトとか

Googleとか

あの辺の

フィッシング

あんまり話聞いたことないけど

実際は

あんのかどうかとか

知らなかったけど

これ見ると普通に

攻撃手法とその対策

あるって感じじゃん。

マイクロソフト、OneDrive

Okta、Adobe

Adobe

Googleは1.3%とかだから

多分なんか

これも

イメージしてる

IDとかパスワードを

抜いて

できに行くような

オース的な

あれを使った

フィッシング

の方なんじゃないかな

イメージに関して

Twitterの

Twitterでたまに

誰かが踏んでる

卒業権限抜いてくるやつ

和訳記事だと

同意フィッシング攻撃

って今チャットで話す

あー

なるほどね

へー

普段Googleが

あんまり標的

Googleがあんまりなんか

使われてないのは

でもなんかその

私たちの業界が

なんかMacOSばっか

って言うだけで

大体の会社は

Windows端末を使ってるから

そういう意味では

多いんじゃないかな

まあでも

エンプラ向け

エンプラのレポートだとしても

結構興味深い

これ記事のタイトルは

ちょっと良くないな

世界第3位ではないね

アジア第3位だね

一瞬下げて

あ、いいんですか

そうだね

まあいいや

足元は

はい

と

じゃあ次

あ

響き

これ

弊社内でもなんか

めっちゃ

みんな

騒いでたな

これは読んでないな

全然

読んでないな

読んでないけど

まあとりあえずなんか

別に

焦る必要はないという

結論に至っただけぐらい

普通にサイドチャンネル攻撃で

物理的に

指キーを奪えさえすれば

あ、タイトル読み忘れた

指キー

指キーサーバーの用語

to clone in attacks

thanks to a newly

discovered side channelで

最初はあの攻撃の

対策脆弱性があって

普通に盗めば

条件が揃えば

10分ぐらいで

秘密カギを

復元

コピーできる

っていう話だったんだけど

盗まなきゃいけないのと

あとなんか

何に金がかかるのか

分かってないけど

1万1000ドルぐらい

かかるみたいなのは

それは

1件あたりなのかな

それとも

それがあれば

いくらでも

これかな

attacks

recover to

なるほどね

それだけの

機器があれば

っていう感じだから

それ自体は別に

あれば

あればいくらでも

っていう感じだから

これなんか

中のライブラリーが

って話だったよね

ライブラリーなのかな

ライブラリーなのか

そこの辺は

全然

分かってない

特定のマイクロコントローラーと

暗号

ライブラリー

が

なんか

脆弱性を

抱えていて

っていう風に

書いてあるのかな

冒頭部分に

implementer ecdsa

insider dcd

今では

several sub

is modular

in this

のバージョン

いやーこの辺がな

こういうなんか

暗号周りは

マジで

二字も分からんな

そんなあなたに

おすすめの本が

もしかして

暗号と認証の

仕組み取り替えが

分かる本ですか

違った

じゃあ読みます

見えない

現代暗号

せっかくだから

ローションにリンクを

貼っとこう

これ

どうなんですか

なんか

その世界で

生きる人にとって

どう見えてるんですか

なんか僕は正直

あの

考え方としては

自分の会社に

影響あるかなと思った時に

まあ呼び聞きそもそも

なんか必須にしてない

っていうのはあるけど

一部

なんだろうな

特権アカウント持つ

人とかだけ

導入しましょうか

って話をしたこと

とかはあって

で

まあそれに対して

これがあるから

何か追加できることが

あるかと言われると

なんか盗まれちゃいけない

っていうのは

別に変わんないし

Cっていうのは

オフィスで

差しっぱで放置するのよ

みたいな

でもそれってもともと

そうだしなんだ

どうだろうみたいな

まあでも気づかれにくくは

なるんじゃない

知らぬ間に

相影作られてました

なんか

物理的になくなってたら

結構

まあ

使用頻度によって

全然気づかないまま

ずっと時間が

経ってしまう

シナリオとして

全く無視できる

レベルかというと

そこまでではないかな

っていう

なるほどね

まあ確かに

今までは盗んで

気づかれるまでに

頑張るって話なんだけど

よく使ってればさ

その

まあ本当に

高頻度で使ってたら

そもそも

まあでも10分か

10分で

クローンされちゃうのだと

結構厳しいかもしれない

うん

まあでもそこに対しての

その

まあだからこそか

どんだけ高頻度で

使ってても

10分でクローンされる

っていうのは

結構厳しいかもしれない

うん

まあでもそこに対しての

その

高頻度で使ってても

10分でクローン

作られちゃうと

うん

なんか

まあ結構気づく問題は

まあ確かにあるはず

で

まあしかも

それをクリティカルなところに

使ってるんだったら

なおさら

うん

要は

1万1000ドルかけるだけの

価値があるケースって

実際にあるはずで

ああまあそうだね

確かに

だからかかるコストと

得られるリターンの

バランスで見た時に

まあ

ケースバイケースであるけれども

無視できないっていうケースは

絶対あるはず

この考え方大事やな

確かに

条件難しくてもね

これで2億手に入ります

だったら多分

やるもん

全然やるでしょ

とか言っちゃうと

語弊があるけど

全然やられる想定で

いないといけないよね

やる人いるよなとは思うんだよな

そもそもなっちゃう

うん

なるほどね

この機器って

どんな感じの機器なんだろう

でもなんか

わかんないけど

オフィスで配達予想って

ぬるっと入って

写真はあるけど

なんか結構いかつそうだな

結構ばらしてるね

なんか

うん

かついね

でもほんとにチップに

なんか

機器を当ててるような感じなんで

これを

うん

でもさ

ここまで想定してさ

そのコードを書かないといけない

あー

ハードウェア側とか

ハードウェア

その中で動いてるさ

あー

そういうことか

なんか

ハードウェアの

ハードウェア

セキュリティ周りの

ハードウェアは

作りたくないなって

結構

こういう記事を読んだら

なんか

うーん

我々はさ

その

まあ

おおむね

ウェブの世界で生きてる

その

ウェブ越しの

サイドチャネルって

成立はしてるわけだけど

うん

でもなんか結構

インターネット越しに

アクセスしてるから

レイテンシーのその

壁によって守られてるっていう

節は

混ざってあると思うので

確かに

監視もできるしね

なんか

やろうと思う

いやー

これを

これを書く側は

大変だよ

リフレッシュの必要性

まああとこれ

アップデート書けられないのも

きつい

ああそうね

っていうのも

なんか

前で考えた時が

こういう所に関わる

行動感

うん

すごいことだな

うん

まあでもなんか

前提としては

分かんないけど

まあいつかは何か

見つかっちゃうみたいな

気持ちで

やっぱリフレッシュしていくしかない

のかな

物理に

いやーでも

シャレにならないでしょ

笑

シャレにならんか

シャレにならない

シャレにならん

でしょ

まあいつか何か見つかっちゃう

っていうのは

それはそうなんだけど

なんか

見つけて発表してくれてるから

いいけど

ああ

見つかんないこともある

見つかんない可能性もあるし

うん

まあ確かに

あと乗り換えた先が

安全っていう保証も

誰もしてないもんね

うん

プレッシャーがすごいと思う

多層動機が大事って

話ですかね

もうこれだけに頼んなって

話かな

そうですね

これが一個

盗まれたら終わりだよ

っていう状況に

しちゃいけない

あるいは

これを一個盗むのが

すごく大変だよ

っていう状況に

しないといけないとか

情報セキュリティの脅威

まあいろいろあるかもしれないけど

うん

疑問がないですな

これは

でももうちょっと

きっとみんなの目にもよく

友記事でしょう

知らんけど

えーっと

あとは

なんかランサムっていう文字を

見て条件反射で

読むリストにいたけど

ちょっと面白いことか分かんない

えー

中小企業への

ランサムやりによる

脅迫件数が増加

with secure調査

ああ

これ系の記事さ

すごいいっぱいあるからさ

いつもなんか

その

うふふふふ

個人的に悩むんですけど

まあ数えきれないほど出てるよね

そうそう

なんか正直

どっか一社決めて

そこが出すレポートを

こう

なんか

半期ごとにとか

一年ごとにとかで

見るくらいで

個人的には

関心がそんなに高くないんだったら

それでいいんじゃないかなとは

あー

思わんでもないけど

なんかねー

身近であることを忘れないために

読みたいっていう謎の

ふふふふ

謎の気持ちで

結構読んじゃう

調査と対策

読ん

まだ読んでない

読んでない

質問あった

どういった

質問あった

どういった

视聴者

話し手 3

もう本当に

- 母b

媽

内部

話し手 5

Mongol

- 大

- 行

話し手 5

- あ

ああ

お気に参りです

pbs-air-parse-didn't-handleのスペシャリアルスキャン

why-didn't-align-with-collective-set

でも、今手元のノードで見てもオンラインにパースする

ああ、他の一般的な実はこうなってるよって話

ちょっと経緯をなんか丁寧に把握しきれてない

でもまあそういうことだろう

うんうん

ホストしかチェックしてない

うん

話があって

いやーこれ他人事じゃないよな

プラットフォームちゃんとチェックしてるやろって思ってても

生体認証技術の導入

大体やってないことってあるだろうから

うん

見つけてくるわ

ほい

えーっと

東武と日立、生態認証を活用のID基盤を全国展開

東武スターでの決済に手応え

これはちょっといろんな意味で個人的には気になる

トピックでございますね

理由は言いませんが

えーっと

GDDの記事ですと

東武鉄道と日立製作所は

9月3日

ん?

9月3日

4月

ああ

4月から提供している生態認証を活用したデジタルアイデンティティの共通プラットフォーム

コミュニティストア

カドリオンアンティショッピングモール

鉄道南東部グループ内外の様々な環境を支えていく

し全国の100カ所以上に順次提供すると発表しましたよと

デジタルアイデンティティとは

個人の証明書属性のID情報を電子化したもの

両者の取り組みでは各種ポイントアイデアやフレージとか情報など

プラットフォーム上に登録されている個人に関する情報を

総称してデジタルアイデンティティとする

うん

なるほど

で両者は4月東武製作さん店舗において

おお

指縄脈認証による決済機能をセルフレージに

順次搭載

来店客は

えー

人差し指中指薬指を

認証掃除にかざすだけで決済

東部グループ共通ポイント

東部ポイントの年齢確認を行う

すごーい

指縄脈の登録者数は8月時点で約3700人で

継続利用率は76.3%

若年層中心利用を想定していたけど実際には

へー

50代以上が搬送してみていると

決済時間は

ポイントアプリを提示してクレジットカードを取り出した場合の決済で

比較して約半分の25秒で完了できるよと

うん

ほー

なるほどねー

でこれ拡大目指してますよと

うんうんうん

うーん

ふふふ

どうすか

何の運ですか

えー

へっへっへ

どうなんの

大阪に

まあでも確かに

ファミリーマートとかでもやろうとしてるよ

リスマッシュとかはできない

よねー

指縄脈認証が

ってどうなんだろ

全く分かんないな文外観すぎる

まあでもスピードが重視される

改札の入室場では

顔認証の方が適してるって言ってるから

指縄脈はねちょっと時間かかる

ああそうなんだ

顔認証とかなんか

突破する技術ありそうだけど

まあでも

そこもまあいたしごっこというか

そんな簡単ではないのかな

顔なんかそんなん出てきない

マイナンバーカードは顔認証じゃない

ああてかiPhoneのあれとかって

要は平面で見てないじゃない

カメラ

Windows Hello対応のカメラとか

ああーなるほどね

平面で画像で見てない

顔のその形状を見て

生体認証してるから

そんな改札とかで

なんでもできますようが

指を切り取る

いややめよう

なんか小説

アニメで見たことある

まあまあでも理屈上は

成立すると思うけどそれでも

そうだよね

多分だけどね

生体認証のさ

生体データって

センシティブなものだと思っていて

はいはいはい

それこそ一生自分の意思が変えられないもの

いろんなところに

ばらまいてほうが

世の中がそれに追いついてるのか

っていうのはちょっと疑問だ

確かにね

あとは

いくら生体認証とはいえ

100%ではない

技術的にはあるから

決済システムの利便性

全てをそこに依存するっていうのが

正しいのかは

まあ現実的には

フォールバック先がある

あるというか必ず用意されてる気がするから

ほんと利便性

強度が上がるものなのかな

強度は上がるわけじゃないよな

いやっていうより

なんていうか

他人受け入れ率の話をしていて

なるほど

生体認証をしてるから本人ですっていうのが

実は違いましたっていうのが

あり得るわけで

これが3本

3本の条約全部使うような

書きっぷりだから

多分それで限りなく

他人受け入れ率できてるよっていう話なのかと

全くの他人が

自分になりすますっていう可能性が

これで完全に否定できるかっていう

ちょっと違うよねっていう

じゃあそれを使ってどこまで

できるのかっていう話になって

なんか医療とか

まで展開を考える

またさらにセンシティブなところが

現実問題

大丈夫だよねっていう風に言えるレベルでは

あるのかもしれないけど

その生体データ一要素で

そこまでさせちゃった

っていうのはあったかな

どっちがいいんだろうね

くれか持ち歩いて

まあでも

便利に座禅組んで

考えないとわかんないな

生体認証データ自体が

漏れても

使えるわけではないよね

漏れても使えるわけではない

けど

漏れても使えるわけではないけど

そのデータを使って

似たような形で

例えば条約をどこか

他のとこでも取ってたとして

その人が同一人物であることは

わかるとか

そういうそのイシューが発生するよね

どっちかっていうとなんか

プライバシーイシューのような話なんだと思うけど

なんか手放しに便利だね

って言っていいのかは

僕はよくわからない

おおむね便利だとは思うけれども

この辺って法整備どうなんだろうね

なんかあるのかな

追いついてます気もしなくなるけど

プライバシーと法整備

個人情報

困ったら

個人情報保護委員会Q&A

生体データFAQ

個人識別不合

2017年に全面

2017年の改正で

えっと

個人識別不合として個人情報に入ったらしい

個人と紐付けられなければ政府ではない

個人と紐付けられるかというと

その辺の定義をちゃんと使い分けられるほど

熟知できていないので

ちょっと言及は避けておく

難しいコメント

個人情報ではあると思う

写真があるわ

3本指こんな感じでやるみたい

今後に期待って感じかな

ファミマで使えるようになるなら

あんまりないんだよな

あほんと

どこで登録できるのかわからない

参田、全然わからない

埼玉県

埼玉まで行けばできるのか

登録プロセスとかも

フォーマンダム

セリをしたら、バレると思うけど

えーと

ボートが入ってるやつだけ読むとかでちょうどいいかもな

ちょでも真面目にボート入れないといけないなそれでいくと

いや気軽に行こう

flat securityさんのブログですね CTFで出題される脆弱性vsプロダクトセキュリティのリアルな課題

いいねワクワクしちゃうね

CTF好きな方が中にいてその人の記事ですねすごいな解説記事40本書くぐらいが強いですと

CTFとプロダクトセキュリティの課題の差は何があるでしょうか

本記事の目的は CTFの問題とプロダクトセキュリティの課題を比べてます

CTFだけやってる人とか逆にプロダクトセキュリティにしか触れてない人にとって

双方に視野が広がればいい感じのことが書いておりますね

CTFとは僕らは分かってるんで読み飛ばして

プロダクトセキュリティは年々重要性も増してて容器も大きくなってるよと

プロダクトセキュリティの中でも脆弱性診断がCTFに最も近い部分であり

多くの共通点があるよとただそれ以外にもクラウドインフラレベルのセキュリティ担保なり

DivSecOpsやSSDLCって何ですか

セキュアソフトウェアデベロップメントライフサイクル

セキュアこれはSecDevOpsと何が違うんだ

DivSecOpsか

だいたい一緒じゃない

あれによくあるタイプなんだな

多分SSDLCのほうが言葉としては古い

なるほどね

DivSecOpsとかDevOpsのほうが比較的最近出ます

DevOps自体の

PDCAの仲間みたいな感じだよ SSD

知らんけどめっちゃいけないんだけど

それぐらいで捉えておくのがちょうどいいな

パソコン防御アプローチなど脆弱性診断以外にもいろいろあるよって感じで

共通してる部分図が分かりやすい図がありますね

有名な脆弱性やアクセス制御不備古いライブのラジオっていうのが共通部分

これは秦さんとしてはどうなんですか

CTF僕多分人生でも10回も参加してないというか

多分4回ぐらい

そうするとプロダクトセキュリティのリアルな課題としてこの辺があるのか

アクセス制御不備は間違いなくあると思うな

古いライブの利用もリスクとして顕在化することはないと思う

ないというかないは言い過ぎなんですけど

意外…いや分かんないな

顕在化するわけじゃないけどでもあるある

なんか放置されてる古いライブラリーとか放置されてるミドルライブラリーっていうのもあるある

有名な脆弱性もまあ組織とかによってはあるあるなんじゃないかな

うちは会社の歴史が浅いんで割と大丈夫な方ではあるけど

それでもやっぱ

ちょっと誰かを傷つけたら申し訳ないけど

今どきSQLインジェクションなんて作りこまんやるっていうのが

ポロッとあったりとか

脆弱性の理解

あと歴史が古けば古いほどそういうのは全然あるんじゃないかな

15年前

意外とねなんかねあるよね

意外とある

なんかこの共通項に入ってる部分は肌感としてはあるし

プロジェクトの規模が大きくなればなるほど

ポロッと変なとこにあるな

そうだね

今どきみたいなのは

あとなんかねやっぱ

現実のプロダクトがそのシンプルであることがもう多分99%ないから

やっぱ複雑な仕様のしわ寄せが実装に来たりし

まあそうだね実装とか何かのアーキテクチャに来るときに

まあ本当はいけてないけどこういう実装しましょうみたいなところに

なんかヌルッと入ってきたりするこういう脆弱性

というかまあ何かありきたりな脆弱性とか

って感じがするな

いやーなんか具体で言いたいけど言えないんだよな

そうなんだよね

説明できないよねこれはね

架空の会社を建てて話したいと思うんですけど

まあまあまあいいや

設計職人とかは結構ある

あるあるだね本当にあるあるだと思う

割とその俺なんか言語的に

言語とかフレームワークの機能に頼ってれば

割と大丈夫っていうものが

比較的最近

比較的最近って完全におっさん丸出しなんだけど

また僕らが学生だった頃ぐらいから

多分そういう時代にはなってきていて

一方でビジネスロジックそのものが壊れてるとか

アクセス性が壊れてる

どうしても人間がやらかしてしまう部分

機械的に多分判断できない脆弱性だよね

仕様としては正しいけど穴で割るみたいな

なんかその穴は意図した穴ですかとか

その判断やっぱ機械にはできないから

Webサービスに対するのに絞って考えると

XSSやコマンドインジクション

まあでもねなんかコマンドインジクションとか

ディレクトリストバサードとかはね

さすがに実現まであんま見ないから

XSSとかSQLインジクションとか

まあCSRFはアーキテクチャー次第かな

なくはないのかな

CSRFもあんま見ない気すんな

フレームワークちゃんと使ってれば

なんかそのレールが外れなきゃいけない

要件っていうほどだから

そもそもバックエンドとそのフロントエンドが

割り取りしてるサービスが今どきあまり多い

あーそうだね

確かに確かに

プリフライトが通らないという

大変なんだな

確かに

一方でプロダクトにある良くある脆弱性にも

思い浮かべてます

アクセス制御の不美や古いライブラシが

これねなんか別に言えるでしょう

おかしいブログ書いたから

喋れるんですけど

ライブラリ管理の課題

なんか1年ぐらいかけて

超膨大な古いライブラリに対して出てる

セキュリティアラートをひたすら

毎朝取り味してたことがあるというか

取り味して終わったんです

終わって今ゼロの状態

ほぼゼロの状態でキープしてるんですけど

だから一個一個見てもね

やっぱ

プロダクトまで貫通するケースは

正直そんなにないなっていう感覚は

かといって無視できるものは全くないし

甘く見積もるものでもないんだけど

やっぱそこがなんか

まあそうね

古いライブラリ利用というか

セキュリティパッチの適応の難しさ

考えずに進むなら考えないように

いつかアドバイス先生からもらいました

先生からもらいましたけど

何も考えずに最新版をキープするっていうのが

いいよねっていう気持ちだわ

でも変なのが混ざってくると

大抵最新版だよね話が

そうね

そこはしょうがないな

そっかね

CTFで出題される問題でよくあるテーマは

最新の攻撃や脆弱性の出題とか

パズル問題

最新の攻撃書は脆弱性の出題は

話題になったものを出題したり

これはなんか昔から変わんないけどな

今だとLLMの脆弱性とか

フロンプトインジェクション

フロンプトインジェクションはでもなんか

いやー

つかないかな

想定外が正しく動くかどうか

ゲスの割合が

その想像で何とかしないといけない部分の割合が

高すぎるんじゃないかな

でもね意外と何個かね

いやほんと何個かですけど

実際のやつ何回も記事で読んだんだけど

あるんだ

なんかね面白かった

NRIセキュアの記事だった気がする

あのね

面白かったなんか賢いなって思って

いやーなんだっけちょっと後で探そう

あのね

裏側で実はこれにアクセスしてるっぽいっていうのを

突き止めて後は支持するだけみたいな

パターンとか

なんかSSRFと

あーそうだね

イメージ的にはそんな感じかも

あー面白いねそれ

あとまだまだというかもう

出たのだいぶ前でやろうやろうと思ってやってるんだけど

ポートスイガーでLLMの

なんか

トレーニングみたいなのがあって

それをやってみると解像度上がりそうとか

あーなるほどね

確かにその観点は

なかったな

LLMのねOWASPトップ10が

それ見るとね意外とね本質はWEBだなと思う

WEBと近いなと思ったり

モデルインディードスサプライチェーン

プラグイン経由で

とかね

ありますよ

おー書いてありますね

生成案に対するプロンテインニューション

対戦になる

ログフォーシェルみたいなのも

へへへへ

開発環境のセキュリティ

あとはそうだね実際サーティション

パズル問題

そうですねパズル問題は

まあパズルです文字通りパズル

この辺読んでると気づく

箱庭XA

っぽいねそんな感じ

いやーこれは楽しいよな

得意得意ではないとか

僕はCTF力が低いですけど

頭の運動か

あとよくわからん仕様を知れるっていうのは結構

そう

いつ役に立つのって思うけど

うーん

でもなんか

うーん

なんか柔軟に考えるっていう意味では

悪くないかなって

プロダクト責任でやってみるとしたら思ってて

うーん

発想を無理に狭めない

というか

これやっとけば大丈夫でしょみたいな

意外とあるよ

入力をめっちゃすごい

加工して最終的に

SK11の中に入ってて

ソルダーとかはなんか

使えない

テーブル名だから

これは大丈夫ですか

はいはいはい

そういう意味ではなんか

こういう問題とかは別に無駄じゃないと

面白いなって

大丈夫かなこれみたいなのなんか

考えないといけないっていうのは

あるかないかで言うとたまにある

まあよくあるかと言うと

うーん

新しい仕様とか結構その

複数組み合わせる時とかはね

そういう感覚持つこと多いかな

なんかその

一個一個はなんか大丈夫っぽいんだけど

なんか組み合わせると

ここ穴になるくねとか

ここでこういう意図しないこと

起きるんじゃないの

そういうところがちょっとパズル味を感じる気がする

ちょっと感覚でしゃべってるけど

なんかタグドテンプレート

ストリングスとか結構革命だったな

スクリプトの

タグドテンプレート

あーそうね

かっこなしで関数呼び出す

そうだねそうだね

いいのがあったりするから

開発者目線くそ便利なんだけどな

まあそう考えて作ってないからな

革命的

いいね、ならではの視点だね

あとなんかジョインはほぼ使わないとかね

うーん

ユニオンセレクトは使うけどジョインはほぼ使わないとか

あとは

プロダクトセキュリティ側の

やつは

CIAのさらなる担保

中間者攻撃

開発環境の堅牢化

中間者攻撃

そんなか

CIAのさらなる担保は

別にこれはもう

主軸だからさ

そりゃそうだよね

開発環境の堅牢化

中間者

後続であるね

CIAはまあまあまあ

フィッシングのこれを

中間者攻撃と呼称してるの

あーでCTUってあんま出題されないから

面白い観点として紹介したいってことか

あーのね

なるほど

まあまあそれなら開発環境の堅牢化

面白さを感じるところは

人それぞれ

他が有形のやつだからな

現場の声やね

いやー

だってさー

ある意味面白くって

技術的にはこうすれば可能だよね

っていうのがさ本当にさ

やってくるんだから面白いよな

なんか

これのしんどいな

人間狙ってきてるところが

本当にしんどいというか

気をつけてくださいは

何の対策もならないっていう前提に

立つと本当にできることは限られる

というか

フィッシングレジスタントの

対応する以外の方法が

今の話じゃなくて

やっと世の中が少しできた気がするけど

いったい何年かかったのか

あると思うし

これに疲弊してる人たちはやっぱり

いるから

まあ面白い技術者として

面白く感じるのはめっちゃ分かるけど

まあでも確かに中間者攻撃ではあるね

うん

開発環境の堅牢化

初めにこれを紹介

貼っといてくれ後で

それがそのリンクが貼られてるから

あーこれね

この攻撃に関するマイク

ちょっと後で読んどこうか

いやー開発環境のやつは

ちょっと面白いというか

いい観点だな個人は

そうだね

いやーそうなんだよな本当に

これ多分トピックとしては

本番掛けじゃない開発環境に

を狙われて

いろいろ入れる話かな

そうだね

そうですね

いやーこれなー

本当

油断するのはあれだろうな

あとなんか結局開発環境も同じ

本番と同じセキュリティレベルに

しとかないと多分

それって多分セキュリティに限らず当たり前の話で

動いてるミドルウェアとか

機能とか

仕組みっていうのが本番と同じ

である状態で

じゃないとそもそも

アプリケーションが意図した通りに

動くかどうかの保証ができないから

まあねー牛は安しなやつだけど

いやでも

そこはもうやんないと

いけないと思う

まあもちろんその開発環境のURLはパブリックに

できないから認証かけるとか

そういう開発環境特児の

やるべきことはあると思うけど

まあまあまあ

逆に本番にバイパスを

入れないといけないのもやっぱりあって

個人的にはそっちの

本番にバイパスを入れるっていうの

例えば

細かい話はできないけど

分かりました

特定条件下で

パスワードマネージャーの実装

いろんなものを多分見てるよ

同じ会社にいたわけだから

まあ

似たようなものは

例になるようなものは多分見てるはずだし

うん

ご想像にお任せしますが

まあどこの会社もあると思うし

なんとなく理解そんな感じですかね

まあ記事自体は結構重厚なんで

気になる人はいい記事ですね

CTFなあ

時間が無限になったらやりたいけどな

いや遅すぎることはないですよ

まあでも結構ね

なんか

もはや追いつくのが大変っていう

のと

逆に昔の

なんかいろんなものをもはや学ぶ

必要がないっていうのと

なんか両面があると思っていて

どうなんだろうな

やるとしても

なんか勉強のためにやるっていうイメージは正直

ないわ

うん楽しくやるのが

一番いいと思うけどね

参加するとね楽しいものでやる

っていうのはすごく純粋に思うんで

はい

ビットワーデンの実装からの

これ会社が貼ってて

なに?と思ってやったけど

言いつきはエンドテンドエンクリプションが

どのように実装されているか

っていう

ビットワーデンはパスワードマネージャーか

ビットワーデン使ってるんですか?

あっ言っちゃったね

わかんない

僕はビットワーデンを使ってます

使ってます

いや僕はワンパスワード使ってるんで

その

これわかんない

わかんないけどなんか

まさかビットワーデンがすごい

まずいものが出たときに

僕が標的にされたりするのかな

あー

ソーシャルエンジニアリングで

このFMにたどり着いて

ビットワーデンを使ってるらしい

あるかもしれない

じゃあ

これ面白いなと思ったのは

うん

その

この同一ユーザー間での

E2EEの話をしてるのが

結構面白いなと思って

いわゆるメッセージングアプリとかの

E2EEって

割とその

なんだっけな

シグナルとかかな

シグナルのやり方とかが

割と広く知られてたりするし

割と話題になるのって

そっちの方が多い

シグナルプロトコル

なんかパスワードマネージャー

っていうのに着目して

この

同一ユーザー間でのE2EE

ってところに触れてるのが面白いな

なるほどね

ワンパスワードとかもホワイトペーパー出してて

そういうところ読めば

いろいろたぶん細かい部分が書いてあると思うんだけど

どのタイミングで

複合するのとか

ローカルにある

ちゃんと読んでみよう

パーって読み流すには

重いかなと思った

すごい細かいね

よく考えるよな

まあでも

突破されたらおしまいだから

サービス提供側は

ちょっと興味あったら

皆さん読んでください

冒頭で触れてる部分かな

E2EEに対する課題感として

インターネット等から得られる説明が

比較的抽象的であり

実装レベルが難しい

これは本当にそうで

E2EEが何をしてるのかっていうのは

割と誰もが理解している部分であるけど

実装がどうなってるのかとか

要件が何なのか

フワッとしていて

あんまり広く知られてないっていうのは

あるはずで

いい記事だなって思いました

macOS版カールの分析

個人的に

ありがとうございます

面白そう

ちょっとさっき

そこにずらしてきたんだけど

冒頭してなかったから

macOS版カールは

カールと証明書の記事

中身何も読んでない

実は

読んでみようぜ

これからインターネットの記事かな

macOS版は

大元の話題になっている記事は

3月に

本当だ

2023年12月

1週が経ったんだ

他の開発者よりも

ダップルカールセキュリティにしている

というタイトルで記事を公開した

本気で明らかになっている部分が多くあるため

推測や仮説

CSアドオプション

これに関して違いがある

使ったことないな

証明書検証

システムの証明書ストアを使って

再度証明書の検証に失敗した場合か

あー

確かそれは差分だね

検証を作成して

分析

分析は失敗しているのに

macOSでは検証していない

へー

オプション利用しない場合も異なる

知りない場合は

組み込みの証明書リストを

カールは使うけど

macOSの場合は

CA証明書のデフォルトの場所があって

Ubuntuはデフォルトの場所

Ubuntuもデフォルトの場所があって

えーっと

ただ

macOSではデフォルトの場所の証明書を

ん?

ちゃんと読む

macOSの場合は

エトセセセル

デフォルトの場所

この

macOSで

デフォルトの場所を

さっき作った証明書に上書きしても

検証に失敗せずにリクエストが成功

してしまうことが確認される

あー

なるほどね

あれかたどれないやつが

あーなるほどだからオプションなしで

目的につかれているやつを

本来は失敗してほしい

証明書に上書きしても

おそらく

システムの証明書ストアへ

フォールバックして成功してしまうって話か

うーん

中間者証明書が設定されていない場合は

最大のリクエストでしょ

パッチが

別にカールにパッチが当たっているわけじゃ

なさそうっていう話も

LibreSSLにパッチが当てている可能性があるから

なんか別に

カールだけの問題じゃない可能性もあるねっていう

意見がされて

まあまあ

問題ないのかな

セキュリティ的な問題もちゃんと書いてくれてるね

まあ本来動作した

動作がちょっと違うって言うと

まあ

なんかMac OSあるあるあるだろうな

せどとかもさ

まあせどはなんかMac OSのっていう

まあでもMac OS独自かあれば

どうなんだろうよく分かってないけど

GNUせどと違うって言うので

たまに困るし

あーMacOSがそうだねだからせどと一緒だよね

結作がね

おもろいな

まあなんか仕事でぶつかることはあんま正直

自分はないかなと思うけど

でも困る人は困るだろうな

えー環境変数で

いやー

なんかすごい

めっちゃドハマリする可能性

ありそうだよねこれでね

そうだね

この情報知らずに踏んだら

発狂するだろうな

踏んだんじゃないかな

わかんない

あー違うわ

そっかね桃本の記事があるから

それを使って書いてるから

書いた人が踏んだわけじゃないけど

この桃本の人は踏んだのかな

違うなでも一周が

そっか一周が経った

その一周を経てた人は踏んだのかもね

あーそうだね

一周の方読まないとわからないけど

はー

今後の展望

おもろかったな

あーざす

結構読んだな

時間がちょっと

いやー読みたいなちょっと読んでおきたい記事あります?

いやー時間

大丈夫かな

これとかはスキップ

まあちょっとなんか

そうだね改善値があるね

まあでも今回

何記事読んだんだろう

ちょっとあとで数えてみてそれぐらい読めるって前提で

出てこっかな

結構ね読まなくていいかな

って思う記事もありそうで

まあこんな感じでちょっと

つんどくを

つんどくしないという

記事をつんどくしそうなもと

ゆるくやっていくんで

また来週もお願いします

個人的にはめちゃくちゃ

いやー面白かったです

いいんすかって感じ

お金払わなくていいですか

全然全然

楽しく楽しくやらせてます

じゃあそんな感じでまた次回もお願いします

はいお願いします

おやすみ

おやすみなさい

スター

メッセージを送信

Sota Sugiura

サマリー

目次

スター

コメント

こちらもおすすめ