古い酒場や地下のクラブのドアに行くところを想像してみてください。扉の小さな穴がスライドして開き、太った用心棒がパスワードを尋ねる。訪問者はパスワードを知らないので、推測します。それが間違っていたので、用心棒は彼らを中に入れませんでした。

これが通常の流れです。ここで、間違ったパスワードを推測したお客様が、すぐに再挑戦し、間違ってしまい、再びアクセスを拒否されたとします。そして、その訪問者が辞書を開いて単語を読み上げ、ツチノコのようなものから始めて、ありとあらゆる単語を試していくとします。

しかし、自動化対策が不十分なWebサイトやアプリケーションでは、そのような行為が行われてしまいます。ユーザーは、適切なキャッチフレーズに出会うまで、自動化技術を使ってでもパスワードを試し続けることができるのです。

このエピソードでは、以下のことを学びます。

• 不十分な自動化を悪用する攻撃者の手口
• 反自動化が不十分なアプリケーションが危険な理由
• この脆弱性を修正することができる技術

攻撃者はどのようにして不十分な自動化を利用するのか？

今回の酒場の訪問者のように、自動化や辞書を使った攻撃を行うことは、サイバーセキュリティの世界では新しいことではありません。実際、ブルートフォース（総当り）方式の攻撃は、これまでに展開された最初のハッカー技術の一部でした。また、コンピュータが高速化するにつれて、その効率も向上していきました。高速なコンピュータであれば、攻撃側のコンピュータと標的となるシステムの間の接続速度にもよりますが、わずか数分で単語の辞書全体を使い切ることができます。

このような自動化された攻撃のために、自動化防止ソフトウェアや技術が生まれたのです。これにより、ユーザーの行動が人間の典型的な行動の規範から外れているかどうかをアプリケーションが判断することができるようになります。

アプリケーションに自動化防止のチェックが十分に行われていない場合、攻撃者は、一致するものが見つかるまでパスワードを推測し続けることができます。また、自動化ソフトウェアを使用して、ウェブサイトのフォーラムへのコメントをスパムするなど、別のことをするかもしれません。

なぜ不十分な自動化は危険なのか？

悪意のあるユーザーが自動化を利用してセキュリティを回避しようとすることは危険です。コンピュータの黎明期から現在に至るまで自動化型の攻撃が続いているのは、非常に効果的だからです。自動化プログラムに無制限の時間を与えてパスワードを送信し、間違った推測をしても何の影響も受けないようにすれば、最終的に正しいパスワードを見つけることができます。

フォーラムなどで使用される場合、明らかにスクリプト化されたコメントが次々と表示されると、有効なユーザーを苛立たせたり、システムリソースを浪費することで一種のサービス拒否攻撃のような働きをしたりするかもしれません。また、自動投稿は、できるだけ多くの人にルアーを見せるために、フィッシングなどの攻撃のツールとして使われることもあります。

不十分な自動化対策問題の修正

自動化対策が不十分であるという問題を解決するためには、すべてのアプリケーションに、実行されているアクションが人間によるものなのか自動化ソフトウェアによるものなのかを判断する機能を持たせる必要があります。最も一般的で広く使用されている技術の1つに、Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)があります。

CAPTCHAは、1950年にコンピュータ科学者のアラン・チューリングが提唱した、人間とコンピュータの行動を分離・識別するためのチューリング・テストが基本となっています。最近のCAPTCHAは、人間には簡単に解ける問題でも、コンピュータには苦手な問題、あるいは単に解けない問題を提示しています。よく知られているのは、グリッドで区切られた写真を提示し、花や顔などの特定のアイテムが写っているすべてのセクターを特定するよう求めるものです。コンピュータは何を要求されているのか理解できないので、画像をスキャンすることもできません。たとえできたとしても、画像認識は、特別に作られていないほとんどのプログラムでは不可能です。

CAPTCHAの他の例としては、ぼやけた文字を表示したり、簡単な論理的質問をしたり、質問を大声で再生したりするものがあります。CAPTCHAチャレンジをパスワード入力時など、アプリケーションの重要なポイントに導入することで、自動化プログラムを途中で止めることができます。

また、同じソースからの間違った推測の数を制限するだけで、自動化プログラムを停止させることも可能です。あまりにも多くの間違った推測が送られてきた場合、アカウントを一時的にロックアウトして、自動化プログラムが有用でなくなるのを遅らせたり、人間の管理者がロックを解除する必要があるかもしれません。このようにして、アプリケーション内の自動化防止の脆弱性を防ぐことができます。

不足している自動化の詳細情報

さらに読みたい方は、OWASPが不十分な自動化対策について述べている内容をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。

今すぐ不十分な自動化防止機能を見つけて修正する準備はできていますか？あなたのスキルをゲームアリーナで試してみませんか？[Start Here]をクリックしてください。

この「Share & Learn」シリーズで取り上げた他の多くの脆弱性とは異なり、ビジネスロジックの問題は、コーディングエラーとは直接関係ありません。コーディングの問題が問題の一部である場合もありますが、ビジネスロジックのエラーは、アプリが最初に作成されたときの設計上の欠陥や誤った論理的仮定の結果であることがほとんどです。

ビジネスロジックの問題は、ユーザーがアプリケーションを使用する際に予期しない行動をとった場合に発生します。例えば、予期せず注文をキャンセルしたり、クーポンコードを何度も適用したり、あるいは単に予期されたステップをスキップして、アプリケーションがどのように処理したらよいかわからないアクションをとったりすることです。ビジネスロジックの欠陥を利用するためには、トレーニングを受ける必要はありません。

