書籍概要

プロになるための

『プロになるためのWeb技術入門』
――なぜ,あなたはWebシステムを開発できないのか

著者
発売日
更新日

概要

2010年に発売された『プロになるためのWeb技術入門』が電子版になりました。

『なぜあなたはJavaでオブジェクト指向開発できないのか』の著者である小森祐介氏の新刊です。Webアプリケーションの開発方法を,インターネットの仕組みの根本原理から,じっくり解説します。Webアプリケーションとは何か?――という根本的な問いかけから始まり,基礎の基礎をかためつつ,本物の実力を養成することを目標に内容を構成しています。これにより一貫した流れでWebアプリケーション開発の真髄を学ぶことができます。図解をたくさん用意しましたので,これで直感的に楽しく理解も進むようになっています。

こんな方におすすめ

  • Webアプリケーションの基礎の基礎を学びたい方
  • Webのしくみを根本的に知りたい方

サンプル

目次

LESSON 0 はじめに

  • 市民権を得た「Webアプリケーション」
  • 「Webアプリケーション」開発の難しさ
  • 「Webアプリケーション」の開発技術はどこで学べる?
  • なぜ,あなたはWebアプリケーション開発技術を学べないのか
  • 本書の対象読者
  • 本書を読む上での想定知識
  • 最も効率よく「技術」を学ぶ方法

LESSON 1 「Webアプリケーション」とは何か

  • 1.1 デスクトップアプリケーション
  • 1.2 Webアプリケーション
  • 1.3 まとめ

LESSON 2 Webはどのように発展したか

2.1 WWWの誕生と普及

  • 世界中のコンピュータを結ぶインターネット
  • インターネット普及の立役者・World-Wide WebとMosaic
  • WWWの誕生
  • 現代Webブラウザの祖先・NCSA Mosaic

2.2 Webを支える技術の発明

  • WebサーバとWebクライアント
  • なぜ,クライアントとサーバに分けるのか
  • コラム 「クライアント」と「サーバ」偉いのはどっち?
  • 「そのリソースはどこにある?」- URL
  • HTTP
  • コラム インターネットに公開された技術仕様・RFC

2.3 CGIの誕生

  • 動的なコンテンツへの要求
  • CGIの誕生
  • Webの爆発的な普及

2.4 サーブレットの登場

  • CGIにまつわる問題点
  • Java/サーブレットの誕生
  • Javaでアプリケーションを開発することの利点
  • コラム 早すぎた技術,Javaアプレット

2.5 JSPの誕生

  • サーブレットの問題点
  • 発想の逆転!JSPの誕生

2.6 Webアプリケーションフレームワークの時代

  • サーブレットやJSPの問題点
  • Webアプリケーションフレームワークの誕生

2.7 まとめ

LESSON 3 HTTPを知る

3.1 HTTPの知識はなぜ必要か

  • コラム ハードウェアさえも信じられない事態!?

3.2 WebブラウザとWebサーバの通信をのぞいてみよう

  • 横取り丸とInetSpyのインストール
  • HTTP通信をのぞいてみよう
  • HTTPリクエストをのぞく
  • コラム URL とURI は何が違うのか?
  • HTTPレスポンスをのぞく
  • HTTPでは1回で1つのリソースを取得
  • ファイル名を省略した場合のリクエスト

3.3 情報はどうやってインターネットの大海原を越えるのか

  • インターネット上の住所・IPアドレス
  • IPアドレスを頼りに情報を届けるTCP/IP
  • IPアドレスは誰が決めるのか
  • グローバルIPアドレスとプライベートIPアドレス
  • コラム IPアドレスと個人情報
  • ホスト名をIPアドレスに変換するDNS
  • DNSはどのようにして実現されるのか
  • ホスト内の宛先を決定するポート番号

3.4 Webサーバへの要求をどのように伝えるか

  • GETメソッドによるパラメータ渡し
  • アプリケーション側でのパラメータの受け取り
  • POSTメソッドによるパラメータ渡し
  • GETとPOSTどちらを使えばよい?
  • 日本語はどのようにして渡せばよいか

3.5 まとめ

LESSON 4 CGIからWebアプリケーションへ

4.1 宅配ピザ注文サイトを作ろう

4.2 画面構成を考える

  • コラム 実際のWebシステム開発の流れ
  • 4.3 画面モックを作ろう

    4.4 ログイン認証機能を作成する

  • PHPで認証機能を作ろう
  • 認証機能の動作を確認しよう
  • リダイレクト動作のHTTP通信を確認しよう
  • コラム PHPはどのように実行されるのか?CGIとモジュールの違い?

