Open1
ウェブ・セキュリティ基礎試験(徳丸基礎試験)③
徳丸基礎試験勉強まとめ③
「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」の4章の4.1&4.2を自分なりにまとめる
アドバイスや間違い指摘など歓迎です
4章 「Webアプリケーションの機能別に見るセキュリティバグ」
4.1 Webアプリケーションの機能と脆弱性の対応
脆弱性ってカテゴリ分けできる?
- インジェクション系脆弱性(出力に起因)
- XSS(クロスサイト・スクリプティング)
- HTTPヘッダ・インジェクション
- SQLインジェクション
- OSコマンド・インジェクション
- メールヘッダ・インジェクション
- それ以外(処理に起因)
- ディレクトリ・トラバーサル
- CSRF(クロスサイト・リクエストフォージェリ)
- セッションID固定化などの認証不備
- 認可不備
4.2 入力処理とセキュリティ
入力ってなにをする?
- 文字エンコーディングバリデーション
- 文字エンコーディング変換
- 入力値バリデーション
文字エンコーディングバリデーションってなに?
文字列が正しいエンコーディング形式(UTF-8など)か判定すること。
不正なバイト列が入ってしまうと脆弱性の原因となる
PHPの場合はmb_check_encoding関数を使用する
mb_check_encoding($string, 'UTF-8')
参考:
文字エンコーディング変換ってなに?
あ → E38182(UTF-8)
逆はデコーディング
E38182 → あ(UTF-8)
自動的に変換する言語と明示的に変換する言語がある
言語 | 自動変換 | 明示変換 |
---|---|---|
PHP | php.ini | mb_convert_encoding関数 |
Ruby | STDIN.set_encoding('cp932', 'utf-8')など | ord関数 |
Perl | 自動変換できない | Encode::decode |
参考:
o.org/moji_conv/16-URLencode_UTF-8.html入力値バリデーションってなに?
フォームの入力欄やGETメソッドのパラメータなどから入った入力をチェックすること
- 用語「バイナリセーフ」
入力値がどんなバイト列でも正しく扱えること
特に、ヌルバイト(PHPでは\0やUTF-8で%00など)が現れても正しく処理できること- ヌルバイトは入力値バリデーションで行う
- 文字エンコーディング変換ではヌルバイトも含めて変換するため、文字エンコーディング変換ではヌルバイトのエラーはでない
なんでヌルバイトを特別視するの?
C言語などでは、ヌルバイトを文字列の終端として見なす。
なのでヌルバイト以降の文字列が入力値バリデーションをすり抜け、インジェクション攻撃の原因になる場合がある
ヌルバイトと同様に他の制御文字(0x20以下)も特別視する
phpで正規表現を扱う場合mregなどのバイナリセーフでない関数ではないため非奨励。代わりにpreg, mb_eregを使うことで対応
他に気をつけた方がいいことは?
- 入力項目が指定されていないケース
- $foo = $_GET['foo'] ?? null; などで対応する
- 配列形式で入力されているケース
- /?foo['a']=1&foo['b']=2などで入力されている場合も考慮する
- PHPではfilter_inputなどで対応する
https://wepicks.net/phpfunction-filter-filter_input/