Web Security: What Security vulnerability is in Apache Server side include?

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”.

Security Remediation

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.

Advertisements


Categories: web application security, web security, webapps security

Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.