Portlet Factory, Version 6.1.2

 

Security best practices

Review these security-related tips, tricks, and best practices for WebSphere Portlet Factory WebApp model-based deployments.

For application server deployment recommendations concerning security in various deployment scenarios, refer to your server's documentation and its vendor's own recommendations.

  • On all deployment servers, make sure that the property bowstreet.server.type= is set to the value deployment rather than to the value development.

    Note: This property is located in the WEB-INF/config/bowstreet.properties file.

  • Do not put development and administration tools that are not absolutely necessary for that deployment on end-user application deployment servers. This practice is observed throughout the web application industry as a common sense measure to limit the number of components that an attacker has to work with. It is a good idea in any web application deployment (using any technology) to provide on deployment servers accessible to end-users only those resources necessary for the end-user application.

    Make sure that the servable content root/factory/designer folder and its contents (logout_redirect.jsp) are not included or installed on any deployment servers. These tools are for development use only.

  • Protect servers hosting admin tools with secure network firewalls that allow access only to those users that should be allowed to run the tools hosted on those servers.

  • Make security changes such as defining new roles and changing protections of both JSP and static pages and WebSphere Portlet Factory models on a staging or administrative system first. Test them there and then roll them out to the deployment servers (cluster) only after qualifying the changes against your security requirements.

  • Keep you application software up to date by installing all vendor-supplied patches and security enhancements.

  • Security Constraints are URL based and act like a locked front door. Once you are in, they do not apply to additional functionality that the resource protected by that security constraint protects. For instance, if you protect access to model A via security constraint URL and model A uses resources B, C, D and model F (as a multi-instance linked model), then the protection by security constraint is still just applied to model A and it is up to model A not to provide access to sensitive information behind the scenes that should be protected more securely than model A's security constraint was intended for.

  • If you add more ways (models) of getting at sensitive backend systems currently protected by existing security constraints, remember to add new security constraints (or make sure the existing ones also apply to these new WebApp models, based on a URL to a folder of models or similar). Think of it as adding more doors to get into a house, and make sure each door has a lock. It does no good to lock the front door if the side and back doors are then left wide open.

  • Similar to the above warning, J2EE Servlet security constraints DO NOT apply to JSP forward() or include() calls. For example, if you protect resource A by security constraint, but it then does a forward() or include() to resource (JSP) B or C, the security constraint is NOT rechecked for applicability to B or C. Do not provide access from within resource A to things that are more sensitive than A's security constraint applies to.

  • Since J2EE Servlet security constraints are based on URL, which includes the "webengine" servlet name used by WebSphere Portlet Factory, if you change the name/mapping of the webengine servlet for any reason, you MUST make sure that you perform any updates to the security constraints to ensure that they still apply to any servlet(s) allowed to execute WebApp models.

  • Use dynamic cookies (the default in most cases) rather than persistent cookies. Since dynamic cookies exist only in memory in the browser process, it is less likely that a session will be left around accessible if someone closes their browser and walks away from their desk assuming that they are logged out. It also improves integration with external security such as IBM® WebSphere Application Server's LTPA based SSO and other components that may themselves use dynamic cookies (so that they ALL go away at the same time when the browser is closed).

  • Provide LOGOUT buttons to kill the session, and any security related cookies if using external security, to make it less likely that someone will leave themselves logged in and vulnerable to a "walk-up" attack. (See the Logout section of this Security chapter). On Logout Screens, recommend that users close their browser, to remove any security related cookies and/or HTTP Basic Auth passwords cached in memory by the browser, after logging out.

  • If possible, have your application's logout window attempt to close the browser via JavaScript after logout (the browser will prompt the user asking if that is ok with them first), to help ensure any security related cookies are cleaned up and not left around if the user then walks away from their desk.

  • Host nothing more than is absolutely required for your web application(s) on your deployment server(s). No test models, development tools or other components unrelated to the actual web applications being hosted should be available (and thus provide additional hacker attack points) on the deployment servers.

  • Use SSL/HTTPS where necessary and possible to insure the privacy of sensitive data (passwords and any sensitive application data) being transmitted over the network between the browser and the server(s).

  • Combine models and JSPs with common functionality and sensitivity levels into common subfolders with recognizable and useful names. Then provide a small number of security constraints that can easily be managed for a large number of similarly protected models and/or JSP/HTML content.

  • Name your subfolders for models consistently with your subfolders for JSP/HTML content, so that you can provide consistent/manageable security constraints for both and more easily keep any changes that apply to both in synch.

  • Profile selection via J2EE role is possible with the J2EE Profile Selection handler described in the Profile Selection chapter of this document.

    Note: This might not be best choice for most scenarios. J2EE Roles tend to be more security related (for example, are you a portal user or not) and not typically granular preference oriented. You will achieve the value of profile based mass customization (many planes of variability) by using profile selection based on more granular user/group preference data than the small number of J2EE Security Roles typically used with any J2EE based web application.

  • Do not try to work with WebSphere Portlet Factory WebApp functionality requiring application server security (J2EE based roles for authorization or profile selection) without first ensuring that your server is properly configured for this use. This includes knowing that roles are properly mapped, security is turned on, and so on.

  • Test, test and then test some more to make sure your security constraints are doing what you expect them to do. Do both positive testing (can the right users/roles get in) and negative testing (are other users/roles and anonymous requests properly blocked from accessing resources you believe you have protected).

  • Testing Productivity Trick – When doing iterative development and testing of models that require a security constraint and application server security provided information, logging in over and over again can become cumbersome. Automate that process by switching from using FORM based security to HTTP BASIC auth (change FORM to BASIC in the login-config element of the WEB-INF/web.xml configuration file and restart your AppServer).

    Using BASIC auth, your browser will submit the same username/password on each request to that URL/realm. If you include a logout button in your app and continue to use the same browser (instead of WebSphere Portlet Factory Designer), you may be able to rerun the app without manually logging in.

    A variation on this tip, is to send the username/password in the URL (see below). For example: http://user:password@host:port/appContext/servlet/path/to/protected/Model

    This should force a basic auth login for you on the application server. (Support for this is up to the application server. This technique might not work on all application servers or all future versions of those servers.)

    Using this technique you can create multiple shortcuts or a page with multiple links, to test multiple users/roles with a single click.

  • If your web application really does not rely on security related user information (such as the username or isUserInRole functionality from the AppServer), then an easier approach is to not enable security until you have developed and tested the rest of the functionality that is not dependent on security or application server-provided user information.

Parent topic: Overview: security methodologies

Library | Support |