Lesson2：リクエストとレスポンスを繰り返し，必要なコンテンツを持ってくる
Lesson2では，WebブラウザがHTTPを使ってWebページを表示するまでの流れを見てみよう。Webアクセスの裏側で，WebブラウザとHTTPがどのような動作をしているのかに注目する。 HTTPを使うことが明記されている HTTPは，要求（リクエスト）と応答（レスポンス）という二つのメッセージで成り立っている。WebブラウザからWebサーバー・ソフトに向かうのがHTTPリクエストで，そのリクエストに対する応答がHTTPレスポンスになる。Webアクセスは，このやりとりを繰り返すことで実現している（図2-1上）。 図2-1●要求と応答を繰り返して必要なデータを集める HTTPで使われるメッセージは，要求（HTTPリクエスト）と応答（HTTPレスポンス）の二つ。この二つのやりとりを繰り返して必要なデータを集める。 [画像のクリックで拡大表示] ユーザーがWebブラウザのURL欄に「http:
韓国の大規模サイバー攻撃は非正規Windowsサーバーのパッチ配布が原因
3月20日に韓国で発生した大規模サイバー攻撃（関連記事1、関連記事2）。同時多発的に発生していることから、ウィルスを用いたサイバーテロ（サイバー戦争）という話が最も有力になっている。 筆者は、今回の事件は、韓国における非正規Windowsの存在が引き金になったと推測している。なぜ、そのように判断したか、順を追って解説してきたい。 まず、2003年に大流行したSQL Server 2000に感染するSQL Slammerというウィルスの存在を思い出してほしい。あのときは、米国と並んで韓国でも大きな騒動となり、一時インターネットが使えないなどの大混乱となった（関連記事3、関連記事4）。その大きな要因は韓国内で大量の海賊版Windowsを利用されていたことで、複数のサーバーで適切な運用及びセキュリティパッチが適用されておらず、そのため韓国内でウィルス感染が一気に広がり、韓国内のインターネットがダ
まだまだあるクロスサイト・スクリプティング攻撃法
前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明
第1回 まずは「クッキー」を理解すべし
Webアプリケーションのぜい弱性がなかなかなくならない。メディアなどでも盛んに取り上げられているにもかかわらず，である。特に，セッション管理がからむアプリケーションのぜい弱性には，気付かないことが多い。具体的には「クロスサイト・リクエスト・フォージェリ」（CSRF），「セッション・フィクセーション」などである。これらはクロスサイト・スクリプティング，SQLインジェクションといった比較的メジャーなぜい弱性に比べて認知度が低く，対策も進んでいない。 原因の一つは，アプリケーションの開発者が原因を正しく理解していないこと。CSRFやセッション・フィクセーションについて言えば，セッション管理に使うクッキー（cookie）の動作を理解していないと対策が難しい。ところが最近の開発環境では，セッション管理の仕組みが隠ぺいされているため，必ずしもこの知識は要求されない。こうした開発者は容易にはぜい弱性に気
第4回 サーバー側で管理する「セッション変数」に要注意 | 日経 xTECH（クロステック）
最近になってセッション変数を使用したアプリケーションを見かけるケースが増えてきている。セッション変数とは，セッションIDとひも付けてサーバー側に格納する変数のことである。開発環境により実装の仕方は様々だが，ログイン成功時に保存される認証情報もセッション変数の一つである。 セッション変数をサーバーに格納すると，アプリケーションはセッションが有効な間，変数の値を再利用できる。これにより，例えばクライアントから送信された大量の入力項目をサーバー上で保持しながら複数の画面を遷移するようなアプリケーションを比較的容易に，かつ低コストで実装できるようになる。 筆者がアプリケーションの開発現場にいたころは，サーバー・リソースを圧迫するという理由から使用を控えていることが多かったが，マシン・スペックの向上や，アプリケーションに要求される機能の複雑さの向上といった背景により事情が変わってきているようだ。 実
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
