[B! Security][http] Oooのブックマーク

Host:リクエストヘッダによるXSS - 葉っぱ日記

本日、とある会合にてTwitterで交わされていたこの会話が話題になりました。紹介されている例はHostヘッダの操作を経路とする攻撃ということであり、Hostヘッダインジェクションという脆弱性はないと思いますよ / “PHPにおけるHostヘッダインジェクション脆弱性 ― A Day in Serenit…” https://t.co/sTzTQEE7a8— 徳丸　浩 (@ockeghem) 2015, 11月 6 @ockeghem @okumuri 実はIEでは細工したホストヘッダを送出できる手法が知られています。間違いなくIEのバグですが、このせいで値をそのまま出力しているサイトではXSSがありえてしまいます。ここが参考になります： https://t.co/G419aaUgNi— Masato Kinugawa (@kinugawamasato) 2015, 11月 9 知る人ぞ

Ooo 2015/11/11

リンク

LWSとHTTPヘッダインジェクション | 技術者ブログ | 三井物産セキュアディレクション株式会社

今回のトピックは「HTTPヘッダインジェクション」です。 HTTPヘッダインジェクションは、リクエストパラメータの操作等により、HTTPのレスポンスヘッダに改行文字（CR,LF）を挿入し、ヘッダフィールドを追加したり、ボディを操作したり、新たな偽のHTTPレスポンスを作り出したりする（HTTPレスポンス分割）攻撃、あるいは脆弱性です。状況にもよりますが、この脆弱性は、被害者のブラウザにおいて、脆弱性のあるページのオリジンで不正なJavaScriptを実行する攻撃につながりえます。つまり被害としては、クロスサイトスクリプティングと同様になりうるということになります。この脆弱性は古くから知られており、近年は特に目新しいトピックもなかったのですが、2014〜2015年に状況の変化があったので、今回取り上げてみたいと思います。タイトルにあるように、本記事の主なテーマは「LWS」とHTTPヘッ

Ooo 2015/08/06

リンク

Goによるプライベートネットワークへのアクセスを禁止するHTTPクライアントの実装 - はこべにっき ♨

クローラのように、ユーザからの入力に応じて任意のURLにHTTPリクエストを発行するソフトウェアは、誤ってプライベートネットワークへのリクエストを処理しないようにする必要があります。悪意のあるユーザが故意にプライベートなネットワークに対してリクエストして、内部情報にアクセスするといった攻撃を行う可能性があるからです。 PerlではLWPx::ParanoidAgentやLWPx::ParanoidHandlerといったモジュールが便利です。これらのモジュールは、リクエスト先のURLをチェックしてプライベートネットワークへのリクエストを禁止してくれます。単にIPアドレスをチェックするだけでなく、ホスト名をDNSで解決して得られたIPアドレスをチェックしたり、リダイレクト先のURLをチェックしたりしてくれます。まさに偏執的です。このLWPx::ParanoidAgentと同様の機能をもったG

Ooo 2015/08/05

リンク

MS15-034で修正されたHTTP.sysの脆弱性 CVE-2015-1635についてまとめてみた。 - piyolog

2015年4月のMicrosoftが公開した更新プログラム MS15-034で修正されたHTTP.sysの脆弱性について関連情報をまとめます。脆弱性概要脆弱性の概要情報は次の通り。愛称無しアイコン無し CVE CVE-2015-1635 発見者名 “…the Citrix Security Response Team…” MSは協調的な脆弱性の公開を通じて情報を得たと発表。 HTTP.sys が特別に細工された HTTP リクエストを誤って解析した場合に、HTTP プロトコルスタック (HTTP.sys) にリモートでコードが実行される脆弱性が存在します。攻撃者がこの脆弱性を悪用した場合、システムアカウントのコンテキストで任意のコードが実行される可能性があります。この脆弱性の悪用には、攻撃者が特別な細工をした HTTP リクエストを影響を受けるサーバーに送信する必要があり

Ooo 2015/04/16

リンク

[Go] port 80を開いたあとroot権限を捨てるwebサーバの例 - Qiita

port 80を開くためにはroot権限が必要だが、開いたあとはセキュリティーリスクを最小限にするために一般ユーザ権限に降格したい、というWebサーバをGoで書く例です。【追記3】下記の例ではLinuxで動作させた場合に不十分です。 Linuxではsetuidを呼び出したスレッドにしか効かないので、以下の例をそのままLinuxで動かすとsyscall.Setuid()は成功しますが、HTTPのHandlerでは別スレッドで動くことがあるため、rootのままで動作することになります。 methaneさんのコメントを参照ください rootで起動した状態で":80"をlistenして syscall.Setuid() で一般ユーザになり http.Serve()する package main import ( "net" "net/http" "syscall" "log" ) func m

Ooo 2014/07/16

リンク

[nginx-announce] nginx security advisory (CVE-2014-0133)

