
エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
脆弱性を直した後のセキュリティテスト(SQLインジェクションの場合) - Qiita
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
脆弱性を直した後のセキュリティテスト(SQLインジェクションの場合) - Qiita
脆弱性が報告されてから修正が完了するまでに、Webアプリケーション開発者(またはテスター)ができること... 脆弱性が報告されてから修正が完了するまでに、Webアプリケーション開発者(またはテスター)ができることをセキュリティテストを中心に書く。 再現手順の確立 原因究明 対策の実行 修正の確認 セキュリティテスト セキュリティテストってどうやればいいの?とか、セキュリティベンダの脆弱性診断高すぎ内製化したる!とか、そんな人たちの参考になればいいなあ。 ※本記事のサンプルコードは C# + Entity Framework だが、プロセスは他の言語やフレームワークでも通用する。 1.再現手順の確立 ※注意:再現行為を本番環境でやるのは危険すぎるので、検証環境でやるのがよい 脆弱性が報告されたら、通常のバグ修正と同じように、まず脆弱性を再現させる。(TDD風に言うなら、レッドになるテストを作る) SQLインジェクションの場合、主にHTTPリクエスト(URL、ヘッダ、本文など)が再現手順になる。あらか