Goのパーサー見落としがちなセキュリティ上の危険

記事 示す。internal model API 直接 公開 セキュリティ footgun。
私 見た サイト hack。secrets 誤って 公開 例。
API 公開 internal models refactor 難しい 例。
layer separation なし maintain 難しい。セキュリティ 問題 多。
skip writing lines extra boilerplate model map DTOs。
layer separation 欠如 長期 問題。start 時 overengineering 違う。

Go JSON parser case-insensitive key handling。
XML parser malleability。
classic 例 differential-prone behavior。
記事 ultimate point。
parser 定義 役立つ。parser recognizer。
recognizers 違い exploit 可能。
bug 必要 なし。difference 必要。
footgun 理由。

私 dayjob 見る。different narrow structs library 統合。supporting code copy structs TON。
問題 それ 解決？
entire internal world outside expose？
different views same entities critical。
PII public endpoints return easy。internal process 必要。

layer separation 欠如 長期 問題。start 時 overengineering 違う。私 同意。
strong layering interfaces 信じる。しかし struct annotation based parsing 信じない。
typically DTOs around code pass 違う。
take struct。code poke places actual data structures。
specification input structure struct 存在 違う。parsing code consequence 存在。
internet driven assume everybody novice。real shame。

Go JSON parser case-insensitive key handling。
explicit decision convenience。
Go struct fields Capitalized export。JSON lower case convention follow tendency。

Sorry。English not native language。
not mean you novice。
take struct。immediately code poke appropriate places actual data structures。
specification input structure struct 存在 違う。parsing code consequence 存在。
define inputs separately internal data storage。違う。
specification input structure struct 存在 違う。parsing code consequence 存在。
example give？

convenient 良い idea 違う！
not what Go other parsers do rest post。

「内部全体を外部に晒す」って話はしてないんだ。内部データを晒さないために構造体を使う必要なんてないよ。JSONオブジェクトを作る時に、特定のフィールドをフォーマットしないコードを書くだけでいいんだ。そのために新しいデータレイアウトは要らないんだよ。

Goのことは知らないけど、Javaや.NET界隈じゃMapStructみたいなライブラリでこの問題は簡単に解決できるよ。20個フィールドがあるモデルから3つだけ取り出すとか、ちょこっとしたコードで済むんだ。
fieldsの名前が合ってれば全部やってくれる。新しい「view」を追加するのも、クラス作ってmapperに1行足すだけ。データのコピーに19行も書かなくていいんだ。
ネストしたやつとかnullも扱えるし、reflectionじゃなくてcodegenだから手書きと同じパフォーマンスで、コードも読みやすい。
https://mapstruct.org
Go開発者は「こんな複雑なのいらない」って言うけど、これこそ自業自発的な問題じゃない？探せば解決策あるかもよ。

例を出すね。JavaのJacksonライブラリは両方のモデルに対応してる。よく見るのはjackson-databindで、クラス定義してフィールドにアノテーションつけてJSONとマッピングする。これはGoとかRustのSerDeに似てるね。このモデルだと、核となる構造体とは別にクラスを宣言するのは超合理的だと思う。
もう一つのモデルはJackson Tree Modelって呼ばれてて、Json Objectの表現をそのまま受け取るんだ。そこからフィールドを取って、それがまたオブジェクトだったり配列だったりする。コンパイラやってる人ならASTみたいなもの。
Tree Modelなら、クライアントからの生JSONを受け取って、自分で必要なフィールドを取り出すことになる。
こうすると、アプリケーション固有のパースが一回で済むし、その場で関連するエラーもいっぱい出せるんだ。Tree Modelは明らかに非効率だけど、効率的に実装する方法もあるよ。

標準ライブラリの他のパーサーはgobとencoding/xmlだね。gobはGo専用フォーマットだからフィールド名のconvention mismatchは起きない。encoding/xmlはJSONみたいに「形が同じ構造体へ変換」って感じじゃなくて、struct tagがXPathみたいなクエリ言語っぽい使い方なんだ。
実際のコードだと
type Person struct {
FirstName string xml:”name＞first”
LastName string xml:”name＞last”
}
みたいな使い方をする。一方でJSONは、「email”: ”jdoe@example.com”, ”name”: ”John Doe”}みたいなのを、ノイズなくパースしたいって明確な願望があったみたいだね。

