あるウェブサイトにアクセスし、ログインします。いつものように、購入したい商品をカートに入れます。ところが、手が滑ってブラウザのタブを閉じてしまったのです。慌ててブラウザにサイトのURLを入力し直し、「Enter」キーを押します。すると、ログインした状態でサイトに戻り、カートの中にはすべての商品が残っていました。ふう。

再認証しなくても、どうやってサイトがあなたのことを知っていたのですか？それは、セッションを使用しているからです。セッションは、Webサイトを利用する際にユーザーエクスペリエンスを向上させる重要な要素です。しかし、セッションの管理を誤ると、攻撃者に悪用されるセキュリティホールが発生します。

ここで、セッション管理とは何か、セッション管理が不十分だとどうなるか、セッションを適切に管理するためにはどうすればよいかを確認しましょう。

セッション管理の弱点を理解する

セッションとは、アプリケーションを使用する一人のユーザーに固有の、サーバーに保存された値のことです。これが必要な理由は2つあります。まず、HTTPはステートレスなプロトコルです。まず、HTTPはステートレスなプロトコルであり、各リクエストは個別であり、前後のリクエストを知ることはできません。セッションは、誰がリクエストを送ったかをサーバーが追跡するのに役立ちます。そうでなければ、ボタンやリンクをクリックするたびにログインする必要があります。

セッションが必要な2つ目の理由は、ユーザーの認証です。セッション識別子を使用して、システム内で特定の権利を持つ特定のユーザーを認識することができます。アプリケーションは、その人が誰なのか、何をすることが許されているのかを知ることができます。

セッションには2つの要素があります。サーバー側のデータストアには、セッション識別子が保存され、ユーザーIDやカート情報などのユーザーに関する情報にマッピングされます。同じセッション識別子は、クッキーでブラウザに送信されます。クッキーは、ブラウザによってユーザーのシステムに保存されます。クライアントは、リクエストごとにクッキーを渡し、このリクエストが同じユーザーからのものであることをサーバーに知らせます。ほとんどのアプリケーションでは、認証前と認証後の両方でユーザーを追跡するためにセッションを使用しています。

適切なセッション管理は、アプリケーションのセキュリティに不可欠です。有効なセッションIDは、ユーザ名/パスワード、あるいは第二因子認証トークンと同じレベルの信頼性を持っています。

セッション管理の不備が危険な理由

セッション管理が不十分だと、アカウントが完全に乗っ取られる可能性があります。つまり、顧客データが盗まれたり、商品が不正に購入されたりする可能性があるのです。攻撃者が有効なセッションIDを取得する方法はいくつかあります。

セッション固定化攻撃は、ユーザーがシステムにログインしたときなどの重要なタイミングでセッションが変更されず、URLを使ってセッション識別子が設定できる場合に発生します。このようにセッション識別子を設定すると、同じ認証ソースを使用する異なるアプリケーション間でユーザーのログイン状態を維持するために使用されることがあります。この場合、攻撃者は Web サイトを閲覧してセッション ID を取得します。次に、攻撃者は、セッション ID を記載した URL を、無防備な被害者に電子メールで送信します。犠牲者はメールに記載されたURLをクリックし、ウェブサイトにログインします。ログイン時にセッションIDがローテーションされていない場合、攻撃者は有効で認証されたセッションIDを持つことになります。これにより、アカウントの完全な乗っ取りが可能になります。

貧弱なセッション管理に対するもう一つの攻撃は、ブルートフォースによる推測攻撃です。開発者が独自のセッション管理システムを作成しようとすると、多くの場合、簡単に推測できるようなセッションIDを使用します。セッションIDは、（1、2、3）のように連続していたり、ある種の予測可能なパターンであったりします。攻撃者は、有効なセッションIDが見つかるまで、単純にセッションIDを推測し続けます。これは、アカウントの乗っ取りにもつながります。

一定の時間が経過しても自動的に無効にならないセッションを悪用して、ユーザーを攻撃することができます。クロスサイトリクエストフォージェリ攻撃が成功するかどうかは、ユーザーがサイトを離れた後も有効なセッションがあるかどうかにかかっています。例えば、ユーザーが訪れたサイトに、攻撃者がiframeや画像を設置したとします。src」（ソース）属性には、脆弱なサイトのURLが設定され、ユーザーに代わってアクションを実行します。例えば、脆弱な銀行アプリケーションを利用して、ユーザーの許可なく攻撃者の口座に送金させることができます。

セッション管理は厄介なもので、弱点があると壊滅的な被害を受けます。しかし、これはよく知られた問題であり、解決することができます。

不安定なセッション管理の解消

セッション管理は、あらゆるウェブアプリケーションの中核をなすものです。そのため、多くのウェブ開発フレームワークには、セッション管理機能が組み込まれています。これらのシステムは、専門家によって精査され、問題点が発見され、排除されています。使ってみてください。

優れたセッション管理には、以下のような共通点があります。

     攻撃者が推測できないランダムなセッションIDの生成

     ユーザーがログアウトするとセッションが無効になる

     一定の時間が経過すると自動的にセッションが無効になる

     ユーザーがログインするとセッションIDが変更される

     ブルートフォースアタックを防ぐために128ビット以上のセッションIDを設定

Spring、ASP.NET Core、Rails、Djangoなどのウェブフレームワークは、このような特性を持っており、このような場合、より高いセキュリティ標準のために使用されるべきです。

結論から言うと独自のセッション管理システムをゼロから作るのはやめましょう。

セッションIDが作成されたら、それを保護する必要があります。セッション・クッキーには、Secure および HttpOnly フラグを "true" に設定します。これにより、JavaScript で値を取得することができなくなります。また、ブラウザは HTTPS 経由でのみクッキーを送信するため、攻撃者が送信中に誰かのセッションを盗むことを防ぎます。

セッションの保護

セキュアなセッション管理の詳細については、無料のラーニングリソースをご覧ください。セッションを保護する方法を学ぶことで、セキュリティ侵害によるユーザーアカウントの乗っ取り、評判の低下、収益の低下を防ぐことができます。セッションを保護して、ユーザーの安全を確保しましょう。

パディング・オラクルは、オルタナティブ・ロック・バンドの悪い名前のように聞こえますが、実際には、攻撃者が暗号化キーを知らずに情報を解読するために使用できる脆弱性です。

攻撃者にとっての全体的な難易度という意味では、この問題は最上位に近いものです。魔法のような復号化ボタンではなく、ハッカーは、送られてきたセルのパディングに関するエラーメッセージを調べ、暗号化されたデータがどこで終わり、パディングが始まるのかを判断するために、手間のかかる作業を行います。そして、暗号化されたデータの中のさまざまなビットを見つけ出し、十分な時間と情報があれば解読できるかもしれません。

ありがたいことに、比較的簡単な手順で、攻撃者がパディング・オラクルを使って暗号化されたデータを解読する能力を取り除くことができます。このエピソードでは、次のことを学びます。

• その仕組み
• なぜこの脆弱性が危険なのか
• それを防ぐために、どのような防御策を講じることができるのか。

Padding Oracleの仕組みは？

CBC（Cipher Block Chaining）とは、データベースに保存されているセルなどの一連の情報全体を、その情報の連鎖全体に適用される暗号鍵を用いて暗号化するブロック暗号の作成方法です。CBCを使用した場合、1つの暗号文ブロックの暗号化は、それ以降のすべてのブロックに依存します。理論的には、ブロックの順序を変えただけでもデータが破壊されてしまうため、非常に強力な暗号化となります。

CBC暗号（およびその他のブロック暗号）の問題点は、正確なサイズのブロックを使ってしか暗号化できないことです。通常、暗号化は8バイトまたは16バイトのサイズで行われます。では、CBCが2バイトのデータを16バイトの暗号文単位に収める必要がある場合はどうなるでしょうか。CBCは、パディング（基本的には無意味な文字）を使って隙間を埋め、適切なサイズのユニットを作ります。

ほとんどのパディング方式はよく知られており、その中でもPKCS#7は最もよく知られている方式の一つです。そのため、攻撃者はどのようなパディングが使用されているかを知っているかもしれません。例えば、CBCがブロック内の5文字をパディングする必要がある場合、PKCS#7では、平文の後に0x05というバイト値を5回繰り返す。

攻撃者は、CBCとパディング方式に関する知識を利用して、ホストサーバ（オラクルとも呼ばれる）にクエリを送信します。適切なツールにアクセスできれば、クエリのパディングが間違っているかどうかをサーバに教えさせることができるかもしれません。そのためには、パディングが正しいとサーバーから言われるまで、暗号の各バイトを0から255まで循環させます。そして、次のユニットに移動してこのプロセスを繰り返し、すべてのケースでパディングがどこから始まるかを記録するのです。

