Web Security Basics Every Developer Must Know — cod-ai.com

三年前、私はコンサルティングを行っていたスタートアップが72時間ですべてを失うのを目の当たりにしました。高度な国家的攻撃や、見出しを飾る0日エクスプロイトによるものではありませんでした。彼らは、急いで行った金曜日のデプロイ中に、ジュニア開発者が導入した一つのSQLインジェクションの脆弱性のために、顧客データベース、評判、そして最終的にはビジネス全体を失いました。攻撃は月曜日の朝に発生しました。水曜日の午後には、彼らは破産手続きを草案していました。

私はサラ・チェンです。過去12年間、スクリーピースタートアップからフォーチュン500企業までの企業でセキュリティアーキテクトとして働いてきました。予防可能な同じミスが何度もビジネスを破壊するのを見てきました。イライラする点は、これらの災害のほとんどは、あなたが平均的なJavaScriptフレームワークを学ぶよりも短時間で習得できる基本的なセキュリティ知識で回避できたということです。

コーディングを学ぶ際に誰もが教えてくれないことがあります。それは、セキュリティは他のすべてをマスターした後に取り組むような高度なテーマではないということです。これは基礎的なもので、赤信号が停止を意味することを理解せずに運転することのようなものです。一時的にはうまくやれるかもしれませんが、結局は壊滅的な事故を引き起こすことになります。

2023年のバイダンデータ侵害調査報告書によれば、侵害の74%は人間要因が関与しており、錯誤、不正使用、またはソーシャルエンジニアリングが含まれています。しかし、ここで重要なのは、彼らがウェブアプリケーション攻撃を具体的に分析したところ、86%が10年以上も前から文書化され、予防可能な脆弱性を悪用していたことです。私たちは、高度な攻撃者に負けているのではありません。私たちは、基本を無視している自分自身に負けているのです。

誰もが引っかかる認証の罠

認証についてお話ししましょう。ここで私は開発者が最初の重大なミスを犯すのをよく見ます。彼らは認証を全体のセキュリティモデルの基盤ではなく、チェックボックス機能として扱っています。ある時、開発者がユーザーのメールアドレスがクッキーに存在するかをチェックして認証を実装したコードをレビューしたことがあります。署名されたクッキーでも、暗号化されたトークンでもなく、誰でもブラウザの開発者ツールで変更できるプレーンテキストのメールアドレスでした。

私がこれを指摘したとき、開発者は「でも動いているじゃないか！」と言いました。そしてまさにそれが問題なのです。セキュリティ脆弱性はエラーメッセージで自らを知らせることはありません。誰かがそれを悪用するまで、完璧に機能します。

適切な認証には実際に何が必要かを説明します。まず、認証（自分が誰であるかを証明すること）と認可（自分が何をすることを許可されているかを証明すること）の違いを理解する必要があります。これらの概念が非常に混乱しているプロダクションシステムを見たことがあります。そのため、一つのセキュリティ問題を修正すると、三つの新たな問題が生じることがありました。

パスワードの保存は譲れません。bcrypt、scrypt、またはArgon2のような適切なパスワードハッシュアルゴリズムを使用しなければなりません。SHA-256でも、MD5でもなく、間違いなくプレーンテキストでもいけません。2026年になっても、パスワードがプレーンテキストで保存されているデータベースに出くわすことがありますが、そのたびに開発者は「誰も実際にハッキングを試みるとは思わなかった」と言います。それは、誰もあなたを実際に襲うとは思わずに玄関のドアを鍵のかからない状態にしておくようなものです。

ここでの数字は厳しいです。2023年のアイデンティティ盗難リソースセンターの報告によれば、米国だけで3,205件のデータ侵害があり、3億5,300万人以上の被害者に影響を与えました。研究者が侵害されたデータを分析したところ、パスワードの保存方法が開示されている場合、43%が不十分なハッシュ化またはまったくハッシュ化されていないことがわかりました。

セッション管理は興味深いところです。暗号的に安全なランダムなセッショントークンを生成する必要があります。ほとんどの言語にある組み込みの乱数ジェネレータは、暗号的に安全ではありません。Node.jsでは、Math.random()ではなくcrypto.randomBytes()を使用したいです。Pythonでは、random.random()ではなくsecrets.token_hex()を使用したいです。私はタイムスタンプとユーザーIDを結合して生成されたセッショントークンを見たことがあります。攻撃者は数秒でそれを予測できます。