このエピソードでは、以下のことを学びます。

• ビジネスロジックの欠陥を攻撃者がどのように利用するか
• ビジネスロジックに欠陥のあるアプリケーションが危険な理由
• ビジネスロジックのエラーを防ぐためのテクニック

攻撃者はどのようにしてビジネスロジックの問題を利用するのか？

多くのエクスプロイトとは異なり、この脆弱性の原因となる特定のコード文字列を指摘することはできません。むしろ、ユーザーが想定外のアクションを起こし、プログラムがその処理方法を知らないことが原因となります。例えば、銀行のアプリケーションで、ユーザーが他の口座にお金を送金できるとします。しかし、悪意のあるユーザが、お金を送るのではなく、マイナスの金額を他の口座に送ろうとしたとします。銀行のアプリケーションはどのように反応するでしょうか。クラッシュするでしょうか？送金を拒否するでしょうか。それとも、実際に送金を開始したユーザにお金を送り返して、そのマイナス分のバランスを取るのでしょうか?

E-コマースサイトは、多くのユーザーが利用することを想定して設計されており、多くのコンポーネントが存在するため、ビジネスロジックの欠陥の影響を受けやすいという特徴があります。ユーザーが突然注文をキャンセルしたり、1つのクーポンを何度も適用しようとしたり、さらにはショッピングカートをオーバーロードしたりすると、アプリケーションは予期していなかった状況に陥ります。未知の状況に直面したときに、プログラムがどのように反応するかを知る方法は、実際にはありません。最善のシナリオはエラーメッセージを出すことかもしれませんが、アプリが商品を無料で提供するなど、より悪い行動を取らないという保証はありません。

なぜビジネスロジックの問題は危険なのか？

ビジネスロジックの問題は、プログラミングやハッカーの訓練を受けていない人でも、誰でも悪用することができるため、非常に危険です。実際に必要なのは、実験と時間をかけて、アプリケーションが反応するように設計されている方法の欠陥を見つけることだけです。悪意のあるユーザがサイトのビジネスロジックの欠陥を発見したら、それを可能な限り利用することは間違いありません。

最も危険なのは通常、金銭的な問題です。ユーザーが大画面テレビを20台も購入していて、その代金を支払っていないなどの問題です。しかし、ビジネスロジックの欠陥は、他の問題を引き起こすこともあります。例えば、サイトを保護するパスワード機能が、ユーザーがキャンセルを連発した場合の対処法を知らない場合、ログインプロセスを完全に回避させてしまう可能性があります。

ビジネスロジックの問題がどれほどの損害をもたらすかを予測する方法は、実際にはありません。多くの場合、問題の最初の兆候は、ユーザーがそれらを悪用した後に起こります。

ビジネスロジックの問題を解決する

残念ながら、ビジネスロジックの問題のテストは簡単には自動化できないため、脆弱性スキャナのような一般的なツールを使っても、ビジネスロジックの問題を特定したり修正したりすることはできません。これらを回避する最善の方法は、アプリケーションが開発されている間に、ネガティブなテストケースに対して、適切な計画、エラー処理、およびテストを実施することです。このためには、まず、アプリケーションが取るように設計されたすべての可能なアクションと望ましいアクションを含む、明確に定義されたビジネスルールのセットが必要です。

ビジネス・ルール・プランを用いて、ビジネス・ロジックの欠陥を防ぐ最善の方法の一つは、アプリケーション内でデータやトランザクションがどのように流れるかを示すフローチャートを作成することです。これには、ユーザーが選択したりデータを入力したりするすべてのインスタンスの動作のモデル化が含まれます。フロー図の中の可能なアクションが、ビジネスルールプランの中の機能と一致しているかどうかを常にチェックします。

最後に、設計、実装、テストの各段階で、ビジネスロジックの欠陥を特定するために、脅威モデルを使用します。フェイルセーフとして、プログラムが想定外の状況に遭遇した場合に取るべきアクションを作成します。これは、アクションを拒否し、発生した問題について管理者に警告するという単純なものです。

ビジネスロジック問題の詳細情報

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

今すぐビジネスロジックの脆弱性を探して破壊する準備はできていますか？プラットフォームに向かい、自分のスキルを試してみましょう。[Start Here]

最近のWebサイトやアプリケーションでは、ユーザーが電子メールを使ってフィードバックやアポイントメント・リマインダー、その他さまざまな情報をアプリケーション経由で送信できるようになっているのが一般的です。通常、このプロセスは非常に良心的であり、ほとんどの人は潜在的なセキュリティリスクの観点から考えることはありません。

しかし、ユーザーの入力を可能にする他のデザイン要素と同様に、適切に設定されていなければ、一見取るに足らない機能であっても、悪意のあるユーザーによって悪意のある目的のために操作される可能性があります。ユーザーが入力フィールドにコードを入力し、それがサーバーで誤って処理されるようにするだけでいいのです。突然、電子メールアプリケーションが武器になってしまうのです。

このエピソードでは、以下のことを学びます。

• 攻撃者がメールヘッダインジェクションを引き起こす方法
• メールヘッダーインジェクションが危険な理由
• この脆弱性を修正することができる技術

攻撃者はどのようにしてメールヘッダインジェクションを引き起こすのか？

