security - 知っておくべき一般的な Web エクスプロイトは何ですか?

Question

Web プログラミングに関して言えば、私はまだかなり環境に優しく、ほとんどの時間をクライアントアプリケーションに費やしてきました。だから私は自分のサイトで恐れる/テストする必要がある一般的なエクスプロイトに興味があります.

score 35 · Accepted Answer

ここにOWASP Top 2007の省略されたリストを掲載しているので、人々は別のリンクを調べたり、ソースがダウンした場合に備えたりする必要がありません。

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

XSS の欠陥は、アプリケーションがユーザーから提供されたデータを取得し、そのコンテンツを最初に検証またはエンコードせずに Web ブラウザーに送信するたびに発生します。XSS を使用すると、攻撃者は被害者のブラウザでスクリプトを実行して、ユーザーセッションをハイジャックしたり、Web サイトを改ざんしたり、ワームを導入したりする可能性があります。

インジェクションの欠陥

インジェクションの欠陥、特に SQL インジェクションは Web アプリケーションでよく見られます。インジェクションは、ユーザーが指定したデータがコマンドまたはクエリの一部としてインタープリターに送信されるときに発生します。攻撃者の敵対的なデータは、インタープリターをだまして、意図しないコマンドを実行させたり、データを変更させたりします。

悪意のあるファイルの実行

リモートファイルインクルージョン (RFI) に対して脆弱なコードにより、攻撃者は敵対的なコードやデータを含めることができ、サーバー全体の侵害などの壊滅的な攻撃が発生します。悪意のあるファイル実行攻撃は、PHP、XML、およびユーザーからファイル名やファイルを受け入れるあらゆるフレームワークに影響を与えます。

安全でない直接オブジェクト参照

オブジェクトの直接参照は、開発者がファイル、ディレクトリ、データベースレコード、キーなどの内部実装オブジェクトへの参照を URL またはフォームパラメータとして公開するときに発生します。攻撃者はこれらの参照を操作して、承認なしで他のオブジェクトにアクセスできます。

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

CSRF 攻撃は、ログオンしている被害者のブラウザに事前認証済みのリクエストを脆弱な Web アプリケーションに送信させ、被害者のブラウザに攻撃者の利益のために敵対的なアクションを実行させます。CSRF は、攻撃対象の Web アプリケーションと同じくらい強力です。

情報漏洩と不適切なエラー処理

アプリケーションは、さまざまなアプリケーションの問題を通じて、意図せずに構成や内部の仕組みに関する情報を漏らしたり、プライバシーを侵害したりする可能性があります。攻撃者はこの弱点を利用して、機密データを盗んだり、より深刻な攻撃を実行したりします。

壊れた認証とセッション管理

多くの場合、アカウントの資格情報とセッショントークンは適切に保護されていません。攻撃者は、パスワード、キー、または認証トークンを侵害して、他のユーザーの身元を偽装します。

安全でない暗号化ストレージ

Web アプリケーションでは、暗号化機能を適切に使用してデータと資格情報を保護することはめったにありません。攻撃者は、保護が不十分なデータを使用して、個人情報の盗難や、クレジットカード詐欺などの犯罪を実行します。

安全でない通信

機密性の高い通信を保護する必要がある場合、アプリケーションはネットワークトラフィックの暗号化に失敗することがよくあります。

URL アクセス制限の失敗

多くの場合、アプリケーションは、許可されていないユーザーへのリンクまたは URL の表示を防止することによって、機密性の高い機能のみを保護します。攻撃者は、この脆弱性を利用して、これらの URL に直接アクセスすることで、不正な操作にアクセスして実行することができます。

オープンウェブアプリケーションセキュリティプロジェクト

-アダム

score 29 · Accepted Answer

OWASPは、 Web開発に役立つその他のセキュリティ情報に加えて、監視するWeb攻撃のトップ10のリストを保持しています。

