ネットワーク第7回

Webセキュリティの基礎

Herokuプロジェクトを使用してセッ
ション管理の仕組みを実践

ステータスライン
レスポンスヘッダ
ヘッダ名：ヘッダ値
・
・
空行(CRLF)

レスポンスボディ(HTMLなど)

HTTP/1.1 200 OK
Server: Jetty(7.6.0.v20120127)
Connection: keep-alive
Content-Length: 692
Content-type:text/plain

番号

意味

200

OK(成功)

302

Found (リダイレクト)

304

Not Modified (キャッシュを参照)

400

Bad Request (Clientからのリクエスト不備)

403

Forbidden (アクセス禁止)

404

Not Found (ページが存在しない)

500

Internal Server Error (サーバエラー)

503

Service Unavailable (サーバが過負荷状態)

 Content-Length
 ボディのバイト数

 Content-Type
 MIMEタイプというリソースの種類を
指定
 セミコロン(;)を付けてcharset=UTF-8と
記述すれば、UTF-8という文字エン
コーディングであることを示す

MIMEタイプ

意味

text/plain

テキスト

text/html

HTML文書

application/xml

XML文書

text/css

CSS文書

image/gif

GIF画像

image/jpeg

JPEG画像

image/png

PNG画像

application/json

JSON(Javascript
Object Notation)

リクエストライン(メソッド

URI

プロトコル)

リクエストヘッダ
ヘッダ名：ヘッダ値
・
・
空行(CRLF)

メッセージボディ(POSTの場合はここにクエリが入る)

 http://httpserverex.herokuapp.co
m/ (各個人のHerokuアプリケー
ションのURL)にアクセスするテ
キストボックスに日本語で入力
して送信ボタンを押す

POST /hello HTTP/1.1
Host: httpserverex.herokuapp.com
Connection: keep-alive
Content-Length: 77
Content-Type: application/x-www-form-urlencoded
Referer: http://httpserverex.herokuapp.com/Cookie:
JSESSIONID=1ut4gy3t4kqu1mncf3ykldj5a
メッセージボディ
input=%E3%81%82%E3%81%84%E3%81%88%E3%81%86%E3%81%8A&submit=%
E9%80%81%E4%BF%A1

 Content-Length
 ボディのバイト数

 Content-Type
 送信する値のMIMEタイプ特にformで
指定がなければ『application/x-wwwform-urlencoded』になる
 名前=値を『&』でつないだデータ形
式

 特殊記号や日本語などURLに使
用できない文字をURL上に記述
する場合に用いる

 対象の文字をバイト単位で
『%xx』という形式で表す。(xx
は16進数※UTF8の場合)
 URL エンコード/デコードフォー
ム
 http://home.kendomo.net/board/decode
/

※半角スペースは『%20』になる
が、Content-Typeが『application/xwww-form-urlencoded』の場合は、
特別扱いして『+(半角)』になる

 リンク元のURLを示すヘッダ
Refererヘッダはセキュリティの
役に立つこともあれば、問題に
なることもある
 メリット：Refererヘッダは、ア
プリケーションが意図した遷移
を経ていることを確認すること
ができるが、アクセスしている
本人によってツールやブラウザ
のプラグインで改変、削除され
ることもある
 デメリット：URLに秘密情報を
含んでいる場合は、セキュリ
ティ上問題になる

 RFC2616より
 GETメソッドは参照(リソースの取得)
のみに用いる
 GETメソッドは副作用がないことが期
待される
 秘密情報の送信にはPOSTメソッドを用
いること

 リソース(コンテンツ)の取得以
外のこと
→サーバ側でのデータの追加・更
新・削除が起きる作用のこと
 典型的な例：物品の購入、利用
者の登録・削除などの処理
 更新系の画面ではPOSTメソッド
を使わなければならない

 GETメソッドは、URLにクエリー
の文字列の形でパラメータを渡
すが、ブラウザやサーバが処理
出来るURLの長さには上限があ
る。
 データ量が多い場合は、POSTメ
ソッドを使う方が安全

 GETメソッドの場合は、以下の
可能性があるため
 URL上に指定されたパラメータが
Referer経由で外部に漏洩する
 URL上に指定されたパラメータがアク
セスログに残る

 以下が1つでも当てはまる場合
にPOSTメソッドを使うべき
 データ更新など副作用に伴うリクエス
トの場合
 秘密情報を送信する場合
 送信するデータの総量が多い場合

 index.jspのbodyタグの中を以下に書き換える
<form action="/confirm" method="POST">
氏名<input type="text" name="name"><br>
メールアドレス<input type="text" name="mail"><br>
性別<input type="radio" name="gender" value="女">女
<input type="radio" name="gender" value="男">男<br>
<input type="submit" name="submit" value="送信">
</form>

 index.jspと同じ階層に『confirm.jsp』を新規ファイルで作成し、
