Quarterly site security check



    A modern web resource is a constantly evolving mechanism with many updates and improvements. They are aimed at improving productivity, increasing conversion, optimizing performance and usability. But at the same time, for one reason or another, errors can be made that can lead to a compromise of a web resource. It can be “forgotten” utility scripts, insufficient data control, lack of access checks, output of various errors and much more. For the CMS used in the public domain, exploits may appear that allow access to one or another functional of the web application, with the help of which an attacker can harm or try to obtain critical data. Many vulnerabilities exploited by the average static attacker

    Easy hack


    Most modern attacks on websites occur using automated tools: all kinds of web scanners, frameworks and utilities. Those. the threshold for entering web-pentesting is rather low and compromising a site (in the presence of superficial vulnerabilities) is just a matter of time.

    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 their mechanism of action.

    Script kiddie - seekers of easy prey. They do not try to gain access to any specific information or carry out an attack on a specific company. Their goal is to gain root privileges in the simplest possible way. They achieve this by selecting a small number of vulnerabilities and then scanning the Internet in search of them. Sooner or later they find a vulnerable system.

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

    Attackers can look for certain signs, such as the type and version of the CMS, the presence of certain files in the root of the site, and so on, using search engines and scanners to check for 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 existence of a vulnerability.

    Basic attack vectors


    In order to be sure that the web application cannot be hacked “right away”, we developed several scripts for checking typical attack vectors for the web application.

    Information collection: accessible information is collected, such as web server headers, determination of the type of platform, CMS, frameworks. It checks the presence of phpinfo files and service scripts that allow you to obtain sensitive information about the attacked web resource, scans the site directories for backup files, critical data (repositories, documents, etc.).

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

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

    • sql injections - various kinds 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 inclusion;
    • open redirects - redirects;
    • code executions - code execution;
    • http response splitting - splitting http requests;
    • xpath injections - xpath injections;
    • buffer overflows - all kinds of buffer overflows;
    • known vulnerabilities - search for known exploits.

    Additionally: authorization forms are attacked by a dictionary (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 as a complex attack scenario for a web application. Checking the site in automatic mode will reveal most of these vulnerabilities to quickly eliminate and minimize the risks of hacking the site.

    Audit methodology


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

    Vulnerability type: code injection - OWASP A1 (injection).
    How it is detected: errors in the body of the page, response time.
    What threatens: compromise of user data, infection of the site.

    Type of vulnerability: 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 leak of someone else's session can lead to the seizure of account management.

    Type of vulnerability: 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 on the user, data manipulation.

    Type of vulnerability: insecure direct object references - OWASP A4 (insecure direct object references).
    How it comes to light: enumerating the value of parameters.
    What threatens: leak of critical data is possible.

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

    Type of vulnerability: sensitive data leak - OWASP A6 (sensitive data exposure).
    As revealed: the correct installation and configuration of certificates, the identification of critical data.
    What threatens: leak of critical data is possible.

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

    Type of vulnerability: cross-site request fake - OWASP A8 CSRF (cross-site request forgery).
    As revealed: lack of verification of the request address (token).
    What threatens: data manipulation.

    Type of vulnerability: using 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: compromise of user data, infection of the site.

    Type of vulnerability: unvalidated redirects - OWASP A10 (unvalidated redirects and forwards).
    As revealed: manipulation of URL parameters.
    What threatens: compromise of user data, critical data may leak.

    Total


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

    The frequency of verification (once a quarter, or more often, at will) will allow the site owner to have an up-to-date picture of security. Such checks will allow to identify most surface vulnerabilities, outdated versions of software and CMS components as soon as possible and will quickly protect the web application.

    Also popular now: