変更ログ：OWASPトップ10プロジェクト

公開: 2022-03-11

Webアプリケーションは、過去10年間で複雑さを増してきました。 それらは、連絡先フォームと投票用の単純なコンテナーから本格的なアプリケーションに進化しました。 サイズとパフォーマンスの両方で、それらを重いデスクトップアプリケーションと比較できます。 複雑さが急増し、機能が豊富なアプリケーションの数が増えるにつれ、すべてのアプリケーションコンポーネントを可能な限り安全にするために多くの時間と注意を払う必要があります。 インターネットユーザーの大幅な増加により、データおよびアプリケーションユーザーの保護の問題に取り組むことがさらに重要になっています。 忍び寄り、関係者全員に深刻な頭痛を引き起こそうとする脅威の膨大なプールがあります。

2001年には、新しい組織が登場しました。 その目標は、Webサイトやアプリケーションに影響を与えるセキュリティの問題と戦うことでした。 これは、Open Web Application Security Project（OWASP）と適切に名付けられました。 現在では、リソースを公開し、会議を開催し、Webおよびアプリケーションのセキュリティに関する標準を提案しています。 Webアプリケーションセキュリティのデファクトスタンダードは、OWASPトップテンプロジェクトです。 最も一般的な10のセキュリティ脅威がリストされています。 何が入るかを決定する際の影響力のある要因は、大量のデータとコミュニティのフィードバックでした。 2017年後半に、プロジェクトの更新がありました。 多くの最新のWebアプリケーションにとって重要ないくつかの新しい問題がその場所を受け取りましたが、いくつかはリストから脱出しました。

この記事は、元のリストを補足し、リストに対する最新の変更を示しています。 脅威について説明し、理解を容易にするための明確な例を提供し、セキュリティの脅威と戦う方法を提案します。

OWASPトップ10リストから削除された問題

2017年の更新前は、2013年のリストが最新のものでした。 Webアプリケーションの構築方法と使用方法の変更を考慮すると、徹底的な改訂を行うことは理にかなっています。 マイクロサービスはそのパイの一部を取り、新しいクールで光沢のあるフレームワークがバニラコードのバトルギアに取って代わりつつあります。 これらの事実は、以前にリストされた脅威のいくつかが削除され、いくつかの新しい脅威がそれらに取って代わったことを意味します。

この記事では、長い間忘れられていた問題の記憶を更新し、新しい悪いオオカミを紹介します。 歴史について学ぶことは、同じ過ちを繰り返さない唯一の確実な方法です。

クロスサイトリクエストフォージェリ

クロスサイトリクエストフォージェリ（CSRF）は、プロジェクトの最近の反復における「敗者」の1つです。 最新のWebフレームワークの多くにCSRF防御メカニズムが含まれているため、これはなくなりました。 したがって、アプリケーションが脅威にさらされる可能性は急速に低下します。

CSRFがリストに残っているかどうかに関係なく、記憶を更新するのは良いことです。 それがこれまで以上に強く戻ってこないことを確認しましょう。

本質的に、CSRFは発煙弾を感じるエクスプロイトです。 攻撃者は、疑いを持たないユーザーをだまして、Webアプリケーション内で不要な要求またはアクションを実行させます。 簡単に言うと、攻撃者は被害者にサードパーティのアプリケーションにリクエストを送信するように強制し、被害者はリクエストが送信されたことに気づきません。 リクエストは、リソースを取得するためのHTTP GETリクエスト、またはさらに悪いことに、被害者の制御下にあるリソースを変更するHTTPPOSTリクエストである可能性があります。 攻撃中、被害者はすべてが正常であると考えます。ほとんどの場合、バックグラウンドで何かが起こっていることに気付くことさえありません。 空気がきれいになった後、損傷が発生したか、何かが欠けていて、何が起こったのか誰にもわかりません。

ターゲットアプリケーション内で以前のユーザー認証が成功したことが、トラップを有効にするための手段です。 ユーザーは、攻撃がアプリケーションにサインインする前のある時点で持っていました。 アプリケーションは被害者にCookieを送信してそれらを記憶させました。 Webブラウザーが悪意のある要求を送信すると、Cookieは潜在的なペイロードとともに自動的に送信され、アプリケーションは、既に知っているユーザーに要求を提供することに反対しません。

最も有名な例の1つは、ユーザーをだまして自分のアカウントから攻撃者が制御するアカウントに送金することです。 ユーザーは、アカウントの残高を確認するために電子バンキングシステムにサインインします。 その後、オンラインフォーラムにアクセスして、新しい携帯電話のレビューを確認します。 ダイナマイトを使って釣りをしている攻撃者が、画像のハイパーリンクが壊れているように見える画像を含むレビューを投稿します。 攻撃者は、実際のハイパーリンクの代わりに、電子バンキングシステムが内部でアカウントAからアカウントBに送金するために使用するハイパーリンクを使用します： https://payments.dummybank.com?receiver=attacker&amount=100 ：//payments.dummybank.com？receiver =attacker＆amount=100。 銀行システムは、認証されたユーザーを送信者にし、「受信者」パラメーターからの値を資金の受信者にします。 もちろん、攻撃者はオフショアアカウントを受信者として指定します。

ブラウザはページのレンダリング時に画像を自動的に読み込むため、リクエストはバックグラウンドで発生します。 銀行の支払いシステムがHTTPGETリクエストを使用して送金を実装している場合、災害の発生を阻止するものは何もありません。 この例は単純であり、ほとんどの場合、転送はHTTPGETを介して処理されないことに注意してください。 ただし、攻撃者は、少しだけ困難を伴いながら、フォーラムのHTMLメッセージ投稿フォームの属性「アクション」を変更することができます。 次に、ブラウザは、フォーラムのバックエンドではなく、銀行の支払いシステムにリクエストを送信します。

お金を盗むことは、そこにある多くの例の1つにすぎません。 ユーザーのメールアドレスを変更したり、意図しない購入を行ったりすることも、このカテゴリに分類されます。 よくあることですが、ソーシャルエンジニアリングといくつかの技術的知識は、ソフトウェアエンジニアリングの間違いに対して効果的に活用されます。

システムを設計するときは、次の点に注意してください。

  • リソースを変更するアクションをカプセル化するためにHTTPGETリクエストを使用しないでください。 これらのリクエストは、情報を取得するためにのみ使用してください。 経験則では、GETリクエストをべき等にすることを忘れないでください。
  • HTTP POSTリクエストを使用してデータを内部的に転送する場合は、JSON、XML、またはパラメータをクエリ文字列としてエンコードする以外の形式でデータを送信する傾向があります。 重要なデータ形式を使用すると、誰かがデータをサービスに送信する偽のHTMLフォームを作成する危険性が減少します。
  • 必ず、一意で予測不可能なトークンを作成してHTMLフォームに含めてください。 これらのトークンは、リクエストごとに一意である必要があります。 このようなトークンの存在と正確さをチェックすることで、脅威が発生するリスクを減らすことができます。 トークンを見つけて偽のリクエストで使用するには、攻撃者はシステムにアクセスし、そこから直接トークンを取得する必要があります。 トークンは1回限りであるため、悪意のあるコードで再利用することはできません。

この脆弱性は、クロスサイトスクリプティング（XSS）と組み合わせると、さらに悪影響を及ぼします。 攻撃者が悪意のあるコードをお気に入りのWebサイトまたはアプリケーションに挿入できる場合、攻撃の範囲ははるかに重要で危険になります。 さらに重要なのは、XSS攻撃が可能である場合、攻撃者はCSRFに対する保護メカニズムの一部を回避する可能性があることです。

CSRFは消えていないことを覚えておいてください。これは、以前ほど一般的ではありません。

動作中のCSRFの図—OWASPトップ10から削除

未検証のリダイレクトと転送

多くのアプリケーションは、アクションを終了した後、ユーザーを同じアプリケーションの別の部分、または他のアプリケーションにリダイレクトまたは転送します。 たとえば、アプリケーションに正常にサインインすると、ホームページまたはユーザーが最初にアクセスしたページへのリダイレクトがトリガーされます。 多くの場合、宛先はフォームのアクションまたはリンクアドレスの一部です。 リダイレクトまたは転送を処理するコンポーネントが、宛先アドレスが実際にアプリケーションによって生成されたものであることを確認しない場合、潜在的な脅威が発生します。 これは、「未検証のリダイレクトと転送」と呼ばれるセキュリティの脆弱性です。

