うさぎ文学日記

Webアプリケーション脆弱性診断本『Webセキュリティ担当者のための脆弱性診断スタートガイド上野宣が教える情報漏えいを防ぐ技術』を発売予定

Wed, 13 Jul 2016 00:00:00 +0900

2016年8月2日に3年ぶりに書籍を出します。テーマは「Webアプリケーション脆弱性診断」です。
弊社（株式会社トライコーダ）では脆弱性診断を学ぶための講座をいくつか提供していたり、リーダーを務めるOWASP Japanの脆弱性診断士スキルマッププロジェクトでのガイドライン作りなどによって、診断会社各社の診断手法やノウハウなどを蓄積することができました。本書はそれを一冊にまとめた本となっています。

Webセキュリティ担当者のための脆弱性診断スタートガイド上野宣が教える情報漏えいを防ぐ技術

発売元: 翔泳社
価格: ￥ 3,456
発売日: 2016/08/02

posted with Socialtunes at 2016/07/13

脆弱性診断はセキュリティ会社が実施することが多いのが現状のようです。それは脆弱性診断という技術が特殊なために熟練のセキュリティ専門家でないと実施できないという誤解からかもしれません。
実際はそうではありません。手法を知り、方法を学ぶことで誰にでもできるようになる技術です。さらにはシステムの仕様を知っている開発者が脆弱性診断を行うことで、システムのことを知らないセキュリティ専門家が行うよりもうまく行える可能性すらあるのです。

本書ではWebアプリケーションの脆弱性診断を行うために必要な基礎知識、診断に必要なツール、そして脆弱性を効率的に発見するための診断手法、報告書の書き方などを学ぶことができます。
また、レビューアーにはOWASP JapanなどのWGでご一緒させて頂いている小河哲之さん（Burp Suite Japan User Group）、亀田勇歩さん（SCSK株式会社）、国分裕さん、洲崎俊さん、西村宗晃さん（株式会社リクルートテクノロジーズ）、山崎圭吾さん（株式会社ラック）にお願いさせて頂きました。

1.脆弱性診断とは
この章では脆弱性診断とは何かということを学んで行きます。WebサイトやWebアプリケーションの脆弱性とはどういったもので、それを発見するための手法である脆弱性診断とはどういったものかを学びましょう。

脆弱性診断とは「脆弱性を発見するためのテスト手法」
本書の脆弱性診断対象とWebサイトの脆弱性対策
脆弱性診断士に必要な知識や技術
脆弱性診断士に求められる倫理観

2.診断に必要なHTTPの基本
この章ではWebの主要なプロトコルであるHTTPの基本について学んで行きます。Webアプリケーションの脆弱性診断を行うためには、Webの主要な通信プロトコルであるHTTPの理解を欠かすことができません。
HTTPというプロトコルの仕組みや、通信でやりとりするメッセージの構造などを学びましょう。

HTTPとは
TCP/IPとHTTPの関係
HTTPと関係深いプロトコル - IP・TCP・DNS
URLとURI
シンプルなプロトコル HTTP

3.Webアプリケーションの脆弱性
この章ではWebアプリケーションの脆弱性について学んで行きます。Webアプリケーションへの攻撃がどういうもので、どういった種類のものがあるのかを学びましょう。

Webアプリケーションへの攻撃とは
インジェクション - Webアプリケーションの脆弱性
認証 - Webアプリケーションの脆弱性
認可制御の不備・欠落 - Webアプリケーションの脆弱性
セッション管理の不備 - Webアプリケーションの脆弱性
情報漏えい - Webアプリケーションの脆弱性
その他 - Webアプリケーションの脆弱性

4.脆弱性診断の流れ
この章ではWebアプリケーション脆弱性診断の流れについて学んで行きます。まず診断会社が提供しているような診断業務全体の流れを学びます。そして診断実施前の準備には何が必要かを知り、脆弱性診断はどのように行うかという実施手順を学びましょう。

診断業務の流れ
診断実施前の準備
脆弱性診断の実施手順

5.実習環境とその準備
この章では本書の実習に必要な診断ツール、Webブラウザ、実習環境のセットアップについて説明していきます。

診断ツールのセットアップ
診断のためのWebブラウザのセットアップ
実習環境のセットアップ
実際の診断の際の注意事項

6.自動診断ツールによる脆弱性診断の実施
この章では自動診断ツールを使った脆弱性診断の実施手順をはじめとして、自動診断ツールとして使用するOWASP ZAPの基本操作、脆弱性診断の実施方法などを説明していきます。

自動診断ツールを使った脆弱性診断の実施手順
OWASP ZAPの基本操作
OWASP ZAPに診断対象を記録
OWASP ZAPで診断を実行

7.手動診断補助ツールによる脆弱性診断の実施
この章では手動診断補助ツールを使った脆弱性診断の実施手順を初めとして、脆弱性診断に使用する基準、診断リストの作成方法、手動診断補助ツールとして使用するBurp Suiteの基本操作、各種ツールの使い方、脆弱性診断の実施方法などを説明していきます。

手動診断補助ツールを使った脆弱性診断の実施手順
Webアプリケーション脆弱性診断手法: 脆弱性診断士スキルマッププロジェクトの基準
Burp Suiteの基本操作: 手動診断のためのBurp Suite基本操作
診断リストの作成: テストケースのシートを作成する手順
Burp Suiteの各種ツールの使い方
Burp Suiteを使った脆弱性診断
より多くの脆弱性を発見するためのヒント集: より多くの脆弱性を発見するための手動診断のコツ

8.診断報告書の作成
この章では脆弱性診断を実施した結果をまとめた診断報告書の作成について、報告書に記載すべき事項や個別の脆弱性の報告方法、リスク評価の付け方などを説明していきます。

診断報告書の記載事項
総合評価と個別の脆弱性の報告
リスク評価

9.関係法令とガイドライン
この章では脆弱性診断に関連する法律、診断時のルールや診断結果の取り扱い、セキュリティに関する基準やガイドラインについて説明していきます。

脆弱性診断に関連する法律、ルール、基準など

付録: 実習環境のセットアップ（Oracle VM VirtualBox）

Webアプリケーション脆弱性診断講座

本書を使ったトレーニングであれば筆者が教える弊社のこちらがお勧めです。

自社で取り組むWebアプリケーション脆弱性診断 | 株式会社トライコーダ
- https://www.tricorder.jp/education02.html

Aterm MR03LNが海外でもSIMフリーになった

Wed, 20 Aug 2014 00:00:00 +0900

モバイルルーターとしては最強と言われるほど申し分ない機能を持つ Aterm MR03LN は、当初SIMフリー機だと噂されていましたが、国内ONLYのDoCoMoのMVNOのSIMにしか対応していませんでした。

【最新】 MR03LN モバイルルーター最強伝説！ - NAVER まとめ

海外によく行く私としては、海外で使えないとモバイルルーターとしての意味がなく、買ってしばらくしてタンスの肥やしに。（買った理由は、クレードルを使うことで有線LANのネットワークが組めるからでした。出張時のサイバー演習のトレーニングに1回使ったっきり。）

そしてこの8月に期待していたファームウェア2系が公開されて、いろいろあって（ファームウェア2.0の公開停止とか）ようやくAPNの設定が自由にできるように！これは期待！ということで、ファームウェアを 2.0 にした MR03LN を今回の台湾出張（ハッカー系カンファレンスの HITCON に参加するため）

結果、松山空港で買った中華電信のプリペイドSIMを挿し、APN設定を行ったところ無事に動作を確認しました。安定性、速度ともにまったく問題ありません。（台湾ではLTEは今年開始しましたが、プリペイドSIMではLTE未対応らしい）

2.0は不具合があって心配していましたが、台湾滞在中の8月19日に2.1が公開されアップデートを行いましたので、これでいろいろ一安心。

このルーターは何と言っても、テザリング使用時はBluetoothで24時間、Wi-Fiで12時間というバッテリーの持ちが海外出張時に非常に便利です。
周波数的には多くの国に対応しているので、モバイルルーター最強伝説と言われていた Aterm MR03LN が個人的にも本当に最強になったかも。

NEC Aterm MR03LN【OCN モバイル ONE マイクロSIM付きセット】クレドール付属 LTE対応 SIMフリーモバイルルーター月額900円(税抜)~

発売元: NTTコミュニケーションズ
価格: ￥ 22,488 (12% OFF)
売上ランキング： 649

posted with Socialtunes

Facebookの写真は公開範囲を限定していても誰でも見ることができる

Thu, 26 Jun 2014 00:00:00 +0900

そう、URLさえわかればね。
セキュリティの講義のネタでよく話してるんですけど、以外と知られていないようなので。

公開範囲は自分のみ

URLさえわかれば表示することが可能です。下記はそのURLです。
https://scontent-a.xx.fbcdn.net/hphotos-xpa1/t31.0-8/10363467_10203851587031224_5439857412795849561_o.jpg
そういう仕様っていうだけなんですけどね。URLは予測することが困難そうですし、あんまり悪用方法は思いつきません。以前のmixiもそういう仕様だったような気がする。
仲間内に限定公開とかしていて、その仲間の誰かが裏切って、あいつこんな写真公開してるぜ。とかぐらいだろうけど、それだったらURLを直リンクじゃなくてもいいですしね。

今夜つける HTTPレスポンスヘッダー（セキュリティ編）

Sat, 30 Nov 2013 00:00:00 +0900

Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。
囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。

X-Frame-Options

ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。

X-Frame-Options: SAMEORIGIN

DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です）
SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこれを使用します）
ALLOW-FROM origin_uri 指定された生成元のみページを表示することを許可（特定のサイトのみに許可したい場合はこれを使用します）

X-Frame-Options レスポンスヘッダ - HTTP | MDN

X-Content-Type-Options

script または stylesheet で読み込むファイルの MIME タイプが正しい（許可された）ものと一致しない限りファイルを読み込みません。非HTMLをHTMLと見なすなど、コンテンツ内容の誤判定を利用した XSS などの攻撃を防ぐために用いられます。

X-Content-Type-Options: nosniff

機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
 MIME タイプのセキュリティリスクの軽減 (Windows)

X-XSS-Protection

ブラウザの XSSフィルターの機能を有効にし、XSS攻撃を防ぐために用いられます。

X-XSS-Protection: 1; mode=block

0 XSSフィルターを無効
1 XSSフィルターを有効（IE,Chromeの場合は 1; mode=block が使える）

2008/7/2 - IE8 Security Part IV: The XSS Filter
IE8 XSS Filterの仕様が微妙に変更されていた。 - 葉っぱ日記

Content-Security-Policy

外部のリソースを信頼できる生成元以外から読み込めないように制限することができます。XSSやデータインジェクション攻撃を検出して軽減することがあります。（ただし、設定によっては外部リソースを読み込めないようにすることによって、現在動作しているスクリプトが動かなくなる可能性があります。）
以前は、"X-Content-Security-Policy" というヘッダーフィールド名を使っていました。

Content-Security-Policy: default-src 'self'

default-src 'self' 同じオリジン（同じURLスキーム、ホスト、ポート番号）からはすべてのコンテンツを読み込むようにしたい場合
default-src 'self' *.example.com 指定したドメインとすべてのサブドメインからのコンテンツを許可したい場合

CSP (Content Security Policy) - Security MDN

X-Permitted-Cross-Domain-Policies

「crossdomain.xml 」（Flash コンテンツから別ドメインにあるファイルを読み込む際に必要になる設定を記述したポリシーファイル）をサイトのドキュメントルートに置くことができない場合などに、同様の効果を発揮することができます。

X-Permitted-Cross-Domain-Policies: master-only

master-only マスターポリシーファイル（ /crossdomain.xml）のみが許可される

Flash Player 9および10におけるポリシーファイル関連の変更点 | デベロッパーセンター

Strict-Transport-Security

指定されたサイトが常に HTTPS プロトコルを使ってアクセスするようにブラウザに指示します。HTTPのサイトからHTTPSにリダイレクトするより安全に誘導する方法です。

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age STSを有効にする期間、想定される再訪問の時間より遙かに長い目に設定した方がよい
includeSubDomains サブドメインにもルールを適用する。

HTTP Strict Transport Security - The Chromium Projects
HTTP Strict Transport Security - Security | MDN

Access-Control-Allow-Origin など CORS 関連

XMLHttpRequestを使って、他のドメインなどからリソースを取得したいクロスドメイン通信をしたい場合に指定します。使う場合には詳しくはCORS (Cross-Origin Resource Sharing)勧告などを参考にして下さい。

Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-TRICORDER
Access-Control-Max-Age: 1728000

上記は "http://www.example.com" からのクロスドメイン通信をしたい場合の設定で、当該リソースへの問い合わせには POST, GET, OPTIONS が実行可能なメソッド、カスタムヘッダーとして "X-TRICORDER" を付けたリクエストを送信し、プリフライトのレスポンスをキャッシュしていい時間が 1,728,00 秒だということを表しています。
HTTP access control (CORS) | MDN