この方法では、メッセージやセルを解読することはできませんが、平文がどこで終わり、パディングがどこで始まるのかという点で、チェーンのすべてのリンクをマッピングすることができます。また、XOR計算を使って、元の平文の最後のバイトの値を把握できる可能性もあります。

Padding Oracleはなぜ危険なのか？

ハッカーが暗号化の解除に多大な労力を費やす理由は、潜在的な報酬があるからです。価値のないものを暗号化する人はほとんどいません。ホスト組織にとっての危険度は、侵害されるデータによって異なります。例えば、パスワード、ユーザーアカウント、財務情報、クレジットカード番号、患者の記録、機密通信など、非常に求められている貴重な情報が含まれています。

パディング・オラクルを使うことは、その後の攻撃の入り口にもなります。例えば、攻撃者がパディング・オラクルを使ってパスワードを盗むことができれば、権限を昇格させてネットワークの奥深くに侵入することは簡単な二次的作業となります。

誰もが暗号化を、盗聴や漏洩に対する究極の防御と考えています。しかし、暗号化の科学と、それを破ろうとする者との間には、何世紀にもわたって一進一退の攻防が繰り広げられてきました。パディング・オラクルは、攻撃者に有利な方法の1つに過ぎません。

パディングオラクル攻撃のハードランディング化

ありがたいことに、パディング・オラクルを防ぐ方法はいくつかあります。その一つは、ガロア/カウンタモード（GCM）やオフセットコードブックモード（OCB）など、より強力な暗号化演算モードを使用することです。GCMは、CBCとは異なり、128ビットの暗号ブロックサイズを使用しています。CBCとの違いは、暗号ブロックサイズが128ビットであることと、データブロックごとにカウンターを使用し、その数字を使って暗号文を作成することです。つまり、パディング・オラクル攻撃の影響を受けないというわけだ。

優れたエラー処理制御を実装することで、攻撃者が成功する可能性を大きく減らすことができます。パディング・オラクル攻撃は情報漏洩に依存しているため、暗号化/復号化の失敗時には特定のパディングエラーではなく、一般的なエラーメッセージを返すようにしてください。

また、メッセージ認証コード（MAC）を実装することもできます。MAC値は、検証者が秘密鍵を使ってメッセージ内容の変更を検出することで、データの完全性と真正性を保護します。

最後に、すべてのパディング・オラクル攻撃は、繰り返しクエリを必要とします。1つのセルのパディング方式を知るためには、チェーンで保護されている情報のユニット数を掛け合わせた200以上のリクエストが必要になります。同一ソースからのリクエスト数を制限することで、攻撃者が実際に攻撃を開始する前にアクセスを拒否することで、パディング・オラクル攻撃をシャットアウトすることができます。

パディングオラクルのさらなる研究

攻撃者が機密情報を解読する方法は、本当に悪夢のようなものです。しかし、そのような事態を未然に防ぐための良い方法がいくつかわかったのではないでしょうか。

さらに読みたい方は、パディング・オラクルのOWASP定義とチェックリストをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

今すぐ、パディング・オラクルの攻撃を阻止することができると思いますか？Secure Code Warrior のプラットフォームで試してみてください。

ほとんどのコンピューターシステムでは、LDAP（Lightweight Directory Access Protocol）が使われている。LDAPは、インターネット・プロトコル（IP）ネットワーク上で分散型ディレクトリ情報サービスを維持するために使用されます。つまり、基本的にはユーザーを管理するための手段として機能しています。

LDAPは、アプリケーションがユーザーに様々なアクションを実行する権限があるかどうか、特に組織内で定義された役割に関連しているかどうかを確認するための認証ソースとしてよく使用される。例えば、経理担当者だけが会社の会計ソフトを使えるようになっているかもしれない。アプリケーションは、LDAPテーブルをチェックして、ユーザーが確立された権限の範囲内で行動していることを確認するようにプログラムされることが多い。

悪意のあるユーザーがLDAPクエリを操作すると問題が発生します。これにより、受信側のサーバーを騙して、通常は許可されない無効なクエリを実行させたり、パスワードを持たない無効なユーザーやセキュリティの低いユーザーにハイレベルまたは管理者のアクセスを許可したりすることができます。  

LDAPインジェクションは厄介なものですが、このエピソードでは、それを学びます。

• 仕組み
• なぜ彼らは危険なのか
• それを阻止するためには、どのような防御策を講じるべきか。

攻撃者はどのようにLDAPインジェクションを利用するのか？

LDAPベースの攻撃が長年にわたって人気を維持している理由の1つは、ほとんどすべてのコンピュータシステムがLDAPを使用しているという事実です。LDAPはオープンソースで、非常によく機能するため、代替手段があまり作られていません。

LDAPは、IPベースのコンピューターシステムやネットワーク内の有効なユーザーを追跡するデータベースであることがその核心である。ユーザーは、システム、ネットワーク、サーバー、アプリケーション、さらには同じネットワーク上の他のユーザーに関する情報を共有することができます。

LDAPでは、データベースの行やレコードに相当する情報が保存されており、これを識別名と呼びます。各DNはユニークです。例として、大企業のシカゴ会計事務所に勤務するユーザーのDNは次のようになります。

cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview  

各 DN が一意であることを保証するために、レコードに「+」、「/」、「=」などのさまざまなコードを追加することができます。また、レコードの前後にスペースを挿入することで、シカゴ・パークビューオフィスのコーポレートアカウントで働くジェームス・スミスが2人いたとしても、それぞれが個別のDNを持つことができます。

アプリケーションでは一般的にLDAPを使用して、ユーザーが特定のDNに関するクエリを送信できるようにしています。例えば、小切手にミスがあったことを相談するために、給与部の正しい連絡先を見つけようとする場合などです。LDAPインジェクションは、検索クエリでユーザーが提供したパラメータの検証が行われていない場合に起こる可能性があります。その場合、ハッカーは良性の検索を操作して、認証メカニズムを回避したり、追加の任意のクエリを実行したりすることができます。これにより、サーバーを騙して、ユーザーのパスワードなど許可されていないはずの結果を表示させたり、有効なパスワードの有無にかかわらず、ネットワーク内のセキュリティの高い領域へのアクセスをアプリケーションに許可させたりすることができます。

なぜLDAPインジェクションは危険なのか？

LDAPインジェクションの最大の危険性は、世界中の大半のIPコンピュータ・ネットワークにLDAPプロトコルが普及していることにある。情報を盗んだり、ネットワーク上で自分の権限を高めたりしたいと考えているハッカーにとって、LDAPは容易な足がかりとなる。訓練されたハッカーであれば、LDAPインジェクションが可能かどうかをチェックしないことはないので、セキュリティチームはその穴が常に閉じられていることを確認しなければならない。

具体的には、組織内のユーザーやグループに関する限定的な情報、あるいはDNに含まれるその他の情報を、有効なユーザーが見つけられるようにプログラムされたアプリケーションがかなりある。例えば、あるアプリケーションでは、LDAPを使ってシカゴで働く企業の会計士の連絡先情報を検索できるようになっており、上記の例では友人のJames Smithが返される。パーミッションにもよりますが、これはLDAPクエリーの完全に有効な使用法と言えます。

危険なのは、悪意のあるユーザがクエリにフィルタリングされていないパラメータを追加し、検索の性質を変え、通常は提供されるべきでない情報を提供するようにサーバを騙した場合です。例えば、user=*という文字列を追加すると、攻撃者は、組織全体のすべてのユーザーに関する情報を取得することができます。

認証にLDAPを使用しているアプリケーションでは、問題はさらに悪化する可能性があります。攻撃者は、例えば、LDAP クエリの最後にある (&) 文字列を使用して、引数が真であるとサーバーに思わせることができます。アプリケーションがパスワードの検証にLDAPを使用している場合、LDAPインジェクションによって引数を強制的にTrueにすると、パスワードがなくても、権限のないユーザーが管理者としてネットワークにログインできる可能性があります。

ネットワークでLDAPインジェクションをL-DON'Tにする

LDAPインジェクションを防止する最善の方法の1つは、LINQtoADなど、LDAPインジェクションに対抗するために特別に設計されたフレームワークを実装することです。ネットワーク上にLDAPクエリを利用するアプリケーションがすでに存在する場合は、これができないこともある。しかし、そのような場合でも、新しいアプリケーションには、インジェクション耐性のあるフレームワークを使用することをお勧めします。

LDAPを使用する既存のアプリケーションでも、ホワイトリストの検証や入力のサニタイズを行うことで、インジェクションに対する耐性を高めることができます。可能であれば、ユーザーの入力を限られた信頼できる値のセットに制限してください。そうでない場合は、LDAP クエリの一部であるユーザーの入力を最初にサニタイズする必要があります。また、GET および POST パラメータ、Cookie、HTTP ヘッダーも攻撃のベクターとして機能することがあるので、これらを含めることを忘れないでください。入力のサニタイズを行うために独自の関数を書かないでください。代わりに、信頼できるサードパーティのセキュリティに特化したライブラリやフレームワークの組み込みAPIを使用してください。

対象となる対策だけでなく、ネットワーク上で必要最小限の権限を持つLDAP照会アプリケーションを割り当てるなど、適切なコンピューティング・プラクティスを行うことも有効です。これにより、万が一、LDAPインジェクションが通過してしまった場合でも、その被害を軽減することができます。

LDAPインジェクションの詳細情報

さらに読みたい方は、OWASP の LDAP インジェクションに関する記事や、インジェクション防止のためのチートシートをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

Unrestricted File Uploads問題は、攻撃そのものではなく、攻撃者がアプリケーションやネットワークリソースに容易にアクセスできるような一般的な状況や状態のことを指します。これは、寒さの中で濡れた服を着て歩くようなものだと考えることができます。濡れた服を着ていても、それだけで病気になるわけではありませんが、日和見のウイルスが体の防御力を簡単に超えてしまうほど抵抗力が低下してしまいます。

サイバーセキュリティの分野では、無制限のファイルアップロードをサポートしているアプリケーションやプログラムがあると、攻撃者はすぐにそれを悪用します。そして、その結果は壊滅的なものになる可能性があります。巧妙な攻撃者は、その無制限のアクセスを利用して、悪意のあるファイルをアップロードしたり、認証情報を盗むためのスクリプトを設定したり、アプリケーション自身の権限を利用してネットワークに深い攻撃を仕掛けたりすることができます。比較的単純な攻撃者であっても、このような自由なアクセスを利用して、サービス拒否攻撃を行ったり、アプリケーションをクラッシュさせたりすることができます。

幸いなことに、「アップロード制限のないファイル」の問題を解決する方法はいくつかあり、攻撃者を阻止することができます。そのため、ここでは「アップロード制限のないファイル」の3つの重要な側面について説明します。

• 仕組み
• なぜ彼らは危険なのか
• それを阻止するためには、どのような防御策を講じるべきか。

無制限のファイルアップロードを悪用した攻撃方法とは？

一般ユーザーがファイルをアップロードできるようにしたい理由はさまざまです。例えば、企業が人材を採用する際に、応募手続きの一環として履歴書をアップロードできるようにしたい場合。銀行では、ローンや新規口座開設などの重要な書類を自宅で記入してもらう。観光やソーシャルメディアのサイトでは、ユーザーが写真をアップロードして他の人と共有することができます。

ファイルのアップロードを許可する正当な理由はたくさんあります。そして、ほとんどの新しいアプリケーションは、デフォルトで、あらゆるタイプのファイルのアップロードを制限なしに許可するようになっています。問題は、潜在的な攻撃者が、アップロードに制限がないことに気付いたときに始まります。

アップロードに制限がないため、サイトは3つのタイプの攻撃を受けます。最も巧妙でないものとしては、悪意のあるユーザが、数百ギガバイトの情報を含むzip形式のアーカイブなどの巨大なファイルを単純にアップロードすることが挙げられます。これにより、帯域幅が制限されるだけでなく、アプリケーションに割り当てられた記憶領域がオーバーロードされます。

次の段階では、ウイルスやランサムウェアのような悪意のあるファイルをアップロードするユーザーが挙げられます。これは、吸血鬼を家に招き入れなければならないという、昔からある迷信のようなものです。誰でも自由に入れるというサインを出しておけば、ファイルのアップロードが無制限にできるのと同じです。ドアから何が入ってくるかはもうコントロールできませんし、すべての訪問者やファイルが良性のものではないことを想定すべきでしょう。中にはモンスターもいるかもしれません。

最後に、熟練した攻撃者は、無制限のアップロードを利用してネットワークへの足がかりを作り、より深い攻撃を行うことができます。誰かがアップロードできる内容には制限がないため、攻撃者はそのプロセスを通じて自分のウェブシェルを送信することができます。その後、自分のシェルにコマンドを送ることができ、そのコマンドはアプリケーションと同じ権限レベルでサーバ上で実行されます。

なぜファイルへのアクセスが制限されると危険なのか？

ファイルへのアクセスが制限されていないアプリケーションを導入することは、直ちに危険なことではありませんが、基本的には、サイバーセキュリティの防御に穴を開けて、誰かが組織を攻撃するのを誘うようなものです。遅かれ早かれ、誰かが反応するでしょう。

最も基本的なレベルでは、攻撃者は大惨事を引き起こすために多くのスキルを必要としません。非常に大きなファイルをZIP圧縮してアップロードするだけで、有効なユーザーのサービスを拒否することができます。時間が経てば、アプリケーションのプログラムやネットワークの状態によっては、アプリケーションやサイト全体がクラッシュする可能性もあります。

また、ファイルへのアクセスが無制限になると、ネットワークのファイアウォールやその他の保護機能に穴が開く可能性があります。攻撃者がマルウェアをコアネットワークに直接アップロードするための経路を作ってしまっては、受信メールや従業員のウェブ閲覧を監視するスキャナがあっても意味がありません。このマルウェアは、アプリケーションや、そのアプリケーションが動作しているサーバーをクラッシュさせるかもしれませんが、それはおそらく最良の結果です。最悪の場合、ランサムウェアのような真に悪質なプログラムは、侵害されたサーバを利用してネットワーク全体に拡散してしまいます。

より熟練した攻撃者であれば、ファイルへのアクセスが制限されていないアプリケーションを悪用しても、それほど目立つことはないでしょう。その代わりに、脆弱性を利用してアプリケーションを侵害し、それを利用してネットワークの奥深くに侵入し、ゆっくりと移動して検知されないようにします。これには、ウェブシェルやその他の.exeタイプのファイルをアップロードして、そのファイルに直接コマンドを送信する方法があります。ユーザーがシェルを介して実行するものは、通常、それをホストするアプリケーションに設定されているあらゆる許可レベルを使用して、サーバーによって実行されます。サーバーにとっては、これらのコマンドはアプリケーションから送られてきたものであり、それ以上のチェックや検査を受けることはありません。

これらのことから、無制限のファイルアクセスが可能な脆弱性は、ネットワーク上に存在する最も危険な脆弱性の一つと言えます。問題が発生するかどうかではなく、いつ問題が発生するかが問題となるでしょう。

ファイルアクセスが制限されていない」という脆弱性をなくすにはどうすればいいですか？

では、無制限のファイルアクセスの問題を解決するにはどうすればよいのでしょうか。最も簡単な方法は、アップロード可能なファイルの種類に制限を加えることです。例えば、Wordやテキストファイルしか受け付けないとか、画像共有サイトの場合は.jpや.gifしか受け付けないなど、必要に応じてユーザーに制限を伝えることができます。バックエンドでは、受け入れ可能なファイル拡張子のホワイトリストを作成し、それ以外のものは拒否する必要があります。また、ファイル名の最大長にも制限を設ける必要があります。また、ファイル名に特殊文字が含まれている場合は、実行可能なコマンドを起動しようとしている可能性があるため、同様に拒否する必要があります。

ファイルの種類や命名規則に加えて、各ファイルの最大サイズを制限したい場合もあります。最大サイズは、アプリケーションが収集するファイルの種類に応じた合理的で適切なものでなければなりません。例えば、Wordファイルの場合は10メガバイト程度、グラフィックファイルの場合は50メガバイト程度と、少し大きめのサイズを設定するとよいでしょう。最小ファイルサイズのルールを設定することも可能ですが、ユーザーが特定のフォームに記入してアップロードする場合など、想定されるファイルのサイズ範囲がよくわかっている場合に限られます。

攻撃者は、ファイルの種類やサイズの制限をかいくぐって、シェルやその他の悪意のあるプログラムを忍び込ませる巧妙な方法を見つけるかもしれません。そのため、収集したファイルは、実行権限のないプライベートなディレクトリに保存するようにしましょう。さらにセキュリティを高めるために、ファイルの名前をシステムがランダムな文字列に変更することができます。これにより、ネットワーク外からの不正なユーザーがアップロードされたファイルの場所を検索することを防ぎ、ネットワークへの偵察を行うことができるかもしれません。ただし、その場合には、ランダムなファイル名と元の指定を結びつけるテーブルを設定して管理する必要があるでしょう。