以下の内容を記述
<%@ page contentType="text/html;charset=UTF-8" %>
<html>
<head>
<title>確認</title>
</head>
<body>
<form action="/ok" method="post">
氏名:<%=request.getParameter("name")%><br>
メールアドレス：<%=request.getParameter("mail")%><br>
性別：<%=request.getParameter("gender")%><br>
<input type="hidden" name="name"
value="<%=request.getParameter("name")%>">
<input type="hidden" name="mail"
value="<%=request.getParameter("mail")%>">
<input type="hidden" name="gender"
value="<%=request.getParameter("gender")%>">
<input type="submit" value="登録">
</form>

</body>
</html>

 index.jspと同じ階層に『ok.jsp』を新規ファイルで作
成し、以下の内容を記述
<%@ page contentType="text/html;charset=UTF-8" %>
<html>
<head>
<title>登録完了</title>
</head>
<body>
氏名:<%=request.getParameter("name")%><br>

メールアドレス：
<%=request.getParameter("mail")%><br>
性別：<%=request.getParameter("gender")%><br>
登録されました。
</body>
</html>

 『src/com.example』パッケージの中に『ConfirmServlet.java』を新規作成し、
以下を記述する
public class ConfirmServlet extends HttpServlet {
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
req.getRequestDispatcher("/confirm.jsp").forward(req, resp);
}
}

 『src/com.example』パッケージの中に『OKServlet.java』を新規作成し、以下
を記述する
public class OKServlet extends HttpServlet {
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
req.getRequestDispatcher("/ok.jsp").forward(req, resp);
}
}

 web.xmlにマッピングを追加(<web-app>タグの中に記述)
<servlet>
<servlet-name>confirm</servlet-name>
<servlet-class>com.example.ConfirmServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>confirm</servlet-name>
<url-pattern>/confirm</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>ok</servlet-name>
<servlet-class>com.example.OKServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ok</servlet-name>
<url-pattern>/ok</url-pattern>
</servlet-mapping>

 http://localhost:8080/ にアクセス
し、項目を入力してボタンをク
リック

 先ほど作った入力フォームの確
認ボタンをクリックした後に、
ブラウザバックで戻って、ソー
スを確認する
 Chromeの場合は、HTMLの中の
要素を変更出来るので、hidden
項目のvalueを変更して、ボタン
をクリックすると、次画面で入
力された値と変更されているこ
とがわかる

 HTTPは、クライアントの現在の
状態を覚えておく設計になって
いる
 この性質をHTTPのステートレス
性と言う
 ラベル表示では、現在の状態を
覚えておくのが出来ないため、
通常はhiddenパラメータに値を
覚えさせておく

 ブラウザのプラグインやプロキ
シツールなどで本来変更があっ
てはならない値が変更されてい
た
 このhiddenパラメータの処理す
る部分に脆弱性がある
 つまり、攻撃対象となる

客：登録したいんだけど
店員：氏名、メールアドレス、性別(男または女)をお願いします
客：氏名は山田太郎、メールアドレスはtarou@example.jp、性別は男です
店員：復唱します。氏名は山田太郎、メールアドレスはtarou@example.jp、
性別は男、確認お願いします。
客：氏名は山田花子、メールアドレスはhanako@example.com、性別は女で
す。登録よろしくお願いします。
店員：氏名は山田花子、メールアドレスはhanako@example.com、
性別は女で登録しました。

 利用者自身からは書き換えが可
能だが、情報漏えいや第三者か
らの書き換えに対しては堅牢で
ある
 hiddenパラメータと比較する対
象には、クッキーやセッション
変数がある
 クッキーやセッション変数の欠
点として、セッションIDの固定
攻撃に弱いことがあげられる
 特に、ログイン前の状態でかつ
地域性型ドメインを使っている
場合には、クッキーモンスター
問題の影響により、セッション
変数の漏洩に対する効果的な対
策がない
 利用者自身によって書き換えら
れては困る認証や認可に関する
情報はセッション変数に保存す
べきだが、それ以外はhiddenパ
ラメータを使用する

 ECサイトの『買い物カゴに入れ
る』
 アプリケーションの状態を覚え
ておくことを『セッション管
理』と言う

 セッション管理をHTTPで実現す
る目的の仕組み
 サーバ側からブラウザに対して、
『名前=変数』の組を覚えてお
くように指示する

 安全なWebアプリケーションの
作り方-脆弱性が生まれる原理と
対策の実践- 徳丸浩著

ネットワーク第7回

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (6)

Plus de Yukiko Kato

Plus de Yukiko Kato (20)

ネットワーク第7回