X-Download-Options

ユーザーがダウンロードしたファイルを直接"開く"ことを防止したい場合に指定します。

X-Download-Options: noopen

noopen IE8以降ではユーザーはファイルを直接開くことができず、ローカルに保存することになります。ダウンロードのダイアログから"開く"がなくなります。

IE8 Security Part V: Comprehensive Protection - IEBlog - Site Home - MSDN Blogs

Set-Cookie

Cookie をセットします。サーバーがクライアントに対して状態管理を始める際などにさまざまな情報を伝えます。

Set-Cookie: name=value; secure; HttpOnly

secure HTTPSで通信している場合にのみ Cookie を送信する
HttpOnly Cookie を JavaScript からアクセスできないようにする
path 属性は Cookie を送出するディレクトリを限定する指定ですが、回避する方法がありセキュリティ機構としては期待できません。
domain 属性は後方一致になります。明示的に複数ドメインに対して Cookie を送出する場合を除いて、この属性は設定しない方が安全です。

Cache-Control

ディレクティブと呼ばれるコマンドを指定することで、ブラウザのキャッシング動作を指定します。

Cache-Control: no-cache, no-store, must-revalidate

no-cache キャッシュサーバーはリソースを格納してはならない。また有効性の再確認なしではキャッシュを使用してはならない
no-store キャッシュはリクエスト・レスポンスの一部分をローカルストレージに保存してはならない
must-revalidate キャッシュ可能であるが、オリジンサーバーにリソースの再確認を要求する

pragma

HTTP/1.0との後方互換性のためだけに定義されているヘッダーフィールドで、本来はクライアントからのリクエストのみに使用されます。"Cache-Control: no-cache”と併記するとよいでしょう。

pragma: no-cache

no-cache クライアントがすべての中間サーバーに対して、キャッシュされた応答を望まないことを要求する

expires

リソースの有効期限の日時を伝えます。キャッシュされることを望まない場合には、Date ヘッダーフィールドの値と同じに設定するか、"-1"と設定します。

expires: -1

HOWTO Internet Explorer でキャッシュを無効にする

content-type

エンティティボディに含まれるオブジェクトのメディアタイプを伝えます。charsetでは文字セットを指定します。正しいメディアタイプの設定と、正しい文字コードを正しい表記で設定しましょう。

content-type: text/html;charset=utf-8

HTTPレスポンスヘッダーの設定の仕方

Apache で追加する場合には、httpd.conf の中で下記のモジュールが有効になっている必要があります。

LoadModule headers_module modules/mod_headers.so

常に表示する HTTP レスポンスヘッダーを追加するには、下記のように設定を行います。

Header set HeaderFieldName "value"

Header set X-XSS-Protection "1; mode=block”

タイトルは、拙著『今夜わかるHTTP』からですが、『HTTPの教科書』の方が新しい本です。また、セキュリティ編としてますがたぶん完結です。2に続くか…？
ご意見などお待ちしています。そのうち OWASP Japan の OWASP Night でも紹介するかも。

HTTPの教科書

発売元: 翔泳社
価格: ￥ 2,730
発売日: 2013/05/25

posted with Socialtunes

追記

2013/12/01 "Access-Control-Allow-Origin"などCORS関連、"X-Download-Options"を追記しました。その他説明を微修正。コメント頂いた @hasegawayosuke さん、@kinugawamasato さん、@ockeghem さん、@hirayasu さんありがとうございます。

クレジットカードのセキュリティコードの保存は禁止

Tue, 28 May 2013 00:00:00 +0900

私も海外でよく使っていたイモトのWi-Fi「GLOBALDATA」のWebサーバーに不正アクセスがあり、調査の結果最大146,701件のクレジットカード情報を含む情報漏えいがあったことが判明しています。

不正アクセスによるお客様情報流出に関するお知らせとお詫び | エクスコムグローバル株式会社｜XCom Global, Inc. (Japan)

リリースによると漏えいした情報は下記の通りと、この情報が揃えば大半のサイトのオンライン決済で利用できるでしょう。

カード名義人名
カード番号
カード有効期限
セキュリティコード
お申込者住所

この中の「セキュリティコード」ですが、これはVISAやMasterでは「CVV」や「CV2」などと呼ばれている不正使用防止のための番号で、カードの裏面などに記載されているものです。
この「セキュリティコード」はカードに記載された番号を確認することで、カードの実物を持った所有者であることを確かめるセキュリティ対策なので、オンライン決済をしている加盟店のWebサーバーが保存してはいけません。

JCCA 日本クレジットカード協会が定める「新規インターネット加盟店におけるクレジットカード決済に係る本人認証導入による不正使用防止のためのガイドライン」にも「加盟店にてセキュリティコードを保存することは、禁止する。」という一文があります。

- http://www.jcca-office.gr.jp/up/file/%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3.pdf

セキュリティコードを保存する実装にしているオンライン決済サイトはすぐにでも修正しましょう。また、上記ガイドラインにもある3Dセキュアなどの本人認証を導入すべきでしょう。

それにしても、エクスコムグローバル社は不正アクセスの件を4月23日から把握していて調査しているようですが、発表が5月27日とかなり遅いですね。

私も被害者ですが、ここまでの情報が漏えいするとクレジットカード番号は再発行になるかもしれませんね…。最近各所で漏えい事件の被害者としてヒットしていますが、そのたびにクレジットカード番号を変更とかになると、いろんなサイトの決済情報を変更しなければいけなくて本当にめんどうくさいですね。

Webに関わる人のための『HTTPの教科書』を発売

Tue, 21 May 2013 00:00:00 +0900

ひさびさの単著となる『HTTPの教科書』が2013年5月24日に発売になります。
内容はタイトルの通り、Webに関わる全ての人に捧げるHTTPを学ぶための教科書です。基礎を学びたい初心者の方から、机の上に置いてリファレンス的に使いたい方までを対象としています。

HTTPの教科書

発売元: 翔泳社
価格: ￥ 2,730
発売日: 2013/05/25

posted with Socialtunes at 2013/05/21

HTTP関連の書籍は『今夜わかるHTTP (Network)』というタイトルの本を2004年に出しています。その頃からHTTP/1.1が主流であるというのは、今でも変わりませんがそれを取り巻く環境というのは変わりつつあります。
HTTPを学ぶ上での要点がわかりやすく、そして読みやすくなっております。前作のリニューアルっぽく感じるかと思いますが、9割以上は書き直しや追記しております。
また、レビューアとして、Masato Kinugawaさん、山崎圭吾さん、ネットエージェント株式会社はせがわようすけさんなどもお迎えして、よりよい一冊となっております。