Maxim Dounin mdounin at mdounin.ru Tue Mar 18 16:45:47 UTC 2014 Previous message: [nginx-announce] nginx-1.4.7 Next message: [nginx-announce] nginx-1.5.13 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hello! A bug in the experimental SPDY implementation in nginx was found, which might allow an attacker to cause a heap memory buffer overflow in a worker process by using a specially

Ooo 2014/03/22

リンク

今夜つける HTTPレスポンスヘッダー（セキュリティ編） - うさぎ文学日記

Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ

Ooo 2013/11/30

リンク

HTTPSを使ってもCookieの改変は防げないことを実験で試してみた

寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe

Ooo 2013/09/30

リンク

Webアプリケーション向けのセキュリティスキャナ「skipfish」を使う | OSDN Magazine

近年では多くの分野でWebアプリケーションが使われるようになり、大量の個人情報や重要な秘密情報を扱うようなアプリケーションも少なくない。そのため、Webアプリケーションも攻撃対象として狙われやすくなっている。今回はWebアプリケーションのセキュリティ対策として、Googleが公開しているセキュリティ調査ツール「skipfish」を使ったセキュリティスキャンを紹介する。 Webアプリケーションに特化したセキュリティ調査ツール「skipfish」今日では、Webブラウザ経由でさまざまな操作を行えるWebアプリケーションが広く浸透している。Webブラウザは最近のほぼすべてのPCにインストールされており、専用のクライアントを用意せずにアプリケーションを操作できるというのがその浸透の理由の1つだ。しかし、Webアプリケーションでは簡単にその一部（HTMLやJavaScript）のソースコードを閲覧

Ooo 2013/09/28

リンク

ログアウト機能の目的と実現方法

このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。議論の前提このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります

Ooo 2013/02/15

リンク

Cookieによるhashdos攻撃と対策

このエントリでは、Cookieを用いたhashdos攻撃の可能性について検討し、実証結果と対策について報告します。はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。先の記事でも説明しているようにPOSTパラメータ(HTTPリクエストボディ)に多数のパラメータを仕込む攻撃が典型的ですが、POSTパラメータ以外のパラメータを用いた攻撃についても検討しておかないと、防御漏れの可能性が生じます。そこで、POSTパラメータ以外を用いた攻撃方法について検討します。 POST以外に多数のパラメータを仕込めるかPOST以外に多数のパラメータを仕込む場所があるでしょうか。候補となる

Ooo 2012/01/19

リンク

1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記

最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty

Ooo 2011/01/08

というか、ほとんどがIE8以降にMicrosoftが導入なんだから、Microsoftはきちんと整理して文書にまとめて欲しい。

リンク

X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記

2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に

Ooo 2011/01/07

リンク

HTTP Strict Transport Security has landed!

It was a year ago now that I first blogged about ForceTLS, and it's matured quite a bit since. I revised ForceTLS to be more robust, and began actually implementing it as HTTP-Strict-Transport-Security in Firefox. I'm excited to say that my patch has been reviewed and landed in mozilla-central. What's that mean? Look for it in the next beta release of Firefox 4! If you can't wait, grab a nightly b

Ooo 2010/10/28

リンク

Mozilla Japan ブログ - Firesheep に関する Mozilla セキュリティチームからのコメント

Web サイトにおけるセキュリティの弱点を浮き彫りにした、Firesheep という最近公開されたツールに関して、多くの反響が寄せられているようです。これは、攻撃者が公共のネットワークを使用している人たちの接続を傍受して Cookie を盗み出し、Facebook や Twitter などのサイトでその人たちのアカウントへログインする、つまり他人になりすますことを可能にするものです。Firesheep の作者は Firefox のアドオン API を使ってこのツールを開発しましたが、単体のプログラムとして開発、配布することも難しくないと思われます。このようなツールが登場したことで、ユーザに安全な接続を求めるよう、サイト側で設定を行うことの重要性がより一層高まりました。それほど前のことではありませんが、Firesheep のようなツールを使った攻撃者から Cookie を読み取られるのを

Ooo 2010/10/28

Strict-Transport-Security

リンク

X-FRAME-OPTIONS を用いたクリックジャッキング対策 - Main Log

旧サーバからの再掲記事です。 "X-FRAME-OPTIONS" は InternetExplorer 8.0 で導入された HTTP レスポンスヘッダです。単純に言うと、自サイトのコンテンツが外部のサイトのフレーム上に表示されることを制御します。それにより、透明度などを操作することでユーザのクリックを横取りするような企図を阻害することを狙っています。 X-FRAME-OPTIONS には "DENY" と "SAMEORIGIN" の二つが存在します。"DENY" は他の Web ページ上からの frame や iframe でのコンテンツ参照を禁止します。"SAMEORIGIN" は Top-level-browsing-context が一致しないページからの表示を禁止します。 "SAMEORIGIN" は判りづらいんですが、HTML 5 の "5 Web browsers" ではこ