「プロになるためのWeb技術入門」の要点整理

web
2023.12.06

技術書を読んでブログで定期的（できたら毎週💦）アウトプットすることを目標にしております🏃

今回は第１弾として、プロになるためのWeb技術入門を読んで、重要だと感じたことや、本をきっかけに自分で調べたことをまとめてみました💡

実務未経験者の学習内容アウトプットですので、おかしな点等あればご指摘いただけますと幸いです🙇‍♂️

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

Webにおけるクライアントとサーバの役割分担

  • 「クライアント」と「サーバ」はコンピュータやその上で動作するソフトウェアを指し、「client（お客様）」と「server（仕える人）」というそのままの意味の英語が語源
  • WWWでは、Webサーバがネット上に公開するHTMLを蓄積し、Webクライアントの要求に従って必要なHTMLを渡す仕組み
  • クライアントからサーバに対する要求を「リクエスト」、サーバからクライアントに対する応答を「レスポンス」と呼ぶ

URLの役割と構造

  • URL (Uniform Resource Locator) は、インターネット上のコンテンツ（リソース）を特定するための仕組み
  • 構造（例：http://www.littleforest.jp/webtext/index.htmlの場合）
    大きく分けて、スキーム名（http）、ホスト名（www.littleforest.jp）、パス名（webtext/index.html）の３つの部分で構成される
  • スキームはリソースを取得するための方法、ホスト名はリソースが存在するコンピュータ名、パス名はホスト名で指定されたコンピュータ上のリソースの位置を表す

HTTPの役割

  • クライアントとサーバ間で通信を行う際に、どのように情報をやりとりするかという取り決め（通信プロトコル）が必要。
  • HTTP (Hypertext Transfer Protocol) は、通信プロトコルの一つ

Webアプリケーションフレームワークの必要性

  • Webアプリケーションフレームワークは、開発者が効率的にアプリケーションを構築できるように作られたライブラリ（プログラム部品）の集合
  • 大規模アプリケーションをゼロから構築すると、コーディング量が莫大となり、完成までに多くの時間とお金がかかるが、フレームワークを利用することで、短期間でアプリを開発可能

Lesson3　HTTPを知る

HTTPリクエストの構造

リクエストライン

  • 例：GET http://www.littleforest.jp/webtext/index.html HTTP/1.1
  • リクエストの種類を表すメソッド（GET）、リクエスト対象のURI（http://www.littleforest.jp/webtext/index.html）、使用しているHTTPのバージョン（HTTP/1.1）を含む行

メッセージ・ヘッダ

  • リクエストに関する追加情報を含む
  • ユーザーエージェントや受け入れ可能なコンテンツタイプなどを指定
    （例）
    • Accept: */*
    • Host: www.littleforest.jp
    • User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
    • Accept-Language: ja-JP
Accept
  • Webクライアントが受け取ることのできるデータの種類（テキストファイルや画像等）を表したもの
  • 例の「*/*」は任意の情報を受け取れることを表す
Host
  • リクエストの送信先ホスト名やポート番号を指定
User-Agent
  • 利用しているWebブラウザの種類やバージョンを示す
  • Webサーバがアクセスしてきたクライアントの種類に応じて適切なコンテンツを返すために利用される
Accept-Language
  • Webクライアントが受け取ることのできる自然言語（人間が使用する言語）の種類を表す
  • 例の「ja-JP」は日本語であることを示す

HTTPレスポンスの構造

ステータス・ライン

  • 例：HTTP/1.1 200 OK
  • 使用しているプロトコルのバージョンを示すHTTPバージョン（HTTP/1.1）、リクエストが成功したかどうかが分かるステータスコード（200）、ステータスコードの意味を人間が見てすぐに分かるように説明するレスポンス・フレーズ（OK）で構成される

メッセージ・ヘッダ

  • HTTPリクエストのメッセージ・ヘッダと同じ形式

メッセージ・ボディ

  • HTMLコンテンツ、画像データ、JSON形式のデータなど、実際のリソースデータやメッセージが含まれる