以下は本書の目次になります。
第1章　Web とネットワークの基本を知ろう
1.1 Web はHTTP で見えている
1.2 HTTP はこうして生まれ育った
　1.2.1　Web は知識共用のために考案された
　1.2.2　Web が成長した時代
　1.2.3　進歩しないHTTP
1.3 ネットワークの基本はTCP/IP
　1.3.1　TCP/IP はプロトコル群
　1.3.2　階層で管理するTCP/IP
　1.3.3　TCP/IP の通信の流れ
1.4 HTTPと関係深いプロトコル IP・TCP・DNS
　1.4.1　配送を担当するIP
　1.4.2　信頼性を担当するTCP
1.5 名前解決を担当するDNS
1.6 それぞれとHTTP の関係
1.7 URIとURL
　1.7.1　URI はリソースの識別子
　1.7.2　URI のフォーマット
　
第2章　シンプルなプロトコルHTTP
2.1 HTTP はクライアントとサーバーで通信を行う
2.2 リクエストとレスポンスの交換で成り立つ
2.3 HTTP は状態を保持しないプロトコル
2.4 リクエストURI でリソースを識別する
2.5 サーバーに指示を与えるHTTP メソッド
2.6 メソッドを使って指示を出す
2.7 持続的接続で通信量を節約
　2.7.1　持続的接続
　2.7.2　パイプライン化
2.8 Cookie を使った状態管理

第3章　HTTPの情報はHTTP メッセージにある
3.1 HTTP メッセージ
3.2 リクエストメッセージとレスポンスメッセージの構造
3.3 エンコーディングで転送効率を上げる
　3.3.1　メッセージボディとエンティティボディの違い
　3.3.2　圧縮して送るコンテンツコーディング
　3.3.3　分解して送るチャンク転送コーディング
3.4 複数のデータを送れるマルチパート
3.5 一部分だけ貰えるレンジリクエスト
3.6 最適なコンテンツを返すコンテンツネゴシエーション

第4章　結果を伝えるHTTP ステータスコード
4.1 ステータスコードはサーバーからのリクエスト結果を伝える
4.2　2XX 成功（Success）
　4.2.1　200 OK
　4.2.2　204 No Content
　4.2.3　206 Partial Content
4.3　3XX リダイレクト（Redirection）
　4.3.1　301 Moved Permanently
　4.3.2　302 Found
　4.3.3　303 See Other
　4.3.4　304 Not Modified
　4.3.5　307 Temporary Redirect
4.4　4XX クライアントエラー（Client Error）
　4.4.1　400 Bad Request
　4.4.2　401 Unauthorized
　4.4.3　403 Forbidden
　4.4.4　404 Not Found
4.5　5XX サーバーエラー（Server Error）
　4.5.1　500 Internal Server Error
　4.5.2　503 Service Unavailable

第5章　HTTPと連携するWeb サーバー
5.1　1台で複数ドメインを実現するバーチャルホスト
5.2 通信を中継するプログラム：プロキシ、ゲートウェイ、トンネル
　5.2.1　プロキシ
　5.2.2　ゲートウェイ
　5.2.3　トンネル
5.3 リソースを保管するキャッシュ
　5.3.1　キャッシュには有効期限がある
　5.3.2　クライアント側にもキャッシュがある

第6章　HTTP ヘッダー
6.1 HTTP メッセージヘッダー
6.2 HTTP ヘッダーフィールド
　6.2.1　HTTP ヘッダーフィールドは重要な情報を伝える
　6.2.2　HTTP ヘッダーフィールドの構造
　6.2.3　種類のHTTP ヘッダーフィールド
　6.2.4　HTTP/1.1 ヘッダーフィールド一覧
　6.2.5　HTTP/1.1 以外のヘッダーフィールド
　6.2.6　エンドトゥエンドヘッダーとホップバイホップヘッダー
6.3 HTTP/1.1 一般ヘッダーフィールド
　6.3.1　Cache-Control
　6.3.2　Connection
　6.3.3　Date
　6.3.4　Pragma
　6.3.5　Trailer
　6.3.6　Transfer-Encoding
　6.3.7　Upgrade
　6.3.8　Via
　6.3.9　Warning
6.4 リクエストヘッダーフィールド
　6.4.1　Accept
　6.4.2　Accept-Charset
　6.4.3　Accept-Encoding
　6.4.4　Accept-Language
　6.4.5　Authorization
　6.4.6　Expect
　6.4.7　From
　6.4.8　Host
　6.4.9　If-Match
　6.4.10　If-Modified-Since
　6.4.11　If-None-Match
　6.4.12　If-Range
　6.4.13　If-Unmodified-Since
　6.4.14　Max-Forwards
　6.4.15　Proxy-Authorization
　6.4.16　Range
　6.4.17　Referer
　6.4.18　TE
　6.4.19　User-Agent
6.5 レスポンスヘッダーフィールド
　6.5.1　Accept-Ranges
　6.5.2　Age
　6.5.3　ETag
　6.5.4　Location
　6.5.5　Proxy-Authenticate
　6.5.6　Retry-After
　6.5.7　Server
　6.5.8　Vary
　6.5.8　WWW-Authenticate
6.6 エンティティヘッダーフィールド
　6.6.1　Allow
　6.6.2　Content-Encoding
　6.6.3　Content-Language
　6.6.4　Content-Length
　6.6.5　Content-Location
　6.6.6　Content-MD5
　6.6.7　Content-Range
　6.6.8　Content-Type
　6.6.9　Expires
　6.6.10　Last-Modified
6.7 Cookie のためのヘッダーフィールド
　6.7.1　Set-Cookie
　6.7.2　Cookie
6.8 その他のヘッダーフィールド
　6.8.1　X-Frame-Options
　6.8.2　X-XSS-Protection
　6.8.3　DNT
　6.8.4　P3P

第7章　Webを安全にするHTTPS
7.1 HTTP の弱点
　7.1.1　通信が平文なので盗聴可能
　7.1.2　通信相手を確かめないのでなりすまし可能
　7.1.3　完全性を証明できないので改竄可能
7.2 HTTP＋暗号化＋認証＋完全性保護＝HTTPS
　7.2.1　HTTP に暗号化と認証と完全性保護を加えたHTTPS
　7.2.2　HTTPS はSSL の殻をかぶったHTTP
　7.2.3　お互いが鍵を交換する公開鍵暗号方式
　7.2.4　公開鍵が正しいかどうかを証明する証明書
　7.2.5　安全な通信を行うHTTPS の仕組み

