ビジネスアプリケーションを構築する際、社内向けであれ、顧客向けであれ、すべてのユーザーにすべての機能を実行させることはないでしょう。そうすると、アクセスコントロールが機能しなくなる恐れがあります。

壊れたアクセスコントロールとは何か、なぜそれが危険なのか、そしてそれを修正する方法を見てみましょう。

壊れたアクセスコントロールの理解

アクセスコントロールの破綻は、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合に発生します。また、アプリケーションが何らかの形で誤設定され、ユーザがアクセスしてはいけない機能やページへのアクセスを許してしまう場合にも発生します。

会社の財務を担当している方は、特定の口座にお金を預けたり、会社の口座間でお金を移動したりすることができます。しかし、それらの口座から現金を引き出したり、他の口座に送金したりするためのアクセス権は持ってはいけません。適切なアクセスチェックが行われていない場合、従業員が必要以上の機能を実行できてしまう可能性があります。

これらのチェックは、コードの中で行われる場合と、設定ファイルの中で行われる場合があります。例えば、ウェブアプリケーションフレームワークに、どのユーザがどのページへのアクセスを許可されているかを伝えるXML設定ファイルがある場合があります。これにより、ユーザは自分が使用することを許可された機能にのみアクセスすることができます。

壊れたアクセスコントロールが危険な理由

次のような例を考えてみましょう。攻撃者は、ユーザアカウント作成コードが操作可能であることに気づき、単純な投稿リクエストで管理者ユーザを作成できるようになりました。攻撃者は、ユーザ名とパスワードを指定してリクエストを送信し、途中で変更して、パラメータとしてのURLやリクエストの本文にadminの役割を含めることができます。攻撃者はアプリケーションにログインし、即座に管理者権限を与えられます。

システムに侵入するのは、悪意のある攻撃者とは限りません。適切なアクセスコントロールがなければ、部門間で共有されるべきではない機密情報が流出する可能性があります。想像してみてください。社内のどの社員も人事の給与データや財務データを見ることができるとしたら。会社の財務状況が悪いためにレイオフが行われることを、どの従業員も知ることができたらどうなるでしょうか。士気や会社の評判にダメージを与えかねません。

また、お客様の機密情報も失われる可能性があります。企業は、自社のサービスを利用するお客様の個人情報を保管していることがあります。アクセスコントロールができていないために、誤ってこれを公開してしまわないように注意してください。例えば、ユーザーが自分の健康記録を請求できるシステムの場合、ユーザーは他の人の健康情報を請求したり、見たりすることもできますか？URLに顧客ID番号が含まれている場合、攻撃者はその顧客ID番号を、他の顧客と一致するものが見つかるまで何度も増分して、顧客の個人情報を公開することができます。

壊れたアクセスコントロールの克服

ロールベースアクセスコントロール（RBAC）は、健全なアクセスコントロールを実現するための非常に有効なツールである。Active Directoryを使用している人は、グループを作成し、個人ではなくグループ全体に特定のアイテムへのアクセス権を与えるというアイデアに慣れているかもしれない。アプリケーションも同様に、ロールを使って誰が何を見ることができるかを定義する。

これには2つの利点があります。まず、管理者を辞めるときに機能を変更する必要がありません。誰かが以前は管理者だったが、今はもう管理者である必要がない場合、新しい人を管理者ロールに入れて、以前の人をロールから外すだけです。このコードでは、個々のユーザーが特定のページや機能へのアクセス権を持っているかどうかをチェックする代わりに、ユーザーが管理者ロールを持っているかどうかをチェックします。

2つ目の利点は、メンテナンスの悪夢を回避できることです。すべての人がすべての機能やページに関連づけられているような細かいアクセスコントロールは、長期間にわたって管理することは不可能です。ロールでは、1つのロールに複数の人を追加することができるため、管理が非常に容易になります。あるロールには会社全体が含まれていますが、別のロールには5人しか含まれていないかもしれません。これにより、管理する役割が少なくなり、効率的に管理できるようになります。10,000人の会社であれば、アプリケーションの機能数が10,000倍になる代わりに、ロールの数が100個で済むことになります。堅牢なアクセスコントロールのためにどのようなオプションがあるか、選択したアプリケーションフレームワークを調査してください。