うん、それは悪いパターンだね。かなりの数のプロダクションコードで見ることになるだろうな。

DB行に1:1でマップするモデルを1つだけ持つ必要はないって意見には同意だよ。これはどの言語でも同じ。でも、たくさんのDTOを作るのは面倒だし、俺たち開発者は怠け者だからね。単一の「User」型があちこちで使われてるのを見るのは超一般的。これもUser関連の関数をあらゆるコンテキストで再利用できるようにする（つまり手っ取り早くて怠惰な）アプローチなんだ。

GoだとJSONをmapにmarshalできるから、手動でフィールドを抽出することもできるよ。

「Transfer ObjectsはStorage Objectsではない」っていうFieldingのREST論文からのコンセプトは、RESTの現在の意味にとって重要なんだ。

俺は反対だな。JSONキーの大文字・小文字を区別できるようにしたことと、公開されているstruct memberを全部デフォルトでシリアライズするようにしたことは、悪い設計判断だよ。これらの決定は、簡単にセキュアじゃないシステムを生み出す可能性がある。

君と俺は違う記事を読んだみたいだね。例えば、JSONキーの大文字・小文字を区別しないことについて、「俺たちの意見では、これはGoのJSONパーサーの最も重要な落とし穴だ。なぜならJavaScript、Python、Rust、Ruby、Java、そして俺たちがテストした他の全てのパーサーと異なるからだ。」って記事は言ってるよ。これがGoに関することじゃないって主張するのは難しいだろうね。誤解しないで、俺もGoは他の人と同じくらい大好きだけど、この記事はGo固有のいくつかのシリアライズに関する問題を間違いなく浮き彫りにしている。

記事がCVEに直接リンクしてるんだから、このフットガン問題は十分証明されてるってことだよ。

ほら見ろ、やっぱりGoの話だよ。オプトアウトのアンマーシャリングにしたのはいいけど、それも脆弱らしいな。逆に、Railsのstrong paramsみたいにオプトインが良いんだって。

記事のタイトルはクリックベイトじゃないと思うな。一つの例じゃなく、他のも見てよ。Goのパーサーには色々なフットガンがあるのがわかるって。これはGoだけの問題じゃなく、他の言語でもあるんだけど、注目すべき点だよ。この記事はセキュリティとの関連性をしっかり示してると思うね。

まったくだね。ドメイン層でデータ型を正確にモデル化して、その上にAPI層を乗せるのがいいんだよ。セキュリティの問題はパーシングライブラリじゃなくて、アーキテクチャ設計の失敗なんだ。

encoding/xmlみたいな例外を除けば、それはGoのパーサーの限界なんだ。すごく緩くて、XMLとして正しいか検証しないんだよ。XMLの断片に対するクエリ言語みたいなものだと考えた方がいいかも。

こういう問題（パーサー差分）があるから、encoding/xmlを使ったGoのSAML実装なんて信じちゃダメなんだ。あれは元々そういう用途じゃないし。だから俺はSAMLを自分で書いたんだよ。（まあ、そもそもSAMLなんて使うなよって話だけどね）

問題はGoのパーサーそのものじゃなくて、検証レイヤーと処理レイヤーが違う入力データを使ってることなんだ［1］。俺たちはgosaml2とか他のGoのSAMLライブラリにパッチを当てて、認証済みのバイト列だけを処理するようにしたんだ（元のXMLドキュメントじゃなくて）。パッチはここだよ：
https://github.com/russellhaering/goxmldsig/commit/e1c8a5b89…
https://github.com/russellhaering/gosaml2/commit/99574489327…
君が自分で書いたSAMLとXML署名、興味あるな。［1］：https://bsky.app/profile/filippo.abyssdomain.expert/post/3le…

こういう問題は避けやすいけど、プロトコルバッファの良さがようやくわかった気がするよ。どの言語でも、シリアライズ・デシリアライズの挙動が一貫してるってのは安心できるからね。

そうだと嬉しいんだけど、残念ながら違うんだよ :-) パーシングっていうより、言語そのものの違いに関係してるんだ。だって、C++の数値とJavaの数値は違うし、PythonともJavaScriptとも違うだろ。文字列も同じだよ。

protobuf のライブラリってさ、プログラム言語が違っても型を合わせるために、たとえばプラットフォームに依存しない 64bit 整数とか、常に UTF-8 の文字列型を強制するイメージなんだけど、実際はどうなんだろうね？ あんまり protobuf 使ったことないから分からないんだ。

なんでそう思うの？ それって protobuf やパーシングより、プログラミング言語そのものの問題じゃん。
protobuf には符号付きも符号なし整数もあるけど、 Java は符号なし整数ないし、 Python は任意精度だし、 JavaScript は昔は double しかなくて、整数は正確に 53bit までしか表せなかったんだ。今は arbitrary size な整数もあるけど、 protobuf のライブラリがそれを使ってるかどうかも分からないし。
これだけじゃないよ、言語ごとに全然違うんだってば。 OCaml は 31bit か 63bit 整数だった気がする。
https://protobuf.dev/programming-guides/encoding/＃int-types
で、文字列も全部の言語で違う。大体 8bit、 16bit、 32bit のコード単位の３つが主流かな。
Go と Rust は 8bit 単位が好きだし、 Java と JavaScript は 16bit 単位、 Python や C/C++ は 32bit 単位（コードポイント）だよ。

なんか説明が悪かったみたい。 バイトとか配列さえあれば、その上に unsigned integer とか 8bit 文字列、 UTF-8 文字列、 UCS-2 とか、何でも自分で実装できるんだよ。 ネイティブ型じゃないから遅いとか、メモリレイアウトが変になるだろうけど、不可能じゃないの。
まあ、 JavaScript みたいに整数すらないレベルで機能制限されてる言語なら、完全にサポートするのは無理だろうけどね。

残念だけど、それじゃ問題は解決しないで、ただ先送りしてるだけだよ。
好きな言語で protobuf のジェネレーターを書いてみることをお勧めするな。 C++ からかけ離れてるほど、難しい決断をしなきゃいけないって分かるはずだよ。
そのやり方でやってみると、 Go とかのイディオマティックなコードと連携する時に“税金”（コスト）を感じるだろうし、そしたら多分逆の決断をするだろうね。
“機能制限されてる”って話だけど、 protobuf の API 設計の議論って、大体こんな感じなんだよね。 特定の言語のユーザーが他の言語のユーザーの視点を想像できないっていう。
たとえば、符号付きか符号なしかが世の中の決まりなのか、それとも単なる実装の詳細なのか、とかね。
あと、 C/C++ より表現力が豊かなのも問題なんだ −− 例えば、 Python のイディオマティックなコードから見ると、 protobuf のデータモデルも問題を引き起こすんだよ。
C/C++ の中でも、 C++ 03 とスマートポインターのある C++ 11 みたいに、複数の“方言”があるでしょ（将来もっと増えるだろうけど）。 こういうスタイルが、 protobuf の v1 と v2 の API に対応してるんだ。
（俺は protobuf の v1 と v2 を何年も使ったし、 protobuf の v3 Python API の設計レビューもしたよ）
要するに、 protobuf は魔法じゃないってこと。コード生成と組み合わされた別のパーシング形式で、いくつかの技術的な問題は解決するけど、全部じゃない。 パーシングとかシリアライズに関する議論もなくならないよ！

“一貫したシリアライズ/デシリアライズ体験が保証される”って言うけどさ、 protobuf の実装ってそんなにたくさんある？ C ライブラリとか proto コンパイラをラップしてるのがいくつあるの？ 一貫性って、下にある単一の文化（ monoculture ）からきてるだけかもしれないよ。まあ、それは結局「 protobuf は YAML じゃないし、 JSON じゃない」っていう無限ループになるけどさ。
話がそれちゃったけど、これも全部、 pure Python のデシリアライザー/ディセクターがなかったから、自分で実装したっていう単純な理由からなんだよね。

ここで似たようなメリットを得るには、 RPC スタイルの JSON API を OpenAPI spec に書いて、そこから Go の struct とかルートハンドラーを生成するってやり方でもいいと思うな。俺は Go のプロジェクトだと大体そうしてるよ。

でもさ、この記事は厳密にはパーサーのバグについてってわけじゃないから、データフォーマットを変えても、そこで説明されてる問題のほとんどからは救われないと思うな。

Go プログラマーじゃない俺から見ると、表面上はフィールドのメタデータに文字列（構造体タグ）を使うのって、 Rust のマクロ（コンパイル時にメタデータを解析）とか Java のアノテーション（ランタイムに処理されるけど、少なくともオプションを分解するために文字列を解析する必要はない）と比べると、かなり後退してるように見えるんだよね。
accidental omitempty とか − が、実際に問題を起こさないとしても、その変さの良い例だと思うよ。

.NET プログラマーとして、メタデータの“stringly typed”な性質にはゾッとするけど、 Go の選択にはずっと困惑してるんだ。
だから、 .NET では、君が言う Java みたいに、属性を使ってるんだ。例えば JsonPropertyName(“username”) とか JsonIgnore とかね。
これはシンプルで分かりやすいんだ。 JsonPropertyName 属性は上書き用で、クラス全体の命名ポリシーも設定できるんだ。 camelCase がデフォルトで、 kebab-case、 snake_case なんかも代替のデフォルトとしてあるんだ。
C＃/.NET はもちろん、 public なプロパティがあるっていう利点があって、これらはデフォルトでシリアライズされるんだ。 private なプロパティはされないから、公開したくないものをうっかり公開しちゃう可能性は低いんだよね。
これに対して Go のアプローチは、 Python とよく似ていて、大文字/小文字の慣習で private か public か決めるんでしょ。（間違ってたら訂正してね）
最初の例もまだ混乱するんだよね。 IsAdmin がユーザーから来るなら、それはデシリアライズしたいだろうし、そうじゃないなら DTO に入れるべきじゃないんだ。
デシリアライズはそこでちょっとした“おとり”（ red-herring ）だよ。 「このユーザーは管理者を作る権限がある？」っていう検証ステップがあるべきなんだ。
ユーザー入力から直接プロパティを使って更新されるユーザーのクラスがあるっていう考え方は、俺には変に感じるけど、俺は“エンタープライズプログラマー”として、全ての間にもっとレイヤーを置きたがるだけだって思われるかもね。

Go で大文字/小文字で public か private か決めるのを“convention”（慣習）って呼ぶのは誤解を招くと思うよ。
Python だと obj._field って書けば _field にアクセスできるんだ。それは強制されてなくて、ユーザーに「触るな」っていう注意書きみたいなもんなんだ。
でも Go だと、 obj.field はコンパイルエラーになる。小文字で始まるフィールドはマジで private なんだよ。これは強制されるんだ。
だから、それは真のプライベートフィールドだけど、ちょっと…ユニークな構文だって考えた方がいいと思うよ。

GoはPythonと違って名前の大小で公開/非公開が決まるらしいね（俺が間違ってたら教えてくれ）。Goは可視性をケーシングに紐付けてて、非公開フィールドはシリアライズしない、公開フィールドだけだってさ。Pythonには可視性って概念自体ないんだ。慣習として_付きの属性にはアクセスしないことになってるけど、止められはしないんだよ。

30758への返信だぜ。_付きの属性にアクセスしないっていう慣習だけど、ちゃんとしたPythonプロジェクトならリンターか型チェッカーを最低一つは使うはずで、それで簡単に強制できるんだよ。

これって変なだけじゃなくて、危ないやり方だぜ。フィールドが増えるにつれて検証を漏らしやすくなるからね。俺的には、全フィールドを明示的に検証する方が良いと思うよ。

普通のGoプログラマーとして言うけど、うん、struct tagはマジでクソだね。複数の“アノテーション”を1つのstruct tag文字列にまとめようとすると、さらに最悪になる。Goがアノテーションとかマクロって考え方にすごく反対で、明確な制御フローって考え方をすごく大事にしてるからこうなってるんだ。そして、これが俺がこの言語を愛してる理由の一つでもある。でも、JSONとかXMLのマッピングみたいに、アノテーションがめちゃくちゃ役立つユースケースが使いにくくなるっていう代償もあるんだ。Goにもっとコンパイル時のマクロがあるって考えは俺にとって面白いけど、同時にGoの制御フローのデバッグしやすさとか分かりやすさは俺がこの言語を大好きな理由の一つだから、Goにもっとメタプログラミング能力があると必然的に生まれるであろう“魔法”みたいなWebフレームワークができる可能性は招きたくないんだ。だから、この結果は受け入れる覚悟ができてるって感じかな。:/

30761への返信だよ。アノテーションに制御フローはないんだぜ。単に項目にメタデータを付けるだけ。struct tagとの違いは、そのメタデータが構造化されてるってこと。

うん、ごめん、ここが分かりにくかったね。俺が言いたかったのは、Goがアノテーションを避けるのは、裏で色々自動でやってくれる魔法みたいなフレームワークとか、他の種類のメタプログラミングを招くからだよ。

君の気持ちは分かるぜ。Springみたいに色々なことやってくれる魔法フレームワークはたくさんあって、何が起きてるのか理解するのが超大変なんだ。解決策は、普通はもっと良い言語を持つことなんだ。型システムがすごく強力で、そういうハックが必要ない言語ね。残念ながら、そういう言語で生産性を上げるにはその型システムを学ばなきゃいけないし、多かれ少なかれ最初から学ぶ必要がある—これはGoogleがGoで避けたいことだったんじゃないかな、人の入れ替わりを考慮してね。

それは「より良い」言語ってより「違う」言語の問題なんじゃないかな。どんな言語設計にも明らかにトレードオフはあるしね。面白いかもしれないのは、システムの一部を一つの言語で書いて、他の部分を別の言語で書けるような言語エコシステムだね。BEAMとかJVMランタイムはそれを許してるけど、違う言語がお互いの強みを活かして上手く連携してる良い例はあまり見たことない気がする。

ええと、俺が言いたかったのは、なんか言語機能が足りないってことなんだよ。だから、その機能が追加されて言語が「良く」なるか、その機能が既にある「違う」言語を選ぶか、ってことなんだ。だから、うん、そうさ。
BEAMとかJVMランタイムはこれを許してるけど、違う言語がお互いの強みを活かして上手く連携してる良い例はあまり見たことない気がする。
多分、ランタイムが常に最低共通項になるからだろうな。とはいえ、Scalaで書かれたAkkaとかSparkみたいなツールがJavaから使われる例はたくさんあるよ。もちろんその逆もね。

struct tagで一番イラつくのは、タグ文字列内の別々の値とかフィールドの標準がないことだね。JSONだとカンマを使うのに、Gorm（確か）だとセミコロンだったりさ。これで何回か頭を抱えたことがあるよ。

Goのstruct tagは、ある人にはバカげてるけど、ある人には素晴らしいんだ。多くの機能の80%を、複雑さとコストの20%で実現するGoの80/20デザインの典型例だね。
struct tagは重要なシナリオを簡単に扱えるようにしてる。でも、annotationみたいに他のシナリオまでカバーしようとはしないんだ。function tagでもvariable tagでもないし、汎用annotationでもない。structのフィールドのためだけのannotationなんだ。
annotationとかmacroみたいに強力かって？当然そんなことない、全然だよ。
実装、理解、使うのがそんなに複雑かって？それもないね。
80/20デザインさ。コストの20%で機能の80%。

Goのシンプル化って、他の場所に複雑さ持ち込むこと多いよね。この記事がstringly-typedなDSLの正確性の複雑さで示してるみたいにさ。
タダ飯なんてなくて、Goがその結果を得るためにした妥協は、設計段階で完全に予測できた形でエラーにつながりやすいってことが明らかになってる。