score 28 · Accepted Answer

次の 3 つが最も重要です。

score 10 · Accepted Answer

誰もが「SQL インジェクション」と言うでしょう。なぜなら、これは最も恐ろしく聞こえる脆弱性であり、理解するのが最も簡単な脆弱性だからです。クロスサイトスクリプティング (XSS) も理解しやすいため、2 位になるでしょう。「不十分な入力検証」は脆弱性ではなく、セキュリティのベストプラクティスの評価です。

これを別の視点から試してみましょう。以下は、Web アプリケーションに実装すると混乱する可能性が高い機能です。

動的 SQL (たとえば、UI クエリビルダー)。ここまでで、Web アプリで SQL を確実に安全に使用する唯一の方法は、クエリ内の各パラメーターを変数に明示的にバインドする、パラメーター化されたクエリを使用することであることがおわかりでしょう。Web アプリがこの規則を破る頻度が最も高いのは、悪意のある入力が明らかなパラメーター (名前など) ではなく、クエリ属性である場合です。明らかな例は、検索サイトで見られる iTunes のような「スマートプレイリスト」クエリビルダです。このクエリビルダでは、WHERE 句演算子などがバックエンドに直接渡されます。もう 1 つの優れた機能は、テーブルの列の並べ替えです。ここでは、HTTP パラメーターで公開されている DESC などを確認できます。
ファイルのアップロード。ファイルのパス名が疑わしく URL のパス名に似ているため、ファイルのアップロードは人々を混乱させます。また、Web サーバーでは、URL をファイルシステムのディレクトリに向けるだけで「ダウンロード」部分を簡単に実装できるためです。私たちがテストした 10 個のアップロードハンドラーのうち 7 個は、攻撃者がサーバー上の任意のファイルにアクセスすることを許可しています。これは、アプリ開発者が、ファイルシステムの「open()」呼び出しに、クエリに適用されるのと同じアクセス許可が適用されると想定していたためです。
パスワードの保管。私が生のパスワードを紛失したときに、あなたのアプリケーションが私に生のパスワードをメールで送り返すことができるなら、あなたは失敗します。パスワードの保存には、安全で信頼できる答えが 1 つあります。それは bcrypt です。PHP を使用している場合は、おそらく PHPpass が必要です。
乱数生成。Web アプリに対する古典的な攻撃: 別のユーザーのパスワードをリセットします。アプリはシステムの「rand()」関数を使用しているため、暗号強度が高くないため、パスワードは予測可能です。これは、暗号化を行っている場所にも当てはまります。ところで、これはすべきではありません。どこでも暗号に依存している場合、脆弱である可能性が非常に高くなります。
動的出力。人々は入力の検証を信頼しすぎています。特に、メタ文字がユーザー入力の必要な部分である現実の世界では、考えられるすべてのメタ文字のユーザー入力をスクラブする可能性は低いです。はるかに優れたアプローチは、データベース出力をフィルタリングし、それらを quot、gt、lt などの HTML エンティティに変換するという一貫した体制を持つことです。Rails はこれを自動的に行います。
Eメール。多くのアプリケーションは、攻撃者が匿名アカウントを作成するか、アカウントをまったく使用せずに、攻撃者が制御する電子メールを任意の電子メールアドレスに送信できるようにする、ある種のアウトバウンドメール機能を実装しています。

これらの機能以外に、アプリケーションで犯す可能性が最も高い間違いの 1 つは、データベースの行 ID をどこかに公開して、数字を「5」から「6」に変更するだけで、ユーザー X がユーザー Y のデータを参照できるようにすることです。

score 10 · Accepted Answer

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}

score 3 · Accepted Answer

SQLインジェクション攻撃。それらは避けるのは簡単ですが、あまりにも一般的です。

フォーム要素から渡されたユーザー情報を信頼することはありません（「これまで」と言いましたか？）。アプリケーションの他の論理レイヤーに渡される前にデータが精査されていない場合は、サイトのキーを通りにいる見知らぬ人に渡したほうがよいでしょう。

