2020-05-21

Webを支える技術第4部まとめ

Webを支える技術　第4部のまとめ

第10章 HTML

HTMLはタグで文書の構造を表現するマークアップ言語である。HTML4.01まではSGMLがベースで開発されていた。しかし複雑だったことから、仕様をよりシンプルにしたXMLが開発され、ベースをこれに変更したものがXHTML1.0であり、モジュール化によって拡張可能にしたXHTML1.1がある。

メディアタイプ

HTMLの文字エンコーディングは、よほどのことがない限りUTF-8を使用するのが無難である。

XMLの木構造

XMLは以下のような木構造になっている。

<html>
    <head>
        <title></title>
    </head>
    <body>
        <p></p>
        <a href=""></a>
    </body>
</html>

HTMLの構成要素

HTMLの基本的な構成要素はヘッダとボディであり、ヘッダ文書のメタデータとボディには文書の内容そのものを入れる。

リンク要素

aタグ - アンカー body内に埋め込む、別のWebページに移動するためのタグ
linkタグ Webページ同士の関係を指定するタグ。 body内に埋め込むaタグに対し、こちらはhead内に埋め込む。
form HTTPのGETやPOSTを利用して、結果を特定のURIに送信する機能。

リンク関係

Web APIのようにクライアントが人間ではなくプログラムである場合は、それぞれのリンクがどのような意味かを解釈し、どのリンクを辿るべきか機械的に判断する仕組みが必要になる。そのためHTMLやAtomは、リンクの意味をプログラムが可読な状態で記述するための機構を用意している。

rel属性「a」と「link」要素は、「rel」属性を持てる。relには、リンク元のリソースとリンク先のリソースがどのような関係にあるかを記述する。

「index.html」が「example.jp」にある「base.css」を参照する場合

<link rel = "stylesheet" href = "http://example.jp/base.css"/>

第11章 microformats

HTMLは見出しや段落などの構造を定義した文書フォーマットだったが、その中で更に意味のあるデータを表現するための技術がmicroformatsである。 microformatsは「より簡単に、もっと気軽にWebページのセマンティクスを記述できるようにしよう」という目的の元、開発された。

※セマンティック(Web)

要約するとWebページ内の細かな情報に意味を持たせ、検索エンジンなどの検索に引っかかりやすくすること
- 住所、緯度や経度
- 楽曲情報など

デメリット

同じclass属性やrel属性を持つWebページが存在していた場合、プログラムがご判定を起こしたり同じ属性を持ったmicroformatsが作成できなくなる
上記の問題を解決するためにW3Cが標準化を進めている「RDFa」がある。これはXMLの名前空間を使用して衝突問題を回避できるが、複雑な点やXHTMLでしか使用できないというデメリットもある。

リソースの表現としてのmicroformats

従来のHTML表現は人が閲覧するために利用されているため、プログラムでの処理に利用するのは難しかった。そのため、プログラム用のJSONなどのデータフォーマットを用意していたが、プログラム用に別のAPIを提供することは以下のような弱点を抱えている.

WebサービスとAPIで機能が異なってしないがち
開発規模の増大に伴うメンテナンス性の低下
Web APIに必要な技術の開発コストがかかる

microformatsはWebページをそのままWebAPIとして提供できるため、以下のようなメリットが期待できる。

ページとAPIでの機能差を無くす
開発はWebページだけで済むため、開発コストを抑えることやメンテナンス性の向上
新たにAPIを作る必要性がないため、学習コストも大幅に抑えられる

第12章 Atom

Atomとは、RFC4287が規定するXMLフォーマットであり、乱立していたRSSの仕様に対し、拡張性のあるフィードの標準フォーマットを策定しようという目的があった。

メンバリソース

Atomにおける最小のリソース単位はメンバリソースである。例を上げるならば、ブログサービスにおける一つ一つの記事、画像保存サービスにおける一つ一つの画像。

尚メンバリソースは、XMLのみで表現できるエントリリソース(文字)と、それ以外のメディアリソース(画像、音楽など)に分類され、それぞれ「entry」「feed」と明示される。

コレクションリソース

コレクションリソースは複数のメンバリソースを含むリソースであり、階層化はできない。そのため、コレクションリソースが他のコレクションリソースを含むことはできない。

イメージ

コレクションリソース
- メンバ
- メンバ
コレクションリソース
- メンバ

↓これはできない

コレクションリソース
- コレクションリソース

メディアタイプ

Atomのメディアタイプは「application/atom+xml」である。

typeパラメータなし Content-Type: application/atom+xml
エントリ Content-Type: application/atom+xml; type=entry
フィード Content-Type: application/atom+xml; type=feed
typeとcharsetパラメータを指定 Content-Type: application/atom+xml; type=feed; charset=utf-8

名前空間

http://www.w3.org/2005/Atom

拡張子

「.atom」

エントリ

前述の通り、エントリはエントリリソースの最

メタデータ

ID

エントリを一意に示すURI形式のID。tagスキームのURIがよく用いられている。

tag:{NS名もしくはメールアドレス},{日付}:{任意の文字列}

DNSもしくはメールアドレスに日付情報を加えることで、グローバルに一意であることを保証する。

タイトルと概要

「title」要素(必須) エントリの題名を表現する
「summary」要素エントリの概要を表現する

また、type属性として「text」「html」「xhtml」といった値を持ち、この値によって内容が変化する。

著者と貢献者

「auther」要素(必須) 著者を表現する
「contributer」要素貢献者を表現する

なお、「auther」「contributer」は以下の要素が必須である。

「name」要素(必須) 自然言語で記述した名前
「uri」要素人に関連付けられたURI
「email」要素人のメールアドレス

公開日時と更新日時

「updated」(必須) 更新日時
「published」公開日時

カテゴリ

カテゴリは、Webサービスなどにおけるタグ(タグ付けと言われるような)のようなもので、「category」で表現する。

リンク

「link」で表現する

フィード

必須要素はエントリと同じ

フィード独自のメタデータ

サブタイトル

「subtitle」タイトルで説明しきれない説明を記述

生成プログラム

「generator」フィードで生成したプログラムの情報を表現

アイコン

「icon」 faviconの指定

ロゴ

「logo」当該フィードを象徴する画像の指定

Atomを活用する

Atomは「タイトル」「著者」「更新日時」などといった基本的なメタデータを備えたリソース表現のためのフォーマットである。特に上記3点のデータはブログ以外のコンテンツでも有用なことが多い。

第13章 Atom Publishing Protocol (Atom Pub)

AtomとAtomPubの関係

Atom データフォーマットの規定
AtomPub Atomを利用したリソース編集プロトコルの規定

AtomPubの存在意義

ブログを編集するためのプロトコルはいくつも存在していたが、ブログ機能に特化していたため、国際化や拡張性で問題点があった。

AtomPubはこれを改善するため、汎用的なWeb APIの基礎を成すプロトコルを備えている。

第14章 JSON

JavaScriptの記法で記述されたデータの形式

拡張子

「.json」を推奨

JSONが持てるデータ

オブジェクト型
配列
文字列
数値
bool(論理型)
null

※参考

・Webを支える技術 https://www.amazon.co.jp/dp/4774142042/ref=cm_sw_em_r_mt_dp_U_LiIUEbQ3NJSJH

2020-05-21

Webを支える技術第3部まとめ

Webを支える技術

Webを支える技術　第3部のまとめ

第6章 HTTPの基本

HTTPとは

HTTPはハイパーテキストの転送用プロトコルであり、実際には静止画や動画、JavaScriptなどのコンピュータで扱えるデータなら何でも転送できる。

現在のWebでは、これのバージョン1.1が最も使用されている。

TCP/IP

TCP/IPはHTTPのベースになっており、インターネットの基盤を構成するネットワーク・プロトコルである。

ネットワークインターフェース層物理的なケーブルやアダプタ
インターネット層ネットワークで実際にデータをやりとりする部分。TCP/IPにおいてIPが相当する。 IPにおいて、データの基本的な通信単位をパケットと呼び、指定したアドレスに対してパケット単位で通信を行う。
トランスポート層 IPが保証しなかったデータの転送を保証する役割を持つ。TCP/IPにおいてTCPが相当する。 TCPでは、接続先に対してコネクションを張ることでデータの抜け漏れをチェックし、データの到達を保証する。また、接続したコネクションがどのアプリケーションを渡るのかを決定するのがポート番号であり、HTTPではデフォルトの80番ポートが使用される。
アプリケーション層メールやDNS、HTTPを実現する層。

TCPでは一般的に「ソケット」いうライブラリが使用される。ソケットは接続、送信、受信、切断などといったネットワークでのデータのやりとりを抽象化したAPIであり、HTTPサーバやブラウザはソケットを用いて実装される。

リクエストとレスポンス

HTTPではクライアント-サーバ間でデータをやりとりする際に、以下のような一連の流れが行われる。

クライアント側

リクエストの構築
リクエストの送信
レスポンスが返ってくるまで待機
レスポンスの受信
レスポンスの解析
クライアント側の目標を達成するために必要な処理

クライアント側

リクエストの待機
リクエストの受信
リクエストの解析
適切なアプリケーションプログラムへの処理の移譲
アプリケーションからの結果を取得
レスポンスの構築
レスポンスの送信

HTTPのステートレス性

HTTPはステートレスなプロトコルとして設計されている。

メリット

クライアント側に自らのアプリケーション状態を覚えさせることで、サーバの負荷を減らすことに繋げられる
クライアント側はどのサーバにリクエストを送っても問題ない

デメリット

送信するデータの量が多くなる
認証などのサーバーに負荷がかかる処理が繰り返される
通信エラーの対処
- ネットワークトラブルが起きたときにリクエストが処理されたかどうか分からない

第7章 HTTPメソッド

メソッド	意味
GET	リソースの取得
POST	子リソースの作成、リソースへのデータ追加、その他処理
PUT	リソースの更新、作成
DELETE	リソースの削除
HEAD	リソースのヘッダ(メタデータ)の取得
OPTIONS	リソースがサポートしているメソッドの取得
TRACE	自分宛てにリソースを返す試験(ループバック)
CONNECT	プロキシ動作のトンネル接続への変更