プログラム可能とはあまり考えられませんが、ほとんどのメール連絡用アプリケーションや、ウェブサイトやアプリケーションに組み込まれた機能は、問い合わせの性質を変える入力を受け付けることができます。これは通常、ユーザーが電子メールアドレスなどの情報を契約フィールドに入力した後、サーバーが自動的に行うものです。その後、プログラムがメッセージを設定し、適切な受信者を追加し、デフォルトのメールサーバーを使用してメッセージを送信します。

典型的なメールのPOSTリクエストは次のようなものです。

POST /contact.php HTTP/1.1
ホスト: www.example.com

そして、ユーザーが情報を入力した後に、以下のようなコードを生成します。

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

トラブルが発生するのは、ハッカーが連絡先情報だけではなく、プロセスにコードを注入し始めたときです。これは、SQLインジェクション型の攻撃と似ていますが、メールアプリケーションに対して行われます。操作されたクエリの例としては、アプリケーションから標的となるユーザーに代わりにスパムを送信するようなものがあり、次のようになります。

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed メッセージ

メールヘッダインジェクションはなぜ危険なのか？

悪意のあるユーザーのスキルとその意図に応じて、メールヘッダインジェクション攻撃は、単に迷惑なものから非常に危険なものまで、深刻度の範囲が異なります。深刻度の低いものでは、社内の秘密または非公開のメールボックスに送信された送信メッセージのBCCフィールドに自分の連絡先情報を挿入し、ハッカーに公開することができるかもしれません。

さらに言えば、メールサーバーを完全にコントロールして、スパムやフィッシングなどの攻撃メールを組織から送信できるようになるかもしれません。彼らは、メールが社内のサーバーから発信されていることを偽装する必要はありません。もしあなたがその活動を監視していなければ、彼らはそのプロセスを自動化し、あなたの組織のサーバーを使って、あなたが実際にその活動を扇動しているように見せかけて、何百、何千もの電子メールを送信することもできます。

メールヘッダーインジェクション問題の解決に向けて

SQLインジェクションなどの攻撃と同様に、悪意のあるユーザーがEメールヘッダーの脆弱性を悪用する可能性を排除するには、ユーザーの入力を決して信用しないことが重要です。ユーザーが情報を入力できた場合、それがメールアドレスの入力のような些細なプロセスに見えたとしても、最悪の事態を想定しなければなりません。少なくとも、最悪の事態が起こりうることを想定しなければなりません。

アプリやWebサイトにメール連絡機能を追加する場合も含め、すべてのパラメータに対して入力検証を行う必要があります。ホワイトリストは、有効と思われるプロセスやフィールドを特別に有効にし、それ以外のものをすべて拒否するために使用できます。実際、ほとんどのフレームワークには、必要な機能だけをロックするためのライブラリが用意されています。これにより、悪意のあるユーザーが入力したコードやコマンドがサーバーに認識され、処理されることを防ぐことができます。

メールヘッダーインジェクションの詳細情報

さらに詳しい情報は、OWASPがEメールヘッダーインジェクションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。

電子メールのインジェクションを見つけて修正する準備ができていると思いますか？プラットフォームにアクセスして、自分のスキルを試してみましょう。[Start Here] (ここからスタート)

URLは、私たちがよく知っているウェブサイトやウェブアプリケーションをナビゲートするのに欠かせないものです。URLの基本的な機能は、リソースがどこにあり、どのようにしてそれを取得するかを特定することです。URL は、WWW が機能するために必要なものですが、適切に保護されていなければ、セキュリティ上のリスクとなります。

この記事では、学ぶことができます。

• IDORとは何か、攻撃者はどのようにIDORを使うのか
• IDORが危険な理由
• この脆弱性を修正するための技術

IDORを理解する

オブジェクトの直接参照とは、アプリケーション内で特定のレコード（「オブジェクト」）を参照することです。通常、一意の識別子の形をとり、URLで表示されることもあります。

たとえば、URLの末尾に「?id=12345」などと書かれていることがあります。この12345という数字は、特定のレコードへの参照です。個々のレコードに対してアクセス制御が行われていないと、セキュリティ上の脆弱性が生じます。これにより、ユーザーは見てはいけないレコードやデータにアクセスできるようになります。これは、比較的低いスキルレベルを必要とする攻撃です。

この例では、攻撃者が URL の ID を 12344 に変更したとします。IDORに脆弱なアプリケーションでは、攻撃者はそのレコードに関連するデータを見ることができます。

この種の脆弱性は、実際にどれほどの被害をもたらすのでしょうか。

IDORが危険な理由を知る

開発者が注意を怠ると、様々な場所にアプリケーションの記録が表示されたり、漏れたりするシステムを設計してしまうことがあります。このような規模の侵害は、特にセンシティブなデータやPIIが関与している場合、重大な問題となります。

オーストラリア税務局は、企業が新しい税金を徴収するためのウェブサイト を開設しました。しかし、このサイトには、IDORの脆弱性という、望ましくない機能がパッケージされていました。あるユーザーが、サイト内のURLに自分のオーストラリア企業番号（ABN）が含まれていることに気がつきました。この番号は、登録されている企業であれば簡単に見つけることができる番号です。このユーザーは、他の企業の番号をURLに入れることにしました。すると、その企業の銀行口座情報や個人情報が手に入ってしまったのです。

Appleは先日、IDOR脆弱性の被害に遭いました。iPadが発売された当初、11万4千人の顧客のメールアドレスが流出しました。公平に見て、これはむしろAT&T側のミスだった）。

AT&Tは、iPadの3G接続をサポートするサービスを構築していました。iPadは、SIMカードに保存されている識別子をAT&Tのサービスに送信する。AT&Tのサービスは、ユーザーのメールアドレスを返した。

残念ながら、これらの識別子は単なる連続した整数であり、容易に推測することができました。攻撃者は、これらの識別子を繰り返し入力し、メールアドレスを盗み出しました。

もうひとつの失敗は、AT&Tのサービスでは、リクエストのuser-agentヘッダーにiPadからの送信であることが示されている場合にのみ、メールアドレスを返そうとすることで、「安全性」を確保しようとしたことです。user-agentは、簡単に操作できる文字列の値でしかありません。

IDORの脆弱性は巧妙で卑劣なものです。ここでは、その対策について説明します。

IDORを倒す

アクセスコントロールは、IDORを解決するための鍵です。ユーザーが特定のレコードをリクエストした場合、リクエストされたレコードを閲覧する権限があるかどうかを確認します。

一元化された認証モジュールを使用することは、このための最良の方法です。Spring Securityのようなツールは、アプリケーションのための堅牢でカスタマイズ可能な認証と認可を提供します。

要するに、他のすべてのコードが認証チェックを行うために依存するモジュールが1つあればいいのです。

もう一つの一般的な緩和策は、サロゲート参照の使用です。実際のデータベースレコードの識別子をURLに使用する代わりに、実際のレコードに対応する乱数を作成することができます。

サロゲート参照を使用することで、攻撃者が次の有効な識別子を推測してレコードを入手することができないようにします。

そして最後に、ユーザーが操作できるものに依存して認証を行わないことです。AT&Tは、user-agentヘッダーを使って自分たちのサービスを認証しようとしました。HTTPヘッダー、クッキー、GETやPOSTのパラメータに頼ってはいけません。

これらの緩和策を導入することで、IDORは過去のものとなるでしょう。

リファレンスの確保

安全でない直接目的参照は、最も悪用されやすい脆弱性の一つです。予期せぬ時に忍び寄られないようにしましょう。常にユーザーの権限を確認してください。本物のデータベース識別子を使用しないでください。ユーザーが管理するデータに依存した認証を行わない。

ラーニングリソースをチェックして、マスターを目指しましょう。選択した言語でIDORの脆弱性を緩和する方法を練習することで、本番のコードベースでこの問題を発見し、修正することができるようになります。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。

今すぐIDORの攻撃から身を守る準備はできていますか？プラットフォームに向かい、無料でチャレンジしてみてください。[Start Here] (ここからスタート)

データはビジネスの活力源です。生き残るために、お金を稼ぐために、そしてお客様にサービスを提供するために必要な基礎情報です。デジタル化が進む社会では、開発者はこの貴重な情報の管理者として、計り知れない責任を負っています。開発者が機密データを保護しないと、ビジネスは安全でない暗号ストレージの餌食になってしまいます。

ここでは、データを安全に保存する方法と、そうしない場合に起こることを見てみましょう。

安全でない暗号化ストレージの理解

攻撃者はシステムにアクセスすると、通常、価値のあるデータを探します。誰かのアカウントを乗っ取ったり、別の攻撃を実行したりするのに利用できるデータです。このようなデータは、単にブラックマーケットで売られて現金化されることもあります。

安全でない暗号化ストレージは、SQLインジェクションやXSSのような単一の脆弱性ではありません。保護すべきデータを、保護すべき方法で保護していないことの結果なのです。

機密情報は保護しなければなりません。パスワードやクレジットカードの情報を平文で保存していると、ビジネスでロシアンルーレットをしているようなものです。

ハッカーがデータベースに侵入し、SQLインジェクションやXMLインジェクションなどの攻撃でデータを盗み出せば、彼らはすべてを手に入れることができます。しかし、データを暗号化しておけば、ハッカーがデータを実際に利用することは非常に困難になります。

侵入は必ずしも悪意のある外部の人間によるものではないことに注意する必要があります。データが暗号化されていなければ、悪質な内部の人間も簡単にデータを盗むことができます。会社の従業員がデータベースのすべてを見る必要はありません。不十分なアクセスコントロールや機密データの露出は、明らかな窃盗につながります。

また、すべての暗号は同じではないことを忘れないでください。誤った暗号化アルゴリズムを使用することは、まったく使用しないのと同じくらい危険です。脆弱なアルゴリズムを知っていても、熟練した攻撃者にはほとんど抵抗できません。

安全でない暗号化ストレージが危険な理由

多くの企業は、別の脆弱性（SQLインジェクションなど）によって危険にさらされ、結局、盗まれたデータを隠すことができません。これでは、ひどい状況がさらに悪化してしまいます。

• Adult Friend Finderが侵入され、4億1200万のアカウントが流出しました。これらのアカウントのパスワードは、脆弱なSHA-1ハッシングアルゴリズムで保護されていました。このパスワードは、1ヶ月以内に攻撃者によって簡単に解読されました。
• Uberが侵入され、5700万人のユーザー記録と60万人のドライバー記録が流出。個人情報が失われたのです。UberのGitHubアカウントに、UberのAWSアカウントのユーザー名とパスワードを含むリポジトリが公開されていたために起こったもので、良いアイデアではありませんでした。Uberの評価額は200億ドルも下がりましたが、これは主にこの情報漏洩が原因です。
• ソニーの「プレイステーション・ネットワーク」が侵害され、7,700万のアカウントが流出しました。そのうち1,200万件のアカウントには、暗号化されていないクレジットカード情報が含まれていました。ソニーは後に、この情報漏洩に関する1,500万ドルの集団訴訟で和解しました。

センシティブなデータを適切に保管しないと、明らかに深刻な結果を招きます。

ソニーは提訴されましたが、これは大きなペナルティです。しかし、たとえ訴えられなかったとしても、風評被害や規制面でのダメージは、企業にとって壊滅的なものになる可能性があります。

安全でない暗号化ストレージを倒す

開発者は、上記のようなデータ漏洩をどのようにして防ぐことができるのでしょうか？

最初のステップは、そもそもどのデータに暗号化が必要なのかを特定することです。結局のところ、すべてのデータが同じではありません。データを分類し、必要に応じて暗号化を行います。

一般的には、社会保障番号、パスワード、クレジットカードの詳細などの個人情報を保護する必要があります。ビジネスの性質によっては、健康記録やその他の個人情報を保護する必要があるかもしれません。

保護すべきデータがわかったら、次のステップは、適切なツールを使ってそのセキュリティを確保することです。一般的には、時の試練に耐え、強力だと考えられている暗号アルゴリズムを使用するのが良いでしょう。

何があっても、自分で暗号化関数を書かないでください。そのような関数には、攻撃者が暗号を解読するために使用できる欠陥が含まれている可能性があります。

社会保障番号やクレジットカード情報などのデータを暗号化するには、AESを使用します。AESにはさまざまな動作モードがありますが、本稿執筆時の推奨モードはGCM（Galois/Counter Mode）です。また、パディングの選択を求められるライブラリでは、パディングを使用しないようにするのがコツです。

パスワードの場合、ハッシュは元に戻せないため、ハッシュアルゴリズムを使用してパスワードをハッシュ化します。強力にハッシュ化された値があれば、攻撃者はその値を作った元のテキストを取り出すことはできません。パスワードのハッシュ化には、Argon2やBcryptが適していると考えられます。ハッシュ化する前に、必ずランダムな値でパスワードを「ソルト」することを忘れないでください。

これらの関数は、すべての主要なプログラミング言語／フレームワークに対応した実装が用意されています。これらの関数を効果的に使用する方法については、それぞれの言語やフレームワークのドキュメントを確認してください。

鍵の生成、保管、管理は、暗号技術の重要な要素です。鍵の管理が不十分だと、データが漏洩して解読されてしまう可能性があります。ASP.NET の Data Protection API のように、鍵の管理を支援するフレームワークもあります。鍵の管理に関する一般的なベストプラクティスについては、OWASP のチートシートを参照してください。

データを安全に保管することで、コストがかさみ、恥ずかしい思いをするようなデータ漏洩を防ぐことができます。最悪の場合、攻撃者があなたのデータを盗むことができたとしても、それを見たり、悪意のある目的に使用したりすることははるかに困難です。

データを見えないところに隠す

データを守るための方法を早速確認してみましょう。

• データを分類して、保護が必要なものを把握する
• 機密データの暗号化には、業界で検証された強力なアルゴリズムを使用する。
• 強力なワンウェイハッシュを使ってパスワードを保存する

さらに詳しく知りたい方は、ラーニングリソースをご覧ください。また、実際に使ってみたいという方は、お好きな言語のプラットフォームをお試しください。多くの言語をカバーしています。

これらのツールを使えば、データが盗まれることを防ぎ、企業の損失や評判の低下を防ぐことができます。

安全でない暗号化ストレージを見つけて修正する準備はできていますか？アリーナに行って自分のスキルを試してみましょう [start here]

XQueryインジェクション攻撃は、より広く普及しているSQLインジェクション攻撃の弟分のように考えられることがあります。この2つの攻撃は根本的な原因が似ており、攻撃者が攻撃のきっかけとして利用するコマンドも非常に似ています。ただ、XQueryインジェクション攻撃は、XMLデータに対するXPathクエリの際にのみ発生します。このため、XQueryインジェクション攻撃は、XPathインジェクションと呼ばれることもあれば、XPathを利用した攻撃と呼ばれることもあります。

大多数のWebサイトでは、ユーザーのログイン認証情報、顧客情報、個人の識別情報、機密データなどの重要な機能にXMLデータベースが使用されているため、XQuery攻撃の攻撃対象はかなり大きくなっています。

このエピソードでは、以下のことを学びます。

• 攻撃者によるXQueryインジェクションの使用方法
• XQueryのインジェクションが危険な理由
• この脆弱性を修正することができる技術

攻撃者はどのようにしてXQueryインジェクションを引き起こすのか？

多くのコンピュータ言語と同様に、XPathのコードはシンプルに設計されています。実際、XPath は標準的な言語であり、すべての記法や構文の記述は、それを使用するアプリケーションに関係なく変更されません。つまり、XPath クエリを操作するためのコマンドはよく知られており、自動化することも可能なのです。

XPath クエリは、どのような情報を検索するかを XML データベースに指示するシンプルなステートメントです。最も単純な例では、ユーザーレコードが存在するかどうかを確認して、そのユーザーのログイン認証情報を取得するために使用されます。問題は、XPathクエリーにはユーザーの入力が含まれるため、ハッカーがクエリーを操作して、保護すべき情報を返すことができることです。

例えば、ログインセキュリティを回避しようとする場合、攻撃者は XPath クエリの最後に変数を追加して、プロセス全体を回避することができます。例を挙げると、次のようになります。

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

ここでは、User Nameフィールドは、1=1またはa=aの記述により、どのユーザーにもマッチするようになっています。クエリの最初の部分だけが真であればよいので、パスワードフィールドは問題になりません。

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