あなたのセッショントークンは、少なくとも128ビットのエントロピーを持つべきです。HTTPSを介してのみ送信されるべきです。JavaScriptがアクセスできないようにHttpOnlyフラグが設定されるべきです。暗号化されていない接続を通じて送信されないようにSecureフラグが設定されるべきです。CSRF攻撃を防ぐためにSameSite属性が設定されるべきです。そして、有効期限が切れるべきです。私は敏感なアプリケーションには30分の非アクティブの推奨、低リスクのシナリオには24時間の提案をします。

クロスサイトスクリプティング: 決して死なない脆弱性

XSS攻撃はゴキブリのようです。彼らは永遠に存在していて、誰もがそれについて知っており、それにもかかわらず本番コードに出続けます。OWASPのトップ10には2003年の設立からXSSの脆弱性が含まれており、2026年にもまだ存在しています。これは21年間、同じ予防可能な脆弱性です。

「セキュリティは他のすべてをマスターした後に取り組むような高度なテーマではありません。これは基礎的なもので、赤信号が停止を意味することを理解せずに運転することのようなものです。」

私は医療アプリケーションを監査したことを覚えています。そのアプリケーションは、医師が入力した患者のメモを表示していました。開発者は基本的なフォーマットが可能なリッチテキストエディタを構築していました。合理的なように思えますよね？しかし、彼らはHTML入力を受け入れ、何のサニタイズもせずにそのままページにレンダリングしていました。私は、スクリプトタグを含む患者のメモを入力することで脆弱性を示しました。そのスクリプトは、セッショントークンを盗んだり、医療記録を変更したり、患者データを流出させたりする可能性がありました。開発者たちはショックを受けていました。彼らは医者が悪意を持つかもしれないことや、医者のコンピュータが侵害されている可能性があることを考えたことがありませんでした。

基本的な原則は、ユーザー入力を決して信用しないことです。医者からも、管理者からも、CEOからも。外部からアプリケーションに入ってくるデータは、他に証明されるまで潜在的に悪意があります。

XSSには理解しておくべき3つのタイプがあります。ストアドXSSは、悪意のあるコードがデータベースに保存され、そのデータを誰かが表示するたびに実行されるものです。リフレクティッドXSSは、URLパラメータにある悪意のあるコードが即座にレスポンスに反映されるものです。DOMベースのXSSは、クライアントサイドのJavaScriptがユーザー入力を取り込み、適切にサニタイズせずにページに挿入するものです。

解決策は複雑ではありませんが、規律が必要です。コンテキストに基づいて出力をエスケープする必要があります。HTMLコンテンツにデータを挿入する場合は、HTMLエンティティエンコーディングが必要です。JavaScript文字列にデータを挿入する場合は、JavaScriptエスケープが必要です。URLにデータを挿入する場合は、URLエンコーディングが必要です。CSSにデータを挿入する場合は、CSSエスケープが必要です。

現代のフレームワークはこれを助けます。React、Vue、Angularは、すべてデフォルトで出力をエスケープします。しかし、これは魔法ではありません。ReactのdangerouslySetInnerHTMLやVueのv-htmlを使用すると、これらの保護をバイパスしています。私は、HTMLをレンダリングする必要があるときにこの機能を使用する開発者を見てきましたが、彼らはXSSの脆弱性を開いていることを理解していませんでした。

コンテンツセキュリティポリシーは、あなたの第二の防御線です。CSPは、ブラウザにどのコンテンツソースが合法であるかを伝えるHTTPヘッダーです。インラインスクリプトを完全にブロックしたり、JavaScriptをロードできるドメインを制限したり、さまざまなXSS攻撃を防ぐことができます。Googleの研究によると、厳格なCSPを実装することで約95%のXSS攻撃を防ぐことができます。しかし、私の経験上、私が監査するアプリケーションの30%未満がCSPを持っており、そのほとんどは非常に許可的で、実質的に役に立たないものです。

SQLインジェクション: まだ機能する古代の脆弱性

SQLインジェクションは絶滅すべきです。1990年代から十分に理解されています。ボビー・テーブルズは10年以上にわたるミームです。それにもかかわらず、Akamaiの2023年のインターネットの現状レポートによれば、SQLインジェクションの試みはすべてのウェブアプリケーション攻撃の65%を占めています。なぜでしょう？それはまだ機能するからです。

私はかつて、8年間ビジネスを営んでいたeコマース会社のコンサルティングを行っていました。彼らは何百万もの取引を処理していました。15人の開発者のチームがいました。そして、彼らの検索機能はSQLインジェクションに対して脆弱でした。コードはこんな感じでした：彼らはURLパラメータから検索用語を取り出し、それを直接SQLクエリに連結していました。パラメタイズはなく、入力の検証もなく、まったく何もありませんでした。

私がその脆弱性を示したとき、彼らは驚愕しました。