尚、TRACEとCONNECTはほとんど使われていない。

POSTとPUTの使い分けについて

特別な理由が無い限り、サーバ側でURIを決定するPOSTを利用する方が望ましい。

第8章ステータスコード

HTTPのステータスを表す番号

コード番号	意味
1xx	処理中
2xx	成功
3xx	リダイレクト
4xx	クライアントエラー
5xx	サーバエラー

よく使われるもの

コード番号及びメッセージ	意味
200 OK	リクエスト成功
201 Created	リソースの作成成功
301 Moved Permanently	リソースの恒久的な移動
303 See Other	別URIの参照
400 Bad Request	リクエストの間違い
401 Unauthorized	アクセス権不正
404 Not Found	リソースの不在
500 Internal Server Error	サーバ内部エラー
503 Service Unavailable	サービス停止

現在の状態を正しいステータスコードで返さなければ、無駄なインデックス処理が行われてしまう可能性もあるため、設計時に注意しなければならない。

第9章 HTTPヘッダ

ヘッダはメッセージのボディに対する付加的な情報を示す。また、HTTPの機能はヘッダに設定されている情報を元に初めて実装される。

日時

Dateヘッダなどによって、日時のフォーマットを指定する。例

Date : Tue, 28 Apr 2020 03:21:05 GMT

HTTPでは、日時は全てGMT(グリニッジ標準時)で記述することになっていため、サマータイムなどの問題を回避することが出来る。

MIMEメディアタイプ

Content-Type

Content-Typeヘッダは、メッセージの内容がどのような種類なのかメディアタイプで示す。現状では、RFC2045及びRFC2046によって9つのタイプが定義されている。

タイプ	意味
text	人が読んで理解できるテキスト
image	画像データ
audio	音声データ
video	映像データ
application	その他のデータ
multipart	複数のデータからなる複合データ
message	電子メールメッセージ
model	複数次元で構成するモデルデータ
example	例示用

charsetパラメータ

文字エンコーディング(文字コード)を指定するパラメータ。HTTPでは、デフォルトの文字エンコーディングはISO 8859-1と定義されているため、日本語文字列が含まれていると文字化けを起こしてしまう。文字化けを防ぐには、予めcharsetパラメータでUTF-8などの日本語に対応している文字コードを指定しておく必要がある。

コンテントネゴシエーション

メディアタイプや文字エンコーディングを、サーバ側で一方的に決めるのではなく、クライアントと交渉して決める方式。

Accept 処理できるメディアタイプを伝える
Accept_Charset 処理できる文字エンコーディングを伝える
Accept Language 処理できる言語を伝える

Content-Lengthとチャンク転送

Content-Length

メッセージがボディを持っている場合、その長さを10進数のbyteで示す。 Content-Lengthヘッダは、静的なファイルなどのあらかじめサイズが分かっているリソースで利用される。

チャンク転送

動的にリソースが生成されるようなWebサービスの場合、あらかじめサイズが決まっておらず、レスポンスが低下してしまう。こういった場合、Transfer-Encordingを利用することで、サイズが分からないリソースを少しずつ送ることができる。

認証

Basic認証

ユーザ名とパスワードをAuthorizationヘッダに入れてリクエストごとに送信する認証方式。ほとんど平文のような形で情報をやりとりするため、SSL/TLSとの組み合わせや平文でもいいという環境などを検討しなければならない。

Digest認証

ハッシュ関数を利用して、メッセージを不可逆な形式にしてやり取りする方法。 Basic認証よりセキュアな方式だが、メッセージ自体は暗号化されないため、暗号化したい場合はHTTPSを利用した方がよい。

HTTPS

HTTPSは、HTTPとSSL/TLSを組み合わせた通信の総称で、クライアント-サーバ間でのデータのやりとりを暗号化して盗聴を防ぐために利用される。

SSL/TLSでは、主に3つの提供している。

暗号化
認証
改ざん検知

キャッシュ

サーバから取得したリソースをローカルに保存しておき、再度アクセスしたときに再利用するというHTTPの機能。

Pragma キャッシュを抑制するヘッダ。リソースをキャッシュさせないように示す。
Expires キャッシュの有効期限を指定するヘッダ。指定された時間まではキャッシュを再利用する。リソースを変更しない場合でも、最長1年程度の保持に留めておくことが推奨されている。
Cache-Control 詳細なキャッシュ方式を指定するヘッダ。

条件付きGET

クライアントがキャッシュをそのまま利用できないと判断した場合でも、条件付きGETを利用することでリソースが変更されている検証する。

If-Modified-Since リソースの更新日時を条件にする。
If-None-Match リソースのEtagを条件にする。

If-Modified-SinceとIf-None-Matchの使い分け

サーバがEtagを利用している場合は「If-None-Match」、そうでない場合は「If-Modified-Since」を利用すべき。

持続的接続

HTTP1.1の新機能であり、クライアントとサーバ間でリクエストのたびに切断するのではなく、まとめて接続し続ける手法。HTTP1.0ではKeep-Aliveヘッダで実現するが、HTTP1.1ではデフォルトの動作になった。

