セキュリティ対策は言語やアプリケーションを問わず非常に重要です。しかし,
最近の例では次のような物があります。
- WordPress Meenews 5.
1 Cross Site Scripting - WordPress Enable-Latex Remote File Inclusion
- Dolibarr 3.
1.0 RC Cross Site Scripting / SQL Injection
上のURLの脆弱性も対策が簡単なものが多いですが,
なぜ簡単な対策で防げる脆弱性でもセキュリティ対策が確実に実施されないのか?
その理由とはこの2つではないでしょうか。
- セキュリティ対策とコーディングのベストプラクティスは相反することを理解していない
- セキュリティ対策の基本中の基本を理解していない
セキュリティ対策とコーディングのベストプラクティスは相反する
セキュリティ対策とコーディングのベストプラクティスは真っ向から対立している部分があります。
- 多重のセキュリティ対策を実施 vs 重複処理を排除した効率よいコード記述
このセキュリティ対策とコーディングのベストプラクティスは対立する考え方で,
セキュリティ対策の基本の1つとして
セキュリティ対策とコーディングのベストプラクティスは対立する考え方ですが,
よいコードとは次のようなコードです。
- 必要なセキュリティ対策コードを書いた上で,
重複などを排除した効率がよいコード
よいコードの必要条件は
セキュリティ対策の基本中の基本
セキュリティ対策の基本中の基本はどこでセキュリティ対策を行うかです。これが理解されていないケースも多くあります。プログラマから見たセキュリティ対策を行うべき箇所は多くありません。多くないどころかたったの3つです。
- 入力
(入力をバリデーション) - ロジック
- 出力
(出力をエスケープ, バリデーション)
この3つしかありません。この3つに分けて考えてセキュリティ対策を行えば,
入力
入力のチェックは必ず入力を受け入れた直後に,
- 期待している文字で構成されているか?
- 期待している範囲
(長さ, 値) のパラメータか? - 期待している形式のパラメータか?
入力チェックのポイントは正しいものだけを受け入れることです。悪いもの
広く利用されているアプリケーションやフレームワークだからといってベストプラクティスが採用されているわけではありません。例えば,
広く利用されているアプリケーションでも確実なセキュリティ対策が行われているわけではない,
ロジック
ロジックの部分は認証
言語や関数の仕様を知ることもロジックの部分に入ります。言語や関数の仕様を知らずに正しいロジックが書けるはずがありません。もし自分が利用している正規表現関数の仕様を調べたことがない方がいらしたら,
入力処理や出力処理もアプリケーション処理のロジックと言えます。入力と出力は多重のセキュリティを取り入れる部分なので独立した処理として作ります。入出力処理はセキュリティ対策の要であり9割のアプケーション脆弱性は入出力にある,