Web8: XSS エクスプロイト - パート 2: 保存された XSS

前回の記事では、XSS (クロス サイト スクリプティング) エラーと XSS Reflected の実際の悪用について学びました。 XSS には、より危険であると考えられるもう 1 つのタイプがあります。Stored XSS です。

ハッカーがターゲットにした少数の被害者を直接攻撃する Reflected とは異なり、Stored XSS はより多くの被害者をターゲットにします。このエラーは、Web アプリケーションがデータベースに保存する前に入力データを徹底的にチェックしない場合に発生します (ここでは、この概念をデータベース、ファイル、またはアプリケーション データを保存するその他の領域を指すために使用します。Web)。

Stored XSS 技術を使用すると、ハッカーは直接悪用することはありませんが、少なくとも 2 つのステップで悪用する必要があります。

まず、ハッカーはフィルタリングされていない入力ポイント (フォーム、入力、テキスト領域など) を使用して、危険なコードをデータベースに挿入します。

次に、ユーザーが Web アプリケーションにアクセスし、この保存されたデータに関連する操作を実行すると、ユーザーのブラウザ上でハッカーのコードが実行されます。

この時点で、ハッカーは目的を達成したように見えます。このため、Stored XSS 技術は 2 次 XSS とも呼ばれます。

悪用シナリオは次のように説明されています。

リフレクト XSS とストアド XSS には、攻撃プロセスにおいて 2 つの大きな違いがあります。

• まず、Reflected XSS を悪用するには、ハッカーは被害者を騙して URL にアクセスさせる必要があります。 Stored XSS に関しては、これを行う必要はなく、危険なコードをアプリケーションのデータベースに挿入した後、ハッカーは被害者が自動的にアクセスするのを待つだけで済みます。被害者にとって、アクセスしたデータが感染していることを知らないため、これはまったく正常のことです。
• 第 2 に、攻撃時に被害者がまだ Web アプリケーションのセッションにいた場合、ハッカーの目的は達成されやすくなります。 Reflected XSS を使用すると、ハッカーは被害者を説得または騙して、被害者が提供した URL にログインしてアクセスさせ、悪意のあるコードを実行することができます。ただし、Stored XSS は異なります。悪意のあるコードが Web データベースに保存されているため、ユーザーが関連機能にアクセスするたびに悪意のあるコードが実行され、おそらくこれらの機能には認証が必要です。最初にログインするため、その間は明らかに認証が必要です。ユーザーはまだセッションに参加しています。

これらのことから、Stored XSS は Reflected XSS よりもはるかに危険であることがわかります。影響を受ける対象は、その Web アプリケーションのすべてのユーザーである可能性があります。また、被害者が管理者の役割を持っている場合は、Web ハイジャックのリスクもあります。