Webセキュリティのテスト

ddos penetration-testing penetration-tools security xss

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

これには、XSS(クロスサイトスクリプティング)、SQLインジェクション攻撃、普通のDDOS、またはサイトの顧客に対するフィッシング攻撃などが含まれます。 昨日だけ私はサイトを監査するためのFirefoxツールとそれらがさまざまな脆弱性の可能性のためのツールの全セクションに出くわした。

この分野での私の知識を役割として広げようと思っているので、読むことや学ぶことがもっと多くの情報が常に得意です – しっかりしたリンクも高く評価されています! そして、あなたが見つけた最悪の、あるいはあなたが見た中で最も怖い穴の戦争物語 – 経験から学ぶことが時々最善の方法です!

  2  6


ベストアンサー

私は何十ものアプリケーションやサイトのために、セキュリティの見直し、ホワイトボックスとブラックボックスをしました。

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

  2. 私が次に見た最も一般的な脆弱性は、単にページソースからURLを取得することによってセキュリティメカニズムを回避する能力です。 技術的な名称は ‘Forceful Navigation’または ‘Forced Browsing’です。これはHTMLを読むことができる人なら誰でもできることですが、さまざまなアプリケーションが脆弱であることに驚きます。 昨日チケット購入サイトを見てみると、この方法で売り切れのショーのチケットを購入することができました。 以前のサイトでは、私は全部支払うことをスキップすることができました(多くの、多くのPaypalサイトはPOSTパラメータを通してpaypalに “購入完了” URLを渡します – yoink!)。 完了、支払い、可用性、正確性などを確実にするために、何らかのバックエンドのステートフルさやチェックが必要です。

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

私は3日でやめるつもりです、なぜなら私は本当に一日中行くことができるからです。私はあなたの質問に焦点を当てていません、そして誰もテキストの壁を読みたくありません。

新しくて熟練したWebセキュリティの達人のためのいくつかのリソース:(ARGH。 正式にリンクを投稿することはできません。 コピーペースト。 ごめんなさい)

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

  • 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

7


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

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

これはSQLインジェクション攻撃の従兄弟です。 クライアントにあまりにも多くの制御を与えているように疑わしく見える許可された要求を調べてください。

1


タイトルとURLをコピーしました