🥇Web サイトのセキュリティの大罪: 年間の脆弱性スキャナーの統計から学んだこと |プロホスター

約 XNUMX 年前、私たち DataLine はサービス IT アプリケーションの脆弱性を検索および分析します。このサービスはQualysクラウドソリューションをベースにしており、その動作についてはすでに言った。このソリューションの 291 年間の取り組みを通じて、さまざまなサイトに対して XNUMX 件のスキャンを実施し、Web アプリケーションの一般的な脆弱性に関する統計を蓄積しました。

以下の記事では、さまざまなレベルの重要度の背後に Web サイトのセキュリティのどのような穴が隠されているかを正確に説明します。スキャナーによって特に頻繁に検出された脆弱性、その脆弱性が発生する理由、および身を守る方法を見てみましょう。

Qualys では、すべての Web アプリケーションの脆弱性を、低、中、高の XNUMX つの重大度レベルに分類しています。「深刻度」別に分布を見ると、すべてがそれほど悪くはないようです。重大度の高い脆弱性はほとんどなく、ほとんどすべてが非重大です。

しかし、批判的でないということは無害という意味ではありません。重大な損害を引き起こす可能性もあります。

上位の「重大ではない」脆弱性

混合コンテンツの脆弱性。
Web サイトのセキュリティの標準は、暗号化をサポートし、情報の傍受から保護する HTTPS プロトコルを介したクライアントとサーバー間のデータ転送です。

一部のサイトでは、 混合コンテンツ: 一部のデータは、安全でない HTTP プロトコルを介して転送されます。こうやって伝わることが多いです 受動的コンテンツ – サイトの表示のみに影響する情報: 画像、CSS スタイル。でもこうやって伝わることもある アクティブコンテンツ: サイトの動作を制御するスクリプト。この場合、特別なソフトウェアを使用すると、サーバーから送信されるアクティブなコンテンツを含む情報を分析し、その場で応答を変更し、作成者が意図していない方法でマシンを動作させることができます。

新しいバージョンのブラウザでは、コンテンツが混在するサイトは安全でなく、コンテンツがブロックされるとユーザーに警告します。 Web サイト開発者は、コンソールでブラウザーの警告も受け取ります。たとえば、次のようになります Firefoxの:

なぜ危険なのでしょうか?：攻撃者は、安全でないプロトコルを使用してユーザー情報を傍受し、スクリプトを置き換え、ユーザーに代わってサイトにリクエストを送信します。サイト訪問者がデータを入力しなかったとしても、これは彼を保護するものではありません。 フィッシング – 不正な方法を使用して機密情報を取得すること。たとえば、スクリプトを使用すると、ユーザーがよく知っているサイトを装った安全でないサイトにユーザーをリダイレクトできます。場合によっては、悪意のあるサイトは元のサイトよりも見栄えがよくなり、ユーザーが自分でフォームに記入して機密データを送信することができます。

Web開発者が覚えておくべきこと: サイト管理者が SSL/TLS 証明書をインストールして設定した場合でも、人的ミスにより脆弱性が発生する可能性があります。たとえば、ページの XNUMX つに相対リンクではなく http からの絶対リンクを配置し、さらに http から https へのリダイレクトを設定しなかったとします。

ブラウザを使用してサイト上の混合コンテンツを検出できます。ページのソースコードを検索し、開発者コンソールで通知を読みます。ただし、開発者は長時間にわたってコードをいじる必要があります。次のような自動分析ツールを使用してプロセスを高速化できます。 SSLをチェック、無料の Lighthouse ソフトウェアまたは有料ソフトウェア Screaming Frog SEO Spider。

また、この脆弱性は、レガシーコード (継承されたコード) の問題によって発生する可能性があります。たとえば、サイトの https への移行が考慮されていない古いテンプレートを使用して一部のページが生成されているとします。
「HTTPOnly」および「secure」フラグのない Cookie。
「HTTPOnly」属性は、攻撃者がユーザーデータを盗むために使用するスクリプトによって Cookie が処理されるのを防ぎます。「セキュア」フラグでは、Cookie をクリアテキストで送信することはできません。通信は、Cookie の送信に安全な HTTPS プロトコルが使用される場合にのみ許可されます。

両方の属性は Cookie プロパティで指定されます。
```
Set-Cookie: Secure; HttpOnly
```
なぜ危険なのでしょうか?注：サイト開発者がこれらの属性を指定しなかった場合、攻撃者が Cookie からユーザーの情報を傍受し、悪用する可能性があります。認証と認可に Cookie が使用されている場合、ユーザーのセッションをハイジャックして、ユーザーに代わってサイト上でアクションを実行できるようになります。

Web開発者が覚えておくべきこと: 一般に、一般的なフレームワークでは、これらの属性は自動的に設定されます。ただし、Web サーバーの構成を確認し、フラグ Set-Cookie HttpOnly; を設定します。安全な。

この場合、「HTTPOnly」属性により、Cookie が独自の JavaScript から見えなくなります。
パスベースの脆弱性。
スキャナーは、機密情報の可能性がある公的にアクセス可能なファイルまたは Web サイトのディレクトリを検出した場合、そのような脆弱性を報告します。たとえば、個々のシステム構成ファイルやファイルシステム全体へのアクセスを検出します。この状況は、サイトでアクセス権が正しく設定されていない場合に発生する可能性があります。

なぜ危険なのでしょうか?: ファイルシステムが「はみ出している」場合、攻撃者はオペレーティングシステムインターフェイスに侵入し、パスワードがクリアテキストで保存されている場合は、パスワードを持つフォルダーを見つけようとする可能性があります (絶対に行わないでください)。あるいは、パスワードハッシュを盗んでパスワードを総当たり攻撃し、システム内の権限を上げてインフラストラクチャの奥深くに侵入しようとすることもできます。

Web開発者が覚えておくべきこと: アクセス権を忘れずに、Web ディレクトリから「エスケープ」できないようにプラットフォーム、Web サーバー、Web アプリケーションを構成してください。
自動入力が有効になっている機密データを入力するためのフォーム。
ユーザーが Web サイト上のフォームに頻繁に入力する場合、ブラウザは自動入力機能を使用してこの情報を保存します。

Web サイト上のフォームには、パスワードやクレジットカード番号などの機密情報を含むフィールドが含まれる場合があります。このようなフィールドについては、サイト自体でフォームの自動入力機能を無効にする価値があります。

なぜ危険なのでしょうか?: ユーザーのブラウザに機密情報が保存されている場合、後で攻撃者がフィッシングなどを通じてその情報を傍受する可能性があります。本質的には、このニュアンスを忘れた Web 開発者がユーザーをセットアップしていることになります。

Web開発者が覚えておくべきこと: この場合、利便性とセキュリティという古典的な対立が生じます。 Web 開発者がユーザーエクスペリエンスについて考えている場合は、意識的にオートコンプリートを選択できます。たとえば、次のことが重要である場合、 Webコンテンツのアクセシビリティガイドライン – 障害のあるユーザーに対するコンテンツのアクセシビリティに関する推奨事項。

ほとんどのブラウザでは、autocompete="off" 属性を使用してオートコンプリートを無効にできます。次に例を示します。
```
 <body>
    <form action="/ja/form/submit" method="get" autocomplete="off">
      <div>
        <input type="text" placeholder="First Name">
      </div>
      <div>
        <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
      </div>
      <div>
        <input type="number" placeholder="Credit card number">
      </div>
      <input type="submit">
    </form>
  </body>
```
ただし、Chrome では機能しません。これは JavaScript を使用して回避され、レシピのバリアントが見つかります。ここで.
X-Frame-Options ヘッダーはサイトコードに設定されていません。
このヘッダーは、frame、iframe、embed、または object タグに影響します。これを利用すると、サイトをフレーム内に埋め込むことを完全に禁止できます。これを行うには、値 X-Frame-Options:deny を指定する必要があります。または、X-Frame-Options: Sameorigin を指定すると、iframe への埋め込みがドメインでのみ利用可能になります。

なぜ危険なのでしょうか?: このようなヘッダーがないことを悪意のあるサイトで利用して、 クリックジャッキング。この攻撃では、攻撃者はボタンの上に透明なフレームを作成し、ユーザーを騙します。たとえば、詐欺師は Web サイト上にソーシャルネットワーキングページをフレーム化します。ユーザーは、このサイト上のボタンをクリックしていると考えています。代わりに、クリックはインターセプトされ、ユーザーのリクエストはアクティブなセッションが存在するソーシャルネットワークに送信されます。これは、攻撃者がユーザーに代わってスパムを送信したり、購読者や「いいね！」を獲得したりする方法です。

この機能を無効にしないと、攻撃者が悪意のあるサイトにアプリケーションボタンを配置する可能性があります。彼はあなたの紹介プログラムやユーザーに興味があるかもしれません。

