Installation installersecurity railoserver - getrailo/railo GitHub Wiki

Documentation Home

Table of Contents Locking Down Railo Server Disable Public Debugging Error Output Ensure All Administrators for All Contexts Have Passwords Assigned and Use Captcha Reduce Request Timeouts as Low as Possible Ensure Railo's “Script-Protect” feature is enabled Avoid Using System-Heavy Client Variables Set Session Timeouts to as Low as Possible Keep Datasource Permissions Simple Use a Separate DB User for Each DSN Consider Using a Web Application Firewall (like FuseGuard)

To disable detailed error messages in Railo, log in to the Railo server administrator and go to Settings → Error → and select “error-public.cfm” from the drop down options. This will only display an extremely generic and uninformative error message to the end-users.

In the Railo Server Administrator, go to Security → Password. From this screen you can set the passwords of all existing web contexts and enable captcha’s to prevent brute-forcing password breaking attempts on your Railo Server & Web Administrators

To change the Request Timeout value, log in to the Railo server administrator and go to Settings → Application → Request Timout. It is recommended you change it from 50 seconds to about 10 or so. Experiment with this to make sure the request timeouts do not effect needed functionality that may exist in your application.

Railo's built-in Script-Protect feature is designed to protect your site from cross-site scripting attacks. Script-Protect will automatically filter dangerous tags in incoming variable scopes like CGI, cookie, form, and URL scopes.

To ensure Railo's Script-Protect feature is enabled, log in to the Railo server administrator and go to Settings → Application → Script-Protect and ensure it's set to “all”.

Note: This setting does not provide comprehensive cross-site scripting prevention, additional steps must be taken in your custom source code to alleviate risk.

Instead, try to keep as many variables as possible session-based, so they expire and are removed when the session expires.

This helps free up RAM and prevents some forms of DoS attacks. You can configure session timeout values globally in the Railo Server Administrator → Settings → Scope screen.

Setting all the available scopes to a value as low as possible is a good idea.

If you can, only enable SELECT, INSERT, UPDATE, and DELETE permissions. This will almost nullify SQL injection attacks. What commands are accepted by Railo is configurable for each DSN, and is controlled when you create or edit a DSN.

Isolating your Database users will help mitigate attacks should a site be found vulnerable. For example should a SQL injection attack occur in one site, the attacker will only have gained the powers of the single Database user account and would only have access to the sites and data for that site - not any other sites that may be present on the system.

Web Application Firewalls are excellent at detecting and deterring attacks on a system. High quality Web Application Firewalls also have the ability to log attacks to let you know what kind of attacks are being directed at your servers, so you can better prepare your defenses. Web Application Firewalls are well worth their initial investment.

Additional information on FuseGuard can be found at this URL: http://foundeo.com/security/

Documentation Home