Attack Surface 攻撃サーフィス

Before we get into the specifics of attacking a J2EE server lets quickly touch on the topic of attack surfaces. What is an attack surface? It's basically all of the points or areas that an attacker can access a system or application. It is very important for both attackers and defenders to know their applications attack surface. You can not protect what you don't know exists. As a defender, you want to have the smallest possible attack surface. As an attacker, you want to identify areas the defender may have missed, or did not consider as being a potential attack vector. Lets use a generic J2EE application server as our example.
Breaking down the possible attack surfaces:
1. HTTP Server Instances - Most application servers have multiple HTTP/HTTPS instances running.

• - Admin Instance, most come with a web management interface.
• - Example Content Instances, sometimes developers leave the example content http instances accessible.
• - User Created Instance(s), for hosting individual applications that the developers created.

2. ORB-IIOP listener - Most enterprise j2EE application servers have some sort of IIOP listener.　These are accessible via remote clients through RMI-IIOP.
3. JMX-RMI management ports - These are accessible remotely by clients (usually they come with the application server installation) over the Java Remote Method Protocol (JRMP).
4. JMS Service - Java Message Service, These are also accessible remotely by clients, the server software usually comes with a client that you can use to connect.
5. JDBC service - Some application servers come with their own database service, you'll commonly see Apache's Derby DB. (http://db.apache.org/derby/)

Depending on the application server, you may see more or less than this. These are just the ones I commonly see in large (enterprise level) J2EE application servers. So we just went from thinking our J2EE server only had HTTP services to attack, to identifying four additional places that may contain vulnerabilities.

J2EEのハッキング方法の話前に攻撃サーフィスを話します。攻撃サーフィスと言うのは何でしょうか。基本的に攻撃者がアプリケーションやシステムのアクセス（攻撃）できる所です。
攻撃者やディフェンダーとしても、攻撃サーフィスの知識は本当に大事です。攻撃サーフィスがわからないと守れません。ディフェンダーとしては攻撃サーフィスが小さいほどより良いです。
攻撃者としてはアプリケーション内のディフェンダーの気づかない所を見つけれなければなりません。以下の例は普通のJ2EEアプリケーションサーバーです。
1. HTTPサーバーインスタンス　－　殆どのアプリケーションサーバーは複数のHTTP・HTTPSのインスタンスを実行されます。

• 管理インスタンス　－　殆どのサーバーは管理者コンソールがあります。
• サンプルコンテンツのインスタンス　－　時々、開発者はサンプルコンテンツのサーバーを実行のままにする。
• 開発のインスタンス －　アプリケーションの配備インスタンス。

2. ORB-IIOP リスナー - 殆どの企業アプリケーションサーバーはIIOPリスナー実行されます。RMI-IIOPでリモートクライアントをアクセスできます。
3. JMX-RMI 管理ポート - JRMPでリモートクライアントをアクセスできます。通常のサーバーはクライアントと一緒にインストールをします。
4. JMSサービス - Javaメッセージサービス、また、リモートクライアントでアクセスできます。
5. JDBCサービス - いくつかのサーバーはDBと一緒にインストールするので、サーバーをアクセスできるクライアントもインストールをします。殆どのサーバーがApacheのDerbyをインストールします。（http://db.apache.org/derby/、http://ja.wikipedia.org/wiki/Apache_Derby）

アプリケーションサーバーによって多かれ少なかれこのサービスにアクセスできます。僕の経験では企業のJ2EEサーバーで以上のリストを結構見ます。J2EEサーバーの攻撃サーフィスはHTTP・HTTPSだけではなく、複数あります。