はじめに

CBCモードへの選択平文攻撃を扱った前々回のエントリ、そしてBEASTの全体像について解説した前回のエントリに続き、今回はTomcatなどのJava製のサーバアプリケーションにおいて、BEAST対策を実施する方法について見ていきます。なお、本エントリの対象はOracleのJava1.6系となります。他のJava実行環境やJSSE実装では事情が異なる可能性があります。

はじめに

CBCモードへの選択平文攻撃を扱った前回のエントリに引き続き、BEASTについて見ていきます。今回は、BEASTの全体像について解説します。なお、BEASTの実際の攻撃コードはパブリックにされていないため、この記事の内容はあくまでも推測に基づくものとなっていることをご了承ください。

はじめに

この秋にウェブアプリケーションセキュリティの分野で大きな注目を集めたBEAST(Browser Exploit Against SSL/TLS)の全貌が、ほぼ明らかになってきました。事前に話題になっていたほどの大きなインパクトを現状のインターネットに及ぼすものではなさそうですが、その中で使われている攻撃テクニックは今後、さらに応用されていく可能性を秘めています。HTTPSに対する攻撃という意味ではひとつの大きなターニングポイントであったと感じます。

私たちが開発しているSaaS型WAFサービス「Scutum(スキュータム)」はWAFであると同時にHTTPSサーバでもあるため、BEASTが及ぼす影響について非常に気になっており、このたび調査を行いました。本エントリから数回に分けて、BEASTについての情報を中心にお届けします。まず今回は、BEASTの攻撃技術のベースとなっている「CBCモードに対する選択平文攻撃(Chosen Plaintext Attack)」について、実際にJavaのコードを用いて検証してみます。

はじめに

SSLを使うウェブサイトでは、ウェブサーバへのサーバ証明書のインストール作業が必要となります。このときややこしいのが、中間CA証明書の扱いです。多くの場合、証明書会社が発行するサーバ証明書は、ユーザのウェブブラウザにインストールされているルート証明書から直接署名されているわけではありません。ルート証明書によって署名された中間CA証明書によって署名されています。そのため、ブラウザはサーバ証明書とルート証明書の信頼のチェーンを辿るために、中間CA証明書を必要とします。

中間CA証明書が見当たらない場合、サーバ証明書が正しいものであるにもかかわらず、ブラウザはエラーと判断してしまいます。そのため、サーバ証明書をインストールする場合には、それに対応する中間CA証明書も一緒にインストールするのが一般的な方法となります。

はじめに

先のエントリにて、EC2のデータ転送と課金の関係についてまとめました。EC2では、同一のAZ内に存在しているインスタンス間でのデータ転送は、プライベートIPを使ったものについては課金されません。

Scutum(スキュータム)はSaaS型のWAFなので、お客様のウェブサーバとScutumのWAFインスタンスの間にそれなりの量のトラフィックが発生します。そのため、この課金されないトラフィックをうまく使いたいと考えていますが、ここに落とし穴が潜んでいました。実は、EC2でのAZは、アカウント毎に指している実体が異なることがあるのです。

(クリックで拡大します)

はじめに

クラウドサービスの代名詞でもあるAWS(Amazon Web Services)が待望の東京リージョンを開設してしばらく経ちました。我々Scutum(スキュータム)はSaaS型のWAF(Web Application Firewall)サービスであるため、AWSのEC2のようなIaaS型のインフラ上に積極的に展開をおこなっています。本エントリではその際にポイントとなる、EC2でのデータ転送量への課金について調べてみました。

(クリックで拡大します)

このエントリの内容はオフィシャルのウェブページやインターネット上の情報を元にしたものであり、実情と異なっている可能性もあるのでご注意ください。また、価格は東京リージョンのものとなっています。

はじめに

SaaS型WAF「Scutum（スキュータム）」では、最近バックエンドのDBにMongoDBの導入を進めています。私も個人的にPHPのフレームワークであるCakePHP向けにMongoDBを扱うプラグインCakePHP-MongoDB Datasourceを開発し、公開しています。
https://github.com/ichikaway/cakephp-mongodb/

今回は、PHPからMongoDBを扱う際の注意点として、RequestInjection攻撃に関して書きたいと思います。この問題は、phpマニュアルのMongoドライバーの章でも扱われています。
この記事では、はじめにPHPでMongoを操作する方法、PHPの基本を書き、最後にInjection攻撃の仕組みと対応方法を書きます。

はじめに

PostgreSQLなどのRDBMSでは、コマンドラインのクライアントからSQL文を打ち込んでデータを操作することが一般的です。これに対し、MongoDBでは、コマンドラインのクライアント（mongoコマンド）からJavaScriptを使ってデータにアクセスすることができます。ただし、JavaScriptを使うといってもif文やfor文などを使うことはまれで、多くの場合は単純にJSON形式で記述したクエリーを関数の引数にして実行するだけになります。その際「find」「update」などの関数や「$gt」「$set」などのMongoDB独自のオペレータを用います。これは特定のプログラミング言語に特化した方法ではなく、少し抽象化された、MongoDB言語とでも呼べるものとなっています。

はじめに

WAF「Scutum（スキュータム）」ではサービス開始時より、データストアとしてmemcachedとpgpool II+PostgreSQLを利用しています。これらはどれも安定して動いており満足しているのですが、最近になってより柔軟にデータを取っていきたいというニーズが高くなってきたため、MongoDBの導入を行いました。まだ完全なリプレースまでは至っていませんが、元々のデータベースのスキーマ構造がシンプルであることもあり、数ヶ月以内にはpgpool II+PostgreSQLの部分をMongoDB（Replica Sets）で置き換えることができるのではないかと思っています。