ウェブアプリケーションセキュリティとバッドノウハウ、そしてグッドラッパーの関係
ウェブアプリケーションセキュリティとバッドノウハウ、そしてグッドラッパーの関係 by 金床 ---------------------------------- はじめに ---------------------------------- 筆者はウェブアプリケーション開発者であると同時にセキュリティ技術にも興味がある。自身がSeaSurfers MLというウェブアプリケーションセキュリティをテーマとしたメーリングリストを主催しており、またセキュリティコミュニティに多くの知人、友人がいる。しかし彼らとウェブアプリケーションなどのセキュリティ対策について意見を交換すると、違和感をおぼえることが多い。 彼らは脆弱性の原理についてとても詳しいのだが、以下のような会話が頻繁に発生するのである。 「…つまり原理的に考えて、このようにすればXSSは発生しないんだよ」 「な
情報処理推進機構：情報セキュリティ：H18年度ウェブアプリケーション開発者向けセキュリティ実装講座の開催について
※講演資料を掲載しました。 独立行政法人 情報処理推進機構（IPA）は、安全なインターネットの利用をめざして、最近、IPAが届出を受けた脆弱性関連情報を基に、届出の多かった脆弱性や攻撃を受けた場合の影響度が大きい脆弱性を取り上げ、その解決策を紹介するセキュリティ実装講座を企画しました。 本講座は本年2月、4月に実施しましたが、好評でしたので、今回は、新たに脆弱性の深刻度評価を用いた届出情報の分析結果や、ウェブアプリケーションの発注者が考慮すべき点なども紹介します。また、開発者の方から安全なウェブアプリケーションの開発に向けた取組み状況を紹介していただきます。 IPAでは、2004年7月8日に脆弱性関連情報の届出受付を開始してから2年4ヶ月が経過し、10月末までにソフトウエア製品に関するもの330件、ウェブアプリケーション（ウェブサイト）に関するもの687件、合計1,017件となり、1
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章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
NPO 日本ネットワ－クセキュリティ協会
JNSAセキュアシステム開発ガイドライン 「Webシステム セキュリティ要求仕様（RFP）」編 β版 セキュアシステム開発ガイドラインワーキンググループ 本ドキュメントは、発注者（ユーザー）に対しては、RFP（提案依頼書）に盛り込むセキュリティ対策のサンプルとして参照していただけることを目指している。本ドキュメントの作成にあたっては、JNSAの会員企業を中心とした、システム開発とネットワークセキュリティに携わる企業の方々によりレビューされているので、このドキュメントに記載されている内容をWebアプリケーションに実装することで、現時点で必要十分と言える対策を施していると考えていただいてよいだろう。受注者（ソフトウェアベンダー）にとっては、Webアプリケーションのセキュリティに関する要件を要件定義・基本設計の段階から盛り込んでいただくことにより、セキュリティに関する要件を「機能要件」として算出
情報処理推進機構：セキュリティセンター：脆弱性関連情報取扱い：安全なウェブサイトの作り方
IPAでは、ウェブサイト運営者が、ウェブサイト上で発生しうる問題に対し、適切な対策ができるようにするための注意事項として、『安全なウェブサイトの作り方』を取りまとめ、公開いたしました。 この資料は、昨年（2005年3月4日）にショッピングサイト運営者がウェブサイト上で発生しうる問題に対し、適切な対策ができるようにするための注意事項として発行した『消費者向け電子商取引サイトの運用における注意点』を、より広いウェブサイトの運営者に利用いただくことを目的に、内容の全面改訂を行ったものです。 『安全なウェブサイトの作り方』では、「ウェブアプリケーションのセキュリティ実装」として、IPAが届出を受けたソフトウエア製品およびウェブアプリケーションの脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、脆弱性の原因そのものをなくす根本的な解決策と、攻撃による影響の低減
高木浩光氏による「安全なWebアプリ開発の鉄則2005」(pdf)
1 安全なWebアプリ開発の鉄則2005 独立行政法人産業技術総合研究所 情報セキュリティ研究センター 高木 浩光 http://staff.aist.go.jp/takagi.hiromitsu/ Internet Week 2005 チュートリアル 2005年12月8日 配布資料 2 目次 • Webアプリの基本的な構成 – セッションIDによるセッション追跡 – セッションIDの配置 • セッション追跡に対する攻撃と防御 – セッションハイジャック – セッションライディング（CSRF:クロス サイトリクエストフォージェリ） – セッション固定化 • セッション追跡方式の欠陥 – 推測可能なセッション追跡パラメタ – 予測可能なセッションID – 稚拙な暗号の使用 • 権限確認の欠陥 – アクセス制御の欠如 – ユーザ識別の欠如 • 画面設計の問題 • 万が一に備えた適切な実装 •
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