最後に、アップロードによってネットワークに到達したものは、組織がこれらのタスクのために使用しているあらゆる防御プログラムによって、マルウェアやウイルスをスキャンする必要があります。これにより、すべてを検出することはできないかもしれませんが、重要なセキュリティ層として、ファイルアップロード経由で侵入しようとする最も一般的な悪意のあるファイルの90％以上を検出することができます。

ファイルのアップロードが制限されていない問題を制限する

バックエンドにいくつかのセキュリティ層を設けると、無制限のファイルアップロードの問題は解消されます。基本的には、ファイルのアップロードに制限を設けることで問題を解消しているので、もはや無制限ではありません。良いファイルだけが内部に入り、吸血鬼やマルウェアはすべて野放しになります。

OWASP Unrestricted File UploadPrevention Cheat Sheetには、このような状況をネットワーク上で許してしまった場合の最も一般的な問題点がまとめられていますので、ぜひご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料ショーケースで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策について詳しく知りたい方は、Secure Code Warrior ブログをご覧ください。

今すぐにでもこの脆弱性に取り組む準備ができたと思いますか？戦場に赴き、自分のスキルを試してみましょう。

NoSQLデータベースの人気はますます高まっています。特に、開発チームがアジャイルな方法論に基づいて作業している場合には、非構造化データを扱う際のスピードと容易さを否定することはできません。

開発者が新技術の脆弱性やその他の課題を解決するには時間がかかります。本番環境での使用期間が長くなって初めて、問題が表面化します。

NoSQLデータベースも同様です。アプリケーションを安全に保つために、開発者が知っておくべき重要なリスクがあります。その一つがNoSQLインジェクションです。

ここでは、NoSQLインジェクションとは何か、どのような被害をもたらすのか、そしてどのように修正するのかを見ていきましょう。

NoSQLインジェクションの理解

NoSQLインジェクションは、XMLインジェクションやSQLインジェクションなどのインジェクション脆弱性と同じものが多く存在します。

NoSQL インジェクションにより、攻撃者は NoSQL クエリに任意のコマンドを入れることができます。これにより、データを盗んだり、権限が十分に高ければデータベースに変更を加えたりすることができます。

アプリケーションがユーザが制御するデータを直接NoSQLクエリ式に配置する場合、これらの式は多くの場合、データを盗んだり変更したりするために操作可能な関数を取ったり、組み込みの演算子を持っています。そして、そのようなことが悪意を持って実行された場合、悲惨な結果になる可能性があります。

MongoDBデータベースは、この脆弱性を悪用する最も一般的な遊び場の一つです。"$ne:""'は、SQLの世界では1=1に相当する演算子なので、例を挙げると、攻撃者は"$ne:""'をUIのユーザー名とパスワードのフィールドに入れることができます。もしそのコードがNoSQLインジェクションに脆弱であれば、データベースはユーザー名とパスワードが空の文字列に等しくないすべてのレコードを検索します。言い換えれば、全部です。やべぇ。

このデータベースが暗号化されていなければ、攻撃者はデータベース内のすべてのユーザーのユーザー名とパスワードを盗むことができます。これには管理者のユーザー名とパスワードも含まれ、データベース全体にアクセスできるようになります。

攻撃者はしばしば、常に真である値をパスインしようとします。また、関数に設定されているプロパティに悪意のあるコードを注入する攻撃もよく行われます。

たとえば、MongoDB の find 関数は $where というプロパティを持つオブジェクトを受け取ります。where プロパティには、true または false に評価されるべき関数が設定されています。ユーザーの入力によってこの関数が何らかの形で変更された場合、NoSQLインジェクションが潜んでいる可能性があります。

NoSQLインジェクションの複雑な仕組みについては、InfoQの記事をご覧ください。

NoSQLインジェクションが危険な理由を知る

NoSQLへのインジェクションが危険なのは、それに見合うだけの精査がセキュリティコミュニティからまだ受けられていないからです。

NoSQLインジェクションの影響は、従来のSQLインジェクションとほぼ同じです。データが盗まれたり変更されたり、データを盗むことでアカウントが侵害されたり、おそらく最も悪質なのは、削除コマンドが正常に発行された場合、データが完全に消去されてしまうことです。

要するに、MongoDBやその他のNoSQLデータベースエンジンは攻撃されやすいということです。"
ありがたいことに、コミュニティの中には注意を促している人もいます。しかし、より多くの開発者が自分たちのアプリケーションを、悪用されると大きな頭痛の種になるような、あまり知られていない厄介なものから守れるよう、自らを教育する必要があります。

NoSQLインジェクションを倒す

NoSQLインジェクションを撃退するのは困難です。残念ながら、SQLインジェクションのようにパラメータ化されたクエリという選択肢はありません。しかし、不可能ではありません。いくつかのオプションがありますので、参考にしてみてください。

• ファザーは、脆弱性を検出するための1つの手法として利用できます。しかし、人生の多くのことがそうであるように、最もシンプルなアプローチが最も効果的であることがあります。ここでは、古き良きコードレビューが最も強い味方となります。
• コードをレビューする際には、ユーザーの入力によって式の値が設定されたり、関数が変更されたりする可能性のある場所を探します。ユーザーの入力によってクエリが変更されないようにしましょう。
• ユーザーの入力は必ず正しいクラスにキャストしてください。数字であれば数字に、文字列であれば文字列に、というように。
• WHEREや類似のeval関数をユーザー入力と一緒に使用しないでください。ほとんどの場合、データモデルやスキーマを変更することで回避することができます。
• MongoDBのドライバにMongooseを使ってみましょう。Mongoose では、NoSQL データベースのスキーマを定義することができます。Mongooseに入力が文字列であることを伝えれば、文字列にキャストされます。つまり、攻撃者から渡されたオブジェクトは、オブジェクトとしてではなく、文字列として扱われることになります。
• DBを強化しよう権限の低いユーザーアカウントを作成し、クエリの実行時間を最大化し、常に組織に適用されるセキュリティのベスト・プラクティスに従ってください。

NoSQLデータベースの使いやすさの欠点は、開発者がセキュリティを考えずに立ち上げて使い始める傾向があることです。

NoSQLデータベースを安全に立ち上げ、NoSQLインジェクションから身を守る方法を時間をかけて学ぶことが不可欠です。

例えば、MongoDB Enterprise Editionには、ドキュメントに対する高度なアクセスコントロール機能があります。最小限の特権」を行使することは、万が一、アプリケーションに脆弱性が見つかった場合に備えたDiD（Defense in Depth）戦略として有効です。

まとめますと、以下のようになります。

• NoSQLのクエリ式で使用する前に入力をサニタイズする
• マングースのように、あなたを助けてくれるドライバーを使う
• クエリの中で入力データがどのように使用されているかを具体的に調べるコードレビューの実施
• ファザーやスキャナーを使って、コードの脆弱性を見つけることができます。

NoSQLはNo Injectionsではない

NoSQL データベースは、そのスケーラブルな機能とセットアップの速さから、急速に人気を集めています。しかし、その新しさゆえに、開発者はセキュリティ対策を考えずにNoSQLデータベースを使ってしまうことがあります。

NoSQLデータベースは、SQLデータベースと同様にインジェクション攻撃に対して脆弱な場合がありますので、慎重に行動し、クエリに注意を払ってください。さらに詳しく知りたい方は、ラーニングリソースをご覧いただくか、無料デモでスキルをお試しください。

事前に準備しておけば、アプリケーションでのNoSQLインジェクションを心配する必要はありません。簡単すぎる！？

今すぐNoSQLインジェクションを見つけ、特定し、修正する準備ができていると思いますか？セキュアコードの世界に飛び込んでみませんか？

これで2018年は終わりです。これが今年最後の記事となりますが、次回のCoders Conquer Securityガイドは2019年1月10日にお届けします。それでは、またお会いしましょう

Webサイトやアプリケーションの運営者を狙った攻撃とは異なり、多くのクロスサイトリクエストフォージェリ（CSRF）攻撃の目的は、ユーザーから直接、金品や認証情報を盗むことにあります。これは、サイト運営者がCSRFコードの脆弱性を無視すべきだということを意味するものではありません。純粋に金銭的な攻撃の場合、最終的に盗まれた資金の補充は、安全でないコードを持つホスティングサイトの責任となる可能性があるからです。また、標的となったユーザーが認証情報を紛失したり、知らないうちにパスワードを変更されたりした場合、特に被害者が特権的なアクセス権を持っている場合には、犯罪者は盗んだIDを使って大暴れすることができるかもしれません。

