【Udemyメモ】 【基礎からわかる！】Webアプリケーションの仕組み

【基礎からわかる！】Webアプリケーションの仕組み

というUdemyの講座を約2年前に、入門、学びなおしを目的として、取り組んだ際のメモをここに記載します。
セクションのタイトル、メモの内容、という形でまとめます。

基礎的すぎて多くの記事などで言語化すらされていないことまで網羅されているので良かったです。

たとえばMetaの提供しているweb applicationの講座

には、このような歴史的背景についての説明はありませんでした。

そしてなんと、以前はUdemyだった本講座は現在Udemyからは無くなっていて、
Youtubeに移行されていました。助かりますね。

２．webアプリケーションの歴史

２．webアプリケーションの歴史

【WWW、HTML、Mosaic】
・インターネットの歴史をまず理解　webappの歴史は、wwwの歴史と深い関係がある。
・インターネットが生まれたきっかけ
アメリカで起きた爆破事件。国防の通信システムがダウン
中央の交換機を破壊されたらすべての通信がストップ
→分散型ネットワーク通信の仕組みを考えることに。
・電信のしくみで伝達→これをコンピューターで実現しよう。
・メッセージブロック・・・データを丸ごと送るのではなく分割して送る。
→パケット分割方式
・メッセージの本文とは別に、目的地やメッセージの通し番号もセットで送る
→ヘッダ
・バラバラの道を通ろうと、目的地に届いて、番号をもとに再構成できれば良しとする
→TCPIPと同じアイデア
・ARPANET
→大学や研究機関のコンピュータ同士を結び付けて情報やリソースを共有できるようにする。
・HTML
→マークアップ言語。タグで囲まれた部分で、webページを記述。
・hyper text
→他のwebページへのリンクや図表を表示させる機能
・NCSAMosaic
→webブラウザの原型のソフトウェア。1枚のwebページで文字と画像を一緒に表現
WWWが登場した当初のブラウザは、文字だけしか表示できなかった。
このNCSAMosaicをマークアンドリューセンが開発し、文字と画像両方を表示できるようになった。
・Mosaic （webブラウザ）+ WWW (簡単に誰もが情報を公開）でウェブ技術は爆発的に進化。
・webシステム→リクエストとレスポンスで成り立つ。

【クライアントサーバーシステム】
・クライアントサーバーシステムなぜ役割が分けられている？
→メインフレームの時代には、1台の大型コンピュータですべてのデータを処理。
役割を分けるのは、負担を分散させるため。

【URL】
http://www.example.jp/contents/index.html
http:// スキーム・・・どの方法で？（通信方法の手段）
www.example.jp　ホスト名・・・サーバーの住所。あくまでwebサーバーの場所。
/contents/index.html　パス名・・・サーバーの中でどのコンテンツかを表す。
www.　ローカル名
example.jp　親ドメイン名

【HTTPプロトコル】
HTTP（hyper text transfer protocol)
→ハイパーテキストを転送するためのプロトコル
プロトコル
→通信をするための約束事
http以外にもプロトコルはたくさん
・https 暗号化されたhttp通信を表す
・mailto 電子メールの宛先を表す
・ftp FTPプロトコルによる入手を表す
・file ファイルやディレクトリを参照する

【CGI】
なぜCGIを学ぶ？
→クライアントサーバー、URL、HTTPだけでは、webアプリケーションを作ることはできないから！
CGI(common gateway interface) クライアントからのリクエストに対して、サーバーが新たにHTMLファイルを作って返す仕組み。
静的コンテンツを表示させる以上のことをしたい。
プログラムが新たなページを作るようにしたい。
例.検索サイト、掲示板システム、ショッピングサイト
→これらはクライアントがサーバーに働きかけることで実現
→これらを実現したのがCGI
PerlやC言語でHTMLを作成することができる。こういったPerlなどのプログラムをwebサーバーに付け加えることで、
そこで、新たにHTMLファイルを作成できる。
この作成したHTMLを異なる機器間で通信を可能にするのが、CGI(Common Gateway Interface)
→CGIによってwebサーバーとプログラムを連携させることができる。
CGIとは連携用の通路。
プログラム、サーバー、クライアントがHTMLをやり取りするイメージを持っておくのが重要。
？異なる機器、っていう説明は微妙な気もする。

