This is mostly because of the following two facts:

• most services and applications appear in the network of the contracting entity in the form of web applications, and
• a simple identification of services and their deficiencies is not enough to properly review the web applications, which is often allowed in certain other applications. Since web applications are very complex, their review requires a specific (manual) methodology.

Depending on the amount of work involved and the methodologies used to identify the security flaws, such a review cannot be compared to other methods of security reviews.

Given that this is a critical business segment, special attention has to be involved.

The specificity of web applications is that their security depends on the system on which the application is running (the operating system, the type of service – e.g. Apache) and the detailed service and script settings that are part of the application.

In any application, the security of the service depends on the operating system, the specific service, and its settings. When it comes to web applications, however, security is significantly more dependent on settings, scripts etc. that can be unique for each environment. Most other applications are more similar to each other in different environments and therefore generate a similar security verification, even if ran in different environments. In web applications, however, each application is unique and, as a result, so is every security verification.

This unique character is the reason why tools performing what is called automatic vulnerability verification are necessary, yet by no means sufficient. They provide a mere general insight into the web application environment, allowing at least to partially direct the manual activities required to successfully complete the review. For other applications, the tools (if used and selected properly) generally carry out most of the review, while manual intervention is then used to simply check for variations.

To a large extent, such a review is performed manually. Web applications can be extremely complex. This means they have a large number of available scripts, directories, HTML pages etc. It is important to be thoroughly familiar with the application first in order to be able to gradually check it for any security flaws in the optimal mode later.

We must be aware of the fact that applications often contain what is called a “closed section”, which is only accessible to authorised users. Performing a review of this section is of vital importance. Many security deficiencies actually relate to this “closed section”. Can an authorised user acquire the rights of another authorised user? Can an unauthorised user access a part they should not access by performing an attack on the authorised user? All of these issues affect the “closed section”, which is therefore always included in the security verification.

Traditional applications and services are subject to well-known and immediate security flaws. For example, a certain version of a certain service is known to exhibit a certain drawback. The attacker’s success therefore lies in merely determining whether such a service exists in the system with such a version, and then use the well-known approaches to relatively quickly test whether the actual vulnerability is present or not (certain circumstances – IDP, settings etc. – can still prevent a breach).

In discussing web applications, we use what is called the OWASP terminology. These are well-known principles of web application abuse, but the actual method of abuse can differ significantly for each application. Tools and manual scans are therefore only used to search for indices/parts of applications that may be susceptible to such deficiencies. This process is followed by manual work, where various attempts are used to determine whether a certain vulnerability and abuse can actually occur on that part.

Testing may also include the access and review of the source code in individual scripts. Most of the review, however, is usually focused on the user’s role rather than on the programmatic scanning of the source code in scripts.

A detailed written report consisting of two parts, which are presented in the form of a workshop:

• Management report
  It is a concise overview for executives, providing the basic cybersecurity information.
• Technical report
  A report intended for the administrator, which details the review of (un)successful manual reviews and malpractice tests of the web application, with added print screens and other data. Each confirmed vulnerability is explained in detail, indicating the potential consequences of the abuse and instructions for their elimination.

The answer is at any time. Web applications are regularly targeted by attackers, which is why the risk of misuse is constant.

Here are some of the excuses or reasons for not performing the review that we often hear and that are extremely dangerous in terms of guaranteeing security:

• We plan to renovate the web applications next year, so it is best to carry out a review at that time. But what about security until such time?
• Web applications offer nothing special to users that would be worth misusing. That is, of course, not true! A misuse of web applications does not involve the mere access to data, it is much more.
• We performed a review a few years ago, but it revealed nothing special. We have not changed anything since, so we are probably still safe. Again, not true! Attackers are constantly finding new ways of misuse.

A general opinion is that such a review should be carried out when it comes to changes in the application. However, this is not necessarily a good idea. Even if nothing changes, the probability of a breach can still increase. Attackers are constantly discovering new ways of attacking web applications, so just because something was safe yesterday it might not be safe today.

A periodical approach is a better approach. Web application security reviews should be carried out once every 6 months or at least every 12 months. It also makes sense to switch security review providers, as each contractor has different experiences, tools, and methodology.