第8章　誰がアクセスしているかを確かめる認証
8.1 認証とは
8.2 BASIC 認証
　8.2.1　BASIC 認証の認証手順
8.3 DIGEST 認証
　8.3.1　DIGEST 認証の認証手順
8.4 SSL クライアント認証
　8.4.1　SSL クライアント認証の認証手順
　8.4.2　SSL クライアント認証は2 要素認証で使われる
　8.4.3　SSL クライアント認証は利用するのにコストが必要
8.5 フォームベース認証
　8.5.1　認証の大半はフォームベース認証
　8.5.2　セッション管理とCookie による実装

第9章　HTTP に機能を追加するプロトコル
9.1 HTTP をベースにしたプロトコル
9.2 HTTPのボトルネックを解消するSPDY
　9.2.1　HTTP のボトルネック
　9.2.2　SPDY の設計と機能
　9.2.3　SPDY はWeb のボトルネックを解決するか？
9.3 ブラウザで双方向通信を行うWebSocket
　9.3.1　WebSocket の設計と機能
　9.3.2　WebSocket プロトコル
9.4 登場が待たれるHTTP/2.0
9.5 Web サーバー上のファイル管理を行うWebDAV
　9.5.1　HTTP/1.1 を拡張したWebDAV
　9.5.2　WebDAV で追加されたメソッドとステータスコード

第10章　Web コンテンツで使う技術
10.1 HTML
　10.1.1　Web ページのほとんどはHTML でできている
　10.1.2　HTML のバージョン
　10.1.3　デザインを適用するCSS
10.2 ダイナミックHTML
　10.2.1　Web ページを動的に変更するダイナミックHTML
　10.2.2　HTML を操作しやすくするDOM
10.3 Web アプリケーション
　10.3.1　Web を使って機能を提供するWeb アプリケーション
　10.3.2　Web サーバーとプログラムを連携するCGI
　10.3.3　Java で普及したサーブレット
10.4 データ配信に利用されるフォーマットや言語
　10.4.1　汎用的に使えるマークアップ言語XML
　10.4.2　更新情報を配信するRSS ／ Atom
　10.4.3　JavaScript から利用しやすく軽量なJSON

第11章　Web への攻撃技術
11.1 Web への攻撃技術
　11.1.1　HTTP は必要なセキュリティ機能がない
　11.1.2　リクエストはクライアント側で改竄可能
　11.1.3　Web アプリケーションへの攻撃パターン
11.2 出力値のエスケープの不備による脆弱性
　11.2.1　クロスサイト・スクリプティング
　11.2.2　SQL インジェクション
　11.2.3　OS コマンドインジェクション
　11.2.4　HTTP ヘッダーインジェクション
　11.2.5　メールヘッダーインジェクション
　11.2.6　ディレクトリ・トラバーサル
　11.2.7　リモート・ファイル・インクルージョン
11.3 設定や設計の不備による脆弱性
　11.3.1　強制ブラウジング
　11.3.2　不適切なエラーメッセージ処理
　11.3.3　オープンリダイレクト
11.4 セッション管理の不備による脆弱性
　11.4.1　セッションハイジャック
　11.4.2　セッションフィクセーション
　11.4.3　クロスサイト・リクエストフォージェリ
11.5 その他
　11.5.1　パスワード・クラッキング
　11.5.2　クリックジャッキング
　11.5.3　DoS 攻撃
　11.5.4　バックドア

※初版は目次内に間違えている部分があります。大変申し訳ありません。
※2刷で目次は修正されました。

コマンドラインから画面共有をONにする方法 for OS X Mountain Lion

Mon, 25 Mar 2013 00:00:00 +0900

システム環境設定からONにすればいいんですけど、なぜかシステム環境設定のロックが外せなくなったので、コマンドラインから各種設定変更を模索してみました。
コマンドラインから画面共有をONにするには、下記のコマンドをターミナルから実行します。

# sudo defaults write /var/db/launchd.db/com.apple.launchd/overrides.plist com.apple.screensharing -dict Disabled -bool false
# sudo launchctl load /System/Library/LaunchDaemons/com.apple.screensharing.plist

ssh とかでもONにできるので、人によっては便利かも。動作は OS X Mountain Lion（10.8.3）で確認しました。

Enabling OS X Screen Sharing from the Command Line - Pivotal Labs

OWASP Top 10 2013 RC1リリース＆日本語訳（ちょっとだけ）

Wed, 20 Feb 2013 00:00:00 +0900

OWASP Japan Leader らしく、OWASP Top 10 2013 RC1版の紹介でも。

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

OWASPでは、PCI DSSなどでも参照しているOWASP Top 10 の 2013年版のリリース準備中です。現在、RC1をリリースして、コメントを募集しています。こちらまでお願いします。 OWASP-TopTen@lists.owasp.org
新規追加のものも名称を日本語に訳しましたが、もっと適切な言葉があれば教えて下さい。

OWASP Top 10 - 2013 RC1

A1 インジェクション攻撃（Injection）
A2 不完全な認証とセッション管理（Broken Authentication and Session Management）
A3 クロスサイト・スクリプティング（Cross-Site Scripting (XSS) ）
A4 安全でないオブジェクトの直接参照（Insecure Direct Object References）
A5 セキュリティの不適切な設定（Security Misconfiguration）
A6 機密データの露出（Sensitive Data Exposure）
A7 機能レベルのアクセス制御の欠落（Missing Function Level Access Control ）
A8 クロスサイト・リクエスト・フォージェリ（Cross-Site Request Forgery (CSRF)）
A9 既知の脆弱なコンポーネントの使用（Using Known Vulnerable Components）
A10 検証されていないリダイレクトとフォーワード（Unvalidated Redirects and Forwards）

詳細はRC1版を参照して下さい。

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20RC1.pdf

OWASP Top 10 - 2010 から何が変わったか

2013年版では主に下記の変更が加えられる予定です。

「不完全な認証とセッション管理（Broken Authentication and Session Management ）」が拡がってきたので、A3からA2に上がりました。XSSがA3に。
「クロスサイト・リクエスト・フォージェリ（Cross-Site Request Forgery (CSRF)）」がA5からA8に下がりました。開発者はCSRF 脆弱性の数を減らすために努力しているようです。
「URLアクセス制限の不備（Failure to Restrict URL Access）」はもっと広い意味にして、A7の「機能レベルのアクセス制御の欠落（Missing Function Level Access Control ）」としました。
2010のA7 安全でない暗号化によるデータ保存（Insecure Cryptographic Storage）とA9 不十分なトランスポート層の保護（Insufficient Transport Layer Protection）から新しいカテゴリ A6の「機密データの露出（Sensitive Data Exposure）」を作りました。
新しく A9の「既知の脆弱なコンポーネントの使用（Using Known Vulnerable Components）」を作りました。

