00:00
こんばんは、Replay.fm第15回です。
挨拶のさ、こなれ感がさ、
こんばんは。
ノリが軽いな。
よろしくお願いいたします。
大事でしょ、頭。
軽いな。
離れてこう。
こなれ感がえぐいな。
今見た後だからかな。
今日の時じゃないけど。
どうも、みたいな。
なるほどね。
まあ、こなれてきたところでね。
今年も最後ですね。
今年も最後です。
これ年内に出てるんですか。
年内に出しますよ。
前回、いよいよ年を言わなかったんで。
おお、偉すぎる。
残り5日でしょ。
まあ、どうにかなるでしょう。
出しますよ。
で、年内最後だけど、
うん。
ん?
あ、いよいよ。
まあ、次は新春スペシャル。
新春スペシャルやるかどうかは、
収録後に相談しましょう。
だって、次。
そうね。
うーん、次。
次2日?
2日か。
いやー、でもこの1週1のペースでさ、特別なことすんの結構きついよね。
なんか、記事読むのに。
ああ、まあね。
まあまあまあ、いいですよ。
今週はね、復習してきたシリーズをね、できなかったんですけど、
代わりに小ネタを持ってきてて、話していいですか?
はい。
小ネタじゃないですけど、
フィッシングメールでQRコードを送りつける手法がちょっと流行ってるって話があるじゃないですか。
ほう。
あるんですよ。
あるんですか?
何かっていうと、
フィッシングメールで、
URLとかだとメールフィルターとかに引っかかっちゃうから、
ブラックリストなり怪しいURLなりで引っかかっちゃうから、
QRコードを送ってそれをキャプチャーしてねっていうメールを送るっていう。
で、それでフィルター回避しようとするっていう手法があって、
で、そこそこ多分トレンドになってて、
何かの時に読んだフィッシング協会のレポートにも確か書いてあったかなって感じなんですけど、
それがね、来たんですよ。僕のGメールに。
で、Gメールさ、フィルター優秀だから基本来ないじゃん。
来てるんだけど、写真ボックスに入ってこないんだけど、とうとう来たんですよ。
で、それをね、キャプチャー取ってきたんでね、紹介したいんですけど。
キャプチャー見せらんないけどなぁ。
まあこれも、だしQRコードは後でちょっとモザイクかけて、
公開前に上げ直すけど、こんな感じでね。
出来がいいなぁと思って。
ヤマトウィン語を語るフィッシングメールで。
リアルだね。
再配達予約するには以下のQRコードを読み取ってくださいみたいな。
で、しかも迷惑メールご通知にご注意くださいみたいな。
03:02
こういうの、なんか絶対LLM使ってるよね。
使ってんのかな、まあ使ってるかもね。
綺麗すぎるよね、なんか日本語が。
あー、あーそうね。
ちょっと前のあれと比べて。
でまあ、もうメアドがめちゃくちゃなんで、
すぐにわかったんですけど、
まあまあ騙される人は騙されるかもねっていうのと、
QRコード読み込んで、ページはアクセスしてないけど、
URLはね、なんかDuckDNS.comの
あー、あれだね。
よく使われてるやつだね、最近ね。
そうそうそう。捨ててるサブドメインで。
真剣詐欺で見たなーって気持ちで。
トレンドの塊じゃないですか。
で実際にそのメールフィルターはね、
Gmailのメールフィルターは回避してるから、
あー、すげーなーと思ってね。
えー。
反応しましたっていう。
うん、来るんですよ。
気をつけてください、皆さん。
はい、おもろいね。
うん、おもろかった。
ちょっと興奮したよね、なんか。
あ、これは?みたいな。
いやーでも言う?
いやーまあね、いやまあいいや。
でもQRコードって割となんか判別が簡単じゃん。
あー、そのフィルター目線でってことね。
そうそうそうそう。
割と本当に入るんだったらすぐ対策されそうだけどね。
うん。
それで言うとどうなんだろうね、このGmailフィルターは
読み込めてなくて擦り抜けたのか、
読み込んでんのに擦り抜けたのかは結構気になる。
いやーまあ読み込んでなさそうだけどね。
まあきっとなんか一過性のものだと思うけどな。
本当に入るんだったらなんか普通に対策されそうな気がする。
確かに。
うん。
どうなんだ、画像なのかな?
結構コスト高いよな、その、いや。
うん。
でもなんかさ、メーラー、
まあねQRコードか、メールでQRコード。
うーん、分からんけどなんかこれが正規のユースケースで
こういうのが増えてきたら、
多分メーラー側でその対応しそうだよね、QRコードをこう。
このQRコードはこのURLですってペッてなんか出してくれる
機能とか出てきそうな気がするし。
あー、なるほどね。
そもそも標準、普通にトレンドと。
そうそうそうそうそうそう、もしそうなったらね。
そこまで行くと多分勝手にフィルターかけてくれる気がする。
QRコードの中身に応じて。
確かに。
まあでも、あんまそういう入り方はしないんじゃない?
しないそうだよね。
URL絶対平気するもんね。
うん。
うん。
普通にわけわかんないし、
僕らみたいなパソコン持ってる人はいいけど、
スマホの人は。
だからそれで言うとスマホでこれ開いても
アクセスできないやんけってなりそうだけどな普通の人。
どうなんだろう。画面キャプチャーこれいけんのかな。
今ちょっと試してないですけど、
まあそんなところでやりますか。
えー、じゃあ上からいきますか今日も。
06:03
いきますか。
はい。
はい。
フリーレッドチーム発足から2024年を振り返ります。
フリーデベロッパーズハブの
フリーデベロッパーズアドベントカレンダー
2024の21日目の記事ですね。
はい。
どう触れていこうかな。
2023年7月にフリーのレッドチームが発足したらしくて、
試行錯誤しつつ、1年半ぐらいなのかな。
とりあえずでも2024年1年間サバイブしたよっていう風に
書いてくれてる記事と解釈しました。
はい。
で、フリーはなんかレッドチーム、ブルーチームとあるらしくて、
ブルーチームは結構形になりつつあった状態の中で、
いろいろ評価をしたい。
ちゃんとできてるかっていう評価を行いたい状態だったが、
レッドチーム側は当時は割と立ち上げ期でまだ安定してない状態だったそうで、
いえらいさんの力を借りて評価を行うっていうことをやりましたよ、
みたいな話とかを書いてくれてるような感じですね。
あとは最近はASMもやり始めていい仕組みになってきていて、
サービスインベントリーみたいな側面もあったりするよって話とか、
シーテムをこないだなんか紹介しなかったんだっけ、
花記事は。
またなんか出てきたねみたいな感じでスルーしちゃったんだけど、
シーテムっていうフレームワークを使って運用してるよっていうのを書いてくれたりしてます。
ミッションビジョンバリューを定めたよって話とか、
これからどうしていきたいよみたいなのを書いてくれてる記事でございます。
なんかいいなと思ったのは、ミッションビジョンバリューのビジョンの部分ですね。
フリーの一番最初で最強の脅威になるっていうのを挙げていて、
これいいなってなんか素直に思いましたね。
かっこいいなあ。
かっこいい。
確かにね。
分かりやすいし。
シンプルに考えるとネットチームが最強でそこから守れてれば、
まあ外の脅威からもまあまあ守れるよねっていう感じかではね。
いいよね。
一方でなんかアメリカのYahooがセキュリティ部門のレイオフでネットチーム丸ごと解体してたりしたけど、
なんか国内の今後の動向はどうなるのかなっていうのはちょっと気になるところではある。
これ最近?
最近。
あれ記事読まなかったっけ?
入れたけど読まなかったんだな。紹介はしなかったんだよ多分。
ここには入れといて。いつものあれに入ってる。
そうなんですか。一回読み逃してた。
これじゃない?なんか普通に無料で読める元記事かなんかあるよ。
なるほどね。そもそも国内でワークしてるネットチームを持ってる企業ってどれくらいあるんだろう。
09:09
結構なんかあんまり。
インハウスでね、ちょっとパッと思いつかないんだよね確かに。
フリーさんぐらいの規模でやれてるところってなると相当少ないんじゃないかなって気がするので。
そもそもなぜレッドチームをみたいな話とかってなんか書いてくれてたんだっけこの記事って。
それでいくとピーサーとの中の役割で、
ブルーに対してその相互に高め合うっていう関係性からピーサーとの中にそのレッドとブルーと両方持つっていうやり方をしてるみたいですね。
あとは実は僕ソフトウェアデザインの今年の6月号から
4回連続でそのフリーさんピーサーとの連載があってですね。
それを読んだんですよ。
この記事のために読んだわけじゃないですよ。
もともと読んでたんですけど、それにもね書いてあった気がしてて。
今ちょっと読み直そうとしてるけど。
でもなんかそのどういう脅威に、そのピーサーと立ち上げてってなった時にどういう脅威に対応したいんだっけっていうところで
その内部犯みたいなところと、あとはその外部からの攻撃に
ありました。
外部からの攻撃、社外からサービスや悪意を持ったアクセスを行うっていうのが1個目と
2つ目が開発者による攻撃、CEIやCDの改ざん、メンテナンスを装ったアクセスを行うっていうのが2つ目。
3つ目が社内関係者からの攻撃、社員ピーサーの乗っ取り、情報戦略を狙ったアクセスを行うっていう
この3つの攻撃経路があるという風に仮定というか設定して
その上で多層防御をしていきたいっていう考え方でチームを作りましたって話をしてて。
なんでその、そうこれ、え?って思ったんですけど。
もろい、もろいけどピーサーとなのそれ。
どうなんすかね。
なんかシーサー、いわゆるそのピーサーとの役割は完全に超えてそうな感じがするけどね、一般的な。
ごめんなさい、シーサーと発足の時のが今の話でした。
シーサーとがまず発足して、シーサーとだけの運用だと、
シーサーとやり込んでいくうちに社内セキュリティとプロダクトセキュリティすべてを担当して業務を行うことが不可能となりましたっていうので
ピーサーとが発足した。
なるほどね。
さっき言ったその3つの役割のうち、一番ピーサーとに切り出されて、
僕はそのレッドチームの存在意義みたいなところはさっきの1個目の外部からの攻撃とかっていうところとか、
社内の攻撃とかも多分そうですよね。
12:02
そういうところへの防御力を作るために。
社内の、例えばアカウントが乗っ取られましたとか端末が乗っ取られましたみたいな状況においては、
実質的にはかなり内部犯に近い形になるはずなので、そこの境目は結構曖昧かもしれないけど。
そうっすね。読み直そう。
ありがとうございます。
ちょっと補足じゃないですけど。
わざわざ錯覚版を読んでますけど。
まあちゃんと両面から見ましょうで、レッドとブルーと両方持つっていうのはなんか理にかなってはいそうなんだけど、
なんかレッドをインハウスで持つコストみたいな部分はなんかすごく話を聞いてみたいな。
何人ぐらいの規模でやってるんだろうな。
何人ぐらいだろうね。
ヤフーの記事をチラッと見たら、レイオフの理由としては外注で回す体制ができてきたからみたいなことが書いてありましたね。
まあだから単純にコストなのかな。
いやなんか稼働状態を常に維持するの結構難しそうだなって思うんだよね。
レッドチームをレッドチームとして常に稼働させるって結構難しいというかハードなような気がしていて。
できなかないんだろうけど、そんなに毎日毎日別に見るとかあるけどさ、変化の多いところそんなにないところっていうのが多分あるはずで。
16時中張ってる攻撃者がいるよっていうのがメリットの一つになるんだろうけどもちろん。
結構この記事で触れてくれてるのはかなりレッドチームの取り組みの一部だろうから、レッドチームの1ヶ月間の生活みたいに密着させて欲しいかもしれないけど、気になるね普通に。
定常業務は定常業務で別にあるっぽいから、なんかこの今回の記事を見てる限りでもね。
確かに確かに。
あとはそのPサート発足時からあったわけじゃないっていうところで言うと、
まあなんかそのこの体制の前だと実現したかったことが実現できなかったって部分があるからこうなってるって話とかもあるんだよね。
まあ何にせよ。
まあちょっと今がその立ち上げにおけるどれぐらいのフェーズなのかはこの記事だけだとなんとも言えないけれども、
なんかうまくいくといいなって感じですね。
そうですね。
良かった。個人的にはマジで生々しくて嬉しいですって感じですね。
そのふわふわっとした話じゃなくて。
はい、じゃあ次は僕か。
15:03
はい、お願いします。
そうですね。
GitHubのブランチプロテクション突破方法っていうめちゃくちゃシンプルなタイトルで、
メルカリさんのテックブログのアドベントカレンダーなのかな。
アドベントカレンダーでした。
の記事です。
記事の内容はタイトルの通りで、
GitHubのブランチプロテクション突破方法を結構オモラ的に、ほぼほぼオモラ的に丁寧に解説してくれてるなっていうところで、
僕は正直、もともとは、なぜか高1年で詳しくなったんで、
そんなにこの記事でそんなルートがっていうのはなかったんですけど、
一方でそんな普段GitHubがっつり使用知らないとかアクションで触んないって人にとっては、
それなりに発見があるんじゃないかなっていうところがあるんで、
ぜひ読んでほしいなっていうところと、
また、これGitHubのドキュメントにないんですよね。
GitHubの…
まとめがないってこと?
そう、仕様としては全部ブランチプロテクションの仕様とかアクションの仕様とか、
そういう仕様あるし、
あとセキュリティのプラクティスみたいなドキュメントもいっちゃって、
こういう設定するといいですよみたいなものもあるんだけど、
こういうふうにしたら脆弱になりますっていうような切り口のドキュメントはないんで、
その意味では結構貴重な資料だなっていうのは思っていて、
なんていうか、頭の片隅に置いときたいなって。
思考の整理としてはすごく良さそうですよね。
そうっすね。
ていうかなんか、このGitHubアクションで使って何ができるんだっけみたいな話とか、
ブランチプロテクションにフォーカスしてるんだけど、この記事は。
そういうのこう、ある種のスレッドモデリングみたいなのやるときに多分めちゃくちゃ役に立つというか、
やりそうだよね、これね、多分。
そうだね。
何かことあるたびにこれ考えるような気がしていて、結局。
そうだね、そうだね。
それをやってくれてて、そのままあそこに置いといてくれるっていうのは、
これ参照すれば終わりだから。
まあ、そのGitHub側の仕様とか変わっていく部分はあるだろうから、
ずっとこれが使えるとは思わないけれども、
めちゃくちゃ助かる系のやつな気がしますね。
そうですね。
まあ1個注意点があるとしたら、結構1年経っちゃうとGitHubかなり仕様が進化しちゃうんで、
そこは意識した方がいいかなと思うんですね。
例えばまあこの記事では触れられてないけど、
ベータ版だからかな、そのプッシュルールセットみたいなのが半年前ぐらいに出たけど、
あの辺使うと結構もうちょっと大胆な防御機構を作れたりとか、
でもなんかその辺になってくると結構求められる仕様自体になってきちゃうんで、
18:04
まあまあまあまあ、スタート地点としては多分この記事の解像度が一番ちょうどいいって感じはする。
って感じかな。
あとはなんかたまたま見かけたけど、鈴木俊介さんっていう多分元メルカリの方のGitHubアクション超詳しいのがいるんですけど、
パターン7についてこういう風に防げますよって補足ツイートしてたんで、それも記事に貼り付けておきました。
まあでもここに貼り付けておいても読めないんだよね。
いや解説難くせえみたいな。
まあ探して読んでくださいっていう感じですかね。
そうですね、はい。
まあ結構ね奥が深いんでね。
その1年間やって思いましたけど、真面目にやろうと思うとなかなか大変だなと思います。
はい、ありがとうございます。
はい、じゃあ次はミスハンドルドオーストークンスオープンバックドアーズっていう物騒なタイトルのトリュフフォグの記事ですね。
個人的には毎回面白くてありがとうございますって思ってるんですけど、
これどういう記事かっていうと、
いろんなSaaSとかを使う時にサードパーティのインテグレーションみたいな形でオース認証でスコープを絞った権限を異常するってことを皆さんやると思うんですけど、
その辺の機能でその連携の実装に不備があるSaaSなり、記事中ではSaaSっていう表現をしてるんですけど、
サービスをいくつか見つけたよって話をしてますと。
具体的に何の不備があるかっていうと、図にしちゃってるんですけど、
従来のオースのあるべき姿としては、ユーザーが連携しますってポチッと押して、
そしたら連携したい先の認証画面に飛んで、この権限とこの権限渡せよ、いいよねってポチッと押したら、
元のサービスにリダイレクトされてきて、元のサービスがリダイレクトされた時に、
いろいろにくっついてる何がしを使ってアクセストークンを取得して、
そのアクセストークンで以降の異常した権限を用いて、いろんな機能を提供していくって形で、
この時にリダイレクトされて戻ってきて、そのパラメータを元に取得できたアクセストークンっていうのは、
ユーザーに渡さないもんですよ、基本的に。
サーバー側で、ユーザーに渡す必要ないからサーバー側で用心やってねっていうのがあるべきだよねっていうふうに書いてある一方で、
じゃあアトリウムフォグがこれは不備だって主張してるのは何かっていうと、
今言った取得したアクセストークンっていうのがユーザー側に露出しちゃってるっていう量っていうのが不備だよっていう話ですと。
21:03
で、一例でサービス名は全部濁してあるんですけど、
一つユースケースで取り上げられてたサービスとかと、
オース連携後に取得したアクセストークンを取得できるAPIエンドポイントとかがあったりして、
これはなんやねんっていうところが書いてあって、
それは確かにいらないね、おかしいね。
これのじゃあ何がいけないのっていう話で言うと、
例えばわかりやすいとかとXSSとかユーザーの環境が何か侵害されてしまったときに、
そのアクセストークンまでたどり着けちゃうっていうところで、
被害が不要に広がるよねっていうところがこの記事が課題として提起してるところで、
あとなるほどなと思ったのはアクセストークンが取れるって仕様だと、
攻撃者目線そのサービスのアカウントを突破してもらえれば、
そこから発信して、
その連携先のアクセス権を収集できるってことにもなるし、
それを悪用したときに悪用されたことに気づきづらいよねってことも書いてあって、
そのサービスに見えるからね。
もともと自分で連携してるサービスが振る舞っているようにしか見えないので。
新しく連携してるんじゃなくて、連携済みのトークンを使ってるから、
連携しましたよみたいな、ログインしましたよって通知もメールとかも飛んでこないから、
結構気づけないよねっていうのが問題です。
で、特にできることはないんですけど、
トリフォーがこの見つけたやつ何十歳とかには報告したが、
70%はごめんねって言って対応してくれて、
20%は無視して10%は使用ですっていうふうに回答してて、
僕ら的にはこれは脆弱性だろうって思うけどね、みたいな感じで。
でもこれさ、フロントエンドアプリケーションとバックエンドアプリケーションを合わせて、
オースクライアントと見成したときに、
両方でアクセストークンが共有されるって自然なことじゃないって思ったけど、
そう…
フロントエンドから直でGitHubにアクセスするケースがあるんだったら、
これ自体は自然じゃない?
アクセストークンがフロントエンド側に渡るっていうのは自然だよね。
そうじゃないんだったら意味がわからんっていうのはその通りだと思うんだけど。
そうしたいパターンってどういうパターンがあるのかなって気はするけどね。
わかんないよ、それはわからん。サービスの特性にもいるし。
サーバー中継して隠蔽した方が良くないって気もするし。
だからその辺は、実際問題は使用次第って話はあると思う。
だからこの10%が脆弱性じゃないって言い張ってる10%は、
24:04
実は使用上そうしなきゃ実現できない機能があるとかって話かもしれないし。
そこはわからんけど、これをもって脆弱性だよねって扱いがおかしいよねみたいな話になっちゃうのは
ちょっと違う気がするけどなと思わんでもないんだけど、どうなんだろうね。
なんか微妙なところではね、記事でも言ってたけど、
これが使用違反なのかと言われると結構、
オース次第本当に大枠しか決まってないってものもあるし、
別に何かの観点で間違ってるというわけではないけど、
リスクは大きいよねみたいな感じの捉え方をしてる。
アクセストークンを返してくれるエンドポイントがあるみたいなのは、
たぶんサバリのITPとかでクッキーとかが飛んじゃうからなんじゃないかなと思うんだけど、
ファーストパーティーなら飛ばないのか。
でも内側の一定期間とファーストパーティーであったとしても飛ばしてたはずだから。
セッションが消えちゃうってことを言ってる?
そう。
でもオース連携してたアクセストークンだければサービス動きますっていうサービスも
よくわからんくらいあるのかな。
でもそっか、どっちにしろクッキーをフロントエンドに置いといたとて、
でもやっぱ必要だよな。
ログインセッション作って、そのサービスとのログインセッションでだけだと、
仮に完結しなかったとしたら、
GitHubとかのアクセストークンをフロントエンド側に何かのタイミングで渡さないと、
特定の機能が使えませんっていうのが出てきてしまう可能性があるのか。
もし仮にフロントエンドからGitHubを直で叩かないといけないユースケースがあるんだとしても、
その場合は多分アクセストークンをそのサービスのバックエンドから返すんじゃない。
ついにフロントエンドにいつでも渡せるようにしとくんじゃなくて、
改めてワンタイムでアクセストークンを取り直すべきな気がするな。
せめて。
もう一回オーセ連携をしてってこと?
そうそうそうそう。
それはちょっと不便なんじゃない?まだ有効期限が。
どうしてもそれやらなきゃいけないんだったらそうするべきだなって思う。
バックエンドで持ってるアクセストークンをいつでも取れるっていう状態にしておくよりは、
絶対そっちのほうがマシなはずで。
そもそもフロントエンドに持たせなくていいよねっていうのはこの指摘の通りで、
持たせない仕様のほうがベタなのは間違いないんだけれども、
どうしてもそれが必要なユースケースがあるんだったら、
多分そういう時は、
2とGitHubの連携をし直してもらうっていうのがベタかな。
なるほどね、確かに。
なるほど、確かに確かに。
わからんけどね。
そんなユースケースあんのかわからんけど。
まあでもサービスによるんじゃない。
GitHubはないかもしれないけど、
GitHubじゃない他のなんていうか、
そのサービスだったらもしかしたらあるかもしれないし。
そうね。
27:00
それはなんとも言えないよ。
もうケースバイケースとしか言いようがない。
そうね、そうね。
そういうユースケースあったら誰か教えてくれ。
俺思いつかんかった。
まあでも10%がそうなのかもしんないし、
まあまあ、まあまあ、
なるほどねと思ったんで紹介しました。
あんまりいやでもないと思うけどな。
いやまあまあまあちょっと僕の経験もそこかもしんないね。
はい。
まあサーバー実装をサボりたいんじゃないの?知らんけど。
まあそれはね、そういう人はそういう人しかない。
直接書くといいじゃんこんなんってなるケースもあるんじゃないの?
別にその間に入る必要がないみたいな。
まあそう思う人もいるかないか。
いやーそうね、まあいるかもしんない。
でOAuthの使用上別にアクセストークンを、
要はそのさっきも言った通り、
そのフロントエンドとバックエンドセットでOAuthのクライアントをみなしたときに
アクセストークンがフロントエンド側のコードにも当たるのは自然なことだと思うから。
うん。
自然なことっていうかまあ別におかしなことではない範疇に十分入ると思うので。
うん。
まあ確かにね。
なるほどね。
と思いました僕は。
ありがとうございます。
まあ渡さんで済むならその通りだと思うけど、
でもアクセストークンがXSSで抜かれちゃうっていうのは確かにリスクとしてはでかくて。
うん。
なんかわかんないけど心配事を、
実装店に立った時にこの視点を持てるんだったら
心配事を増やさない方が良くないって気はするんだよね。
うん。
守る箇所が増えるじゃん。
それは間違いないですね。
うん。
なんかそうしない方が良いんじゃないかなって気はするけど。
まあでもセッション取られたりしたらほぼ同じだろうからそこはまあまあ。
いやそんなことないよ。
だってそのサービスを要は仮に要はXSSの影響範囲がめちゃくちゃ広がるんですよこれ。
うんうん。
そのサービスに留まらないところまで。
そのサービスの要はバックエンド側にしかアクセストークンがなかったら
そのサービスの機能を通じてできることしか
例えばGitHubだったらGitHubの影響は及ぼすことができない。
一方でアクセストークンを取ることができれば
そのアクセストークンを使ってそのアクセストークンでできる範囲のことすべてを
GitHubに対してできるようになるから影響範囲がめちゃくちゃ広がるって意味だと。
それはそうですね。
この指摘自体はもっともだと思うし完全にそうだよねと思うんだけれども
これを持って、要はこうなっていることを持って
これはNGだよねって言い切れるかは何とも言えないなっていう感じでございます。
ありがとうございます。
それで言うとGitHubはオース連携が2種類あるんですけど
30:01
古い方の連携だとめちゃくちゃファジーな権限を渡しちゃって結構危ないかもしれないですね。
まあいいや。
はい、そんな感じです。
じゃあ次行きますか。
次も私で、まあサクッとって感じですけど
Google Chrome uses AI to analyze pages in new scam detection feature
っていうブリーピングコンピューターの記事かな確かですね。
で、時間なくて元のリリースノートというかたどれなかったんですけど
どういう記事かというと
Chromeにいわゆる偽サイト、正規のサイトを模倣したサイトが
世には蔓延してると思うんですけど
それをリアルタイムにAIを使って判定するっていう機能を実装
実装というか試験的に実装してるっていう話ですと。
今はまだChrome Canaryでのテスト中らしいんで
多分Chrome本体はできてなさそうかなってところですね。
はい、まあそんだけなんですけど
まあ結構個人的にはこの偽サイトをありたらゆうてで
Googleの場合は検索画面から徹底排除するとか
そのURLのブラックリスト超リアルタイムで
なるべく補足してアクセスブロックしてあげるとか
まあいろんな話がありますけど
まあそれでも追いついてない部分に対して
ある程度収支法を打てたら嬉しいんじゃないかな
っていう希望の面と
もう一つはこの機能さえも騙すような偽サイトを
攻撃者が作るっていうまたイタチごっこが始まるのかっていう
どうなんだろうなみたいな部分はちょっと
まあこの分野も恩返かなんであんまわかんないけど
どうなんでしょうねっていう感じでちょっと紹介したかった感じですね。
そんだけです。
面白いですね。なんか取り組みとしては面白そう。
そうなんだよね。
これ元のGoogleの紹介記事とかがないかなと思ってしまうときは
僕はたどり着けなくて
成果が出たらなんか記事出してくれるんじゃないかな
とか思ってるんですけど
ちょっと今後に期待したいなっていう気持ちでいます。
これもう売却されてしまったら
こういう取り組みができないのかもしれないが
じゃあ次。
33:01
サクサクいっちゃいますよもう。
次は
マリシアサーレスパックパッケージスパルウィッシュ
ユージングストールNPMトークスっていう
このブリピンコンピューター記事なんですけど
何かというと
マリシアサーレスパックっていう
JS Kyraではかなり結構有名なパッケージがあって
それがサプライチェーン攻撃でやられて
マイニングの丸山仕込まれましたっていう
話の記事ですね。
どれぐらいだっけな
人数、ダウンロード数が書いてあったと思うんだけど
39万4千ダウンロード
39万4千回ダウンロードされて
ダウンロードで言ったら
2つあるからか
39万4千回プラス14万5千回ダウンロードされたんで
結構デカいパッケージなんですよ
僕も知ってるというか
ウェブパックの次世代版みたいな感じなんで
なんですけど
盗まれちゃってやられましたって話で
って感じの
結構厳しいなっていうところで
思ったんですけど
ちょっと話としてはそれだけなんですけど
なぜここでわざわざ取り上げたかっていうと
社内でこの話した時に
これNPMのプロビナンスっていう機能があって
これを使えば防げましたよっていうツイートを
そのツイート僕は見つけられてないんですけど
社内の人が教えてくれて
そういうのがあって
このプロビナンス機能知らなかったんで
ちょっとへーと思って紹介するかみたいな感じで
持ってきたって感じで
これ以上は何かっていうと
シンプルにパブリッシュする前に
署名的なものをして
本人がビルドしたものであることを証明する
みたいなことができます
要はGitHubのサインドコミッツに近い感じなのかな
多分そう
リリースに対して署名を付けてくれる感じってことでしたね
ですね
そうそう
ただなんかちょっとドキュメント見ただけだと
結構わかんないのが
GitHub Actionsだったらこうやったら
署名的なことできるよっていう例とか書いてあるんですけど
オプション1個足してるだけでできてて
前にトークンライト権限つけてるんで
なんか結構吉野にやってそうで
そのどういうレベルの署名がされてるのかいまいち
わかんなくて
今回はNPMトークンが漏れてるから
それで見てればわかってるって話なわけですよね
詰まるところ
そう
要はこの吉野にやってくれるレベルだと
36:00
GitHubのコード側に変なものが入っちゃいました
みたいな話だと多分防げないわけですね
それは防げない
あとは結局そのNPMトークン使って別のリポジトリで
このProvenanceオプションつけて
パブリッシュしたときに
署名はされてる状態で配信はされるけど
署名元がどうかっていう検証をちゃんとしないと
不適切なやり方が
でもアテステーションって書いてあったから上の方に
Provenanceアテステーションって書いてあったから
なんかその辺は何かしらのサポートがありそうだけどね
なんかね
その辺
だからちょっと
それこそ来週もしくは再来週の宿題にしたいなと思ってるのは
これでその
これじゃあ今回これ使えば防げましたよってなったときに
なんだろうな
分かんないですけど直感的には
今入れてるライブラリがあって
それぞれにこういうProvenanceコマンドで言うと
このパッケージはこういう署名ができますってなってたときに
そのスナップショットを取って
サブをちゃんと取ってないと
変なやつが入ってきたときに分かんないんじゃないかなと思って
大体からして署名の鍵が何を使ってるのかよく分かんないんだよね
そうなんですよね
手元でこの
npm orbit signaturesだっけな
このコマンド叩くとそれこそ
インストールしたNodoモジュールに
どのパッケージにこの処理がされてますっていうのが出るんですけど
この結果見ると
なんか1267
今エグザンプルで書いてあるやつを読むと
1267パッケージをチェックして
チェックしたわけじゃないか
1267パッケージがauditで
それがverified register signaturesを持ってますよ
そのうち74個はverified attestationsを持ってますよ
っていうところまでしか出してくれないので
そうなんだよね 何をチェックしたらいいのかよく分かんないよね
そうなんですよ
あとその実務にどう活かせるのって話だよね
リノベートとかで勝手に入ってくるわけじゃないですか
そのリクエストが立ってバージョンアップしてくださいね
っていうのが入ってきたりするわけだけれども
っていう中でこれをどう活かせますかっていう話はちょっと気になる
そうなんです
まさしく言いたかったこと全部言ってくれました
そこは結構自分への宿題としたいなって思ってると
今日は間に合わなかったんで
新春スペシャルで
あとはなんか分かんないけど
NPMのレジストリ側でもうちょっとこれ
パブリッシュされる段階で防いでくれないかなって気持ちもあって
例えば
NPMトークン盗まれたらダメなのかな
今回の場合で言うとNPMのアカウントまでは盗まれてないわけじゃないですか
だからアカウントの権限を持って設定できる項目として
39:04
こういう環境でビルドしたものしか
パブリッシュできないよみたいな設定をかけるようにして
例えばそこにはこのリポジトリのこのワークフローでみたいな
このPodcastで多分紹介したと思うんですけど
GitHubのアテステーションの機能でその辺を検証できるようにするっていう
簡単にできるよっていうビルドのワークフローとかで
それとかでこういうものっていう設定をして
それしかパブリッシュできないっていう設定にしとけば
NPMトークン盗まれても環境までは盗めてないんであれば
悪意のあるものを新しい場所に出すってことはできなくなるわけだから
なんかそっち側で担保してほしいなみたいな
なんかこっち側で運用でカバーするのちょっと不毛だよなっていう気持ちもありつつ
感じですね
でもさっき言ったとおり
今言ったパターンだと行動が
悪いプロジェクトがマージされちゃって
正規のリリース方法を持ってリリースされちゃったパターンは気づけないんで
そこは別立てかなっていう感じですね
ちょっと勉強になるなと思って
とかなんかちゃんと調べよう
勉強したほうがいいことだらけなんだな
いいことじゃないっすか
まあそうっすねいいことです
ノードJS好きと豪語しながらこれを知らないことはちょっと
知らなかったことに少しだけ恥を感じつつ
まあそんなんばっかだよね
前知前能は遠いぜ
まあレスパックね
まあまあやられるときはやれるよねっていう例としては
僕は被害範囲じゃなかったからいいですけど
まあイージー
ここから恐れずに言うと
脅威を伝える上ではイージー例だなと思っておりましたので
紹介しました
はいありがとうございます
うっすうっす
はいじゃあ次も私ゾーン最後かな
あーこれねなんかタイトルだけ見たけど上げなかったやつ
あーほんとっすか
権限管理基盤チームのCIの仕組みと課題っていう
フリーさんのアドベントカレンダーかな
ここ3週間くらいフリーさんのアドベントカレンダーめちゃくちゃ読んでますね
ハイウェアのアドベントカレンダー
いくつやってんだろアドベントカレンダー
追わない
QAとデベロッパーだけなんじゃない
2つ3ついそうだよねなんか
あんのかね
まあすごい
あーでも多分2つだな
同一日付で2つずつ出てるから
42:01
あーそうか
25日がえっと
まだ1個しか出てないけど大丈夫かな
まあまあまあ
まあまあまあまあまあ
応援してます
この記事自体はタイトルの通りで話していくと
その権限制御を担うマイクロサービスっていうのが
アーキテクチャ上がってそれに対してどういう風にテストをするかって話ですと
で今まで基本的には機能追加ごとに
テストケースをどんどん追加していって
かつそれをリグレッションテストとして
新しい機能が追加されるたびにデグレが起きてないかっていうテストとして活用してたんだけど
テスト増えすぎてローカルのテスト実行が長くなってきたっていうところで
その辺の実行CIに移したりいろんな工夫をしたよっていう話ですね
まあまあまあ話としてはよくある話かなって気はしてて
工夫ポイントとしてはマイク使い上げてくれてて
並列実行で速くしたよとか
またマイクサービスアーキテクチャなんで
権限管理基盤マイクロサービスが依存するマイクロサービスを立ち上げるための
データベースのデータみたいのを事前にダンプして
S3に置いといてすぐに立ち上げられるようにするとか
あとはこれはなるほどって思ったんですけど
テスト対象の機能ごとにラベルっていうのを用意して
このテストケースはこういう機能で走らせるみたいなラベルをつけて
プレリクエストにラベルをつけたときに
それに対応するテストだけが走るようにする
だから全部走らせないっていうようなことをやってますって話で
これはRANっていうE2Eテストのフレームワークなのかな
僕はちょっと知らなかったんですけれども
こういうテストツールを使って
それがYAMLでいろいろかけてラベルをつける機能があるんで
それを使ってますっていう話をしてたのと
あと毎朝定期実行するみたいなことをやってて
工夫してるんだけど課題はあるよって話で
適切なラベル設計をちょっとしていかなきゃいけないって感じのところと
あとはリグレッションテストの量自体が
どれぐらいが適正なんだっけっていうところに話が上がってて
無限に増えていっちゃうんで
無限にCI回し続けるのっていうところだと思うんですけど
っていうところですね
なるほどね
なんか結構
権限制御とか自分の仕事に置き換えたときに
認可機能みたいなの漏れなく得てるってなったときに
ロールの数が4つぐらいあって
その4ロールがこのエンドポイントにこういうふうにアクセスしたらこれがダメみたいなやつを
45:02
全エンドポイントでやりたいってなったときに
結構大変だよなって気はしてて
じゃあそのテストケースやめられますかって言われると
割と最後の壁なんじゃないかなと個人的には思ってるんで
安直になくす予選とか取れないなっていうところで思うと
同じような課題にぶつかりそうだし
同じような工夫ポイントを踏むんだろうなみたいな
ちょっと自分事として読んだって感じですね
またラベル設計は確かに便利そうなんだが
普通に設計めっちゃ難しそうだなって思ったら
やっぱり最後に難しいですって書いてあってそうだよねって思った
なんかちょっとすごい言うは安い案件な気がするけど
変更範囲に応じて影響範囲がある程度自動で定まるような
自明に定まるような工夫の方が筋が良さそうな感じがするな
ラベルを人間が頑張るのは結構しんどそうな感じがする
つけ忘れるとかも普通にあると思うし
あるいはハウの一つとして最終的にラベルに落ち着くっていうのはありかもしれないけど
ラベルをつけるところを自動化できないかとか
確かにね
それはなんか十二分にありなアプローチな気がするな
そのリグレッションテスト
なんか変更範囲に基づいてテスト系吉成テストを回すみたいなのって
こういう権限制御系に限らずすごい人類の夢感があると思うんだけど
そうなんだよね結構ヒューリスティックな営みな気がするんだけど
結構むずいんだよな
それをなんかアーキテクチャとか
なんて言ったらいいんだろうな
ある種のアーキテクチャ的な考え方で上手いことできたりしないのかな
影響範囲が小さくできるような
なんかマイクロサービスも一個その回で
それはそうだね確かに本当か
インターフェースが変わらなければっていう考え方はあるよねマイクロサービスの場合はね
というかなんか単純にその分かんないけど
ABCDってマイクロサービスがあってBのコードしか変えてなかったら
ACDの振る舞いは
振る舞いは変わんないけど壊れる可能性はあるから
でもセキマは分割されてるじゃん壊れたらBが悪いんだって
そのBで完結できるはずっていう
なんかその一個一個がまた被害していったりとか
なんか弊社の場合はモノリスアーキテクチャなんで
モノリスの時にどうするかは結構ね
むずいなって思いますね
綺麗に縦割りにならないじゃん
現実世界は結構なかなか複雑なんで
48:02
ちょっと難しい感じはするけど
でもラベルに応じてテストのボリュームを変えるとか
実行するテストを変えるみたいな仕組みができたので
どうやってラベルをつけますかに今度はフォーカスできるっていう
ところまでいけてるはずだからステップバイステップでやっていくとして
じゃあそのラベル付けの苦しみをどう解決しましょうかっていうところに
次取り組めるはずだから多分流れとしては全然おかしくないはずで
確かにね
これは結構ね来年のアドベントカレンダーを
正座して待ちたいなっていうまあ来年じゃないかもしれないけど
今後に今後の話聞きたいなと思ったって感じですね
このLAN-Nは便利っすね使ったことないけど
なんかGoのテストのテストヘルパーに組み込めるらしくて
便利やんってちょっと思ってる
使ってみたいけど使ってみたいけど素振りする機会がねえなこれ
いやーマジくそー
こういうのはね現場で使うのが一番いいよね
そうなんだよそうなんだよマジでそうなんだけど
いやーそうなんだよマジでそうなんだよね
分かるよ
なんか全然モチベーションわかんよね
しかもそんな複雑なそのなんて言ったんだろう
LANブック的なものが必要になるようなテストをまず書かない
書かないっていうかそんなものが必要になるようなアプリケーション
趣味で全然書かない
そうだね
本当はなんかもうだらだらメンテするそこそこ複雑な
いやー分かるよめちゃ分かる超欲しい
一個あるとね色々実験できるんだろうけど
こっそりちょっとずつなんかその
アストロで自分のページ書いて作ってたりするけど
なんか全然進まんし
しかも別に大した希望にならんし
そうね
しかもCSS触ってる時間が一番長い
あれある
テイルウィンドウとデイジーUIと格闘してる時間が一番長い
あれこれがやりたかったんだっけってなるんだよな
違うんだよ俺はリアクトが触りたかったんだよって思うんだけど
面白いね
100人が100人通ってきた道やな
まあそんな感じ
勉強になりましたちょっと今後に続報待ちします
ランNはなんかちょっと触ってみようかな
ランN触ってみたのなんか
そうですね
スクラップを作っとこう
お願いします
はいそんな感じですね
じゃあ次
全然変わるんだけどさ
全然変わるんだけどさこの
51:02
スクラップのさデフォルトの設定を変えらんないのかな
他の人が投稿できるやつ
わからん
わからんか
わからん後で研究してください
後で言ってみますね
記事読んでください
僕も読んでる記事ですけど
いきますかじゃあ
距離モデリングのためのカードゲームを比較するフリーデベロッパーズハブの記事です
これがまたフリーデベロッパーズアドベントカレンダー2024の17日目の記事ですね
ちょっと待って
昨年のアドベントカレンダーではクレデンシャルをスラックに書くなこうこうこうかというのを出してプチバズリしていたのですが
今回はネタワークではなくもうちょっと真面目な話を書きますとのことです
ワトソンさん
クレデンシャルをスラックに書くなこうこうこうかは何でもかんでも何とかこうこうこうかにするな
派閥になんか微妙に叩かれてたりとかしてちょっと面白かった記憶があるな
そうなんだ
そんな派閥があるんだ
なんかわからないけど
なんかそんな界隈を観測してて俺のタイムラインで
誰の何なんだ
何でもかんではなんかそんなふわっとこうなんか何とかこうこうこうかにするなみたいな
ことを言ってる人がいた記憶がある
なんなんだよほんとに
サニタイズユーナとなんか同じような話なんじゃないかなってちょっと思ったけど
まあまあまあはい
えーっと
そうですねどう紹介していこうかな
どっかで以前そのフリーでの教員モデリングの取り組みがあんまりうまくいかなかったって話をしたらしいんですけど
ピーサートだけでの活動では限界があって大きく複雑なシステムに対して継続的に取り組むのが難しいという課題とかがありましたよと
ピーサートが完全主導するよりはより開発者チームに寄った形で進めていくのが望ましいのではないかっていう
仮説から
移動機にこの筆者の方がセキュリティチャンピオンになったらしいんですね開発チーム側に移動して
でチームメンバーを巻き込んで教員モデリングを開発チーム側でやってみましたよっていう記事です
はいで
えーっとなんだっけ
なんやかんや書かれててシステムに対する脅威を列挙するっていうステップが
えっと開発者チーム開発チームではえっと脅威とか攻撃についての知見が少ないっていう点で
セキュリティ専属のチームが進めるより若干ちょっと劣るというか難しいハードになるっていう部分があって
まあなんか割と多分万人に共通する課題なんですけどこれ自体はこれをカバーするための方策として脅威モデリングを行うためのカードゲームが考案されたらしい
これ知らなかったんでなんかほえーと思ったんですけどはいなんかいくつかあるらしくてえっとそうやってみましたよ紹介の記事でした
54:09
まあちょっとこれは正直読んでみてくださいっていう感じなんですけど
で得られたその学びとしてこれを実践する上では事前準備が非常に重要だっていうのを感じたらしくて
でまあ例えばゲームを行う前にチームメンバーに対して脅威モデリングって何っていう話をちゃんと1時間ぐらいかけて説明を行ったりとか
あとは構成図とかも先に用意しておいたりとかで脅威モデリングを行うその時間自体はすごくスムーズに進められるようにできたよみたいな話とか
あとは今回カードゲームをするのに3時間ぐらい時間取ってたらしいんですけど時間内で全部終わらなかったらしいです
結構だよね
かなり重めなんだなっていうのがちょっと伺いしてるんですが
でまあ結構疲れちゃうんでなんか集中力も切れ気味になっちゃうよねみたいな話があって
なんか割と生の声だなと思いながら読んでました面白かった
まずカードゲームなんてあるんだっていうのがおって思ったのと
あとは少し別系統のものとしてプライバシーに関わる脅威モデリングフレームワークの一つをベースにした
リンダンなのかリンドンなのかわかんないんだけどリンダンGOっていうなんかカードゲームもあるらしいこれがちょっと僕は気になった
これはちょっと社内のプライバシーチームと一緒にやってみたいなと思ったりとかしましたよっていうのと
あとは開発者によった形で進めるのが望ましいっていうのは完全に同意でメルカリでも実際そうしてた
ドメインごとにきてドメインごとの開発チームとプロダクトセキュリティとプロダクトセキュリティではない僕でやってた
週に1時間みたいな感じで連続で分けてやってたんでその3時間やってちょっと疲れちゃうみたいなのはあんまりいなかった
ただ1時間複数回やらなきゃいけないっていうのは間違いなくあって
ただなんか洗い出しするのにそこそこメンバー集めない人を集めないといけなかったけど洗い出しするのに週に1時間ワーって集めてワーってやって何回かやったらそれで洗い出しが終わるよみたいなのは
個人的にはかなりコスパがいいなって思いながらやってたんですけど
そこそこ人数集めないといけないからコストはかかるんだけれども
週1時間で済むんだったら結構コスパは良かったのかなとか思っていて
ただカードゲームっていう形にしちゃうとシナリオが多分決まってるはずだから
ゲームとしてどうしても一巡するまでに時間がかかっちゃうっていうのがあるはずで
57:05
その辺はちょっと課題なのかなとは思いましたね
そういうのをこうなんとかしてくれてるカードゲームもあったりするのかもしれないけどねもしかしたら
なんかちょっとやってみたいなと思うけど
そうそうめっちゃ素振りしたいこれも
素振りの機会が欲しい
この3時間で終わらなかったってやつも結局そのさ
ある程度アレンジをしたわけじゃん
もともとルールはこのラウンドやるけど時間もあるしこのラウンドやる
ワナシロイでその
割とこのゲームをこの1時間でここまでやればこのぐらいのノリはわかるよねとか
そういう感じでカスタマイズして使う
使えるんじゃないかなって気は個人的にはするけどね
でも今のそのコスパいいっていうのはマジで個人的には同意でなんていうか
その原則で
まあそもそも僕は教育モデリングというかセキュリティー浅い
経験値が圧倒的に浅いですけど
どっちもやったんですよ
セキュリティチームだけでひたすら教育モデリングをして
どこが危ないんだって目を凝らすっていうのと
開発メンバーと一緒に
これちょっとちゃんとリスク洗い出したいんで一緒にやりましょうっていう風に
やるっていうのをやったんですけど圧倒的に
後者の方が楽
楽というかその前者だとある程度までいけるんだけど結局なんか抜け落ちる観点とか
あれこのシステムってどうなってるんだってなったときに
コミュニケーションコストが発生するし
なんていうかその
じゃあそのある程度完成したからじゃあ店に行こうってなった時に
その過程みたいな部分が向こう目線が抜け落ちていくから
割と説明し直しというか
視点とか何を見てるかとか何を考えてるかみたいなところも共有しながら進めると
そうなんだよねコミュニケーションコストが結構高くなっちゃうというか
それだったら最初から一緒にある程度
期待を
そうなんですよ
やった方がいいんじゃないかな
多分これ回数重ねていくと開発チームだけでできるようになると思うんだよね
わかる
っていうところを多分ある程度カバーしてくれるのがこのカードゲームなのかなってちょっと思ったんですけど
その回数重ねてなんとなく分かってこないと
うまくこなせるようにならないっていうところがカードゲームになってる
ゲーミフィケーションを通してその辺が固い解決されてるっていうのがこの話なのかなと思っていて
そうだね確かに確かに
ちょっとこれやってみたいですね
やりますかね
やってみたいな
2人でやってもらう
やってみたいな
なんかこれをやる勉強会でも開く
でもなんかリアルなものに対してやりたいな
社内のエンジニア合宿とかやんないかな合宿とかやったらこれコンテンツでねじ込みたいな
1:00:05
いいよね
それそんな感じでやると
なんかアイスブレイクにも良さそうだしね
いいですねでも知らなかった全然
めっちゃ素振りしてみたいこれ
素振りしてみたい案件がどんどん増えていくんだよな
素振りの急をちゃんと積まないと急のプライオリティ降ってかないと
いや違うんだよまず転職しろって話なんだよ
業務でやりたいならそうだね
そうなんだよ
それはそうね
そんななんか別にいいけどさ楽しく練習しましょうみたいな感じで素振りしてもいいけど
もうちょっとひりついた感じでやりたいよね
ひりついた感じとは
ここで脅威を洗い出さなければ死ぬ
どういうコンセプトのゲーミフィケーションなのそれ
そんなに
最初はハードル下げていこう
これでサクサクってやってたらいざ本番ってなった時に
いやこれもう死にますけどねって気持ちでやってもらえればいい
うっす
わかんないですけど何の会話だよ
まあ素振りできそうな会社さんお話お待ちしてます
XのDMまで
DM殺到するで
聞いてないでしょ聞いてないってまず誰も
それはそうかもしんない
条件はお相談ということで
はいお願いします
じゃあ次ですね
MPA対応したView Transitions APIの悪用方法を考えていたっていう
茶芸の京都JSっていうところで発表したスライドを見たいですね
京都JSっていうのがあるの8年ぶりらしいですけど
めっちゃ行きたかった
近いじゃん
絶対近いんだよ
なんで行かなかったの
知らなかった
キャッチしときます次からは
ジョイングループしときます
8年後かもしんないけど
ロジーがダメなら僕がロジーやるんでちょっと
はい紹介どうぞ
イエラエCTFで出題したスムースノートっていう問題の話ですね
スムースノートっていう問題の解説自体は
イエラエさんのブログのほうでも紹介されていて
このスライドからリンクが貼ってあったはずですね
大雑把に言うとCSSを自由に設定可能なノートを作れるアプリで
検索機能があって
フラグは管理者が作ったノート
1:03:01
シークレットノートの中に存在するが
ノートはユーザーごとに隔離されているので
管理者以外はそのノートを見ることができない
CSPでそこそこかなり固めになっていて
CSSと画像を利用することができるが
JSは動作しないという状態
自分で作成したノート上では好きなCSSを使って
情報をリークできるものの
検索画面や別のノートには影響しないので
一見するとCSSによるエクセスリークスは成立しなそうに見える
ようなアプリケーションですよと
自明な脆弱性としてCSRFがあって
SLA Createにポストリクエストを送ると
管理者のブラウザから好きなCSSを設定したノートを開くことができる
ただしCSSだけで別のノートの内容を読み取ることができない状態ですよと
脆弱性ではないものの
多分これヒントというか実質ヒントみたいになってるんだけど
DevToolsを開くと
Unexpected Duplicate View Transition Name Site Title
というエラーが表示されているよという状態らしいですよと
何かというと
MPA用のView Transitionsの新しい仕組みを利用して
ページ遷移時のアニメーションをさせている
要はナビゲーション発生時に
View Transitionが聞くように
今多分ベータだか何だかでなっててっていう話ですね
ヒロッピーがなんか拾ってた気がするなこれ
タイム前だけど
遷移前遷移後のページでそれぞれ同じ名前のCSS属性
View Transition Nameが指定された要素がアニメーションの対象となりますよと
この辺は前提なんですけど
解法として一言で言うと
View Transition
ナビゲーションオートが指定されている時
正しくView Transition Nameが設定されていれば
遷移後にアニメーション用の
View Transition 基地要素が生成されます
なので
この説明を口頭でし続けて
理解できる人がどれだけいるのか考えると
毎度のことながら
このためノート一覧画面から個別ノート画面に遷移したときに
遷移元画面でサイトタイトルが正常に設定されているかどうかを
View Transition New Site Title Selectorでキャッチして
攻撃者サーバーにリークすることができます
みたいなことがつらつら書いてあって
要はこれによって一文字ずつ
フラッグをリークすることができるよっていう話ですね
ありがとうございます
まとめとしては
すげえ限定的な条件下でトランジションAPIが
悪用できるよっていう話で
ウェブサービスでCSSがかけて
1:06:00
検索結果等でView Transition Nameの
設定されている要素が増減して
訪問者が長時間ワンサイトに座る
これは探索に時間がかかるからですね
みたいなことを書いてくれている
クロスサイトView Transitionsが来たら
もっと悪用できそうなので
密かな楽しみですよみたいなこと書いてくれていて
面白かった
多分理解度70%ぐらいですけど
でも割と面白かったです
よく考えるなって
このAPIも知らなかったしな
どんな脳みそをしてるんだろうな
クロスサイトビュートランジションは
あれなのかな
使用策定中なのかな
分かんないですね
楽しみって言ってるってことは
議論してるところなんじゃないですかね
今SameOriginでしか聞かないから
記事が出てくるな
なるほどね
複数のドメイン持ってるような
サービスとかでやりたいって言ってるのか
まあまあまあまあ
デモはあるかな
実装はありそうだな
なるほど
面白いですね
これは口頭では説明不可能だと思うんで
ぜひスライド見てください
っていう感じですね
面白かった
面白かった
面白かったしか出てこないですけど
面白かったっていう情報が
大事ですよ
では次ですね
これラストだっけ
ラストですね
ラスト1個手前です
1個手前か
オフトピーですね
忙しさの中毒性っていう
コニファーさんの
オフトピーラベルができてる
作りました
毎週あるんで
オフトピーくん作りましたよ
コニファーさんのブログですね
いつもの
オフトピーといえば
オフトピー扱いされてるのもちょっと嫌かもしんないけど
ごめんなさい
ほんとごめんなさいって感じなんですけど
まあ何事も忙しすぎるのは良くないっていう話ですね
それだけなんですけど
なんか僕はなんか
記事以上のなんかあれをちょっと考えていて実は
キャパあふれ気味の状態で何とかするのを
自分の役割や使命のように感じてしまい
根本的な改善も進まなくなるっていうのを
問題の一つとして書いてくれてるんですけど
これがマジで本当に良くないと思っていて
燃えてる状態でわーってなんか対応すると
やるべき議論とかにちゃんと時間かけられないよなと思っていて
流れちゃうんですよね
1:09:01
もっとそこちゃんと話すべきなんじゃないのとか
最終決めの問題なのは確かにそうだと思うけど
決めるまでの過程って
もっとちゃんと話した方が良いんじゃないのっていう
もっと色々論点あるよねみたいな部分とかが流されちゃうというか
一方でやった感だけが醸成されて
本質的な問題解決に至らないとか
そのまま物事が進んでいくみたいな状態が
あるある過ぎてすごくしんどいなと思っていて
どこの会社のことかは言わないんですけど
結構あるあるでしんどいなと思っていて
これなんか木こりのジレンマの話で合ってますか
うーん
ちょっと違う
ちょっと違いますね
ちょっと違うかな
そうか
なるほど
要は何か機能が必要ですってなって
1ヶ月で実装してくださいって言われた時と
半年で実装してくださいって言われた時とで
どっちがより良い選択を積み重ねられるかって考えた時に
多分校舎の方が
分かんないけど
それが実際に結果的に良いかどうかは別として
より良い選択をするため
意思決定を積み重ねていくための
営みはやりやすいよなと思うんですよね
っていう話
なるほどなるほど
なので結果的に忙しくなっちゃったっていう状況というよりは
結果的に忙しくなっちゃったっていう状況だからそういう形にはなってるんだけど
むずいな
複数の原因パターンがあるよね
見る人が見たら忙しくなっちゃうじゃんってなってんのに
そのレバーを引いてしまったパターンもあれば
みんな大丈夫だと思ってたけどやったら忙しくなっちゃったっていうパターンもあるだろうし
あと単純に何かが燃え上がってるっていうパターンもあるし
まあそうだね何か外敵要因で
外敵要因でっていう
確かに確かに
ずっとみんなが多分漠然と課題として認識していたにもかかわらず
外敵要因によって
僕が具体的にイメージしてるのは
そういう外敵要因によってワーッとやんなきゃいけなくなっちゃいましたみたいな状況
そこまでにやってきた良質な議論とかが全部吹っ飛んじゃうような感覚がすごくあって
嫌だなーっていつも思うんですけど
なんでそんなことになっちゃうのかなーっていつも思うんですけど
まあどこの会社のことかは言わないんですけど
なんか珍しくじゃないですけど今回は読むタイミングがあったんでこの記事読んだんですけど
なんか結構シンプルに思ったのはこれ
1:12:02
組織で働く人の話なんであれば
なんかこう今言ってくれたヤギハシの話もそうだしこの記事で触れられてるその
まあ何でしょうねその忙しさの中毒性というタイトルですけど
まあちょっとやれちゃうんだけどこういう風の側面もあるよねみたいなところに触れてる記事だと思うんだけど
なんかそういう部分はなんか理想論で言うとひっくるめてその組織の課題として捉えなきゃいけないことであり
なんかそういうところがピープルマネージメントなんじゃないかなって思っていて
なんでそのなんだろうなあんまなんか
その自分の一瞬とかなんかその人の一瞬って捉え方したくないなっていうのはなんかシンプルに思ったところ
それはそうねそれは間違いなくそう思うその人の問題ではないと思う
まああの
いやいやいや
ニヤニヤしすぎ
あのなんかわざわざいらん仕事ばっかり取ってきてなんか拾ってきてめっちゃ自分で勝手に忙しくなっているような人とかもいたりするから
まあ個人の一瞬じゃないのかなとかちょっと一瞬思っちゃったんだけどまあいいやと思った
まあその自分の立ってる立場によって見え方変わるかもねもしかしたらその
冗長の立場だとなんかそういう動きを抑制することも込みで
わかんないチームのパフォーマンスを最大化するときにその人の動きがそれと相反するんであればそれを抑えるべきだよねって話で
なんかそのいやあなたがフォーカスすべきってことはこれなのになんでこれ取ってきてんのっていうその対話を通して
辞めさせるのか必ずしも正解じゃないと思うから
なんかそこは切り込みに行かなきゃいけないし
同じチームメンバーの目線だとまあなんかどうにかせいやっていう風に見えるだろうし
まあもしくはもうわかんないその冗長というかマネージメントする人でもどうしようもないみたいなレベル感の人とかは
じゃあなんかわかんないな仕事の仕方というかその人能力の話になってくるだろうから
それはもう個人に回帰してくる部分は
だからなんか実際なんか01じゃないかもねちょっとグラデーションがあるというか
まあでも極論それを採用した組織の問題とも捉えられる
あーそうだねそうだね確かに確かにその捉え方もできるね
そうだねなんか結構また環境もあると思うんだよな環境というかそういうのがゼロには絶対ならないけど
その生まれづらいチームとか組織作りっていうのは大事だとは思うな
これに依存しているような組織はマジでちょっと寿命短いかなと思ったりする
続かないよね
続かない
たまに出てくるけど人は疲れるんですよっていうやつ
そうだね組織は続くかもしんないけどその人がねなんか長く優秀な人を与えてもらうみたいなものを求めるんであればあまり良くない
1:15:07
まあいいんじゃないですか新陳代謝ですよ
まあその物は異様案件じゃんそれは
いいな物は異様案件
物は異様案件です成長痛とかと一緒ですよ最近最近とかじゃなくてその僕が一貫して結構あんま好きじゃない言葉なんですけど
多様性とか
多様性とか日本語がちょっと便利すぎない
多様性も確かになたまに物は異様案件あるよな
そうなんですよ
まあまあ
カオスとかね
あー
カトキとかね
カルタ作れそうだね物は異様ワードで
物は異様ワードカルタ作りたい
作るか
技術書店で販売しよう
ひどすぎる
カルタカルタカルタだと何どういうなんかムズないワンフレーズしかないから
読み上げの時間がクソ短くない
読み上げ
あーあれカルタってカルタ忘れたのルールなんか
神の口もろく的な概念ではないのか
それはなんか
100人種かな
そうか
読み上げる方はそれを表したやつで
叩く方はそのワード
まあいいや
いやでもこれ面白いな
個人的には結構
なるほどねっていうオフトピーでしたね
うん
まあね
大事ですよ
はい最後いきますか
いきましょう
はい最後は僕が引っ張ってきた記事で
自分の車の診断アプリ作ってみたっていう
ラックセキュリティごったにブログの記事ですね
これはなんかもしや
嫌気者もこんなん知ってるよと思ってるのかもしれないと思いつつ
僕は全く知らなかったので取り上げるんですけど
記事としてはタイトル通り
自分で持ってる自分の車を
診断するアプリ作りましたって話で
どういうことっちゃいっていうところで言うと
その車には
多分大半のほとんどの車にはソフトウェアなのかな
ソフトウェアに限らないか
ハードウェアとかソフトウェアの異常を検知するための
診断機能みたいなのがありますと
この機能は本来は整備士向けのもので
その診断情報を読み出すために
数十万する専用の機器みたいなのを
使うらしいんですけど
今回はそれを自作してみたっていう話ですね
値段は言及してなかったけど
多分相当安くというか
1000円ぐらいの部品と何かを組み合わせて作ったって書いてあったんで
作ってみたっていう記事ですと
車の中にコネクタみたいなのがあって
1:18:02
そこにその専用機器繋ぐと
情報がバイナリーで流れてくるんですけど
それ自体は何種類かの決まったプロトコルがあるんで
プロトコルさえ特定しちゃえば
あとはもう解釈できるんで
ニールなりヤクナリしましょうっていうので
それを元にAndroidアプリを作ってみたっていう話ですね
あとは診断情報
診断情報自体はここに異常があるよとか
ここが見てみたほうがいいよみたいなのがあるんですけど
それに合わせてエンジンの情報とかも
いろいろ取れるらしくて
その辺もアプリで見えるようにして楽しいみたいな感じの記事でした
大体の車って書いてあるけど
2002年の車でも付いてますと書いてくれてるんですけど
2002年でいうと
日本車でOBDIIのポートが付き始めたのは
本当にこのぐらいの時期からなんで
むしろ多分付いてる車の中だと
一番古い部類の車の話をしてますね
なるほど
2000年ぐらいの車だと逆に付いてない
はいはいはい
なるほどっすね
おもろいなあ
要は知ってるなあ
だからこのぐらいの時期だと
今のISOCANの企画が今の種類のものとは全然違っていて
まだあんまりフィックスしてなかった時期なんで
だから変なプロトコル使ってたりとかする感じですね
あとはこのぐらいの時期は
なんて言ったらいいんだろうな
今のCANって呼ばれてる
コントロールエリアネットワークっていうのが
ネットワークとして車の中で構築されてるんですけど
バス形式のネットワークとして構築されてるんですけど
CANの前の世代のやつを何と呼ぶのかが
忘れちゃったけど
なんだっけな
CANの前が
CANの前ってなんて言えばいいんだろう
分からんけどCANの前のやつと
なんか結構
なんて言ったらいいんだろうな
本当過渡期で多分完全にCANに置き換わってないぐらいの時期なんじゃないかなと思うんですよね
そのぐらいの時期だと
面白いですCANも通信方式としてはかなり面白いんで
調べてみてほしい
なるほど
ELM327っていうのはあんまり通信の安定性が良くないらしくて
僕はもうちょっといいやつを持ってるんですけど
ここまでなんか生で触ることはしたことない
やっぱご存知だったか
OBDの企画として
オンボディングダイアグノーシスができる通信のやり方と
1:21:04
そこに対してCANの通信がそこにも流れてくるっていう
その要は2種類のアクセスの仕方が多分あって
どうやらCANがOBDに流れてくるパターン
流れてくる車と流れてこない車がよろしくて
この間知ったんですけど僕も
なんでこれはどっちかというと
OBDを使ってCANにアクセスしてるよっていう話ですね
CAN通信を見てるよっていう話かな多分
それともそんなことないか
それともあくまでOBDのフォーマットの話をしてるのかなこれは
そうですねだからISOCANになる前の話だから
あくまでOBDの話なのかな
ちょっとごめんなさいその辺の使い分けというか
仕様がどういう速やけになってるのかとか
僕はちょっとよくわからないあんま知らない
なるほどですね
なるほど
この辺が最近の
なんて言ったらいいんだろう
これでも2021年の記事の同じ内容なんだ
あーそうなんだ
なるほどね過去記事持ってきたのか
この辺のセキュリティの話もあって
要は
まあいいやなんかすごい
全然記事の話から外れすぎちゃうからあれだけど
なるほどありがとうございます
いやーおもろいな
やってんな
でも僕はもう全く普段触れない世界なんで
この端子の写真を見ただけで割と感動しちゃいました
あ、いけるんだとやろうと思えば
あとこの
あんま触んないほうがいいっすよ
まじで普通に壊すんで車
やめたほうがいい
あんま触らんほうが
じゃあやめます
これなんかプロトコル紐解いて
自前実装みたいな大学生の頃思い出して
こういうのいいよなと思いながらやるんだけど
やるなら壊していい車でやったほうがいいっすね
普通に
あんま普通に壊れる
なるほどね
はい
今日はこれで全部かな
いやーなんか年乗せも結局
粛々とやったなでもまあまあ
じゃあ年乗せっぽい
何買おう
なんか今年面白かった記事みたいな
来週
あー2024年面白かった記事
やる?思い出せる?
1:24:02
思い出せないかもね
一覧見れば思い出せそうだけど
まあでもいやー
何が面白かったかな
ちょっと見てみるか
今何だっけ
公開ページのあれ見てる記事一覧の
タブを一個ずつ見てる
うーん
2024年タブ作りますよ
いいよ
いいの?いいんかい
なんか別に十分このタブポチポチで
済んどる
なんかあったかな
そんなー
後半意外となかったな
そんななんかわざわざ
2024年この記事が面白かったって紹介するほどの
はねーな
なんか勉強になったのはすごく多かったけど
中堅の停滞期緩やかなCとかは
いや僕的になんだよな
あとアクティブレコード
エスケルインジェクションクイズは面白かった
あれ面白かった
間違いない
あとなんかあるかな
リードスダメ絶対取っかな
アクセシビティも良かったな
赤木
ドメイン名の収穫について良かったな
永久保存版だねあれは
マジで永久保存版
あとあれだシーサーとの政治駆動を可視化するシム3とは
後半の方が結構面白い記事多かった気がするな
確かに確かに
なんかAI系の記事も多かったけど
ちょっともう少し浅瀬でチャプチャプやめたいなって思った
感じだったな今年の
なんかいまいち踏み込めないわ
詳しくないからどうなんでしょうね
同じく
まあいいんじゃないそれぐらいのノリで
まあね
ここは知りついた場所じゃないじゃないですか
まあ確かに確かに
だからいいんじゃないかなって思いますけど
なんか前々回やったら記事多いね
何だろうねやっぱ波はあるね
面白すぎる
まあちょっとパッと思いつくとこはその辺ぐらいかな
ベース64エンコードした
シークレットギター部セキュリティスキャン
アドバンスセキュリティがスキャンできないのはちょっと重かった
まあそんなとこまでなんか
お世話できないよっていう感じなんだと思うけど
まあね
1:27:01
そんな感じですかね
いや読んだな読みましたね
結構やりましたね
だって15回やったってことは
まあ1回平均1時間半だとして
何時間15時間に
22時間ぐらい
20
そうっすね22、3時間ぐらい
やってますね
生配信してるのと同じぐらい
やります?24時間リプレイFM
体が悲鳴上げちゃう
171記事
いやー素晴らしい
いやーだってこんな読めてなかったですよこれ始める前は
しかもさ紹介してるのがこれだけであって
その読んでる記事はもっとあるわけじゃん
もっと読んでるね
なんかさ最初の方は
ガーって読んでちょっともうまあこれもういいかみたいな感じで
落ち着くかなと思ってたけど意外とやっぱ
落ち着かないねトレンドもそうだし知らないこともやっぱ
まだまだ多いね
なんか
サプライチェーンの侵害された系とかもさ何回か取り上げても
またまたかみたいな感じで思ったけど
RSパックとかはまじかと思ったし
いやー何なんだろうね
どうしたらいいんだろうね
サプライチェーンですか
それで言うと何回何巻の時に
ヤイヤシャー紹介してくれたNRA関屋さんのセッション
何かのイベントセッションの
遺伝子
遺伝的な考え方でやつみたいなやつすごく面白かったけどね
あれぐらいのアプローチを取らないと
もう無理かもしれない
全部LLMで何とかしてくれ
全部生成AIで何とかしてくれよ
あれじゃないOSSを使うのをやめればいいんじゃない
生成AIで毎回全部生成するようにすればいいんじゃない
必要なものを
それで済んだらそんな楽なんしねえよ
いやーOSSで
サプライチェーンを断ち切って
全部自家生産するようにすればいいんじゃない
でも結局
サプライチェーンを断ち切ったとして外で
外のサプライチェーンにどうしても
生成AIのモデル自体は依存するだろうから
そこが汚染されてやっぱり変なコードを
吐き出すようになったりするんだろうな
やっぱあいつら思考してねえからな
来年は仲良くなろうな
使いどころだと思うんだよ
いろんな人と話してると仲良くなんないと
まずいなって危機感が若干あるよ
1:30:02
使いどころなのは
真理で
使いどころだと思う
自分の方が早く思考できるところに使う理由がないんだよね
それはだから使いどころじゃない
自分が思考しなくていい仕事はやらないようにしてるっていう
本当に必要ないタイプの人材説あるかもね
人材っていうか今の仕事が本当に必要ない
っていう話とかはもちろん
そこはなんか我からは見えんところやから
なんとも言えんけど
結局なんか
今俺が見てるものを一緒に解釈してほしいんだけど
それを食わせる手間が
要は非定型な業務が多すぎるんだよな
定型化できるんだったらやる用はいくらでもあるんだろうけど
非定型業務で使えるから結構難しいところかもね
壁打ち役ぐらいがせいぜい
まずだから定型化するところにすら苦しんでる状況で
なんだろう
なんだかなと思っちゃうんだけど
ちょっとずつ解説あげてこ
俺と一緒に俺も勉強するわ
一人じゃないぞ
いやーむずいな
読んでみて良かった記事だけここに持ってきてるけど
良さそうな記事をピックするために
サマリーを作ってくれたりしたら楽だろうな
とは思うんだよな
あとはケンゴさんから教えてもらった方法だけは
そもそも読むか読まないかの意思決定をするための
サマリーをまず作ってもらう
そうそうそれをしてほしいなと思ってる
それぐらい良いんじゃないかな
AIのサマリーを読んで読んだ気になるのは
多分違うみたいなところがあるのは確かに
まぁね
結構
それでいくと別にいらないかな
まずタイトルでフィルターかけてるんだよ
読む読まないを
タイトルでフィルターかけて
これは読まなくていいタイトルだなってあるじゃん
まぁでも個人的には微妙なやつもある
メディアによるかな
アドベンタカレンダーで
このタイトルだったら薄いやつだな
テクノログ系は
判別できてたりするじゃん
ブリーピングコンピューターとかは
開いてみると聴診記事でしたとかがあったりするから
結構微妙なのがあったりするのは確かにそう
でもそういう時も実は読んでなくて
1:33:00
読んで面白かったからこっちの脳書に持ってくるっていうのは
実は俺はしてなくて
タイトル見て読んでみようと思って開いたら
まずわーって下までとりあえず
流すのよ
面白そうかどうか判断して
脳書にとりあえず置いておくっていうやり方をしてて
後で脳書に溜まったやつを
順番に上から見ていって面白かったやつだけ
収録で読みたいっていうフラグを取って
ワークフロー的に改善する余地がないんだ
そうなのよだから
サマリを作っておいてもらう必要がない
わーって流し読めば終わりだから
それで消化できてるのは無理に活用しなくてもいいかも
これについて来られる
特に俺が工夫しなくても
これについて来られるような生成愛のソリューションがあるんだったら
それはぜひ使いたいと思うんだけど
なるほど
なかなかなさそうだよね
サマリを作ってもらってサマリを読むことすらめんどくさいのよ
それでいくと
わーっと視界の中を流すだけで
面白そうかどうか判別しちゃってるから
人間性の高すぎっていう結論で通させてください
わかんない
AIはまだ矢消しに勝てません
そんなことはないと思うんだけど
どうだったらいいんだろうな
まあまあ
今後の宿題にしましょう
今年はそんな感じですか
ありがとうございました
来年もしくしくとやりましょう
はい
正月から記事を読みましょう
お願いします
来週そこそこ記事あるよね
そうだね
再来週落ち着くかもね
そこでまあまあ考えましょう
再来週にどれだけネタを持ち込めるかが
勝負だね
いっぱい作るか
お願いします
今回はそんな感じでおしまいしましょう
はい
皆さんお休みなさいではなくて
良いお年を
明けましておめでとうございます
今年もありがとうございました
来年もよろしくお願いします
メリークリスマス
おやすみなさい
