ウェブ・セキュリティ基礎試験(徳丸基礎試験)⑭
徳丸基礎試験勉強まとめ⑭
「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」の単語集を自分なりに作ってみる
アドバイスや間違い指摘など歓迎です
-
「パーセントエンコーディング」
URLで特別な意味を持つ文字の変換(HTTPのリクエストボディ内など)
UTF-8では
あ → %E3%81%82 -
「文字エンコーディング」
あ → E38182(UTF-8)
逆はデコーディング
E38182 → あ(UTF-8)(HTTPリクエストのGETやPOSTで送られてきたデータを、サーバーで処理する時など) -
「バイナリセーフ」
入力値がどんなバイト列でも正しく扱えること
特に、ヌルバイト(PHPでは\0やUTF-8で%00など)や制御文字が現れても正しく処理できること- ヌルバイトは入力値バリデーションで行う
- 文字エンコーディング変換ではヌルバイトも含めて変換するため、文字エンコーディング変換ではヌルバイトのエラーはでない
-
「クッキー属性」
上記の「path=/」もクッキー属性のひとつ
その他Domain, Expires, Secure. HttpOnlyがある- Domain: 原則使用しないこと!複数のサーバーにクッキーを送信したい場合使う(サブドメインのみ。別ドメインは指定できるがブラウザ側で無視するようになっている)
- Path: ブラウザがクッキーを送信するURLのディレクトリ
- Expires: クッキーの有効期限。設定しない場合はブラウザ終了まで
- Secure: HTTPS通信のサーバーにのみクッキーを送信する
- HttpOnly: Javascriptからクッキーにアクセスできないようにする
-
「クッキーモンスターバグ」
古いブラウザでは、クッキー属性 Domain = co.jp などのクッキーが作れるというバグ。
これができると、amazon.co.jpやyahoo.co.jpにも自由にクッキーが送れてしまう
現在も地域型JPドメイン(xx.kanagawa.jpなど)では古いWindowsブラウザではこの問題が残ってしまっている -
「同一オリジンポリシー」
JSは下記の条件のソースにしかアクセスできない(CORSなしのXMLHttpRequestも同様)
URLホストが一致、スキーム(httpなどプロトコルが一致)、ポートが一致
(クッキーはドメインだけだったのでJSの方が厳しい条件) -
「クロスドメインアクセス」
iframe: src要素にクロスドメインの指定可能だが、クロスドメインを指定した場合は、Javascriptでiframe内の要素にアクセスできない(同一ドメインならアクセスできる)
img: src要素にクロスドメインの指定可能だが、あまり問題ない
script: JSONP
css: CSSXSS攻撃。最新ブラウザを使用することで対応
formのaction属性: CSRF攻撃 -
「CORS(Cross-Origin Resource Sharing)」
XMLHttpRequestなどで別オリジンとのデータ交換をやり取りするための規格- シンプルなリクエスト
- Access-Contral-Allow-Originレスポンスヘッダ
- プリフライトリクエスト
- Access-Control-Request-Method, Access-Control-Allow-Methods
- Access-Control-Request-Headers, Access-Control-Allow-Headers
- Origin, Access-Control-Allow-Origin
- Access-Control-Max-Age(レスポンス)
- XMLHttpRequestのwithCredentioalsプロパティをTrue, Access-Control-Allow-Credentials: true
- シンプルなリクエスト
-
「XSSフィルタ」
反射型XSSをブラウザが検知し無害な出力に変更する機能(ブラウザに実装されている)
X-XSS-Protection(X-XSS-protection: 1; mode=block)をレスポンスヘッダに追加することで、ブラウザのXSSフィルタ設定を強制でONにする -
「TRACEメソッド」
古いブラウザにはクロスサイトトレーシング(XST)攻撃ができる。これはJSでHTTPのTRACEメソッドを送信することでクッキーやBasic認証のID、パスワードを盗む手法
Apacheの場合、httpd.confにTraceEnable Off設定を記載。nginxはデフォルトでOffなので設定不要 -
「反射型XSS」
クッキーを盗む例のように、攻撃用スクリプトが正規サイト以外(罠サイトやメール)にある場合のXSSのこと -
「持続型XSS」
攻撃用スクリプトが正規サイトにある場合(正規サイトDBにスクリプトが保存され、正規サイト内でスクリプトが展開される場合など) -
「動的プレースホルダ」
アプリケーション内でSQLを組み立ててデータベースに送る -
「静的プレースホルダ」
データベース内でSQL文を組み立てる -
「セッションアダプション」
未知のセッションIDを受け入れてしまう特徴。
PHPやASP.NETなどはセッションアダプションの特徴があるので特に注意が必要。
ただし、セッションアダプションがないミドルウェアの場合も、有効なセッションIDを特定して、ユーザーにセッションIDを強制させることができるので注意が必要。 -
「HTTPヘッダインジェクション」「メールヘッダインジェクション」
- 専用のライブラリを使用する
- 外部からのパラメータをヘッダに含ませないようにする
- 外部からのパラメータには改行を含ませないようにする
-
「ディレクトリトラバーサル」
クエリパラメータによってサーバー内のファイルを閲覧できる場合、想定していないファイルを閲覧される(相対パスや絶対パス、ヌルバイトが混入できる場合、かなり危険) -
「OSコマンドインジェクション」
内部でOSコマンドを実行する場合(PHPのsystem関数などのシェル呼び出し機能のある関数を利用するなど)へ外部入力を引数として渡している場合などに起こる
シェルのメタ文字(|, &&, ;など)がエスケープされていない場合、特に危険 -
「PDFのFormCalcによるコンテンツハイジャック」
PDFはFormCalcと呼ばれるスクリプト言語が使用できる。
FormCalcにはURL関数という機能があり、HTTPリクエストを呼び出し結果を受け取ることができる
Adobe Acrobat Readerプラグインを備えたブラウザが影響を受ける(主にIE) -
「レスポンスヘッダX-Content-Type-Options: nosniff」
Content-typeヘッダのみからContent-typeを解釈 -
「Content-type: application/octet-stream」
アプリケーションで開かず、ダウンロードのみ許容する場合は、下記で対応
Content-Disposition: attachment
Content-type: application/octet-stream; filename="hoge.pdf" -
「レスポンスヘッダ: X-Download-Options: noopen」
PDFファイルはブラウザ内で開かずダウンロードを強制(IE限定) -
「RFI(リモートファイルインクルード)」
RFI(リモートファイルをインクルード)できなくすることで、RFI攻撃を防ぐ -
「XXE(XML外部実体参照)」
XML中に外部ファイルの内容を取り込める機能(非推奨) -
「レスポンスヘッダ:Cache-control」
no-store: 全くキャッシュなし
no-cache: キャッシュ有効性を毎回サーバーに確認
private: 1人のユーザーのためのキャッシュ許可。(ブラウザキャッシュ許可、キャッシュサーバーキャッシュ禁止)
public: 全てのキャッシュ保存許可
must-revalidate: キャッシュが陳腐化していないか確認
max-age: リソースが陳腐化していないと考えられる最長期間(秒) -
「JSON」
Ajaxで使用されるデータ交換形式(元々はJSONの代わりにXMLを使用していた) -
「JSONP」
XMLHttpRequestではなくscript要素を用いて外部JSを直接実行してデータ取得
CORSができる前に、異なるオリジンのサーバーとやり取りするために開発された(同一オリジンポリシーの枠内でデータやり取り) -
「セキュリティを強化するレスポンスヘッダ」
X-Frame-Options: frameやiframeの内部に表示することを禁止
X-content-Type-Options: MIMEタイプを厳密に指定(nosniffにする)
X-XSS-protection: XSSフィルタの設定をブラウザでしていても、フィルタの動作モードを上書きする(X-XSS-protection: 1; mode=block)
Content-Security-Policy: https://techblog.securesky-tech.com/entry/2020/05/21/
Strict-Transport-Security: HTTPSを強制する
X-Requested-With: (X-Requested-With:XMLHttpRequest) XMLHttpRequestなどCORS対応機能からのリクエストか確認 -
「DOM-based XSS」
innerHTMLやdocument.write, JQueryセレクタの動的生成, javascriptスキーム(location.href, a要素やiframe要素など) でScript実行
URLパラメータやlocation.hashからの外部入力, XML HttpRequestのURL未検証(外部URLへリクエスト)により攻撃用スクリプトが混入