正誤表

本書発売後に見つかった誤りおよび改善点に関する正誤表です。ご指摘頂いた読者の皆様に、この場を借りてお礼申し上げます。

次回増刷時に修正予定の箇所

※ 現時点ではありません

第6刷(2012年8月1日発行)での修正点 (修正箇所は第5刷に対するものです)

ページ	箇所	修正前	修正後
p47	ページ下部	右の注意書きを追加	■MacOSをご利用の方へ 本章で紹介している「横取り丸」および「InetSpy」はWindows用のアプリケーションであるため,MacOS環境では使用できません。代替手段として,Chrome（Google社の提供するWebブラウザ）に内蔵されているデベロッパーツールを利用する方法があります。詳細は本書のサポートサイト（http://www.littleforest.jp/webtext/）にて紹介していますので,そちらをご覧ください。
p79	表3-5 左下のセル	副作用	副作用が発生しないこと
p81	注釈43	Firefoxなど，ブラウザによっては	FirefoxやChromeなど，ブラウザによっては
p82	注釈46	(新規追加)	コンピュータにおける文字の取り扱いについては,長い歴史と複雑な経緯が絡んでおり,本書では最低限のことしか説明できません。文字コードについて,より深びたい方には,『プログラマのための文字コード技術入門』(矢野 啓介/技術評論社/2010)をお勧めします。
p165	コラム「表5-3」下から6行目	Aさんが作成した「α」というソフトウェア作成したとしましょう。	Aさんが「α」というソフトウェアを作成したとしましょう。
p166		GNUGeneral Public Licence	GNU General Public License
p171	4～6行目	「このページ・ディレクティブでは～伝えています。」を右のように差し替え	このページ・ディレクティブでは，JSPファイルが記述されている文字コード(pageEncoding)とHTMLとして出力するときの文字コード(charset)を，アプリケーションサーバに対して指定しています。
p274	Index(索引) G欄	GPL (GNU General Public Licence)...166	GPL (GNU General Public License)...166

第5刷(2011年12月10日発行)での修正点 (修正箇所は第4刷に対するものです)

