アイデアとインサイト

AI ファースト開発、コーディングガードレール、使い捨て前提のアーキテクチャを探求します。

依存関係は環境変数を読める。JavaScriptはそれを許している

Ambient Authorityとは、Node.jsプロセス内のあらゆるコードがファイルシステム、ネットワーク、環境に触れられる状態のことだ。ここでは、lockdown、compartment、明示的なcapabilityの受け渡しによってそれを剥ぎ取る方法を解説する。

一つの侵害された推移的依存関係が、あなたの を外部に漏洩し、ファイルシステムに書き込み、外向きの接続を開くことができる。自分のコードに脆弱性がある必要はない。同じプロセス内に存在するだけで十分だ。JavaScriptでは、デフォルトですべてのモジュールがランタイムの完全な権限を継承する。これがAmbient…

ネットワークの近接性はアイデンティティではない:サービスが環境的権限なしに認証する方法

サービス間の信頼の大半は暗号学的証明ではなく、ネットワーク上の位置関係に基づいている。以下では、ケイパビリティ、相互TLS、SPIFFEを使ってサービスが環境的権限なしに認証する方法と、その実現が予想以上に難しい理由を解説する。

あなたのマイクロサービスはVPCを共有しているため、互いを信頼している。この信頼は環境的権限である。サービスを呼び出す許可は、暗号学的証明ではなく、ネットワークトポロジーによって与えられる。境界を突破した攻撃者は、その権限をすべて相続する。…

依存ライブラリがディスク上の任意のファイルを読める。cap-std は許可を求めさせる

Rust の標準ライブラリはあらゆる依存ライブラリに対して、暗黙的なファイルシステム権限を付与する。cap-std はそれを能力ベースの API に置き換え、コードがパスを開く前にそのアクセス権を証明することを強制する。

依存ツリーのどのクレートも、 を開いたり、 ディレクトリに書き込んだり、プロジェクト内のすべてのファイルを列挙したりできる。Rust の標準ライブラリは許可を求めない。 を呼べるコードなら、オペレーティングシステムが許すあらゆるパスに触れる権限を持つものとして扱う。 cap-std はこの前提を覆す。Rust の…

あなたのサービスは知らぬ間の共犯者:Confused Deputy Attackの仕組み

Confused Deputy Attackは、特権を持つサービスを騙してその権限を悪用させる攻撃です。ここでは、攻撃者が暗黙の信頼をどう突くか、そしてcapability-based securityがなぜ解決策になるかを解説します。

あなたのサービスはクラウドストレージへのAPIキーを持っています。ユーザーがリクエストを送信します。あなたのサービスは忠実にファイルを書き込みます。ファイルはあなたのバケットではなく、攻撃者のバケットに着地し、彼らはあなたのデータを手に入れました。あなたは知らぬ間の共犯者になったのです。 これがconfused…

あなたの権限チェックは嘘をついている

ケイパビリティベースセキュリティは、散在するロールチェックを改ざん不可能な権限トークンで置き換える。コードを読みにくくすることなく TypeScript で実装する方法はこちら。

後になって振り返ると、すべての権限バグは同じ顔をしている。コールスタックの奥深くにある関数が、呼び出し元がすでに をチェックしたと想定している。実際にはチェックされていない。あるいは新しいロールが追加され、47ファイルを横断して を grep し、見落としていないか祈ることになる。…

もしすべての関数が、権限を前提とするのではなく受け取る必要があったら?

ほとんどのコードは ambient authority のもとで動作している。つまり、すべての関数があらゆるリソースに暗黙的にアクセスできる。capability-based security はこのモデルを覆し、関数に明示的でスコープ化された権限を受け取らせる。

あなたの 関数は、たまたま同じプロセス内に存在するという理由だけで、データベース、決済ゲートウェイ、監査ログへのすべてのアクセス権を持っている。攻撃者が 1 つの HTTP ハンドラーに injection bug…

throw するのをやめて、エラーを返すべきか

例外を投げると、型システムから失敗の経路が見えなくなる。明示的なエラー返却がコードをより正直にする理由と、それを苦痛なく導入する方法。

関数のシグネチャは を返すと言っている。嘘だ。実際には を返すか、爆発するかのどちらかだ。型システムはその後者の分岐を知らない。 これが例外ベースのエラーハンドリングの根本的な不誠実さだ。すべての…

Rustのnewtypeで、誤った状態をコンパイル時に無償で表現不能にする

1フィールドのラッパー構造体が、1バイトのオーバーヘッドも増やさずに単位混在バグや型の混同を防ぐ。

のユーザIDを、注文IDを期待する関数に渡しても、Rustは文句を言わない。両方とも だ。コンパイラは同じ型を見ているので、助けてくれない。実行時に気づく。通常は本番環境で、通常は安全だと思っていたリファクタリングの後だ。 これこそが、newtypeが存在する理由、つまり排除すべきバグの類型だ。…

Switch文はコンパイル時にバグを見逃す

TypeScriptのswitch文は、ケースの欠落を黙って許してしまう。以下は、実行時ではなくビルド時に失敗する、網羅性チェック付きのパターンで置き換える方法だ。

あなたはshape型をリファクタリングし、新しいバリアントを追加した。TypeScriptはグリーンのままだった。CIは通過した。デプロイも完了した。そしてユーザーがを返す実行時の分岐に到達し、アプリがプロダクションで例外を投げた。…

コンパイラが不足している状態のケースを捕捉すべきだ。QAチームが見つけるのではなく

マシンに新しい状態を追加するのは簡単だ。すべてのswitch文を更新することを覚えておくのは難しい。TypeScriptに、ケースを忘れたときにコンパイルを拒否させる方法を紹介する。

ステートマシンはきれいに始まる。3つの値、3つのswitch分岐。そしてリトライロジックが4つ目の状態を追加する。部分失敗が5つ目を追加する。reducerは更新したが、ステータスバッジコンポーネント、分析マッパー、エクスポートフォーマッタを見落とした。…