XQueryインジェクション攻撃が危険である第一の理由は、攻撃者がログインやアカウントのセキュリティを回避することができるからです。また、アプリケーションによって異なることのない標準的な言語を使用して、自動化された方法で実行することができます。攻撃者は、ウェブサイトやアプリケーションを自動的にスキャンして、この脆弱性を発見したらすぐに行動することができます。あなたのアプリに脆弱性があれば、攻撃者はそのアプリを侵害します。アカウントのセキュリティを侵害するだけでなく、XQuery攻撃はデータの流出にも利用できます。例えば、攻撃者はXMLデータベースからすべてのレコードを転送することができます。

XQueryインジェクション攻撃の排除

同様の脆弱性と同様に、重要な防御策の1つは、単純にユーザーの入力を信用しないことです。ユーザーが情報を入力する際には、それがデータベースへの問い合わせであるかどうかにかかわらず、そのプロセスを精査する必要があります。これは、物理的な建物の窓やドアを保護することと同じです。なぜなら、これらの窓やドアは人がアクセスできる主な方法だからです。

XQuery のインジェクション対策としては、フィルタリングによるユーザー入力のサニタイズや、ホワイトリストによるユーザー入力の検証を行うことで実現しています。また、SQL クエリのプリペアド・ステートメントと同様に、パラメータ化された XPath インターフェイスを使用することもできます。

最後に、すべてのアプリケーションに最小の特権を適用するようにしてください。これは、すべてのアプリケーションのクエリを実行するために、読み取り専用の特権を持つユーザーを作成することを意味します。

これらの技術を用いることで、ウェブサイトやアプリケーションに対するXQueryインジェクションの試みをすべて阻止することができます。

XQuery Injectionsの詳細情報

さらに、OWASPがXQuery Injectionsについてどのように述べているかを見ることができます。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warriorブログをご覧ください。

セキュリティ上の誤設定という言葉は、コードの問題ではなく、アプリケーションの設定に起因する一般的な脆弱性を含む、ちょっとしたキャッチボールのようなものです。最も一般的なものは、通常、単純なミスを伴うものですが、そのような誤設定をしたアプリを展開する組織にとっては大きな影響を与える可能性があります。

よくあるセキュリティの設定ミスには、本番環境にデプロイする前にアプリケーションのデバッグ処理を無効にしていない、アプリケーションに最新のパッチを自動的に適用させていない、デフォルトの機能を無効にし忘れている、などがありますが、これらは将来的に大きな問題を引き起こす可能性があります。

セキュリティの設定ミスによる脆弱性に対抗する最善の方法は、本番環境に展開する前にネットワークから排除することです。

このエピソードでは、以下のことを学びます。

• ハッカーはどのようにして一般的なセキュリティの誤設定を見つけ出し、悪用するのでしょうか。
• セキュリティの誤設定が危険な理由
• セキュリティの誤設定を見つけて修正するために採用できるポリシーとテクニック。

攻撃者はどのようにして一般的なセキュリティの誤設定を利用するのか？

よくあるセキュリティの設定ミスはたくさんあります。最もよく知られているものは、ハッカーのコミュニティでよく知られており、脆弱性を探すときにはほとんどの場合、検索されます。最も一般的な誤設定には、以下のようなものがありますが、これらに限定されるものではありません。

• よく知られているパスワードのデフォルトアカウントを無効にしない。
• スタックトレースやその他のエラーメッセージをユーザーに表示するようなデバッグ機能をプロダクションでオンにしておくこと。
• 不要なポート、サービス、ページ、アカウント、権限など、不要な機能やデフォルトの機能が有効なままになっている。
• セキュリティヘッダを使用していない、またはセキュリティヘッダに安全でない値を使用している。

誤設定の中には、よく知られていて、簡単に利用できるものがあります。例えば、デフォルトのパスワードが有効になっている場合、攻撃者はそのパスワードとデフォルトのユーザー名を入力するだけで、システムへのハイレベルなアクセスが可能になります。

また、アプリをデプロイした後にデバッグ機能を有効にしたままにしている場合など、設定ミスにはもう少し手間がかかります。このような場合、攻撃者はエラーを引き起こそうとし、返された情報を記録します。その情報をもとに、ターゲットを絞った攻撃を行い、システムに関する情報や、盗もうとしているデータの所在を明らかにすることができるのです。

なぜセキュリティの設定ミスは危険なのか？

悪用されるセキュリティの誤設定の内容によっては、情報の漏洩からアプリケーションやサーバの完全な侵害まで、さまざまな被害が発生する可能性があります。セキュリティの誤設定は、熟練した攻撃者が利用できる防御の穴を提供します。デフォルトのパスワードが有効になっているなど、一部の脆弱性については、経験の浅いハッカーであっても悪用することができます。デフォルトのパスワードを調べて入力するのは、天才でなくてもできることです。

セキュリティの設定ミスがもたらす脅威の除去

セキュリティの設定ミスを避けるための最善の方法は、組織全体に展開されるすべてのアプリやプログラムに安全な設定を定義することです。これには、不要なポートを無効にする、アプリが使用しないデフォルトのプログラムや機能を削除する、デフォルトのユーザやパスワードをすべて無効にするか変更する、などが含まれます。また、本番環境に導入する前に、ソフトウェアのデバッグモードを常に無効にするなど、よくある設定ミスをチェックして対処することも含まれます。

