Tag Archives: web security

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.

WebSecurity: Why SSL Cookie needs secure flag?


In Web application, We generally think of secure HTTP (i.e HTTPS) is good enough but the truth is application security is as important as network & protocols security. Let’s understand why SSL cookie needs secure flag in your application.

SSL Cookie problem without secure flag?

If the secure flag is set on a cookie, then browsers will not submit the cookie in any requests that use an unencrypted HTTP connection, thereby preventing the cookie from being trivially intercepted by an attacker monitoring network traffic. If the secure flag is not set, then the cookie will be transmitted in clear-text if the user visits any HTTP URLs within the cookie’s scope.

An attacker may be able to induce this event by feeding a user suitable links, either directly or via another web site. Even if the domain that issued the cookie does not host any content that is accessed over HTTP, an attacker may be able to use links of the form http://example.com:443/ to perform the same attack.

How hacker can exploit cookie secure problem?

To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim’s network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer.

Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user’s ISP or the application’s hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet’s core infrastructure.


The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.

WebSecurity: Cookie without HttpOnly Flag set

In any web application, Cookies play a very significant behavior of the application. Whether user experiences, personalization, analytics or session management, Cookies are part of every web module. The importance of cookies in a web application is so critical that privacy regulation put clause about cookies & web apps. And, Every web application must alert to the user.

Importance of HttpOnly Flag in Cookie

If the HttpOnly attribute is set on a cookie, then the cookie’s value cannot be read or set by client-side Javascript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie’s value via an injected script.

Should Every cookie have HttpOnly Flag set?

There is usually no good reason not to set HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie’s value.

So, Setting of HttpOnly flag is always conditional & you should evaluate when to set.

How to set HttpFlag in cookie?

#J2EE Servlet API
Cookie cookie = request.getCookie("myCookieName");

#Java Enterprise application WEB-INF/web.xml

#Tomcat 6 In context.xml
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/exampleApp" useHttpOnly="true">

WebSecurity: Possible Security issues in Robots.txt file

Purpose of Robots.txt File

The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site that robots are allowed, or not allowed, to crawl and index.

Security Important of Robots.txt File

The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to identify restricted or private areas of a site’s contents. The information in the file may therefore help an attacker to map out the site’s contents, especially if some of the locations identified are not linked from elsewhere in the site.

If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.

Possible Solution

The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons. You should not assume that all web robots will honor the file’s instructions. Rather, assume that attackers will pay close attention to any locations identified in the file. Do not rely on robots.txt to provide any kind of protection over unauthorized access.

Web Security: How to use third-party javascript securely

In Security of WebApps, we often think of securing our database, application server security & other frameworks security like Structs, Spring etc. Generally, Frameworks are the first point of target for the hackers because it provides straight entry into the target application. But, the situation has been changed a little bit. These frameworks are getting more secure day by day. And hackers are targeting low hanging fruits.

The more vulnerable piece of software in any web application could be your fancy third-party javascript. Javascript is actually bad for security but very powerful language. And, one of the core issue & feature with Javascript is that it is flexible & does not require whole programming stuff like Java or Python. It executes within the browser, easy minimum code & easily injectable in many ways: Through Forms, Review comments, Web service response etc.

Hackers do not need to hack your server & network to steal your information. One or two lines of javascript could be good enough.

Hacking through Javascript

Following problems may happen using third-party libraries:

  • Third-party javascript will have access to the application as your own javascript.
  • Malicious javascript code. Third-party libraries has been compromised.
  • Confidentiality, Integrity etc are other security risks.

Most of the applications use third parties, open source javascript libraries to implement some functionalities. And, hardly anybody knows who maintain, fix bugs in these open source libraries. Even if we buy javascript libraries, Hardly there is any security testing done on those frameworks. Hackers use third-party & integrated services to break the target application. The recent example is here.

The British Airways Hack: JavaScript Weakness Pin-pointed Through Time-lining

How to secure our application when you have used third-party javascript?

About Open Source Libraries: Open source libraries are great & provide so much fancy javascript stuff. However, the major concern is that we never know what changes have been updated & how those are affected to your application. Someone can add malicious code & will wait for you to get the latest changes loaded in your application.


General practice is that keep them in the source code & use them. Do not depend on patch & updates regularly from the owner of these libraries. It is one way to add security to our application. Let’s assume you want to upgrade these libraries to get some latest features or bug fixes then plan just like you plan for any software update. Do not just copy paste minified version.

Not every third-party javascript can be party of your source code. For those situation try solution-2.


Another way is to keep relying on libraries hosted by third-party. In the case of analytics, DTM scripts are generally loaded from third-parties. However, the point is that make sure security testing do the diligent work. Use some JavaScript specific security tools like Javascript security analyzers. These tools perform code analysis on client-side applications.

Final Thought

This seems very small step & do not get much attention. We all try to solve big problems first. But, In my opinion, these small issues solve the bigger problem & control much more damage than building a new rocket. For suggestion or inputs, leave your comments. Thanks.