2

あなたの経験では、サイトの脆弱性に関して何を見つけ、取り組み、または遭遇しましたか？そして、これらの問題を軽減するためにどのような行動を取りましたか？

これには、XSS（クロスサイトスクリプティング）、SQLインジェクション攻撃、単純な古いDDOS、またはサイトの顧客に対するフィッシングの試みが含まれる場合があります。昨日だけ、サイトを監査するためのFirefoxツールのセクション全体とさまざまな脆弱性の可能性に出くわしました。

この分野での私の知識を役割のために拡大することを目指しているので、読んだり学んだりするためのより多くの情報は常に良いです-しっかりしたリンクもありがたいです！そして、あなたが見つけた最悪の、またはあなたが見た中で最も恐ろしい穴の戦争物語-経験から学ぶことが時々最良の方法です！

4

2 に答える 2

7

数十 (数百?) のアプリケーションとサイトのセキュリティ レビュー、ホワイト ボックスとブラック ボックスを行ってきました。

  1. XSS と SQL インジェクションは多くの報道を受けていますが、最も一般的なセキュリティ上の欠陥は何か知っていますか? 本番コードにデバッグおよびテスト機能を残します。POST パラメーター (isDebug=True) を改ざんするか、サイトをスパイダーして残りのページを見つけるかのいずれかによって、これらはセキュリティに関して私が目にする最悪の間違いです。テスト/デバッグ コードを含める場合は、別のコード ブランチに配置するか、少なくともリリース前に削除するためのチェックリストを準備してください。

  2. 私が確認した次の最も一般的な脆弱性は、ページ ソースから URL を取得することによってセキュリティ メカニズムをバイパスする機能です。技術的な名前は 'Forceful Navigation' または 'Forced Browsing' です。これは、HTML を読むことができる人なら誰でもできることですが、脆弱なアプリケーションの多様性には驚かされます。昨日チケット購入サイトを見ていたら、売り切れていた公演のチケットをこの方法で購入できました。以前のサイトでは、支払いを完全にスキップできました (非常に多くの Paypal サイトが、「購入完了」URL を POST パラメーター経由で Paypal に渡します - yoink!)。完了、支払い、可用性、正確性などを保証するために、何らかのバックエンドのステートフルネスまたはチェックが必要です。

  3. 率直に言うと、私は通常、AppScan、BURP プロキシ、WebScarab、Fortify、FindBugs、または YASCA などのツール (予算とソース コードのアクセシビリティに応じて) に XSS および SQL インジェクション攻撃を見つけてもらいます。シンプルなものを自分で試して、明らかな穴を探しますが、自分で試すには既知の組み合わせが多すぎます。より高度な、または最近発見された欠陥のスクリプトとテスト ケースの小さなコレクションを保持しています。

私は本当に一日中続けることができたので、3でやめます。あなたの質問から集中力が失われ、誰もテキストの壁を読みたがりません.

初心者および経験豊富な Web セキュリティの専門家向けのリソース: (ARGH. まだ正式にリンクを投稿することはできません。コピーして貼り付けてください。申し訳ありません)

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

http://www.owasp.org/

Web セキュリティ テスト クックブック

この本は、監査人、テスター向けに書かれており、開発者向けではありません。これは、O'Reilly の本としてはかなり珍しいことです。

websecuritytesting.com

Fortifyによる脆弱性の分類

www.fortify.com/vulncat/

一般的な弱点の列挙 (警告: 広範囲)

nvd.nist.gov/cwe.cfm

一般的な攻撃パターンの列挙と分類 (警告: さらに広範囲)

capec.mitre.org/

Google の Web セキュリティ チュートリアル

（かなり弱い）

code.google.com/edu/security/index.html

于 2009-11-12T16:56:16.773 に答える
1

ドキュメント ライブラリを含む Web アプリ プロジェクトに参加しました。ドキュメントを参照する方法は、 http://example.com/getdocument?file=somefile.pdfのようなものでした。もちろん、file=/etc/passwd を試すだけで、もちろんうまくいきました。

解決策: ユーザー入力のサニタイズを実行するか、URL で要求されたリソースと実際のファイルシステム リソースの間である程度の抽象化を使用します。

これは、SQL インジェクション攻撃のいとこです。クライアントに過剰な制御を与えている疑いのある許可されたリクエストを調べます。

于 2009-11-12T14:01:52.090 に答える