＞Goのシンプル化って、他の場所に複雑さ持ち込むこと多いよね
たまにあるけど、「多い」ってほどかな？Goのシンプル化のおかげで、コードベースの大部分は…まあ…シンプルになるんだよ。
その代わり、エッジケースで少し複雑になるコストはかかる。それは全然受け入れられるトレードオフだね。普通の部分がシンプルになる代わりに、変な部分が複雑になるのは許容できるよ。エッジケースを簡単にするために、常により高いレベルの複雑さに対処するよりマシだ。
＞タダ飯なんてない
これには同意。タダ飯じゃないけど、すごくリーズナブルな値段だよ（壁に穴が開いてるようなレストランで、値段の割にめちゃくちゃ美味い飯が出てくるみたいな）。
＞Goがその結果を得るためにした妥協は、設計段階で完全に予測できた形でエラーにつながりやすいってことが明らかになってる
ここも同意だね。でも、俺はこれをメリットとして見てる。エラーになりやすい部分が、設計時に十分明確に見えるんだ。ここにもタダ飯はないけど、どっちの部分をエラーになりやすくするかでGoがしたトレードオフは気に入ってるよ。他の言語で、そういうエラーになりやすい箇所を減らすために大幅に複雑さを増やした結果、かえってエラーになりやすい場所の表面積が増えたってのが俺の経験だね。
デザイン空間の他の場所の方がより良いトレードオフだって主張できるかって？もちろん、特に特定の問題に対してはね。でも、この場所は〜95%のことで本当によく機能してるように見える。

んー、null値とかデフォルトのzero-valueはそんな簡単に看過できないな。あれでいつも困ってるし、代替策（明示的な代入）より意味があるほどシンプルでもない。
あとはmutability修飾子とか。確かに余分な機能だけど、機能が少ない方が魅力的なのは否定しない。でも、immutableってフラグを立てられると、これから扱う全てのコードが楽になるんだよ。
genericsを15年も入れなかったことを考えてみてよ。ある意味言語をシンプルにはするけど、genericsが必要な時はreflectionを使わなきゃいけなくて、それはgenericsよりよっぽど複雑だよ。macroだって不人気とはいえ、codegenよりはマシだ。
繰り返しになるけど、ミニマリズムの魅力は分かるよ。でも、これらの機能のコスト/メリット分析を見ると、どれも圧倒的なプラスになってる。なんか「良いものは持てない」みたいな全体的なポリシーは、不必要に厳しくて、みんなを損させてる気がする。

＞Goのシンプル化って、他の場所に複雑さ持ち込むこと多いよね
まさにこれ。
基本的に：複雑な圧縮アルゴリズムがあるとする？はい、それは複雑だけど、結果のファイルサイズ（=プログラムの複雑さ）は小さくなる。
すごく基本的な圧縮アルゴリズムを使うと、アルゴリズム自体は理解しやすいけど、ファイルサイズははるかに大きくなる。
それはトレードオフだね。でも、プロとして、ちゃんと時間をかけて良い複雑な圧縮アルゴリズムを一度しっかり学んで、それから書く全てのプログラムで恩恵を受けるべきだと思うんだ。

＞ちゃんと時間をかけて良い複雑な圧縮アルゴリズムを一度しっかり学んで
[ここにPikeのGoogleの若いプログラマーについての引用が入る]
それってGoの哲学じゃないんだよ。Goの規約は、効率よりもできるだけ明白であることなんだ。それが好きな人もいれば、そうじゃない人もいる。俺はそれが嫌だから、Goを使うのをやめた。

80/20デザインって良くない気がしてきた。worse is betterに driven されてるように見える多くのことが、気候変動とか見ると…それって価値があったの？

そう、多くの理由でひどいアイデアだよ、セキュリティだけじゃなくてね。文字列の中に隠された、定義が不明確でよく理解されてないDSLみたいだ。
でも、struct tagを使わないこともできるんだ。代わりにmapにunmarshalして、必要なキーを選んだり、検証したり、それから値を設定したりできる。
公開する時も同じ。俺は、型に紐づいたこのよく分からない文字列キーに基づいてデフォルトですべてを公開するより、公開するキーを定義する明示的なビューを持つ方が好きだよ。

struct tagは、フィールドをフィールドにマッピングするために必要な定型コードを大幅に削減するんだ。理解すると、本当にかなり斬新だね。