ハッカーがSQLインジェクションとDDoSを使ってWebサイトを奪う方法

AnonymousとLulzSecのハッカーグループのイベントをゆるく追跡しただけでも、悪名高いSonyハックのように、ハッキングされているWebサイトやサービスについておそらく聞いたことがあるでしょう。あなたは今まで彼らがそれをどのようにしているのか疑問に思いましたか?

これらのグループが使用する多くのツールとテクニックがあります、そして、我々があなた自身これをするためにあなたにマニュアルを与えることを試みていない間、何が起こっているのか理解することは役に立ちます。あなたが一貫して使っている攻撃についての2つの攻撃は、「（分散型）サービス拒否」（DDoS）と「SQLインジェクション」（SQLI）です。これが彼らのしくみです.

による画像 xkcd

DoS攻撃

それは何ですか?

「サービス拒否」（「分散サービス拒否」またはDDoSとも呼ばれる）攻撃は、システム（この場合はWebサーバー）が一度に非常に多くの要求を受信し、サーバーリソースが過負荷になるとシステムがロックアップすると発生します。そしてシャットダウンします。 DDoS攻撃が成功した目標と結果は、ターゲットサーバー上のWebサイトが正当なトラフィック要求に利用できないことです。.

どのように動作しますか?

DDoS攻撃のロジスティクスは例によって最もよく説明されるかもしれません.

何百万人もの人々（攻撃者）が、コールセンターを倒してX社の事業を妨げるという目標を達成していると想像してください。攻撃者は、火曜日の午前9時に彼ら全員がX社の電話番号に電話をかけるように調整します。ほとんどの場合、X社の電話システムでは一度に100万件の通話を処理できないため、すべての着信回線が攻撃者によって縛られることになります。その結果、正当な顧客の電話（すなわち攻撃者ではない電話）は、電話システムが攻撃者からの電話を処理するために拘束されているので通過しない。したがって、本質的には、正当な要求が通過できないためにX社が事業を失う可能性があります。.

Webサーバーに対するDDoS攻撃はまったく同じように機能します。 Webサーバーが要求を処理するまで、正当な要求と攻撃者のどちらからのトラフィックであるかを知る方法は事実上ないため、この種の攻撃は通常非常に効果的です。.

攻撃を実行する

DDoS攻撃は「総当たり」の性質を持っているため、同時に多数のコンピュータが攻撃を調整する必要があります。我々のコールセンターの例を再考すると、これは全ての攻撃者が午前9時に電話することとその時に実際に電話することの両方を知ることを要求するでしょう。この原則はWebサーバーの攻撃に関しては確実に機能しますが、実際の有人コンピュータではなくゾンビコンピュータを利用すると、はるかに簡単になります。.

ご存じかもしれませんが、マルウェアやトロイの木馬にはさまざまな種類の亜種がありますが、いったんあなたのシステムに侵入すると、命令のために休眠状態になり、時には「電話の家」になります。これらの指示の1つは、たとえば、午前9時に企業XのWebサーバーに繰り返し要求を送信することです。そのため、それぞれのマルウェアのホームロケーションを1回更新するだけで、1人の攻撃者が何十万もの感染したコンピュータを即座に調整して、大規模なDDoS攻撃を実行することができます。.

ゾンビコンピュータを利用することの美しさは、その有効性だけでなく、攻撃者が実際に攻撃を実行するために自分のコンピュータをまったく使用する必要がないため、その匿名性にもあります。.

SQLインジェクション攻撃

それは何ですか?

「SQLインジェクション」（SQLI）攻撃は、貧弱なWeb開発技術を悪用し、通常は不正なデータベースセキュリティと組み合わせて利用されます。攻撃が成功した結果は、ユーザーアカウントのなりすましからそれぞれのデータベースまたはサーバーへの完全な危殆化までさまざまです。 DDoS攻撃とは異なり、Webアプリケーションが適切にプログラムされていれば、SQLI攻撃は完全かつ簡単に防止できます。.

攻撃を実行する

Webサイトにログインしてユーザー名とパスワードを入力するたびに、資格情報をテストするために、Webアプリケーションは次のようなクエリを実行する可能性があります。

UserName = "myuser" AND Password = "mypass";からユーザーを選択します。

注：SQLクエリ内の文字列値は一重引用符で囲む必要があります。これが、ユーザーが入力した値の前後に表示される理由です。.

したがって、UserIDが返されるためには、入力されたユーザー名（myuser）とパスワード（mypass）の組み合わせがUsersテーブルのエントリと一致する必要があります。一致するものがない場合、UserIDは返されないため、ログイン認証情報は無効です。特定の実装は異なるかもしれませんが、メカニズムはかなり標準的です.

それでは、ユーザーがWebフォームに入力した値を代用できるテンプレート認証クエリを見てみましょう。

ユーザー名を "UserName =" [user] "、パスワード=" [pass] "から選択します。

一見したところ、これはユーザーを簡単に検証するための直接的で論理的なステップのように思えるかもしれませんが、このテンプレートでユーザーが入力した値を単純に置き換えると、SQLI攻撃を受けやすくなります。.

たとえば、ユーザー名フィールドに「myuser'-」、パスワードに「wrongpass」と入力したとします。テンプレートクエリで単純な置換を使用すると、次のようになります。

ユーザーからユーザーIDを選択しますWHERE UserName = "myuser" - 'AND Password = "wrongpass"

この声明の鍵は、2つのダッシュを含めることです （ - ）. これはSQLステートメントのコメント開始トークンであるため、2つのダッシュ（両端を含む）の後に表示されるものはすべて無視されます。基本的に、上記のクエリはデータベースによって次のように実行されます。

