最近は、ソフトウェア セキュリティに興味があります。論文を読んでいると、多くの攻撃があり、研究者はソフトウェアがより安全なシステムを手に入れるための新しい方法を発明しようとしていることがわかります。
この質問は、すべてのタイプの攻撃を含む一般的なものになる可能性があります.SOには多くの経験豊富なプログラマーがいます.これらの攻撃に対してコードをチェックするために何を使用しているかを知りたいですか? 使用するツールや気にしないツールはありますか?
たとえば、静的/動的コード分析とファズ テストについて聞いたことがあります。
ありがとう
ここでは、Webアプリケーションのセキュリティに焦点を当てます...
本当にあなたはウェブサイト/アプリケーションを手動でトロールし、さまざまなパラメータなどで遊ぶことに慣れたいので、プロキシツールは非常に役立ちます（サーバーに到達する前にフォームをキャプチャして操作することができます）：
LiveHTTPHeaders -FireFoxプラグイン。
BurpProxy -Javaベース。
明らかに、Webサイト全体を手動でクロールするのはかなり時間と手間がかかるようになり、自動スキャンツールが役立つ場合があります。
ブラックボックス：
WebSecurify-使用されていませんが、有名なWebアプリのセキュリティ担当者によって作成されています。
Skipfish -Googleは最近これをリリースしたので、おそらく一見の価値があります。
そして、他にも多くの商用ツールがあります。WhiteHatSentinel、HP Web Inspect、そしておそらく私が覚えていない他の多くのツールです。
白い箱：
私が見た学術研究の多くは、静的コード分析ツールに関連しています。それらはすべてPHPのみに焦点を当てており、いくつかの制限があったため、私は何も使用していません。
その他のリソース：
ha.ckers.org-すばらしいブログで、ウェブアプリの秒に関連する活発なフォーラムがあります。 OWASP-前述のように、ここには洞察に満ちた記事/ガイド/チュートリアルがたくさんあります。
自分でサイトを手動で攻撃する方法について詳しく知りたい場合は、Damn VulnerableWebAppが優れた学習プロジェクトです。つまり、意図的に安全でないように作成されたWebアプリケーションなので、Webアプリケーションのセキュリティの脆弱性に関する知識を合法的にテストできます。
私は3年目の論文のためにPerlでブラックボックススキャナーを書きました。これは非常に興味深いプロジェクトでした。自分で何かを作成したい場合、それは実際には次のもので構成されています。
あなたが言及していないことですが、私は重要だと思います: コードレビュー。
何かをできるだけ早く実装しようとしているだけでは、セキュリティの問題を見落としがちです。特にレビュアーが典型的なセキュリティ ホールを発見する経験を積んでいる場合は、別の目で多くの問題や潜在的な問題を見つけることができます。
多くの場合、特別なツールを使用せずに手動でコード レビューを行うことが可能であると考えています。同じコンピューターの前に一緒に座るか、コードを印刷して、紙のコピーを確認してください。しかし、具体的にツールを求めたので、手動のコード レビューを支援するツールはRietveldです。私自身は使用していませんが、Google 社内で使用されているのと同じアイデアに基づいています (Python の作成者でもある同じ人によって書かれています)。
市場にはたくさんのWebアプリケーションセキュリティスキャナーがあります
このリストを見てください：
WASC-WebアプリケーションセキュリティスキャナーリストとNetsparkerCommunityEdition：Netsparkerの無料バージョンです。
セキュリティは間違いなく懸念事項であり、開発者は少なくとも一般的な脆弱性（およびそれらを回避する方法）を認識している必要があります。これが私が面白いと思ういくつかのリソースです：
私はツールを使用して脆弱性の探索を支援していますが、テストを開始しただけですべてが問題ないと仮定することはできません。プロジェクトを監査しているときは、コードを見て、プログラマーのスタイルとスキル レベルを感じようとします。コードが乱雑に見える場合は、初心者である可能性があり、おそらく初歩的なミスを犯します。
プロジェクト内のセキュリティ関連機能を特定し、手動で監査することが重要です。 Tamperdataは、カスタムの http 要求を作成できるため、手動の監査やエクスプロイトの開発に非常に役立ちます。PHP の手動監査の良い例は次のとおりmysql_real_escape_string($var)ですhtmlspecialchars($var,ENT_QUOTES)。(ENT_QUOTES は、mysql の引用符と同じくらい危険なバックスラッシュを停止しません。mssql は別の話です。) セキュリティ機能は、「論理エラー」が発生する場所でもあり、これを検出できるツールはありません。 、これには手動監査が必要です。
Web アプリケーションのテストを行っている場合は、 Acunetixが最適なテスト ツールです。Wapitiは非常に優れたオープン ソースの代替手段です。どんなツールでも不適切に使用できますが。Web アプリケーションのテストを行う前に、エラー レポートがオンになっていることを確認し、try/catch などで SQL エラーを抑制していないことも確認してください。
バッファ オーバーフローなどの脆弱性について自動静的コード分析を行っている場合は、Coverityが最適なツールです (Fortify は Coverity とほぼ同じです)。Coverity は数万ドルの費用がかかりますが、国土安全保障省などの有名企業が使用しています。 ラットはオープン ソースの代替手段ですが、Coverity ははるかに複雑なツールです。これらのツールはどちらも、多くの偽陽性と偽陰性を生成します。RATS は厄介な関数呼び出しを探しますが、それでも安全かどうかはわかりません。そのため、RATS は strcpy() strcat() sprintf() のすべての呼び出しを報告しますが、たとえば静的テキストをコピーするだけの場合、これらは安全です。これは、多くのがらくたを掘り下げる必要があることを意味しますが、査読を行っている場合、手動検索を絞り込むことで RATS が大いに役立ちます。Linux のような大規模なコード ベースで 1 つの悪用可能な脆弱性を見つけようとしている場合、Rats はあまり役に立ちません。
私は Coverity を使用しましたが、彼らのセールス チームは、「コード ベース内の **** すべて **** の脆弱性を検出する」と主張しています。しかし、直接の経験から、Coverity が検出しなかったピーチによるバニラ スタック ベースのバッファ オーバーフローを発見したことがわかります。(ただし、RATS はこれらの問題を検出し、安全な 1,000 以上の他の関数呼び出しも検出しました...) 安全なアプリケーションが必要な場合、または悪用可能なバッファ オーバーフローを見つけたい場合は、Peach を使用してビルドに使用できるプラットフォーム ツールです。必要なツール。
ダングリング ポインターなどのよりエキゾチックなメモリ破損の問題を探している場合は、Valgrindが役に立ちます。
セキュリティ上の問題を引き起こす可能性のあるソフトウェアの欠陥には、実装のバグと設計上の欠陥の 2 種類があります。
実装のバグは通常、コード内の特定の領域に現れます。検出は比較的簡単で、(通常) 修正するのはそれほど複雑ではありません。これらの (ほとんどの) 静的コード分析を行う自動ツール (Fortify や Ounce などのツール) を使用すると、これらのツールは高価ですが、検出できます。そうは言っても、「銀の弾丸」はなく、ツールが報告する問題の背後にある実際のリスクを確認/理解するために何らかの手動のコードレビューを行わずに、ツールの出力のみに盲目的に依存することはできないことを覚えておく必要があります。
もう 1 つの問題は設計上の欠陥です。それはまた別の話です。これらは通常、コードの誤りの結果ではなく、アプリケーションの設計またはアーキテクチャの選択の誤りによる複雑な問題です。これらは自動化されたツールでは識別できず、コード/設計/アーキテクチャのレビューによって手動でのみ検出できます。それらは通常、設計段階を過ぎて修正するのが非常に難しく、費用がかかります。
したがって、セキュリティに影響を与える可能性のある実装バグについてコードをレビューし (Fortify/Ounce などの自動化ツールを使用したコード レビュー + ツール結果の手動レビュー)、セキュリティ上の欠陥について設計をレビューすることをお勧めします (これにはツールがなく、実行する必要があります)。セキュリティについて知っている人によって）。
ソフトウェア セキュリティと安全なソフトウェアの設計の背後にある複雑さについてよく読むには、Gary McGraw による Software Security: Building Security In をチェックしてください ( amazon リンク) 。
ツールは、コードが安全でないかどうかを知りません。
あなただけが（そして攻撃者も）そうします。
せいぜい、ツールはコード内の1つのタイプのいくつかの脆弱性を発見し、そのタイプの脆弱性から保護されていないことを認識させますが、ツールが見逃したすべてのインスタンスをクリーンアップする必要があります。