Tag Archives: web application security

Web Security: Importance of Strict-Transport-Security in any website

Abstract

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.

Read more in

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

Advertisement

How to fix Web Performance issues?

This post will give your a list of actions and quick guide how to optimize your website and increase performance significantly. following guidelines are:

  • Reduce required requests: Less number of http requests means less overhead on the page.
  • Use css for your main images: CSS Sprites is wonderful solution for merging icons and lots of small images into one. This reduce number of http requests in every page of the website.
  • Use a faster web server: Apache is standard solution however, there are solution which provides better speed. Look for more details.
  • Implement caching: It’s common to implement caching however, you should look for caching at multiple layers. Web-server caching, CDN caching and end user browser caching. All of them gives extra mileage in performance.
  • Enable compression: Compression(GZIP) is common and must be implemented in every content transfer happens from client to server. Read about it in below articles.
  • Eliminate plugins: Use standard libraries and try to avoid building wheel for any new problem. Libraries help in providing optimized solutions. Just look for security before using it though.
  • Use a top tier host
  • Use a content delivery network: CDN is good at serving static content and improves overall performance of the application. you must implement it.
  • Employ anycast dns: Anycast is CDN of DNS. It means all DNS resolution happens very quickly and available any cast DNS server helps resolve DNS queries quickly.

Read more in following documents.

https://moz.com/learn/seo/page-speed

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency

https://danielmiessler.com/study/web-performance/

https://developers.google.com/web/fundamentals/performance/optimizing-javascript/tree-shaking

Good Read: MIME Sniffing in Browsers and the Security Implications

Whenever a website in opened in a browser, there are many tasks that are being silently performed in the background. One of those tasks is fetching resources such as images, stylesheets and JavaScript from different domains on the internet and then parsing those resources.

For example, a browser fetches an image from remote server and renders it for display when it encounters an <img> tag with src attribute in an HTML document. Browsers handle these resources based on their MIME type, and a browser’s behavior can be guided by the X-Content-Type-Options HTTP header returned by the web server.

In this post, we are going to look at security risks for an application that does not make use of this header. Specifically, we will look at the conditions under which exploitable vulnerabilities arise.

MIME Sniffing Introduction

MIME stands for “Multipurpose Internet Mail Extensions.” MIME was originally defined to support non-ASCII text and non-text binaries in email. However, the content types defined in MIME standard are used in HTTP protocol to define the type of content in a request or response. 

A browser usually identifies a resource’s MIME type by observing the Content-Type response header in an HTTP response. 

Figure 1:Content-Type response header for an HTML page from google.com

Sometimes, developers set values for Content-Type headers that are not appropriate for the response’s content. For example, if a server sends text/plain value for a JavaScript resource, it is a mismatch. As per web standards, text/plain is not a valid JavaScript MIME type. However, browsers may parse and render such misrepresented resources so that the website will operate as intended. This is where MIME sniffing comes into picture. An example has been given in Figure 2.  

Figure 2: A JavaScript resource served with incorrect Content-Type value

 “MIME sniffing” can be broadly defined as the practice adopted by browsers to determine the effective MIME type of a web resource by examining the content of the response instead of relying on the Content-Type header. MIME sniffing is performed only under specific conditions. Please note that MIME sniffing algorithms vary by browser. A MIME sniffing standard has been defined on the Web Hypertext Application Technology Working Group (WHATWG) website. 

Read more in

https://www.denimgroup.com/resources/blog/2019/05/mime-sniffing-in-browsers-and-the-security-implications/

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: 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");
cookie.setHttpOnly(true);

#Java Enterprise application WEB-INF/web.xml
<session-config>
 <cookie-config>
  <http-only>true</http-only>
 </cookie-config>
</session-config>

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