IPアドレス、TCP/IP

  • IPアドレスは、インターネット上の各デバイスを識別するユニークなアドレス
  • IPアドレスが分かると宛先のホストが特定でき、そのホストへ任意の情報を届けることができる
    インターネットの世界でその役割を担うのが「TCP/IP」と呼ばれるプロトコル
  • TCP/IPはブラウザから受け取ったHTTPリクエスト等の情報をパケットと呼ばれる小さな単位に分割して送信し、受け取った側でそれらを元のように組み立ててから受け手となるWebサーバなどのアプリケーションへ渡している

DNS

  • ドメイン名とIPアドレスの対応表を持ったDNSサーバをインターネット上に配置しておき、DNSサーバへ問い合わせればドメイン名に対応するIPアドレスを教えてもらえるという仕組み

GETリクエストとPOSTリクエストの違い

  • GETリクエストはデータ取得に使用され、POSTリクエストはデータをサーバに送信するために使用される
  • GETリクエストはURLにパラメータを含むが、POSTリクエストはメッセージ・ボディを利用してパラメータを渡す

パーセントエンコーディングによる表現

  • URLで利用できる文字には制限があり、日本語は許可されていない
  • パーセントエンコーディングとは、日本語のように許可されていない文字を「%」に続く2桁の16進数で表現すること

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

リダイレクトの仕組み

  • リダイレクトは、ウェブサーバがクライアント（ブラウザ）に特定のURLから別のURLへ移動するよう指示するプロセス
  • 実現方法：HTTPレスポンスでステータスコード（例えば、301, 302, 307, 308）を使用し、Location ヘッダに新しいURLを指定する。

ステートフルなプロトコルとステートレスなプロトコルの違い

ステートフルプロトコル

  • ステートフルプロトコルでは、クライアントとサーバー間の通信は「状態」を持つ
  • サーバーが過去のリクエストと応答を「記憶」している
  • サーバーはクライアントごとに状態情報（ログイン状態、過去のリクエスト履歴など）を保持する
  • 例：FTP（ファイル転送プロトコル）
    クライアントがログインしてファイル操作を行う間、サーバーはそのセッション情報を保持する

ステートレスプロトコル

  • ステートレスプロトコルでは、各リクエストは独立しており、サーバーは過去のリクエストと応答を「記憶」しない
  • 各リクエストは自己完結型であり、サーバーはそれ以前のやり取りに基づいてリクエストを解釈しない
  • 例：HTTP
    ウェブページのリクエストは独立しており、過去のリクエストに基づいてサーバーが応答を変更することはない

Cookieの考え方と実現方法

  • ステートレスなHTTP上で状態を表現させるために考えられたのがCookie
  • Cookieはウェブサイトがユーザーのブラウザに保存する小さなテキストファイルであり、ユーザーの設定、ログインセッション、ショッピングカートの内容などを記憶するために使用される
  • 実現方法
    • CookieはHTTPヘッダを通じて設定される
    • サーバは Set-Cookie ヘッダを使用してクライアントにCookieを送り、クライアントはその後のリクエストで Cookie ヘッダを使用してこれを送り返す

セッションの考え方と実現方法

  • Cookieは悪意ある攻撃者に簡単にのぞかれるため、ユーザー名やPWをCookieで保存することはセキュリティ上非常に大きな問題となる
    より安全に多くの情報を保持するための方法として考え出されたのが「セッション」と呼ばれる仕組み
  • セッションは、ユーザーがWebサイトにログインしてからログアウトするまでのユーザーの状態をサーバが追跡する仕組み
  • 実現方法
    • セッションを開始する時にWebサーバが新しいセッションIDを発行する
    • 発行されたセッションIDは、HTTPレスポンスのCookieへ格納してクライアントへ渡す
    • それ以降のリクエストの際、クライアントはセッションIDを格納したCookieをサーバへ送信する
    • WebサーバはCookieを受け取ると、そこに格納されたセッションIDを元にしてメモリ上に持っているクライアントの状態（ログイン情報、ユーザーの設定、購入履歴など）を復元する

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