また、機能レベルのアクセス制御を行うことも重要です。すべての機能へのアクセスを保護するために、ユーザーは特定のアクセス制御チェックに合格する必要があります。最小限の特権の原則を用いて、デフォルトではアクセスを拒否し、必要に応じてのみアクセスを許可する。機能ごとにアクセスコントロールを実施することを忘れないようにする。アクセスコントロールの管理と実施には、中央のコンポーネントを使用する。

デリケートな機能を守る

アクセスコントロールが機能していないと、データやアプリケーションが攻撃や搾取の対象となってしまいます。適切に保護されていない顧客データは、大規模なデータ侵害につながり、企業の評判や収益に悪影響を及ぼす可能性があります。

また、アクセスコントロールがうまくいかないと、攻撃者がアクセスすべきでない機能にアクセスできてしまい、アカウントの乗っ取りにつながる可能性があります。適切な機能レベルのアクセスコントロールを使用することで、悪意のある攻撃者や偶発的なインサイダーからもアプリケーションを安全に保つことができます。

ファンクショナルレベルのアクセスはもういいと思っていませんか？壊れたアクセスコントロールの修理に今すぐチャレンジしてみませんか？ [Start Here] (ここからスタート)

"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。

ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。

この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。

情報露出の把握

情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。

多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。

機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。

一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。

情報漏洩の危険性を理解する

アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。

攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。

OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。

情報露出をなくす

情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。

アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。

ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。

ウェブアプリを沈めないために

第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。

同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。

アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。

今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]

すべてのアプリケーションに共通するものは何でしょうか？それはコンポーネントであり、依存関係やライブラリとも呼ばれます。世の中には、どこかの時点で他のコードに依存していないコードはほとんどありません。アプリケーションを作成した時点で、依存関係が山のようにあるのです。

すべてのアプリケーションはコンポーネントを使用しており、そのほとんどはあなたが書いたものではありませんので、使用しているコンポーネント内の脆弱性が負債となる可能性があります。ここでは、既知の脆弱性を持つコンポーネントを使用することの意味、その危険性、解決方法について説明します。

既知の脆弱性を持つコンポーネントの使用に関する理解

複雑なソフトウェアには必ず脆弱性があります。それが獣の性質なのです。ですから、あなたのコンポーネントが100％安全であることはありません。しかし、コンポーネントに脆弱性が見つかったとき、あなたはそれを知っていますか？そのための準備はできていますか？

問題が発生するのは、コンポーネントが耐用年数を超えて使用された場合や、脆弱性が発見された後であることがほとんどです。ほとんどのコンポーネントやライブラリは、セキュリティ上の脆弱性が発表されるのと同時に、またはそれ以前に、その脆弱性に対するパッチをリリースしています。したがって、コンポーネントの脆弱性が発見・公表された場合には、できるだけ早くコンポーネントを更新することが何よりも重要です。脆弱なソフトウェアを本番環境に放置しないでください。

コンポーネントにはいくつかの供給元があります。サードパーティのベンダー製品を購入して、自分のカスタムコードと直接統合することもあります。これらのコンポーネントは、あなたのコードの一部となり、同じレベルの権限で動作します。もう一つのソースは、GitHubのようなサイトでホストされているオープンソースプロジェクトです。すべてのオープンソース・ライブラリが慎重に吟味されているわけではなく、また脆弱性がないか監査されているわけでもないので、オープンソースは危険です。

攻撃者は、コンポーネントの脆弱性情報を利用しています。脆弱性は公開されているので、攻撃者はあなたと同じタイミングで脆弱性を知っています。また、攻撃者は、あなたが使用しているコンポーネントを見つけるために使用できる技術を持っています。これらの情報が分かれば、アプリケーションにパッチが適用されていない場合の攻撃方法が分かります。

脆弱な部品がなぜ危険なのかを知る

脆弱性が知られているコンポーネントを使用することがどれほど危険かを示す証拠を探しているなら、2017年のEquifax社の情報漏えいを見れば一目瞭然でしょう。

2017年7月、米国の信用調査機関であるEquifax社が、1億4700万人以上の個人を特定できる情報を流出させる大規模なデータ流出を発見しました。このデータ侵害の範囲と影響は前例のないものです。最近では、Equifaxのセキュリティ対策の甘さを指摘するニュースが出ています。

その1つがパッチ管理です。Equifaxではパッチ管理が十分ではなかったため、コンポーネントにパッチが適用されないまま長期間が経過していました。これが今回の侵害の直接の原因です。