使用しているプラットフォームについては言及していませんが、ASP.NETを使用している場合は、古き良きスコットガスリーと彼の記事「ヒント/トリック：SQLインジェクション攻撃に対するガード」から始めてください。

その後、ユーザーがデータベースに送信したり、最終的にデータベースから送信したりできるデータの種類を検討する必要があります。HTMLの挿入を許可し、後で表示することを許可すると、クロスサイトスクリプティング攻撃（XSSと呼ばれる）に対して広く開放されます。

これらは私にとって頭に浮かぶ2つですが、私たち自身のJeff Atwoodは、「 19 Deadly Sins of Software Security 」という本のレビューとともに、CodingHorrorで優れた記事を掲載しました。

score 3 · Accepted Answer

ここでほとんどの人が SQL インジェクションと XSS について言及していますが、これはある程度正しいですが、だまされてはなりません。Web 開発者として心配する必要がある最も重要なことは、XSS と SQL インジェクションが発生する場所である INPUT VALIDATION です。

たとえば、整数のみを受け入れるフォームフィールドがある場合は、データをサニタイズするために、クライアント側とサーバー側の両方で何かを実装していることを確認してください。

特に SQL クエリになる場合は、入力データを確認して再確認してください。エスケーパー関数を作成して、クエリに入るすべてのものをラップすることをお勧めします。例えば：

$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";

同様に、ユーザーが入力した情報を Web ページに表示する場合は、 <script> タグや、Javascript の実行につながる可能性のあるその他のもの (onLoad= onMouseOver= など) をすべて削除してください。タグの属性）。

score 1 · Accepted Answer

これは、WordPressのコア開発者の1人によるセキュリティに関する短いプレゼンテーションでもあります。

WordPressのセキュリティ

Webアプリの基本的なセキュリティ問題をすべてカバーしています。

score 0 · Accepted Answer

ストアドプロシージャやパラメータ化されたクエリを使用すると、SQLインジェクションから保護するのに大いに役立ちます。また、Webアプリにsaまたはdboとしてデータベースにアクセスさせないでください。標準のユーザーアカウントを設定し、権限を設定します。

AS for XSS（クロスサイトスクリプティング）ASP.NETには、いくつかの保護機能が組み込まれています。最良の方法は、検証コントロールと正規表現を使用して入力をフィルタリングすることです。

score 0 · Accepted Answer

0

SQLインジェクション。クロスサイトスクリプティング。

于 2008-08-22T18:28:50.313 に答える

score 0 · Accepted Answer

私は専門家ではありませんが、これまでに学んだことから、ゴールデンルールはユーザーデータ (GET、POST、COOKIE) を信頼しないことです。一般的な攻撃の種類と自分を救う方法:

SQL インジェクション攻撃: 準備されたクエリを使用する
クロスサイトスクリプティング: 最初にフィルタリング/エスケープせずに、ユーザーデータをブラウザーに送信しません。これには、データベースに保存されているユーザーデータも含まれます。

score 0 · Accepted Answer

最も一般的なのは、おそらくデータベースインジェクション攻撃とクロスサイトスクリプティング攻撃です。主に、それらが最も簡単に達成できるためです (これは、プログラマーが最も怠惰であるためと思われます)。

score 0 · Accepted Answer

このサイトでも、アプリケーションへのコードインジェクションに関連する最も有害なものが見られることがわかります。そのため、XSS (クロスサイトスクリプティング) と SQL インジェクション (@Patrick の提案) が最大の懸念事項です。基本的に、アプリケーションでユーザーがコードを挿入できるようにする場合は、許可したいもの (html リンク、画像など) のみを許可するように規制およびテストされていることを確認する必要があります。 ) が渡され、他には何も実行されません。

13 に答える 13

Related

Reference