こんばんは、Replay.fm 第52回です。
こんばんは。
はい。3連休真ん中の日に収録してるんで、すごい、個人的にはイマイチね、閉まってない。
そんな、そんな、なんか、そんなことある?
なんか、何だろうな、火曜日、いつも火曜日、儀式収録で、今回ずらしたけど、その、火曜日だと翌日も仕事だし、
日チェンも仕事してたし、なんかその、仕事の脳みそのアリとか。
あー、狭間だね、確かに。
そう、今完全にアイドリングしてるんで、今回3連休から明日も休みで。
うん。
なんか、寝かし、子供寝かしつけ終わる手前までは、なんか全く別のことに思い出させてたから、すごい不思議な感覚で、やってますけど。
まあ、じゃあ今日はね。
そんな気持ちとは裏腹に、記事は多いと。
そうなんだよね。
うん。
いやー、そうなんですよ。やりますか。
やりますか。
14、うん。1個減らしたから14。
あ、そうなんだ。
うん。
はい。
はい。
じゃあ1個目、お願いしようかな。
ブラウザはフロントエンドを何から守っているのか、というスライドですね。これどこで話したスライドなんだろうな。
どこで話したスライドなんだろうね。
なんかまあ、かなるんさんのスライドなんだけど。何なら誰が話してるかすら、そのスライドの中で言及されてなくてさなんだが。
40、あ、フロントエンドカンファレンスか。
あ、なるほどね。
9月6、あ、なるほどね。フロントエンドカンファレンスは北海道があったんですね。
はい。
まあ、そのスライドでございます。
で、中身をあえて1個ずつ紹介する必要はないかなと。
あ、かなるんさんの自己紹介あったね、スライド。だいぶ後ろだな。
すごいな。独特のスタイルだな。
そう、でも俺割とこのスタイル好きだけどね。
あ、そうなんだ。
個人的に。掴みというかね。
まあ、そりゃそうだよね。なんかね、自己紹介にしても。
まあ、よほどこういう人間が喋ってますよっていう前提が大事じゃない限りは別に。
こういう持ってき方のほうがいいかも、確かに。
うん。
まあ、そんな感じなんですけど、中身紹介する必要はないかなとは思っていて。
なんかウェブフロントエンドにおける攻撃の類型のいい整理になってるなというふうに思って。
いや、これフロントエンドカンファレンスで発表されてるっていうので推してすごい納得したわ。
結構さ、めっちゃ丁寧だなと思って、そのスライドが。
そうだね。
多分新卒でウェブアプリかける人でも理解できるぐらいまで結構ブレイクダウンしてくれていて。
ね、一個一個すごい復習、復習というには僕は自分が完璧に把握してるか自信が正直ないっちゃないんだけど。
うん。
ありがたいなと思ってたわ。
いいよね。
うーん、かなり丁寧。
スライド数、それを裏付けるかのようにスライド数は多分これ見れないけど相当な、あ、102枚か。
なんかエスケープとかしたら多分アレのモードになるんでしょうか。
あー、なるほどね。
なんで。
なんなかった。
いや、一回ね、一回左上から戻ってMy Driveに行くと閲覧した、あれなんていうの。
左、なんか普通にプレゼンテーションモードみたいな感じでしか見えない。
いや俺もね、プレゼンテーションモードから抜け出すのに、あの左上にさ、ちょっとリロードしてみよう。
なんで出てこないの。
なんで出てこないの。
いけるんだけど。
なんかあれかな、さっきのが悪さしてるのか。
俺なんか一番上にヘッダー行が、ヘッダーがあって、そっからMy Driveに戻ることができて。
My Drive開いてみるわ。My Drive開くとなんか閲覧したファイルもこうやってると思う。
なるほどね。
見えちゃいけないものがなければ。
うん。
あー、はいはいはい。
あー、そりゃそうだね。
なるほどね。
これそのまま、うん、あ、そうそうそうそう。
そうするとなんか全部見えるから、その非表示スライドとかも見える。
あー。
おもろい。
おもろい。
おもろい、マジでおもろい。EDFにしてなんか見直せばよかったのに。
ほんとだね。はい。
まあ。
よかったですね。
うん、よかった。
なんか、メモってないけど、なんか満遍なくよかったんだよな。
これがめっちゃ勉強になったっていうか。
そうそうそうそう。
ほんと全体的に勉強になったなっていうか。
まあなんか別に知ってるところは飛ばしていいかなと思うんだけど、なんか。
うんうんうん。
うん。
あ、ちょっとこれなんか、まあ自信ないなっていうところさ、全部。
うんうん。
あの、見かけたら見ていくぐらいで多分十分だと思うし。
うん。
うん。
あとはなんか、これ系の資料毎回読む度に思うけど、無理よな、こんななんか。
うん。
その、例えばじゃあフロントエンドカンファレンスに参加してるWebフロントエンドのガチ勢がこれを全部意識して開発しきれるかとかやっぱ難しいというか。
いやー、Webの面白さであり、カオス味があるなっていう気持ちもあります。
平たい感想です。
いつも思うんだよな。
うん。
うん。
だからもう持ち屋持ち屋じゃないと、持ち屋持ち屋でなんか分業しないとどうにもならん気がする。
でも、どうなんだろうね。
なんか。
まあでも確かになー、フロントエンドの開発者向けではあるよなー。
サイトアイソレーションの話とか出てないもんね。
覚えてないなー。
出てなかった気がするんだよ。
サイトアイソレーションの話は出てない。
全部説明しきれんよなー。
うーん。
まあでもなんかこういうの知ってくっていうのは大事だろうな、別に。
自分の口で覚えて説明できるレベルまで行けずと思う。
うんうんうん。
だからこういうの考えると、いやーどうなんだろうなー、まあ分かんないけどその、
まあバックエンドだとさ、そのオレオレフレイマークで、今の時代はさすがにないのかもしれないけど、
昔だったらオレオレフレイマーク使って、なんかしょうもない脆弱性めっちゃ作り込むみたいなやつとか、
ところに対し、反省に対して、まあきちんとユーザーが多いコミュニティーのデカいフレイマーク使ってればそんなおかしいこと起きないでしょみたいな話と同じように。
いやーでもフロントエンドどうなんだろうなー。
フロントエンドもある程度乗っかっとけば、この辺安全だよねみたいな。
いやー、ちょっとなんか喋ってて思ったけどそんなことないなって気持ちになってきたから、何でもないです。
そこに難しさあるよな。
はい。
次行きますか。
行きますか。
はい。
まあそんな感じで、みなさん読んでみてください。
お。
えーっと、GDNETの記事で、クロームアンドロイド売却は回避、米連邦地裁がGoogleに是正命令っていう記事ですね。
よかったねー。
よかったのこれ。
うーん、まあよかったの…。
まあ分かんない。僕ら目線で言われるか。
なんか出したんですよ、命令。
えーっと、あのー、あまり書いてないな。
えーっと、販売は、販売じゃない、売却はしなくていいよっていうところで、
まあ、かつその売却を要求するには行き過ぎだよねっていう判決になったんだけど、一方で何もしなくていいってわけじゃなくて、
えーっと、あれか、一つはGoogleをデフォルトの検索エンジンにするっていう契約を各ブラウザーとか端末メーカーと結んでいたっていうところに対して、
まあそれを禁止するっていう話かな。
なんで、えー、まあアップルとかそうなんか、サファリとかで開いたらGoogle検索ページのトップに行く、代わりにGoogleからめっちゃお金払うみたいなのは禁止するっていう風になったって感じかな。
で、なんかその契約内容が配達的契約はダメっていう感じだから、まあ非配達的な契約ならいいよっていう言い方してるけど、
うん、まあ非配達的な契約ってどういう感じなんだろう、なんか現状の契約ちょっと僕把握できてなかったから。
まあ例えばだけど、その初期設定時にさ、選べるとか。
あー、なるほどね。
選べる中に多分なんか、えーっと、例えばBing、Yahoo、Googleみたいな感じで並べられるようにするとかはありなんだろうね。
なるほどね。
で、それぞれがお金払うとか。
うんうんうん。一番上に表示するためにたくさんお金払うとかだったらまあいいのかなって感じですね。
あー、どうなんだろうね。なんかそこはちょっと分からんけど。
配達的な、これもなんかその、今後Googleがどう振る舞うかでどういう塩梅になるかって感じなのかな。
で、あともう一つが、あれだね、競合他社に一部の検索データを共有するっていうのを明示したって言ってて、
具体的にはユーザーの操作履歴や検索インデックスの一部が対象となる。
正しい広告関連のデータについて共有の義務は課されなかったっていう風な感じがあったって。
なんでユーザーの操作履歴をさ、Googleの操作に出すことをさ、そこに決められなきゃ。
それは本当にそうだし、Googleのユーザー目線はたまたまじゃないよね。
そうだよね。分からんけど、あえてGoogleを使ってる人間もいるわけでしょ。
まあそうかもね。Googleのプラポリと利用契約に同意してGoogleを操作していたら、なぜかそれは別の会社に。
だからどうなるんだろうね。
操作履歴って何だろうね。
うーん。
だとその、なんだろうな。
どれぐらいの抽象度というか、この人がこういう操作をしたまで取られるのか、
もしくは、何だろう、100万人ユーザーがいて、
何なんだろうな、ある種匿名化じゃないけど、全員がこういう動きをしたよみたいな話なのか。
まあでもこの記事にも書いてるけど、なんか実際にどうするかっていうのはまだ不透明っていう話をしてるんで、
だからどうなんでしょうっていう。
まあそうだね。
まあまあまあまあ、
市場的にはGoogleの勝利でGoogleの株価は8%給投したらしいです。
すごいな。
まあそれはこれからなんじゃない、正直。
メルカリの評価とかもそうなんだけどさ、そこの権威づけって本当に機能するのかな、まともなのかなって思ってて。
いやなんかこういう使い方をし始めた瞬間に、なんか結構壊れ始める感じがしてて。
バランスが、パワーバランスがさ、なんかおかしくなるというか。
うんうんうんうん。
めっちゃ極端なこと言うと、例えばその評価を悪くするぞっていう事業者からの。
例えばね。
例とかだよね。
まあでもタイミーの場合は相互評価みたいなところはある気がするけどな。
まあそこの堅実性をどう保つかは、まあちょっと設計の見せどころというかそういうのが結構なんだよね。
まあまあ言わんとすることはわかったわ。
まあ用意あるわと思います。
気になる人はリンクから飛んで読んでください。
次行きますか。
アクセスボウガイドトゥダブルシーエイティースリーエイト
アーティンティケーションウィザードブラストレーション
というオーステロンですね。
とりあえずちょっと僕、なんかサマリーしか読んでないんだけど。
お願いしていいですか。
いいですよ。
まあ詰まるところ認証方法に関するアクセシビリティの話で
具体的にそのダブルシーエイティーっていう
ちょっとアクセシビリティの本読んだのに思い出せないんですけど
まあそのアクセシビリティを語るにおいて標準みたいなものがあって
それにその認証に関連するダブルシーエイティーっていうのが追加されたのかな。
まあ元かったのか追加されたのか忘れたんですけど
リンク貼ってあるんですけど、そこにはこういうふうにあるべき
これは避けるべきみたいな具体的な言及があるんですけど
その辺に基づいて、こういう認証方法はアクセシビリティ観点ではバッドパターンですよ。
じゃあどうすればいいのみたいなところを割と丁寧に解説してくれている記事です。
日本語訳の貼り付けなんですけど
リファレンスの方では認証プロセスのステップにおいて
いくつか条件があるんですけど、その条件のうち一つを満たしてない場合は
認知機能テストっていうのをする必要ないというか、しちゃいけないって感じなんじゃないかなという感じで書いてあって
認知機能テストっていうのが結構この記事で触れられてるんですけど
これ何かっていうと人間の
これどういう意味なんだろうな、例えば具体で話した方が意味付けやすいと思います。
IDパスワード認証みたいなのがあったときにそれをパスワードマネージャーの自動入力とかじゃなくて
自分で覚えているIDとパスワードを手打ちするパターンっていうのは
その人の記憶力をテストしていることになるので、ここで言うと認知テストに当たりますよとか
あとは覚えるケースじゃなくて、どっかに書いてあるものを書き写すっていう行為
例えば2FAのコードでスマートフォンのOTPで6桁の数字があって
それを見てパソコン上でポチポチ手打ちするっていうのも認知テストになりますっていうところとか
あとはこういうのをパスワードマネージャーで自動入力って場合は認知テストにならない
記憶する必要もないし、転記する必要もないんだけど
それが例えばたまにあるコピペをブロックしているようなサイトとかがあると
もう少なくとも転記が要求されちゃうんで、これはもう漏れなく認知テストになってしまいますよって話
またそのキャプチャー、画像のキャプチャーみたいな
キャプチャー認証の画像を選ぶ方式とかは、これは認知テストなんですよって話をしていて
まず写真のものを認識しなきゃいけないっていう部分があったりとか
ものによっては頭を使って解かなきゃいけないクイズみたいなのがある時点で
認知テストに含まれますっていう話が書いてあって
笑ったのは日にこを込めてキャプチャーの例を貼っていて
どっかのカンファレンスでこのキャプチャーがあったんだよねみたいな
シェアされたやつをつけてるんですけど
あと参考画像でキャベツの画像があって
このキャベツより小さいものの写真を選んでくださいみたいなキャプチャーの例があって
これとかまずキャベツを認識しなきゃいけないって話もあるし
そのキャベツより小さいかどうかっていうクイズを解かなきゃいけないっていう観点で
これアクセシビティガイドの観点においては
結構クリアすべき要求は満たせてないっていう話がありますっていうところですね
具体的にどうすればクリアできるのっていうところは
まずパスアドレス パスキー認証とかでポチポチって押したら認証できるっていうのは
認知テストがないのでOKだよとか
認知テストっていうのはさ 認知機能テストっていうのはまず何なんだ?ちゃんと理解できない?
認知機能テストそうだね 辛いツッコミを置いてありました
最初読みながら何なの?っていうのがあるけど
記事中で振られてたのは
あれかな 認知周りの障害がある人にとってそれは衝撃になるよみたいな話があって
アクセシビティガイド 認知機能テスト
認知機能テストとは何でしょうか
実際にユーザーが次のいずれかを実行することを要求するテストです
まず情報を記憶するか情報を転記するかパズルを解くかの3つが例にある
さっきのまんまだに記憶するか転記するかパスアドレスにするはパスキーに限らず
マジックリンクのクリックとかも今の3つに引っかからないのかな
記憶する必要もないし転記する必要もないしパズルを解く必要もない
メールが来てクリックしてOKなのでアクセシビティ観点ではクリアだし
パスキーでポチポチって押したらログインできるというのもOK
また場合によってはMFAでそのキャプチャ認証を求めるとか
2FAの転記を求めるパターンとかはそこの部分をパスキーに置き換えて
認知機能テストを求めないようにするとかそういうのをやったほうがいいなとか
またキャプチャ認証を導入する場合はこの記憶する転記する
パズルを解くという観点に画像を選ぶ方式だと引っかかっちゃうんで
例えばGoogleキャプチャのV3とかだったらそのスコアリングで
パズルを解かせずに認証を導通するというのができるので
そういうものを使うことを検討しましょうみたいな話とか
あとは多分これをクリアしたらOKってわけじゃないけど
パスワードマネージャーによる自動入力っていうのを
許可しない設定というのはやめようねって書いてあって
これを許可しない設定にした途端に
記憶するもしくは転記するっていうのを求めることになっちゃうんで
これをちゃんとやりましょうっていうことを書いてあったという感じですね
書いてありましたね 記事の中に読み落としてたときに
なんか割とこの視点なかったしこのガイドラインも知らなかったので
ちょっと恥ずかしながら勉強になりましたっていう気持ちで
確かになっていう ブログとか書いてあるんですけど
Webアクセシビティの本を1ヶ月か2ヶ月前くらい読んだんですけど
例えば何かのタスクを解くときにすぐにパニック状態に落ちちゃうような
障害を持つ人にとってこういうUIとかこういうのってストレスだよねとか
あとは一つのタスクに集中できないみたいな
人にとってこういうのってダメやでみたいなところをすごい細かに書いてあって
何だろうな 視覚障害とか聴覚障害とか
あとは何だろうな 指がうまく動かなくてとか
そういうのはすごい知ってたし想像もできたしできてたんだけど
語体満足なんだけど認知機能に障害があるみたいなところのパターンを
正直あんまり勉強できてなかったのですごい学びがあったなと思ったんですけど
認証部分においても言われてみれば
これもなんかこの記事の1から10までそうだよねっていう気持ちでは
読んでいたし あとはその認証って多分避けらんないじゃないですか
大体手段がないというか何かサービスを使うときに通らざるを得ないっていう部分が
アクセシビティを担保できてないってなると
もうその時点でそのユーザーは落とさざるを得ないっていう部分を考えると
結構ちゃんと真面目に考えないといけない領域だなっていうのを思ったって感じですね
なるほど
なんか結構OSとかブラウザ側のUIに体験を統合できるって意味だとか
ASCIIは言われていいのかな一瞬思ったんだけど
なんか要はなんて言ったらいいんだろうな
コンテンツを作る側でめちゃくちゃアクセシビリティに配慮せんでも
そっち側に寄せてあげることでデフォルトでハンダリングしてくれるみたいな感じになるかなと思ったんだけど
でもサードパートのASCIIプロバイダーとかどうなのかな
鍵がどこに入ってるかわかんねえみたいな問題とかって
私なんか何とかなるのかな
そうだね
じゃあそこ
PASCII自体のアクセシビリティみたいなのって
どっかで当然論じられてそうな気はするけど
でも手前って感じなんだよな
普通の頭のいいユーザーというか
僕らレベルであってもたまになんかこれダメやんとかなってるから
ちょっと先は流そうかもね
でもその寄せるって観点は確かにな
各事業者が
そうだねそれできたらめっちゃいい
PASCIIに
フィッシングレジェンスな印象保護みたいな
もうこれに選択肢ないよねって寄せていって
PASCII側もPASCII側で
鍵のプロバイダーの人たちはこのアクセシビリティも加味しつつ
改善されてくってなると思う
ウィンウィンな世界になる
と思いました
だから明らかに私がイレギュラーっていう変わってる側の
関係だから
こういう世界にしたいみたいな固まったタイミングでやっぱり手を動かす人欲しいというか
まあでも難しいな でも最初から入ってて欲しいな
結局なんかその開発リソース
要はなんて言ったらいいんだろうな
プライバシーバイデザインはいいとして 例えばだけど
私がメルカリでやってたので言うと
PIA いらなくなったPIAを削除して回るような仕組みを作りましょう
みたいな話になった時に やっぱいるのよソフトエンジニアが
いるね
スマートHRが今どういう開発体制になってて どういうフェーズなのか全然分かんないけど
そこに関して その領域に関して
そこは一個苦労しそうだなと思って
今の段階で何か言えるわけではないんだけど
どこまでどうやって踏み込んでいくのか楽しみ
気持ちを待ちしてます
超楽しみになりました
こういう先行事例みたいなのいいな
この課題に取り組みますよ
ある程度そこを明文化して出してるっていうのはかなり好感度高いな
しかも大概的に
めっちゃいいなと楽しみにしてます
ありがとうございます
クッキーケイオス How to bypass host and secure cookie prefix
という記事でございますが
これ実は読んでない 長谷川さんの
ホストを見ただけなんだけど
これ以上のまとめは我々にはできないし そんなに長さもない
多分そういうことなんだけど
JSから生UTF-8を含むクッキーを設定すると サーバー側で本来のクッキーと区別がつかず
JSで生成された側が優先的に使われる
生UTF-8を含むクッキーを設定すると
サーバー側では本来のクッキーと区別がつかず JSで生成された側が優先的に使われる
ただそれだけ
ちょっと頭おかしくなっちゃうなと
一応読んだけど全く同じ感想
頭おかしくなる
むずいよ
バックエンドの実装は
djangoとasp.netが
特定のサーバーサイドフレームワークが
ガイドしそうって感じか
みんなdjangoは仕様ですみたいな感じで書いてる
脆弱性方向警戒に対して
ドキュメントでこういう風に書いてる
信頼できないサブドメインからのクッキーを許可すると 攻撃に対して脆弱性になるため警告してる
今回攻撃はその前提条件だから脆弱性とはしない
みんなしますよって
いやー脆いな
よう見つけられるような
今日の1個目の記事と結構同じ感想という それよりもって感じやな
これどうやって見つけたんだろうね ファッシングかな
あー確かにね その発想のこと
でもなんかキーのRFCから拾ってた感じっぽいな
わからんけど
解釈違い系
しんどいし あるんだろうな
同じポーツ映画のhttp1.1脆弱話も
似たような話があったじゃないですか リレーしていく過程で
解釈違いでする
リクエストスマグネがね
頭おかしくなっちゃいますね
そんな感じの面白記事でございました
サクサクいきましょう
いやーこれ重いな
NXの攻撃から学べること ジャックさんのブログです
いやーこれね
なんともなんともって感じなんですよ
先週確かちょっと話したけど NXっていうめっちゃ有名な
NPMパッケージが侵害されて 結構な被害が出たよって話で
ついでにもう一個Wizの
これなんかキャンペーンだったらしいんだけど 解説した記事
あるんでそっちも一緒に紹介しちゃいたいんだけど
あれか なんかの記事で
1700人とかだっけ 結構な規模に
被害が及んでるんだけど
詳しいレポートはWizのほうを多分読むとよくて
先週も話したけど脆弱性のあるワークフロー
具体的なシェルインジェクションで PRのタイトルを経由してシェルインジェクションできる
ワークフローがあって それ経由でNPMトークン盗まれて
これか
脆弱じゃない
マリシアスなコードを仕込んだNXをNPMパブリッシュして それを実行して
ユーザーから山ほどクレデンシャルを引っこ抜いて それを使ってさらに
いろんなGitHubの環境を侵害して
っていう感じで 文字通りサプライチェーンで繋がっていったみたいな
感じの攻撃で なんかJackさんの攻撃記事を見て
知らなかったんだけど この初手のPR
AIが作ったみたいな
AIが作ってたらしくて 結構それにみんな着目してるけど
そしたらそこじゃないよ みたいな感じのことを言ってて
他なんかその AI騒ぎがあったんだって
知らなかったんですけど 僕も全く同意というか
脆弱性自体は別に AI関係ない
AIだから攻撃ができたものでは全くないっていうのもその通りだし
一個一個Jackさんの記事は紐解いて言ってくれてるとか
入り口ここでこういう対策してばよかったよとか
盗んだものは何かみたいな話とか それで何ができちゃうのかみたいな話とか
あとはNPMトークン そうね だからすごい
丁寧に書いてくれてるんですよね
パッケージをホスティングする人たちはみんなこれ読むと 何をすべきかっていうのは結構
知名だし理解できるんじゃないかな あと被害者リストみたいなのがあって
これはちょっと知らなかったんですけど
NX使ってる人は見ておくと良さそう
あれかNPM NXマリシアスのコードを実行した環境から情報を引き抜く方法として
その情報を丸っとまとめてGitHub上にシンギュラリティリプションっていう名前で
パブリックリプションとして公開するみたいな手法を取ってるっぽくて
自分のアカウントにこの名前が入ってる人が万が一いたら早急にどうにかしてください
たぶんGitHubが対応してると思うんだけど
おそらく300 あでもぼちぼちか
これ908個か そうですね
はいって感じですね まあしんどいですね
まあちょっとやってらんないよな
これも
いやーなんかもうちょっとさ
いやー
なんか
アクション いやーでもなんかGitHub
GitHubアクション自体がさ結構放置されてるけど
なんかその意外とさ
普通にしんどくないこれ
安全に実装するのもそうだし
ちょっとジャックさん記事をめっちゃちゃんと読めてないけど
CodeQLの話が出てたと思ってて
そうだね CodeQLがそのいわゆるアクションリントって出してくれて
アクションリントは機械的にシェルインジェクションのリントをかけてくれる
CodeQLもたぶん同じようなことできるはずで
たぶんこれサポートサイトの今年とかだと思うんだけど
なかなか
セキュアはデフォルトじゃないけど
今はオプトインしないと言っても使えない
だからパブリックリポジトリでパッケージホスティングしてる人は
CodeQL有効にしてやればいいと思うんだけど
それをしてないリポジトリでユーザーが多いリポジトリってのも全然あると思うから
そこは引き続きしんどいよねと思うし
しんどいね
どこで防ぐかだよな
垂れ場で言うと
いやでもな
例えばNPMは最近OIDC連携でトークンレスでパブリックできるようになったけど
でもワークフロー乗っ取られたらアウトだよねって言ってんのは
映像化はできずとも緩和にしかならないよねだし
ワークフローの脆弱性はCodeQLにしてなかったらアウトだよねだし
でもNPMまで行っちゃったら正直どうしようもないから
2つだよね防げても
ワークフロー
脆弱なワークフローを作らずに済むっていうところだよな
これシークレッツNPMトークン入ってたのかな
もしかしたらこのワークフローを乗っ取った時に
シークレッツは盗めるけどNPMのパブリッシュまではできないであれば
NPMパブリッシュをOIDC連携してれば防げたっていう話になるかもねもしかしたら
ちょっと見てないなこれか
これアクションリンと回してればさ防げたんだけど
実際のコード見てないか分かんないけど基本は防げるんじゃないかな大半のケースは
PRタイトルをエスケープせずに延分に突っ込ませていいっていうケースは防げるはず
全然振り込まないな
これVizのほう見ればあるかもね
Vizのほうにコードは書いてあるか
コードはないなマリシアさんコードの解説とかしてくれてるんだけど
気になるなめっちゃ気になる
プレイエクストターゲットそうだよね
ちょっと気になるねアクションリンと入れてたらよかった
アクションリンとの話は
スクリプトインジェクションというかコマンドインジェクション的なやつは多分刺さらんよね
刺さらんというか見つけてくれるよね
見つけてくる基本的に見つけてくる
だから多分セゲトンのほうが思ってる
面白いねジャックさんの最後の記事でこの対策すればいいよってやつ
箇条書きで書いてくるこれAIに出させたやつって言ってるから
AI使えば安全な対策は誰でも出せるしそれをやればいいんだよっていう感じで
まあ確かに
いやーTシェアアクションズに引き続き
あと今日は別の記事でもね多分
いやまあそうね別の記事
いやでもそうねなんかサプライチェーン関連とか
GitHubアクションズ経由のサプライチェーン関連って気がするな
なんで今まで狙われなかったんだろう
あれかな俺が知らないだけかな
いやーなんかでも別に今までないわけないと思うからさ
少なくともこの1年間でさ記事を追ってきて
もうなんかこの可能性としてはずっと語られてきたやつというか
そうだね
シークレット参照できてるとかシェルインジェクション
でその対策みたいなのやってるところとやってないところがあって
でも別に実際のインシートはないみたいなところが
今年Tシェアアクションズが来てこいつが来て
狙い目だと思われ始めたのか
なんか
なんか
わかんないね
なんか
いやー
まあこればっかりはマジわかんねえな
まあパブリック中から
パッケージ出してる人はみんな読んでほしいね
そういう願いを感じるわ個人的にこのブログからは
なんかAIがプロジェクト立てて侵害したで終わらせるにはちょっと浅すぎるというか
もうちょっとだいぶ身近なトピックだよねっていう
認識してほしいなって気はしますね
自分も含め
次の記事がめっちゃ綺麗に繋がってる
そうだね
はい
読もうかな
NPM Trusted PublishingでOIDCを使ってトークンレスでCIからNPMパッケージを公開する
AZさんのブログの記事ですね
もう話したと言っても過言ではないですけど
タイトルのとおりのやつです
これなんかこのリリースを紹介したけど
週刊先生週刊忘れてた
そうだね
ただなぜその上でこの記事を紹介したかったかっていうと結構
確かにってなったのは僕持ってなかったんで
なるほどってなったんですけど
これ実際にやる時に
僕と違うなって思ったのは2つで
1つは管理してるパッケージの数がめっちゃ多い人とか
あとそのモノリポイをしてる人は
これこの記事読むといいんじゃないかなと思ってて
AZさんちょっと何個か数えてないですけど
途中でいろいろなんか自動化とかリリースフローの工夫とか
めちゃくちゃちゃんとまとめてくれてるんですけど
その中の工夫の一つに
OIDC連携をできてないリポジトリ一覧っていうのを
自動でGitHubの一周
プルリクエストかプルエクストにコメントで出すようにしてて
そいつらを一個一個作業しなきゃいけないわけじゃないですか
NPM側のOIDCの設定ってAPIとかないから
ブラウザ開いて正しい値を入れてってやらなきゃいけないんだけど
そこでミスると事故になるよねっていうので
その辺にこのリポジトリの設定にはこの値を入れるっていうのを
ワンパスアウトとかで事前にバーって入力して自動化して
ポチポチ押してったら機械的に設定できるようにするみたいな
自動化スクリプトみたいなのとかを書いてて
めちゃくちゃなるほどなというか
僕はせいぜい5個ぐらいなんですけど
こんだけ20個30個あるんだったら確かに
こういうのないとやらないよねとか
またそのモノリポ構成の時にはこういう風にやるとうまくいくみたいなことが書いてあって
これはかなりいい知見だなって思って
そうねモノリポでそうか
リリースする時に今までは一つのトークンで全部リリースできたけど
そのOIDCごとに分けるんだったらどうするんだって話とか
エンパイロメントぐらいじゃない?分けようと思ったら
NPM何設定すんだっけな
リポ単位だったらか
ワークフローの名前まではいけるのかな
そこ分けるのかどうかとかは
そうだねワークフローレフとかは入ってくるからワークフローの名前はいける
エンバイロメントも入ってくるからエンバイロメントもいける
ブランチもいけるねやろうと思う
そうだねただNPM側はどんぐらい自由度とか
フレームを何ていうか何を見てくれるか
エンバイロメントネームがいけるんだ
フレームとかはね
ワークフローレフと
ワークフローレフもさ
2つあるじゃん
なんでこんなクソっぽいトークをしてるのかわからない
詳しいが言えない
ワークフローレフって2つあって
ジョブワークフローレフとワークフローレフがある
ワークフローレフの方じゃないかな
ギター部から降ってくるジョットに入ってる
ペイロードの話だよね
どれだこれだ
ワークフローレフと
見つけたか
片方のプレイン
これが一番
ワークフローレフ
この辺多分NPMに関しては隠蔽されてるんじゃないかな
どっち見てるのかな
ワークフローからワークフロー
ワークフローからワークフローコールしてる
それぞれ3つのものが入る
どっちがどっちだかちょっと忘れちゃったんだけど
ワークフローレフ
どうなんでしょう
エンバイロメントでやるほうが確実
ワークフローはプッシュまでされちゃったら
エンバイロメントもそうだけど
エンバイロメントはブランチルール
ブランチプロテクションとかいろいろ突っ込めるから
個人的にエンバイロメントでやるほうが
でもワークフローファイルネーム必須だねNPMは
使わないって言ってはなさそうだね
まあまあまあ
なんですごい
とてもなんていうか
ある種のオットフォームにあるんですけど
これが必要な人っていうのは必ずいると思ったので
ぜひ読んでみてください
普通に勉強になるしね
リリース前とかは別にモネレポ数多いとかにかけ出す
なるほどねって言うとか
あずさん丁寧だなって見てました
ありがとうございます
これ記事じゃなくてページなんですけど
無理やり今日読む記事に
日付に設定して持ってきたんですけど
何を紹介したいかというと
セールスロフトトラストポータルっていう
どこだっけな
ごめんなさいこれは記事でした
これは記事というかアナウンスで
セールスロフトっていう
セールスロフトのアナウンスを引っ張ってます
これ何のアナウンスかっていう前段から
いろいろちょっと話させてほしいんですけど
セールスロフトのドリフトっていう製品があって
このドリフトっていう製品は何かっていうと
セールスフォースのインテグレーション的な
サービスになっていて
これは誰が使うかというと
セールスフォースを使ってる企業が
ドリフトと契約して
ドリフト側にセールスフォースの権限っていうのを
オース認証を通じて渡して使うっていうものになってるんですけど
このドリフト側が侵害されちゃって
セールスフォースのオーストークンがそこから盗まれて
さらにそこから
300企業ぐらいが
そのオーストークンの悪用で侵害
セールスフォースインスタンスに
インスタンスって表現は確かかないけど
セールスフォース環境に侵害されてるっていう
結構そういうインシデントが起きてます
この話題自体は多分2週間前ぐらいから
出てたんですけど
いろいろサミナルに情報出てたんで
まだ
327人って数を思うと
効率的にやれちゃうならどんどんやるよなっていうのを今後も続くと思って
こうやっていかないといけないかもなって気はするな
そうだね1個目はパイパイ攻撃したやつ気づいて報告して収束したんだけど
もうちょっと調べると同じような攻撃のされ方をされて成功してるユーザーがめっちゃいるじゃんみたいになって
調査したら大規模でしたって話っぽいね
シンギラリティー攻撃NXのやつも触れないという
それは多分無関係っていう感じか
この3300漏れてるから多分今週来週やばいんじゃないかなって気がするんだよな
誰のが盗まれたかは大事だと思うんだけど
でもTGアクションズと一緒で2ホップ3ホップいって
どこまでいけるか正直予想がつかないから
皆さんも気を付けくださいパッケージを使うっていう意味でも気を付けてほしいし
パッケージをパブリッシュするというかワークフロー自体の脆弱性みたいなのもきちんと
パブリックはCodeQL使ってもらってプライベートはCodeQLが有用なんで
アクションリントJJリントを使って
あとはAIに聞いてどうかしましょうって感じですね
厳しいですね
直近仕事でこの辺向き合ってどうですか
向き合っておいてよかったなって気持ちですね
直近もそうだし2年前くらいからなんだかんだGitHub Actionsの改善を
なんだかんだずっとやってるけど
やる前めっちゃ危機感を持ってたかとか知識持ってたかというと
全くそうじゃないから
そこに難しさがあるなって個人的には思ってるな
CICDって僕らみたいに改善とか気を配って脅威をリサーチして
対策を重ねていくみたいな立場に立ってると結構詳しくなっていくし
一目でやばい奴わかるようになってくるんだけど
僕がソフトエンジニア中心生活だった時に
同じレベルでキャッチアップできたかというと全然そうじゃなくて
実態としてリポジトリ作って一番初期の設定で
初めて触るもの
でも触る時にめっちゃ詳しいわけじゃないから
やっぱ既存のやつ真似して
時にはちょっと部分的にピペして動いた
じゃあ開発しようみたいになることもあるし
それ以降って触るタイミングで壊れるタイミングぐらいしかなくて
全然詳しくなっていかないし
セキュリティ面もキャッチしてないとなかなか掴めないし
また不合理だなって思うのは
ギターバクションズの脆弱なワークフローを見ていった時に
その対策って普通にワークフローを書いてて
自然に満たされることってほとんどないと思ってて
どちらかというとかなりめんどくさいものが多い
シェルインジェクションとかは
変数埋め込みでハードコードしたほうが絶対楽だし
わざわざ演舞に通すなんて知識がないと絶対にやらないんだろうし
サードパーティーのハッシュ固定なんかもやんないじゃないですか
めんどくさすぎるし
あっとV1で済ますみたいなことだし
そこの不合理さもあるなと思うし
これが仕事じゃなくて趣味でNPMパッケージ書いてますみたいな
ところとかなってくると
ユーザーコミュニティがめっちゃでかければ
みんな指摘してくれるかもしれないけど
そうじゃないでもみんな使ってるみたいな
みたいなものとかが脆弱なものになってるっていうのは
なんかあんまり責められないというか
物によっては何年放置されてますみたいなのもおそらくあるわけで
それがなんか実はある分野においてみんな使ってて
有名ライブラリ5個ぐらいネストしていくとこそこれにたどり着いちゃうとか
全然あることだし
いやーなんかやってらんねぇよな
なんかもう開発者心の事情動力ではどうにもならんっていう前提で
いろいろ変えていくしかない気はしてて
そういう意味では先週話したイミュータブルリリースとか
またNPMのYDC連携とか
パイパイのフレイアカウントのメール未確認するとか
あれとかめっちゃいいなと思うし
あとピンニングラインフォースとかね
あれが真に働く世界になったら結構救えるものもある
そうだね
だからもう本当にここまで攻撃が流行ってきちゃうと
待ってらんねぇみたいな世界線も全然ある気はしてて
使ってるやつがピンしてくれれば待てないみたいな
そうなると自ずと淘汰されてくるみたいな世界線はあるかもね
何せなんか
そうだね
OSS開発者みんなに気をつけてくださいっていうのは結構厳しいものがあるよな
っていう気持ちですね
あとは
自分の会社のメンバーが被害を受けないようにって思うとやっぱもう
EDRとかになってくるのかなっていう
でも銀の段階じゃねぇしなみたいな気持ち
そんな気持ちですか
EDRって言ってんのかな
あれごめんちょっと待って
まぁ今回のケースは
企業が被害っていうよりは個々人のトークンが詰まったって話
だからこれが仕事の
ワークフローの改ざんなのか注入なのか
改ざんとかプッシュだから
会社でパブリックリポジトリを展開しててみたいなケースだったら
被害の範囲に入り得るけど
ほとんどそうじゃない気がするから
これがどう波及して僕らとか会社に影響を出得るかというと
普通に何かのパッケージが侵害されて
手元にあるビームインストールを叩いたら
そいつが落ちてきて
何かをフックにマリシアスのコードが走るとかかなって気がする
あとはどっかとかだったら悪意のあるイメージが
手元に落ちてきてとかもあると思うし
何かまずいものが本来信頼できるはずのパッケージに混ざってきて
降ってくるみたいなのが第一なんじゃないかなって気がする
ワークフロー侵害されないって意味だったら
それは守る手段があるし
僕らの場合は結構やれてると思うから
自分たちでコントロールの余地があるんだけど
どっちかというと自分たちが使ってるものが侵害を受けるっていう方に対しては
EDRって言葉を出したって感じかな
あとあれかサードパティアクションズとかは
EDRとかじゃなくてアクションズの環境の話だから
そっちはピンニングとかいろいろ合わせる
結局そこの管理者のアカウントが乗っ取られてみたいなところまで
もうどうしようもないもんな
あとあれかな
社員が個人で出してるOSSのワークフローに脆弱性があって
そこにめっちゃ強いパッドがあるとかはしんどいかもね
そのパッドになぜかうちのオルグの権限が付いたとか
最悪だね
まあそうね丁寧に考えると結構穴はあるかもね
パッドとかはオルグに関しては中央管理できるからとか
クラシックトークンじゃなければ大丈夫とか
大丈夫っていうかコントロールできるとかいろいろあるけど
まあまあまあそうですね
でも一番リアルにすぐ起きるだろうなって思うのは
脆弱なパッケージを手元に落とすパターンだと思うな
アタックベクターはいっぱいあるけど