なぜWEBアプリケーションフレームワークを使う必要があるのか
2019/01/02 - moriya - ~3 Minutes
私が使ったことのあるWEBアプリケーションフレームワークは、以下のようなものだが、どれもすばらしいと思った。
Python | Django |
---|---|
PHP | Zend Framework |
Java | Spring Framework |
Golang | ECHO |
私は、WEBアプリケーションフレームワークを使ったほうがよいと考える。
セキュリティ
言語そのままの機能だけで、以下のような脆弱性をカバーしきれるであろうか。(他にもあるが大物だけ挙げた)
- クロスサイトスクリプティング(XSS)
- SQLインジェクション
- クロスサイトリクエストフォージェリー(CSRF)
CSRF
特にCSRF、割と大物だと思うが、理解されているのだろうか、と思うことがあるので少し書いておきたい。
GET で取ってきた form は次のようなものだろう。
<form method="post" action="どこかのURL">
:
</form>
この form を POST するのであるが、このままだと、この form は POST しようとしているサイトから受け取る必要はなく、どこからもらってきてもよいし、それは、プロトコル的には許されている。さて、POSTすると、おそらく用心深い人でなければログイン状態を維持しているであろうから、このPOST自体は通ってしまうだろう。適当なサイトに置かれた適当に hidden で値を埋められたような form だとどうだろうか。(例えば、メールのリンクなどをクリックして表示した場合はどうだろうか。)
そういったことを防ぐため、GET 時、form を送信するサーバが、ランダムな値を form 等に埋め込んで(典型的には、csrftoken)、POST 時にサーバで発行した乱数値と同じかどうかチェックする。
一般的には、CSRF対策はフレームワークに内蔵、もしくは、拡張機能として装備されている。
セッション管理
昔 OSI 7階層モデルを教えてもらった時、これはすばらしい考え方だ、と思ったが、ログインからログアウトまでをセッションだと言われ、唯一、何を言っているのか私にはさっぱりわからなかったセッション層。
例えば Amazon にログインした後、使っているノートPCを別の場所に持っていっても、移動前と同じ状態で作業できるのは不思議ではないだろうか。そういったことを実現しているのがセッション層だろう。
ログインした後は、セッションIDが発行され、リクエストのどこかにセッションIDが含まれているはずだ。(ブラウザの developer tool で network を見てみるとよい) サーバは一定時間、もしくは、ログアウトするまでそのIDを覚えているので、どのセッションのリクエストかがわかる。
WEBアプリケーションフレームワークでは、セッションを作ったり、セッション毎に変数を覚えさせたりすることができるようになっている。(例えば複数ページに渡る form がある時、各ページの入力値をセッション変数に記憶させるなど)
これら、言語標準の機能だけでは難しいだろう。
テンプレート
表示のための雛形。変わる部分は変数名やオブジェクト名等を入れておく。
そうすることでデザイン(見た目という意味での)と、コードを分離することができる。
分離するメリットは、分業できたり、画面レイアウトだけ修正したい時にテンプレートを修正するだけでよくなる点だろう。
URLとコードの対応づけ
router と呼ばれたり、request mapping と呼ばれたりもしている。
あるURLに対するGETはこの関数、あるURLに対するPOSTはこの関数、といった定義ができる。
また、URLに含まれるパターンも合わせて定義することができる。
例えば、/owners/{ownerId}/pets/{petId}のようなパターンが定義可能だ。
まとめ
私は、これらの機能をまず見るが、他にも便利、セキュアな機能、また、クライアントサイドのための機能も随分盛り込まれているので、tutorial などを試されてみてはいかがだろうか。