4.5 ログイン状態をどのようにして記憶するのか

  • ステートフルなプロトコルとステートレスなプロトコル
  • ステートレスなHTTP上で状態をどのように表現するか
  • Cookieを利用して状態を保持する
  • Cookie利用の実際を確認する

4.6 安全に状態を保存するための技術 ?セッション?

  • Cookieにまつわる問題点
  • コラム Cookieはどこに保存されている?
  • 銀行の窓口業務でセッションを理解しよう
  • 口座開設業務の進行状況をどのように管理するか
  • セッションで処理の進行状況を管理する
  • セッションの状態をどこで保持するか
  • HTTPにおけるセッションIDの受け渡し方法
  • セッションID利用の実際を確認する
  • セッションIDによるユーザの識別

4.7 ピザ・ペントミノの完成

  • コラム Webサーバによる認証機能 ?Basic認証?

4.8 まとめ

LESSON 5 Webアプリケーションの構成要素

  • なぜWebアプリケーションの構成を理解しなければならないのか
  • コラム コンピュータは「節」?

5.1 WebサーバとWebクライアントの時代

  • WWWの黎明期
  • CGIの時代
  • コラム ソフトウェア? プログラム? アプリケーション? サーバ?

5.2 データベースサーバの登場

  • 大量の情報をどのようにして管理するか
  • データベース管理システムの登場
  • コラム DB?  DBMS? RDBMS?
  • データベースに対する操作
  • データベースによる情報の管理
  • コラム データベース設計はITシステムの要
  • データベースから情報を抽出する
  • 必要な情報をSQLでデータベースへ伝える
  • コラム データベースに対するCRUD操作とSQL文の関係
  • データベースとクライアントの関係
  • データベースサーバの分離
  • Webアプリケーションとデータベースの通信
  • コラム 代表的なデータベース製品

5.3 アプリケーションサーバの登場

  • ServletやJSPはどこで動いているのか
  • Servlet / JSPを動かすためのアプリケーションサーバ
  • Webサーバとアプリケーションサーバの連携
  • Webサーバとアプリケーションサーバの分担
  • Webサーバとアプリケーションサーバ連携のメリット
  • 複数のTomcatへの転送
  • Webサーバの機能を持ったアプリケーションサーバ
  • コラム アプリケーションサーバの提供する機能

5.4 Webシステムの三層構成

  • 最小構成のWebシステム
  • 一般的な構成
  • Webシステムの三層構成
  • コラム 現代のWebシステムを支えるオープンソース

5.5 まとめ

LESSON 6 Webアプリケーションを効率よく開発するための仕組み

6.1 サーブレット/JSPだけではいけないのか

  • Webアプリケーション開発のスタンダード・Java
  • サーブレットとJSPの連携

6.2 サーブレット/JSPで「ピザ・ペントミノ」のログイン処理を実現する

  • JSPによるログイン画面の表示
  • サーブレットの呼び出し
  • ログインサーブレットの処理
  • フォワードとリダイレクトの違い
  • リクエストスコープにおける情報の受け渡し
  • JSPにおけるリクエストスコープからの情報の取り出し
  • なぜリクエストスコープが必要なのか
  • セッションスコープとリクエストスコープの違い
  • コラム さまざまなセッションの実現方法

6.3 Webアプリケーションのアーキテクチャ

  • ロジックとデザインの分離
  • ソフトウェアの建築様式
  • コラム カスタムタグとJSTL
  • 「ピザ・ペントミノ」の構造を俯瞰しよう
  • MVCモデルによるWebアプリケーションのアーキテクチャ
  • MVCモデルによる処理の流れ

6.4 フレームワークによるアーキテクチャの実現

  • フレームワークとは何か
  • StrutsによるMVCモデルの実現
  • Strutsによる「ピザ・ペントミノ」のログイン処理
  • JSPからのログイン処理アクションの呼び出し
  • コラム Javaを部品化するための仕組み - Java Beans -
  • ログイン処理アクションでのログインチェック処理
  • 商品一覧画面への遷移

6.5 レイヤパターンによるデータアクセス層の分離

  • モデルをどのように実現するか
  • JDBCによるデータベースからの情報の取得
  • レイヤパターンによるデータアクセス層の分離
  • DAOパターンによるデータアクセス層の実現