Web開発者が覚えておくべきこと注：Web サーバーまたはロードバランサ上で、競合する値の X-Frame-Options が設定されている場合、この脆弱性が発生する可能性があります。この場合、サーバーとバランサーはバックエンドコードに比べて優先度が高いため、ヘッダーを書き換えるだけです。

X-Frame-Optionsヘッダーのdeny値とsameorigin値は、Yandex Webビューアの動作を妨げます。 Web ビューアで iframe の使用を許可するには、設定に別のルールを記述する必要があります。たとえば、nginx の場合は次のように設定できます。
```
http{
...
 map $http_referer $frame_options {
 "~webvisor.com" "ALLOW-FROM http://webvisor.com";
 default "SAMEORIGIN";
 }
 add_header X-Frame-Options $frame_options;
...
}
```
PRSSI (パス相対スタイルシートインポート) の脆弱性。
これはサイトのスタイルの脆弱性です。この問題は、href="/ja/somefolder/styles.css/" のような相対リンクを使用してスタイルファイルにアクセスする場合に発生します。攻撃者は、ユーザーを悪意のあるページにリダイレクトする方法を見つけた場合、これを利用します。ページは URL に相対リンクを挿入し、スタイル呼び出しをシミュレートします。 badsite.ru/…/somefolder/styles.css/ のようなリクエストを受け取ります。これは、スタイルを装って悪意のあるアクションを実行する可能性があります。

なぜ危険なのでしょうか?: 詐欺師が別のセキュリティホールを見つけた場合、この脆弱性を悪用する可能性があります。その結果、Cookie やトークンからユーザーデータを盗むことが可能になります。

Web開発者が覚えておくべきこと: X-Content-Type-Options ヘッダーを nosniff に設定します。この場合、ブラウザはスタイルのコンテンツタイプをチェックします。タイプが text/css 以外の場合、ブラウザはリクエストをブロックします。

重大な脆弱性

パスワードフィールドを含むページは、安全でないチャネルを介してサーバーから送信されます (パスワードフィールドを含む HTML フォームは HTTP 経由で提供されます)。
暗号化されていないチャネルを介したサーバーからの応答は、「中間者」攻撃に対して脆弱です。攻撃者はトラフィックを傍受し、ページがサーバーからクライアントに移動する際にクライアントとサーバーの間に割り込む可能性があります。

なぜ危険なのでしょうか?: 詐欺師はページを置き換えて機密データのフォームをユーザーに送信し、そのフォームが攻撃者のサーバーに送信されるようになります。

Web開発者が覚えておくべきこと：一部のサイトでは、パスワードの代わりに電子メールまたは電話でワンタイムコードをユーザーに送信します。この場合、脆弱性はそれほど重大ではありませんが、そのメカニズムはユーザーの生活を複雑にするでしょう。
ログインとパスワードを含むフォームを安全でないチャネル経由で送信する (ログインフォームは HTTPS 経由で送信されない)。
この場合、ログインとパスワードを含むフォームが、暗号化されていないチャネルを介してユーザーからサーバーに送信されます。

なぜ危険なのでしょうか?: 前のケースとは異なり、これはすでに重大な脆弱性です。コードを記述する必要がないため、機密データを傍受するのが簡単になります。
既知の脆弱性のある JavaScript ライブラリを使用している。
スキャン中に最も使用されたライブラリは、多数のバージョンがある jQuery でした。各バージョンには少なくとも XNUMX つ、またはそれ以上の既知の脆弱性があります。影響は脆弱性の性質に応じて大きく異なる可能性があります。

なぜ危険なのでしょうか?: 既知の脆弱性を悪用する方法があります。たとえば、次のとおりです。

Web開発者が覚えておくべきこと: 既知の脆弱性の検索 - 修正 - チェックのサイクルに定期的に戻ります。たとえば、古いブラウザをサポートしたりコストを節約したりするために、レガシーライブラリを意図的に使用する場合は、既知の脆弱性を修正する機会を探してください。
クロスサイトスクリプティング (XSS)。
クロスサイトスクリプティング (XSS) またはクロスサイトスクリプティングは、Web アプリケーションに対する攻撃であり、データベースにマルウェアが導入されます。 Qualys がそのような脆弱性を発見した場合、潜在的な攻撃者が独自の js スクリプトをサイトコードに導入して悪意のあるアクションを実行できるか、すでに導入していることを意味します。

保存された XSS スクリプトはサーバーに埋め込まれており、攻撃されたページがブラウザで開かれるたびに実行されるため、より危険です。

