InfoQ: How HTML5 Web Sockets Interact With Proxy ServersInfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
Content-Security-Policyやらsubresource integrityなどに関するメモ - Sexually Knowing
最近、セキュリティに特に気をかけなければいけないサービスの開発をしていて調べた知見のメモ。 subresource integrity Subresource Integrity - Web security | MDN いわゆるチェックサムの仕組み。 integrity 属性に ${hashalgorithm}-${hashdigest} 形式の値を書いておき、フェッチしたファイルのハッシュ値が一致していなければブラウザが読み込みをブロックする。 これは、たとえばCDNが攻撃されるなどしてスクリプトなどが改竄された場合に有効。 JSやCSSはプリ・ポストプロセッサで処理し出力することがほとんどだろうが、subresource integrityとどうやって統合するかというとgulp-hashsumを使ってコンパイルしたファイルのハッシュ値をdigest.jsonに保存し、HTMLのレンダ
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
curlでPOST送信する場合に注意しておいた方がいいこと(続・CentOS4系と5系のcurlの違い) - tokuhy’s fraction
以前のエントリで調査したcurlのバージョンの違いについてその後色々調べたので結果をまとめてみる。 おさらい CentOS4系 curl 7.12 CentOS5系 curl 7.15 サーバの移行を行ったところ、curlの通信に著しい遅延が発生した。具体的に言うと1回の通信で2秒かかる。 前回の対策としてはとりあえずCentOS4系のSRPMを持ってきてビルドし、バージョンをダウングレードして対応した。 調査 実は前回のエントリでは環境を正確に書ききっていなかったorz。 今回調査を続けた結果以下の環境でのみこの2秒遅延が起こることが判明した。 環境 curl 7.13以降 POSTデータが1024バイト以上 Poundサーバ経由したときのみ 前回は単純にcurlのバージョンのみが問題だと思って色々調べたんだけど、他のサーバのログや環境を比較しているうちに上記の条件が確認できた。 確認し
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
【セキュリティ ニュース】プロクシー利用時に影響受ける脆弱性「FalseCONNECT」 - OS XやiOSは修正済み（1ページ目 / 全2ページ）：Security NEXT
プロクシー経由でインターネットへアクセスする際に、中間者攻撃を受けるおそれがある脆弱性が「FalseCONNECT」として公表された。WebKitを用いるブラウザでは、任意のスクリプトを実行されるおそれがあるという。 セキュリティ研究者のJerry Decime氏が公表したもの。 同氏によれば、プロクシーにおける認証機能の実装に問題があり、プロクシ経由で接続する際に認証情報を詐取されるおそれがあるという。 同氏は今回の脆弱性について「FalseCONNECT」と名付け、ウェブサイトを公表した。 具体的には、HTTPS通信においてもプロクシーに対する接続要求「HTTP CONNECT」が平文で送信されるため、アクセス先が秘匿されないほか、さらに平文により応答があり、これを「HTTP 407 Proxy Authentication Required」へ置き換えることで、認証情報を詐取するマン
httpoxyでAffected指定されているけどPoCが無いフレームワークで再現試験をした話
はじめまして。HASHコンサルティングでエンジニアをしている一ノ瀬と申します。 ご存知の通り、現在HASHコンサルティングは現在も積極的にセキュリティエンジニアを募集しています。従業員も少しずつ増えてきましたので、今回の投稿から弊社の代表である徳丸と共に従業員もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。 というわけで、従業員の投稿第1弾は2016/7/19に公開され話題となったhttpoxyの話です。 httpoxyは警視庁による注意喚起もされており、非常に注目を集めています。 “[PDF] CGI 等を利用するウェブサーバの脆弱性（httpoxy）を標的としたアクセスの観測について - 警察庁 (平成28年７月20日)” https://t.co/DE7LG7MwQC — 徳丸 浩 (@ockeghem) 2016年7月20日
米Google、検索サイトに「HSTS」実装 危険URLを自動変換
HSTSではインセキュアなHTTP URLを自動的にセキュアなHTTPS URLに変換することによって、ユーザーによるHTTP URLの参照を防止する。 WebサイトのHTTPS接続を推進している米Googleは7月29日、転送中のデータの保護を一層強化する目的で、「www.google.com」のドメイン上で「HTTP Strict Transport Security」（HSTS）を実装したと発表した。 Googleによると、HSTSではインセキュアなHTTP URLを自動的にセキュアなHTTPS URLに変換することによって、ユーザーによるHTTP URLの参照を防止する。ユーザーはアドレスバーにHTTPのURLを入力したり、他のWebサイトのHTTPリンクをたどったりして、そうしたHTTP URLにアクセスしてしまうことがあるという。 「転送中のデータの暗号化は、ユーザーやユーザー
「httpoxy」の脆弱性発覚 PHP、Go、PythonなどのCGIアプリに影響
PHP、Python、Goを使ったCGIベースのアプリケーションで脆弱性が確認されたほか、影響を受ける恐れのある多数のアプリケーションがあると推定される。 PHP、Go、Pythonなどの主要なプログラミング言語に影響するCGIアプリケーションの脆弱性が発覚した。発見者はこの脆弱性を「httpoxy」と命名し、7月18日に詳しい情報を公開。悪用は極めて簡単とされ、米セキュリティ機関もパッチまたは回避策の適用といった対策を直ちに講じるよう呼び掛けている。 httpoxyの情報サイトや米CERT/CC、SANS Internet Storm Centerなどによると、この問題はWebアプリケーションにおけるHTTP「Proxy」ヘッダの不適切な使用に起因する。CGIまたはCGIのようなコンテキストで運用されているWebサーバでは、クライアントにリクエストされたHTTP Proxyヘッダが「HT
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
「常時SSL」の疑問に答えよう、どうすればできるか
簡単に解説すると、安価な証明書はそのほとんどが「ドメイン認証」であり、通常は個人利用が多い。その次が法的な実在証明を行う証明であり、一般企業の多くがこの方式を採用している。最も厳格なものは以前にも解説したが「EV SSL」だ。「物理的実在証明」と呼ばれている。安全な場合はWebブラウザのアドレスバーが緑色に変化するので、初心者が見ても分かりやすいと評判だ。 EV SSL証明書は価格が少し高いものの、顧客の安全を考慮するなら、十分に検討に値するものだろう。定価ベースで年間に約7万～10万円ほど高いだけだ。月1万円にも満たない価格差でより大きな安心感を得られると思えるが、あまり普及していないのは残念である。証明書の処理については、確かに厳密な確認を行うものであるほど時間がかかると想定される。だが、体感ではユーザーが全く気付かない場合がほとんどだろう。 また、「証明書失効リスト」（CRL）をチェ
21世紀のエンジニアのためのHTTP/2入門 | κeenのHappy Hacκing Blog
第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。
HTTP接続は「安全でない」と明示すべし――Googleが提案
HTTPSを使ったセキュアな接続の普及を目指す米Googleが、ユーザーエージェント（UA）の仕様を段階的に変更して、通信が暗号化されないHTTP接続に対して「安全でない」と明示することを提案している。 この提案の狙いは、「HTTPには情報セキュリティ対策が施されていない」という事実を、もっとはっきりユーザーに示すことにあるとGoogleは説明。「Web上のデータ通信はすべてセキュアでなければならない。情報セキュリティが存在しない場合はそのことを明示して、ユーザーが情報を得たうえで対応を決められるようにしなければならない」と主張する。 背景として米国家安全保障局（NSA）などがネットの監視活動を行っていると伝えられた事例を列挙し、「Web上では改ざんや監視などの攻撃が、理論上ではなく実際に横行している」とした。 具体的にはセキュリティ状況を3段階に分類し、有効なHTTPSなどを使っている場
「SSL証明書無償配布」がもたらすWebの変革、企業ネットの管理にも影響
2015年の夏以降、Webアクセスの姿が大きく変わる可能性が出てきた。現在主に使われている「HTTP（HyperText Transfer Protocol）」の代わりに、SSL（Secure Sockets Layer）やTLS（Transport Layer Security）を用いて通信を暗号化する「HTTPS（HTTP over SSL/TLS）」を利用したWebサイトやサービスが一気に増えることが予想されるからだ。 なぜHTTPの代わりにHTTPSを使うWebサイトやサービスが増えるのか。それは、HTTPSを利用するために必要となる「SSLサーバー証明書」（以下SSL証明書）を誰でも無償かつ簡単に入手できるようになるからである。これまでは、年間数千円から数万円程度の料金をベンダーに支払ってSSL証明書を取得する必要があった。2015年夏以降、これがタダで“も”入手できるようになる
HTTPSを使っているのにCookieに「secure」属性を設定していない危険なサイトが話題に | スラド セキュリティ
最近SSL関連の脆弱性がたびたび話題になったが、これに関連してか、HTTPSを利用しているのにCookieのsecure属性を設定していないサイトについてが話題になっているようだ（セキュリティ研究家高木浩光氏によるTogetterまとめ）。 Cookieのsecure属性については、2004年に高木浩光氏がまとめた「安全なWebアプリ開発の鉄則 2004」の「CookieにSecure属性を」以下が分かりやすいが、この属性をセットしておくと、HTTPSでの通信時にのみそのCookieが送信される、というもの。secure属性が設定されていない場合、HTTP通信の際にもそのCookieが送信されるため、通信内容を傍受するなどでセッションIDなどが盗まれる可能性がある。 高木氏が検証したところ、secure属性が設定されていないサイトとしては全日空やニコニコ動画、OCNメールなどがあった模様。
あたらしいHTTPの話をしよう
あたらしいHTTP/1.1、RFC7230-7239のざっくりしたまとめ http://blog.hmm.jp/entry/new-http1.1-rfcs
HTTPの標準規格が15年ぶりに改訂、文書を6分割し改善仕様を盛り込む
図●新たに公開されたRFC7230の冒頭部分 RFC2616を破棄（Obsoletes）したことが示されている。 Webブラウザーによるアクセスをはじめ、スマートフォンアプリや家電機器、IoT（Internet of Things）デバイスの通信など、世の中のいたるところで使われている最も重要な基本プロトコルの一つ「HTTP」（HyperText Transfer Protocol）が6月上旬、実に15年ぶりに改訂された（プロトコルのバージョン自体は1.1のまま）。 インターネット技術の標準化団体であるIETF（Internet Engineering Task Force）が2007年に立ち上げた「HTTPbisワーキンググループ（WG）」が規格改訂に携わった。 1999年の公開以来、長らくインターネットアプリケーション開発者のバイブルとして使われてきた「RFC2616」（RFCはreq
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - asciimoo/wuzz: Interactive cli tool for HTTP inspection
GitHub - qustavo/httplab: The interactive web server
GitHub - jgrahamc/httpdiff: Perform the same request against two HTTP servers and diff the results
