Application auditing can be approached from a black-box or white-box perspective. In the white-box approach, the application’s Source Code is available and audited, but a manual component is required to assimilate the application’s context to obtain optimal results — and that capability is what we offer at Internet Security Auditors.
Companies normally include on their website small applications (Applets, CGIs, ActiveX, etc.) that help manage data submitted by users (personal data, orders, online payments, access control, etc.). There are also companies that use their website to carry out a wide variety of operations with their customers/suppliers/staff (e.g., corporate portals, online brokers/banking, e-commerce, extranets, etc.) and this implies the use of a complex application that runs on the web or application server and manages all these operations.
The actions carried out to perform the Application Audit follow the black-box philosophy, that is, at no time is the application’s source code audited. The reason for this working methodology is to simulate the real actions of a malicious attacker who, through the audited applications and without having access to their source code, attempts to attack the system, databases, etc.
The process of auditing applications is planned in the phases presented below:
Code
The programming language and its functionalities and particularities from the security point of view, since the project’s objective will be to define possible improvements to implement good security practices in development in that specific language.
Context
It is necessary to become familiar with the application to be reviewed. The security intended to be achieved will be defined by the business requirements of where the application is used, what data it handles, and what the consequences would be of illegitimate access to this information.
Audience
It may be advisable to have the collaboration of application users who can provide information about the audited application. Knowing how security controls have been implemented in the critical and key aspects will make it possible to identify where the most relevant deficiencies may be found.
Topology
Location of the application and its components within the context of the network (in some cases, reviewing these aspects will be omitted).
Importance
It is necessary to know the need for application availability and the effect of its loss on the business.
Our methodology allows us to carry out a thorough review of the audited applications covering the following security aspects:
Authentication
Auditing verifies that all internal and external connections (users and entities) pass through an appropriate and adequate authentication system and ensures that these controls cannot be bypassed; all pages or zones of the application require proper authentication; those points where credentials or sensitive information are transmitted use POST; credentials are transmitted encrypted; etc.
Authorization
It is verified that adequate authorization mechanisms have been implemented; user types or profiles and the rights of said users are clearly defined; the premise of “least privilege” is applied; authorization on each request; etc.
Cookie Management
It is reviewed that cookies do not include sensitive information; that unauthorized actions cannot be carried out by manipulating them; encryption and secure transmission are used; session data is correctly validated and the cookie contains the least amount of information possible; etc.
Input Data Validation
The audit verifies that robust data validation mechanisms exist and include all data that can be modified by a malicious user such as HTTP headers, input fields, hidden fields, list data, cookies, HTTP headers/data; that all validation checks are on the server and not on the client side; that there are no backdoors in the validation model; etc.
Error Management / Information Leakage
At this point it is reviewed that all methods/functions that return values have correct error management and return checked and expected values under error conditions. Exceptions and error situations are handled; system errors are not returned to the user; the application fails in a “secure” way; etc.
Logging / Auditing
It is audited that no type of sensitive information is stored in the application logs: cookies, information in “GET” methods, authentication credentials, etc.; the application logs the actions produced in the application by users and especially in cases of potentially dangerous actions; all authentication events, failed or not, are logged; etc.
