Let’s consider a scenario of a web application which has common copyright & footer links and developer wants this footer to be displayed in every page. One solution is to add copyright & footer links in every page manually or use server side include.
What is Server side include?
Server side include is a web server feature that allows developers to dynamically generate web content by using “#” directives without having to do it manually. The server searches for the SSI directives in the HTML code and executes them sequentially. These directives may include shell commands or files or CGI variables that have to be replaced with their value. After executing all the directives, the HTML is finally served at the requestor. This saves a lot of time, makes the code more readable and easy to maintain. The following are some sample directives:
<! — #include virtual=“/footer.html” →
Server Side Include(SSI) Security vulnerability
Server-Side Include (SSI) injection vulnerabilities arise when an application incorporates user-controllable data into response that is then parsed for Server-Side Include directives. If the data is not strictly validated, an attacker can modify or inject directives to carry out malicious actions.
SSI is a form of attack that can be used by attackers to compromise web applications having SSI directives. Such applications often accept user input and render the same in their pages. This functionality is taken advantage by the attacker who can inject a malicious SSI directive as input. As a result, the hacker can add, alter or delete files on the server, execute shell commands and even gain access to sensitive files like “/etc/passwd”.
If possible, applications should avoid incorporating user-controllable data into pages that are processed for SSI directives. In almost every situation, there are safer alternative methods of implementing the required functionality. If this is not considered feasible, then the data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable SSI metacharacter, should be rejected.
In this post, I would like to share some of the most important points which I have learned in tomcat security. This isn’t the only list of security points which we should care. My objective is to share what I got to know.
In most of the cases, the default security configuration of tomcat may be adequate, but not when you have eCommerce running on the server & small security implication will have a big impact on your business. Let’s see some of the TO-DO lists to secure tomcat application.
NOTE: Tomcat is not the only defence against cybersecurity threats. There are many other systems, networks, the database needs to be secured.
Non-tomcat security checks:
- Do not run tomcat server on root user. Create another dedicated user & provide minimum adequate permission to the new user. And, Make sure user should not be able to remotely log on in tomcat server.
- Have restricted directories. Keep The principle of least privilege in place. Every user should not have access to logs file, process configurations etc.
- Make sure firewall is configured for the incoming & outgoing connections requests which you expect else deny any other connection request. For instance, proxy servers in load balancing.
- Keep health check page & internal network tracking of Tomcat applications.
Tomcat server security checks:
- All default tomcat web apps should be removed. If your web apps named as root then rename it. Root app isn’t safe to use.
- Enable HTTPS connections even for internal networks which are connecting to the tomcat server un-securely.
- Disabled tomcat console & default credentials. Some users like to deploy tomcat through the console.
- Automatic deployment is easy for deployment, however, it is easy for hackers as well to install a malicious application. Host element has autoDeploy and deployOnStartup. Keep these attributes false.
- Follow tomcat Securing Management Applications guidelines.
- Ensure that any users permitted to access the management application have strong passwords.
- Do not remove the use of the LockOutRealm which prevents brute force attacks against user passwords.
- Uncomment the RemoteAddrValve in which limits access to localhost. If remote access is required, limit it to specific IP addresses using this valve.
- Disabled the shutdown by setting up port as “-1” or have a strong password in the shutdown process.
- By default, an HTTP and an AJP connector are configured. Connectors that will not be used should be removed from server.xml.
Web application specific security checks:
- Restrict POST request & size of the request. An only expected POST request should be allowed.
- Keep custom error handler & make sure application do not throw big application error & java code in response. It helps hackers to understand the application.
- Keep validation of every user inputs.
- Get security testing done before deploying an application in prod.