OWASPは皆様に支えられています。参加をお待ちしています。

Japan - OWASP

脆弱性報奨金プログラムを提供しているサイト一覧

Sat, 15 Dec 2012 00:00:00 +0900

いわゆる"Bug Bounty Programs"と言われている、Webサイトの脆弱性情報などを受け付けて、それに報奨金を出すというプログラムです。報奨金で飯を食えるようになるといいですね。

Google
- Program Rules – Application Security – Google
facebook
- Security Bug Bounty - Facebook
Etsy（ハンドメイド商品のマーケットプレイス）
- Announcing the Etsy Security Bug Bounty Program « Code as Craft
Barracuda Networks（セキュリティ機器）
- Barracuda Networks Security Bug Bounty Program
Yandex（ロシアのGoogle的な。今年モスクワのオフィスに遊びに行かせて頂きました。）
- Yandex.Company ― Bug Bounty Program

以下は、バグハンターの名前は掲載するけど、報奨金は出さないサイト。

Adobe
- Adobe - Security advisories
Twitter
- Twitter / セキュリティ
EBay
- Security Researchers Acknowledgment
Microsoft
- http://technet.microsoft.com/en-us/security/ff852094.aspx
- http://technet.microsoft.com/en-us/security/cc308589
- http://technet.microsoft.com/en-us/security/cc308575
- http://technet.microsoft.com/en-us/security/cc261624
- http://www.microsoft.com/security/msrc/default.aspx
Apple
- http://support.apple.com/kb/HT1318
- https://ssl.apple.com/support/security/
Dropbox
- Dropbox - 規約
- Dropbox - スペシャルサンクス
Reddit
- help/whitehat – reddit – Trac
Github
- Responsible Disclosure of Security Vulnerabilities · github:help
Ifixit（iPhone修理とか）
- Responsible Disclosure of Security Vulnerabilities - iFixit
37 Signals
- 37signals security response
Twilio（クラウド電話）
- Reporting Security Vulnerabilities
Constant Contact（マーケティング）
- Report A Security Vulnerability - Constant Contact
Engine Yard（Ruby,PHP クラウドプラットフォーム）
- Responsible Disclosure Policy
Lastpass（パスワードマネージャー）
- LastPass - セキュリティ
RedHat
- Vulnerability Acknowledgements for Red Hat online services - Red Hat Customer Portal
Acquia（CMSのDrupal）
- How to responsibly report a security issue | Acquia
Zynga
- Whitehats | Zynga
Owncloud（自分専用クラウド）
- Security Policy | ownCloud.org
- Security Hall of Fame | ownCloud.org
Tuenti（SNS）
- Thank You! | Tuenti Corporate
soundcloud（音楽シェア）
- SoundCloud | Responsible Disclosure
Nokia Siemens Networks
- Responsible disclosure | Nokia Siemens Networks

スペシャルサンクスには、何人か知っている名前を見かけますね。もちろん、日本人のあの人も！

List of Bug Bounty program for PenTesters and Ethical Hackers | Hacking News | Security updates

報奨金プログラムやっているサイトの追記情報をもらいました！

Mozilla
- Mozilla Security Bug Bounty Program
Hex-Rays（IDAの）
- Bug Bounty
PayPal
- For Security Researchers - PayPal

追記

Mon, 12 Nov 2012 00:40:00 +0900

ハッシュじゃなくて、いわゆる暗号化してるんじゃない？とか平文じゃないんじゃない的なことを言う人もいますが、この場合わざわざ鍵の管理がめんどうな暗号化を選ぶ理由はないと思いますが。

お名前.comのレンタルサーバーが平文でパスワードを保存している

Mon, 12 Nov 2012 00:00:00 +0900

お名前.comで取ってるドメインがあったので、とりあえずレンタルサーバーも使ってみようと申し込んでみました。

月額1575円の共用サーバー SD｜ドメイン取得ならお名前.com

設定を始めたところ、設定用のWebインタフェースのコントロールパネルに、メールアカウントや管理者アカウント、FTPアカウントなどのパスワードが表示されるという状況でした。

※パスワードの箇所は暗号化されていないパスワード文字列
さらに、パスワード変更の際には旧パスワードの入力もいらないという仕様。
そして、コントロールパネルの横のお知らせには「セキュリティ対策は万全ですか？」とか出ててシュール。

サポートセンターに「パスワードを平文で保存しているのか？」ということや「なぜWebにパスワードをわざわざ表示するのか？」について問い合わせてみたところ、下記の回答がきました。

弊社サーバーNavi、および、コントロールパネルにつきましてはSSL(Secure Socket Layer)での通信を採用いたしております。
SSL：インターネット上で情報を暗号化して送受信するプロトコル
サーバー上でのパスワード保管につきましては、弊社にて行なわせていただいておりますので、ご安心ください。
>Webのコントロールパネルにパスワードを表示する必要があるのでしょうか？
安全な形式にてお客様にパスワードをご確認いただくための対応でございます。

今後ともお名前.comをよろしくお願いいたします。

「ご安心下さい」って何だよ。今後ともよろしくお願いいたしますじゃないよ。

SEC職員がBlackHatに暗号化していないPCを持ち込み。検証に20万ドル。

Sat, 10 Nov 2012 00:00:00 +0900

米国証券取引委員会（The US Securities and Exchange Commission : SEC）の職員が、ハッカーの会議（たぶん今年のBlackHat USA？）に機密情報がたくさん入ったPCを持ち込んだおかげで、安全かどうかの検証に20万ドルも費やす結果となったそうです。
PCのデータは機密情報が暗号化されていない状態で、場合によっては情報が取り放題だったようです。なぜ、職員がこのPCを持ってきたのかは明確にはなっていません。

検証の結果は情報漏えいの痕跡はなかったようですが、どうなんでしょうね。もしくは、DEFCONにも参加してたら…。気軽に機密情報入りのPCを持ち歩くと大変なことになりますね。

Exclusive - SEC left computers vulnerable to cyber attacks - sources | Reuters

サイバー犯罪対策コストのレポート2012が興味深い

Wed, 31 Oct 2012 00:00:00 +0900