2020-05-21

Webを支える技術第2部まとめ

Webを支える技術

Webを支える技術の第2部をまとめました

第4章 URIの仕様

URIは統一されたリソースの識別子であり、リソースに割り当てれば一意に示すことができる。

URIの基本的な構文

URIは基本的に以下のようなパーツから構成されている。

URIスキーム : http
ホスト名 : example.com
パス : /hoge/fuga

URIスキーム

URIはまず利用するプロトコル(スキーム)から始まる。上記の場合、HTTPでリソースにアクセスするということが分かる。

ホスト名

次にホスト名が入る。ホスト名は基本的にDNSによって割り当てられた「ドメイン」もしくは「IPアドレス」になり、必ず一意な値となる。(同名のサーバーは存在してはならない)

パス

最後はホスト内のパスを指定する文が入る。これはホストサーバ内のディレクトリ及びファイルを指定するものであり、ホスト名と同様こちらも必ず一意な値となる。

一意なURI

URIのホスト名及びパス値が一意に割り当てられていることによって、世界中の他のリソースと重複しないようになっている。 (現実の住所と同じ。同じ住所の家が複数あった場合、どの家が本物なのか分からない)

複雑なURIの構文

以下はより複雑になったURIの構文の例である。

URIスキーム : http
ユーザ情報 : ID:PW
ホスト名 : example.com
ポート番号 : 8000
パス : /hoge/fuga
クエリパラメータ : ?name=ryo&a=a
URIフラグメント : #n10

ユーザ情報

リソースにアクセスするための情報

ポート番号

ホストにアクセスする際に利用するプロトコルのTCPポート番号。省略した場合、HTTPのデフォルト値である「80」が利用される。

クエリパラメータ

動的にページや数値を生成する場合に使用。複数の値を受け渡しする場合は「&」で結合される。

URIフラグメント

URIで指定されたリソースの中でも更に細かい場所の指定を行う(目次等で使用される)

絶対URIと相対URI

絶対URI：ルートディレクトリから特定のファイルを指定したパス
相対URI：現在のディレクトリから特定のファイルを指定したパス

OSのファイルシステムにおいては、毎回絶対URIを記述するのは冗長であるため、相対URIが用いられる。

ベースURI

上記の「相対URI」は、サーバー側のディレクトリ構造や現在位置を知らないクライアントからすると、どのファイルを指定しているのかが分からない。

そのため、起点となるベースURIが必要になってくる。ベースURIを用意することによって、以下のように相対URIを絶対URIと同じように取り扱うことが出来る。

ベースURI : [http://example.com/foo/bar/]

相対URI	絶対URI
hoge	http://example.com/foo/bar/hoge
hoge/fuga	http://example.com/foo/bar/hoge/fuga
./hoge	http://example.com/foo/bar/hoge
../hoge	http://example.com/foo/hoge

ベースURIの指定方法

相対URIが出現するページ(リソース)のURIをベースにする

相対URIのリンクが発生するページを起点として、他のURIにアクセスする方式である。

この方式の場合、直感的で分かりやすい(全てのリンクが、現在位置から見た位置を指定しているため)というメリットがある。その一方、ベースURIをクライアント側で保存しなければならない、ベースURIを見失ったとき、相対URIのみではアクセスできなくなってしまう(可用性の低下)といったデメリットもつきまとう。

予め明示的にベースURIを指定する

HTMLやXMLのリソース内に予めベースURIを指定する文を組み込む方式

例：HTML この場合、baseタグが指定されたHTML文書(index.html)内のベースURIは「http://example.com/foo/bar」となる

<head>
    <base href="http://example.com/foo/bar"/>
</head>

例：XML この場合、スペースA内のベースURIは「http://example.com/foo」、スペースB内は「http://example.com/foo/bar」となる

<foo xml:base="http://example.com/foo">
    <!--スペースA-->
    <bar xml:base="http://example.com/foo/bar">
    <!--スペースB-->
    </bar>
    <!--スペースA-->
</foo>

この方式の場合、クライアント側にベースURIを保存する必要が無くなり、より確実に相対URIにアクセス出来るようになる。

URIと文字

URIで直接使用できる文字はASCIIのみであり、そのままでは日本語は使用できない。使用する場合は、%エンコーディングが必要になる。

例エンコード前

http://example.com<あ

エンコード後

http://example.com/%E3%81%82

UTF-8において、「あ」は「0xE3 0x81 0x82」の3バイトから成り立っているため、このような結果になった。尚、記号「%」は%エンコーディングを示す特別な記号であるため、URIに直接使用することはできない。万が一使用する場合は、「%25」と示す必要がある。

URIの長さ制限について

仕様上では、URIの長さについて特に制限は無い。しかし、実装する際に事実上の制限は存在する。特にInternet Explorerにおいては2048バイトまでという制限があり、これに合わせて実装されることが多い。

URIの実装で気をつけること

URIの仕様上、取扱に気をつけるべきなのは「相対URI」と「%エンコーディング」の2点である。

相対URI

クライアント側で解決しようとすると処理が面倒になるため、WebサービスやAPIにおいてはなるべく「絶対URI」を使った方が親切

%エンコーディング

URI内にASCII以外の文字を入れる場合、文字エンコーディングの混乱を避けるためにUTF-8のみを用いてエンコードするのが望ましい

第6章 URIの設計

Webではサービスの終了やURIの変更によって、これまでアクセス出来ていたページが表示できなくなってしまうことがある。但しURIの変更については、システム設計段階である程度防ぐことは出来るため、以下のような取り組みが必要である。

URIを変わりにくくするための方法

URIにプログラミング言語依存の拡張子を使用しない (.pl、.rbなど)
URIに実装依存のパス名を使用しない(cgi-bin、sevletなど)
URIに言語のメソッドを利用しない
URIにセッションIDを含めない
URIはリソースを表現する名詞である

URIを強く意識する

URIは、Webアプリケーションフレームワークが隠蔽をし、あまり意識しなくてもよい存在になってしまいがちだが、以下の点でとても重要である。

URIはリソースの名前である
URIは寿命が長い
URIはブラウザがアドレス欄に表示する

これらの点からURIはWebアプリケーションの中で最も重要するべきパーツであると言える。

※参考

・Webを支える技術 https://www.amazon.co.jp/dp/4774142042/ref=cm_sw_em_r_mt_dp_U_LiIUEbQ3NJSJH

・IEのURI長さ制限について https://support.microsoft.com/ja-jp/help/208427/maximum-url-length-is-2-083-characters-in-internet-explorer

2020-05-21

Webを支える技術第1部まとめ

Webを支える技術

Webを支える技術の第1部をまとめました

第1章 Webとは何か

一般的なWebサイト
- ECサイト、ポータルサイト、検索サービスなど
- クライアント側が、サイトの仕組みを意識せずに利用できる
UIとしてのWeb
- Webサイトだけではなく、ネットワークや家電の設定においても、ブラウザないしはHTMLで記述されたページで操作
- 何故こういった使い方がされるか
  - 専用のインターフェースやアプリケーションを作るよりコストがかかりにくい、効率的
  - ブラウザを搭載しており、ネット環境があれば端末の種類を問わず操作可能
APIとしてのWeb
- プログラム向けのインターフェース
- SNSなどで行われるデータの連携などが有名
- データフォーマットは、XMLやJSONが使用される

Webを支える技術

様々な用途で使用されるWeb、それは下記のような技術で支えられている

基本的な技術

HTML
- Webコンテンツを構成するための文書
URI
- コンテンツの場所や名前を特定する
HTTP
- HTMLなどの情報を送受信するためのプロトコル(規則)

ハイパーメディア

先頭から順当に情報が遷移していくのではなく、非線形的にリンクを選択して情報を取得する形式

分散システム

処理を分散させることで、単一のコンピュータでは困難な機能や性能を実現できるシステム
Webは世界中に配置されたサーバに対し、世界中からのアクセスが行われるため超大規模な分散システムと言える
この分散システムの恩恵でWebは実現している

第2章 Webの歴史

Web以前のインターネット

最初は米国防総省のコンピュータネットワークとして構築された
TCP/IPではなく、UUCPで通信を行っていたためタイムラグが発生した
UNIXに接続するためのtelnetやファイル交換のためのFTP等が存在

Webの特徴、強みである「ハイパーメディア」について

Web以前に存在していたハイパーメディアの特徴

Webよりも高機能なモノも多かったが、それゆえ複雑になってしまった

Webの実現しているリンクの特徴

シンプルな単方向リンクによって実現
インターネットを用いてるため、不特定多数の情報とリンクさせ合える
ユーザーにとっても分かりやすい

Webの成功は、実装が簡単なシンプルで必要最低限のリンク機能が存在していたから

分散システム

Webはオープンな環境で、不特定多数のクライアントを相手にするシステム

クライアントのコンピュータ環境(OS、ブラウザ、機種など)が統一されていなくても同じWebサービスできる。

HTTPプロトコルによって、クライアント-サーバ間の通信インターフェースが統一されているため

Webの標準化

Webの急速な普及に伴って、仕様標準化が求められた。

しかし当初は標準化が間に合わず、Web事業に参入した各社の実装がバラバラになってしまい、相互運用能力に欠ける仕様となってしまった。また、この頃に存在していたブラウザは、それぞれでHTMLとCSSのレンタリング結果が大きく異なっていたため、開発者はブラウザごとの対応を迫られていた。現在では解消しつつあるものの、未だにIEなどのブラウザ対応が行われているのはこの時代の名残である。

様々なハイパーメディアフォーマットの誕生

Atom Webページで新着情報を取り扱うためのフォーマット
JSON データフォーマットとして、HTMLやAtomは冗長 ↓ 単純で機械や人間にとっても可視性の高いフォーマットとして「JSON」が誕生

WebAPI

分散システム(オブジェクト)の標準化を進めるため、WebAPIを構成する2つ仕様が発生

SOAP
- RPC/分散システムの中での基本的なプロトコル(規則)
- リクエスト、レスポンス共にXMLが利用される
- 利用者が少なく、複雑な入出力や厳密なチェックを必要とするサービス向け
REST
- 分散システムにおける考え方
- リクエストは「GET」「POST」などによって行われ、レスポンスについてはフォーマットの指定が無い
- 不特定多数の人が利用する、入出力に対して厳密無くてもよいサービス向け

結果的には、「簡単でシンプル」「政治的理由」によってRESTの方に軍配が上がった。

全てがWebへ

バックエンドのプロトコルは現在に至っても変化はしていないが、UIはWebで統一されつつある。また、一台のコンピュータで行えない処理も、Webを通じてインターネット上のコンピュータの力を借りて実現できている。こういったことから、今後もWebの重要性は増すばかりである。

第3章 REST Webのアーキテクチャスタイル

RESTはWebのアーキテクチャスタイルであり、クライアント/サーバのスタイルから派生したWebの設計思想のことである。

アーキテクチャ構造、仕様そのもの
アーキテクチャスタイルアーキテクチャを設計する上での思想、方針

また、このRESTの制約に遵守してサービスを作ることがWeb全体で統一した設計をすることができる。

リソース

RESTにおいて「リソース」は重要な概念だ。 Web上のあらゆる情報は、全てリソースとして取扱われる。

例

動画
ニュース
ページ

また、これらのリソースはWeb上の無数のサーバーに存在しており、プログラムで利用するためには、どのサーバーにあるどのリソースが必要なのか正確に判断するための材料が必要になってくる。

それを解決するために「URI」という重複しない、一意な名前を割り当てられている。

URIは「プロトコル」「サーバー情報」「ディレクトリ構造」「ステータス」といった情報を一文でまとめたもので、プログラムでの処理やアクセスを容易にできる。

RESTに含まれているアーキテクチャ

クライアント/サーバ

Webは、HTTPという通信プロトコルでクライアント-サーバ間の通信を行う「クライアント/サーバ」のアーキテクチャスタイルを採用している。これは、クライアントから送られたリクエストに対し、サーバがレスポンスを返すという方式であり、クライアントはUI、サーバはデータを担当することで、処理を分散できるメリットがある。

また、クライアントはUIのみを担当すれば良いので、PCだけでなく携帯電話やゲーム機などのプラットフォームからもアクセスすることができる。

ステートレスサーバ

クライアントのアプリケーション状態をサーバ側で管理しないアーキテクチャスタイルであり、サーバ側の実装の簡略化に繋がる。また、サーバの行う処理を軽減することも出来る。

しかし実際には、Cookieを利用したセッション管理を行うステートフルなサービスも多く存在しており、REST的には間違っていると言える。ただし、現実的に考えてそれらを全てステートレスに置き換えるといったことは出来ないため、最低限に留めつつ利用することが大切だ。

キャッシュ

一度取得したリソースをクライアント側で保存をしておき、再度必要になったときに使い回す方式。クライアント-サーバ間での通信量を減らすことや処理時間の短縮に寄与するが、取得した時の情報が古いくなっていた場合、情報の信頼性が下がってしまう。

統一インターフェース(UI)

リソースの操作を制限を設けることで、システムを多種多様のクライアントやサーバに対応させるアーキテクチャスタイル。

階層化システム

システム全体をいくつかの階層に分割するアーキテクチャスタイル。

RESTにおいては、インターフェースをHTTPで統一しているため、途中で階層構造を変更してもクライアント側は大きな影響無く利用することが出来る。

コードオンデマンド

プログラムコードをサーバからダウンロードして、クライアント側で実行処理を行うスタイル。

例

この方式には、クライアントにあらかじめ用意しておいた機能だけでなく、後から機能を追加できることやFlashやJavascriptを利用した派手なサービスも提供することができる。また、処理はクライアント側で行うため、サーバ側の負担を軽減することが出来る。

しかし、クライアント側でプログラムが実行されるため、サーバ側からプロトコルの可視性が低下してしまうといった欠点も存在する。

※参考

・Webを支える技術 https://www.amazon.co.jp/dp/4774142042/ref=cm_sw_em_r_mt_dp_U_LiIUEbQ3NJSJH

2020-05-21

AppGoat まとめ

AppGoat

「AppGoat」を利用したセキュリティ勉強のまとめです。

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

Webページに対し不正なスクリプト文を埋め込み、それを利用者の元で表示させて被害を与える攻撃。

危険性

Webページの改ざん
情報の窃取(フィッシング)
セッション情報の改ざん

また、XSSには主に3つのタイプがある。

1.反射型

不正なスクリプト文を含んだリクエストが、送信者の元で実行されるタイプ

流れ

スクリプトをパラメータに含ませたURLをサービスを利用しているクライアントの元へ送る
URLにアクセスし、パラメータをサーバに送る
パラメータ内の不正なスクリプトを含んだHTMLを出力し、それを返されたクライアントの元で実行

例えばアンケートサイトなどで、nameタグに脆弱性があったとする。その状態で、以下のURLにアクセスするとパラメータ内のスクリプトが実行されてしまう

http://example.com/enquete?name=<script>alert("不正スクリプト");</script>

2.格納型

不正なスクリプト文をサーバ内に格納し、アクセスした利用者のブラウザで実行させるタイプ

流れ

DBにデータを格納しているWebサイトで、不正なスクリプト文を入力、格納
利用者が正規のURLを使ってアクセスした場合でも、DB内に格納されたスクリプトがページに出力され、クライアントの元で実行
反射型と違い、修正を行うまでほぼ永続的に実行される

3.DOMベースのXSS

javascriptを利用して動的にDOMを操作するページにおいて、エスケープ漏れ等の脆弱性を狙って不正なスクリプトを実行させる攻撃

反射型や格納型と違い、スクリプトの実行及びHTMLの生成は、サーバ側ではなくクライアント側で行うため、ログが残らず発見しにくいという特徴がある
動的に内容を変えるページの増加に伴い、脆弱性を突くこの攻撃手段も増えつつある

原因

入力値やパラメータに対し、エスケープ処理を行っていないため。
- エスケープ処理：言語において特別な機能を持つ文字を、特に機能を持たない普通の文字列として扱うための処理

対策方法

反射型パラメータの値を表示する前にエスケープする
格納型入力された値をDBに格納する前にエスケープする
DOMベースのXSS javascriptで内容を書き換えるときは、毎回エスケープする

SQLインジェクション

不正なSQL文を実行することで、データベースを不正に操作する攻撃

危険性

本来取得すべきでないDBの情報が不正に取得される
不正取得された情報でサービスにログインされる
DBの改ざん、データ削除
OSコマンドが不正に実行される

原因

入力値に対し、エスケープ処理を行っていないため。

対策方法

静的プレースホルダによるSQL文の組み立てを行った上でクエリを実行する (入力された情報を直接文字列結合しない)

例

$fuga = ?_GET["fuga"]; //GETされた値

//「?」パラメータでSQLステートメントを用意
$stmt = $db->prepare("SELECT * FROM hoge WHERE fuga = ?;");

//配列の値を渡してからステートメントを実行
result = $stmt->execute(array($fuga));

また、DBを操作できるアカウントに権限を設け、普通のページからでは操作できないようにすることも対策の一つ。

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

何らかのオンラインサービスにログイン中の被害者に対し、偽のURLを踏ませることで不正なリクエストを送信させる手法。

危険性

主に正規ログインしたユーザーのみが行える操作が意図しない形で行われてしまう

サービスの不正利用
各種設定の変更
個人情報の取得

原因

ログイン状態(セッションを確立した状態)なら認証を行わずに、各種操作ができてしまうから。

対策方法

予測不能なトークン(疑似乱数)を設定する
大きな操作をする際、PWなどによる認証を促す

バッファオーバーフロー

確保しているメモリの容量(バッファ)に対し、それを上回る値を書き込むことでオーバーフローを引き起こし、システムの機能停止や誤作動を狙う攻撃手段。

特徴

主に「C」や「C++」における脆弱性
- 割り当てられているメモリの許容値内に入力値が収まっているかチェックせず、そのままメモリに書き込みをしてしまうため
「Java」や「php」等の言語
- メモリを直接操作することは無いため、ライブラリ等の脆弱性が無い限りはこの攻撃を受ける可能性は低い

危険性

プログラムの異常終了
メモリ上のデータの改ざん、破壊
外部からのシェルコマンドの実行

原因

入力値をチェックせず、そのままメモリに書き込みをしているから。

対策方法

入力値チェックを行い、不正な値を弾く
領域溢れが起きた時点でプログラムを強制終了させる
シェルコードを送り込めないようにする

ディレクトリ・トラバーサル

Webに公開しているサーバーの中にある、公開していないデータを不正に閲覧したり操作する攻撃。

危険性

公開していないファイルの閲覧による情報漏えい
サーバー上のデータの改ざん、破壊

原因

ファイルにアクセス制限を設けていない
「/」で階層を遡れる設計

対策方法

特定のファイルに対し、外部からのアクセスを制限する
ファイルを指定するパスに、ディレクトリの名称を含めないようにする
- 階層を意味する「/」を受け取らないようにする

OSコマンド・インジェクション

Webアプリ上で入力されたユーザからのリクエストを、実行可能な文字列としてシェルに渡すことで、OSに任意のコマンドの実行命令を行わせる攻撃。

危険性

不正にOSコマンドを実行されることで、ファイルの改ざんやシステム全体を操作される(OSコマンドで実行されることが全て可能)

原因

エスケープ処理をかけていない
ファイル名の書き換えなどで、OSコマンドを利用していること

対策方法

入力された値にエスケープ処理をかける
可能な限りOSのコマンドを利用せずに、言語やフレームワーク内の関数を利用する

セッション管理の不備(セッションハイジャック)

ユーザを識別するための「セッションID」に以下のような不備があったとする。

推測されやすいID
IDの漏洩
IDの固定化

その場合、攻撃者が利用者のセッションを使用して被害者になりすます、といった被害が起こりゆる。

危険性

サービスの会員になりすまし、ログインが必要なサービスの不正利用が行われる

対策方法

推測

せッションIDの生成規則を推測されにくいものにする
- (推奨)言語に含まれている関数を利用して生成
- 暗号論的疑似乱数生成器を利用して桁数の長いIDを生成する

漏洩

URLにGET形式でIDを埋め込まない (POSTやhiddenで受け渡しを行う)
Cookieに記録する際はsecure属性を指定し、HTTPS通信のときのみデータの受け渡しを行う

固定化

ワンタイムセッションIDの生成 (頻繁にセッションIDを変更する)
XSS等の攻撃と組み合わせて使用されることがあるので、そちらの対策も同時に行う

認証制御や認可制御の欠落

認証確認が不十分であることから、権限の無い人間に、本来操作できないはずのファイルの操作や閲覧が行われてしまうこと

原因

各ファイルやディレクトリ、DBに適切な権限を付与していない
ログイン時に、第三者が知りうる情報のみで認証が行われている場合
認証に失敗した際に、どこが間違っているか教えてしまう
- IDとPWで認証している場合、「PWだけが間違っている」と表示するとIDの存在が知られてしまう
- 攻撃者にヒントを与えてしまいかねない

危険性

攻撃者が本来行うことのできない操作をすることで、非公開の情報が漏洩、改ざんされる

対策

適切な権限を付与する
ログイン及びセッション情報の照合
利用者本人しか知らない情報を認証に利用する
何が間違っているか具体的に教えない -「 ID、もしくはパスワードが間違っている」等

HTTPヘッダ・インジェクション

HTTPヘッダレスポンスの情報を書き換えることで、本来とは違う偽のページを生成する

原因

PHP 5.3.10以前の改行コードの脆弱性

危険性

Cookieの不正発行による成りすまし
出力内容の改ざん、それによるフィッシング詐欺
サーバのキャッシュ汚染

対策

レスポンスヘッダでは、外部からのパラメータを出力しないようにする
言語にある専用のAPIで、リダイレクトうやCookie出力を行う
ヘッダに入力された改行を弾く

クリックジャッキング

Webサイトのボタンや説明を偽装することで、被害者に正規のサイトを操作しているように思わせつつ、意図していない操作を行わせる手法

原因

HTTPレスポンスヘッダの欠陥

対策

HTTPレスポンスヘッダに「X-FRAME-OPTIONS」を付ける

メールヘッダ・インジェクション

メールヘッダを改ざんするリクエストを送り、送信先や本文の改ざんを行う攻撃

危険性

意図しないアドレスへのメール送信
メールの改ざんにより、危険なサイトへアクセスしてしまう
スパムメール、ウイルスの受信

対策

本文チェックを行い、外部からのパラメータを含まないようにする
改行コードを受け付けないようにする

その他

エラーメッセージの脆弱性
存在しないページを参照した際に、エラーメッセージとしてファイルやDBの情報が出力される
- Webサイトが構築されている環境が攻撃者に知れ渡ってしまう

対策

実行環境の設定を変えることで、エラー出力を無効化
リリース以降はデバッグ機能を無効化
オープンリダイレクト

Webページがリダイレクトする際、リダイレクト先のページを書き換えることで被害者を偽のサイトにアクセスさせて、情報を窃取する手法

危険性

送信先が偽のサイトだとしても、入力ページ自体は本物のページなため、被害者が気付かず情報を入力してしまう可能性が高い

原因

リダイレクト先のチェックを行っていない

対策

リダイレクト先のURLをチェックする
クッションページを設けて、クライアントにも間違いないか確認させる

第10章 HTML

メディアタイプ

XMLの木構造

HTMLの構成要素

リンク要素

リンク関係

第11章 microformats

デメリット

リソースの表現としてのmicroformats

第12章 Atom

メンバリソース

コレクションリソース

メディアタイプ

拡張子

エントリ

ID

タイトルと概要

著者と貢献者

公開日時と更新日時

カテゴリ

リンク

フィード

フィード独自のメタデータ

サブタイトル

生成プログラム

アイコン

ロゴ

Atomを活用する

第13章 Atom Publishing Protocol (Atom Pub)

AtomとAtomPubの関係

AtomPubの存在意義

第14章 JSON

拡張子

JSONが持てるデータ

※参考

第6章 HTTPの基本

HTTPとは

リクエストとレスポンス

クライアント側

クライアント側

HTTPのステートレス性

メリット

デメリット

第7章 HTTPメソッド

POSTとPUTの使い分けについて

第8章 ステータスコード

よく使われるもの

第9章 HTTPヘッダ

日時

MIMEメディアタイプ

Content-Type

charsetパラメータ

コンテントネゴシエーション

Content-Lengthとチャンク転送

認証

キャッシュ

条件付きGET

If-Modified-SinceとIf-None-Matchの使い分け

持続的接続

第4章 URIの仕様

URIの基本的な構文

URIスキーム

ホスト名

パス

一意なURI

複雑なURIの構文

ユーザ情報

ポート番号

クエリパラメータ

URIフラグメント

絶対URIと相対URI

ベースURI

ベースURIの指定方法

URIと文字

URIの長さ制限について

URIの実装で気をつけること

第6章 URIの設計

URIを変わりにくくするための方法

URIを強く意識する

※参考

第8章ステータスコード