【Java オブジェクト指向】
CGIの登場によってネット検索や掲示板など動的コンテンツの作成が可能になったが、、、、
CGIに問題点があった。
・Perlが大規模開発に向いていなかった。
→Perlはあくまでテキスト処理が得意な言語。大規模アプリケーションには向いていない。
・CGIではレスポンスには時間がかかる
CGIでは、レスポンスの度にプログラムを起動
→リクエストが多いと、処理が追い付かなくなってしまう。

【Java/サーブレットの登場】
java
・webアプリの複雑化大規模化に対応
→オブジェクト指向の機能を備えているため！
オブジェクト指向⇔プロセス指向
プロセス指向　小さな部品（関数）を使ってプログラムを作る。
オブジェクト指向　大きな部品（クラス）を使ってプログラムを作る。
サーブレット
・CGIではHTMLの作成に時間がかかった。
なぜサーブレットは作られた？
→webアプリの開発をサポートするため。元々javaは、webアプリのための言語ではなかった。
サーブレットとは？
→サーバー上で動くJavaのこと。
サーバー上で動くjava　
・HTMLファイルの作成をjavaでできる。
・WebサーバとJavaを一緒に動かせる。
→サーブレットはCGIとほぼ同じだが、javaに対応していること、Webサーバーと同じプロセスで動かせること、
がメリット。同じプロセスなので、高速でHTMLファイルを作成可能になった。
加えて、javaは、OSやハードに依存しないというメリットがある。
java VMによって、Javaで作ったプログラムを翻訳し、それぞれのOSで実行可能なコードに変換してくれる。

【JSP】
java/サーブレット開発による問題点。
1枚のHTMLでプログラムとデザインを行うと複雑になってしまう。
また、プログラムを開発をする人と、画面のデザインをする人を、分ける仕組みが必要とされた。
→JSP（Java Servlet Pages)の登場！
→HTMLの中にJavaプログラムを埋め込む。動的に出力したい部分を%で囲む。

【フレームワークの登場】
・全てのwebアプリを0からjavaで作っていては、時間と労力がかかってしまう。
・プログラムが複雑すぎると安定して運用できない。
→巨大なWebアプリを作るには、再利用する！
→フレームワーク　システム開発を楽に行うために用意されたプログラムのひな型。

【セクション２まとめ】
WWW誕生、クライアントサーバー、URL、HTTP、CGI、Java、サーブレット、JSP、フレームワーク

3. get post

S3 HTTPについて。

【パケットキャプチャ】
パケット　リクエスト、レスポンスとは、パケットをやり取りしているということ
パケットの中身を見るには、パケットキャプチャツールが必要。
httpやhttpsのパケットキャプチャツール→Fiddler

【テキストのみのwebページのパケット】
8種類のメソッド
get post put delete head options trace connect
get postがメイン
リクエストライン
GET http://XXX/get_request1.html HTTP/1.1
GET GETメソッド　URIの中に欲しい情報を指定するリクエスト方法
http://XXX/get_request1.html　URI (URLとほぼ同義）どのコンテンツが欲しいのか
HTTP/1.1　HTTPバージョン HTTPのversionによって使えるメソッドなどが変わる
メッセージヘッダ
ヘッダ　付加される情報。一番重要な情報はリクエストライン
Host
Connection
Upgrade-Insecure-Requests
User-Agent
Accept
Referer
Accept-Encoding
Accept-Language

【テキストのみのwebページのレスポンス】
レスポンスの中身はどのようになっている？
HTTP/1.1 200 OK
HTTP/1.1 HTTPバージョン
200 ステータスコード
OK レスポンスフレーズ
ステータスコード一覧
200 OK リクエストが正常に完了
302 Found リソースが一時的に別のURIに所属
304 Not Modified キャッシュから表示
401 Unauthorized ユーザー認証に失敗
403 Forbidden アクセス権限がないため拒否
404 Not Found URIが存在しない場合
500 Internal Server Error サーバー内部でエラー発生

