Quarterly site security check

A modern web resource is a constantly evolving mechanism with many updates and improvements. They are aimed at improving performance, increasing conversion, optimizing performance and ease of use. But at the same time, for one reason or another, mistakes may be made that may lead to a compromise of the web resource. These can be “forgotten” service scripts, insufficient control over data, lack of access checks, output of various errors and much more. For the CMS being used in public access, exploits may appear that allow access to a particular web application functionality, with which an attacker can harm or try to obtain critical data. Many vulnerabilities that are exploited by the average malefactor lie on the surface and do not require deep knowledge or qualifications for their exploitation.

Easy hack

Most modern attacks on websites occur with the use of automated tools: various kinds of web scanners, frameworks and utilities. Those. The threshold for entry into web pentesting is quite low and the compromise of the site (if there are surface vulnerabilities) is only a matter of time.

Kiddie Script (English Script kiddie) is a derogatory term in hacker culture used to describe those who use scripts or programs developed by others to attack computer systems and networks without understanding the mechanism of their action.
')
Script kiddie - easy prey seekers. They are not trying to access any specific information or carry out an attack on a specific company. Their goal is to get root as the simplest possible way. They achieve this by selecting a small number of vulnerabilities and then scanning the Internet for their searches. Sooner or later they find a vulnerable system.

According to the statistics of our automatic scanning system, up to 30% of the sites submitted for inspection contained critical vulnerabilities - sql injection, unsafe direct links to objects, the vulnerability of critical data - all this makes attacks on sites easily accessible and productive.

The attackers can search for certain signs, such as the type and version of the CMS, the presence of certain files in the root of the site, etc. using search engines and scanners to check the presence of a particular vulnerability. It can also be a set of specific patterns, server responses to certain requests, by which you can try to determine the presence of a vulnerability.

Basic attack vectors

In order to be sure that the web application will not be able to crack the "outright" we have developed several scenarios for checking the typical attack vectors on the web application.

Information gathering: information available is collected, such as web server headers, platform type definition, CMS, frameworks. It checks for the presence of phpinfo files and service scripts that provide sensitive information about the attacked web resource, scans the site directories for the presence of backup files, critical data (repositories, documents, etc.).

Analysis: a web application map is compiled with all available links from the site for further exploitation attempts. Detected email addresses are added to the list of intended logins to the bruteforce module.

Check: the site is checked for the most common errors and vulnerabilities, such as:

• sql injections - all sorts of sql injections;
• cross site scripting - xss, crossite scripting;
• cross site requets forgery - csrf, cross-site request forgery;
• local file inclusion - local inclusion;
• remote file inclusion - remote incloud;
• open redirects - redirects;
• code executions - code execution;
• http response splitting - splitting http requests;
• xpath injections - xpath injections;
• buffer overflows - all sorts of buffer overflows;
• known vulnerabilities - search for known exploits.

Additionally: authorization forms are subject to a dictionary attack (bruteforce) with a list of frequently encountered logins (admin, user, test, web, etc.) using a specialized password database.

Identified vulnerabilities can be exploited either individually or in a complex attack scenario for a web application. Checking the site in automatic mode will allow you to identify the majority of vulnerabilities of this kind to quickly eliminate and minimize the risks of hacking the site.

Audit methodology

These scenarios are compiled taking into account the methodology OWASP TOP 10.

Type of vulnerability: code injection - OWASP A1 (injection).
How to identify: errors in the body of the page, response time.
What threatens: the compromise of user data, site infection.

Vulnerability type: incorrect authentication and session management - OWASP A2 (broken authentication and session management).
As revealed: the transfer of the session in the URL, the lack of encryption.
What threatens: the leakage of someone else's session can lead to the interception of account management.

Vulnerability type: cross-site scripting - OWASP A3 XSS (cross-site scripting).
As revealed: the presence of a response to a specially formed request in the page code.
What threatens: the attack is made directly to the user, data manipulation.

Vulnerability type: unsafe direct object references - OWASP A4 (insecure direct object references).
As detected: enumerate the values ​​of parameters.
What threatens: possible leakage of critical data.

Type of vulnerability: insecure configuration - OWASP A5 (security misconfiguration).
How to identify: identify default settings, standard passwords, error messages.
What threatens: the compromise of user data, site infection.

Type of vulnerability: sensitive data leakage - OWASP A6 (sensitive data exposure).
How to identify: correct installation and configuration of certificates, identification of critical data.
What threatens: possible leakage of critical data.

Type of vulnerability: lack of access control to the functional level - OWASP A7 (missing function level access control).
As detected: data manipulation to gain access.
What threatens: possible leakage of critical data.

Vulnerability type: cross-site request forgery - OWASP A8 CSRF (cross-site request forgery).
How to identify: no validation of the request address (token).
What threatens: data manipulation.

Vulnerability type: use of components with known vulnerabilities - OWASP A9 (using components with known vulnerabilities).
As revealed: the presence of publicly available vulnerabilities for this version of the application.
What threatens: the compromise of user data, site infection.

Type of vulnerability: unvalidated redirects - OWASP A10 (unvalidated redirects and forwards).
As detected: the manipulation of the parameters of the URL.
What threatens: the compromise of user data, possible leakage of critical data.

Total

All detected vulnerabilities are assigned a certain rank: from minor to critical. Each vulnerability from the category of critical is manually checked to minimize false-positives. The report contains a list of vulnerable URLs, parameters, type and description of the vulnerability, as well as the likely consequences of the exploitation of the vulnerability by the attacker.

Frequency checks (quarterly, or more often, if desired) will allow the site owner to have an up-to-date picture of security. These types of checks will quickly reveal most of the surface vulnerabilities, outdated versions of software and CMS components, and allow you to quickly protect your web application.

An example of a report on the automatic site scan .