Webサーバ

  • Webサーバは、インターネット上でHTTPを通じてコンテンツ（HTML、画像、JavaScript、CSSなど）をクライアント（通常はウェブブラウザ）に提供する
  • 静的コンテンツの提供が主な役割だが、動的コンテンツの生成に対応するためにアプリケーションサーバと連携することもある
  • 高速で安定したコンテンツの配信が求められ、大量の同時接続に対応する能力が重要
  • ApacheやNginxなどのWebサーバソフトウェアが広く使用されている

データベースサーバ

  • データベースサーバは、アプリケーションサーバからのデータの要求に応じてデータの保存、検索、更新、削除などを行う
  • 上記により、アプリケーションサーバは必要なデータを効率的に取り扱うことができる
  • データベースサーバとアプリケーションサーバ間の情報の受け渡しにはSQL（MySQL、PostgreSQLなど）が利用される

アプリケーションサーバ

  • アプリケーションサーバは、動的なコンテンツを生成する役割を持つ
  • クライアントのリクエストに基づいて、適切なデータベース操作を行い、その結果をもとに動的なWebページを作成する
  • Webサーバとアプリケーションサーバを異なるノードに配置すると、軽い処理で回数の多い静的コンテンツへのリクエストはWebサーバに、回数が少なく処理の重い動的コンテンツへのリクエストはアプリケーションサーバーへと、異なる性格のリクエストをうまく分担することができる

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

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

SQLインジェクション

  • 攻撃方法
    攻撃者が不正なSQLクエリをWebアプリケーションの入力フォームに注入し、データベースを操作する
  • 対策①：入力値のチェック
    フレームワークのバリデーション機能を利用し、SQLインジェクションで利用される「’」（アポストロフィ）の混入を防ぐ
  • 対策②：プリペアドステートメントの利用
    プログラム上で動的にSQL文を生成する必要があるとき、可変部分を変数のようにしたSQL文をあらかじめ作成しておき、値の挿入は処理系に行わせる方式

クロスサイトスクリプティング (XSS)

  • 攻撃方法
    • 攻撃者の用意したサイトに脆弱性のあるサイトへのリンクを用意しておき、GETリクエストを利用してJavaScriptを脆弱性のあるサイトへ渡すようにしておく
    • 攻撃者の用意したサイト訪問者がリンクをクリックすると、脆弱なサイトを経由してJavaScriptが被害者のブラウザへ送られ、悪意のあるスクリプトが実行されてしまう
    • 上記のようなスクリプトにより、例えば、被害者のブラウザが保存しているCookieの内容（セッションIDなど）が盗まれる
  • 対策：サニタイジング
    ユーザーからの入力を適切にサニタイズ（Webサイトの入力フォームから入力された悪意のあるHTMLタグ、JavaScript、SQL文などを検出し、それらを無害化するために他の文字列に置き換える操作）する

クロスサイトリクエストフォージェリ (CSRF)

  • 攻撃方法
    • 通常、ウェブサイトはユーザーがログインすると、そのユーザーのブラウザにセッションIDを保存する
      これにより、ユーザーはサイト内を移動する際に毎回ログイン情報を入力する必要がなくなる
    • ユーザーが攻撃者が用意した悪意のあるリンクやフォームにアクセスすると、そのユーザーのブラウザは自動的に悪意のあるリクエストを脆弱なウェブサイトに送信する
      この時、ブラウザはユーザーのセッションIDを含めたリクエストを送るため、ウェブサイトはそのリクエストが正規のユーザーから送られたものと誤認する
    • これらのリクエストは、パスワードの変更、金融取引の実行、メールアドレスの変更など、ユーザーの意図しない行動をウェブサイト上で実行することが可能
  • 対策：トークンの使用
    ウェブサイトの各フォームに一意のトークンを含めることで、そのフォームが正規のものであることを確認する
    フォームを送信する際、サーバはトークンを検証し、トークンが一致しない場合はリクエストを拒否する

コメント

タイトルとURLをコピーしました