ページ	箇所	修正前	修正後
p148	コラム a)4～5行目	Oracle Database 10g Express Edition(Oracle Database XE)	Oracle Database Express Edition 11g Release 2 (新バージョン公開にあわせて修正しました)
p148	脚注19	(URLの部分)	http://www.oracle.com/technetwork/database/express-edition/overview/index.html (新バージョン公開にあわせて修正しました)
p148	コラム b)5行目	SQL Server 2008 Express Edition	SQL Server 2008 R2 Express Edition (新バージョン公開にあわせて修正しました)
p165	-	「コラム：オープンソースのライセンス」を追加。	コラム：オープンソースのライセンス 上のコラムでは、オープンソースの概要について説明しました。多くのオープンソースは無償で利用可能ですが、 そこには一定の制限があり、利用者はその制限の範囲内で利用することが求められます。 この制限を「ライセンス(License)」と呼びます。 オープンソースのライセンスにはさまざまなものがありますが、大きく3つのカテゴリに分かれます*46。 カテゴリ 代表的なライセンス コピーレフト型 GPL 準コピーレフト型 LGPL, MPL 非コピーレフト型 BSD, Apache License ここで、コピーレフトについて説明しましょう。一般に書籍、音楽、絵画、映画、写真などの創作物と同様に、 ソフトウェアに対してもその創作者に著作権（Copyright）が発生し、著作物を一定の支配下に置くことができます。 一方、オープンソースは「ソフトウェアは人類の共通財産である」という理念に基づいているため、 著作権の考え方と相いれません。そこで、リチャード・ストールマンによって「コピーレフト（Copyleft）*47 」 と呼ばれる概念が提唱されました。コピーレフトは、著作者が著作権を保有したままで著作物、 つまりソフトウェアの複写・再配布・改変の自由を利用者に与えます。たとえば、Aさんが「α」 というソフトウェアを作成したとしましょう。「α」の著作権はAさんが保有します。 Aさんがソフトウェア「α」をコピーレフトに基づくライセンスによって公開した場合、 以下のようなことが実現されます。 誰もが「α」を利用することができる（複写可能） 誰もが「α」を別の人に配布することができる（再配布可能） 誰もが「α」のソースコードを改変したソフトウェア（「派生物」といいます）を作成できる（改変可能） ここで重要なのは、これらの複写・再配布・改変された「α」のいずれにも「コピーレフト」の概念が適用されることです。 たとえば、Bさんが「α」の一部を改変して「β」というソフトウェアを作成した場合、「β」には「α」 のもつコピーレフトが適用されます。このようにすることで、ソフトウェアの自由な利用を義務づけるのがコピーレフトの考え方です。 このコピーレフトの考え方をもっとも厳格に実現しているライセンスが「GPL（GNU General Public Licence）」です。 GPLではソースコードの開示を義務づけ、コピーレフトに従って派生物にもソースコード開示が義務づけられます。 代表的なオープンソースOSであるLinuxや、コンパイラのGCCといったものがGPLで公開されています。 また、データベースのMySQLもGPLまたは商用ライセンスのいずれかを選択する方式となっています。 一方で、現実には企業などがオープンソースのライブラリを改変はしないものの一部に取り込んで利用したソフトウェアを開発したい場合、 GPLライセンスではソースコードすべてを公開する義務が生じてしまいます。そこで、元のソースコードを改変しないで利用する限り、 独自に開発したソースコードの開示をしなくて済むように条件を緩めたものが、「準コピーレフト型」と呼ばれるライセンスです。 代表的なものに「LGPL(GNU Lesser General Public License)」が挙げられます。 また、ブラウザのFireFoxが採用している「MPL(Mozilla Public License)」もこの形態のひとつです。 これらコピーレフトに基づくライセンスは、ソースコード開示の義務が発生するという点でソフトウェアの商用利用に影響を及ぼします。 そこで商用利用を推進するために、新たに作成した部分だけでなく改変部分のソースコード開示も不要としているものもあります。 「非コピーレフト型」と呼ばれるライセンスで、「BSD License（Berkeley Software Distribution License）」 や「Apache License」がその代表格です。本書で紹介している中では、PostgreSQLのライセンスが BSD Licenseの派生系であり、Apache HTTP ServerやTomcat、StrutsがApache Licenseで公開されています。 オープンソースソフトウェアを使用するにあたっては、そのライセンスがどのようなものであるかについても、 注意深く確認する必要があります。
p165	脚注44	ただし、OSSだからといって必ずしも無償で利用できるわけではなく、各製品のライセンスに従わなければなりません。たとえば、148ページで紹介したMySQLは～	(MySQLのライセンスについては新規に追加したコラムのなかで説明するようにしたため、削除)
p165	脚注45	(新規追加)	電子商取引の形態の1つ。Business to Consumerの略で、企業と一般消費者の間の取引を指します。インターネットショッピングなどがBtoCの代表例です。
p165	脚注46	(新規追加)	この分類は、IPA(情報処理推進機構)が公開している『OSSライセンスの比較、利用動向および係争に関する調査』(http://ossipedia.ipa.go.jp/doc/203/)に基づいています。
p165	脚注47	(新規追加)	これは著作権を意味するCopyrightと真逆を意図することから、ユーモアを交えてもじったものです。
p182	1行目～10行目	右の文章に差し替え。(赤字部分が追加部分)	一方、セッションスコープは複数のリクエストにまたがって有効なので、ログイン状態やショッピングカートに保存した購入商品など、 ユーザがWebアプリケーションを使用している間に保持しておきたい情報を格納するのに適しています。 本来、ステートレスなプロトコルであるHTTPの上で「セッション」という状態を管理する仕組みを実現しているのはアプリケーションサーバやPHPの実行エンジンです。 しかし、セッションスコープに伴うセッション自体の開始と終了はWebアプリケーション側で制御する必要があり、 終了させるのを忘れるとタイムアウトまでセッションが残ってしまうという欠点がありました。 そして、Webアプリケーションではユーザにログアウトを強制することができないため、 状況によってはどうしてもタイムアウトを待たざるを得ないということも理解しておく必要があります。
p270	参考文献[2]	[2] 『オブジェクト指向でなぜつくるのか ―知っておきたいプログラミング、UML、設計の基礎知識―』 平澤 章/日経BP社/2004	[2] 『オブジェクト指向でなぜつくるのか 第2版 知っておきたいOOP、設計、関数型言語の基礎知識』 平澤 章/日経BP社/2011 (第2版刊行に併せて修正しました)
p274	Index(索引) B欄	(新規追加)	BSD License(Berkeley Software Distribution License)...166
p274	Index(索引) G欄	(新規追加)	GPL (GNU General Public Licence)...166
p276	Index(索引) ら欄	(新規追加)	ライセンス(License)...165

第4刷(2011年8月10日発行)での修正点 (修正箇所は第3刷に対するものです)

ページ	箇所	誤	正
p120	2行目	今までのCookieが無効となり	(削除)
p123	下から2行目	Digest認証使用したり	Digest認証を使用したり
p160	「c)データベース接続の管理」の2行目	データベースへアクセスる際は	データベースへアクセスする際は
p78	「GETとPOSTどちらを使えばよい?」3～4行目	「しかし，GET リクエストによるパラメータ渡しにも，ちゃんとメリットはあるのです。」を右の文章に置き換え	しかし、GETリクエストとPOSTリクエストには大きな違いがあります。
p79	1行目～3行目	「このように～使い方はできません。」を下の文章に前差し替え	このように、GETメソッドではURLにパラメータが含まれるため、パラメータごと記憶したり、人に伝えたりするのに便利です。また、そのようなことを可能にするためには、GETリクエストの結果がシステムの状態に影響を与えないようになっていることが重要です。たとえば、ある一時点でgoogleに何度同じ検索キーワードを入力しても結果は変わらないはずです。このように同じ要求をを何度繰り返しても同じ結果が得られることを「副作用がない」といいます。HTTPについて規定したRFC2616（28ページコラム参照）でも、GETリクエストには副作用が無いことが期待される旨、記述されています。 一方POSTメソッドでは、メッセージ・ボディにパラメータが含まれているために、ブックマークを使ったパラメータの保存はできません。
p79	表3-5	表の最後に以下の表を追加	副作用 期待される 期待されない
p79	表3-5 次の文	「たいていの場合は～ということになります。」までの3行を右の文章に置き換え	GETリクエストとPOSTリクエストの使い分けをまとめましょう。ログイン処理のようにユーザ名やパスワードといった機密情報を送信する場合や、決済処理などの副作用を伴う処理、クエリ文字列に収まりきらない大量の情報を送信する必要がある場合は、POSTメソッドを使用すべきです。 前述の条件にあてはまらず、副作用がない処理ではGETリクエストを利用した方がパラメータごと保存できるというメリットを活かすことができます。
p219	脚注49	右の内容に置き換え	なお、2010年6月にiBATISプロジェクトは活動を中止し、mybatisプロジェクト(http://www.mybatis.org/)に引き継がれました。
p250	図7-12 右上吹き出し内	hiddenタグ	hiddemパラメータ
p250	下から2行目	hiddenタグ	hiddemパラメータ
p250	脚注20 1行目、2行目	hiddenタグ	hiddemパラメータ
p250	脚注20	最後に右の文を追加	hiddenパラメータは正確には「type属性がhiddenであるinput要素」なのですが、開発現場では「hiddenタグ」と呼ばれてしまうことも多いです。
p251	脚注21	最後の「危険性が低いため～」以降を右の文に変更	危険性が低いのですが、SHA-1よりもさらに衝突の危険性が低い「SHA-256」の利用が推奨されています。
p253	コラム上から4行目	「そこで、パスワードの代わりに～」以降を右の文に変更	そこで、パスワードの代わりにユーザ名とパスワードを結合した文字列のメッセージダイジェストを保存するようにするのです(図7-16)
p253	図7-16 下の吹き出し	パスワードのメッセージダイジェストを保存しておけば、盗まれてもパスワードが推測できない	メッセージダイジェストを保存しておけば、盗まれてもパスワードが推測困難
p253	コラム下から5行目	推測することは事実上不可能です。	推測することが非常に困難になります。
p253	コラム下から5行目	これも簡単です。	(削除)
p253	コラム最終行	右の文を追加	なお、近年では「レインボークラック（Rainbow Crack）」と呼ばれる手法が発達し、パスワードのように文字数と文字種が限られているような場合には、メッセージダイジェストから元の文字列を短時間で推測できるようになってきました。そのため、パスワードだけでなくユーザ名までメッセージダイジェストの対象とすることで、元の文字列を見かけ上長くし、レインボークラックに対する耐性を高めることが推奨されています。また、ユーザIDのように本来の変換対象に追加する文字列を「ソルト（salt）」と呼んでいます。（レインボークラックについては「体系的に学ぶ安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」 [43]に詳しく説明されています）
p260	図7-19 左下吹き出し内	hiddenタグ	hiddenパラメータ
p263	5行目(見出し)	hiddenタグに重要な情報を持たせない	hiddenパラメータ利用時の注意点
p263	8～19行目	「しかし、hiddenタグ～事実上困難です。」を右の文に差し替え	一方で、hiddenパラメータに格納された情報はWebブラウザからHTMLソースを表示させれば、簡単に覗くことができます。そのため、たとえばログイン中であるかどうかといったアプリケーション上の状態をhiddenパラメータに直接保持させると、利用者に容易に書き換えられてしまいます。このようなアプリケーション上の状態は、Lesson 4で紹介したセッションを利用してアプリケーションサーバ側で管理すべきです。 また、CSRF（248ページ参照）のような手段を使えば、第三者がhiddenパラメータの内容を好きなように書き換えてWebアプリケーションへ情報を送ることができるため、セキュリティホールになりがちです。 そのため、hiddenパラメータによって送信された情報を処理する場面では、そのリクエストが本当に利用者の意図したものであるかどうかを確認する必要があります。該当する場面としては決済処理、個人情報の更新処理、掲示板などへの書き込み処理といったものが挙げられます。 確認の方法としては、CSRFの対策で解説したワンタイムトークンを利用する方法が有効な方法の1つです。ワンタイムトークンは更新画面や決済画面を表示する際にサーバ側が発行するため、ワンタイムトークンがわからなければねつ造したhiddenパラメータを直接POSTしてアプリケーションに処理をさせることが困難になります。また、使い捨てで推測困難な文字列という特性上、仮に攻撃者がワンタイムトークンを盗んだとしても、連続した攻撃に利用することはできませんし、ワンタイムトークンをねつ造することも事実上困難です。
p266	この章で学んだこと 下から3行目	hiddenタグ	hiddenパラメータ
p273	参考文献 [43]	右の文献を追加	[43] 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 徳丸 浩／ソフトバンククリエイティブ／2011
p274	Index(索引) H欄	hiddenタグ	hiddenパラメータ
p275	Index(索引) そ欄	右の索引を追加	ソルト(salt) ... 253
p276	Index(索引) ふ欄	右の索引を追加	副作用 ... 79
p276	Index(索引) れ欄	右の索引を追加	レインボークラック(Rainbow Crack) ... 253

第3刷(2011年4月1日発行)での修正点 (修正箇所は第2刷に対するものです)

ページ	箇所	誤	正
p119	3行目	新しくWebブラウザを起動して，	メニューから [ファイル] - [新規セッション] を選択して新しいブラウザを起動し(Internet Exploler 8 以降での方法です。他のブラウザについては，次ページの脚注をご覧ください)
p120	1行目	ブラウザを新しく起動したことで	ブラウザが異なるセッションで起動されたことで Cookie の管理も別となり，
p120	脚注*34	(以下に全文差し替え)	ブラウザ側における Cookie の管理方法については仕様として明示されているわけではありません。しかし近年のタブ型ブラウザでは，同じPC上でタブやウィンドウを複数表示しても Cookie (つまりセッション)は共有されるという振る舞いに統一されつつあります。ただし，Internet Exploler 7 以前のバージョンでは，ブラウザのメニューから [ファイル] - [新規作成] - [ウィンドウ] (または Ctrl + N キー)で新しいウィンドウを開かない限り，異なるセッションとなります。一方 Firefox や Chrome では，同一 PC上では必ず同じセッションとなるため，前ページの実験は異なる PC から行う必要があります。
p140	図5-14	SELECT 商品ID,商品名,SUM(品数) AS 合計	SELECT 商品.商品ID,商品名,SUM(品数) AS 合計

第2刷(2010年11月25日発行)での修正点 (修正箇所は第1刷に対するものです)

ページ	箇所	誤	正
p21	下から4行目	「レスポンス(responce)」	「レスポンス(response)」
p115	図4-30 (図中矢印の上から2番目)	「セクションID」	「セッションID」
p140	2行目	SQLとは「Structured Query Language」の略で～	SQLとはもともと「Structured Query Language」の略で，直訳するならば「問い合わせのための構造化言語」となります。要するに，データベースに対して欲しい情報を効率よく伝えるための言語です。(ただし，SQLはその標準化の過程でなんらかの略称とは見なされなくなっています)。
p140	脚注*10	OracleのPL/SQLやPL/pgSQL	OracleのPL/SQLやPostgreSQLのPL/pgSQL
p148	コラム 9行目	Oracle Database 11g Express Edition	Oracle Database 10g Express Edition
p148	コラム 最後から2行目	しかし，いずれにせよ非営利団体，教育機関，個人で利用する範囲においては，無償で利用することができます。	しかし，GPLの条件に従って利用する範囲においては，無償で利用することができます。
p173	リスト6-3 2行目	responce	response
p173	リスト6-3 23行目	responce	response
p247	2行目	暗号鍵が第三者に盗まれてしまえば，	暗号鍵が第三者に盗まれてしまうと，
p247	図7-8 の下2行目	公開鍵は盗まれても構わないので，メールで送っても問題ありません。	公開鍵は，それが確かにBobが生成したものであるということが保証される限り，第三者に見られても構いません。たとえ盗んでも復号化には利用できないためです。ここで，「保証される限り」という条件をつけましたが，それについてはあとで説明します。
p248	1行目から11行目	また，公開鍵暗号を使用するとメッセージの偽造を防ぐことができます。インターネットの世界では，送信者を偽って情報を送ることができます。たとえば，第三者であるCarolがBobの名前をかたってAliceへメッセージを送信したとしましょう。Aliceはどうすれば送られてきたメッセージがBobものではないと見破ることができるでしょうか。このような詐称を防ぐには，公開鍵と秘密鍵を逆に使って，自己証明を行います。Bobは自己証明用の公開鍵と秘密鍵のペアを作成しておき，秘密鍵の方をAliceへ渡しておきます。BobのがAliceへメッセージを送信するときには，自己証明用の公開鍵でメッセージを暗号化してから送信します。Aliceは，事前に受け取ったBobの秘密鍵を使って受け取ったメッセージを復号します。ここで復号できるのは，Bobの公開鍵で暗号化されたメッセージだけですから，正しく復号できればまちがいなくBobのメッセージであることがわかります。この仕組みを使えば，暗号化用の公開鍵をCarolに詐称されることなくAliceへ送ることができます。	また，公開鍵暗号を使用するとメッセージの改ざんを防ぐことができます。さきほどの説明で，Bobが生成した公開鍵をAliceに送る際，第三者であるCarolが公開鍵を途中で盗み取って，その代わりに自分で作成した公開鍵をAliceに送ったとしたらどうなるでしょうか。Aliceにとっては受け取った公開鍵が本当にBobの生成したものかどうかを判別することができません。 このような改ざんを防ぐには，公開鍵と秘密鍵を逆に使い，デジタル証明を実現します。BobからAliceへメッセージを送信する際，そのメッセージを自分の秘密鍵で暗号化したものを同時に送信します(実際にはメッセージそのものを暗号化すると長くなってしまうため，251ページで説明するメッセージダイジェストを暗号化します)。Aliceは，すでに公開されているBobの公開鍵(この公開鍵も，何らかの方法で確かにBobによるもであることが保証されなければなりません。このような保証を行う信頼できる第三者機関が認証局(Certification Authority，略してCA)です)を使って暗号化されたメッセージを復号化し，それが受け取ったメッセージと同じであるかどうかを確認します。Bobの公開鍵で正しく復号化できるメッセージを生成できるのは，その秘密鍵を持っているBob本人に他なりません。そのため，受け取ったメッセージはたしかにBobによるものだと信用できます。 この仕組みを利用すれば，Bobは暗号化用の公開鍵をCarolに改ざんされることなく，Aliceへ送ることができます。
p274			Indexに「CA(Certification Authority)・・・p248」を追加
p274			Indexに「デジタル証明・・・p248」を追加
p274			Indexに「認証局・・・p248」を追加
p276		レスポンス(responce)	レスポンス(response)