CSRF攻撃はかなり複雑で、成功させるためには複数のレイヤーに依存します。言い換えれば、この攻撃を成功させるためには、多くの要素が攻撃者に有利に働く必要があります。しかし、CSRF攻撃は、成功すればハッカーに直接お金を渡したり、サイト内を自由に動き回れるようにしたりできるため、非常に人気の高い攻撃手段です。すべてがハッカーの思惑通りに進めば、標的となったユーザーは攻撃の被害に遭ったことにさえ気づかないかもしれません。

しかし、CSRF攻撃を成功させるためには多くの要素が必要であるため、攻撃を阻止するための優れた防御技術がいくつかあります。

そのために、CSRF攻撃の3つのポイントについて説明します。

• 仕組み
• なぜ彼らは危険なのか
• 彼らを冷遇するための防御策を講じることができます。

CSRF攻撃の仕組みは？

CSRF攻撃が成功すると、標的となるユーザーから金品や認証情報を直接盗むことができるため、その作成には多大な労力を要するにもかかわらず、人気があります。また、さまざまなプラットフォームで試行されることが多いため、長年にわたってさまざまな名前や称号が付けられてきました。CSRF攻撃は、XSRF、Sea Surf、Session Riding、Cross-Site Reference Forgery、Hostile Linkingなどと呼ばれることもあります。マイクロソフトは、ほとんどのドキュメントでこれらをワンクリック攻撃と呼んでいます。しかし、これらはすべてCSRF攻撃であり、その対策方法も同じです。

CSRF攻撃は、ユーザーがサイトにログインしてビジネスや仕事をしているときに起こります。重要なのは、ユーザーがウェブサイトやアプリケーションにログインし、積極的に認証されていることです。この攻撃は通常、二次的なウェブサイトや電子メールから行われます。多くの場合、攻撃者はソーシャルエンジニアリング技術を使用してユーザーを騙し、攻撃スクリプトが置かれた危険なWebサイトに誘導する電子メール内のリンクをクリックさせます。

侵害されたウェブサイトには、アクティブなブラウザにコマンドを実行するよう指示するスクリプトが含まれています。通常は、ユーザーのパスワードを変更したり、攻撃者が管理する口座に送金したりするような悪質なものです。ユーザーが認証されている限り、サイトはそのコマンドが認証されたユーザーによって発行されたものであると考えます。なぜそうしないのでしょうか？ユーザーはすでに自分自身を認証し、サイトにアクセスするために必要なパスワードを提供しています。また、ジオフェンス内にいて、オフィスの端末に座っているかもしれません。パスワードの変更や送金をしたいと思ったとき、それを要求したのが本人であると信じない理由はないだろう。

この攻撃の要素を分解してみると、なぜこの攻撃が攻撃者にとって非常に難しいものであるかがわかります。まず、攻撃が行われるサイトでは、ユーザーが積極的に認証を受ける必要があります。ユーザーがブラウザのセッションを終了したり、ログオフしたりした後に、攻撃スクリプトを含むメールが届いた場合、攻撃は失敗します。

また、攻撃者は、そのサイトがどのようなスクリプトを受け入れるかを知るために、標的となるサイトで多くのリコンを行う必要があります。攻撃者は被害者の画面を見ることができず、ウェブサイトからのフィードバックは攻撃者ではなく被害者に送られます。攻撃者は、被害者の口座に突然お金が入ってくるなど、攻撃が成功した証拠を見ることができなければ、攻撃が成功したかどうかもすぐにはわかりません。

CSRF攻撃を実行するためのコードは、攻撃時にユーザーがログインしていること、標的となるサイトがどのようなスクリプトを受け入れるかを知っていることという、難しいようでいて不可能ではない条件の中で、サイト自体によって異なりますが、非常にシンプルなものになります。

例えば、銀行や金融機関のアプリケーションが、以下のようにGETリクエストを使って送金するとします。

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

このコードは、NancySmith12というユーザーに100ドルを送金するリクエストを送信します。

しかし、ターゲットとなったユーザーが、同僚を装ったメールを受け取った場合、クリック操作にCSRF攻撃スクリプトが埋め込まれる可能性があります。

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

ターゲットとなったユーザーがソーシャルエンジニアリングリンクに引っかかり、ファイナンスアプリケーションのブラウザセッションがまだ開いている間にリンクをクリックすると、ブラウザはアプリケーションにShadyLady15の口座に10万ドルを送金するように要求します。

このスクリプトは、ユーザーには見えないが、ブラウザがリクエストを行うきっかけとなるような不可視の画像の中に隠すこともできます。

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

結果は同じです。ShadyLady15は、誰にも攻撃を検知されずに10万ドルを手に入れます。

なぜCSRFは危険なのか？

CSRF攻撃は、ランサムウェアが流行し続けているのと同じ理由で、現在人気があります。CSRF攻撃は、攻撃者と被害者の資金の間のホップが非常に少ないのです。ランサムウェア攻撃では、システムが暗号化され、ユーザーはそのデータを解読するために金銭を要求されます。CSRF攻撃では、さらに少ないステップで攻撃を行うことができます。CSRF攻撃が成功すると、被害者は知らないうちに攻撃者にお金を送ってしまいます。

CSRF攻撃が成功すると、被害者の金銭や企業の財務に対する直接的な攻撃だけでなく、有効なユーザーを使ってネットワークを侵害することができます。もし攻撃者がCSRF攻撃を利用して管理者のパスワードを変更したとしたらどうでしょう。攻撃者はすぐにそのパスワードを使用して、データの盗み出し、ネットワーク防御の穴を開け、バックドアをインストールすることができます。

CSRF攻撃を成功させるには、多大な労力とある程度の運が必要ですが、ハッカーにとっては、最終的な目的にかかわらず、宝くじに当たるようなものです。ネットワークを攻撃する場合、他のほとんどの種類の攻撃では、SIEMやサイバーセキュリティ担当者のレーダーに映らないようにしながら、何ヶ月もかけてじっくりと偵察する必要があります。これに対して、CSRF攻撃は、サイバーキルチェーンのいくつかのステップをスキップして、最終的な目標に非常に近いところからスタートさせることができます。

CSRF攻撃を防ぐにはどうすればいいですか？

一般的な脆弱性とは異なり、CSRF攻撃では、コードではなく、攻撃者が作成したエクスプロイトを利用して、ユーザーが望まない、あるいは知らないリクエストをブラウザにさせることができます。しかし、これらの攻撃は防ぐことができます。

最良の方法の1つは、新しいセッションが生成されるたびに、開発者がユーザーのIDにCSRFトークンを追加することです。このトークンは、ユニークでランダムな文字列で構成され、ユーザーからは見えないようにする必要があります。次に、新しいリクエストが送信されるたびにサーバがチェックするフォームに、CSRFトークンのリクエストを隠しフィールドとして追加します。ユーザーのブラウザを介してリクエストを送信する攻撃者は、隠されたトークン・フィールドについて知ることもできず、ましてやそれが何であるかを知ることもできないので、リクエストはすべて失敗します。

さらに簡単な方法で、プログラミングをあまり必要としないものは、パスワード変更要求や送金注文のような機密性の高いものにCaptchaチャレンジを追加することである。これは、リクエスト者がロボットでないこと、あるいはこの場合はCSRFスクリプトでないことを確認するボタンを1つクリックしてもらうだけの簡単なものである。攻撃者はこのチャレンジに対するレスポンスをスクリプト化することができないので、送金リクエストのようなことを最初に行わずに突然CAPTCHAチャレンジを受けたユーザーは、何かが起きていることに気づくだろう。あるいは、組織がセキュリティの名の下にどれだけ作業を遅らせたいかにもよるが、スマートフォンのようなサードパーティトークンを使ったワンタイムパスワード生成も利用できる。

最後に、鉄壁ではありませんが、Microsoft EdgeやGoogle Chromeなどの多くのブラウザには、ローカルユーザ以外からのリクエストをブロックする同一オリジンポリシーの制限が設けられています。ユーザーにこれらのブラウザの最新バージョンを使ってサイトにアクセスしてもらうことで、開発チームに負担をかけることなく、CSRFのセキュリティをさらに強化することができます。

CSRFの扉を閉める

しかし、なぜこのような攻撃が行われるのか、また、どのようにしてネットワークから遮断すればよいのかをご理解いただけたのではないでしょうか。

さらに詳しい情報は、OWASP Cross-Site Request Forgery Prevention Cheat Sheetをご覧ください。また、セキュリティに関する知識を深めたい方は、以下のブログをご覧になり、この脅威に対抗する方法を学んでください。 Secure Code Warriorブログをご覧ください。