Equifax社のWebサイトでは、Webフレームワーク「Apache Struts」が使用されていました。攻撃者がネットワークに侵入する数カ月前に、Strutsフレームワークに脆弱性「Apache Struts CVE-2017-5638」が発見されました。しかし、Equifax社はこの脆弱性にパッチを当てていませんでした。攻撃者はこの脆弱性を利用して、Equifax社のネットワークにアクセスしました。そこから、個人情報の宝庫にアクセスしたのです。

多くのWebサイトは、自社で作成したものではないWebフレームワークをベースにしています。これは、必要な機能をすべて一から構築するのは大変な作業なので、標準的な方法です。しかし、フレームワークへの依存度が高いと、脆弱性が発生する可能性があります。次のEquifaxにならないために。

脆弱なコンポーネントからの保護方法

脆弱なコンポーネントの使用を防ぐための特効薬はありません。しかし、システムを危険にさらすために脆弱なコンポーネントが使用されるリスクを軽減するために使用できるポリシーとコントロールがあります。

アプリケーションを構築するためには、どのコンポーネントを、どのバージョンで使用しているかを知る必要があります。OWASP の Dependency Checkのような依存性管理ツールは、あなたが使用している依存性を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントの中に、一般に公開されている脆弱性があるかどうかも教えてくれます。

また、パッチマネジメントの手法も不可欠です。脆弱性が発見された場合、パッチがダウンロードされ、テストされ、本番にスムーズにリリースされるようなシステムが必要です。ソフトウェアにパッチを当て続けることで、数ヶ月前の脆弱性が攻撃者に利用されることを防ぎます。

最後に、オープンソースやサードパーティ製コンポーネントの使用を管理するためのポリシーを用意します。開発者はお役所仕事を嫌うものです。しかし、自組織が作成したものではないコードについては、審査プロセスを設ける必要があります。それは重荷である必要はありませんが、未知のコンポーネントが使用されるのを防ぐためには必須です。少なくとも、使用されているコンポーネントのインベントリーは最新の状態に保たれていなければなりません。

サードパーティ・バグに巻き込まれないために

コンポーネントには脆弱性があります。あなたのビジネス・アプリケーションは、ベンダーのものであれ、オープンソース・ライブラリのものであれ、コンポーネントを使用します。だからといって、あなたの組織が攻撃されやすいとは限りません。

攻撃者はあなたと同じ時期にどのような脆弱性が存在するかを知っているにもかかわらず、通常、パッチは一般の発表と同時に提供されます。ですから、自分のアプリケーションが何を使用しているのか、必ず教育してください。何が脆弱なのかを知る。コンポーネントには常にパッチを当てておきましょう。

脆弱な部品を発見して（倒して）いく準備はできていますか？アリーナに行ってバトルしてみましょう。 [Start Here]をクリックしてください。

原文は以下の通りです。 DevSecConブログ.

双方の立場に立ってみて、セキュリティのベストプラクティスを守ることに関して、開発チームとAppSecのスペシャリストの間に起こりうる緊張感をよく理解しています。

難しいですね。結局のところ、開発者の最優先事項はソフトウェアの機能を提供することです。これらの機能は、美しく、機能的で、アプリケーションのパワーをアピールするものでなければなりません。最近では、アジャイル開発が一般的に行われているため、これらの機能は厳しい納期に合わせて完成させなければなりません...そして、他の多くの問題がある中で、セキュリティが高い関心事になることはほとんどありません。

セキュリティはAppSecチームの領域と考えられています。AppSecチームはコードをスキャンして（もっとひどい場合は、一行ずつ手作業でレビューして）、コードが安全でない、あるいはまったく使用できないと開発チームに報告するという、気の遠くなるような仕事をしています。彼らは、自分たちの良い仕事を邪魔し、イノベーションを妨げ、開発者の頭痛の種となる泥まみれの棒です。結局のところ、多くのセキュリティ問題は簡単に解決できるものです。おそらく、たった1行のコードが数分で脆弱なバックドアを強化してしまうでしょう。

