【Webを支える技術】第４部 ハイパーメディアフォーマット 学習メモ
目次
- 目次
- はじめに
- 第４部 ハイパーメディアフォーマット
はじめに
この記事は「Webを支える技術」を読んで自分なりにまとめた学習メモです。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者: 山本陽平
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
- 購入: 143人 クリック: 4,320回
- この商品を含むブログ (183件) を見る
第４部 ハイパーメディアフォーマット
第１０章 HTML
HTML（Hypertext Markup Language）
HTMLとは、タグ（Tag）で文書の構造を表現するコンピュータのマークアップ言語です。マークアップした構造を持った文書のことを「構造化文書」（Structured Document）と呼びます。
HTML5 は現在まさに仕様策定中の新しい HTML です。
HTMLのメディアタイプの種類
拡張子
- 「.html」：現在の一般的な拡張子
- 「.htm」：古いOSの制限による
HTMLの構成要素
- ヘッダ：メタデータのこと
- ボディ：文書の本文のこと
- 大きく分けて２種類：ブロックレベル要素、インライン要素
- 共通の属性：HTMLのすべての要素は、id 属性と class 属性を持つ
- id: 文書内で一意なID
- class: その要素が属するクラス
リンク
- <a>：アンカー
- <link>：リンク
- <object>：オブジェクトの埋め込み
- <form>：フォーム
第１１章 microformats
microformats
microformatsとは、HTMLの中でさらに意味のあるデータを表現するための技術のことです。
セマンティクス（Semantics）
セマンティクスWeb とは、人間が読んで理解するWebページの意味を、プログラムからも処理できるように形式的に意味を記述するための技術のことです。
RDFとmicroformats
RDF（Resource Description Framework）とは、Webページ上の情報のメタデータ（データの属性や関係を表すためのデータ）を記述するための構造のことです。
RDFの問題点
- 記述が複雑になりがち
- 統一的な記述がしづらい
- 対象データとは独立したメタデータが必要
RDFの問題点を解消した技術が microformats です。
microformatsの分類
- elemental(単純) microformats：rel-license のように、リンク関係（<a>要素や<link>要素の rel 属性）を使ってメタデータを表現するフォーマット
- compound(複合) microformats：後述する hCalendar のように、主に class 属性を使って階層構造のあるメタデータを表現するフォーマット
リソースの表現としてのmicroformats
microformatsは下記の弱点を補ってくれるリソース表現です。
第１２章 Atom
Atom（Atom Syndication Format）
Atomとは、RFC 4287 が規定する XML フォーマットです。
Atomのリソースモデル
- メンバリソース（Menber Resource）：Atomにおける最小のリソース単位
- コレクションリソース（Collection Resource）：複数のメンバリソースを含むリソース
Atomの拡張
- Atom Threading Extensions ―― スレッドを表現する
- Atom License Extension ―― ライセンス情報を表現する
- Feed Paging and Archiing ―― フィードを分割する
- OpenSearch ―― 検索結果を表現する
第１３章 Atom Publishing Protocol
Atom Publishing Protocol（AtomPub）
AtomPubは、Atom が規定したフィードやエントリで表現するリソースの編集、いわゆる CRUD 操作を実現するためのプロトコルです。
サービス文書
- メディアタイプ
- <service>要素
- <workspace>要素
- <collection>要素
- <accept>要素
- カテゴリ
AtomPubに向いているWeb API
AtomPubに向いていないWeb API
- Cometを利用するような、リアルタイム性が重要なAPI
- 映像のストリーム配信など、HTTP以外のプロトコルを必要とするAPI
- データの階層構造が重要なAPI
- 「タイトル」「作者」「更新日時」など、Atom フォーマットが用意する出たデータが不要なAPI
第１４章 JSON
JSON（JavaScript Object Notation）
JSONとは、RFC 4627 が規定するデータ記述言語です。JavaScript の記法でデータを記述できる点が最大の特徴です。
メディアタイプ
- 「application/json」
拡張子
- 「.json」
データ型
- オブジェクト
- 配列
- 文字列
- 数値
- ブーリアン
- null
JSONP（JSON with Padding）によるクロスドメイン通信
JSONP (JSON with padding) とは、scriptタグを使用してクロスドメインな（異なるドメインに存在する）データを取得する仕組みのことです。
ハイパーメディアとしてのJSON
JSON は JavaScript をベースにしたシンプルなデータフォーマットです。JavaScript はもちろん、各種のプログラミング言語がライブラリを用意しています。
JSONをハイパーフォーマットとして使うためには、リンクを表現するメンバをきちんと入れる必要があります。
【リーダブルコード】まとめ
目次
はじめに
この記事は「リーダブルコード」を読んで自分なりにまとめた学習メモです。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (140件) を見る
１章 理解しやすいコード
コードを書く上でいちばん大切な原則
- コードは理解しやすくなければいけない
読みやすさの基本定理
- コードは他の人が最短時間で理解できるように書かなければいけない
第 I 部 表面上の改善
２章 名前に情報を詰め込む
名前を見ただけで情報を読み取れるようにすること。
- 明確な単語を選ぶ
- 例えば、Get ではなく、状況に応じて Fetch や Download などを使う
- tmp や retval などの汎用的な名前を避ける
- ただし、明確な理由があれば話は別
- 具体的な名前を使って、物事を詳細に説明する
- ServerCanStart() よりも CanListOnPort() のほうが明確
- 変数名に大切な情報を追加する
- ミリ秒を表す変数名には、後ろに _ms をつける
- これからエスケープが必要な変数名には、前に raw_ をつける
- スコープの大きな変数には長い名前をつける
- スコープが数画面に及ぶ変数に１〜２文字の短い暗号めいた名前をつけてはいけない
- 短い名前はスコープが数行の変数につけるべき
- 大文字やアンダースコアなどに意味を込める
- 例えば、クラスのメンバ変数にアンダースコアをつけて、ローカル変数と区別する
３章 誤解されない名前
最善の名前とは、誤解されない名前である。つまり、自分のコードを読んでいる人が、自分の意図を正しく理解できるということ。英語の単語は、filter・length・limit のように、プログラミングに使うには意味があいまいなものが多い。
名前を決める前に反対意見を考えるなどして、誤解されない名前かどうかを想像してみる。最善な名前というのは、誤解されない名前である。
- 上下の限界値を決めるときには、max_ や min_ を前につける
- 包含的範囲は、first や last を使う
- 包含／排他的範囲は、begin と end がイディオムなのでそれを使う
- ブール値は、ブール値だとわかるように is や has などの単語を使う
４章 美しさ
一貫性と意味のあるやり方でコードを「整形」すれば、すばやく簡単に読むことができる。
- 複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする
- コードの「列」を整形すれば、概要が把握しやすくなる
- ある場所で A・B・C のように並んでいたものを、他の場所で B・C・A のように並べてはいけない。意味のある順番を選んで、常にその順番を守る
- 空行を使って大きなブロックを論理的な「段落」に分ける
５章 コメントすべきことを知る
コメントの目的とは、コードの意図を読み手に理解してもらうこと。
コメントすべきでは「ない」こと：
- コードからすぐに抽出できること
- ひどいコード（例えば、ひどい名前の関数）を補う「補助的なコメント」。コメントを書くのではなくコードを修正する
記録すべき自分の考え：
- なぜコードが他のやり方ではなくこうなっているのか（「監督コメンタリー」）
- コードの欠陥を TODO: や XXX: などの記法を使って示す
- 定数の値にまつわる「背景」
読み手に立場になって考える：
- コードを読んだ人が「えっ？」と思うところを予想してコメントをつける
- 平均的な読み手が驚くような動作は文書化しておく
- ファイルやクラスには「全体像」のコメントを書く
- 読み手が細部に捕らわれないように、コードブロックにコメントをつけて概要をまとめる
６章 コメントは性格で簡潔に
小さな領域にできるだけ多くの情報を詰め込んだコメントを書くこと。
- 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける
- 関数の動作はできるだけ正確に説明する
- コメントに含める入出力の実例を慎重に選ぶ
- コードの意図は、詳細レベルではなく、高レベルで記述する
- よくわからない引数にはインラインコメントを使う（例：Function(/* arg = */)）
- 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ
第 Ⅱ 部 ループとロジックの単純化
７章 制御フローを読みやすくする
比較：
- 変化する値を左に、より安定した値を右に配置する
- 例：while(bytes_expected > bytes_received) → while(bytes_received < bytes_expected)
if/else 文：
- ブロックを適切に並び替える
- 肯定形・単純・目立つものを先に処理する
三項演算子（? :）・do/while ループ・goto など：
- コードが読みにくくなることが多い
- 代替となるものが必ずあるので、これらは使わないほうがいい
ネストしているコード：
- コードを追うのに集中力が必要になる
- ネストが増えるたびに「スタックにプッシュ」することが増える
- 深いネストを避けるには「直線的」なコードを選択する
- 早めに返してあげると、ネストを削除したりコードをクリーンにしたりできる
- 特に「ガード節」（関数の上部で単純な条件を先に処理する）が便利
８章 巨大な式を分割する
巨大な式を一度に理解しようと思うと難しい。巨大な式を分割して、読み手が１つずつ飲み込めるようにする。
説明関数：
- 巨大な式を分割できる
- 簡潔な名前で式を説明することで、コードを文書化できる
- コードの主要な「概念」を読み手が認識しやすくなる
ド・モルガンの法則：
- 論理式をキレイに書き直すことにも使える
- 例：if(!(a && !b)) → if(!a || b)
- 問題を「否定」したり、反対のことを考えてみたりすることが必要になる
９章 変数と読みやすさ
変数を減らして、できるだけ「軽量」にすれば、コードを読みやすくなる。
- 邪魔な変数を削除する
- 結果をすぐに使って、「中間結果」の変数を削除する
- 変数のスコープをできるだけ小さくする
- 変数を数行のコードからしか見えない位置に移動する
- 一度だけ書き込む変数を使う
- 変数に一度だけ値を設定すれば（あるいは、const や final などのイミュータブルにする方法を使えば）、コードが理解しやすくなる
第 Ⅲ 部 コードの再構成
１０章 無関係の下位問題を抽出する
プロジェクト固有のコードから汎用コードを分離するということ。
- ほとんどのコードは汎用化できる
- 一般的な問題を解決するライブラリやヘルパー関数を作っていけば、プログラムに固有の小さな核だけが残る
１１章 一度に一つのことを
- 読みにくいコードがあれば、そこで行われているタスクを列挙する
- タスクをどのように分割するかよりも、分割するということが大切
- いちばん難しいのは、プログラムが行っていることを正確に説明すること
１２章 コードに思いを込める
プログラムのことを簡単な言葉で説明することでコードがより自然になっていく。
- 問題や設計をうまく言葉で説明できないのであれば、何か見落としているか、詳細が明確になっていないということ
- プログラム（あるいは自分の考え）を言葉にすることで明確な形になる
１３章 短いコードを書く
できるだけコードを書かないこと。新しいコードには、テストや文書や保守が必要になる。また、コードが増えると「重く」なるし、開発が難しくなる。
新しいコードを書かないようにするには
- 不必要な機能をプロダクトから削除する。過剰な機能は持たせない
- 最も簡単に問題を解決できるような要求を考える
- 定期的にすべての API を読んで、標準ライブラリに慣れ親しんでおく
第 Ⅳ 部 選抜テーマ
１４章 テストと読みやすさ
テストコードでも読みやすさが大切。
- テストのトップレベルはできるだけ簡潔にする。入出力のテストはコード１行で記述できるといい
- テストが失敗したらバグの発見や修正がしやすいようなエラーメッセージを表示する
- テストに有効な最も単純な入力値を使う
- テスト関数に説明的な名前をつけて、何をテストしているかを明らかにする。Test1() ではなく、Test_<関数名>_<状況> のような名前にする
特に、新しいテストの追加や修正を簡単にすることが大切。
【Webを支える技術】第３部 HTTP 学習メモ
目次
はじめに
この記事は「Webを支える技術」を読んで自分なりにまとめた学習メモです。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者: 山本陽平
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
- 購入: 143人 クリック: 4,320回
- この商品を含むブログ (183件) を見る
第３部 HTTP
第６章 HTTPの基本
HTTP（Hyper Text Transfer Protocol）
HTTPとは、TCP/IPをベースとした Web 上でやりとりするリソースの表現を、クライアントとサーバの間でやりとりするためのプロトコルです。
TCP/IP（Transmission Control Protocol / Internet Protocol）
TCP/IPとは、インターネットの基盤を構成する重要なネットワークプロトコルです。
プロトコル
プロトコルとは、コンピューター同士が通信をする際の手順や規約などの約束事。
階層型プロトコル
インターネットのネットワークプロトコルは階層型になっています。
| アプリケーション層 |
| トランスポート層 |
| インターネット層 |
| ネットワークインタフェース層 |
クライアントで行われること
サーバで行われること
HTTPメッセージ
▶ リクエストメッセージ
- リクエストライン
- ヘッダ
- メッセージのメタデータ
- ボディ
- メッセージを表す本質的な情報
▶ レスポンスメッセージ
- ステータスライン
- ヘッダ
- メッセージのメタデータ
- ボディ
- メッセージを表す本質的な情報]
▶ HTTPメッセージの構造
| スタートライン |
| ヘッダ |
| 空行 |
| ボディ |
HTTPのステートレス性
HTTPはステートレスなプロトコルとして設計されています。
ステートレスとは、「サーバがクライアントのアプリケーション状態を保存しない」制約のことです。
アプリケーション状態（セッション状態：Session State）とは、システムの一連の操作の間の状態のことです。
- ステートフルなやりとりは簡潔
- ステートレスなやりとりは冗長
- ステートフルなやりとりでは、サーバがクライアントのそれまでの注文を覚えている
- ステートレスなやりとりでは、クライアントは毎回すべての注文を繰り返している
第７章 HTTPメソッド
8つのメソッド
| メソッド | 意味 |
|---|---|
| GET | リソースの取得 |
| POST | 子リソースの作成、リソースへのデータの追加、そのほかの処理 |
| PUT | リソースの更新、リソースの作成 |
| DELETE | リソースの削除 |
| HEAD | リソースのヘッダ（メタデータ）の取得 |
| OPTIONS | リソースがサポートしているメソッドの取得 |
| TRACE | 自分宛にリクエストメッセージを返す（ループバック）試験 |
| CONNECT | プロキシ動作のトンネル接続への変更 |
HTTPメソッドとCRUD
HTTPメソッドのうちGET、POST、PUT、DELETEは、これら4つで「CRUD（クラッド）」という性質を満たすため、代表的なメソッドと言えます。
第８章 ステータスコード
ステータスコード（Status Code）
ステータスコードとは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードのことです。
ステータスコードの分類
- 1xx：処理中
- 2xx：成功
- 3xx：リダイレクト
- 4xx：クライアントエラー
- 5xx：サーバエラー
よく使われるステータスコード
- 200 OK ―― リクエスト成功
- 201 Created ―― リソースの作成成功
- 301 Moved Permanently ―― リソースの恒久的な移動
- 303 See Other ―― 別URIの参照
- 400 Bad Request ―― リクエストの間違い
- 401 Unauthorized ―― アクセス権不正
- 500 Internal Server Error ―― サーバ内部エラー
- 503 Service Unavailabel ―― サービス停止
第９章 HTTPヘッダ
HTTPヘッダ
HTTPヘッダとは、メッセージのボディに対する付加的な情報、いわゆるメタデータのことです。
日時
例：Date: Tue, 06 Jul 2010 03:21:05 GMT
MIME（Multipurpose Internet Mail Extensions）
メッセージでやりとりするリソースの表現の種類を指定するのがMIMEメディアタイプです。
タイプ
| タイプ | 意味 | 例 |
|---|---|---|
| text | 人が読んで直接理解できるテキスト | text/plain |
| image | 画像データ | image/jpeg |
| audio | 音声データ | audio/mpeg |
| video | 映像データ | video/mp4 |
| application | そのほかのデータ | application/pdf |
| multipart | 複数のデータからなる複合データ | multipart/related |
| message | 電子メールメッセージ | message/rfc822 |
| model | 複数次元で構成するモデルデータ | model/vrml |
| example | 例示用 | example/foo-bar |
言語タグ（Content-Language）
言語タグとは、 リソース表現の自然言語を指定するヘッダのことです。
コンテントネゴシエーション（Content Negotiation）
コンテントネゴシエーションとは、メディアタイプや文字エンコーディング、言語タグをクライアントと交渉（ネゴシエーション）して決める手法のことです。
- Accept ―― 処理できるメディアタイプを伝える
- Accept-Charset ―― 処理できる文字コーディングを伝える
- Accept-Language ―― 処理できる言語を伝える
Content-Lengthとチャンク転送
- Content-Length ―― ボディの長さを指定する
- チャンク転送 ―― ボディを分割して転送する
認証
HTTPSとは、HTTPとSSL/TLSを組み合わせた通信の総称です。通信路を暗号化してクライアントとサーバの間でやりとりするデータを保護し、盗聴を防ぐ目的で主に利用します。HTTPSのデフォルトポート番号は443です。
SSL/TLSとは、インターネット上で通信を暗号化する技術のことです。
- 暗号化：共通鍵暗号に基づく暗号化機能
- 認証：公開鍵証明書に基づく認証機能
- 改ざん検知：ハッシュ用共通鍵に基づく改ざん検知機能
キャッシュ
キャッシュとは、サーバから取得したリソースをローカルストレージ（ハードディスクなど）に蓄積し、再利用する手法のことです。
- Pragma ―― キャッシュを抑制する
- Expires ―― キャッシュの有効期限を示す
- Cache-Control ―― 詳細なキャッシュ方法を指定する
- If-None-Match ―― リソースの Etag を条件にする
そのほかのHTTPヘッダ
- Content-Disposition ―― ファイル名を指定する
- Slug ―― ファイル名のヒントを指定する
【Webを支える技術】第２部 URI 学習メモ
目次
はじめに
「Webを支える技術」を読んで自分なりにまとめた学習メモです。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者: 山本陽平
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
- 購入: 143人 クリック: 4,320回
- この商品を含むブログ (183件) を見る
第２部 URI
第４章 URIの仕様
URIとは
URI（Uniform Resource Identifier）とは、リソースを統一的に識別するIDのことです。
- 統一的：全てが同じルールに従っているということ
- 識別子：あるものをほかのものと区別して指し示すための名前／ID
URIの構文
例：http://yohei:pass@blog.example.jp:8000/search?q=test&debug=true#n10
- URIスキーム（URI Scheme）：http
- ユーザ情報：yohei:pass
- ホスト名（DNS: Domain Name System）：blog.example.jp
- ポート番号：8000
- パス（Path）：/search
- クエリパラメータ：q=test&debug=true
- URIフラグメント：#n10
※ ポート番号を省略した場合は各プロトコルのデフォルト値が使われます。HTTPのデフォルト値は80番です。
絶対URIと相対URI
絶対URI（Absolute Path）：ルートから記述したパス
http://example.jp/foo/bar相対URI（Relative Path）：カレント（現在）ディレクトリから記述したパス
/foo/bar
ベースURI（Base URI、基底URI）：相対URIの起点となるパス
URIの長さ制限
仕様上はURIの長さ制限はありません。しかし、実装上は制限が存在します。特に Internet Explorer はバージョンに問わず2,038バイトまでという制限があり、事実上この長さに合わせて実装することが多くなります。
さまざまなスキーム
- URIスキームの公式一覧：Uniform Resource Identifier (URI) Schemes
- 非公式を含めたURIスキーム一覧：Uniform Resource Identifier - Wikipedia
第５章 URIの設計
クールなURIは変わらない
クールURI（Cool URI）：良いURIやきれいなURI
URIの設計指針
- URIにプログラミング言語依存の拡張子を利用しない（.pl、.rb、.do、.jspなど）
- URIに実装依存のパス名を利用しない（cgi-bin、servletなど）
- URIはセッションIDを含めない
- URIはそのリソースを表現する名詞である
URIのユーザビリティ
複雑なURI
http://example.jp/servlet/LoginServletシンプルなURI
http://example.jp/login覚えやすく、開発者ではない普通の人にも使いやすい。それがクールURIの良い点です。
URIを変更したいとき
現在運用しているシステムのURIを変更したいときは、できる限りリダイレクト（Redirect）するようにしましょう。リダイレクトとは、古いURIを新しいURIに転送するHTTPのしくみのことです。
URI設計のテクニック
コンテントネゴシエーション（Content Negotiation）：言語やファイルタイプなど複数の表現形式のファイルをサーバ上に用意しておき、ブラウザからのリクエストに応じてサーバが最適なファイルを自動的に判断してレスポンスを返す仕組みです。
マトリクスURI：複数のパラメータの組み合わせを表現するリソースの場合に用いる。例：「Google Map」
URIを強く意識する
これらの観点から、URIはWebサービスやWeb APIの設計において最も重視すべきパーツであると言えるでしょう。
【AppGoat】学習メモ
目次
はじめに
本記事について
本記事の内容の多くは IPA が提供している AppGoat からのものになります。
Webサービスなどを開発するに当たって、脆弱性を防ぐためにはどんなコードを書くべきなのかを教えてくれます！個人的にすっごく勉強になったので、記事にまとめてみたいと思いました。
本記事の内容は、AppGoat のほんの一部に過ぎないので、良かったら使ってみてください！
AppGoat とは
AppGoat（脆弱性体験学習ツール）とは、脆弱性の概要や対策方法等の脆弱性に関する基礎的な知識を実習形式で体系的に学べるツールです。
脆弱性とは
脆弱性とは、プログラムの不具合や設計上のミスが原因となって発生した情報セキュリティ上の欠陥のことです。つまり、弱点！
クロスサイト・スクリプティング（XSS）
概要
XSS（Cross Site Scripting）とは、悪意のある人が不正なスクリプトを何らかの手段でウェブページに埋め込むことで、その不正なスクリプトが被害者のブラウザ上で実行されてしまう脆弱性です。
影響
種類
- 格納型（直接攻撃するタイプ）
- 反射型（間接的に攻撃するタイプ）
- DOM型ベース
検査方法
受け取った入力データを、エスケープ処理を行わずに画面に出力している箇所があれば、クロスサイト・スクリプティングの脆弱性になります。
※ エスケープ処理：特別な意味を持つ文字を、特別な意味を持たない表記文字に置換すること
対策方法
出力する要素にエスケープ処理をします。
例（PHP）：htmlspecialchars()
SQLインジェクション
概要
SQLインジェクションとは、悪意のあるリクエストにより、ウェブアプリケーションが意図しないSQL文を実行してしまうことで、データベースを不正に操作されてしまう脆弱性です。
影響
- データベースに蓄積された非公開情報を閲覧される
- データベースに蓄積された情報を改ざん、消去される
- 認証回避により不正にログインされる
- ストアドプロシージャなどを利用したOSコマンドを実行される
※ ストアドプロシージャとは、データベースに対する一連の処理をまとめ、関係データベース管理システムに保存したものです。
種類
- 文字列リテラルに対するSQLインジェクション
- 数値リテラルに対するSQLインジェクション
検査方法
SQL文の構成時に入力された値をそのままSQL文に使用する箇所があれば、SQLインジェクションの脆弱性になります。
対策方法
プレースホルダの種類
補足
ブラインドSQLインジェクションとは、SQLインジェクションの手法の一つです。一度に1ビットの情報しか得られないため、何度もSQL文を実行する必要があります。そのため、通常はツールを用いてブラインドSQLインジェクションの攻撃を行います。
一般的には以下のことによって攻撃されることが考えられます。
- IDの重複チェックによる判断
- ログイン成否による判断
- エラーの有無による判断
- sleep句を用いたレスポンス遅延による判断
例：input_id' AND SUBSTR((SELECT password FROM user WHERE id=1), 1, 1) = 'a' --
CSRF（クロスサイト・リクエスト・フォージェリ）
概要
CSRF（Cross Site Request Forgeries）の脆弱性とは、ウェブサイトにログインしたユーザが、悪意のある人によってあらかじめ用意された罠により、意図しないリクエストを実行させられてしまう脆弱性です。
影響
- ログインしたユーザのみが利用可能なサービスを悪用される
- ログインしたユーザのみが編集可能な情報を改ざんされる
検査方法
パスワードや公開範囲などの変更、商品の購入と行った重要な操作が行える画面において、
この３つ全てを満たす場合にクロスサイト・リクエスト・フォージェリの脆弱性になります。
※ トークンとは、利用者確認のために使われる秘密情報のことです。
※ Refererとは、Webサイトに到達する参照元となったWebサイトのこと
対策方法
- hidden属性に秘密情報を挿入する
- 秘密情報として安全な疑似乱数を利用する（例：session_id）
バッファオーバーフロー
概要
バッファオーバーフローとは、外部からのデータなどによって、プログラムが用意したメモリ領域からデータがあふれてしまうことで発生する脆弱性です。
影響
- プログラムが異常終了させられる
- 外部から任意のマシンコードが実行される
種類
- スタック領域におけるバッファオーバーフローの脆弱性
- ヒープ領域におけるバッファオーバーフローの脆弱性
検査方法
入力された値がバッファからデータがあふれて処理が中断した箇所があれば、バッファーオーバーフローの脆弱性になります。
対策方法
- 安全な関数を利用する
- 動的にバッファを確保する
【Webを支える技術】第１部 Web概論 学習メモ
目次
はじめに
はじめまして、入社して間もない駆け出しのエンジニアです。エンジニアとして、基礎を磨くために今後定期的にブログを更新していきたいと考えています。というわけで、まずはWebからやっていきたいと思います！こちらの技術書はとても有名な本なので、個人的におすすめです！
そして、ブログを書くのは初めてなので、自分なりに理解してまとめたメモを書いてみたいと思います。皆さんお手柔らかに。。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者: 山本陽平
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
- 購入: 143人 クリック: 4,320回
- この商品を含むブログ (183件) を見る
第１部 Web概論
第１章 Webとは何か
Webとは
一言で説明するのであれば、
Web（World Wide Web, WWW）とは、「蜘蛛の巣」をイメージした世界中の人々と情報を繋げる場所のことです。
そして、Webを閲覧できるソフトウェアがブラウザ（Browser）です。
Webを支える最も基本的な技術
- URI（Uniform Resource Identifier）：世界中のあらゆる情報を指し示せる
- HTML（Hypertext Markup Language）：それらの情報を表現する文章フォーマット
- HTTP（Hypertext Transfer Protocol）：それらの情報を取得したり発注したりできる
Webは、情報システムとして見ると２つの側面を持つ
- ハイパーメディアシステム（Hypermedia System）：テキストや画像、音声、映像など様々なメディアをハイパーリンク（Hyper Link）で結び付けて構成したシステム
- 分散システム（Distributed System）：複数のコンピュータを組み合わせて処理を分散させるシステム
第２章 Webの歴史
Web以前
- Web以前のハイパーメディア
- 問題点：高機能ゆえの複雑さ
- Web以前の分散システム
- 問題点
- ネットワークのオーバーヘッドが呼び出し回数分かかるという性能劣化問題
- プログラミング言語ごとのデータ型変換の問題
- インターフェースバーションアップ時の互換性の問題
- 多数サーバの負荷分散の問題
Webの誕生
- ハイパーメデイアとしてのWeb
- Webはインターネットを使ったハイパーメディアとして設計された
- 利点：不特定多数の情報をリンクさせ合うことができ、システムを大規模化しやすい
- 欠点：情報の集中的な管理が難しく、リンク切れを起こしやすい
- 分散システムとしてのWeb
- 利点：分散システムを実現するための技術の一つであるRPCは閉じたネットワーク環境で、あらかじめ想定した数の種類のクライアントを相手にサービスを提供するシステムとしては優れている
- 欠点：オープンなネットワーク環境で、不特定多数のクライアントに対してサービスを提供するシステムには向いていない
第３章 REST ―― Webのアーキテクチャスタイル
RESTとは
RESTとは、Webのアーキテクチャスタイルです。
アーキテクチャスタイルは複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す言葉です。
リソース ―― RESTにおける重要な概念の一つ
RESTは次の６つを組み合わせたアーキテクチャスタイル
- クライアント／サーバ：ユーザインタフェースと処理を分離する
- ステートレスサーバ：サーバ側でアプリケーション状態を持たない
- キャッシュ：クライアントとサーバの通信回数と量を減らす
- 統一インタフェース：インタフェースを固定する
- 階層化システム：システムを階層に分離する
- コードオンデマンド：プログラムをクライアントにダウンロードして実行する
※ Cookie を使ったセッション管理はステートレスではないので、利用するときはステートレスの利点をあえて捨てることを理解したうえで、必要最低限利用しましょう。