新しいディフェンスの知識を試す準備ができたと思いますか？Secure Code Warrior プラットフォームの無料デモで遊んでみてください。

クロスサイト・スクリプティング（XSS）は、2000年代初頭からセキュリティ専門家の悩みの種であったが、悲しいことに、数十年経った今でも、最も一般的なコードレベルの脅威の1つとして登録されている。この種のソフトウェアの脆弱性は、あまりにも長い間私たちを悩ませてきたが、CISAからの最近の警告は、彼らのSecure-by-Design運動の一環として、これをきっぱりと阻止しようとしている。開発者主導のセキュリティにスポットライトを当てることで、その針を動かし、変化をもたらすことができるのだが、それには開発者をセキュリティの成功に導く賢明な企業のコミットメントが必要だ。



ウェブブラウザは、オンライン上のあらゆる素晴らしいものへの入り口かもしれませんが、悲しいことに、良いニュースばかりではありません。ウェブブラウザ固有の動作が、セキュリティ脆弱性のきっかけになる可能性があるのです。ブラウザは当初、目にしたマークアップを信頼し、何の疑問も持たずに実行するという特徴を持っていました。そして当然のことながら、攻撃者は最終的にこの傾向を悪用し、邪悪な目的を達成する方法を見つけるのです。

クロスサイト・スクリプティングは、ブラウザの信頼とユーザーの無知を利用して、データを盗んだり、アカウントを乗っ取ったり、ウェブサイトを改ざんしたりします。これは、非常に醜く、非常に速くなり得る脆弱性です。

XSSがどのように機能するのか、どのような被害をもたらすのか、そしてどのように防ぐのかを見てみましょう：

XSSの仕組みは？

XSSは、信頼されていない入力（多くの場合、データ）がページの出力として表示されているにもかかわらず、実行可能なコードと誤認されることで発生します。攻撃者は、入力パラメータの中に悪意のある実行コード（HTMLタグやJavaScriptなど）を置くことができ、ブラウザに返されたときに、データとして表示されるのではなく実行されてしまいます。

前述のとおり、この脆弱性は、データと実行コードを区別することが難しいブラウザの中核的な機能の動作に起因しています。Webの動作モデルは次のようになっています。

1. ユーザーがWebページにアクセスする
2. ページでは、どのファイルを読み込み、何を実行するかをブラウザに伝えます
3. ブラウザは、ページに書かれていることを問答無用で実行する

この機能のおかげで、私たちがウェブで楽しんでいる最も素晴らしいインタラクティブな体験のいくつかが生まれました。

攻撃者が悪意のあるスクリプトを脆弱なサイトに追加すると、何の疑いもなく実行されてしまいます。より深い調査も、検知手段も用意されていません。

XSSには3つのタイプがあります。

• ストアドXSS
• 反射型XSS
• DOM XSS

Stored XSSは、攻撃者がアプリケーションのデータフィールド（ユーザの携帯電話番号を格納するフィールドなど）に悪意のあるスクリプトを持続的に格納できる場合に発生します。

このタイプの攻撃は、フォーラムサイトやコメントエンジンでよく見られます。攻撃者がコメントに悪意のあるスクリプトを入力すると、そのコメントを見たすべてのユーザが知らず知らずのうちにそのスクリプトを実行してしまいます。

反射型XSSは、ユーザの入力がそのままユーザのブラウザに反映されることで発生します。

ここで、検索結果を取得する際に、ユーザに「You searched for ...」と表示する検索ボックスがあったとしましょう。悪意のある攻撃者は、同じパラメータに悪意のあるスクリプトを埋め込んだリンクを被害者に送ることができますが、正直なところ、ほとんどのウェブユーザはそれに気づきません。

被害者がリンクをクリックすると、フィッシングサイトにリダイレクトされ、知らず知らずのうちにそのサイトのパスワードを入力してしまいます。

DOM XSSは、この脆弱性の中でも比較的新しいものです。

これらのテンプレートは、動的なコンテンツやリッチなUIアプリケーションを可能にします。誤った使い方をすると、XSS攻撃の実行に利用されてしまいます。

以上、XSSの範囲について説明しました。XSSの範囲を簡単にご理解いただけたと思います。それでは、XSSがどのように破壊的に使用されるのか、さらに深く掘り下げてみましょう。

なぜXSSは危険なのか？

XSSは、ユーザーを悪意のあるサイトにリダイレクトしたり、クッキーを盗んだり、セッションデータを探したりするのに使われます。基本的に、JavaScriptでできることはすべて、XSS攻撃でも可能です。

XSS攻撃の例を3つ紹介します。

1. ヤフーのメールユーザーは、2015年にXSSを使ってセッションクッキーを盗まれました。
2. Samy ワームは、MySpace の XSS 脆弱性を利用して配布されました。わずか20時間で100万人のユーザーに影響を与えたこのワームは、今でも史上最速の拡散力を誇るマルウェアです。
3. eBayでは、商品説明文に悪意のあるスクリプトが含まれることがありました。これにより、eBayのユーザーに対してXSS攻撃が行われていました。

XSS攻撃は、単純なようでいて非常に深刻です。XSS攻撃は、セッション、ユーザー認証情報、または機密データの盗難につながる可能性があります。評判の低下や収益の減少は、これらの攻撃の大きな落とし穴です。

しかし、XSSは、あなたのような経験豊富なセキュリティ戦士が打ち負かすことができます。修正方法は複雑ではありませんし、XSSが一般的に使用されるようになってから、業界は長い長い道のりを歩んできました。

XSSを倒すことができます。

XSSを撃退するには、コンテキストを理解することが重要です。具体的には、ユーザーの入力がどのような状況でクライアントに戻されるのか、どこで戻されるのかということです。HTMLコードの中か、JavaScriptのスニペットの中か。

ユーザー入力がブラウザに送り返される必要がなければ、それに越したことはありません。しかし、必要な場合は、多くの場合、HTMLエンコードされるべきです。出力をHTMLエンコードすることで、ブラウザはコンテンツをそのままレンダリングし、実行しないように指示します。

入力の検証も重要です。しかし、検証やホワイトリストは 確実な解決策ではありません 。エンコーディングはさらに数歩進んで、ブラウザが悪意のあるスクリプトを実行するのを阻止します。

多くのフレームワークが、HTML出力を自動的にエンコードするようになっています。
Angular、ASP.NET MVC、React.jsは、デフォルトのHTMLエンコードが使用されるフレームワークです。

その他のほとんどのフレームワーク（DjangoやSpring など）には、XSS 対策のための標準ライブラリが用意されており、簡単にコードに組み込むことができます。

最大の課題は、ユーザーの入力がシステムに入る方法をすべて分析し、それを見極めることができるようになることです。クエリ・パラメータは、ポスト・パラメータと同様に、攻撃の対象となる可能性があります。アプリケーション全体のデータの流れを追い、外部からのデータを信用しないようにしてください。

国境警備隊のように考えてください。すべてのデータを止めて検査し、悪意があると思われるものは入れないようにします。

これらの戦略を実行すれば、XSS による攻撃からユーザーを守ることができます。OWASP Cheat Sheetには、データを管理するためのさらなるヒントが掲載されていますので、ぜひご覧ください。

XSSを阻止し、セキュリティスキルをレベルアップさせる。

XSSは、OWASP Top 10 2017のWebセキュリティリスクのリストの7位に存在しています。

トレーニングは、開発者がコードを作成する際に、セキュリティを第一に考えた考え方を構築する上で非常に重要です。そして、そのトレーニングは、開発者が実際に使用している言語で、実際のアプリケーションをシミュレートすることで、常に最も効果的なものとなります。この点を踏まえて、XSSについての詳細を学ぶために、ラーニングリソースをチェックしてみてはいかがでしょうか。その後、トレーニングと実践を重ねて、マスターを目指しましょう。

XSSの脆弱性を見つけて修正する準備が今すぐできたと思いますか？ 挑戦してみませんか？ Secure Code Warrior プラットフォームで。

簡単に言うと、SQL（Structured Query Language）とは、リレーショナルデータベースと通信するための言語で、開発者やデータベース管理者、アプリケーションが日々生成される膨大なデータを管理するために使用する問い合わせ言語のことです。

私たちのデータは急速に、世界で最も価値のある商品のひとつになりつつある......そして価値のあるものであれば、悪者は自分たちの利益のためにそれを手に入れようとするだろう。