検証されていないリダイレクトと転送が危険であると見なされる2つの主な理由は、フィッシングと資格情報の乗っ取りです。 攻撃者は、リダイレクト/転送先の場所を変更して、元のアプリケーションとほとんど区別がつかない悪意のあるアプリケーションにユーザーを送ることができます。 疑いを持たないユーザーが、悪意のある第三者に自分の資格情報と機密情報を公開します。 彼らが何が起こったのかを理解する前に、それはすでに手遅れです。

例として、Webアプリケーションは、最後にアクセスしたページへのリダイレクトをサポートするサインインを実装することがよくあります。 これを簡単に実行できるようにするために、HTMLフォームのアクション属性はhttp://myapp.example.com/signin?url=http://myapp.example.com/puppiesのようになります。 あなたは子犬を大いに愛しているので、ウェブサイトのファビコンをお気に入りの子犬のサムネイルに置き換えるブラウザ拡張機能をインストールするのは理にかなっています。 残念ながら、それは犬を食べる犬の世界です。 ブラウザ拡張機能の作者は、あなたの無条件の愛を利用して、追加の「機能」を導入することにしました。 お気に入りの子犬ファンサイトにアクセスするたびに、フォームのaction属性の「url」パラメーターが自分のサイトへのリンクに置き換えられます。 サイトはまったく同じように見えるため、子犬のトランプを購入するためにクレジットカードの詳細を提供すると、実際には趣味ではなく、悪意のある攻撃者に資金を提供します。

脆弱性を解決するには、目的の場所であることを確認して目的地を確認する必要があります。 フレームワークまたはライブラリが完全なリダイレクトまたは転送ロジックを実行する場合は、実装を確認し、必要に応じてコードを更新すると便利です。 それ以外の場合は、攻撃から保護するために手動でチェックする必要があります。

あなたがすることができるチェックのいくつかのタイプがあります。 最高の保護のために、それらの1つだけに固執するのではなく、いくつかのアプローチの組み合わせを使用してください。

  • 送信URLを検証して、管理しているドメインを指していることを確認します。
  • 明示的なアドレスを使用する代わりに、フロントエンドでエンコードしてから、バックエンドでデコードして検証します。
  • 信頼できるURLのホワイトリストを作成します。 ホワイトリストに登録された場所にのみ転送とリダイレクトを許可します。 ブラックリストを維持するために、このアプローチを優先します。 ブラックリストは通常​​、何か悪いことが起こったときにのみ新しいアイテムで埋められます。 ホワイトリストはより制限されています。
  • LinkedInやその他のアプリケーションで使用されているアプローチを採用する：リダイレクト/転送の確認を求めるページをユーザーに提示し、ユーザーがアプリケーションを離れることを明確にします。

マージされた問題

リストにある問題のほとんどは、知識が不足しているか、潜在的な脅威の調査が不十分であるために、実装の欠陥としてラベル付けされる可能性があります。 これらの理由は両方とも経験不足に起因する可能性があり、将来それらを検討するための解決策は簡単です。ただ、より多くを学び、より徹底するようにしてください。 特にトリッキーなものは、複雑なコンピュータシステムの開発と保守の難しさと相まって、あまりにも多くの仮定を行うという危険な（しかし非常に人間的な）特性の組み合わせに依存しています。 このカテゴリに該当する脆弱性は、「壊れたアクセス制御」です。

壊れたアクセス制御

脆弱性は、アプリケーションの特定の部分に対する承認とアクセス制御が不十分または完全に欠如していることが原因で発生します。 OWASPトップテンプロジェクトの以前の反復では、2つの問題がありました。安全でない直接オブジェクト参照と機能レベルのアクセス制御の欠如です。 それらは類似しているため、1つに統合されました。

直接オブジェクト参照

直接オブジェクト参照は、操作対象のリソースを識別するためにURLでよく使用されます。 たとえば、ユーザーがサインインすると、プロファイルIDを含むリンクをクリックしてプロファイルにアクセスできます。 同じ識別子がデータベースに保存され、プロファイル情報の取得に使用され、アプリケーションは、ユーザーがサインインページを介してのみプロファイルページにアクセスできると想定している場合、URLのプロファイル識別子を変更すると、別のユーザーのプロファイル情報が公開されます。

プロファイルの削除フォームhttp://myapp.example.com/users/15/deleteのURLを設定するアプリケーションは、アプリケーション内に少なくとも14人の他のユーザーがいることを明確にします。 この場合、他のユーザーの削除フォームにアクセスする方法を理解することは、ロケット科学ではありません。

この問題の解決策は、アプリケーションの一部に到達するために特定のパスしか使用できないと想定せずに、各リソースの承認チェックを実行することです。 さらに、直接参照を削除して間接参照を使用することは、悪意のあるユーザーが参照の作成方法を理解するのを困難にするため、もう1つの前進です。

開発中は、予防策として、単純なステートマシン図を書き留めてください。 状態がアプリケーション内のさまざまなページを表し、ユーザーが実行できるアクションを遷移させます。 これにより、特別な注意が必要なすべてのトランジションとページを簡単に一覧表示できます。

ステートマシン図の図

機能レベルのアクセス制御がありません

機能レベルのアクセス制御が欠落していることは、安全でない直接オブジェクト参照と非常によく似ています。 この場合、ユーザーはURLまたはその他のパラメーターを変更して、アプリケーションの保護された部分にアクセスしようとします。 アクセスのレベルを調べる適切なアクセス制御がない場合、ユーザーはアプリケーションリソースへの特権アクセス、または少なくともその存在に関するある程度の知識を得ることができます。

直接オブジェクト参照の例から借用すると、スーパーユーザーが追加の承認を行わなくても削除フォームへのリンクを表示できるという理由だけで、削除フォームにアクセスするユーザーがスーパーユーザーであるとアプリケーションが想定した場合、大きなセキュリティ上の欠陥が発生します。 一部のUI要素の可用性を期待することは、適切なアクセス制御ではありません。

この問題は、アプリケーションのすべてのレイヤーで常にチェックを実行することで解決されます。 フロントエンドインターフェースは、悪意のあるユーザーがドメインレイヤーにアクセスできる唯一の方法ではない可能性があります。 また、ユーザーから渡されたアクセスレベルに関する情報に依存しないでください。 適切なセッション制御を実行し、受信したデータを常に再確認してください。 リクエストの本文にユーザーが管理者であると記載されているからといって、実際には管理者であるとは限りません。

壊れたアクセス制御は、ファイルシステムの設定ミスなど、アプリケーションレベルでもシステムレベルでも、不十分なアクセス制御に関連するすべての問題を組み合わせるようになりました。

壊れたアクセス制御の図

OWASPトップ10リストの新しい問題

新しいフロントエンドフレームワークの出現と新しいソフトウェア開発手法の採用により、セキュリティ上の懸念は完全に新しいトピックに移りました。 新しいテクノロジーは、以前は手動で扱っていたいくつかの一般的な問題も解決することができました。 したがって、リストを改訂し、現代の傾向に合わせて調整することが有益になりました。

XML外部エンティティ

XML標準は、ドキュメントのデータ型定義（DTD）の一部である外部エンティティと呼ばれるあまり知られていないアイデアを提供します。 これにより、ドキュメントの作成者は外部エンティティへのリンクを指定でき、それを参照してメインドキュメントに含めることができます。 非常に簡単な例は次のとおりです。

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

解析中、参照&bar; 定義されたエンティティのコンテンツに置き換えられるため、 <foo>baz</foo>が生成されます。

アプリケーションが外部入力を受け取り、それをチェックせずにXMLドキュメント定義に直接含めると、さまざまなデータ漏洩や攻撃が発生する可能性があります。

魔法のようなことは、エンティティが単純な文字列である必要はなく、ファイルシステム上のファイルへの参照である可能性があることです。 XMLパーサーは、指定されたファイルの内容を取得し、生成された応答に含めて、機密性の高いシステム情報を明らかにする可能性があります。 OWASPで示されているように、エンティティを次のように定義することで、システムのユーザーに関する情報を取得するのは非常に簡単です。

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

この脆弱性の特に厄介な「機能」は、サービス拒否攻撃を簡単に実行できる可能性です。 これを行う簡単な方法の1つは、 /dev/randomのような無限のファイルの内容を一覧表示することです。 もう1つは、エンティティのシーケンスを作成することです。各エンティティは、前のエンティティを何度も参照します。 これにより、最終的な参照が、解析によってシステムメモリを使い果たす可能性のある非常に広く深いツリーのルートになります。 この攻撃は、BillionLaughsとしても知られています。 ウィキペディアに示されているように、一連のダミーエンティティが定義されており、攻撃者が最終的なドキュメントに10億の笑いを含める機会を生み出しています。

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