6.6 O/Rマッピングフレームワークによるデータアクセス層の実現

  • O/Rマッピングフレームワークの必要性
  • RDBとオブジェクトのインピーダンス・ミスマッチ
  • iBATISによるO/Rマッピングの実際
  • Data MapperとSQLマップファイルによるO/Rマッピング処理
  • Dao Frameworkを利用したDAOの作成

6.7 フレームワーク利用におけるメリットとデメリット

  • フレームワーク利用のメリット
  • フレームワーク利用のデメリット

6.8 まとめ

LESSON 7 セキュリティを確保するための仕組み

7.1 なぜセキュリティを確保しなければならないのか

  • Webアプリケーションが守るべきセキュリティ

7.2 代表的なWebアプリケーションの攻撃手法とその対策

  • SQLインジェクション
  • クロスサイトスクリプティング(XSS)
  • セッションハイジャック
  • コラム SSLによる通信路の暗号化
  • クロスサイトリクエストフォージェリ
  • コラム セキュリティの陰の立役者・ハッシュ関数
  • 強制ブラウズ
  • ディレクトリトラバーサル
  • コラム より安全な認証方式?Digest認証?

7.3 設計・実装ミスに起因する誤動作やセキュリティ問題を防ぐための対策

  • 「戻る」ボタン対策
  • ダブルサブミット対策
  • hiddenタグに重要な情報を持たせない
  • デバッグ情報を出力させない
  • グローバル変数に情報を持たせない

7.4 まとめ

  • 謝辞

LESSON 8 おわりに

LESSON 9 付録

9.1  参考書籍・サイト

  • Lesson 0
  • Lesson 2
  • Lesson 3
  • Lesson 4
  • Lesson 5
  • Lesson 6
  • Lesson 7

サポート

ダウンロード

本サンプルソースコードは,あくまでも本書の理解をすすめるためのものです。本アーカイブに含まれるプログラムの使用により生じたいかなる損害に対しても,技術評論社および著者はいっさいの責任および損害に対する責務は負いません。あくまでも自己責任のもとでのご使用をお願いいたします。あらかじめご承知おきください。

ダウンロード後,ファイル解凍ツールで適宜解凍しご利用ください。なお,商用利用は一切禁止します。

また,執筆者の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番目

「セクションID」
セッションID」

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行目

responce
response

P.173 リスト6-3 23行目

responce
response

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右上吹き出し内

hiddenタグ
hiddenパラメータ

P.250 下から2行目

hiddenタグ
hiddenパラメータ

P.250 脚注1行目

hiddenタグ
hiddenパラメータ

P.250 脚注2行目

hiddenタグ
hiddenパラメータ

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の左下吹き出し内

hiddenタグ
hiddenパラメータ

P.260 下から5行目

hiddenタグ
hiddenパラメータ

P.263 5行目(見出し)

hiddenタグに重要な情報を持たせない
hiddenパラメータ利用時の注意点

P.263 「hiddenタグに重要な~」の項の3行目以降

補足説明追加

追加 一方で、hiddenパラメータに格納された情報はWebブラウザからHTMLソースを表示させれば、簡単に覗くことができます。そのため、たとえばログイン中であるかどうかといったアプリケーション上の状態をhiddenパラメータに直接保持させると、利用者に容易に書き換えられてしまいます。このようなアプリケーション上の状態は、Lesson 4で紹介したセッションを利用してアプリケーションサーバ側で管理すべきです。
また、CSRF(248ページ参照)のような手段を使えば、第三者がhiddenパラメータの内容を好きなように書き換えてWebアプリケーションへ情報を送ることができるため、セキュリティホールになりがちです。
そのため、hiddenパラメータによって送信された情報を処理する場面では、そのリクエストが本当に利用者の意図したものであるかどうかを確認する必要があります。該当する場面としては決済処理、個人情報の更新処理、掲示板などへの書き込み処理といったものが挙げられます。
確認の方法としては、CSRFの対策で解説したワンタイムトークンを利用する方法が有効な方法の1つです。ワンタイムトークンは更新画面や決済画面を表示する際にサーバ側が発行するため、ワンタイムトークンがわからなければねつ造したhiddenパラメータを直接POSTしてアプリケーションに処理をさせることが困難になります。また、使い捨てで推測困難な文字列という特性上、仮に攻撃者がワンタイムトークンを盗んだとしても、連続した攻撃に利用することはできませんし、ワンタイムトークンをねつ造することも事実上困難です。

商品一覧