HPが主催し、英国のPonemon Instituteが調査したさまざまな産業分野の38団体のサンプルに基づくセキュリティのベンチマーク調査レポートです。

サイバー犯罪は被害・対策ともに高く付く。年間平均コストは平均210万£（約2.7億円）で、4百万£〜770万£の範囲
最も高く付いたサイバー犯罪は、DoS攻撃と不正なプログラムによる被害
サイバー犯罪対策コストは組織規模や産業によって異なる。防衛・公益事業・エネルギー・金融サービスは、他の産業より高い

レポートはコストに関するさまざまな項目が調査されていて、興味深いですね。
「5カ国のサイバー犯罪の総コスト」では、英国、AU、日本、DE、米国がビックアップされていて、日本は真ん中の3番目でした。
他にも、「業種別の平均年間コスト」、「38ベンチマーク企業が経験したサイバー攻撃の種類」、「攻撃を解決するまでの平均日数」、「活動コストの比較とセキュリティインテリジェンス技術の利用」、「国別のサイバー犯罪対策の内部コスト／外部コスト」など面白いレポートが目白押し。セキュリティの予算をいくらにするのかとかの参考にもなるかもしれません。

2012 Cost of Cyber Crime Study: UK by ComputerWeekly.com

登録が必要ですが、無料で読めるので一読をお勧めします。

2012 Cost of Cyber Crime Study: United States - HP Enterprise Security

US版のレポートもありました。

11月7日、8日にイベントもあるみたいです！

The Cost of Cyber Crime: Live Webinar - HP Enterprise Security

このレポート、日本のHPさんが翻訳版とか出さないかなァ。

イーモバイルを電話だけで解約、書類もSIM返送も必要なし

Thu, 04 Oct 2012 00:00:00 +0900

ちょうどイーモバイルを契約して2年、ソフトバンクグループになったし、WiMAXは快適だし、iPhone5はDoCoMoだし、と継続する理由も特になかったのでいいタイミングで解約しました。以前は、店頭に行くのが一番という解約難所のイーモバイルでしたが、電話だけで解約できました。手順は以下の通り。
まず、手元に契約時に登録した電話番号とネットワーク暗証番号を用意して、カスタマーセンターに電話して、解約の窓口につなげます。

お問い合わせ | イー・モバイル

登録時の電話番号、名前、ネットワーク暗証番号を聞かれたら、「解約する書面を郵送します」うんぬんと言われますが、「他に方法は？」と聞くと「電話だけで解約できます」と言われますので、そのまま手続きをどうぞ。
SIMの返送も必要ありません。ハサミで切って捨てて下さい。と言われます。

サヨナラ、イーモバイル！
また契約するかもしれないけど。

iPhone5 + docomo を都内で使ってみて

Fri, 28 Sep 2012 00:00:00 +0900

いつものExpansysからiPhone5 64GB（GSM A1429）を買いました。もちろん香港版のSIMフリー。LTEが使えないとか、FOMAプラスエリアが使えないとか、いろんな問題がありますがとりあえず新しい端末は快適です。
気になる電波状況ですが、LTEは使えないのはさておき、FOMAプラスのエリアが気になる人が多いみたいですね。とりあえず、都内にいる限りは使えなくっても何ら問題なさそうです。iPhone4S + docomo のときと全然変わりません。むしろ、端末が快速なので快適です。
テザリングの使い勝手はSoftbankやauに比べてもぜんぜん問題なし。むしろ制限もなし。

23区に住んでて都心で生活しているなら、iPhone5でDoCoMoを使うって選択肢も物好きにはありだと思います。
WiMAXもemobileもIIJmioも持ってるので、回線速度が欲しいときはそちらを使ってます。地方出張はたまにしか行かないし、月に1回ぐらい海外なので、やっぱりSIMフリー端末がいい。
そのうちJailbreakでLTEが使えるようになったりしたらいいなァ。

XSS Filter 回避のためのチートシート（旧XSS Cheat Sheet）

Wed, 19 Sep 2012 00:00:00 +0900

OWASPではXSS Filter 回避のためのチートシート（XSS Filter Evasion Cheat Sheet）を公開しました。
これは有名な「XSS (Cross Site Scripting) Cheat Sheet（http://ha.ckers.org/xss.html）」を移行したものです。Robert "RSnake" Hansenの協力に感謝！

XSS Filter Evasion Cheat Sheet - OWASP

Mac OS Xの全パスワード表示と自動ロック

Fri, 14 Sep 2012 00:00:00 +0900

ターミナルを起動して下記のコマンドを実行する。

security dump-keychain -d ~/Library/Keychains/login.keychain

「”security”がキーチェーン”ログイン”を使おうとしています。キーチェーンのパスワードを入力して下さい」とパスワードを聞いてこない場合、あなたのコンピュータのすべてのパスワードは読み取り放題な状況になっています。他人に安易にPCを貸してはいけません。（このコマンドの実行を止めるには Control+c）

この状況を改善するには、Spotlightなどで「keychain」と入れて「キーチェーンアクセス」を起動して、左上の錠前アイコンをロック状態にしておきましょう。

自動ロックを有効にする場合には、キーチェーンアクセスの「ログイン」を右クリックして設定変更を起動し、「操作しない状態がX分続いたらロック」や「スリープ時にロック」にチェックを入れます。

Print out all your saved passwords – OSX | Song Zheng

30秒であなたのsshを二要素認証対応に

Wed, 29 Aug 2012 00:00:01 +0900

GoogleやDropboxなどが次々と二要素認証に対応していますが、そろそろウチのsshも二要素認証対応にという方向けに。30秒の簡単導入です。

$ curl 'https://raw.github.com/authy/authy-ssh/master/authy-ssh' -o authy-ssh
$ sudo bash authy-ssh install /usr/local/bin
$ sudo /usr/local/bin/authy-ssh enable `whoami`   
$ authy-ssh test
$ sudo service ssh restart

AuthyというサービスのAPIを利用するみたいですね。このサービスがなくなったらどうなるんだろう…。
sshは公開鍵認証がいい気がする。あと、22/tcpではない違うポート番号で運用と。

Authy Blog! Awesome two-factor authentication

ベルアメールのチョコと焼き菓子セット

Wed, 29 Aug 2012 00:00:00 +0900

おやつ用に。大丸東京店のほっぺタウンが拡張してベルアメールとかいろいろ入ってます。
甘味じゃないけど、ヤザワミートのお弁当が買えるのも嬉しいです。けど、弁当で30分待ちとか本店の行列を彷彿させる感じです…。

