Tag Archives: webapps security

World’s 100 largest banks Application security are very vulnerable.

Abstract

Industry analysts and security practitioners unanimously concur that application security is a big deal. The application security market is predicted to exceed $7 billion USD by 2023 according to a recent research by Forrester. While Gartner says that banking sector leads in global cybersecurity spending.

This research guides you through application security, privacy and compliance of the world largest financial institutions from S&P Global list for 2019.

Key Findings

Compliance:

  • 85 e-banking web applications failed GDPR compliance test
  • 49 e-banking web applications failed PCI DSS compliance test
  • 25 e-banking web applications are not protected by a Web Application Firewall

Security Vulnerabilities:

  • 7 e-banking web applications contain known and exploitable vulnerabilities
  • The oldest unpatched vulnerability is known and publicly disclosed since 2011
  • 92% of mobile banking applications contain at least 1 medium-risk security vulnerability
  • 100% of the banks have security vulnerabilities or issues related to forgotten subdomains

Read more at

https://www.immuniweb.com/blog/SP-100-banks-application-security.html

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?

Overview

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.

Solution

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");
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">

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.