セッションを使ったフォーム処理にありがちな問題点 - T.Teradaの日記
入力画面が複数に渡るフォームで、ユーザが各画面で入力したデータを、hiddenによって引き回すのではなく、セッション変数（セッションIDにヒモ付いてサーバ側に格納される情報）に一時保存するタイプのWebアプリケーションが増えているように思います。 フォーム処理でセッションが使われるのは、「実装をシンプルにしたい」「携帯サイトなどで通信量を減らしたい」といった理由のほかに、「アプリケーションをセキュアにしたい（hiddenだと改竄される）」という理由があるのではないかと思います。 しかし、セキュリティ上の問題は、セッションを使ったフォーム処理においてもしばしば見つかります。 以下では、セッションを使ったフォーム処理で、割と多く見つかる問題について書きます。 画面遷移の不正 ある会員制サイトの、会員登録フォームを会話風に書いてみます。 会員登録の際には、氏名、生年月日、住所の3つを登録します。
Webアプリケーションを作る前に知るべき10の脆弱性 ― ＠IT
Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP（Open Web Application Security Project）は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ
T.Teradaの日記 - ログイン直後のレスポンスの返し方
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう？というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して（HTTP1.1では303応答）、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
Perl Tips | ウェブサイト構築時のセキュリティのポイント
IPA（独立行政法人情報処理推進機構）の「 安全なウェブサイトの作り方 」というドキュメントは、なかなかまとまっていて、良い。すべてのウェブアプリ開発者は目を通しておくべきだ。ここではこのドキュメントから注意点をピックアップしてまとめてみた。 SQL インジェクション OS コマンド・インジェクション パス名パラメータの未チェック／ディレクトリ・トラバーサル セッション・ハイジャック クロスサイト・スクリプティング クロスサイト・リクエスト・フォージェリ (CSRF) HTTP ヘッダ・インジェクション メールの第三者中継 以下は、各ポイントの問題と対策。 SQL インジェクション （問題） リクエスト URL を https://www.yourdomain.com/post.php?param=XXXXX とすると、攻撃者が XXXXX のところにSQL 文を書いて SQL を実行して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IPA セキュア・プログラミング講座
http://cgi36.plala.or.jp/tera5/v/security/webap_sec2/chap01.html
開発者向け セキュリティ オンライン セミナー