XML外部エンティティの悪用を防ぐには、それほど複雑でないデータ形式を使用します。 JSONに対する攻撃の可能性があるため、何らかの予防策も講じられている場合は、JSONが適切な代替手段です。 XMLライブラリの更新は、外部エンティティ処理とDTDの無効化と組み合わせて必須です。 いつものように、信頼できないソースからのデータを使用したり、ドキュメントに含めたりする前に、データを検証してサニタイズします。

安全でないデシリアライズ

コードを書くとき、開発者は自分が書いたコードを使用して開発しているシステムを制御する力を持っています。 コードを少しだけ、またはまったく記述しないサードパーティシステムの動作を制御することはどれほど素晴らしいことでしょうか？ 人々が完璧ではなく、図書館に欠陥があるという事実のおかげで、これは間違いなく可能です。

多くの場合、アプリケーションの状態と構成はシリアル化されて保存されます。 シリアル化されたデータが現在のユーザーと緊密に結合されている場合、ブラウザーがストレージエンジンとして機能することがあります。 巧妙で処理時間を節約しようとするアプリケーションは、Cookieを使用して、ユーザーがサインインしたことをマークできます。Cookieは、サインインが成功した後にのみ作成できるため、ユーザー名をCookieに保存することは理にかなっています。 次に、Cookieの存在と内容に基づいて、ユーザーが認証および承認されます。 人々が悪意を持っていなければ、何も悪いことはありません。 正直なところ、彼らも好奇心を持ってはいけません。

好奇心旺盛なユーザーが自分のマシンでCookieを見つけた場合、次のようなものが表示される可能性があります。

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

JSONにシリアル化された完全に有効なPython辞書で、特別なことは何もありません。 好奇心旺盛なユーザーは、アプリケーションがサインアウトを強制しないように有効期限を変更する場合があります。 さらに好奇心旺盛なユーザーは、ユーザー名を"jane.doe"に変更しようとする可能性があります。 このユーザー名が存在する場合、個人データにアクセスできる疑いを持たないユーザーにまったく新しい世界が開かれます。

データをJSONにシリアル化し、すべてを透過的に保つという簡単な例は、起こりうる最悪の事態とはほど遠いものです。 攻撃者がシリアル化されたデータを変更しようとすると、システムに任意のコードを実行させるような方法でデータを変更できる可能性があります。

Pythonで独自の機械学習モデルを作成してサービスにアップロードできるRESTAPIを構築しているとします。 このサービスは、アップロードされたモデルを評価し、データセットを使用してそれらをトレーニングします。 これにより、人々はコンピューティングリソースと利用可能な大量のデータセットを使用して、すばやく簡単にモデルを構築できます。

このサービスは、コードをプレーンテキスト形式で保存しません。 ユーザーはコードをピクルスにし、秘密鍵を使用して暗号化し、トレーニングのためにAPIに送信します。 サービスがモデルを実行する必要がある場合、サービスはコードを復号化し、ピックルを解除して実行します。 トリッキーな部分は、ピクルスプロトコルが安全ではないということです。 コードは、逆シリアル化中に任意の悪意のあるコードを実行できるように構築できます。

Pythonのpickleプロトコルを使用すると、クラスでメソッド__reduce__を定義できます。このメソッドは、カスタムオブジェクトを逆シリアル化する方法に関する情報を返します。 サポートされている戻り値の1つは、2つの引数のタプルです。呼び出し可能オブジェクトと呼び出し可能オブジェクトに渡される引数のタプルです。 MLモデルトレーニングシステムがコード構造の最大限の柔軟性を提供することを目的としていることを考慮すると、次のコードを記述できます。

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

オブジェクトを逆シリアル化（選択解除）する必要があると、1つの引数だけで関数listが呼び出されます。 関数listはPythonのリストコンストラクターであり、関数itertools.countは、渡されたパラメーターから始まる値の無限のイテレーターを生成します。 無限イテレータを有限リストに変えると、システムのパフォーマンスと安定性に壊滅的な結果をもたらす可能性があります。

このタイプの脆弱性の唯一の本当の治療法は、外部ソースからのデータを逆シリアル化しないことを選択することです。 これが不可能な場合は、悪意のあるユーザーによって変更された可能性のあるデータの逆シリアル化を防ぐために、チェックサムまたはデジタル署名を使用することをお勧めします。 また、発生する可能性のある問題の影響を制限するために、メインシステムから切り離されたサンドボックス環境をセットアップしてみてください。

