バーチー / GMO Pepabo, Inc. 2019.10.12 PHPカンファレンス沖縄 https://phpcon.okinawa.jp
Webアプリにおける11の脆弱性の常識と対策:Webアプリの常識をJSPとStrutsで身につける(11)(1/4 ページ) 本連載は、JSP/サーブレット+StrutsのWebアプリケーション開発を通じて、Java言語以外(PHPやASP.NET、Ruby on Railsなど)の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です 【2013年2月25日】編集部より、おわびと訂正のお知らせ 本稿において読者の皆さまより多数のご指摘をいただきまして、誠にありがとうございます。編集部であらためて調べた結果、間違いを把握し、あらためて修正版を掲載させていただきます。この度は、長期にわたり誤った内容を掲載したので、読者の皆さまに多大なご迷惑をお掛けしたした点をおわび申し上げます。 通常、記事に間違いがあった場合には、筆者確認後に修正版を掲載するのですが、今回の場
■ ログイン成功時のリダイレクト先として任意サイトの指定が可能であってはいけない これが「脆弱性」として合意されるかどうかわからなかったが、脅威と対策をまとめてIPAに届け出てみたところ、受理され、当該サイト(複数)は修正された。以下、この問題がどういうもので、どうするべきなのか、はてなのケースを例に書いておく。 4月にこんな話が盛り上がりを見せていた。*1 ソーシャルブックマークユーザーのIDとPASSをいとも簡単に抜き取る手口, ホームページを作る人のネタ帳, 2007年4月6日 Bボタンフィッシングとは何? 記事の最後には私のブログでもおなじみの、はてなブックマークへ追加ボタンや、バザールのブックマークボタン(Bボタン)を設置しているブログを最近良く見かける。何気なく私はそれを利用したりしている。(略)『あれ?セッションがきれたのかな』と思い、自分のIDとパスワードを入れてログイン。
Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP(Open Web Application Security Project)は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ
ウェブアプリケーションセキュリティとバッドノウハウ、そしてグッドラッパーの関係 by 金床 ---------------------------------- はじめに ---------------------------------- 筆者はウェブアプリケーション開発者であると同時にセキュリティ技術にも興味がある。自身がSeaSurfers MLというウェブアプリケーションセキュリティをテーマとしたメーリングリストを主催しており、またセキュリティコミュニティに多くの知人、友人がいる。しかし彼らとウェブアプリケーションなどのセキュリティ対策について意見を交換すると、違和感をおぼえることが多い。 彼らは脆弱性の原理についてとても詳しいのだが、以下のような会話が頻繁に発生するのである。 「…つまり原理的に考えて、このようにすればXSSは発生しないんだよ」 「な
※講演資料を掲載しました。 独立行政法人 情報処理推進機構(IPA)は、安全なインターネットの利用をめざして、最近、IPAが届出を受けた脆弱性関連情報を基に、届出の多かった脆弱性や攻撃を受けた場合の影響度が大きい脆弱性を取り上げ、その解決策を紹介するセキュリティ実装講座を企画しました。 本講座は本年2月、4月に実施しましたが、好評でしたので、今回は、新たに脆弱性の深刻度評価を用いた届出情報の分析結果や、ウェブアプリケーションの発注者が考慮すべき点なども紹介します。また、開発者の方から安全なウェブアプリケーションの開発に向けた取組み状況を紹介していただきます。 IPAでは、2004年7月8日に脆弱性関連情報の届出受付を開始してから2年4ヶ月が経過し、10月末までにソフトウエア製品に関するもの330件、ウェブアプリケーション(ウェブサイト)に関するもの687件、合計1,017件となり、1
多くの会員制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応答のページは、ブ
data スキーマを使ったスクリプトの実行 † data スキーマは、画像やIFRAMEなどのデータをHTML中に埋め込んで使用するための方法で、RFC2397で定義されています。複数のWebメールにてこれを使用してスクリプトの実行が可能な脆弱性がありました。 <iframe src='data:text/html;base64,PHNjcmlwdD5hbGVydCgiZGF0YToiK2RvY3VtZW50LmNvb2tpZSk7PC9zY3JpcHQ+'></iframe> <img src='data:text/html;base64,PHNjcmlwdD5hbGVydCgiZGF0YToiK2RvY3VtZW50LmNvb2tpZSk7PC9zY3JpcHQ+'> 多くのWebアプリケーションでは、http もしくは https スキーマのURIのみを入力値として許可すれば十分だと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く