|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||||
See:
Description
| Class Summary | |
| BufferedHttpRequestWrapper | BufferedHttpRequestWrapper is an implementation of a HttpServletRequestWrapper that returns a buffered InputStream from getInputStream() and adds a method getBufferedInputStream() that returns the same InputStream. |
| BufferedServletInputStream | BufferedServletInputStream is an implementation of ServletInputStream that is backed by a BufferedInputStream to provide buffering support. |
| Gatekeeper | Gatekeeper enforces service invocation rules based on the FlashGatekeeper configuration. |
| GatekeeperFilter | GatekeeperFilter is a standard Servlet 2.3 Filter that is designed to inspect the AMF messsage sent by a Flash MX client when trying to invoke a service in the servlet container through Macromedia Flash Remoting MX for J2EE. |
FlashGatekeeper is an implementation of a Servlet 2.3 Filter that provides an important Flash Remoting security solution by limiting the services that can be invoked by Flash clients through Macromedia Flash Remoting MX for J2EE and for ColdFusion J2EE Edition on any Java application server.
FlashGatekeeper is supported by Carbon Five and can be deployed on application servers with Flash Remoting MX including Macromedia JRun, Jakarta Tomcat, JBoss, Caucho Resin, IBM WebSphere, BEA Weblogic and ATG Dynamo.
FlashGatekeeper gives developers the ability to limit the services that can be invoked through Flash Remoting. It provides the ability to restrict service access by Java package and class name, JNDI context or EJB name, to define exactly which service methods may be called and to restrict service method access by user role as determined by standard container managed security.
GatekeeperFilter is a standard Servlet 2.3 Filter that is designed to inspect the AMF messsage sent by a Flash MX client when trying to invoke a service in the servlet container through Macromedia Flash Remoting MX for J2EE. GatekeeperFilter uses classes included in the Flash Remoting flashgateway.jar distribution to parse and inspect AMF messages sent by the Flash client.
GatekeeperFilter only allows AMF messages that are trying to invoke a configured list of services to get to the Flash Remoting gateway. If it encounters an AMF request that it not allowed, it logs a warning with the full details of the service request and returns a 403 Forbidden status to the client.
Macromedia Flash Remoting is implemented as a servlet that uses introspection to invoke methods on a class in the application server. The class and method are both named by the Flash client. A Flash MX client can invoke any method through the Flash Remoting gateway on any class that has a no argument constructor and can therefore be created by the Flash Remoting gateway servlet using Class.forName("package.ClassName").newInstance( ). It can also invoke any method on any EJB home interface that it can find in JNDI.
This opens up many potential security issues. A malicious user could write a Flash client to access known core Java classes, classes in the application server APIs, or classes in your application. The potential exploits are numerous. A Flash client could access application server classes to manipulate the state of the server or gain access to protected information.
Using the core Java APIs a Flash client can connect to java.util.ArrayList as a Remoting service through Flash Remoting and invoke ArrayList.addAll(new Array("some string")) in an infinite loop. This is basically a denial of service attack that will fill up the memory available to the application server. Before long, it will crash the JVM (Java Virtual Machine) running the application server.
Macromedia's recommended approach for dealing with this security issue is to enable the Java Security Manager for your application server and edit the Java security policy file to limit the classes the Remoting gateway servlet can access. Unfortunately, the Java Security Manager will slow down your application server, security policy files are a pain to edit and manage, and you can't even prevent the ArrayList exploit above because the Remoting gateway needs access to ArrayList to function. The Security Manager can not distinguish between the gateway using a class as a Remoting service or as part of its written code.
Don't use the Security Manager solution. Use FlashGatekeeper.
If you are not using Flash Remoting, you do not have a need for FlashGatekeeper. Get Flash Remoting for J2EE from Macromedia.
FlashGatekeeper uses classes that are part of the Flash Remoting distribution and included in Flash Remoting's flashgateway.jar. Be sure to install Flash Remoting for your application by:
<servlet>
<servlet-name>FlashGatewayServlet</servlet-name>
<servlet-class>flashgateway.controller.GatewayServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>FlashGatewayServlet</servlet-name>
<url-pattern>/gateway</url-pattern>
</servlet-mapping>
FlashGatekeeper also utilizes specific components from other open source projects. These libraries are provided in the distribution, and can be freely used by commercial and non-commercial applications. More information can be found here:
FlashGatekeeper uses Jakarta Commons Digester to parse its configuration. Digester requires an XML parser conforming to JAXP , version 1.1 or later (the first one to support SAX 2.0). You're application server probably already has one so you probably don't need to worry about getting one. If you turn out to need one, Xerces will do the job.
Configure FlashGatekeeper in your application's WEB-INF/web.xml file as a servlet filter mapped to the URL of the Flash Remoting gateway servlet. For example:
<filter>
<filter-name>GatekeeperFilter</filter-name>
<filter-class>com.carbonfive.flashgateway.security.GatekeeperFilter</filter-class>
<init-param>
<param-name>config-file</param-name>
<param-value>flashgatekeeper.xml</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GatekeeperFilter</filter-name>
<url-pattern>/gateway</url-pattern>
</filter-mapping>
FlashGatekeeper looks for its configuration file in the classpath of your web application. In this example, you would put flashgatekeeper.xml in WEB-INF/classes or in another directory in your web applications classpath.
FlashGateway configuration allows you to define service access with a number of options.
A simple flashgatekeeper.xml configuration file that allows access to all services and service methods to all users restricted to the com.carbonfive.services package follows:
<config>
<service>
<name>com.carbonfive.services</name>
<method>
<name>*</name>
</method>
</service>
</config>
A following flashgatekeeper.xml configuration file shows the range of configuration options.
<config>
<service>
<name>com.carbonfive.AllowAllService</name>
<method>
<name>*</name>
</method>
</service>
<service>
<name>com.carbonfive.RestrictedService</name>
<method>
<name>allowAllMethod</name>
</method>
<method>
<name>restrictedMethod</name>
<access-constraint>
<role-name>ADMIN</role-name>
<role-name>MANAGER</role-name>
</access-constraint>
</method>
</service>
<service>
<name>com.carbonfive.services</name>
<method>
<name>*</name>
<access-constraint>
<role-name>USER</role-name>
</access-constraint>
</method>
</service>
<service>
<name>webapp</name>
<method>
<name>*</name>
</method>
</service>
<service>
<name>java:comp/env/ejb</name>
<method>
<name>*</name>
</method>
</service>
</config>
This sample configuration defines five service configurations.
|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||||