【画像のみのwebページのバケット】
2回リクエストが行われる。
1回目　get メソッド　サイトのHTMLを返す
2回目　get srcから、画像ファイルを取得
画像の数だけリクエストを発行しないといけない。

【getメソッドによるパラメーター渡し】
http://XXX/do_calc_get.php?arg1=12&arg2=34
?arg1=12&arg2=34 クエリ文字列　サーバーに情報を送るためURLの末尾に付け足す文字列
phpもjspと同じように、プログラムに変数を埋め込める

【postメソッドによるパラメータ渡し】
getメソッドによるパラメータ渡しの問題点と、なぜpostメソッドが生まれたか
getメソッドによるパラメータ渡し　問題点
・サーバーログに記録が残るので、情報がバレてしまう
・URLの長さが255文字に制限されている場合も
Postメソッドとは？
メッセージボディに情報を入れて、送る方法
http://XXX/do_calc_get.php?arg1=12&arg2=34　これみたいに、パラメータがURLに、
表示されることはなくなる。
長さも制限がなくなる

【Get Postどちらを使う？】
Getメソッド　メリット
・URIに情報が含まれるので、他の人に伝えやすい
ブラウザの検索に使われている。
URIに含まれているので、お気に入り登録、ができる！
・Getリクエストの処理は結果に影響しない
→副作用がない、と言う。
セキュリティの高さと、パラメータの長さに制限がないことが、
postメソッドのメリット。

4. cookieとセッション

s4 Coolieとセッション

【Cookieとセッションのメリット】
・ログインの状態を継続させたまま、webページを見れる
・カートに商品を入れたまま、ネットショッピングができる
HTTPでのログイン問題を考える
→前回までのやり取りを覚えることができない

【PHPによるログイン認証】
リダイレクト
クライアントとサーバーがやり取りすることで、
最初の要求とは別のページを表示させる
例　
C　login.phpください
S　ここではなく、item_listをみてね
C じゃあitem_listください
S　item_listどうぞ

【リダイレクトのパケットキャプチャ】
【ステートフルステートレス】
PHPでログイン認証を作れたが、、、URLがわかれば誰でもアクセスできてしまう。
HTTPの問題点　要求されたことを返すだけ
・たくさんの情報を処理することが目的だから
HTTｐが作られる前に、FTPやSMTPなど他のプロトコルはあった。
WWWは世界中からのリクエストを1台のサーバーで処理しないといけない。
→相手がだれであろうが、値を返す
・高度な使い方を前提にしていない
→もともとは研究者が研究成果を共有するためのものだったから。
ログインとかを意図していない。
ステートレス　前回までのやり取りを覚えておくことができない。
なぜステートレス？　すべてのやり取りを記憶して、次回のやり取りに生かしているとデータの量が莫大になってしまうから。
1回のやり取りで処理が完結するというのはメリットでもある。
ステートフル
直前にやり取りした相手の状態を、以降のやり取りでも覚えていること。
ex.HTTPよりも古いFTPプロトコル

【Cookieによるログイン認証】
Cookieとは？
サーバーからブラウザに渡すメモ書き
（レスポンスヘッダに入れて渡す情報）
サーバーは相手を覚えていることができないので、メモ書きを渡して相手を特定するようにした。
新たなリクエストでも、メモ書きを見て相手を特定する。
Cookieがどこに入るか？どのように書かれているか？
・1度目のリクエストでクッキーを渡す
・2度目のアクセスからは自分でクッキーをもっていく
メッセージボディの中にクッキーが入る。
ログアウトの際、クッキーを削除するコードが書かれている。
CookieはNetscape Communications社によって開発
非常に便利な技術であったためInternet explorer など他のブラウザにも採用され、
その後RFC2695で標準化

【セッションによるログイン認証】
Cookieによる通信の問題点
ヘッダの中を見れば情報（ユーザー名パスワードなど）がまるわかりになっています。
クロームでもディベロッパーツールから、cookiesが見れる。
よってよりセキュアな仕組みが生まれた
それがセッション
セッション
受付番号をつかってユーザーを特定する仕組み
→番号のみをやり取りし、丸裸の情報は扱わない。
セッションを使ったやり取り
情報を受け取ったサーバーは、ユーザーに対して受付番号（セッションID)
を発行。
セッションIDによって相手を識別。
セッションIDはサーバー上で保管
（クッキーはブラウザで保管）
CookieもセッションIDも、ヘッダの中に格納される
（丸裸の情報か、受付番号か、の違い）
セッションでは、
Cookie:PHPSESID=XXXXX
とセッションIDが記載される。

5.　webアプリの構成

【DBの概念、５つの種類】
DB コンピューター上で実際に扱う情報のこと
DBMS データベース管理システム。データベースを管理し、扱うためのソフトウェア。
RDBMS リレーショナルデータベースを扱う、データベース管理のソフトウェア。
階層型データベース　データをヒエラルキー構造で管理するDB　データベースの歴史で一番最初に登場
リレーショナルデータベース　二次元表の形式で管理するDB　最も主流
NoSQLデータベース　SQLを使わないDB　RDBの機能を一部捨てて、パフォーマンスを追及

【リレーションナルデータベース】
関係データベース、関係型データベース
数学でいう「二次元表」のこと。
・二次元表でデータ管理を実現
・複雑なプログラミング言語を使わずDBを操作可能

【SQL CRUD DB製品】
SQL　シンプル。ループや条件分岐など不要。
代表的なDB製品
Oracle Database 最も大きなシェア。機能や動作速度、信頼性は抜群。
Microsoft SQL server Windowsとの相性が抜群
PostgreSQL オープンソースとして公開されており、ほとんどの環境で使用可能
MySQL オープンソースとして無料で使用することができる

【SQL発行、クエリ取得】
webブラウザ　webserver リクエストのやり取り
webサーバーとDBサーバーのやり取り　SQLの発行とクエリの取得でやり取り

【DBサーバーの構成】
SQLだけでは情報をやり取りできない。HTTPのような通信のプロトコルが必要。
DBとの通信プロトコルはHTTPのように標準化されていない。
通常、WEBサーバーに、データベースにアクセスする部品である、DBライブラリがある。

【アプリケーションサーバーの構成】
サーブレット/JSPはwebサーバーと同じプロセスで動く。
APサーバーがプログラムを動かすのが基本。
ただし、javaの場合は、java VMが土台となる。

【webサーバーとAPサーバーの連携】
前提：異なるプロセスを連携させるには新たな方法が必要
ex.HTTP通信、DBライブラリ
apach mod_jk を通って、apatchからtomcatへ。
apath tomcatの場合。
ajp13と呼ばれるtomcat独自のプロコルで通信。

【リクエストの転送方法(Apatch,Tomcat】
転送するリクエストをどう見分ける？
URLによってAPサーバーに送るリクエストを見分ける。
tomcatに関する情報を記述したファイル
workers.list=worker1
worker.worker1.host=localhost　web webappを分離させていないのでlocalhost
worker.worker1.port=8009
worker.worker1.type=apj13
workers.list=worker1
これから接続するtomcatのtomcatワーカにworker1と名前を付ける。
tomcatワーカ
接続先となる、Tomcatワーカのプロセスのこと。
なぜわざわざworker1を定義する？
→台数を増えた時に、tomcatの処理先を割り振るため。
Apacheの設定ファイル(httpd.conf)
JkWorkersFile /usr/local/apatch2/conf/workers.properties
JkLogFile /usr/local/apatch2/logs/mod_jk.log
JkLogLevel info
JkMount /delicious/burger* worker1
JkWorkersFile /usr/local/apatch2/conf/workers.properties
HTTPリクエストの転送先をworkers.profilesに指定。
JkMount /delicious/burger* worker1
/delicious/burger*以下のものをworker1に変える。

【WebサーバーとAPサーバーの分離】
tomcatに関する情報を記述したファイル
tomcatのhost名を指定。
worker.worker1.host=178.148.1.2
とすることで、分離させても通信が可能。
webサーバー　回数は多いけど処理は軽い
APサーバー　和は少ないけど処理は重い
worker2と増やせば、APサーバーを増やすことが可能。
APサーバーがwebサーバーの機能も持つので、webサーバーなしにする場合もある。

【Web三層構造】
Webサーバー、APサーバー、DBサーバーの３つに分けて運用すること。
障害に強く、柔軟に変更できるようになる。

6. 効率的なwebアプリの開発

【JSPとサーブレットの連携】
画面の表示がJSP login.jsp
実際のログイン処理が サーブレット　
JSPはどうやってサーブレットを呼び出すか。
異なるプロセスなので、連携させる必要がある！
web.xmlファイルに定義されている。
urlでクラスを呼び出す。

【リクエストパラメータ】
リクエストスコープとは？
1回のリクエストレスポンスで、データが保持される仕組み。
リクエストスコープへの変換
String user = request.getParameter("user");
request.setAttribute("user",user);
なぜリクエストスコープを使う？セッションでできるのでは？
→セッションＩＤはcookieの仕組みを利用しただけで、それを破棄する仕組みがない。
セッションタイムアウトがある！
一定時間が経ったらセッションを削除。tomcatならデフォルト30分など。
けれど、セッションは多くのメモリを使う。
そのため、リクエストスコープの仕組みが生まれた。

【MVCモデル】
Model 内部の処理に関する部分
View 画面の表示に関する部分
Controller 全体の流れを制御する
３つは完全に独立。

【Strutsの内部構造】
Struts MVCモデルを採用。
Apatch software foundationsによって、開発、公開、されている。
フレームワーク　webアプリケーションを効率的に開発するためのひな型。
アクションサーブレット　リクエストをすべて引き受ける。　リクエストプロセッサを呼び出す
リクエストプロセッサ　コントローラーの役割。すべての流れを制御
アクション　リクエストによって呼び出される異なる処理。アクションフォームbeanから取り出す。
XML URLのパターンとアクションの対応が記載されている。
アクションフォームBean リクエストパラメーターを解析して、アクションフォームbeanというクラスに格納
JavaクラスEJBなど　モデル。アクションによって呼び出され、実際の処理を行う。リクエストプロセッサに返す。
JSP画面を作る。　モデルで処理されたリクエストを、リクエストプロセッサから受け取る。View

7.　セキュリティ

【SQLインジェクション】
select * from USER where PASSWORD='aaa' or '1'='1'
内部のデータ構造を把握する必要があるが、エラーメッセージなどの手がかりから、
探られてしまう。
防ぐには？　
・入力値のチェック（バリデーション）
ex1. パスワード入力を半角英数字にして「’」を防ぐ。
ex2. 入力する文字を厳格に指定する
・プリペアードステートメント
そのままSQLでチェックするのではなく、先に用意した変数に格納してチェックする。
PreparedStatement st = conn.prepareStatement("select * from USER where NAME=? PASSWORD=?);
st.setString(1,Name);
st.setStirng(2,password);
これによって条件の追加など、あとからの変更を防げる。
【クロスサイトスクリプティング（XSS)】
HTMLフォームの中に悪意のあるJavaScriptを埋め込む攻撃
レスポンスの中に埋め込み、Webブラウザに実行させる。
javascriptインジェクションとも呼ばれる。
XSSできるのは？
フォームに入力された文字をそのまま、次のHTMLだけで完結する場合。
これによって実行される悪意
・偽サイトのリンクを貼りつける
GETリクエストを用意してJavaScriptを利用し、偽のサイトへ飛ばす。
防ぐには？
・サニタイジング
HTMLに埋め込むと、構造を変更してしまう文字列を無害に

↓
<script>alert('XSS')</script>
実行環境がサニタイジングの機能を有しているときもある。
【セッションハイジャック】
セッションIDを盗み取って、本人に成りすまして攻撃
対策
・クロスサイトスクリプティングを対策する
・通信経路の暗号化
通信路をSSL(secure sockets layer)によって暗号化
特殊な機材やソフトでの盗聴を防ぐ
・セッションタイムアウト値の変更
セッション情報は意図的に破棄しない限り、タイムアウトが発生まで
サーバーに保持される。
・セッションIDのランダム化
IDの桁数を大きくして、数字をランダムに選択する。

【クロスサイトリクエストフォージェリ(CSRF)】
攻撃者が用意したフォームから強制的にリクエストさせる
掲示板に書き込みをさせたり、ネットショッピングさせたりする。
・リンクを攻撃者が仕掛けたJSにしておく。
Webページを開く＝リクエストを送る
別サイトに強制的に情報を送らされたりする。
対策
自分たちが用意したフォーム以外を実行させないこと。
ワンタイムトークンを発行
ユーザーごとにこれを発行。サイト側が発行したトークンをもっていなければ、
処理を行わないようにする。
攻撃者が用意したフォームがあっても、実行できないようになる。
【強制ブラウズ】
WebブラウザのアドレスバーにURLを直接入力し、表示されないはずのページ
表示させる。
↓
ログイン画面をとばしていきなり会員画面に入れさせられる。
webサーバーやAPサーバーに問題がある場合に仕掛けられる。

【ディレクトリトラバーサル】
表示してはいけないファイルの位置を相対パスで指定させて、
アクセスする攻撃。
/home/koukai/koukai.txt
/home/himitsu/himitsu.txt
↓
https://XXX.co.jo/?file=koukai.txt
https://XXX.co.jp/?file=../himitsu/himitsu.txt
対策
サニタイジング
ファイル名に使わない文字を削除することが有効

引用元

関連記事

同時期にLinuxの勉強とセキュリティの勉強もUdemyでやってました。
これらの講座もオススメです。
セキュリティの方は特に一度、Udemyのページを見てみてください。
講師の方の怪しい魅力があります。

感想など

基本情報などを受けていない自分にとって、この辺をやってからAWS資格のpro資格やspecialtyに挑めたのは、
良かったんじゃないかと振り返って思いました。
以下は当時の感想です。

【2】
歴史に触れることで、背景知識が増えて理解が深まった。なぜjavaができたのか、など。HTML、Perl、CGI、java、サーブレット、JSPとつながる過程や、そもそもwebとは？など理解できた。

【3】
fiddrerを使うことで、パケットを見る、というのを体験する内容で良かった。
postメソッドgetメソッドの違いを理解できた

【4】
クッキー、セッション、ステートレスステートフルについて理解できた。

PHPでログイン認証を作れたが、、、URLがわかれば誰でもアクセスできてしまう。
HTTPの問題点　要求されたことを返すだけ
・たくさんの情報を処理することが目的だから
HTTｐが作られる前に、FTPやSMTPなど他のプロトコルはあった。
WWWは世界中からのリクエストを1台のサーバーで処理しないといけない。
→相手がだれであろうが、値を返す
・高度な使い方を前提にしていない
→もともとは研究者が研究成果を共有するためのものだったから。
ログインとかを意図していない。
ステートレス　前回までのやり取りを覚えておくことができない。
なぜステートレス？　すべてのやり取りを記憶して、次回のやり取りに生かしているとデータの量が莫大になってしまうから。

このあたりの説明がわかりやすかった。

【5】
データベースは知っていることが多かった。
データベースやアーキテクチャなど。
tomcatのワーカーの説明など、特にwebサイドの通信面で知らないことが多く、勉強になった。
また前提：異なるプロセスを連携させるには新たな方法が必要
ex.HTTP通信、DBライブラリ
というプロセスを連携させるという観点は知らなかった。
（今までなんとなく、このjarで連携している、みたいなことは聞いたことがあったが、よくわかっていなかった）

【6】
web.xml、サーブレットなど、
言葉は知っていたが、ずっとしっくりきていなかったワードが理解できた。
リクエストスコープなど、まったく知らなかった知識だった。
MVCの詳細な説明は難しかったが、Strutsを例に説明されていて、詳細な部分を確認できた。

【7】
知っていることも多かったが、
前回までに学んだことを使って、説明されているのが良かった。
XSSの説明で、
GETリクエストを用意してJavaScriptを利用し、偽のサイトへ飛ばす。
のようにGETリクエスト、という言葉を使って説明されているなど。