XMLやJSONなどからデータを逆シリアル化するために外部ライブラリを使用する場合は、実際の逆シリアル化手順が実行される前に、オブジェクトタイプチェックを実行できるライブラリを選択してください。 これにより、システムに損害を与えることを唯一の目的とする予期しないオブジェクトタイプが検出される可能性があります。

アプリケーションが実行する他のすべてのアクションと同様に、広範なロギングとモニタリングを実施します。 逆シリアル化が頻繁に発生するか、通常よりも失敗することは、何か悪いことが起こっていることを示しています。 早期に問題をキャッチします。

不十分なロギングとモニタリング

アプリケーションで発生するすべての警告とエラーを確実にログに記録するためにどのくらいの時間を費やしますか？ コードで発生したエラーのみを保存しますか、それとも検証エラーもログに記録しますか？ ドメインのビジネスルールが満たされない場合はどうなりますか？ アプリケーションで誤った疑わしいアクティビティをすべて永続化しないと、セキュリティとデータの侵害が発生します。

次のシナリオを想像してみてください。 ほとんどの場合と同様に、アプリケーションにはサインインページが含まれています。 フォームには2つのフィールドがあります。1つは電子メールの入力用で、もう1つはパスワード用です。 ユーザーがサインインしようとして、間違ったパスワードを入力した場合は、再試行できます。 残念ながら、誤った試行の数は制限されていないため、N回失敗してもサインインページはロックされません。 攻撃者はこの機会を利用して、1つの正しい電子メールが与えられると、1つの組み合わせが最終的に成功するまで、レインボーテーブルからパスワードを入力し続けることができます。 アプリケーションが十分に安全であり、データベースに入力する前にパスワードをハッシュする場合、この特定の攻撃は機能しません。 ただし、侵入を識別するためのメカニズムはありますか？

この1回の試みでサインインページを開くことができなかったからといって、他の人がそうしないという意味ではありません。 サインインページは、おそらくあなたが持っている唯一の潜在的なバックドアではありません。 他の目的ではない場合、誰かがあなたに対して壊れたアクセス制御を使用しようとする可能性があります。 完全に作成されたアプリケーションでさえ、それが不可能な場合でも、誰かがそれらを攻撃しようとしていることを知っている必要があります。 しかし、それは常にそれです。

このような攻撃から身を守るために最善を尽くすには、次の手順を実行します。

  • コードでスローされた例外、アクセス制御、検証、データ操作のエラーなど、アプリケーションで発生したすべての障害と警告をログに記録します。 保存されたすべての情報は、遡及的な検査と分析が可能になるように、複製して十分に長く保持する必要があります。
  • フォーマットと永続性レイヤーを決定することは重要です。 任意のテキスト形式の巨大なファイルを作成するのは簡単です。 後で処理することはできません。 データの保存と読み取りを容易にするストレージオプションと、簡単かつ高速な（逆）シリアル化を可能にするフォーマットを選択してください。 迅速なアクセスを可能にするデータベースにJSONを保存すると、使用が簡単になります。 定期的にバックアップして、データベースを小さくしてください。
  • 重要で価値のあるデータを扱っている場合は、最終的な状態を監査するために従うことができるアクションの証跡を保管してください。 データの改ざんを防ぐためのメカニズムを実装します。
  • バックグラウンドシステムにログを分析させ、何かが発生した場合に警告します。 チェック（ユーザーがアプリケーションの保護された部分に繰り返しアクセスしようとするかどうかをテストするのと同じくらい簡単です）が役立ちます。 ただし、ダミーチェックでシステムを過負荷にしないでください。 監視システムは個別のサービスとして実行する必要があり、メインシステムのパフォーマンスに影響を与えてはなりません。

問題を解決するときは、エラーログを外部ユーザーに漏らさないように特に注意してください。 そうしないと、機密情報にさらされやすくなります。 ロギングとモニタリングは、攻撃者がより効率的に仕事をするのではなく、問題の解決に役立つはずです。

ロギングとモニタリングの図

次のステップ

Webアプリケーションの潜在的な脅威と脆弱性を認識することは重要です。 アプリケーションでそれらを識別し始め、パッチを適用してそれらを削除することがさらに重要です。