ユーザーからのSELECTユーザーID WHERE UserName = "myuser"

ここでの明白な省略は、パスワードチェックの欠如です。ユーザーフィールドの一部として2つのダッシュを含めることで、パスワードチェック条件を完全に回避し、それぞれのパスワードを知らなくても「myuser」としてログインすることができました。意図しない結果を生成するためにクエリを操作するこの行為は、SQLインジェクション攻撃です。.

どんなダメージがありますか?

SQLインジェクション攻撃は、過失や無責任なアプリケーションコーディングによって引き起こされ、完全に防止可能です（これについてはすぐに説明します）が、被害の程度はデータベースの設定によって異なります。 Webアプリケーションがバックエンドデータベースと通信するためには、アプリケーションはデータベースへのログインを提供しなければなりません（これはWebサイト自体へのユーザログインとは異なります）。 Webアプリケーションに必要な権限に応じて、このそれぞれのデータベースアカウントには、既存のテーブルの読み取り/書き込み権限からデータベースへのフルアクセスのみを要求することができます。現時点でこれが明確でない場合は、いくつかの例を挙げて明確にします。.

上記の例に基づいて、あなたはそれを見ることができます、例えば, "youruser ' - "、 "admin' - " または他のユーザー名であれば、パスワードを知らなくても、そのユーザーとして即座にサイトにログインできます。システムに入ったら、実際にはそのユーザーではないことがわからないため、それぞれのアカウントにフルアクセスできます。通常、Webサイトは少なくともそれぞれのデータベースへの読み取り/書き込みアクセス権を持っている必要があるため、データベースのアクセス許可はこのための安全策にはなりません。.

ここで、Webサイトが、レコードの削除、テーブルの追加/削除、新しいセキュリティアカウントの追加などの機能を提供するそれぞれのデータベースを完全に管理しているとしましょう。Webアプリケーションによってはこのタイプの許可が必要なので注意してください。完全なコントロールが与えられることが自動的に悪いことではない.

そのため、この状況で発生する可能性がある損害を説明するために、ユーザー名フィールドに次のように入力して、上記のコミックで提供されている例を使用します。 "Robert '; DROP TABLEユーザー; - ". 単純な置き換えの後、認証クエリは次のようになります。

UserName = "Robert";からユーザーをSELECTします。 DROP TABLEユーザー; - 'AND Password = "wrongpass"

注：SQL照会内のセミコロンは、特定のステートメントの終わりと新しいステートメントの始まりを表すために使用されます。.

これはデータベースによって次のように実行されます。

UserName = "Robert"のユーザーからのSELECT UserID

DROP TABLEユーザー

そのように、私たちはUsersテーブル全体を削除するためにSQLI攻撃を使いました。.

当然ながら、許可されているSQL権限によっては、攻撃者が値を変更したり、テーブル（またはデータベース全体）をテキストファイルにダンプしたり、新しいログインアカウントを作成したり、データベースインストール全体を乗っ取ったりする可能性もあります。.

SQLインジェクション攻撃の防止

前述したように、SQLインジェクション攻撃は簡単に防止できます。 Web開発の基本的な規則の1つは、上記のテンプレートクエリで単純な置換を実行したときに行ったように、ユーザー入力を盲目的に信頼することは決してないということです。.

SQLI攻撃は、入力のサニタイズ（またはエスケープ）と呼ばれるものによって簡単に阻止されます。サニタイズ処理は、基本的にインライン一重引用符（ '）文字を適切に処理することでSQL文の内部で文字列を途中で終了させることができないため、実際には非常に簡単です。.

たとえば、データベースで「O'neil」を検索したい場合は、Oの後の一重引用符で文字列が途中で終了するため、単純な置換は使用できません。代わりに、それぞれのデータベースのエスケープ文字を使用してサニタイズします。インラインの単一引用符のエスケープ文字が各引用符の前に\記号を付けるとしましょう。したがって、「O'neal」は「O \ 'neil」として消毒されます。.

この単純な衛生行為は、SQLI攻撃をほとんど防止します。説明のために、前の例をもう一度見て、ユーザー入力がサニタイズされたときに結果として生じるクエリを見てみましょう。.

myuser '-- / 間違った：

ユーザーからのユーザーIDの選択WHERE UserName = "myuser \" - 'AND Password = "wrongpass"

myuserの後の一重引用符はエスケープされているため（ターゲット値の一部と見なされます）、データベースは文字通り次のUserNameを検索します。 "myuser ' - ". さらに、ダッシュはSQLステートメント自体ではなくストリング値内に含まれているため、SQLコメントとして解釈されるのではなく、ターゲット値の一部と見なされます。.

Robert '; DROP TABLEユーザー。-- / 間違った：

UserName = "Robert \";のユーザーからSELECTユーザーIDを選択します。 DROP TABLEユーザー; - 'AND Password = "wrongpass"

Robertの後の単一引用符を単純にエスケープすることで、セミコロンとダッシュの両方がUserName検索文字列内に含まれるため、データベースは文字列として検索します。 "Robert '; DROP TABLEユーザー; - " テーブル削除を実行する代わりに.

要約すれば

Web攻撃は進化し、より洗練されたり、別の侵入点に集中したりしますが、それらを悪用するように設計されたいくつかの無料の「ハッカーツール」から発想を得ている.

DDoSなどの特定の種類の攻撃は簡単には回避できませんが、SQLIなどの他の攻撃は回避できます。ただし、これらの種類の攻撃によって加えられる可能性がある損害は、取られた予防措置に応じて、不便から壊滅的なものまでどこにでも及ぶ可能性があります。.