これらが定義されたら、すべてのアプリがデプロイされる前に通過するプロセスを導入する必要があります。理想的には、誰かがこのプロセスの責任者となり、それを実施するための十分な権限を与えられ、一般的なセキュリティの設定ミスがあった場合には責任を負うべきです。

セキュリティの誤設定に関する詳細情報

さらに詳しい情報は、OWASPの最も一般的なセキュリティ設定ミスのリストをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。

今すぐセキュリティの誤設定を阻止する準備はできていますか？私たちのプラットフォームにアクセスして、自分自身に挑戦してください。 [Start Here]

スージーは、2日後に迫った嫌なレポートから逃れるためにメールを開きました。すると、受信トレイに無料でiPadがもらえるというリンクが表示されていた。そのリンクをクリックすると、「無料でiPadを手に入れるにはここをクリックしてください！」という大きなバナーのページがあるウェブサイトにアクセスします。ボタンをクリックしても、特に何も起こらない。問題は、何かが起こったということだ。

受信箱に戻ってみると、すべてのメールが削除されていることに気がつきました。彼女はどのメールにも「削除」を押していない。どうしたんだ？

メールサイトがクリックジャッキングされた。クリックジャッキングは、ユーザーを騙して意図しない行動を取らせるもので、深刻な問題に発展する可能性があります。

ここでは、クリックジャッキングがどのような仕組みで、なぜ危険なのか、そして開発者がどのようにしてそれを防ぐことができるのかを見ていきましょう。

クリックジャッキングの理解

クリックジャッキングは、「UIリドレス攻撃」とも呼ばれ、攻撃者がWebページ上のいくつかの透明なレイヤーを使って、ユーザーを騙し、ユーザーが意図しないボタンやリンクをクリックさせることで発生します。

車の中で虫が動かなくなったことはありませんか？虫は外に飛び出そうと、窓に向かって猛烈に飛んできます。虫の意図は、木や外気に見えるところに飛んでいくことであり、ガラスが行く手を遮っていることには気づかない。

クリックジャッキングは、ユーザーが虫で、あなたのウェブサイトが道を塞ぐガラスであることを除けば、デザイン的には似ています。ユーザーは無料のiPhoneのような欲しいものを見つけます。攻撃者は、無料のiPhoneの広告の上に、あなたのサイトを透明なフレームの中に配置します。ユーザーが「無料」とされている賞品を手に入れるためにボタンをクリックすると、実際にはあなたのサイトのボタンをクリックしていることになり、意図しない動作を行ってしまいます。

クリックジャッキングが危険な理由

クリックジャッキングで攻撃者は何ができるのか？それは、対象となるウェブサイトの機能に大きく依存します。

攻撃者は、ユーザーにソーシャルメディアで攻撃者のサイトを「いいね！」や「シェア」してもらうことができます。多くの人が利便性のためにソーシャルメディアのアカウントにログインしたままにしているので、これは簡単に実行できます。

あなたのサイトがフレーム内に設置できる場合、ボタンをクリックすることで機密性の高い操作が完了してしまい、これが攻撃のベクトルとして機能してしまいます。例えば、ユーザがiPadを無料で手に入れようとクリックしたにもかかわらず、代わりにサイトのアカウント設定を変更して、アカウントの安全性を低下させてしまうような場合です。この種の攻撃は、Adobe Flashプラグインの設定ページに対して発生しました。この設定は、透明なフレームの中に配置され、ユーザーを騙して、Flashアニメーションがマイクやカメラにアクセスできるようにします。これにより、攻撃者は被害者を録音することができ、プライバシーの重大な侵害となります。

メールクライアントがサイトにハメられ、ユーザーがメールボックス内のすべてのメールを削除したり、攻撃者が管理するメールアドレスにメールを転送したりする可能性があります。

要するに、ユーザーは自分が何をクリックしているのか分からないので、何でも納得してクリックすることができるのです。それがソーシャルシェアであれ、マルウェアのダウンロードであれ、可能性は無限大です。

クリックジャッキングに対抗するには

クリックジャッキングは防ぐことができます。クリックジャッキングを防ぐには、サイトにコンテンツ・セキュリティ・ポリシー（CSP）を設定することをお勧めします。frame ancestors」というHTTPレスポンスヘッダを使用することで、サイトのフレーム化を制御することができます。

• "frame-ancestors none"-他のサイトがあなたのサイトをフレームに入れることはできません。これは推奨される設定です。
• "frame-ancestors self"-サイト内のページは、サイト内の他のページによってのみ囲まれます。
• "frame-ancestors self <uri list=""> - Your site can be framed by the sites in the URI lists and no others.</uri>

CSP のフレーム・アンセスタは、現在すべての主要ブラウザでサポートされていません。そのようなブラウザでは、"X-Frame-Options" HTTPヘッダを予備のオプションとして使用してください。

• DENY - 誰もあなたのサイトをフレームできません。これは推奨される設定です。
• SAMEORIGIN - CSPの「self」と同じです。自分のコンテンツをフレーム化することはできますが、他の人はできません。
• ALLOW-FROM <uri> - Allow the specified URI to frame your content.</uri>

クリックジャックされないために

クリックジャッキングとは、巧妙で誤解を招くような攻撃のことで、貴社の製品が攻撃者に操作されてしまうと、風評被害や収益の損失につながる可能性があります。クリックジャッキングについての詳細は、無料のラーニングリソースをご覧ください。

コンテンツ・セキュリティ・ポリシーと「X-Frame-Options」ヘッダーを使用して、他の人があなたのサイトを悪意のある方法で使用するのを防ぎましょう。攻撃者がユーザーを操作することを許してはいけません。クリックジャックされないようにしましょう。

