この記事を読むのに必要な時間：およそ 0.5 分
ダウンロード
※ 本サンプルソースコードは，あくまでも本書の理解をすすめるためのものです。本アーカイブに含まれるプログラムの使用により生じたいかなる損害に対しても，技術評論社および著者はいっさいの責任および損害に対する責務は負いません。あくまでも自己責任のもとでのご使用をお願いいたします。あらかじめご承知おきください。
ダウンロード後，ファイル解凍ツールで適宜解凍しご利用ください。なお，商用利用は一切禁止します。
また，執筆者のWebページでも，同じサンプルソースコードを提供していますので，そちらも参照ください。
お詫びと訂正（正誤表）
本書掲載の記述に誤りがありました。訂正するとともに，読者の皆様および関係者の方々に深くお詫び申し上げます。
P.21 下から4行目
| 誤 |
「レスポンス(responce)」 |
| 正 |
「レスポンス(response)」 |
|---|
P.78 「GET とPOST どちらを使えばよい？」内の3～4行目
| 誤 |
しかし，GET リクエストによるパラメータ渡しにも，ちゃんとメリットはあるのです。 |
| 正 |
しかし，GET リクエストとPOSTリクエストには大きな違いがあります。 |
|---|
P.79 表3-5の次の文
| 誤 |
たいていの場合は～中略～ということになります。 |
| 正 |
GETリクエストとPOSTリクエストの使い分けをまとめましょう。ログイン処理のようにユーザ名やパスワードといった機密情報を送信する場合や、決済処理などの副作用を伴う処理、クエリ文字列に収まりきらない大量の情報を送信する必要がある場合は、POSTメソッドを使用すべきです。前述の条件にあてはまらず、副作用がない処理ではGETリクエストを利用した方がパラメータごと保存できるというメリットを活かすことができます。
|
|---|
P.79 1行目～3行目
| 誤 |
このように～中略～使い方はできません。 |
| 正 |
このように、GETメソッドではURLにパラメータが含まれるため、パラメータごと記憶したり、人に伝えたりするのに便利です。また、そのようなことを可能にするためには、GETリクエストの結果がシステムの状態に影響を与えないようになっていることが重要です。たとえば、ある一時点でgoogleに何度同じ検索キーワードを入力しても結果は変わらないはずです。このように同じ要求をを何度繰り返しても同じ結果が得られることを「副作用がない」といいます。HTTPについて規定したRFC2616（28ページコラム参照）でも、GETリクエストには副作用が無いことが期待される旨、記述されています。 |
|---|
P.79 4行目
| 誤 |
ここまでお話ししてきた～後略～ |
| 正 |
一方POSTメソッドでは、メッセージ・ボディにパラメータが含まれているために、ブックマークを使ったパラメータの保存はできません。ここまでお話ししてきた～後略～ |
|---|
P.115 図4-30
図中矢印の上から2番目
P.120 2行目
| 誤 |
いままでのCookieが無効となり |
| 正 |
※削除してください |
|---|
P.140
| 誤 |
SQLとは「Structured Query Language」の略で～ |
| 正 |
SQLとは、もともと「Structured Query Language」の略で、直訳するならば「問い合わせのための構造化言語」となります（ただし、SQLはその標準化の過程でなんらかの略称とは見なされなくなっています）。 |
|---|
P.140
| 誤 |
SELECT 商品ID, 商品名, ............. |
| 正 |
SELECT 商品 . 商品ID, 商品名, ............. |
|---|
P.140 脚注※10
| 誤 |
「OracleのPL/SQLやPL/pgSQL |
| 正 |
OracleのPL/SQLやPostgreSQLのPL/pgSQL |
|---|
P.148 コラム9行目
| 誤 |
Oracle Database 11g Express Edition |
| 正 |
Oracle Database 10g Express Edition |
|---|
P.148 コラム 最後から2行目
| 誤 |
しかし、いずれにせよ非営利団体、教育機関、個人で利用する範囲においては、無償で利用することができます。 |
| 正 |
しかし、GPLの条件に従って利用する範囲においては、無償で利用することができます。 |
|---|
P.173 リスト6-3 2行目
P.173 リスト6-3 23行目
P.219 脚注49
| 追加 |
なお、2010年6月にiBATISプロジェクトは活動を中止し、mybatisプロジェクト(http://www.mybatis.org/)に引き継がれました。 |
P.247 2行目
| 誤 |
暗号鍵が第三者に盗まれてしまえば、 |
| 正 |
暗号鍵が第三者に盗まれてしまうと、 |
|---|
P.247 図7-8 の下2行目
| 誤 |
公開鍵は盗まれても構わないので、メールで送っても問題ありません。 |
| 正 |
公開鍵は、それが確かにBobが生成したものであるということが保証される限り、第三者に見られても構いません。たとえ盗んでも復号化には利用できないためです。ここで、「保証される限り」という条件をつけましたが、それについてはあとで説明します。 |
|---|
P.248 1行目から11行目
補足説明追加
また、公開鍵暗号を使用するとメッセージの改ざんを防ぐことができます。さきほどの説明で、Bobが生成した公開鍵をAliceに送る際、第三者であるCarolが公開鍵を途中で盗み取って、その代わりに自分で作成した公開鍵をAliceに送ったとしたらどうなるでしょうか。Aliceにとっては受け取った公開鍵が本当にBobの生成したものかどうかを判別することができません。
このような改ざんを防ぐには、公開鍵と秘密鍵を逆に使い、デジタル証明を実現します。BobからAliceへメッセージを送信する際、そのメッセージを自分の秘密鍵で暗号化したものを同時に送信します（実際にはメッセージそのものを暗号化すると長くなってしまうため、251ページで説明するメッセージダイジェストを暗号化します）。Aliceは、すでに公開されているBobの公開鍵（ この公開鍵も、何らかの方法で確かにBobによるもであることが保証されなければなりません。このような保証を行う信頼できる第三者機関が認証局(Certification Authority、略してCA)です）を使って暗号化されたメッセージを復号化し、それが受け取ったメッセージと同じであるかどうかを確認します。Bobの公開鍵で正しく復号化できるメッセージを生成できるのは、その秘密鍵を持っているBob本人に他なりません。そのため、受け取ったメッセージはたしかにBobによるものだと信用できます。
この仕組みを利用すれば、Bobは暗号化用の公開鍵をCarolに改ざんされることなく、Aliceへ送ることができます。 |
P.250 図7-12右上吹き出し内
P.250 下から2行目
P.250 脚注1行目
P.250 脚注2行目
P.250 脚注
補足説明追加
| 追加 |
hiddenパラメータは正確には「type属性がhiddenであるinput要素」なのですが、開発現場では「hiddenタグ」と呼ばれてしまうことも多いです。 |
P.251 脚注21
| 誤 |
危険性が低いため～後略～ |
| 正 |
危険性が低いのですが、SHA-1よりもさらに衝突の危険性が低い「SHA-256」の利用が推奨されています。 |
|---|
P.253 コラム上から4行目
| 誤 |
そこで、パスワードの代わりに～後略～ |
| 正 |
そこで、パスワードの代わりにユーザ名とパスワードを結合した文字列のメッセージダイジェストを保存するようにします |
|---|
P.253 図7-16下の吹き出し
| 誤 |
パスワードのメッセージダイジェストを保存しておけば、盗まれてもパスワードが推測できない |
| 正 |
メッセージダイジェストを保存しておけば、盗まれてもパスワードが推測困難 |
|---|
P.253 図7-16下の表のヘッダ
P.253 図7-16下の吹き出し
| 誤 |
パスワードのメッセージダイジェストを保存しておけば |
| 正 |
メッセージダイジェストを保存しておけば |
|---|
P.253 コラム下から5行目
| 誤 |
推測することは事実上不可能です。 |
| 正 |
推測することが非常に困難になります。 |
|---|
P.253 コラム下から4行目
| 誤 |
ログイン画面で入力された～中略～計算し、 |
| 正 |
ログイン画面で入力されたユーザ名とパスワードを結合した文字列のメッセージダイジェストを計算し、 |
|---|
P.253 コラム最終行
補足説明追加
| 追加 |
なお、近年では「レインボークラック（Rainbow Crack）」と呼ばれる手法が発達し、パスワードのように文字数と文字種が限られているような場合には、メッセージダイジェストから元の文字列を短時間で推測できるようになってきました。そのため、パスワードだけでなくユーザ名までメッセージダイジェストの対象とすることで、元の文字列を見かけ上長くし、レインボークラックに対する耐性を高めることが推奨されています。また、ユーザIDのように本来の変換対象に追加する文字列を「ソルト（salt）」と呼んでいます。（レインボークラックについては「体系的に学ぶ安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」 [43]に詳しく説明されています） |
P.260 図7-19の左下吹き出し内
P.260 下から5行目
P.263 5行目(見出し)
| 誤 |
hiddenタグに重要な情報を持たせない |
| 正 |
hiddenパラメータ利用時の注意点 |
|---|
P.263 「hiddenタグに重要な～」の項の3行目以降
補足説明追加
| 追加 |
一方で、hiddenパラメータに格納された情報はWebブラウザからHTMLソースを表示させれば、簡単に覗くことができます。そのため、たとえばログイン中であるかどうかといったアプリケーション上の状態をhiddenパラメータに直接保持させると、利用者に容易に書き換えられてしまいます。このようなアプリケーション上の状態は、Lesson 4で紹介したセッションを利用してアプリケーションサーバ側で管理すべきです。
また、CSRF（248ページ参照）のような手段を使えば、第三者がhiddenパラメータの内容を好きなように書き換えてWebアプリケーションへ情報を送ることができるため、セキュリティホールになりがちです。
そのため、hiddenパラメータによって送信された情報を処理する場面では、そのリクエストが本当に利用者の意図したものであるかどうかを確認する必要があります。該当する場面としては決済処理、個人情報の更新処理、掲示板などへの書き込み処理といったものが挙げられます。
確認の方法としては、CSRFの対策で解説したワンタイムトークンを利用する方法が有効な方法の1つです。ワンタイムトークンは更新画面や決済画面を表示する際にサーバ側が発行するため、ワンタイムトークンがわからなければねつ造したhiddenパラメータを直接POSTしてアプリケーションに処理をさせることが困難になります。また、使い捨てで推測困難な文字列という特性上、仮に攻撃者がワンタイムトークンを盗んだとしても、連続した攻撃に利用することはできませんし、ワンタイムトークンをねつ造することも事実上困難です。 |