千疋屋のフルーツプリン、レアチーズケーキ、マンゴープリン

Tue, 28 Aug 2012 00:00:00 +0900

マンゴープリンのプリン部分が濃厚で果実味もあって美味しかった。チーズケーキやフルーツプリンも果物が美味しい。フルーツプリンはラム酒が効いていました。

京橋千疋屋東京駅一番街店

ジャンル：フルーツパーラー
住所：千代田区丸の内1-9-1 東京駅一番街 B1F 北通り
このお店を含むブログを見る |
(写真提供：iidagmt)

Mountain Lionにアップデートしたら、スリープ後の復帰に失敗して再起動する問題

Thu, 23 Aug 2012 00:00:00 +0900

MacOS X Mountain Lionにupgradeインストールしたら、スリープして、復帰するときに何度かに一度結構な高確率で再起動してしまっている問題にセキュリティキャンプ中に悩まされていました。最初はMBP Retina個体の問題かと思っていましたが、MBP Airの方でも同様の問題が出ていました。
サポートセンターに電話して、PRAMクリアとかいろいろ試してみましたが治らず。結局、初期化してクリーンインストールすることで無事にスリープからうまく復帰するようになりました。
Airはまだクリーンインストールしていませんが、Retinaの方は今のところ不具合は出ていません。

アンリ・シャルパンティエのゼリーセット

Sun, 19 Aug 2012 00:00:00 +0900

テリーヌ・ドゥ・フリュイというなのフルーツゼリーを頂きました。濃厚なお菓子も好きですが、盛夏にはさっぱりしたゼリーがとても合いますね。

BlackHat、DEFCON、セキュリティキャンプと連続出張が終わったので、ようやく腰を落ち着けて日本で甘味が食べられそうです。

Beans Nuts の豆詰め合わせ

Thu, 09 Aug 2012 00:00:00 +0900

久々の日本橋三越。夏はケーキよりも、和菓子とかつまみとかに惹かれます。試食して美味しかったので購入。日本橋三越では、今ならオリジナル風呂敷に包んでくれるというキャンペーンもやってます。お持たせにいいね。

ボルチーニとかわさびがおすすめ。わさびは結構なわさび辛さです。

Beans Nuts

BlackHat・DEFCONでラスベガス行ったり、何だかんだで甘味の更新をサボり気味でした。ちゃんとしっかり食べてますよ！

JavaScriptによるIntel Core2Duo脆弱性を利用したリモートExploit

Sun, 15 Jul 2012 00:00:01 +0900

Intel Core2DuoのCPUキャッシュコントローラーの脆弱性を利用したリモートコード実行のPoCが公開されています。Core2Duo以外にもAtomでも動くそうです。

Intel Core2Duo cpu cache controller bug PoC | Inj3ct0r - exploit database : vulnerability : 0day : shellcode（テキストなのでコードは実行されません。）

JavaScriptで動作するので、ブラウザで観ただけで死ねます。NoScriptなどによる防御が必須ですね。

※fakeかも。HITB2008って書いてるし。

中国は世界中の通信の80%にアクセス可能なバックドアを持っている

Sun, 15 Jul 2012 00:00:00 +0900

元ペンタゴンのアナリストによると、中国政府または人民解放軍が世界の通信の約80％にアクセスできるバックドアを持っていると伝えています。
中国企業のHuawei社とZTE社製品のネットワーク機器にバックドアがあるので、それらを使っているネットワークにはアクセスが可能だとか。世界145カ国トップ50のテレコムセンターのうち45にアクセスできるそうです。

Former Pentagon analyst: China has backdoors to 80% of telecoms | ZDNet

どこまで本当かわかりませんが、ありそうな話ですね。

マルチプラットフォーム対応のバックドア

Thu, 12 Jul 2012 00:00:00 +0900

F-Secureの研究者がコロンビア交通のWebサイトで、Windows、MacOS、Linuxなどマルチプラットフォームで動作するバックドアを発見しました。
バックドアは署名されたJavaのJARファイルを使って、ユーザーの端末がどのOSかを判定して、プラットフォームに適した追加ファイルをダウンロードしてくるとのことです。

なお、すでにF-SecureではC&Cサーバーなどについては当局に届出済みだそうです。
当局ってどこだろう？

Multi-platform Backdoor Lurks in Colombian Transport Site - F-Secure Weblog : News from the Lab

プロトコル内での"X-"接頭辞の廃止 - RFC6648

Tue, 26 Jun 2012 00:00:00 +0900

RFC6648として、アプリケーションプロトコル内での"X-"接頭辞と同様の構造の廃止というのが上がっていました。
HTTPなど多くのプロトコルでは、非標準パラメーターに”X-”接頭辞を付けることで、標準パラメーターと区別していましたが、メリットがないというより問題が多いので、既存のはさておき新たなプロトコルを作るときには、それは止めましょうとのこと。

RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

PayPal がバグ報奨金プログラムを開始

Fri, 22 Jun 2012 00:00:00 +0900

PayPal もバグ報奨金プログラムを開始しました。GoogleやFirefoxなどがやっているあれです。
対象となる脆弱性は、XSS、CSRF、SQLインジェクション、認証のバイパスとのこと。報告したらいくらぐらいもらえるんでしょうね？

For Security Researchers - PayPal

ゼロデイ脆弱性の価格表、秘密の攻撃コードはいくらか？

Sun, 17 Jun 2012 00:00:00 +0900

フランスのexploit販売会社のVupenによると、ターゲットの制御を得ることができるようなゼロデイ攻撃の価格は下記のようになっているとのこと。

Adobe Reader	$5,000-$30,000
Mac OSX	$20,000-$50,000
Android	$30,000-$60,000
Flash,Java Plugin	$40,000-$100,000
MS Word	$50,000-$100,000
Windows	$60,000-$120,000
Firefox, Safari	$60,000-$150,000
Chrome, IE	$80,000-$200,000
iOS	$100,000-$250,000

iOSが一番高いんですね。それだけ脆弱性が少ないのか、需要がないのか。

Shopping For Zero-Days: A Price List For Hackers' Secret Software Exploits - Forbes

はらロールのロールケーキ

Fri, 15 Jun 2012 00:00:00 +0900

はらロールは神戸のお店。豆乳を使ったクリームとスポンジ生地がとても美味しいです。ルレ・レーブを思い出す美味しさ！リピートしたい。

左から、オリジナルのはらロール、きなこ、フルーツ、抹茶。抹茶美味しい。
東京駅地下グランスタの特設会場に出ていました。