Best Practices for Securing Public Facing Applications

When deploying public facing applications, several steps can be taken to further protect your applications from nefarious activity. While m-Power supports multiple levels of enhanced security, these features are not enabled by default as doing so would hinder development efforts. When deciding which of these steps to take, please keep in mind how sensitive your data is and what is its overall level of access. For example, internal applications may not need the same level of security as customer facing applications because they are only accessed by internal employees, from behind your firewall. Below are numerous techniques that could be implemented to further protect your data:

1. Enabling SSL

   What it protects against
   SSL gives you an encrypted connection between your server and your user while verifying your server's identity. This prevents attackers from impersonating your server and requesting information, or intercepting any data transmitted between the user and server.
   Implementation
   The specifics of each step can vary between SSL provider but all fall into these broad steps:

   1. Create a key store file
   2. Generate a Certificate Signing Request (CSR)
   3. Send CSR to SSL provider and receive certificates in return
   4. Add Certificates to key store
   5. Modify your connector in Tomcat's 'server.xml' file to point to your key store and password. More information on the specifics of this step can be found in Apache's Documentation.

2. Changing Tomcat Default Password

   What it protects against
   m-Power installations use 'mrcuser' as the username and password for the Tomcat, by default. If an attacker knew this, they could simply go to your server's address followed by '/probe/' and enter the default user/password. This would give them access to logs and the ability to stop your Tomcat Service among other things.
   Implementation
   To change the username and password for this utility, you will need to edit the "tomcat-users.xml" file (tomcat/conf/tomcat-users.xml). Find the '<user>' tag containing 'mrcuser' for both the username and password. Change the username and password to values of your choosing. Lastly, delete any other '<user>' tags so that the user you just renamed is the only one.

   Note: Since the development environment will use those credentials to reload Tomcat when compiling an application, additional steps are required to change the Development Tomcat username and password. Please see this page for further instructions.

3. Disabling Debug Statements

   What it protects against
   Without this security feature enabled, attackers could append "debug=1" to the end of the applications URL and learn many details of your application, such as the executed SQL statement being and parameter information. While this information alone will not lead to unauthorized access, it provides information (Database type, schema/table/field names) that could help execute additional attacks.
   Implementation
   In your production environment, open the servlet configuration file (m-power/mrcjava/WEB-INF/classes/DICTIONARY_NAME/mrc_servlet_config.xml).
   Change the line: <disable_debug pdesc="disable_debug" value="0">
   To this:<disable_debug pdesc="disable_debug" value="1">

4. Suppressing SQL Error Messages

   What it protects against
   Error messages are another way attackers can find information about your database and how its structured. This information can lead to further, more specific attacks.
   Implementation
   In your production environment, open the servlet configuration file (m-power/mrcjava/WEB-INF/classes/DICTIONARY_NAME/mrc_servlet_config.xml).
   Change the line: <suppress_sql_msg pdesc="suppress_sql_msg" value="0">
   To this:<suppress_sql_msg pdesc="suppress_sql_msg" value="1">

   Additionally, you can enter a generic SQL error message to appear in its place. To do this, enter your message as the value attribute on this line:
   <msg_for_sql_error pdesc="msg_for_sql_error" value="Error - Please contact your System Administrator.">

5. Securing Redirects

   What it protects against
   Utilizing Cross-Site Scripting (XSS) techniques, attackers could redirect users to a page that looks similar to your application and ask for valuable information. By setting the Secure Redirects property, m-Power will allow you to restrict redirects to authorized applications within specified data dictionaries.
   Implementation
   In your production environment, open the servlet configuration file (m-power/mrcjava/WEB-INF/classes/DICTIONARY_NAME/mrc_servlet_config.xml).
   In the value attribute of the line below, enter a list of comma separated dictionary names, that contain applications you will need to redirect to.
   <secure_redirects pdesc="secure_redirects" value="DICTIONARY1,DICTIONARY2">
   This will restrict all redirects to applications in the dictionaries you have listed.

6. Enabling CSRF Tokens

   What it protects against
   Cross-Site Request Forgery (CSRF) is a method of submitting POST requests to applications that the user is already authenticated against, without the users knowledge. One way to prevent this is to pass unique tokens with each Maintainer's request to ensure the user is the one willingly making the requests.
   Implementation
   In your maintenance application, open the Application properties. Find the enable_csrf_prevention property under the Program Options tab and set it to 'Yes'. Click Accept to save the changes. This property could also be set as the default for all maintainers in your dictionary. This page details setting the default case conversion property for a dictionary, but could also be done with the CSRF property.

7. Whitelist/Blacklist Characters

   What it protects against
   To further prevent from SQL injections and Cross-site scripting (XSS) attacks, you can control what exact characters and phrases are allowed to be entered for certain input fields. For example, if you know your user will never need to search for the character '}' or the phrase '<script>' for any of your fields, you can blacklist that character or phrase. If a user enters a blacklisted character or phrase as a search/filter value, it will simply be removed from the search string. In addition, you can make an exception, or whitelist, any characters/phrases for inputs that point to certain database fields, if necessary.
   Implementation
   To implement, create a file called mrc-field-security.properties and save it in m-Power/mrcjava/WEB-INF. Insert the following code into the file, replacing FIELD1, FIELD2, and FIELD3 with any fields from your dictionary you would like to make exceptions for.
   
## Blacklisted Phrases are comma separated
BLACKLIST_PHRASES=//,,onError,confirm(,%0A,%0D
## Blacklisted Characters are NOT comma separated
BLACKLIST_CHARACTERS=!"&#$%'()+/:;<=>?@[]^_`{|}~\
## Whitelisted Field Level exceptions below are NOT comma separated
FIELD1=&%
FIELD2=&'%
FIELD3=&'
sort_col=_
cur_sort_col=_
add_redir=?&#=${}_
upd_redir=?&#=${}_
dlt_redir=?&#=${}_
all_redir=?&#=${}_
redirect=?&#=${}_


In conclusion, adding the above features will maximize security of your applications that are exposed to the public internet. While cyber criminals continue to evolve their techniques, mrc will continue to implement features that will thwart their efforts.