しかし、ここに問題があります。セキュリティ」があまりにもネガティブな代名詞になっているため、開発者は必要以上にセキュリティに関与していないのです。結局、AppSecの担当者は常に同じ問題に直面しているのです。私たちがSQLインジェクションの欠陥を発見してから（そしてその後の修正から）20年以上経ってもなお、彼らがSQLインジェクションの欠陥を指摘し続けるのは、非常に気が重いことでしょう。

私たちがこれまでに行ってきたことは、私たちが期待したほど効果的ではありませんでした。私たちは、開発者とAppSecスペシャリストの間の橋を修復することに焦点を当て、開発者がこの分野で真の影響を与えるためのツールとトレーニングを与えられるような、前向きなセキュリティ文化を目指していく必要があります。

誰にもわからない。私のように好きになってくれるかもしれません。

ポジティブなセキュリティは、アプリケーションのセキュリティを向上させる最も早くて簡単な方法です。

そしてそれは、無形の成果をもたらすうわべだけのものではありません。セキュアコーディングを成功させるためには、絶対に欠かせない要素なのです。

開発者は、最初に安全なコードを書くことによって、生産の最初の段階からセキュリティを向上させる鍵を握っています。積極的なセキュリティ文化を創造し、開発者がアプリケーション・セキュリティに関心を持つようにすることで、一般的な脆弱性は、AppSecランドのスキャンや手動のコードレビューにかけられる前に一掃することができます。

すでにコミットされているコードの脆弱性を修正するには、30倍のコストがかかります。ですから、開発者の強みを活かし、興味を引き、実際に効果のあるトレーニングを見つけることは、繰り返し発生する脆弱性を特定して修正するための将来的なコスト削減の大きな一歩となります。

開発者を中心とした前向きな取り組みが、適切なセキュリティ文化を育みます。

全員がセキュリティのベスト・プラクティスを理解していれば、ポジティブなセキュリティ・カルチャーは幸せで重要な副産物となります。

開発者を中心としたポジティブでスケーラブルな取り組みが、適切なセキュリティ文化を育みます。開発者の問題解決能力と創造性を引き出すことは、開発者を獲得するために不可欠であり、また、新入社員がチームのセキュリティに対する期待に迅速に対応できるようにするためにも必要です。開発者とセキュリティの関係がどのように進化してきたのか、また、お客様の組織でセキュリティ意識向上プログラムを成功させるためのアイデアについては、こちらまでお問い合わせください。

このブログでは、ウェブサイトを運営している企業や、従業員にコンピュータリソースへのリモートアクセスを許可している企業（ほとんどの企業）が直面する最も一般的な問題の1つを取り上げます。このブログでは、Webサイトを運営している企業や、従業員がリモートでコンピュータリソースにアクセスする際に直面する最も一般的な問題の1つである「認証」について取り上げます。

ハッカーが有効なユーザー名とパスワードを使って管理者としてシステムにログインするだけであれば、ネットワーク防御に対抗するための高度な技術を導入する必要はありません。システムがドアを開けて攻撃者を侵入させるだけです。さらに悪いことに、攻撃者があまり突飛なことをしなければ、その存在を検知することはほとんど不可能です。なぜなら、ほとんどの防御システムは、攻撃者を有効なユーザーまたは管理者が自分の仕事をしていると見なすからです。

認証の脆弱性のカテゴリーは非常に大きいのですが、ここでは、ユーザーのログインプロセスに誤って組み込まれがちな、最も一般的な問題について説明します。これらの穴を塞ぐことで、認証に関する問題の大部分を組織から取り除くことができます。

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

• 一般的な認証の脆弱性がどのように利用されるか
• なぜ彼らは危険なのか
• 認証の脆弱性を排除するために、どのようなポリシーやテクニックを用いることができるか。

攻撃者はどのようにして認証の脆弱性を利用するのか？

認証システムに入り込む可能性のある認証の脆弱性は非常に多く、ハッカーはそれぞれの脆弱性を少しずつ悪用しています。まず、最も一般的な脆弱性について説明し、次にそれらの脆弱性がどのように悪用されるかを示す例を挙げてみましょう。

最も一般的な認証の脆弱性は以下の通りです。

• 弱いまたは不適切なパスワードポリシーを持つこと。
• 無制限のログイン試行を許可する。
• ログインに失敗したときに攻撃者に情報を提供する。
• 認証情報を安全でないチャンネルで送信すること。
• パスワードを弱くハッシュ化すること。
• そして、安全ではないパスワード回復プロセスを持っていること。

