一般的な Web エクスプロイトについて知っておくべきことは何ですか?[閉まっている]

https://stackoverflow.com/questions/23102

09-06-2019
|

質問

私は Web プログラミングに関してはまだまったく知識がなく、ほとんどの時間をクライアントアプリケーションに費やしてきました。したがって、私のサイトで恐れ/テストする必要がある一般的なエクスプロイトについて興味があります。

解決

オワスプのリストを保持しますトップ10 Web 開発に役立つその他のセキュリティ情報に加えて、注意すべき Web 攻撃についても説明します。

他のヒント

を投稿しています OWASP 2007 年トップ短縮リストここにあるのは、ソースがダウンした場合に備えて、人々が別のリンクを参照する必要がないようにするためです。

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

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

射出欠陥

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

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

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

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

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

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

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

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

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

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

アカウント資格情報とセッショントークンは、適切に保護されていないことがよくあります。攻撃者は、パスワード、キー、または認証トークンを侵害して、他のユーザーの ID を詐称します。

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

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

安全でない通信

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

URL アクセス制限の失敗

多くの場合、アプリケーションは、権限のないユーザーに対するリンクや URL の表示を防ぐことによって機密機能のみを保護します。攻撃者はこの弱点を利用して、これらの URL に直接アクセスし、不正な操作を実行する可能性があります。

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

-アダム

これら 3 つが最も重要です。

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

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

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

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

bool UserCredentialsOK(User user)
{

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

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

NEVER EVER EVER EVER (「決して」と言ったでしょうか?) フォーム要素から渡されるユーザー情報を信頼します。データがアプリケーションの他の論理層に渡される前に精査されていない場合は、路上で見知らぬ人にサイトのキーを渡してしまうのと同じことです。

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

その後、ユーザーがデータベースに送信し、最終的にはデータベースから送信できるようにするデータの種類を検討する必要があります。HTML の挿入とその後の表示を許可すると、クロスサイトスクリプティング攻撃 (XSS と呼ばれる) の危険にさらされてしまいます。

私にとって思い浮かぶのはこの 2 つですが、当事務所のジェフ・アトウッド氏が次の記事に優れた記事を掲載しています。コーディングホラー本のレビューとともに」ソフトウェアセキュリティの19の大罪".

ここのほとんどの人は SQL インジェクションと XSS について言及しています。種のそれは正しいことですが、だまされないでください。Web 開発者として考慮する必要がある最も重要なことは、XSS と SQL インジェクションの起源である INPUT VALIDATION です。

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

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

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

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

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

ワードプレスのセキュリティ

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

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

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

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

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

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

私は専門家ではありませんが、これまで学んだことから、黄金律はユーザーデータ (GET、POST、COOKIE) を信頼しないことです。一般的な攻撃の種類と身を守る方法:

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow