2. 自己紹介 セキュリティエンジニアやってます。 脆弱性診断業務を担当しており、専門はWebセキュリ ティです。 趣味で脆弱性の検証したり、最近はCTFイベントなどに 参加してたりします。 TwitterID: tigerszk 3. Webアプリの脆弱性ってどんなの？ Webアプリの脆弱性達 SQLインジェクション OSコマンドインジェクション パス名パラメータの未チェック/ディレクトリ・トラバーサル セッション管理の不備 クロスサイト・スクリプティング CSRF HTTPヘッダ・インジェクション メールヘッダインジェクション アクセス制御や認可制御の欠落 IPA「安全なウェブサイトの作り方」より https://www.ipa.go.jp/security/vuln/websecurity.html 例えばこんなのがありますね
Web ブラウザーは通常 HTTP 要求の Referer: ヘッダーに参照元ページの URL を入れますが (あるいは document.referrer で参照元ページの URL を取得できますが)、 Web サイト側でこれを制御したいことがあります。 例えば、次のような場面が想定されます。 URL にユーザー名や秘密の ID などを含めざるを得ない時は、プライバシーやセキュリティーの観点から、この URL を外部に漏らしたくありません。 社内システムに URL を貼りたいことがありますが、社内システムの URL を外部に漏らしたくありません。 Web アプリケーションの開発用サーバーは、その所在を外部に漏らしたくありません。 投稿者と友達のみに公開される SNS の投稿にリンクが含まれる時、その個別 URL を漏らしたくありません。 (SNS 全体の URL が漏れることは問題ありま
先日Jxckさんがセッションオーナーを務めた次世代Webセッション@CROSS2014に参加してきました。 セッションではSPDYやHTTP/2(その当時はまだHTTP/2.0だったかな)について主にリソース転送をどうよくするかについて話がされ、QUICなど”Post-TCP”な話も出て非常に興味深く楽しみました。 そこで「僕が考える次世代Web」というお題でブログを書けとJxck先輩から宿題をいただいて、何の話を書こうかなとずーっと思っていたのですが、最近のIETFの議論で個人的にはとても大切だと考えるトピックがあったので紹介＋僕の思いを書きたいと思います。 [訂正] 私がドラフトを読み違えていたのが問題なのですが、このExplicit Proxyの仕組みはhttp schemeの場合だけ適用され、httpsでは適用されません。そのため、httpsについては引き続き安全だと言えます。 し
アメーバ事業本部のセキュリティチームの伊藤と申します。 アメーバでは日々、新しいサービスを開発しています。セキュリティチームのお仕事には、それらのサービスにセキュリティ上の問題が存在していないかどうかを調査する(以下、監査)という事も含まれます。※監査専門のベンダに調査を依頼することもあります。 今回は、私たちセキュリティチームが、どのようにWebアプリケーションの監査をしているのか、その一部を簡単に紹介しようと思います。 ※本エントリで紹介している手法は自分の管理しているサイト以外に適用しないでください ■Webアプリケーションの監査とは何を見ているのか 簡単にいうと、ブラウザ等から、Webアプリケーションサーバに対して送られるリクエストを変更して、サーバからの応答がどのように変わるのかを見ています。※ほかにもいろいろやっています。 ■具体的にはどうしているのか Webアプリケーションを
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
あるサイトから別ドメインのクッキーを書き込む。こういうクッキーは、サードパーティクッキーと呼ばれる。FirefoxとChromeはデフォルトでサードパーティクッキーが書き込めるようになっているが、IEとSafariが問題になる。IEはコンパクトポリシーというものを設定すればいけるが、Safariは出来ない。Safariはデフォルトで”知らないとサイトや広告のみCookieをブロック”となっている。でも、GoogleAdsenseとかは書き込めている。なので調べた。 目的 localhostにアクセスしたときsample.comのクッキーを書き込みたい。 もちろんクロスブラウザで。 (sample.comはhosts書き換えやるといい) ポリシーの設定 (P3P) (以下IE対策用) webサイトで個人情報などを取り扱う場合、ブラウザで設定されたポリシー設定とアクセスしているサイトのポリシー
地方公共団体が運営するホームぺージの改ざん防止等に資するため、Webアプリケーションの脆弱性の有無を診断し、その対処方法をお知らせします。個人情報漏えいの危険性があるSQLインジェクション等の脆弱性についても診断できます。 ウェブ健康診断とは？ 「ウェブ健康診断」とは、人間に例えるなら、その名のとおり 「健康診断」にあたるような位置づけの診断です。人間ドックに比べたら精密ではありませんが、平成19年度に実施したWebアプリケーション脆弱性診断結果等も考慮しながら重要な診断項目を検討しました。 本診断は「基本的な対策が出来ているかどうかを診断するもの」とご理解ください。また、診断対象のWebアプリケーションの全てのページを診断するものではなく、診断対象の規模にもよりますが、基本は抜き取り調査(診断)です。 Webアプリケーションとは？ ホームページの閲覧者が何らかの情報を書き込む等して、
Mozilla Foundationは、米連邦取引委員会（FTC）の提案に従い、ウェブページにおいてユーザーのオンライン行動が広告上の目的で追跡されてしまうことを防ぐため、「Firefox」などのウェブブラウザに実装する仕組みを詳細に提案している。 Mozillaの「Do Not Track（追跡拒否）」技術では、ブラウザから送られるネットワークデータパケットが、ユーザー側で追跡されることを望まないウェブサイトに信号を送る。そしてここが厄介な部分なのだが、ウェブサイトの運営者に協力を求める。 Mozillaで国際プライバシーおよびパブリックポリシー担当リーダーを務めるAlex Fowler氏によると、この仕組みでは、ウェブのHTTP（ハイパーテキスト転送プロトコル）を使用する基本的な通信を行っている間に、ブラウザがウェブサイトに警告を出すという。同氏はまた、このシステムを機能させる上での最
2010年08月17日06:45 カテゴリLightweight Languages Ajax - Goodbye, JSONP. Hello, Access-Control-Allow-Origin もうそろそろJSONPとはお別れできるのではないかと思い立ったので。 XMLHttpRequestとその問題 AjaxといえばXHRの愛称で親しまれているXMLHttpRequestですが、これには一つ重大な欠点がありました。 これを発行するDHTMLページのドメインが、Request先のドメインと一致する必要があったのです。いわゆる Same Origin Policy というやつです。おかげでサイトをまたがって使えなかったのです。これではマッシュアップできない。どうしよう。 JSONPとその問題 そこで生まれたのが、JSONPという手法です。 これは、scriptノードを追加した時に、単
多くの会員制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応答のページは、ブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く