パスワードポリシーが脆弱であることは、最も一般的な脆弱性であると考えられます。ユーザーが何の制限もなくパスワードを作成できるとしたら、あまりにも多くのユーザーが簡単に推測可能なパスワードを使用してしまうでしょう。毎年、様々なコンピュータ関連の報道機関が「最も使われているパスワード」を発表していますが、「123456」や「password」は常にトップ5に入っています。他にもあります。管理者は「God」をよく使います。確かに、これらはどれもユーモアがあって覚えやすいですが、同時に非常に推測しやすいものでもあります。ハッカーは最も一般的なパスワードを知っていて、システムに侵入しようとするときにまずそれを試します。そのようなパスワードを許している組織では、いずれ侵入されてしまうでしょう。

あまり目立たないが、それでも危険な脆弱性は、ログインに失敗したときにユーザに情報を返すことです。これは、ユーザ名が存在しない場合に1つのメッセージを返し、ユーザ名は存在するがパスワードが不正である場合に別のメッセージを返すと、攻撃者がシステム上の有効なユーザをマッピングし、それらのユーザ名のためだけにパスワードを推測することに集中できるようになるからです。これが、パスワードを無制限に推測できる認証の脆弱性と組み合わさると、攻撃者は見つけた有効なユーザーに対して辞書攻撃を行うことが可能になり、パスワードが簡単に推測できる場合には、かなり早くシステムに侵入できるかもしれません。

認証の脆弱性はなぜ危険なのか？

アメリカの旧西部には、ある偏執狂的な開拓者の物語がある。彼は玄関に3重の鍵をかけ、窓を塞ぎ、たくさんの銃を手の届くところに置いて寝ていた。朝、彼は死体で発見された。裏口に鍵をかけるのを忘れたため、攻撃者に狙われてしまったのです。認証の脆弱性はそれとよく似ています。攻撃者が有効なユーザ名とパスワードを使ってネットワークに侵入することができれば、どのような監視ツールやプロアクティブなコントロールを導入していても、専門のアナリストをどれだけ雇っていても、実際には問題になりません。

いったん侵入してしまえば、攻撃者ができることにはほとんど制限がありません。管理者アカウントを侵害した場合には、かなり広範囲に及ぶユーザー権限の範囲内で行動する限り、深刻な問題を防ぐのに間に合うように攻撃者が捕まる可能性は非常に低くなります。このため、認証クラスの脆弱性は、あらゆるシステムで最も危険なものの1つとなっています。

認証の脆弱性を排除する

ネットワークから認証の脆弱性を排除する最良の方法の1つは、グローバルに施行される優れたパスワード・ポリシーを持つことです。ユーザーはもちろん、管理者であっても、「password」のようなパスワードの使用を制限するだけでなく、攻撃者が辞書攻撃や常套句攻撃を行うことができないような複雑なレベルのパスワードを追加する必要があります。保護するシステムの重要性に応じて、独自のパスワード作成のルールを作ることができます。そうすることで、攻撃者がパスワードを推測したり、ブルートフォース攻撃をしたりすることが非常に難しくなります。

また、不正なパスワードが3回以上入力された場合、ユーザーがロックアウトされるように、ログイン試行の失敗回数を制限する必要があります。ロックアウトは一時的なものでも構いません。数分遅れるだけで、自動化された辞書攻撃が続くのを防ぐことができます。また、管理者がアカウントのロックを解除しない限り、永久的にロックアウトされることもあります。いずれの場合も、このようなロックアウトが発生した場合には、セキュリティ担当者に警告し、状況を監視できるようにする必要があります。

攻撃者による情報収集を防ぐもう一つの良い方法は、不正なユーザー名またはパスワードが入力された場合に、一般的なメッセージを作成することです。ユーザーが存在しないために拒否されたのか、パスワードが間違っているために拒否されたのか、ハッカーにはわからないように、どちらの場合も同じメッセージを表示する必要があります。

認証の脆弱性は、ほとんどのシステムで最も一般的で危険なものの一つです。しかし、これらの脆弱性を発見し、排除することはかなり容易です。

認証の脆弱性に関する詳細情報

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

Secure Code Warrior プラットフォームで認証の脆弱性に正面から向き合うステップアップ。[Start Here] (ここからスタート)

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

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

しかし、自動化対策が不十分な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] (ここからスタート)