反射型 XSS 悪意のあるスクリプトを HTTP リクエストに挿入できるため、実行が容易になります。アプリケーションは HTTP リクエストを受け取り、データを検証せず、パッケージ化してすぐに送信します。攻撃者がトラフィックを傍受し、次のようなスクリプトを挿入した場合
```
<script>/*+что+то+плохое+*/</script> 
```
その後、クライアントに代わって悪意のあるリクエストが送信されます。

XSS の顕著な例: CVC やカードの有効期限などを入力するページをシミュレートする js スニファー。

Web開発者が覚えておくべきこと: Content-Security-Policy ヘッダーで script-src 属性を使用して、クライアントブラウザーが信頼できるソースからのみコードをダウンロードして実行するように強制します。たとえば、script-src 'self' は、当社のサイトからのすべてのスクリプトのみをホワイトリストに登録します。
ベストプラクティスはインラインコードです。unsafe-inline 値を使用したインライン JavaScript のみを許可します。この値により、インライン js/css の使用が許可されますが、js ファイルを含めることは禁止されません。 script-src 'self' と組み合わせて、外部スクリプトの実行を無効にします。

report-uri を使用してすべてを記録し、それをサイトに実装しようとする試みを確認してください。
SQLインジェクション。
この脆弱性は、Web サイトのデータベースに直接アクセスする SQL コードを Web サイトに挿入する可能性を示しています。ユーザーからのデータがスクリーニングされていない場合、SQL インジェクションが発生する可能性があります。データは正確性がチェックされず、すぐにクエリで使用されます。たとえば、Web サイト上のフォームが入力がデータ型と一致するかどうかをチェックしない場合に、これが発生します。

なぜ危険なのでしょうか?: 攻撃者がこのフォームに SQL クエリを入力すると、データベースがクラッシュしたり、機密情報が漏洩したりする可能性があります。

Web開発者が覚えておくべきこと: ブラウザから来るものを信用しないでください。クライアント側とサーバー側の両方で自分自身を保護する必要があります。

クライアント側では、JavaScript を使用してフィールド検証を記述します。

一般的なフレームワークの組み込み関数も、サーバー上の疑わしい文字をエスケープするのに役立ちます。サーバー上でパラメータ化されたデータベースクエリを使用することもお勧めします。

データベースとの対話が Web アプリケーションのどこで正確に行われるかを決定します。

インタラクションは、ID を伴うリクエスト (ID の変更)、新しいユーザーの作成、新しいコメント、データベース内の新しいエントリなど、何らかの情報を受け取るときに発生します。ここで SQL インジェクションが発生する可能性があります。データベースからレコードを削除してもSQLインジェクションは可能です。

一般的な推奨事項

車輪の再発明ではなく、実績のあるフレームワークを使用してください。一般に、人気のあるフレームワークはより安全です。 .NET の場合 - ASP.NET MVC および ASP.NET Core、Python の場合 - Django または Flask、Ruby の場合 - Ruby on Rails、PHP の場合 - Symfony、Laravel、Yii、JavaScript の場合 - Node.JS-Express.js、Java の場合- 春のMVC。

ベンダーの更新情報を追跡し、定期的に更新してください。彼らは脆弱性を見つけてエクスプロイトを作成し、それを公開すると、すべてが再び起こります。ソフトウェアベンダーから安定バージョンへのアップデートを購読します。

アクセス権を確認する。サーバー側では、コードが最初の文字から最後の文字まで、サイトを破壊し、データの整合性を侵害しようとする最も憎むべき敵によって書かれたものであるかのように、常にコードを扱ってください。さらに、これが真実である場合もあります。

クローンを使用してサイトをテストし、本番環境に使用する。これは、第一に、生産的な環境での間違いや間違いを避けるのに役立ちます。生産的な環境はお金をもたらします。シンプルな生産的な環境は重要です。問題を追加、修正、または解決する場合は、テスト環境で作業し、見つかった機能と脆弱性を確認してから、実稼働環境での作業を計画する価値があります。

Web アプリケーションを保護するには Webアプリケーションファイアウォール脆弱性スキャナーからのレポートを統合します。たとえば、DataLine は Qualys と FortiWeb をサービスのバンドルとして使用します。

出所： habr.com

Web サイトのセキュリティの大罪: 年間の脆弱性スキャナーの統計から学んだこと

上位の「重大ではない」脆弱性

重大な脆弱性

一般的な推奨事項

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル