(この記事は古いため、HTTP2.0と表記していますが、正しくはHTTP/2です) (HTTP ConnectメソッドのALPNヘッダは「ALPN HTTP Headerとは」) TLS-NPN(Next Protocol Negotiation) SPDYはHTTPSと同一ポートで接続を受け付けるため、SPDYの通信を開始する前にどちらのプロトコルで通信するか決める必要がある。その方法としてTLS-NPNを用いる。これは、SSLハンドシェイク時に使用するプロトコルのネゴシエーションも同時に行なってしまう方法である。TLS-NPNはGoogleによって仕様が策定されている(仕様URL)。 TLS-ALPN(Application Layer Protocol Negotiation) HTTP2.0においても、このSSLハンドシェイク時にネゴシエーションをすることが検討されている。もともと
Di era digital 2025,Mawar189 hadir sebagai pilihan cerdas bagi siapa pun yang mencari hiburan ringan namun penuh potensi keuntungan. Dengan konsep platform modern, Mawar189 memadukan kenyamanan beraktivitas online dengan fitur-fitur yang dirancang untuk membuat setiap pengguna merasa betah dan percaya diri dalam menjelajahi setiap peluang yang ditawarkan. Keamanan dan kenyamanan adalah dua pilar u
ターミナルで利用できるインタラクティブなHTTPインスペクションツール「wuzz」。 任意のHTTPリクエスト発行し、レスポンスを検証するためのツールです。cURLと似通ったコマンドラインパラメータが利用できるので、ChromeやFirefoxなどの「copy as cURL」機能を使って簡単にネットワーク関連のテストを実行することができるように設計されています。 バイナリは公開されていませんが、Go言語によって作成されたツールなので、各種プラットフォームで簡単にビルドすることが可能です。 以下macOS環境で、実際の使用方法を説明します。 wuzzの使用方法 以下のコマンドを実行してwuzzをインストールします。 $ go get github.com/asciimoo/wuzz $ "$GOPATH/bin/wuzz" --help Go言語がインストール済みで、環境変数GOPATHが
インタラクティブなHTTPサーバー「HTTPLab」。 Go言語で作られたオープンソースソフトで、任意のHTTPリクエストに対するレスポンスを自由に作成することができる特徴を持ちます。 レスポンスのステータスコードのほか、遅延時間や、ヘッダー、ボディなどレスポンスの各データを変更することができるため、HTTPクライアントの作成やテストに便利なツールです。 以下使用法を説明します。 HTTPLabはマルチプラットフォーム対応のGo言語で作られています。macOS、FreeBSD、Linux環境の場合GitHubのリリースページから実行ファイルをダウンロードして利用するのが簡単です。 Macの場合「httplab_darwin_amd64」をダウンロードし、以下のようにして実行します。 mv httplab_darwin_amd64 httplab ./httplab デフォルトポートは100
Cross-Site Tracing(XST)という化石のような攻撃手法があります。「化石」と書いたように、既に現実的な危険性はないのですが、XSTに関連して「TRACEメソッドは危険」というコメントを今でも見ることがあります。 このエントリでは、XSTという攻撃手法について説明し、XSTおよびTRACEメソッドについてどう考えればよいかを紹介します。 TRACEメソッドとは HTTP 1.1(RFC2616)では、8種類のメソッドが定義されています。GET、POST、HEADなどはおなじみのものですが、それ以外にPUT、DELETE、OPTIONS、TRACE、CONNECTの5種があります。 このうち、TRACEメソッドは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返すもので、以下のようにGET等の代わりにTRACEとしてWebサーバーにリクエストします。 TRACE
Documents PDF of slides summary of briefing for non-experts Paper: Virtual Host Confusion Paper: Triple Handshake and Cookie Cutter Exploit videos Disclaimer: The goal of these videos is not to criticize the affected websites but to demonstrate that the attacks we describe are practical and can have a strong impact. The attacks have been responsibly disclosed to the affected vendors, giving them a
Webサーバのサポートしているメソッドはtelnetやnetcatを使用してサーバに接続した後、OPTIONSメソッドで問い合わせを行う事で得られます。 具体的には「OPTIONS / HTTP/1.0」をサーバに送信します。 ※サーバの応答は青色。 # telnet itochif.com 80 #telnetでitochif.comのTCPポート80番に接続 OPTIONS / HTTP/1.0 #(入力後に改行を2つ入れる) HTTP/1.1 200 OK Date: Sun, 10 Aug 2008 10:00:00 GMT Server: Apache Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0 Connection: close Content-Type: text/html 図1.telnetで接続し、TCP/80
Rack限定ならむかし rack-spyup というものを書いた。自分で使ってみたけどJSON APIのデバッグとかだと革命的に便利だと思う。 ただ、Rackに到達する前にリクエストがお亡くなりになったりとか、そもそもサーバルビーじゃないしとかあると思うので、もっと汎用的な感じでダンプする手順をメモしてみる。 リクエストが来たら内容を全部ダンプするHTTPサーバを作る Rubyに標準添付されている、WEBrickの基本的な機能で割と簡単に作れる。 # -*- coding: utf-8 -*- require 'optparse' require 'webrick' require 'json' options = ARGV.getopts("p:", "port:") # The :monkey: raises # cf. http://d.hatena.ne.jp/vividcode/
2011/5/10 以下の訂正をしました。 s/prefetch/preflight/g JavaScriptのクロスドメイン通信で微妙な話があったので書いてみます。ちなみにクライアントサイドJavaScriptの話です。下記仕様に敬意を表して以下ではクロスオリジンと書きます。一般にクロスドメイン通信と呼ばれているものと同じ意味で使います。 Cross-Origin Resource Sharing XMLHttpRequest2(XHR2) WebブラウザからXMLHttpRequest(XHR)で外部のWeb APIを直接叩こうとするとクロスオリジンの制限に当たります。制限の必要性は次の説明がわかりやすいのでリンクを張っておきます。 Same-Originポリシーの必要性 クロスオリジン制限がある中でWebブラウザから直接Web APIを叩こうと先人は知恵を絞ってきました。iframe
近年では多くの分野でWebアプリケーションが使われるようになり、大量の個人情報や重要な秘密情報を扱うようなアプリケーションも少なくない。そのため、Webアプリケーションも攻撃対象として狙われやすくなっている。今回はWebアプリケーションのセキュリティ対策として、Googleが公開しているセキュリティ調査ツール「skipfish」を使ったセキュリティスキャンを紹介する。 Webアプリケーションに特化したセキュリティ調査ツール「skipfish」 今日では、Webブラウザ経由でさまざまな操作を行えるWebアプリケーションが広く浸透している。Webブラウザは最近のほぼすべてのPCにインストールされており、専用のクライアントを用意せずにアプリケーションを操作できるというのがその浸透の理由の1つだ。しかし、Webアプリケーションでは簡単にその一部（HTMLやJavaScript）のソースコードを閲覧
HTTPプロトコルでは、コンピュータ同士が通信している間に、コードを用いてお互いの状態(ステータス)をやり取りしています。このコードのことをHTTPステータス・コード(HTTP Status Code)と呼び、エラーが発生した場合に「404 Not Found」のようにブラウザ上に表示されたり、エラーが発生しなかった場合にも見えないところでやり取りされています。 また、通信を行うためにクライアントがサーバーに様々なリクエストを行いますが、このリクエストの方法をメソッドと呼びます。 規格
WebSocket（ウェブソケット）は、単一のTCPコネクション上に双方向通信のチャンネルを提供する、コンピュータの通信プロトコルの1つである。WebSocketプロトコルは、2011年にRFC 6455としてIETFにより標準化された。Web IDL（英語版）中のWebSocket APIは、当初W3Cにより標準され、後にWHATWGに引き継がれている。 WebSocketはHTTPとは異なるプロトコルである。ともにOSI参照モデルのレイヤー7に位置し、レイヤー4のTCPに依存している。両者は異なるプロトコルであるが、RFC 6455では、WebSocketは「HTTPプロキシと仲介者をサポートするために、HTTPの443番および80番ポート上で動作するように設計されている」と述べられているように、HTTPプロトコルと互換性がある。互換性を実現するために、WebSocketのハンドシェイ
次期HTTPの有力候補に挙げられたSPDY Googleが提唱している「SPDY（スピーディ）」がにわかに注目を集めている。 SPDYは高速なWebコンテンツ転送を実現するための新しいネットワークプロトコルである。Googleは以前からWebの高速化に極めて熱心に取り組んできた。そのために開発されたプロダクトは、Webサーバ、Webブラウザ、JavaScriptエンジン、各種開発ツールなど、Web技術のあらゆる側面をカバーしている。SPDYもその取り組みの一環であり、ネットワークプロトコルというWebの基幹部分から高速化へのアプローチを進めようというものだ。 SPDYは2010年に発表され、2011年前半にはブラウザのChromeに実装され、一般のユーザーでも利用できるようになった。このとき、Googleの一部のサービスではChromeとの通信にSPDYを利用していることが明かされている。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