アプリケーションのセキュリティへの注意は、ソフトウェア開発プロジェクトのすべてのステップの重要な部分です。 ソフトウェアアーキテクト、開発者、およびテスターはすべて、ワークフローにソフトウェアテスト手順を組み込む必要があります。 セキュリティチェックリストと自動テストをソフトウェア開発プロセスの適切なステップに利用して、セキュリティリスクを軽減することは有益です。

既存のアプリケーションを分析する場合でも、新しいアプリケーションを開発する場合でも、OWASPアプリケーションセキュリティ検証標準プロジェクト（ASVS）を調べる必要があります。 このプロジェクトの目標は、アプリケーションのセキュリティ検証の標準を開発することです。 この規格は、安全なWebアプリケーションを開発するためのテストと要件を列挙しています。 テストには1から3までのレベルが割り当てられます。1つは危険の量が最も少ないことを意味し、3つは潜在的な脅威が最も高いことを意味します。 この分類により、アプリケーションマネージャは、どの脅威がより可能性が高く、重要であるかを判断できます。 各アプリケーションに各テストを含める必要はありません。

新規および既存のWebアプリケーションプロジェクトの両方、特にアジャイルの原則に従っているプロジェクトは、アプリケーションを保護するための取り組みの構造化された計画から恩恵を受けます。 OWASP Security Knowledge Frameworkを使用する場合は、OWASPASVSテストの計画が簡単になります。 これは、セキュリティテスト指向のスプリントを管理するためのアプリケーションであり、一般的なセキュリティ問題を解決する方法に関する一連の例と、OWASPASVSに基づくわかりやすいチェックリストが付属しています。

Webアプリケーションのセキュリティの調査を開始したばかりで、安全なサンドボックスプレイグラウンドが必要な場合は、OWASPのWebアプリケーション実装であるWebGoatを使用してください。 これは、意図的に安全でないWebアプリケーションの実装です。 アプリケーションはレッスンをガイドし、各レッスンは1つのセキュリティ脅威に集中します。

アプリケーション開発中は、次のことを確認してください。

  • 脅威を特定して優先順位を付けます。 どの脅威が現実的に発生し、アプリケーションにリスクをもたらす可能性があるかを定義します。 脅威に優先順位を付け、開発とテストの作業に最も値する脅威を決定します。 静的なブログを提供している場合、不十分なログ記録と監視を解決するために多くの努力を払うことにはあまり意味がありません。
  • アプリケーションのアーキテクチャと設計を評価します。 一部の脆弱性は、アプリケーション開発の後の段階で解決するのが非常に困難です。 たとえば、サードパーティのコードを実行する予定があり、サンドボックス環境を使用する予定がない場合、安全でない逆シリアル化やインジェクション攻撃から防御することは非常に困難です。
  • ソフトウェア開発プロセスを更新します。 Webアプリケーションの脅威に対するテストは、可能な限り自動化されたプロセスである必要があります。 セキュリティホールを見つけようとする自動テストでCI/CDワークフローを強化することは有益です。 既存の単体テストシステムを利用して、セキュリティテストを開発し、定期的に実行することもできます。
  • 学び、改善する。 問題と脆弱性のリストは静的ではなく、10または15の脅威に限定されません。 新しい機能とアイデアは、新しいタイプの攻撃への扉を開きます。 最新の状態を維持するには、Webアプリケーションセキュリティの世界における現在の傾向について読むことが重要です。 学んだことを適用します。 そうでなければ、あなたはあなたの時間を無駄にしています。

結論

名前が示すように、OWASPトップテンプロジェクトには10​​のセキュリティ脆弱性しかリストされていませんが、アプリケーション、そして最も重要なことに、ユーザーとそのデータを脅かす可能性のあるトラップとバックドアが何千もあります。 テクノロジーの変化と改善には長所と短所の両方があるため、常に注意を払い、知識を常に更新してください。

ああ、そして、忘れないでください、世界は白黒ではありません。 セキュリティの脆弱性は単独では発生しません。 彼らはしばしば絡み合っています。 多くの場合、1つにさらされるということは、他の多くの人が角を曲がったところにいて、醜い頭を後ろに向けるのを待っていることを意味します。システムセキュリティ開発者として、システムセキュリティ開発者として、抜け穴にパッチを当てて抑制する必要があります。サイバー犯罪。 例については、ハッキングされたクレジットカード番号はまだGoogle対応ですを参照してください。