Imperva Blog|Login|中文Deutsch日本語
Glossary

Access of Internal Components

Applications are generally built from many different components, some of which are intended for internal use by other components and should not be accessible to external users. In a secure environment, such internal components are hidden and blocked from external access. An insecure system, however, might allow remote access to some or all of the internal components. Attackers may take advantage of this vulnerability in their attempts to attack the system application or system.

Detailed description

Internal modules used by developers can be divided into two groups. The first group comprises components that are called by the browser from within other pages. These are not truly "internal" to the application, as they are normally exposed to requests from outside. What makes them internal is the way the developer treats them - meaning, the developer assumes that since they are called only from within another page (and not directly by a link or a form), they are not exposed to attacks, and therefore present no real security risk. Yet this type of component does not really differ from a normal page, and can be vulnerable to attacks such as SQL injection, cross-site scripting, parameter tampering, etc.

The second group comprises components that are truly internal, and are called by other pages on the server side only. For example, instead of having all ASP pages access the database directly, the developer may build a Data Access Layer, implemented by another component, which all ASP pages access. This enables connectivity to the database to be handled in a single location, rather than in every page.

Although using internal reusable components appears to be the right way to build an application, it may also be very dangerous. Many programmers allow these components to be accessed externally via the Internet, even though this is not required and not recommended. An attacker may access one of the main pages and cause it to send out an error indicating the name of the internal component, and then access the internal component directly. By doing so, the attacker may be able to execute attacks against that component.

Internal components often do not include their own security checks. They are called by the main pages, and it is assumed that the main pages handle all security-related checks. Looking at the Database Access Layer in the example above, it is likely that there is no further need to handle access permissions for the database, as the pages that call it already check permissions. However, by accessing the Database Access Layer directly, the attacker may gain complete access to the database.