Application Security

Why should I be concerned about the security of my application?

Almost all applications are vulnerable to attack. According to Gartner, applications and data - not infrastructure - are the focus of modern cyber attacks. And attacks are on the rise. In 2015, companies saw an average of 160 successful cyber attacks per week, more than three times the 2010 average of 50 per week.

When you consider how many applications are used by the typical enterprise, the vulnerabilities increase dramatically. There are also new types of attacks: Web, cloud, API and mobile systems and interfaces can often be exploited by SQL injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) or denial of service attacks that thwart old defenses and result in the loss of sensitive information, unauthorized asset transfer, business discontinuity or dangerous system behaviors. (Gartner 2015, Hype Cycle for Application Security).

Insecure software is undermining financial, healthcare, defense, energy, and other critical infrastructure applications. As digital infrastructure gets increasingly complex and interconnected, the difficulty of achieving application security increases exponentially. Companies can no longer afford to tolerate relatively simple security risks like injection, broken authentication and session management, cross-site scripting, or insecure direct object references (OWASP Top 10, 2013).

In addition, many applications have inherent programming errors, such as insecure interaction between components, risky resource management, and porous defenses. Features and functionality are usually more important to software developers than security, and as a result, well-known security vulnerabilities are often not addressed (SANS Top 25 Most Dangerous Programming Errors).

Breaches are expensive and can lead to serious reputation damage. According to the Heritage Foundation, Nov. 18, 2015, Ponemon surveyed companies in the areas of finance, energy and utilities, and defense and aerospace - three of the most affected sectors - as well as communication, retail, and health care. The annual cost of cybercrime for these companies has more than doubled since 2010. Of the companies surveyed, the minimum cost to a company was $1.9 million while the maximum cost was as much as $65 million in 2015. The bottom line is that all applications are vulnerable, and when applications are vulnerable, so is the overall organization and its users.

Software vulnerabilities come in two basic flavors

Security bugs

Security bugs are errors present in source code, usually locally in a single line of code or slightly distributed. Most of these issues are likely to be SQL Injection and Cross-site Scripting vulnerabilities. They are fundamentally errors in coding and because all of them follow the same specific patterns, there are different types of technologies able to detect them automatically, with varying levels of accuracy.

These tools can even report the file and line where the security bug has been found, making it simple for software developers to resolve.

However, several details should be taken into account:

  • Accuracy: depending on the type of tool, the accuracy of security bug detection might be far from perfect, which may lead to a waste of resources trying to resolve false positives.
  • Number of vulnerabilities: when first used, these tools might report thousands of vulnerabilities, so it is important to be able to sort them as the workforce dedicated to solving these issues will be limited and it is critical to fix those of highest risk.

Hdiv solutions for Security Bugs

Hdiv provides a solution to fight against security bugs focusing on two aspects:

Detection: Hdiv provides accurate security bug detection (100% in OWASP Benchmark tool) so that developers know the exact file and line of each vulnerability, making them easy to fix. Hdiv is integrated within the Software Development Life Cycle so that programmers can detect such issues during the development process.

Protection: Due to its web information flow control system, Hdiv can protect the application against most malicious attacks, preventing such things as parameter tampering, which is closely linked to many instances of security bug exploitation. By using Hdiv, in most situations these vulnerabilities cannot be exploited. This allows us to focus on those security bugs that can be attacked, primarily those coming from client-side data (textfields).

Business Logic Flaws

Security issues are better known these days than they used to be, and it is not uncommon to find software developers aware of some application security concepts such as SQL Injection or XSS. However, the same does not occur with concepts such as Business Logic Flaws (also known as Security Design flaws), which represent about 50% of security problems.

It is not easy to understand why such a significant proportion of security issues go unnoticed but there are many reasons for this.

First of all, they are not easy to describe, because in many cases they are based on a combination of different things. Probably the best way to define business logic flaws is to describe what they are not about. Security design flaws or business logic flaws are security issues that cannot be detected by tools such as ASTs. In other words, they are business specific and do not follow a particular pattern of risk and therefore they have to be detected by auditing the applications manually.

A slightly different description could be that design flaws are not located only in a specific file and line of your code. Instead, these kinds of issues are more related to the general security architecture of the application and the problem is spread over many areas of the source code. Therefore the detection of business logic flaws cannot be automated.

"Tests of business logic flaws are similar to those used by functional testers focusing on logical or finite state testing. These types of tests require security professionals to think a bit differently, develop abuse and misuse cases and use many of the testing techniques embraced by functional testers. Automation of business logic abuse cases is not possible and remains a manual art relying on the skills of the tester and their knowledge of the complete business process and its rules."

Secondly, the impossibility of detecting these issues makes them unattractive to most of the security industry, leading to a lack of awareness of these risks as they are rarely mentioned by the big companies. Therefore, an application security strategy that is only based on Application Security Testing tools (AST), will only be detecting 50% of the problem as these tools are unable to detect any issue related to security design flaws or business logic flaws.

The issues are similar when using protection solutions such as Web Application Firewalls (WAF). We should take into account that many of them are only designed or configured to protect against some specific common attack patterns, but business logic flaws are not included in those patterns. So, it is very common to have production environments protected by WAFs that are still vulnerable to 50% of risks.

Hdiv solutions for Business Logic Flaws

The pragmatic approach of Hdiv is to try to protect the application against business logic flaws instead of trying to detect them. This can be done by solving the root cause of all business logic flaws as these kinds of vulnerabilities all have something in common - they are based on malicious crafting of URLs, parameters, etc. on the client side. Hdiv limits end-user interaction, avoiding the manipulation of data, therefore protecting from such risks. Basically, Hdiv enforces the contract offered by the server side avoiding any kind of unexpected behavior.

Resources

VIDEO

Application self-protection is finally here

Watch

VIDEO

Hdiv Protection (RASP) in the Production environment

Watch

CONFERENCE

Protection and Verification of Security Design Flaws

Watch

VIDEO

Hdiv RASP protecting Spring REST APIs

Watch