Security
This chapter provides information about security.
Securing Session IDs
Enabling Session Cookies
Session cookies are the preferred way to track session IDs.
For an application running on Tomcat, session cookies are enabled by assigning the value true to attribute cookies in the application’s context descriptor file:
<Context … cookies="true" …/>
Session cookies are by default enabled for the standard Web Center applications.
Disabling URL Rewriting
Tracking session IDs via URL rewriting is considered a security risk and should be turned off.
For Web Center applications, you can turn off URL rewriting by filtering all relevant requests through the RequestFilter, a servlet filter delivered with Web Center.
The filter is defined in the deployment descriptor web.xml and mapped to all request URIs ending with *.do or *.jsp and to the URI /saveFile.
The filter is usually configured to disable URL rewriting, since the default value for its initialization parameter URLRewritingEnabled is false.
Since this doesn’t cover all possible cases of URL rewriting, also set the session tracking mode to COOKIE in section session-config:
<session-config> ... <tracking-mode>COOKIE</tracking-mode> </session-config>
Setting the HttpOnly Flag
The HttpOnly flag prevents client-side scripts from accessing the session cookie, thereby mitigating the risk of cross-site scripting attacks.
For an application running on Tomcat, the flag is enabled by assigning the value true to attribute useHttpOnly in the application’s context descriptor file:
<Context … useHttpOnly="true" …/>
The flag is by default enabled for the standard Web Center applications.
Preventing Session Fixation
To prevent session fixation attacks, Web Center changes the ID of a user’s session after a successful login via single sign-on, via entering user name and password, or via answering challenge/response questions.
A session ID change is triggered by assigning the value true to the request-scoped variable changeSessionID in a logic JSP:
<c:set var="changeSessionId" scope="request" value="true"/>
The session ID is changed after execution of the logic JSP.
You can enable or disable the feature via a parameter in webCenter.properties:
loginChangeSessionId = true
Preventing CSRF Attacks
To prevent cross-site request forgery (CSRF) attacks, Web Center should be configured to require a token to be sent as parameter of each incoming request.The tokens are generated either per request or per session and then stored in the session.If the token of an incoming request matches, the request is accepted.If the token doesn’t match or the incoming request does not provide a token at all, the request is (usually) rejected.The tokens are always transferred as HTTP post parameters so that they are not visible in URLs.You can configure the token’s HTTP parameter name, its length and its scope (either request or session).We strongly recommend generating a new token with each request.
This plain approach, however, causes some problems, especially when each request generates a new token.
First, a Struts action often forwards request processing to another one via HTTP redirect.This causes the browser to submit a GET request for the new URL.Since a GET request can only include URL parameters and a CSRF token mustn’t be disclosed in a URL, this means that the GET request cannot present any CSRF token at all.Therefore, Web Center stores the redirect URL before sending the response to the original request.The subsequent GET request is then accepted only if its URL matches the stored one.In fact, Web Center stores a list of expected redirect URLs per session to support simultaneous requests which may all get redirected.You can configure the maximum number of entries in the list.When the list size is exceeded the least recently used redirect URL is removed.
Some requests load an HTML page, and then use asynchronous requests to load additional content into certain areas of the page.An example is the Web Center home page which asynchronously loads the content of the plug-ins.Since the requests are sent simultaneously, they all include the same CSRF token, namely the one set by the request loading the HTML page.The first asynchronous request is accepted and changes the token.The other ones will then fail due to a token mismatch.To handle this case as expected Web Center must keep the original token valid for some time.Therefore, Web Center invalidates all tokens that were generated before the token presented by a request.The presented token itself remains valid, and also all tokens generated afterwards, including the new token created when processing the request.
Another problem is caused by page refreshes in the browser.The browser then sends the original request, including the original token.When the tokens vary with each request, the original token is invalid, and the request would usually be rejected.To handle page refreshes as expected by the end user, however, Web Center stores the URLs and the request parameters of the last two requests that loaded an entire HTML page (Requests loading just a part of a page are ignored by browser refreshes.) If an incoming request matches one of the stored requests, it is accepted.
Finally, you can also define a list of application entry points to be exempted from the token match. This allows for bookmarking Web Center pages, and for links from outside into a Web Center application. The list should include only paths that do not compromise security.
The filter is defined in the deployment descriptor web.xml and mapped to all request URIs ending with *.do or *.jsp and to the URI /saveFile.
The filter is configured in file WEB-INF/config/webCenter.properties:
csrf.enabled = true
csrf.allowPostForEntryPoints = false
csrf.tokenName = WT
csrf.tokenLength = 20
csrf.tokenScope = request
csrf.maxRedirectURLs = 5
csrf.entryPoints = /login.do,/index.jsp,/error.do,
/logout.do
To filter is enabled by default.
Notes
-
Before you enable the feature it in a productive system test it carefully for possible side-effects.
-
Newer versions of Tomcat are shipped with a CSRF prevention filter that uses only one-time tokens.The filter doesn’t work with Web Center applications.
Preventing Clickjacking Attacks
Web Center provides a servlet filter to prevent clickjacking attacks.
Clickjacking attacks may occur if an application runs in a frame or an iframe.The recommended way to prevent such attacks is to restrict framing to the same domain the application was loaded from, or to a trusted domain.The HTTP headers X-Frame-Options and Content-Security-Policy can be used to achieve this.Unfortunately, browser support for these headers is inconsistent.
The filter is defined in the deployment descriptor web.xml with name ClickjackingFilter and by default mapped to all request URIs.
Allow Framing from Application Domain Only
The filter adds the HTTP header X-Frame-Options with value SAMEORIGIN to the HTTP response.This instructs browsers to not allow framing Web Center pages from other domains.
<filter> <filter-name>ClickJackingFilter</filter-name> ... <init-param> <param-name>X-Frame-Options</param-name> <param-value>*:X-Frame-Options:SAMEORIGIN</param-value> </init-param> </filter>
The SAMEORIGIN option is supported by Internet Explorer, Firefox and Chrome.
Allowing Framing from a Trusted Domain
In this case, the filter adds two HTTP headers to the response.
The X-Frame-Options header allows framing from a single URI. It doesn’t support wildcards. The header is evaluated by Internet Explorer and Firefox but ignored by Chrome.
The X-Content-Security-Policy: frame-ancestors header allows framing from one or more URIs. It supports wildcards. The header is evaluated by Firefox and Chrome but ignored by Internet Explorer.
<filter>
<filter-name>ClickJackingFilter</filter-name>
...
<init-param>
<param-name>X-Frame-Options</param-name>
<param-value>*:X-Frame-Options:
ALLOW-FROM http://my-host.my-company.com:8080
</param-value>
</init-param>
<init-param>
<param-name>X-Content-Security-Policy</param-name>
<param-value>*:X-Content-Security-Policy:
frame-ancestors *.my-company.com:*
</param-value>
</init-param>
</filter>
Disabling Potentially Risky HTTP Methods
Some HTTP methods can potentially pose a security risk for web applications.Web Center provides a servlet filter that blocks requests with risky methods.
The filter checks the HTTP method of each incoming request.GET and POST requests are always allowed.HEAD, OPTIONS and TRACE requests are optionally allowed.All other ones like PUT and DELETE requests are always rejected.The filter also processes OPTIONS and TRACE requests directly instead of forwarding them further down the processing chain.
The filter is defined in the deployment descriptor web.xml with name MethodFilter and by default mapped to all request URIs.
The filter is by default configured to reject all requests other than GET and POST requests.To also allow HEAD and OPTIONS requests, for example, add them to the list of allowed methods:
<filter> <filter-name>MethodFilter</filter-name> ... <init-param> <param-name>AllowedMethods</param-name> <param-value>HEAD,OPTIONS</param-value> </init-param> </filter>
Configuring Cross-Origin Requests
Traditionally browsers follow a same-origin policy: a web page can send HTTP requests via Javascript only to the server the page was loaded from.HTTP protocol (http/https), server name and port must coincide.
Since this policy was considered too restrictive for some modern types of web applications, the policy was weakened in newer browsers.Now, a browser may send a request to a different server than the origin.The original server is indicated to the request target in a new request header with name “Origin”.The target server can decide whether to accept or reject the request.Some browsers like Chrome also send “Origin” headers if origin and target server are identical.
By default, Web Center accepts requests with an “Origin” header only if origin and target server coincide.Otherwise, the request is rejected.
You can tell Web Center to accept requests from other origins as well.List the origins to accept in parameter AcceptedCrossOrigins of the RequestFilter in file web.xml.Separate the origins by commas.Each origin is evaluated as a case-insensitive regular expression (see Java API documentation of package “java.util.regex”).
The following configuration accepts cross-origin requests from server http://alpha.beta.com:8080. Note that the dots are escaped by backslashes in order to distinguish them from regular expression wildcards.
<filter>
<filter-name>RequestFilter</filter-name>
...
<init-param>
<param-name>AcceptedCrossOrigins</param-name>
<param-value>http://alpha\.beta\.com:8080</param-value>
</init-param>
</filter>
Input Validation
The flexibility of many components processing Web Center requests is based on JSP expressions.This, however, poses a security risk if end users are allowed to enter JSP expressions into input fields.Therefore, the input of each request should be checked for JSP expressions, and the request should be rejected if an expression is found.JSP expressions start with “${” and end with “}”; examples for input values with JSP expressions are “John ${alpha} Doe” and “${1+2}”.
Web Center’s input validation process performs this check for each incoming request.It parses each request parameter value for JSP expressions.When it detects a JSP expression, it rejects the request.If the request is part of a self-registration, it cancels the self-registration and redirects the user is to the login page.Otherwise, it redirects the user to a previously called page of its session.
You can disable input validation for specific request parameters that are allowed to contain JSP expressions; for example, passwords.The components that subsequently process the request must then make sure that the JSP expressions are not evaluated.
You can configure the request parameters excluded from input validation in the file webCenter.properties.You can also disable input validation completely, but this is not recommended.The default configuration is:
inputValidation.validateRequestParameters = true
inputValidation.excludedParameters =
password,oldPassword,retypedPassword,newPassword
Adding a parameter to the list of excluded parameters just disables input validation for this parameter.It does not imply that the components involved in processing the request do not evaluate JSP expressions within the parameter value.This must be explicitly ensured and tested in each case.
On detection of a JSP expression, Web Center forwards request processing to the Struts action assigned to the global action forward with name “invalidInput“.By default, this is the action with path “/invalidInput“.The action then either cancels a self-registration or goes back to the last action in the user’s session that is marked as a reset point.
Error Pages
In order not to disclose any security compromising information to end users and to disrupt user experience as little as possible, Web Center defines some HTML and JSP pages to be displayed in situations where request processing is denied for security reasons or fails due to unrecoverable errors.The pages are configured in the deployment descriptor web.xml, for example
<error-page>
<error-code>400</error-code>
<location>/redirectToError.do</location>
</error-page>
<error-page>
<error-code>403</error-code>
<location>/WEB-INF/jsp/view/error/forbidden.html</location>
</error-page>
Adapt the definitions and the files in folder /WEB-INF/jsp/view/error to your requirements.
Login Configuration
Login Cookie
Web Center uses a cookie with name login to make some user-specific settings available from one user session to subsequent sessions.The login cookie includes
-
The user’s Web Center language.
-
The user’s Web Center font size.
-
The value of the user name field of the login form.In case a customized login form contains more than one user identification field, the cookie stores the values of all of them.In case of single sign-on applications, of course, no value is stored at all.
Note that the cookie is not available to script code in the browser since Web Center sets the cookie’s httpOnly flag.
The cookie’s maximum lifetime is by default 30 days.
If you think that the cookie compromises the security in your environment in any way, you can configure Web Center
-
To send the cookie over secure connections only.
-
Not to include the login form input in the cookie.
-
To set a different maximum age for the cookie.
-
To disable the cookie at all.
The respective configuration parameters (with their default values) are:
loginCookie.enabled = true
loginCookie.includeAttributes = true
loginCookie.maxAge = 2592000
loginCookie.secure = false
For details, see the chapter “Web Center Configuration”.
Login Form
Disabling Form Authentication
When running a Web Center application with single sign-on, a user is authenticated by some single sign-on component. The component forwards some kind of user credentials to Web Center. Web Center then searches the DirX Identity database for a user matching the presented credentials. This may fail for several reasons: the credentials may match more than one user or a disabled user or no user at all. In case of failure, you can have Web Center either reject the request or display the login form to let the user manually login with name and password. For security reasons, the request should be rejected.
You can enable or disable form login in webCenter.properties:
ssoFallbackToLoginPage = false
The default value is “false”.
Disabling Autocompletion
Browsers may store values entered into form input fields and redisplay them next time the form is displayed or suggest them as input in a proposal list. This might compromise security since a user may get access to login name and password of a previous user.
Therefore, Web Center deactivates the browser’s autocompletion feature for any password field (in the login form as well as in the forms to change or reset a password). This is achieved by setting the attribute autocomplete to "off" in all password field renderer snippets, for example
<input type="password" … autocomplete="off" …
When customizing a form with a password field, make sure that autocompletion is deactivated for the password field.
Autocompletion can also be deactivated for the user name field in the login form. The field renderer secureText sets the autocompletion flag to the value of the configuration parameter loginForm.autoComplete. Use this renderer if you define a custom login form with different user name fields.
You can then switch on and off autocompletion for user name fields in webCenter.properties:
loginForm.autoComplete = off
The default value is “off”.
Disabling Logins with Incomplete User Names
Another configuration parameter in webCenter.properties lets you define the minimum number of characters a user must enter into the user name field of the login form (not counting white spaces). For example, if the minimum number is 3, a login attempt with user name “smi” will succeed if there is only one user whose name starts with “smi” (and of course if the password is correct).
This feature surely compromises security since attackers don’t need a complete user name to break into the application. It must therefore be deactivated in productive environments by assigning the value 0 (which is the default):
loginForm.minChars = 0
Preventing Non-SSO Requests
When operating Web Center with a single sign-on provider, you can block attempts to access Web Center without single sign-on information.
In file web.xml, set parameter ssoRequired of the SSOHeaderFilter to true:
<filter> <filter-name>SSOHeaderFilter</filter-name> ... <init-param> <param-name>ssoRequired</param-name> <param-value>true</param-value> </init-param> </filter>
On receipt of an unauthorized request, Web Center rejects the request. You can instead define an action to redirect the request to.
In file web.xml, set parameter ssoLoginAction of the SSOHeaderFilter to the Struts action to redirect to. Note that Web Center does not forward any request parameters to the redirect action.
<filter> <filter-name>SSOHeaderFilter</filter-name> ... <init-param> <param-name>ssoLoginAction</param-name> <param-value>/login.do</param-value> </init-param> </filter>
Restricting Access to the Password File
A Web Center application needs one or more passwords for example to access the LDAP server or a Java keystore.The passwords are stored in encrypted format in file WEB-INF/password.properties.To change a password, just overwrite its encrypted value with the new clear text value.Then restart Tomcat.During restart, the new password will be encrypted.
Set the password file permissions so that
-
The Tomcat server can read and write the file.
-
Authorized users can read and write the file in order to change a password.
-
No one else can read or write the file.
Self-Registrations and User ANYONE
To perform user self-registrations, Web Center binds to the directory server for provisioning as user ANYONE (cn=ANYONE,cn=<domain>).User ANYONE is created during initial domain configuration with a default password.Whenever you configure a Web Center application for that domain, the DirX Identity Configurator adds the default password to the application’s password file password.properties.
The first thing you should do is to change the default password in the directory to a secure value.
Then, if your application uses self-registration:
-
Change the password with id “ANYONE” in file password.properties accordingly.
If your application does not use self-registration:
-
Make sure that file password.properties does not contain the correct password.Change the password to any dummy value you like or remove it at all.Now, any self-registration attempt will fail.
-
Make sure the self-registration section is not shown on the login page by setting property “loginForm.showRegister” in file webCenter.properties to false (this is the default value):
loginForm.showRegister = false
-
Make sure the self-registration actions “/startRegistration” and “/finishRegistration” in file WEB-INF/config/workflows/struts-config.xml are deactivated (which they are by default).Otherwise a user could start a self-registration directly from his browser’s address bar.
Securing Connections
Interprocess communication over an untrusted network should generally be secured via SSL.For a Web Center application, this includes:
-
HTTPS between browser and Tomcat.
-
LDAP over SSL between Tomcat and the LDAP server.
-
SOAP over HTTPS between Tomcat and request workflow service of the Java-based Server.
-
JMS over SSL between Tomcat and the message server.
Requiring HTTPS
Web Center can be configured to require HTTPS. Unsecure requests are either redirected to a predefined URL or rejected.
The feature is implemented by the RequestFilter, a servlet filter delivered with Web Center. It is defined in the deployment descriptor web.xml and mapped to all request URIs ending with *.do or *.jsp and to the URI /saveFile.
The filter is by default configured to process any requests whether secure or not. To have insecure requests simply rejected, set its parameter SSLRequired to true:
<filter> <filter-name>RequestFilter</filter-name> ... <init-param> <param-name>SSLRequired</param-name> <param-value>true</param-value> </init-param> </filter>
To have insecure requests redirected to another page, additionally assign the redirect URL to parameter SSLRedirectURL:
<filter> <filter-name>RequestFilter</filter-name> ... <init-param> <param-name>SSLRequired</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>SSLRedirectURL</param-name> <param-value> https://localhost:8443/webCenter-My-Company/login.do </param-value> </init-param> </filter>
| In case of a redirection the URL and any parameters of the original request get lost and are not available when processing the redirected request. |
Disabling Development Tools
Web Center provides some tools to help in developing customized applications.In order not to disclose any security compromising information to end users you should deactivate these tools in productive systems.
Development Mode
Turn off Web Center’s development mode feature.
In configuration file WEB-INF/config/webCenter.properties, set
developmentMode = false.
Online Debug
Turn off Web Center’s online debug output feature.
In configuration file WEB-INF/web.xml, set
<context-param>
<param-name>com.siemens.webMgr.debug.enabled</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>com.siemens.webMgr.debug.trace.enabled</param-name>
<param-value>false</param-value>
</context-param>
Output Escaping
When customizing an application, make sure that all data written to an HTTP response is properly escaped in order not to break the generated HTML page or Javascript code.Incorrect escaping also makes a page prone to script code injection attacks by hackers in particular when form input values or request parameters are inserted as part of the response page.
Document Root Folder
The document root folder of a web application contains the files that are required to run the application in the web application server.For the standard Web Center applications, the folder contains the file index.jsp and the sub folders resources and WEB-INF.Users can download any file below the document root provided they know its name, for example via URLs like
http://host:port/webCenter-domain/index.jsp
http://host:port/webCenter-domain/resources/images/new.gif
http://host:port/webCenter-domain/resources/build/config/config.js
The only exception is the WEB-INF folder.The application server guarantees that files in the WEB-INF folder are not directly accessible to clients.The server also ensures that clients cannot directly access files outside the document root.
Therefore, keep your document root folder clean.Put only those files into the folder (apart from sub folder WEB-INF) that must be directly accessible to clients like images, Javascript and VBScript source files, style sheets and static HTML files.Any other file might pose a security risk.
The document root for the standard Web Center applications is install_path/web/webCenter-domain/webCenter.The folder contains only the necessary files.