マジかよ Substackエディタが「/etc/hosts」でまさかの大炎上
引用元：https://news.ycombinator.com/item?id=43793526
CDNでWAFルール設定する人って、技術的な内容扱うサイトとかサービスの理解が甘いんだよね。Cloudflareだけじゃなくて、Akamaiも同じ。データベースの話してると、SQLインジェクション対策ルールでサイトが壊れるし、/etc/hostsとか/etc/passwdがブロックされるファイルインクルージョン対策もあるし。セキュリティとユーザビリティのバランスは難しいよね。WAFルール全部オンにすれば安全だけど、技術的な話したい時は邪魔になる。ルール調整は時間かかるし、切っちゃうことも多い。/etc/hostsがURLに入ってるとページ読み込めないとか、XHRリソースが読み込めないとか、JSの分析ライブラリがURLをcookieに入れるとか、マジで面倒。
セキュリティとユーザビリティのバランスに加えて、経済的な理由もあるんだよね。セキュリティチームとかアプリ開発者が無能だって言われがちだけど、変なセキュリティポリシーの多くは保険会社が原因。保険会社が「パスワードを90日ごとに変更させないと保険料20%アップ」って言ってきたら、それが悪い習慣だって言っても無駄。NISTがパスワード定期変更は推奨しないって言っても、保険料は上がる。だから、嫌々ながらパスワード有効期限ポリシーを導入して、従業員に文句言われる羽目になる。log4shellみたいなことがあったから、/etc/hostsとか/etc/passwdとかjndi:みたいな「ハッキング文字列」をサーバーが拒否するように保険会社が義務付けてる可能性もある。
保険会社がセキュリティポリシーを要求するって話をよく聞くけど、個人的には見たことないんだよね。もしそういう保険契約があるなら、ぜひ共有してほしいな。保険契約は秘密じゃないし、公開しても大丈夫なはず。自動車保険の契約書はたくさんGoogleで見つけられるし。
例を見つけたよ！Zurich Cyber Insuranceのアンケートに「強力なパスワードを使用し、少なくとも四半期ごとにパスワードが変更される技術的に強制されたパスワードポリシーがありますか？」って質問がある。保険のアンケートだから、この質問への回答で保険料が変わるんじゃないかな？o4-mini(https://chatgpt.com/share/680bc054-77d8-8006-88a1-a6928ab99a…)で見つけた。
ITチームが「パスワードの要件は保険のポリシーで決まってるんです」って言ってくれたら、納得できるのに。理由を教えてくれたら、パスワードの有効期限切れルールにイライラしなくなると思う。
製品の視点からすると、この決定を支持するよ。デフォルトでルールを複雑にしてSQLインジェクションの脆弱性を見落とすリスクを取るか、SQLに似たものをすべて禁止して、例外的なケースに対処してもらうか？後者のアプローチが良いと思う。Cloudflareのユーザーなら、SQLをペイロードに含める複雑さを理解してるだろうし、デフォルトのルールを変更できるはず。Cloudflareからすると、SQLのすべての有効な使い方を網羅するのは不可能だし、SQLコンテンツをホストするウェブサイトは1%くらいだろうから。
最近見たのは、パスワードの長さが一定以上（12文字くらい）なら、90日ごとの変更は不要で、1年に1回でOKっていうルール。業界がパスワードの複雑さよりも長さが重要だって気づいたから、ポリシーに反映されるのは良いことだね。
質問4.3は「ユーザーがエンドユーザーデバイスにプログラムをインストールすることを常に禁止していますか？」だって。マジでヤバい。
パスワードのローテーション間隔を長さに比例させるのは良いアイデアだと思う。たとえば、文字を追加するごとに間隔を倍にする。セキュリティ標準では、年1回のローテーションがセキュリティを低下させることが認識されているから、ローテーション間隔を許容できる範囲で、できるだけ長いパスワードを選ぶように促すべき。年1回のローテーションが面倒なら、12文字から14文字にするだけで、4年、8年、16年にできる。
専門家じゃないけど、CISSPのコースを受けたことがあるよ。そこで覚えているのは、パスワードは数字とか特殊文字とか大文字小文字を混ぜるよりも、長くすることが推奨されてたってこと。正確な言い回しは覚えてないけど、短いパスワードよりも文章が良いって話だった。でも、多くのサイトは短いパスワードを要求してくるから、覚えられないんだよね。
パスワードを定期的に変更する必要があるって知ってから、セキュリティがマジで下がったわ。今の会社で働き始めた時、めっちゃ強固なパスワードを作って1週間かけて覚えたんだ。でも6ヶ月後、変更必須ってなって、昔使ってたパスワードをちょっと変えたやつに戻しちゃった。変更のたびに末尾の文字をローテーションさせるつもり…
もし君のウェブアプリがSQLインジェクションを防ぐためにCloudflareのフィルタリングに頼ってるなら、そのアプリはSQLインジェクションに対して脆弱だってことだよ。
なんでCDNレベルでSQLインジェクションのフィルタリングをする必要があるのかマジで理解できない。長さとか、日付とか数字とか、単純なタイプのチェックくらいならまだしも。バックエンドはどんなバイトコンテンツでも扱えるようにすべきだし、CDNレイヤーのプリフィルタリングがなくてもSQLインジェクションに脆弱であるべきじゃない。
Defense in-depth（多層防御）ってやつでしょ。脆弱なウェブアプリをWAFだけで守ろうなんて考える人は少ないと思うけど、アプリが完璧だからってWAFを省略すべきじゃないよ。
ITの人がその理由をそのまま従業員に説明すればいいだけじゃん？
最近の会社のワークステーションのトレンドは、アプリストアがロックダウンされたスマホに近づいてるよね。会社のソフトウェアリポジトリからのプログラムしか使えなくして、業界特化のアプリ、MS Office、有名な生産性ツール以外を排除すれば、サポートの電話も減るし（カスタマイズできないから！）、カスタムの実行ファイルが展開できないからサイバー攻撃も防げる。
経済的な理由だけじゃなくて、監査プロセスも大規模なルールセットを採用するように促すんだよね。SOC2 + HIPAA準拠ってことは、自分たちのセキュリティルールが監査人が気にするケースを100％カバーしてるって説得するか…既に対応済みのWAFを買ってきて「はい、終わり」って言うか。CTOは毎回後者を選ぶよ。
セキュリティと使いやすさのバランスだと思うな。どんなサービスがセキュリティホールを持って実装されてるか分からないし、WAFルールを全部適用すれば安全になる。ただ、技術的な話をしたい時に、そのルールセットが邪魔になるんだよね。
もしかして時代遅れかもだけど、リクエストされたリソースのどこかに”/etc/hosts”って文字列があるだけでWAFが反応するなら、それは明らかに壊れてる。
「念のため」ってのは最悪のセキュリティだよ。パスワードは安全のために毎月変えろ、安全のために20文字以上の英数字（記号5文字必須）にしろ、チェックリストにあるからWAFを有効にしろ…CIOに「一体何の脅威を防いでるんですか？」って聞いても、ポカーンだよ。エンジニアはちゃんとサニタイズするより、チェックボックスを埋めて終わりにするインセンティブしかない。組織はセキュリティ向上じゃなくて、何かあった時に責任逃れすることしか考えてない。
保険会社にも限度と責任を持たせるべきだよ。保険会社が何でも要求できるわけじゃないし、企業はそれに従う必要もない。マネジメント、ITセキュリティ、保険会社、規制機関…みんな他人のことなんて考えずにルールを押し付けてくる。保険会社の要求に対する反論の仕組みがないなら、何かがおかしい。
パスワードマネージャー使えばよくね？
大企業じゃ普通だよ。ITにチケット発行してソフト入れてもらうし、開発者は管理者権限あってもroot権限はないとか、一時的なものとか。昔のタイムシェアリング時代からそうだったし。だからPCが自由だって感じたんだよね。
それはないと思うな。このルールで古いWordPressの脆弱性とか結構ブロックできるんじゃない？
え、マジで？ちゃんとクエリ組めば(1990年みたいに文字列連結とかじゃなくて)、WAFに邪魔されたくないんだけど。ユーザー名にアポストロフィ入ってるだけでブロックとかありえない。
全部拒否するルールが一番安全だよね。クエリパラメータとかヘッダーの値の評価が保守的すぎて誤検知するのはまだわかる。でもブログ記事の内容で誤検知とか意味不明。
わかる。SOC2って、営業のことも思い出させるんだよね。セキュリティ＝経済みたいな。大企業のRFPでセキュリティプロトコルを指定されること多いけど、まともなのもあれば、そうでないのもある…。\nWAF入れろって言われたら、嫌でも入れるしかないよね。
よくあることじゃん。今の職場だとセキュリティ担当者が主導してるけど、保険会社じゃないよ。セキュリティ担当もちゃんと理解してないこと多いし。
CIOは自分のポジション守ってるだけ。今まで見てきたCIO(n=3)は、技術知識ほぼゼロなのに、マネジメント能力だけで出世してる。MBAとかでビジネスを重視しすぎてるせいで、全然物事が進まない。昔はビジネスの学位持ってるとか言っても笑われたのに。
パスワードの推奨事項は変わってきてるけど（アメリカ政府がガイドラインを去年更新したし）、パスワードは共有しないのが基本だよね。パスワードマネージャーを使えば“長いパスフレーズ”vs“複雑なパスワード”みたいな議論は意味なくなるし。パスフレーズはパスワードマネージャーをアンロックする時用で、普段使いのパスワードは自動生成された32文字のランダムな小文字で十分じゃね？
ECサイトの逸話を思い出した。誰かが脆弱なwebshopを作っちゃって、その対策がログに”OutOfMemoryException”って文字列が出たらアプリを再起動するっていうものだったんだって。で、別の開発者が顧客の検索ワードをログに残したいってなって、誰かが検索バーに”OutOfMemoryException”って入力したら…
もっとコメントを表示（1）
適当なテキストログの解析って、システムを攻撃する上で意外と有効な手段なんだよね。ソフトウェアがデータをエスケープやサニタイズせずに盲目的にログに記録してるのがマジで怖い。
”OutOfMemoryException”みたいな既知の文字列をサニタイズするって話じゃなくて、ログに記録する信頼できないデータは全部サニタイズするか（できれば）エスケープして、他のものと混同されないようにするってこと。
たぶんGPの言いたいことは、信頼できるシステムから来るはずの文字列”OutOfMemoryException”をどうやってサニタイズするんだ？ってことだと思う。「全部構造化ログにしろ！」ってことなのかな？（o11y詳しくないから見当違いだったらごめん）
o11yは”observability”の略。
Numeronym（数字を使った略語）はマジ勘弁。もう使うのやめようぜ。
ありがとう。制限の中でランダムな文字列を生成しようとしてパズルゲームみたいになってたわ。教えてもらわなかったら意味不明だったかも。こんなバカげたアイデア考えたやつ誰だよ。
だってググりやすいじゃん。反論としては、みんな使うんだから早いうちから触れさせて慣れさせた方が良くない？略語は絶対需要あるよ。昔は「horseless carriage」って言ってて、それが「automobile」になって、最終的に「car」になったじゃん。”Light amplification by stimulated emission of radiation”って言うより”laser”って言うでしょ？ニューヨークタイムズならちゃんと”observability”って書くけど、HNで？勘弁してくれよ。もう7年も使われてる言葉だし。
検索エンジン使わないと読めない言葉を使うのはやめようよ。テキストを読むために検索エンジンに頼る必要はないでしょ。入力が面倒ならオートコンプリートとか他のツールを使えばいいじゃん。
その通り。避けた方がa11y（アクセシビリティ）が向上するね。
マジそれな。人工性を自動的に保証する、あるいは適用性と受容性を確保する最良の方法だね。自伝にまるまる一章割いてるわ。冒険的に、本物を含める必要があったの（当然）。
ローテクな例：ユーザーが入力した文字列内のすべての改行をエスケープし、既知のプレフィックス（例えば##）をすべてのユーザーデータに追加する。システムのログを検索するときは、マーカー以降を無視する。結局、2つの文法の共通部分が空かどうかを理解することが重要。
難しいのは、この例だと、規模によっては2人が同じチームにいる可能性が低いこと。同じデータを使って異なることをしていて、お互いのことを知らないかも。ログ記録方法のドキュメントに、すべてのユーザー入力を##でタグ付けするルールを追加できるけど、壊れるまでドキュメントを読む人なんていないでしょ？規約は役に立たない。正しく動作させる方法は100通りあるけど、より具体的な文字列（例えば、アプリ名を含む）で再起動するなど、燃える可能性を減らすだけ。自分もOOM-Killer.shを書いたことがあるけど、正しく行うのが不可能なエッジケースの一つ。だからログデータを解析してアクションするのはアンチパターンとみなされる。
OutOfMemoryExceptionログは検索ログと同じであるべきではない。Error：OutOfMemoryExceptionとSearch：OutOfMemoryExceptionは、いかなる意味でも関連付けられるべきではない。
誰かが“Error：OutOfMemoryException”を検索するまではね。
構造化ロギングが面倒なら、ユニークなプレフィックスで解決できる。要するに、ユーザーがログに出力できないトークンが必要。すべての改行を厳密にエスケープすれば、行の先頭と末尾を偽造不可能なトークンとして使用できる。可能性は無限大で、結局、2つの文法の共通部分が空かどうかを理解することが重要。
gpの言いたいことは、OOMを探すために解析されるerror.logが、エンドユーザーがOOMを検索したuserSearches.logとは関係ないってことだよね。
HNのやつら、マジで頭固すぎ。誰も説明してないじゃん。言いたいのは、サーバーを単純な文字列検索で制御するのがマジでアホだってことだろ。そんなのありえねー。
俺もWAFで同じような経験あるわ。ユーザーが”system(…”って文字列を含むメモを書いたせいで、WAFがPHPインジェクションだと勘違いしてIPbanされた。
/etc//hostsとか/etc/./hostsはブロックするの？こんなのいたちごっこで絶対失敗するって。ハッカーはもっと賢いし、セキュリティは実績のあるものだけに頼るべき。例えば、信頼できない入力を実行しないとか。
WAFに完璧を求めるのはナンセンス。でも、無いよりはマシって考え方もある。
よくあるFortune 500のチェックボックス案件だよね。とりあえずWeb Application Firewall入れとけ！ルールなんてどうでもいいんだよ。SQLインジェクション対策に必要だって言われたけど、SQLデータベース使ってないアプリだったし。
反論すると「多層防御」とか言われるんだよなー。毎週木曜の朝に机を叩いて3回転する方が効果的だって言うと、マジで変な目で見られるけど。俺は毎週やってるけどハッキングされたことないし。多層防御だろ？害はないし！
セキュリティ対策は、本気の攻撃者を止められないと無意味なの？WAFのルールは、既製の脆弱性スキャナからのプローブをブロックすることが多い。
Web application firewallを「全部許可」に設定してチェックボックス要件をパスさせるのが大好き。
（俺は反WAF派だけど）軽度のDoS攻撃を緩和するために、応急処置を迅速に適用できる点は評価できる。完全に無意味ってわけじゃない。
リクエストごとにレイテンシが増えるんじゃないの？
それがあった方がないよりは一般的に良いよね。じゃあHNとか他のサイトも、ユーザーが“/etc/hosts”を投稿できるせいで全部セキュリティが甘いってこと？
どうかな？知らんし興味もないけど。もしHNにパストラバーサルの脆弱性があったとしても、まともな設定のWAFならその攻撃を防ぐでしょ。
うちも今クライアントとまさに同じ状況だよ。「WAFにSQLインジェクション対策を入れろ」って。「でもSQLデータベースないじゃん」「でも将来、別の会社と組んで、そこのデータをSQLデータベースに入れる可能性もあるから対策が必要」だってさ。 NISTとかクラウドサービスプロバイダーがWAFはベストプラクティスだって言うから、仕方ないんだろうけどね。
そんなの難しくないでしょ？文字列の絶対パスを取得するのなんて、ほとんどの言語の標準ライブラリにあるじゃん。スラッシュを含む文字列をgrepして、解決を試みればいいんだよ。ワイルドカードの解決はちょっと難しいけど、禁止ファイルのリストがあれば可能だよ。
ちゃんと仕事したいなら、頭使って考えたら？エンジニアに指示する前に、自分が何を言ってるのかちゃんと理解してからにしてほしいわ。
それってただのセキュリティ劇場だよね。空港で靴爆弾事件があったからって、みんなの靴をスキャンし始めたの思い出すわ。確かに同じ手口は防げるかもしれないけど、旅行者全員に迷惑だし、攻撃者は別の場所に爆弾を仕込むって。
もっとコメントを表示（2）
「何もないよりはマシ」って、ちょっと変な基準だよね。ファイル名に“virus”って単語を使わせないみたいなもんじゃん。確かに一部のウイルスは防げるかもしれないけど、簡単に回避できるし、正当な理由で使いたいユーザーにとっては大きな問題だよ。無意味じゃないけど、バカげてる。
システムの仕組みを知らない人が、セキュリティ対策について指示するべきじゃないと思うな。それって、壁に繋がってない門にも鍵をかけるべきだ、って言ってるのと同じだよ。 https://i．imgur．com/ntYUQB1．jpeg
玄関に鍵かける？
WAFの会社がロビー活動して、チェックリストに入れさせたんじゃない？結局、第三者に金を払わせたいだけなんだよ。
既存のリバースプロキシをWAFって呼んで､チェックリスト項目をクリアできるぜ｡(言いたいことはわかる｡多くの企業は色々な理由でWAFを買うかもね｡)
McAfeeを全てのPOST bodyで実行するようなもんだけど､やりたがるやつはいるんだよな｡(せめてスキャナがカーネルで動いてないことを願うよ｡)
そのロジックはおかしいよ｡もし君のアプリが､「/etc/hosts」みたいなテキストをフィルタリングするだけで効果があるほど脆弱なら､入力が少し変わるだけで同じように脆弱なままだよ｡セキュリティ的には意味ないし､ユーザー体験は悪くなるから､無い方がマシ｡
システムがどう動くかを知らない､あるいは気にしない人が､安全にするために何をすべきか指示するべきじゃない｡多くの“computer security”の人はシステムを理解しようとしてないんだよ｡もしそうなら､彼らはエンジニアだ｡理解せずに安全にしようとしてる｡
彼らはちゃんと仕事をしたいんじゃない｡仕事ができるように見せたいんだ｡仕事のやり方を知らない人や､実績と全く関係ない評価基準を持つ人にね｡
「でも､それがある方が無いより一般的に良い」って？俺は全く逆だと思うね｡理由の一つは､セキュリティのミスを隠してコードの安全性を下げてしまう可能性があるから｡もしWAFがエスケープの問題を隠蔽したら､WAFを出し抜けるクリエイティブな攻撃者に脆弱なままになる｡
“攻撃者が靴爆弾を使った”って､それよりもっとアホらしい話だよ｡攻撃者が靴爆弾を使おうとして失敗したのに､その失敗のせいで13年以上も無駄な遅延が発生してるんだぜ｡
まあ、どれくらい影響あるかだよね。緊急時の保護で3～10msくらいなら許容範囲じゃない？
Substackが技術系のライターのために状況を改善する方法？
記事を編集するendpointで、アホみたいなWAFを動かすのをやめればいいんじゃね？WAFに引っかかるような文字列について議論する記事だってあるんだからさ。
ちゃんとエスケープ処理を学べっての！
セキュリティ認証を通すためにWAFを運用しなきゃいけないんだよね。
OSSのWAFはmodsecurityとそのベータ版のcorazaしかないし。
OWASPのcorerulesetを使ってるんだけど、マジで意味不明なゴミの山なんだわ。
今回の件は、セキュリティとユーザビリティのバランスの問題じゃない。
単なるバグ、アホなバグだ。
セキュリティとユーザビリティのトレードオフは確かにあるけど、今回は違う。
セキュリティを強化するとユーザ体験が悪くなる。2FAとか、3回失敗したらロックアウトとか、DoS対策のレート制限とか。
今回はセキュリティもユーザ体験も両方悪い。
WAFをすべてのendpointに適用して、問題が発生したら選択的に削除するのは、一般的なセキュリティ対策として有効だと思う。
特にWordpressみたいなサードパーティ製のソフトウェアをプラグインと一緒にホストしてる場合、すべての公開endpointを評価するのは非常に難しい。
