![Amazon.co.jp: ソースコードリーディングから学ぶ Javaの設計と実装: WINGSプロジェクト佐藤匡剛 (著), 山田祥寛 (読み手): 本](https://cdn-ak-scissors.b.st-hatena.com/image/square/c579d3414409401e53f452d0eafdf6e411724721/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F4169CSHV2AL._SL500_.jpg)
HTTPを使用したWebアプリケーションにおいて、安全なセッション管理を行うことは難しい問題である。タブブラウザによる画面の複数起動や、Webブラウザの戻るボタン/更新ボタンの押下といった、予期しない画面遷移に起因するバグの発生に頭を悩ませることは多いだろう。 大きな問題が発生しないならば、画面遷移の仕様上の制限をクライアントに許容してもらう選択肢もあるだろうが、不正な画面遷移を利用したセキュリティホールが存在するならば、放置しておいてよい問題ではなくなる。今回はセッション管理を安全に行うための基本的な注意点について解説していこう。 セッション固定攻撃とは何か セッション固定攻撃(Session Fixation)という脆弱性を耳にしたことはあるだろうか。脆弱性そのものの詳しい解説は本稿の趣旨ではないため割愛するが、簡潔に説明すると、以下のような手順を踏むことによりセッション情報がハイジャ
本記事は2006年に執筆されたものです。RubyやRuby on Rails全般の最新情報は@IT フォーラムをご参照ください。 Javaエンジニアの皆さんにとって、最近気になるテクノロジーとして「Ruby On Rails(以下、Rails)」が挙げられるのではないでしょうか。 インターネットを使って、Railsについて少し調べてみると、いろいろと刺激的なキーワードが並んでいることが分かります。例えば、もう誰もが用語として知っているAjaxへの標準対応であったり、「Javaの10倍の開発生産性」「ブログサイトが15分でできる」といったようなパフォーマンスを強調する触れ込みであったり、「DRY」「Convention over Configuration」といったRailsの思想を表す目新しいキーワードであったりします。 逆に、Railsの概要を紹介する文に必ず書かれている「MVCアーキテ
サーブレットコンテナが抱える問題を認識する:Strutsで作るセキュアWebアプリケーション(2)(1/3 ページ) 第1回「適切なエスケープ処理でクロスサイトスクリプティングに備える」では、Strutsカスタムタグを使用する際の注意点を解説した。今回はサーブレットコンテナが抱える問題にまで視野を広げて、クロスサイトスクリプティング(Cross Site Scripting:XSS)に関する注意点を考察していこう。 エラーページで動作するスクリプト アプリケーションが返すレスポンスは、必ずしもアプリケーションの開発者が作成したものとは限らない。例えば、アプリケーション内において例外が発生した場合、明示的な指定がなければ製品のデフォルトエラーページが表示される。デフォルトエラーページはデバッグ用に用意されているものが多いため、表示内容には問題の起因となったパラメータやスタックトレースが含まれ
Webアプリケーションのセキュリティホールが注目を浴びたことから、セキュリティを意識した開発の必要性が高まってきている。今後の流れとして、セキュリティ上満たすべき項目が要件定義の段階から組み込まれるケースが増えていくことが予想されるが、実際の開発現場においてはセキュリティホールをふさぐための実装方法が分からないという声も多いのではないだろうか。 そういった開発者の負担を少しでも軽くすることができるように、本連載ではJavaにおけるWebアプリケーション開発時に最もよく利用されているStrutsフレームワークの実装に踏み込んで、セキュリティ上注意すべきポイントを解説していきたい。なお、本連載ではStruts 1.2.8を対象として解説を行っていくが、すでにStrutsを利用したWebアプリケーション開発を行っている開発者をターゲットとしているため、Strutsの使用方法、各機能の詳細な説明な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く