OS コマンドインジェクション攻撃は、アプリケーションがユーザーにシェルへの入力を許可しているにもかかわらず、入力文字列が有効であるかどうかを確認するアクションを取らない場合に発生します。これにより、攻撃者は、アプリケーションをホストしている OS に直接コマンドを投下することができ、その際、侵害されたアプリケーションに設定されているあらゆる許可レベルを使用することができます。  

OSコマンドインジェクション攻撃は、エントリーレベルのハッカーやスキルの低いハッカーでも行うことができるため、セキュリティチームが経験する最も一般的な弱点の1つとなっています。ありがたいことに、これらの攻撃を防ぐための非常に効果的な方法がいくつかあります。このエピソードでは、次のことを学びます。

       仕組み

       なぜ彼らは危険なのか

       それを阻止するためには、どのような防御策を講じるべきか。

OSコマンドインジェクションはどのように利用されるのか？

OSコマンドインジェクション攻撃を行うために、攻撃者が最初にしなければならないことは、アプリケーション内のユーザー入力を見つけることです。ユーザーが入力するフォームは、良い出発点となる可能性があります。最も巧妙な攻撃者は、ほとんどすべてのアプリケーションやWebサイトで使用されている、クッキーやHTTPヘッダーなども攻撃の起点として使用します。

次に必要なのは、アプリケーションをホストしているOSを把握することです。選択肢が限られているので、この段階では試行錯誤が有効です。ほとんどのアプリケーションサーバは、Windowsベース（Windowsのフレーバーは通常問題ではありません）、何らかのLinuxボックス、またはUnixである可能性があります。

この時、ハッカーは入力を修正して、一見無害に見える入力にOSのコマンドを注入します。これにより、ホスティングOSを騙し、アプリケーションが持つあらゆる許可レベルで意図しないコマンドを実行させることができます。

例えば、次のコマンドは、アプリケーション内の有効なユーザーがファイルの内容を見るために使用することができます（この場合は、月例理事会のメモ）。

exec("cat " + filename")

この例では、次のコマンドを実行して、ユーザーに会議のメモを返します。

$ ./cat MeetingNotes.txt

7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。

これは、Linuxでディレクトリの内容を一覧表示するときに使われるような、入力の最後に攻撃者が追加のコマンドを追加したときに起こる現象です。このケースでは、会議のメモを表示するという元のコマンドはそのまま実行されます。しかし、悪意のあるユーザーには、ディレクトリ内の他のすべての内容が表示され、OSのコマンドインジェクション攻撃のフォローアップに使用できる他のコマンドも表示されます。彼らは入力します。

$ ./cat MeetingNotes.txt && ls

そして、代わりにこれを手に入れる。

7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。

MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c

このケースでは、ハッカーはディレクトリの内容を見せられただけでなく、ホストOS上で実行できることがわかっている他のコマンドのメニューを渡されました。

OSコマンドインジェクション攻撃はなぜ危険なのか？

ユーザーが対象となるアプリケーションの目的を回避して、オペレーティングシステムのコマンドを実行するために使用できるようにすることは、非常に危険です。攻撃者は、例えば、機密データを盗んだり、サーバーのドライブ全体をフォーマットするなど、壊滅的な行為を簡単に行うことができます。攻撃者が利用できる選択肢は、オペレーティングシステムで許可されているコマンドと、それを使用する際の創造性によってのみ制限されます。

OSのコマンドは、アプリケーションと同じ権限レベルで実行されます。管理者権限で実行されるアプリケーションは、それを侵害したハッカーがOSのあらゆるコマンドを実行できることを意味します。

OS コマンドインジェクションの攻撃パターンはよく知られており、文書化されています。脆弱なアプリケーションは、プロのハッカーと同様に、スクリプトキディの影響を受けやすくなります。ほとんどスキルのない攻撃者は、OS のコマンドをアプリケーションにカット＆ペーストして、何が起こるかを試すことができます。

OSコマンドインジェクションに対するセキュリティOKの取得

OSのコマンドインジェクションを阻止するための優れた技術がいくつかあります。まず、アプリケーションを、その機能を果たすために必要な最小限の権限で実行することです。これによって攻撃を防ぐことはできませんが、万が一侵害が発生した場合には被害を最小限に抑えることができます。

ほとんどのプログラミング言語やフレームワークは、ディレクトリの内容の一覧表示や、ハードディスク上のファイルの作成や読み取りなど、OSの一般的なメソッドのAPIコールを提供しています。OSコマンドインジェクションを環境から排除する完璧な方法は、すべてのアプリケーションがOSコマンドを直接使用する代わりに、これらのAPIコールを使用することです。

これが不可能な場合は、ユーザーの入力を検証してからOSのコマンドで使用する。ホワイトリストを使用すると、信頼できる小さな値のセットのみを使用することができます。技術的にはブラックリストを使っても可能ですが、許可されるコマンドの数が圧倒的に少ないので、ホワイトリストの方が簡単な場合がほとんどです。ホワイトリストには、有効なPOSTとGETのパラメータを含めることを忘れないでください。また、クッキーのような見落とされがちなユーザー入力ベクターも含めてください。

最後に、利用可能なプログラミングAPIがなく、ホワイトリストを使用できない場合は、サニタイズライブラリを使用して、ユーザーの入力に含まれる特殊文字をOSのコマンドで使用する前にエスケープします。

OSコマンドインジェクション攻撃の詳細情報

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