指摘を修正する
既存のアプリケーションの最初のスキャンから、CI で問題のない状態を保つまでの、報告書の進め方です。
1. 報告書を上から読む
指摘はリスクごとにまとまっています。高 (SQL、リクエストで選ぶビュー、リクエストの unserialize()、本番の デバッグレベルや salt) から始め、次に 中 に進みます。各ルールのページには、見つけたものと、箇所とそのコードが あります。コードで開き、修正方法は ルールのページ をご覧ください。
ルールが見るのはコードの書き方で、値がどこから来たかではありません。各箇所で、まず値がユーザーから来うるかを 判断してください (リクエスト、Cookie、ヘッダー、アップロードされたファイル、ユーザーが以前に保存したデータ)。来うるなら 脆弱性なので修正します。来ないなら、簡単なら修正し (あとでコードが変わったときにも安全です)、そうでなければ理由を書いて 除外します。
2. ルールごとにまとめて修正する
ほとんどのルールには、すべての箇所に共通の修正方法があります。query() のプレースホルダー、find() の条件の配列、 ビューの h()、許可した値の一覧です。ルールのすべての箇所を 1 つの変更で修正し、スキャンの範囲外のコード (シェル、 プラグイン、アプリケーションのライブラリ) にも同じ書き方がないか探してください。
設定の指摘は、コードではなく本番の設定で修正します。設定 と、秘密の値を変えると何が使えなくなるかの 注意をご覧ください。
3. 修正できたことを確かめる
- もう一度チェックし、その箇所が指摘されないことを確かめます。
- 壊れたはずの値でアクションのテストを足します。検索のクォート (
O'Brien)、テキストとして表示されるべき名前の<b>、 リダイレクトのほかのサイトの URL などです。 - End-to-End テストで pieceofcake2/security-dast のフルスキャンを 実行します。攻撃者と同じようにページとフォームを攻撃します。
4. 安全なものは理由を書いて除外する
定数のクエリなど安全な箇所は、その場所で、理由を書いたコメントで除外します (指摘を除外する)。報告書を通すために、アプリケーション全体でルールを除外しないでください。 そのルールの次の箇所が指摘されなくなります。
ビューでわざとサニタイズした HTML を入れる変数は、safeViewVariables で一度だけ安全にします (cakephp2-view-unescaped-output)。
5. CI で保つ
push と pull request のたびにチェックします (GitHub Actions での CI)。
- まず
--fail-on=noneにします。ジョブを失敗させずに、報告書で指摘を見られます。 - 高の指摘を修正してから
--fail-on=highにします。新しい高の指摘は、それを足した pull request を失敗させます。 - 中の指摘を修正してから
--fail-on=mediumにします。
実行ごとの報告書 (ジョブの成果物) は残してください。アプリケーションのチェックの記録になります。