攻撃者は、世界中の何百万ものデータベースに存在する機密情報を盗んだり変更したりするために、最も古く（1998年以降）、最も厄介なデータ脆弱性の1つであるSQLインジェクションを使用しています。データを安全に保つためには、開発者はSQLインジェクションについて理解する必要があります（また、その防御方法についても）。

そのために、SQLインジェクションの3つのポイントについて説明します。

• その仕組み
• なぜ危険なのか
• どうやって防御するか

SQLインジェクションの理解

SQLインジェクションは、「コンテキスト」という言葉で理解することができます。

アプリケーションの中には、データ用とコード用の2つのコンテキストが存在します。コードのコンテキストは、何を実行するかをコンピュータに伝え、処理されるべきデータから分離します。

SQLインジェクションは、攻撃者が入力したデータが、SQLインタープリターによって誤ってコードとして処理されることで発生します。

一例として、ウェブサイトの入力フィールドに攻撃者が「'' OR 1=1」と入力すると、それがSQLクエリの最後に付加されます。このクエリが実行されると、データベースのすべての行に対して「true」が返されます。これは、クエリを実行したテーブルのすべてのレコードが返されることを意味します。

SQLインジェクションの影響は、壊滅的なものになる可能性があります。ログインページで発生した場合、ユーザー名やパスワードを含むすべてのユーザー記録が返される可能性があります。データを取り出すための単純なクエリが成功すれば、データを変更するためのクエリも成功するでしょう。

SQLインジェクションの脆弱性がどのようなものかを実際に確認するために、脆弱なコードを見てみましょう。

このコードをチェックしてください。

String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
   Statement statement = connection.createStatement( ... );
   ResultSet results = statement.executeQuery( query );
}

ここでのコードは、検証を行わずに、クライアントからのパラメータ情報をSQLクエリの最後に追加するだけのものです。このような場合、攻撃者は入力フィールドやURLのパラメータにコードを入力すると、それが実行されてしまいます。

重要なのは、攻撃者が各SELECTクエリに「''OR 1=1」を追加することしかできないということではなく、攻撃者はあらゆるタイプのSQLクエリ（INSERT、UPDATE、DELETE、DROPなど）を操作し、データベースがサポートするあらゆるもので拡張することができるということです。どのようなことが可能なのかを示す素晴らしいリソースやツールが公開されています。

この問題を解決するための方法をすぐに学びます。まず、どのくらいのダメージがあるのかを理解しましょう。

SQLインジェクションが危険な理由

ここでは、SQLインジェクションが原因で発生した侵害の例を3つだけ紹介します。

• イリノイ州選挙管理委員会のウェブサイトが、SQLインジェクションの脆弱性により侵害されました。攻撃者は、20万人の米国市民の個人データを盗みました。見つかった脆弱性の性質上、攻撃者はデータを変更することも可能でしたが、そうはしませんでした。
• 南アフリカのウェブサイトホスティング会社であるHetzner社は、4万件の顧客記録が侵害されました。SQLインジェクションの脆弱性により、同社のデータベースに登録されているすべての顧客記録が盗まれた可能性があります。
• 米国ミネソタ州にあるカトリック系の金融サービス会社が、SQLインジェクションを利用した不正アクセスを受けました。約13万人の顧客の口座番号を含む口座情報が盗まれました。

機密データは、アカウントの乗っ取り、パスワードのリセット、金銭の窃盗、詐欺などに利用される可能性があります。

機密情報や個人を特定できない情報であっても、別の攻撃に利用される可能性があります。住所情報や政府機関の識別番号の下4桁は、お客様になりすまして企業に連絡したり、パスワードをリセットしたりするのに使われます。

攻撃が成功すると、顧客は企業に対する信頼を失うことになります。システムへのダメージや規制による罰金からの回復には、数百万ドルの費用がかかります。

しかし、あなたがそのように終わる必要はありません。

SQLインジェクションの撲滅

SQLインジェクションを防ぐには、アプリケーションの一部を明確にラベル付けすることで、ある部分がデータなのか実行されるコードなのかをコンピュータに認識させる必要があります。これには、パラメータ化されたクエリを使用します。

SQLクエリがパラメータを使用する場合、SQLインタープリタはパラメータをデータとしてのみ使用します。コードとしては実行されません。

例えば、「''OR 1=1」のような攻撃は機能しません。データベースは「OR 1=1」という文字列を検索しますが、データベース内には見つかりません。単に肩をすくめて、"Sorry, I can't find that for you. "と言うだけです。

Javaでのパラメータ化されたクエリの例は次のようになります。

ほとんどの開発フレームワークには、SQLインジェクションに対する防御機能が組み込まれています。

.NETファミリーのEntity Frameworkのようなオブジェクトリレーショナルマッパー（ORM）は、デフォルトでクエリをパラメータ化します。これにより、SQLインジェクションの対策が何もしなくてもできるようになります。

しかし、特定のORMがどのように機能するかを知っておく必要があります。例えば、Javaの世界では人気の高いORMであるHibernate も、使い方を誤るとSQLインジェクションの危険性があります。

クエリのパラメータ化は最初で最良の防御策ですが、他にもあります。ストアドプロシージャもSQLパラメータをサポートしており、SQLインジェクションを防ぐために使用することができます。ただし、ストアドプロシージャも正しく構築されていなければなりませんのでご注意ください。

// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );

常に入力を検証し、サニタイズしてください。OR 1=1 "のような文字は、アプリケーションの正当なユーザーが入力することはないので、許可する必要はありません。ユーザーにエラーメッセージを表示したり、入力を処理する前にそれらの文字を取り除くことができます。

とはいえ、バリデーションやサニタイズだけに頼っていてはいけません。賢い人間はそれを回避する方法を見つけています。それらは深層部への防御(DiD)として有効ですが、パラメータ化は、すべてのベースをカバーする確実な方法です。

もうひとつの優れたDiD戦略は、データベース内で「最小特権」を使用し、入力をホワイトリスト化することです。最小限の特権を行使するということは、アプリケーションがデータベース内で無限の権限を持たないことを意味します。仮に攻撃者がアクセスしたとしても、その被害は限定的です。

OWASPでは、いくつかの言語やプラットフォームでこの脆弱性をどのように処理するかを示した素晴らしいSQLインジェクション・チートシートを用意していますが、さらに上を目指したい方は、今すぐ私たちのプラットフォームで、お好きな言語でSQLインジェクション・チャレンジをプレイすることができます。

C#でのSQLインジェクション

Node.jsにおけるSQLインジェクション

Python DjangoでのSQLインジェクション

Java SpringにおけるSQLインジェクション

旅の始まり

SQLインジェクションを理解し、それを修正するために必要なステップを理解する上で、あなたは大きな進歩を遂げました。すばらしいですね。

これまで、SQLインジェクションがどのように起こるかを説明してきました。通常、攻撃者は入力を使用してデータベースのクエリを制御し、悪意のある目的を達成します。

また、SQLインジェクションの脆弱性が悪用されることによる被害も目にしてきました。アカウントが侵害され、何百万ドルものお金が失われる......悪夢のような、そして高価なものです。

SQLインジェクションを防ぐ方法を見てきました。

• クエリのパラメータ化
• オブジェクトリレーショナルマッパーとストアドプロシージャの使用
• ユーザー入力の検証とホワイトリスト化

あとは、あなた次第です。練習は、学習と習得を続けるための最良の方法です。だからこそ、私たちの ラーニングリソースSQLインジェクションの学習資料をご覧になり、無料体験版をお試しください。 無料デモプラットフォームの無料デモを試してみませんか？そうすれば、Secure Code Warrior に近づくことができるでしょう。

2020年にはリモートワークが急増し、さらに大規模なデータ流出が続き、オンライン上でのプライバシー侵害の影響に注目が集まっていることから、サイバーセキュリティに対する社会の注目度はかつてないほど高まっています。その結果、世界各国の政府は、私たちの最も貴重なデジタルリソースを取り扱う際に企業が遵守すべき戦略や規制を含む、サイバーセキュリティの計画やインフラの再構築と更新に乗り出しています。

サイバーセキュリティの戦略的保護ガイドラインは新しい概念ではなく、NISTのような組織が長年にわたって世界の政府部門の方針を伝えてきました。しかし、デジタル化が急速に進むにつれ、多くの人々にとって、変化し続ける状況の中で、数多くの脅威、考えられる攻撃経路、コンプライアンス要件に対応することは困難になっています。

最近発生したニューサウスウェールズ州の運転免許証54,000件の漏えい事件は、サードパーティのサーバに設置されたS3バケットに簡単にアクセスして設定を間違えたことが原因で、数千人の個人情報が漏えいしたもので、この事件を報告したセキュリティ研究者は、データがすでにダークウェブで販売されている可能性があることを認めています。悲しいことに、この問題は簡単に解決できるものであり、キャッシュの設定者がセキュリティを最優先に考えていたならば、このような事態は全く起こらなかったでしょう。

オーストラリア政府は先日、「オーストラリア・サイバーセキュリティ戦略2020」を発表しました。これは、「オーストラリア人とそのビジネス、そして私たち全員が依存している重要なサービスのために、より安全なオンライン世界を構築する」というビジョンを達成するために、新たな取り組みと今後10年間で使用される16億7,000万ドルの資金増強を強調したものです。特に、主な目的の一つが以下の通りであることから、これは非常に歓迎すべき見直しであり、更新された計画です。

"企業が自社の製品やサービスの安全性を確保し、既知のサイバー脆弱性から顧客を守るための行動"

政府機関は、国の重要なインフラ（壊滅的な組織的攻撃を受けやすい分野）に関するセキュリティ対策を重視する傾向にありますが（当然のことですが）、これまでは、私たちのデータを日々収集・利用している企業に対するガイドラインが不足していました。

さて、このような公式の戦略となると、ビールとスキットルばかりではありません。解釈がやや難しく、詳細が曖昧なため、組織のセキュリティチームが具体的でないガイドラインに基づいて計画を組み立てることになってしまうのです。この問題は、オーストラリア政府に限ったことではありませんが、オーストラリア政府の新しいリリースを分析してみましょう。

予防ではなく、反応に焦点を当てています。

更新されたオーストラリアのサイバーセキュリティ戦略は、2016年に発表された前回のものよりも関連性がアップしており、企業、特に中小企業向けにかなり包括的な計画が盛り込まれています。戦略の概要は以下の通りです。

"政府と大企業は、中小企業がサイバーセキュリティに対する意識と能力を高め、成長できるように支援する。オーストラリア政府は、大企業やサービスプロバイダーと協力して、中小企業にサイバーセキュリティの情報やツールを、安全なサービス（脅威の遮断、ウイルス対策、サイバーセキュリティ意識向上トレーニングなど）の「バンドル」の一部として提供する」としている。

これにより、中小企業はサイバー脅威から自社のビジネスを守るための基本的な基盤を整えることができます。しかし、これは主に後付けのアプローチであり、サイバーセキュリティの中でも比較的小さな部分である検知ツールに焦点が当てられています。

また、大企業がどのように自らを守り、攻撃のベクトルを減らすことができるのかについての情報は驚くほど少ない。重要インフラ（通信、輸送など）を保護する計画の一部であることは確かだが、金融サービス、小売、その他多くの業種は、サイバー攻撃が成功した場合、失うものが大きい。しかし、企業レベルでのサイバーセキュリティのベストプラクティスの重要性を強調することは、大きな変化をもたらし、漏洩したデータやサイバー犯罪を減少させるための基本です。

今回の戦略は、全体的に見て、リアクティブなアプローチを中心に構築されています。サイバー攻撃に対抗し、活動中のサイバー犯罪者を混乱させて確実に処罰し、国際的な同盟国と情報を共有することは、いずれも重要な要素ですが、もし国全体の保護の基準が予防に集中していたらと想像してみてください。重要インフラの保護対策とともに、すべての企業でセキュリティが最優先され、デジタル世界を創造するコードに触れるすべての人が、攻撃を未然に防ぐための適切な装備を備えていたとしたら、時間、お金、そして被害者の心労を減らすことは計り知れません。

レジリアンスは可能ですが、計画的に行わなければなりません。

オーストラリア政府がサイバーセキュリティに本腰を入れて取り組んでいることからもわかるように、サイバーセキュリティは国家レベルで重要なリスク領域として認識されています。私たちの生活を破壊する可能性のある他の悪意のある攻撃と同様に、そのような試みに耐えるだけでなく、そのようなことが全く起こらないように抑止するためにも、レジリエンスは絶対に重要です。結局のところ、脅威となる人物は怠け者であり、成功を阻む障害が多ければ、目的を達成するためにもっと簡単なターゲットに移ってしまうのです。

現在、私たちは世界的なサイバーセキュリティのスキル不足に直面しており、これは世界中のCISOを夜も眠れない状態にしています。何十億行ものコード、絶え間ない大規模なデータ侵害、そしてかつてないほどのペナルティのリスク（マリオットだけでも、2018年のデータ侵害でGDPRによる1億2,300万米ドルの罰金を受けており、さらに今年も侵害が発生しています）により、セキュリティの専門家に対する需要の溝は、現実的には埋められそうにありません。コードがあまりにも多く、それをあらゆる角度から防御するためのリソースがあまりにも不足しているのです。

では、私たちは、サイバー脅威に直面したときに、真の意味で立ち向かえるようになることを諦めるべきなのでしょうか？そんなことはありません。レジリエンスを高めるためには、利用可能なすべてのリソースを活用し、一歩先を見据えて行動する必要があります。多くの企業では、開発者がコードを書いている最中に、強力な防御方法を解き放つことができます。企業全体で目に見える積極的なセキュリティ文化と組み合わせれば、多くの攻撃者が揺さぶりをかけて壊すことのできない安全な基盤ができあがります。しかし、この方法は、オーストラリアのサイバーセキュリティ戦略の提案を例にとり、ビジネスに適した効果的な変化をサポートするために、どのようにカスタマイズできるかを深く掘り下げる必要があります。

そのためには、いくつかのヒントを分解することが重要です。

• セキュリティ意識向上のためのトレーニング。これは特に中小企業を対象としたもので、報告書全体の文脈からすると、主にすべてのスタッフに基本的なセキュリティ衛生を教えることを目的としています（例：フィッシングメールの見分け方、知らないリンクをクリックしないなど）。現実的には、それよりもはるかに進んで、特に開発者のようにコードを触る人たちのために、役割に応じたトレーニングを行う必要があります。セキュリティ意識の向上のためのトレーニングは、予防措置と回復力の構築のための要素であることが不可欠です。
• 教育です。新たな試みとして、初等・中等教育から高等教育に至るまで、サイバーセキュリティのトレーニングを重視することで、今後10年間のサイバーセキュリティのスキル不足に対処するための綿密な計画が立てられています。将来のセキュリティ・スーパースターを育成するためには、このようなトレーニングが必要です。しかし、現在のビジネス・ニーズに対応するという観点からは、一般的な脆弱性を減らしていくためには、開発者向けのセキュア・コーディングの実践的なトレーニングが絶対に必要であり、機能的なセキュリティ・プログラムの一部でなければなりません。

私たちはセキュリティの専門家として、世界中の企業が、単純な基礎的認識にとどまらず、社内のセキュリティプログラムを構築することの重要性を理解するために、もっと努力する必要があります。開発者のスキルアップに時間をかけることで、過重労働を強いられているAppSecの専門家のプレッシャーを軽減し、組織全体がそれぞれの役割に応じて可能な限りセキュリティを意識するようにすることが、ソフトウェアにおける脅威表面の攻撃領域を減らすために不可欠です。

開発者のスキルアップは時間を有効に使うことができますが、なぜ多くの企業がそれを無視しているのでしょうか？

DDLSが最近実施した調査によると、オーストラリアの組織では、サイバーセキュリティのトレーニングに関して、優先順位がほとんど意識されていないことがわかりました。実際、回答者の77%がサイバーセキュリティに対する意識を「非常に重要」または「非常に重要」としているにもかかわらず、トレーニングの優先順位のトップ3にも入っていませんでした。

そのため、オーストラリアが拡大するスキル格差の解消に苦戦しているのも不思議ではありません。また、基本的なサービスから小売店、そしてその間にあるすべてのものに至るまで、より回復力のあるインフラを構築するためには、いくつかの課題があります。

政府がセキュリティスキルのベースライン認証や規制を設ける機会は非常に多く、戦略では、有限の資源で取り組む方法として、このことを示唆しています。しかし、繰り返しになりますが、これは未来状態の提案であり、影響力の大きい分野を最初にターゲットにすれば、もっと早く始めることができるツールがあるのです。私にとっては、希望の光は各組織内の開発チームにあり、成功するためのツールと知識を与えられれば、一般的な脆弱性を峠で断ち切り、組織内のデータ侵害のリスクを大幅に減らすことができる。

2019年には、データ漏洩全体の24％が人為的なミス、つまりセキュリティの設定ミスが原因となっていますが、これらは通常、比較的簡単なコードレベルの修正です。ここで、全社的なセキュリティ意識の醸成と合わせてトレーニングが優先されれば、侵害された何千人もの顧客への侵害通知に署名するCISOは少なくなるに違いないと思います。