WO2018135964A1 - Способ защиты веб-приложений с использованием автоматического построения моделей приложений - Google Patents

Способ защиты веб-приложений с использованием автоматического построения моделей приложений Download PDF

Info

Publication number
WO2018135964A1
WO2018135964A1 PCT/RU2017/000194 RU2017000194W WO2018135964A1 WO 2018135964 A1 WO2018135964 A1 WO 2018135964A1 RU 2017000194 W RU2017000194 W RU 2017000194W WO 2018135964 A1 WO2018135964 A1 WO 2018135964A1
Authority
WO
WIPO (PCT)
Prior art keywords
web application
requests
web
attacks
functioning
Prior art date
Application number
PCT/RU2017/000194
Other languages
English (en)
French (fr)
Inventor
Георгий Максимович НОСЕЕВИЧ
Денис Юрьевич ГАМАЮНОВ
Валерия Григорьевна ШЕРВАРЛЫ
Эмиль Марселевич КАЮМОВ
Original Assignee
Общество с ограниченной ответственностью "СолидСофт"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Общество с ограниченной ответственностью "СолидСофт" filed Critical Общество с ограниченной ответственностью "СолидСофт"
Priority to EP17892571.5A priority Critical patent/EP3550789A4/en
Publication of WO2018135964A1 publication Critical patent/WO2018135964A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis

Definitions

  • This technical solution relates, in general, to the computing field, and in particular to the field of detecting attacks on a protected web application using positive security models and building models of a web application using machine learning methods.
  • the technical solution describes the principles for automatically detecting such parameters using heuristic features (for example, passing parameters as hidden fields of web forms) and statistical (invariance of parameter values between consecutive requests and responses of a web application), with subsequent control of invariance of read-only parameters on Web application protection phase.
  • heuristic features for example, passing parameters as hidden fields of web forms
  • statistical invariance of parameter values between consecutive requests and responses of a web application
  • this solution describes only a special case of constructing one of the web application models (the so-called “profile” of parameters), but only from the point of view of HTTP requests and responses.
  • page-flow web application model constructed in this way is suitable for protection against certain types of attacks (for example, direct access via a link to the closed part of the web application), but it does not, for example, control user access rights in terms of objects of the web subject area applications.
  • firewalls at the web application level do not have technical solutions for detecting a wide class of logical attacks on protected web applications.
  • the level of modeling the main aspects of the functioning of the web application for firewalls in existing technical solutions is limited by the syntax and semantics of HTTP requests to the web application and responses of the web application, as well as control of types and ranges of HTTP request parameter values. These models do not allow detecting logical attacks on a web application efficiently and with a low level of false positives.
  • the technical problem to be solved in this technical solution is to build and use not only the syntax and semantics models of HTTP requests to the web application to protect the web application, but also the models of the logic level of the web application’s functioning, including recognition of actions of the logic level of the web’s functioning applications (request routing schemes in a web application), determining the syntax and semantics of the parameters of actions of a web application, identifying scenarios for using a web application and user access control rules her resources and objects related to the Web application field.
  • the technical result achieved in this technical solution is to increase the performance of an intelligent firewall.
  • the technical result is an increase in the quality of detecting false positives of signature rules for detecting attacks and anomaly detection modules for certain types of requests.
  • the proposed solution is an intelligent firewall for protecting web applications, which automatically collects training data and builds models of the web application’s functioning, including the construction of syntax and semantics models of HTTP requests to the web application and responses to them (for further analysis of HTTP requests and responses), identifying actions of the logic level of the web application functioning (query routing model), determining sets of parameters and acceptable parameter values for action data d (a model of the parameters of the actions of the web application), and building models for the scenarios of using the web application and the rules for controlling access to the resources and functions of the web application.
  • the intelligent firewall also detects false positives (for signature rules for detecting attacks or individual anomaly detection modules) and identifies requests to static resources of a web application with the construction of URL patterns for these requests.
  • constructing syntax and semantics models of HTTP requests and responses to them, building a routing model of requests, identifying requests to static resources of a web application (with building URL patterns of request data addresses) and identifying false positives (signature detection rules attacks or individual anomaly detection modules) are performed using machine learning methods (for example, through hierarchical clustering) and data analysis (for example, statistical correlation analysis).
  • machine learning methods for example, through hierarchical clustering
  • data analysis for example, statistical correlation analysis
  • Mistake! The source of the link was not found, illustrates the general architecture of the system that implements a method of protecting web applications using an intelligent firewall using automatic construction of application models.
  • FIG. 3 illustrates a method for constructing models of a protected web application in one embodiment of the method.
  • FIG. 4 illustrates an embodiment of a partial parsing tree for a web application request.
  • FIG. 5 illustrates another embodiment of a web application request parsing tree.
  • FIG. 6 illustrates a method for constructing a query parsing tree.
  • FIG. 7 illustrates an example implementation of a decision tree for parsing queries.
  • Fig. 8 illustrates a method for constructing a decision tree for parsing queries across a plurality of query parsing trees.
  • FIG. 9 illustrates the applicability table of decoders used in the process of clustering query trees when constructing a decision tree for parsing queries.
  • FIG. 10 illustrates a method for constructing a web application request routing model.
  • FIG. 11 illustrates a method for detecting requests to static resources of a web application and constructing URL patterns of requests for static resources of a web application.
  • FIG. 12 illustrates a method for finding a plurality of URLs of static web application resources based on a plurality of pairs of web application requests and web application responses.
  • FIG. 13 illustrates an example implementation of a state machine simulating a web application use case.
  • FIG. Figure 14 illustrates a method for detecting false positives for signature rules for detecting attacks and individual modules for detecting anomalies, creating log messages about false positives, and generating settings for exclusion of signature rule data from further processing during the security phase of the web application.
  • FIG. 15 illustrates a general method for processing a single request for a web application during the security phase of a web application by the system.
  • This technical solution can be implemented as a distributed computer system.
  • a system means a computer system, a computer (electronic computer), CNC (numerical control), PLC (programmable logic controller), computerized control systems, and any other devices that can perform a given, clearly defined sequence of operations (actions, instructions).
  • command processing device an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs).
  • the command processing device reads and executes machine instructions (programs) from one or more data storage devices.
  • Storage devices may include, but are not limited to, hard disks (HDD), flash memory, ROM (read only memory), solid state drives (SSD), optical media (CD, DVD, etc.).
  • a program is a sequence of instructions intended for execution by a control device of a computer or a device for processing commands.
  • Positive security model also known as “white lists” - security models that explicitly specify the set of allowed actions and prohibit all other actions (that is, those that are not included in the allowed list).
  • the logic of a web application functioning is a set of applied tasks solved by a web application expressed in terms of objects of the web application subject area, actions (logical manipulations) over them and restrictions that reflect acceptable scenarios for using the web application and the rights of various categories of its users.
  • a web application that supports the Internet the blog provides the user with the ability to create, view, edit and delete entries and comments on them - each such opportunity is a separate action of the logic level of the web application.
  • Examples of objects of the subject area of a web application are, for example, products in an online store, blog entries, user accounts in payment systems, etc.
  • a computer attack is a targeted unauthorized impact on information, on the resource of an information system or gaining unauthorized access to them using software or hardware tools.
  • Logical attack - a computer attack on the level of the logic of the functioning of a web application, i.e. such an attack, during which there is no violation of the syntax and semantics of HTTP requests to the web application, but on behalf of the attacker, those actions are performed at the level of the logic of the functioning of the web application that should not be available to him as intended by the developers.
  • Firewall (ME), firewall, security system, firewall, "fire wall” - a system (hardware or software) or a combination of systems that, for the purpose of protection, forms the boundary between two or more networks, protecting against unauthorized entry into the network or preventing exit from the network her data packets.
  • a web application is a client-server application in which the client is the browser and the server is the web server.
  • the logic of the web application is distributed between the server and the client, data storage is carried out mainly on the server, information is exchanged over the network.
  • Training data collection in this technical solution, the process of collecting requests for a web application, responses of a web application (and, optionally, messages about the triggering of signature rules for detecting attacks) during a time period predefined by the operator and / or system administrator during which the operation Web applications are considered “normal” (reflects acceptable use cases).
  • Web application protection stage - this stage implements the web application protection mode from possible attacks by malicious users.
  • the implementation of this stage begins after the system is put into the protection mode of the web application, which is carried out automatically after the completion of the training and construction phase. functioning models of the web application or at the command of the operator and / or system administrator.
  • FIG. 1 The general architecture of a system implementing the proposed method is illustrated in FIG. 1.
  • the system consists of the following components:
  • Analyzer which is designed to receive and analyze the traffic of the protected web application (requests to the web application and responses of the web application), its analysis in order to detect attacks on the web application (including attacks of the logic level of the web application functioning) ) and responding to attack data, including blocking attack requests and / or generating and saving messages about detected attacks;
  • Database component of data storage
  • Training data requests for a web application and web application responses collected at the stage of collecting training data
  • built models of web applications log messages generated during the operation of the system and various system settings
  • Web dashboard which is designed to implement the graphical interface of the operator and / or system administrator.
  • the components used in the system can be implemented using electronic components used to create digital integrated circuits. Not limited to, microcircuits can be used, the logic of which is determined during manufacture, or programmable logic integrated circuits (FPGA), the logic of which is set by programming.
  • FPGA programmable logic integrated circuits
  • programmers and debugging environments are used that allow you to specify the desired structure of a digital device in the form of a circuit diagram or a program in special equipment description languages: Verilog, VHDL, AHDL, etc.
  • Alternative FPGAs are: programmable logic controllers (PLCs), base matrix crystals ( BMK) requiring a factory production process for programming; ASIC - specialized custom large integrated circuits (LSI), which are much more expensive in small-scale and single-unit production.
  • components can be implemented using read-only memory devices (see O. Lebedev. Memory microcircuits and their application. - M .: Radio and communications, 1990. - 160 s; Large integrated circuits of memory devices: Reference / A.Yu. Gordenov et al. - M: Radio and Communications, 1990 .-- 288 s).
  • the Analyzer component implements the following functionality:
  • An Analyzer component consists of at least the following three service components:
  • HTTP reverse proxy • component of active traffic capture (HTTP reverse proxy), which implements the logic of the reverse HTTP proxy to intercept requests to the protected web application and responses from the web application;
  • Passive HTTP proxy which implements the functionality of passive receiving a copy of traffic between the protected web application and its users through a network branch (network TAP); • a component for analyzing requests and responses of a web application and making decisions (Analyzer Core), which implements the functionality of collecting information about requests for a web application and responses of a web application, analyzing requests for a web application using the built-in functioning models of the web application, classification requests for normal and abnormal (including the classification of the request as attacks on the web application), and the decision to transfer the request to the protected web application or block it.
  • Passive HTTP proxy which implements the functionality of passive receiving a copy of traffic between the protected web application and its users through a network branch (network TAP)
  • Analyzer Core which implements the functionality of collecting information about requests for a web application and responses of a web application, analyzing requests for a web application using the built-in functioning models of the web application, classification requests for normal and abnormal (including the classification of the request as attacks on the web application), and the decision to transfer
  • the HTTP reverse proxy service component is a reverse proxy server for intercepting HTTP traffic.
  • the system is supposed to operate in reverse HTTP proxy mode. In this mode, the HTTP reverse proxy service component intercepts requests to the protected web application, transfers information about these requests to the Analyzer Core service component, and waits for a request processing solution from this service component.
  • the request it is possible, at least, to transfer the request to the protected web application, or to block and reset the request.
  • the user request can be transmitted to the protected web application only after the SARTSNA test is successfully solved by the user of the web application.
  • the HTTP reverse proxy component can also implement the logic of automatic classification of requests for requests to static and dynamic resources of a web application. This behavior of the HTTP reverse proxy component is controlled by special settings created during the learning process of the system by the Learning component, stored in the database of the Database component and transferred to the HTTP reverse proxy component by the Analyzer Core component.
  • the Analyzer Core component When classifying a received request as a request to the static resource of the protected web application, the request is transmitted to the protected web application without further processing by the Analyzer Core service component, which reduces the computational load.
  • the Passive HTTP sniffer component is responsible for capturing a copy of the traffic to the protected web application received from the network branch.
  • the Passive HTTP sniffer component extracts from the copy of the network traffic the flow of requests to the protected web application and responses from the web application and the information about them is transmitted to the Analyzer Core component.
  • blocking abnormal (or attacking) requests and web server responses to these requests is not possible, although collecting training data at the system training stage and analyzing requests and responses at the web application protection stage (with the generation of appropriate log messages for the operator and / or system administrator) remain available.
  • the Passive HTTP sniffer component can also implement the logic of automatic classification of requests for requests to static and dynamic resources of a web application. This behavior of the Passive HTTP sniffer component is controlled by special settings created during the learning process by the Learning component, stored in the Database component and passed to the Passive HTTP sniffer component by the Analyzer Core.
  • This behavior of the Passive HTTP sniffer component is controlled by special settings created during the learning process by the Learning component, stored in the Database component and passed to the Passive HTTP sniffer component by the Analyzer Core.
  • the Analyzer Core When classifying an incoming request as a request to a static resource of a protected web application, information about the request is not transmitted to the Analyzer Core component, which reduces the computational load.
  • information about the request is passed to the Analyzer Core component for further analysis.
  • the Analyzer Core component analyzes the requests to the protected web server and responses from the web server and makes decisions on processing the request based on the analysis results.
  • the Analyzer Core component consists of a set of modules, which include:
  • module for interacting with the component of active traffic capture (Proxy Adapter) - is responsible for interacting with the HTTP reverse proxy service module in terms of:
  • module for interacting with the passive traffic capture component (PassiveAdapter) - is responsible for interacting with the Passive HTTP sniffer service module in terms of:
  • HTTP request and response parsing module (DecisionTreeParser) - is responsible for parsing incoming requests to the web application and responses from the web application in accordance with the constructed syntactic and structural models for parsing HTTP requests and responses of the web application;
  • module for recognizing actions of the level of the logic of the functioning of the web application (ActionDeterminer) - is responsible for analyzing requests to the web application to identify actions of the level of the logic of functioning of the web application in accordance with the request routing model;
  • module for recognizing the result of the action of the logic level of the functioning of the web application (ActionStatusDeterminer) - is responsible for analyzing the responses of the web application to identify the success or failure of the previously initiated action of the logic level of the functioning of the web application in accordance with the request routing model in the web application;
  • Session Tracking Module (SessionTracker) - is responsible for analyzing web application requests and web application responses to track sessions and users, in accordance with the request routing model in a web application and auxiliary models that describe signs of successful and unsuccessful requests;
  • DecisionMaker a decision-making module — is responsible for analyzing requests to a web application, performing at least:
  • the Analyzer Core component may also include a module for detecting attacks on a web application using the ModSecurity tool (ModsecurityDetector).
  • This module is a tool for analyzing HTTP requests to a web application, based on the application of a set of signature rules. This tool is developed by a third party and is available publicly in the form of source codes and a set of signature rules.
  • the ModsecurityDetector module analyzes requests to the protected web application using a set of signature rules and generates log messages about the operation of certain signatures. These messages can be written to the database of the Database component, and also used by the DecisionMaker component to classify the request.
  • the Analyzer Core component may also include a module for detecting attacks on a web application using the Libinjection tool (LibinjectionDetector).
  • This module is a tool for analyzing HTTP requests to a web application, based on an assessment of the degree of anomalousness of a request based on the presence of attack signs in a previously parsed request.
  • This tool is developed by a third party and is available. publicly in the form of source codes and a set of signature rules.
  • the LibinjectionDetector module analyzes requests to the protected web application, parses the request and searches for signs of attack in it, and generates log messages with an assessment of the degree of abnormality of the given request. These messages can be written to the database of the Database component, and also used by the DecisionMaker module to classify the request.
  • the Learning component can perform the stage of detecting false positives of individual signature rules for detecting attacks, and configure the settings for ModsecurityDetector and LibinjectionDetector modules, which allow excluding these signature rules from further use when analyzing requests.
  • the Database component is a database designed for long-term storage of all the information necessary for the functioning of the system. This information includes at least:
  • various DBMS options can be selected on the basis of which this component can be implemented, and various architecture options of the Database component (for example, a centralized or distributed database).
  • the Learning component is designed to automatically build web application functioning models based on the collected information about the characteristics of normal web application requests and the rules for building web application models.
  • Information about the characteristics of normal requests to a web application is stored in the database of the Database component and updated by the Analyzer component at the stage of collecting training data.
  • the rules for constructing models are stored in the database of the Database component and can be added to it or modified by the operator and / or system administrator using the Web dashboard component.
  • the process of building models of the functioning of the web application can be started automatically at the end of the time period allocated for the collection of training data.
  • the models of the functioning of the web application constructed by the Learning component are stored further in the database of the Database component.
  • the Learning component may also include the functionality of detecting false positives (signature rules for detecting attacks or individual modules for detecting anomalies) using statistical methods.
  • the Learning component uses the data collected by the Analyzer component at the training data collection stage and stored in the Database component database to identify signature rules and individual anomaly detection modules that have a high level of false positives. It also creates log messages about false positives and creates new settings for the signature modules of the Analyzer component, with the help of which these signature rules are excluded from subsequent use.
  • the Web dashboard component implements GUI functions for the operator and / or system administrator in order to monitor the situation and respond to incidents.
  • This component is designed to implement at least the following functions: • providing the operator and / or administrator with information about the current state of the protected web application, including data on current requests to the web application;
  • the Web dashboard component receives all the necessary information from the Database component. If the operator and / or administrator creates new rules for constructing models, classifying requests or responding to anomalies and attacks, or modifying existing rules, these changes are saved in the database of the Database component.
  • FIG. 2 illustrates a basic method of operating a system in one embodiment. It consists of the stage of collecting training data, the stage of building models of the protected web application, the stage of detecting false positives and the stage of protecting the web application.
  • the Analyzer component collects requests to the protected web application and responses of the web application and writes them to the database of the Database component. At this stage, the Analyzer component also records information about the operation of signature rules in the database if the Analyzer component includes at least one module for detecting attacks on a web application based on a set of signature detection rules.
  • the Learning component builds the previously specified set of models the functioning of the web application based on the set of requests and answers collected at the stage of collecting training data.
  • the constructed models are stored in the database of the Database component.
  • the Learning component identifies signature rules for detecting attacks and individual modules for detecting anomalies that have a high level of false positives. For detected signature rules with a high level of false positives, the Learning component generates and stores in the database settings for attack detection modules that use signature rules, by which signature rules with a high level of false positives are excluded from further use during the protection phase of the web application. For false alarms detected, log messages are also created that allow the operator and / or system administrator to analyze the causes of false alarms of the anomaly detection modules and initiate the system training step to re-manually or manually make the necessary changes to the constructed functioning models of the web application.
  • the Analyzer component receives constructed models of the web application functioning from the Database component and uses them to analyze new incoming requests to the web application and its responses, assess the degree of normality or anomaly of these requests and decide on their further processing ( blocking or permitting the request).
  • the Analyzer component also uses the built-in web application functioning models to configure the HTTP reverse proxy and Passive HTTP sniffer service components to ensure that only those requests (and responses) of the web application that are requests (and responses) to dynamic ones are sent to the Analyzer Core component for analysis. protected web application resources.
  • the analysis of requests to the static resources of the web application (and the answers to these requests) at the stage of protecting the web application is not performed in order to reduce computational complexity and increase system performance.
  • FIG. 3 illustrates a method for constructing functioning models of a protected web application. This method is executed by the Learning component based on information about the requests and responses of the web application obtained at the stage of collecting training data. The results of the various steps of this method are constructed models of various aspects of the functioning of the protected web application. This method consists of the following main steps: • building parsing trees for all requests to the protected web application and responses from the web application;
  • the list of steps of the method and corresponding models of the protected web application, the construction of which is carried out by the system in a fully automatic mode, includes at least the following steps:
  • the models built during the training phase of the system are stored in the database of the Database component and are used later in the protection phase of the web application to analyze requests and responses of the web application.
  • the operator and / or system administrator has the ability to manually edit and configure all built models using the Web dashboard component.
  • the first step used at the stage of constructing the functioning models of the web application is the construction of parsing trees for all requests to the protected web application and responses from the web application collected at the training data collection stage.
  • To create an HTTP request to a web application modern browsers encode structured data to be transmitted using the sequential application of various encoding methods. Parse trees simulate specific results of a web application parsing incoming HTTP requests to it by using a set of appropriate decoders and restoring the original structured data. Parse trees are an internal representation of HTTP requests to a web application and are used in other web application models.
  • the parsing tree for a request is the presentation of a request to a web application in the form of a root tree, which uniquely reflects the structure of the request and its contents and obtained as a result of successively applying various data decoding functions to the request and its parts (for example, x-www-form-urlencode, json, etc.).
  • FIG. Figure 4 illustrates the process of applying the x-ww-form-urlencode decoder to string data (in this example, the query string of an HTTP request).
  • string data in this example, the query string of an HTTP request.
  • the leaves of a partially constructed parse tree can be structured data obtained using any encoding method. Applying an appropriate decoder to them modifies the partial tree, replacing the given leaf vertex with a new root parse tree. This process continues until the resulting leaf vertices of the parse tree turn out to be simple data (numbers, lines, etc.), to which it is no longer possible to use decoders.
  • FIG. 5 illustrates an HTTP GET request parsing tree obtained by sequentially applying three decoders.
  • FIG. 6 illustrates a method for constructing a parse tree for an arbitrary request to a web application, many of which were obtained at the stage of collecting training data.
  • a root tree is created from a single leaf vertex, which is added to the list for processing.
  • the proposed method further selects one of the root vertices for processing and tries to find a decoder, applying it to the contents of the vertex leads to successful parsing and building a child parse tree. This vertex is then replaced by the found tree and marked with the appropriate decoder applied.
  • Leaf vertices of the constructed tree are added to the list for further processing. The process ends when the list of vertices for processing becomes empty.
  • parsing trees To simulate the responses of the web application, a similar mechanism of parsing trees is used, and a similar method of constructing parsing trees for all answers of the web application obtained at the stage of collecting training data.
  • Different requests for a web application can have different internal structures. This means that different parsing trees will be built for different requests (and responses), differing not only in the contents of leaf vertices, but also in the structure of the tree itself.
  • the decision parsing decision tree (and a similar decision parsing decision tree) are used. This tree models the logic for parsing requests by a protected web application.
  • the decision parsing decision tree is a root tree, all paths from the root to the leaves of which correspond to one of the possible chains of decoders for parsing an HTTP request to a web application.
  • the tops of this tree are marked with a pair consisting of:
  • the arcs of the decision parsing decision tree are marked with predicate sets. These predicates are defined above the current parse tree and can check conditions of at least the following types:
  • the predicates by which the arcs of the decision tree of query parsing are labeled control during the query parsing process the choice of the next vertex of the decision tree (i.e., the choice the next applicable decoder and the element of the current parse tree to which this decoder should be applied).
  • predicates are successively calculated. If for the next arc all the predicates take the true value, then the incoming vertex for this arc becomes the next vertex of the decision tree used to parse the query. This parsing process is performed until the leaf vertex of the decision tree is reached, or until a parsing error is detected (situations where the predicates did not take the true value for any of the arcs of the current vertex).
  • FIG. 7 illustrates an example decision tree for parsing queries.
  • the web application processes information from GET and POST requests according to the standard scheme, except for the situation when the jsonjmport.php script is processed, which processes j son data from the request body.
  • FIG. 8 illustrates a method for constructing a decision parsing decision tree based on a plurality of query parsing trees constructed in the first step of a method for constructing web application functioning models. This method consists of the following steps:
  • FIG. 9 illustrates the above-described table of applicability of decoders to leaf vertices of an auxiliary set of parse trees and the criterion for the prevalence of a set of decoders in some row of such a table.
  • the decision tree for parsing the answers of a web application is constructed in a similar way.
  • the request routing model is designed to match the requests to the web application with the actions of the logic level of the web application functioning that should be performed as a result of the processing of this request by the web application.
  • Various actions of the logic level of the web application functioning are implemented by various request processing functions in the web application, and the choice of this function in the web application is determined by the presence of a given set of query parameters (affecting the routing of the request) and the values of these parameters.
  • the web application parses the request, applies a set of predicate checks to it and selects the desired request processing function (which implements the required action) depending on which predicate takes the true value.
  • FIG. 10 illustrates a method for constructing a query routing model in the form of a set of predicates applied to queries (more precisely, query parsing trees) of a web application in order to identify individual actions of the logic level of the web application functioning. This method includes the following steps:
  • a random set is selected from a given number of parse trees
  • clusters are selected whose size exceeds a predetermined threshold value
  • a predicate is constructed as a conjunction of two types of conditions:
  • conditions of the first type check the presence of a vertex with a given path. These conditions are built for all leaf vertices of the maximum common subtree;
  • conditions of the second type check the value at the vertex with the given path (equality of the value to the constant). These conditions are built for all leaf vertices of the maximum common subtree if all cluster trees have the same common value at a given vertex;
  • a method for constructing a query routing model is performed by the Learning component in a fully automatic mode, without the participation of an operator and / or system administrator.
  • the operator and / or system administrator has the opportunity to further review and edit the constructed set of predicates, for example, to assign each of them a meaningful human-readable name by which a specific action of the logic level of the functioning of the web application is identified.
  • This step is performed solely for the convenience of defining subsequent models for the functioning of the web application (models of usage scenarios and a set of rules for controlling access to the resources and functions of the web application).
  • the model for extracting session and user identifiers from requests and responses of a web application is intended for use in tracking mechanisms of user sessions of a web application.
  • each of the actions of the logic level of the web application functioning is associated with a set of parameters of this action (paths in the tree for parsing requests to the web application or responses of the web application), the values of which contain the identifiers of the session of the web application or the identifier of the user performing this action .
  • Tracking user sessions and actions of the logic level of the web application functioning, the execution of which leads to the initialization or termination of the user session, is important for use in the model of scenarios for using web applications and as service information for identifying requests to static resources of the web application.
  • the model for extracting session and user identifiers is built on the basis of the previously received request routing model and the decision tree for parsing requests and responses.
  • the construction of this model can be done by the operator and or system administrator manually or in an automated mode when interacting with the Learning component.
  • the syntax and semantics models for the parameters of the web application’s actions are designed to identify the action parameters of the logic level of the web application’s functioning, determine the types and ranges of acceptable values for these parameters, and identify the objects of the subject area of the web application.
  • the web application action parameter syntax model is used at the web application protection stage to identify anomalies in the action parameter values, and the parameter semantics model is used to build a web application use case scenario model for determining data dependencies between actions and in the resource access control model for Setting the web application user access rights to the objects of the web application subject area.
  • the parameters of the web application action include the parameters of the requests to the web application identified at the stage of constructing the parse trees, minus the following set of query parameters:
  • the range of valid values for the action parameters determines the rules for checking the value of the parameter during the security phase of the web application. Values of parameters that are not valid for a parameter of this type increase the estimate of the anomaly of the request in accordance with the specified syntax checking rules and semantics of web application action parameters. Thus, at the training stage, for each of the parameters, restrictions on the range of permissible values of this parameter should be determined:
  • one-dimensional and multidimensional models of Gaussian distributions are constructed that describe at least the characteristics of the following parameters: parameter length, number of separate “words”, number of separate characters of various classes (letters, numbers, punctuation characters, other ASCII characters) and the maximum number of consecutive characters from each category;
  • objects of the domain level of the web application are identified, identified by the values of some subsets of the parameters of the actions of the web application.
  • the syntax and semantics models of the web application action parameters are built on the basis of the previously obtained query routing model and the decision parsing decision tree.
  • the construction of a syntactic model can be carried out automatically, based on the data obtained at the stage of collecting training data.
  • the model semantics model is built by the operator and / or system administrator manually or in an automated mode when interacting with the Learning component.
  • the identification of requests to static resources of a web application and the construction of URL patterns of requests to static resources of a web application is performed in order to identify a set of static web application resources in the form of a set of URL request patterns for these resources.
  • This set of request URL patterns is used later in the web application security phase to improve the performance of the Analyzer component.
  • a method for identifying requests for static resources and constructing URL patterns of requests for static resources is illustrated in FIG. 11 and consists of the following main steps:
  • FIG. 12 illustrates a method for obtaining a plurality of URLs of static resources based on an analysis of a plurality of pairs of web application requests and web application responses received during the training data collection step. This method is based on the classification of requests for requests to static or dynamic resources by analyzing the characteristic features of requests and responses of a web application and includes the following main steps:
  • the method builds many resource URL descriptors, filling it with records of newly discovered request URLs, and marks the URL descriptors as static or non-static, depending on the characteristics of the observed URLs of the web application requests and responses of the web application, as well counts the number of unique users who accessed resource at this URL. For each next processed request-response pair, the following steps are performed:
  • the identification of requests to static resources of a web application and the construction of URL request templates for static resources is performed by the Learning component fully automatically, without the participation of an operator and / or system administrator.
  • the scenario of using the web application is designed to model valid scenarios for using the web application in the form of the dependence of some actions of the logic level of the web application on the successful completion of other actions, as well as the possible dependencies of these actions on the data.
  • a state machine mechanism is used, the states of which model the logical states of the web application when interacting with the user, and there are two types of transitions between states:
  • FIG. 13 illustrates an example model for a use case for a web application and a sequence of user actions indicating valid and unacceptable actions depending on the logical state of the usage scenario model.
  • the usage scenario model shown in the example describes a system in which only access to the start page of the web application is possible initially (“View index” action), then after entering credentials (“Password auth” action) and authorization by crypto key (“Tokep auth” action ”) The user gets the opportunity to view data on accounts (the action" View account "), and to perform the action to transfer funds (“ Transfer funds ”) the user also needs to enter a one-time sms code.
  • objects of the domain level of the web application can be distinguished (for example, accounts, user profiles, forum posts, etc.), identifiable as the values of the corresponding parameters of the web application actions.
  • Scenarios for using a web application are automated in an interaction with the Learning component.
  • the model for controlling access to the web application resources is intended for checking the web application user access rights to the requested resources and logical functions of the web application.
  • This model is a set of access control rules, each of which is a set of predicates over the values of the parameters of this action, the logic level of the web application’s functioning and the decision to allow or deny access to the requested resource or logical function.
  • these access control rules can be described in terms of predicates over level objects.
  • the construction of a model for controlling access to web application resources is performed by the operator and / or system administrator manually or partially in an automated manner when interacting with the Learning component.
  • FIG. Figure 14 illustrates the method used by the Learning component at the stage of detecting false positives to automatically detect signature rules for detecting attacks and individual anomaly detection modules that have a high level of false positives, creating log messages about false positives and creating settings that exclude these signature rules from further use at the stage protect web applications. This method is performed by the system completely automatically, without the participation of the operator and / or system administrator.
  • This method uses a lot of requests to the web application as input and information about the triggering of signature rules for detecting attacks and individual anomaly detection modules obtained at the training data collection stage. To automatically detect false positives, a correlation analysis is used. For this, at the first step, the method separates the total time period of the training data collection stage into separate equal time intervals. Then, in the second and third steps of the method, for each of the time intervals, the total number of requests to the web application and the number of times each individual signature rule for detecting attacks and the anomaly detection module for each of the time intervals are calculated.
  • the ranks for these signature rules and modules are constructed, as serial numbers in a sequence ordered by increasing the number of times each of the signature rules or anomaly detection modules are triggered.
  • the method calculates, at predetermined time intervals, the correlation coefficients between the ranks and the number of requests to the web application.
  • n is the number of observations (the number of time intervals)
  • x t is the value of the observed quantity in the ith time interval
  • the values of the time intervals into which the time period for the collection of training data is divided, and the threshold value of the correlation coefficient, were established during preliminary experiments and are part of the settings stored in the database of the Database component. These settings can be changed, if necessary, by the operator and / or system administrator using the Web dashboard component.
  • FIG. 15 illustrates a general method for processing a request for a secure web application during the security phase of a web application in one possible embodiment of the system.
  • Various steps of this method are performed by various modules of the Analyzer Core component after receiving the next request to the web application through the Proxy Adapter or PassiveAdapter module, depending on the version of the system and its location.
  • various models of the functioning of the web application are used, which were built earlier at the stage of training the system.
  • the DecisionTreeParser module parses and parses the HTTP request.
  • the decision tree of query parsing is used.
  • the second step identifies the action of the logic level of the web application and the parameters of this action. This step is performed by the ActionDeterminer module using the web application request routing model.
  • the session and the user who owns this request are identified.
  • This step is performed by the SessionTracker module, which identifies among the request parameters the parameters responsible for identifying the session and user.
  • the fourth step checks the validity of the action from the point of view of the use cases of the web application. This step is performed by the DecisionMaker module using the web application use case scenario model. For valid actions, the fifth step checks the syntax (types and valid values) and semantics of the action parameters and identifies anomalies in the parameter values. This step is performed by the DecisionMaker module using syntax and semantics models of the web application action parameters.
  • the DecisionMaker module checks the access control rules for the web application resources using the set of access control rules created by the operator and / or administrator.
  • the LibinjectionDetector and ModsecurityDetector modules are used, which are responsible for detecting attacks on a web application using the previously configured signature rules.
  • the transition to these steps also occurs if the request cannot be parsed (performed at the first step of the method), and it is impossible to identify the action of the logic level of the web application functioning (performed at the second step of the method).
  • results obtained at the seventh and eighth steps of the method are aggregated together with anomalies detected during the verification of types and values of the action parameters (at the sixth step of the method), forming an integral estimate of the “anomalous” request.
  • the DecisionMaker module decides to classify the request as normal, anomalous, or an attack on a web application, based on an integrated assessment of its anomaly and the results of checking the validity of this action within the framework of the scenario model for using the web application and access control rules. Based on the classification of the request, a decision is made about further processing (sending the request to the protected web application, blocking, issuing the SARTSNA test to the user, etc.) and passing this decision to the Proxy Adapter module (if the system is used as a reverse HTTP proxy server) .
  • Information about the request and the decision made (the request itself and the log message and the detected anomalies and the decision made) are then stored in the Database component database to collect statistics and notify the operator and / or system administrator about incidents.
  • a web application receives a response to a request and parses this response using the DecisionTreeParser module.
  • the ActionStatusDeterminer module determines the result of the action based on the analysis model web application responses.
  • information about the state of the user session is updated from the point of view of the scenario model for using the web application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Техническое решение относится к области обнаружения атак на веб-приложения с помощью позитивных моделей безопасности и построения моделей веб-приложения с помощью методов машинного обучения. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак, включая логические атаки, основанный на автоматическом построении моделей функционирования веб-приложения, в котором осуществляют автоматический сбор обучающих данных о функционировании веб-приложения; формируют по меньшей мере одну модель функционирования веб-приложения посредством разбора и анализа обучающих данных, полученных на предыдущем шаге; выявляют ложные срабатывания для правил обнаружения атак на веб-приложения на основании обучающих данных и сформированных моделей функционирования веб-приложения; включают режим защиты веб-приложения, в котором анализируют новые поступающие запросы к веб-приложению и его ответы, оценивают степень нормальности или аномальности данных запросов, после чего принимают решения по их дальнейшей обработке. Технический результат - повышение производительности интеллектуального сетевого экрана.

Description

СПОСОБ ЗАЩИТЫ ВЕБ-ПРИЛОЖЕНИЙ ПРИ ПОМОЩИ
ИНТЕЛЛЕКТУАЛЬНОГО СЕТЕВОГО ЭКРАНА С ИСПОЛЬЗОВАНИЕМ АВТОМАТИЧЕСКОГО ПОСТРОЕНИЯ МОДЕЛЕЙ ПРИЛОЖЕНИЙ
ОБЛАСТЬ ТЕХНИКИ
Данное техническое решение относится, в общем, к вычислительной области, а в частности к области обнаружения атак на защищаемое веб-приложение с помощью позитивных моделей безопасности и построения моделей функционирования веб- приложения с помощью методов машинного обучения.
УРОВЕНЬ ТЕХНИКИ
В настоящее время веб-приложения автоматизируют сложные и критичные функции, такие как работу на бирже, управление грузовыми перевозками, государственные услуги и т.п. Существующие средства защиты веб-приложений - сетевые экраны уровня веб-приложения (Web Application Firewall, WAF) - не обеспечивают должной защиты от актуальных угроз. Согласно актуальным рекомендациям международной организации OWASP по использованию сетевых экранов уровня веб-приложения, значительная часть современных типов атак на веб-приложения не могут обнаруживаться и блокироваться с помощью существующих средств.
Недостаточные механизмы защиты в современных сетевых (межсетевых) экранах уровня веб-приложения имеют под собой технологические причины. С одной стороны, устаревшими являются представления о веб-приложениях (или, формально, модели веб-приложений), которые используют такие средства. В большинстве средств защиты веб-приложений моделью клиентской части приложения является концепция "HTML- страница со ссылками и формами", а серверная часть описывается как набор статически и динамически исполняемых файлов. С развитием подходов к разработке веб-приложений (MVC, SOA, REST, API-centric) концепция файлов была заменена концепцией обработки запроса по его фрагментам (обычно URL), a HTML- документы уступили место динамическим асинхронным интерфейсам. Помимо этого, увеличивается структурная сложность HTTP-сообщений; для передачи структурированных данных используется вложенная инкапсуляция и кодирование (например, Ьазе64-закодированный массив из JSON-объектов). В результате выразительные средства современных сетевых экранов уровня веб-приложения не позволяют описывать структуру и нормальное поведение современных веб- приложений ни вручную, ни, тем более, автоматически. Создаваемые современными средствами позитивные модели безопасности не эффективны, подвержены обходам и ложным срабатываниям, а синтаксическое разнообразие запросов делает неприменимыми негативные модели безопасности (сигнатурные правила).
С другой стороны, «традиционные» компьютерные атаки постепенно перестают быть актуальными, уступая место сложным логическим уязвимостям, в число которых входят по меньшей мере:
• уязвимости авторизации, позволяющие пользователям получить доступ к данным и функциям веб-приложения в обход правил контроля доступа;
• повышение привилегий за счет манипуляции значений параметров;
· доступ к функциям веб-приложения, не выведенным в пользовательский интерфейс;
• нарушение доступности веб-приложения для других пользователей;
• возможность обхода или злоупотребления правилами предоставления бонусов/скидок;
· атаки на протоколы интеграции веб-приложения со сторонними системами, например, некорректная реализация интеграции с платежными системами. Из уровня техники известен патентный источник информации N°US8051484 «Method and security system for indentifying and blocking web attacks by enforcing read-only parameters)), патентообладатель: Imperva, Inc., дата публикации: 01.11.2011. В данном источнике описываются способы защиты веб-приложений от атак, связанных с подменой злоумышленником значений read-only параметров HTTP-запросов, т.е. таких параметров, для которых разработчиком веб-приложения подразумевается неизменность значений. Техническое решение описывает принципы автоматического выявления таких параметров с помощью эвристических признаков (например, передачи параметров как скрытых полей веб-форм) и статистических (неизменность значений параметра между последовательными запросами и ответами веб- приложения), с последующим контролем неизменности значений read-only параметров на этапе защиты веб-приложения. Таким образом в данном решение описывается только частный случай построения одной из моделей веб-приложения (т.н. «профиля» параметров), однако лишь с точки зрения HTTP-запросов и ответов.
Также известен патентный источник информации US7472413 «Security for WAP servers)), патентообладатель: F5 Networks, Inc., дата публикации: 30.12.2008. В данном техническом решении описывается способ автоматического выявления допустимых последовательностей обращений к ресурсам веб-приложения в виде графа допустимых переходов между его HTML-страницами на основе автоматического обхода веб- приложения специальными инструментальными средствами (веб-краулерами), а также анализа последовательности запросов и ответов из сетевого трафика. Данный способ позволяет построить аналог модели «сценариев использования» веб-приложения, но не в терминах уровня логики функционирования веб-приложения, а лишь в терминах последовательности переходов между HTML-страницами. Построенная таким образом модель «page-flow веб-приложения» пригодна для защиты от некоторых видов атак (например, прямого доступа по ссылке к закрытой части веб-приложения), но не позволяет, например, контролировать права доступа пользователя в терминах объектов предметной области веб-приложения.
Также из уровня техники известен источник информации US20120278851 ((Automated policy builder», патентообладатель: F5 Networks, Inc., дата публикации: 01.11.2012. В данном решении описываются способы автоматического построения таких моделей функционирования веб-приложения, как списки разрешенных URL адресов в веб- приложении, списки допустимых параметров (которые могут быть переданы в запросе к каждому из URL адресов) и диапазоны их допустимых значений. Данные модели (т.н. «профили» веб-приложения) строятся автоматически на основе анализа запросов к веб-приложению и ответов от него и могут быть скорректированы оператором вручную. Кроме этого, описываются принципы определения «стабильности» отдельных элементов построенных профилей (на основе эвристических критериев длительного отсутствия изменений в значениях) или необходимости перестройки «профилей» для отдельных элементов или исключения из обработки отдельных сигнатурных правил с высоким уровнем ложных срабатываний (на основе эвристических правил наблюдения больного числа аномалий с большого числа доверенных IP адресов). Недостатком данных способов является, во-первых, моделирование веб-приложения лишь в терминах HTTP-запросов, и во-вторых, использование эвристических правил с единым набором констант для всех защищаемых веб-приложений без учёта таких характеристик, как, например, относительный объем запросов к веб-приложению за единицу времени.
Основные мировые производители сетевых экранов уровня веб-приложения не имеют технических решений в области обнаружения широкого класса логических атак на защищаемые веб-приложения.
Уровень моделирования основных аспектов функционирования веб-приложения для межсетевых экранов в существующих технических решениях ограничен синтаксисом и семантикой HTTP-запросов к веб-приложению и ответов веб-приложения, а также контролем типов и диапазонов значений параметров HTTP-запросов. Данные модели не позволяют эффективно и с низким уровнем ложных срабатываний обнаруживать логические атаки на веб-приложение.
Также в уровне техники отсутствуют способы автоматического построения моделей уровня логики функционирования веб-приложения с помощью методов машинного обучения.
СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ
Данное техническое решение направлено на устранение недостатков, свойственных решениям, известным из уровня техники.
Технической задачей, решаемой в данном техническом решении, является построение и использование для защиты веб-приложения не только моделей синтаксиса и семантики HTTP-запросов к веб-приложению, но и моделей уровня логики функционирования веб-приложения, включая распознавание действий уровня логики функционирования веб-приложения (схемы маршрутизации запросов в веб- приложении), определение синтаксиса и семантики параметров действий веб- приложения, выявление сценариев использования веб-приложения и правил контроля доступа пользователей к ресурсам и объектам предметной области веб-приложения. Техническим результатом, достигаемым в данном техническом решении, является повышение производительности интеллектуального сетевого экрана.
Также техническим результатом является повышение качества выявления ложных срабатываний сигнатурных правил обнаружения атак и модулей обнаружения аномалий для отдельных типов запросов.
Данные технические результаты достигаются с помощью методов машинного обучения, причем автоматически выявляются запросы к статическим ресурсам веб- приложения и производится построение шаблонов URL адресов данных запросов с целью исключения данных запросов из детального анализа на этапе защиты веб- приложения.
Ключевым отличием предлагаемого технического решения от подходов, применяемых в существующих сетевых экранах уровня веб-приложения, является переход от принципа "разбор запроса до уровня HTTP; один URL - один набор параметров и их моделей" к принципу "глубокий разбор запросов с учетом особенностей приложения, выделение действий уровня логики функционирования веб-приложения и их параметров (при этом критерием классификации может являться не только URL запроса), и создание моделей для параметров действий". Данный подход обеспечивает два преимущества перед существующими решениями для защиты веб-приложений:
• делает возможным обнаружение логических атак на веб-приложения;
• снижает уровень ложных срабатываний сетевого экрана уровня веб- приложения (с -30% до 0.1% и ниже).
Предлагаемое решение представляет собой интеллектуальный сетевой экран для защиты веб-приложений, который осуществляет автоматический сбор обучающих данных и построение моделей функционирования веб-приложения, включая построение моделей синтаксиса и семантики HTTP-запросов к веб-приложению и ответов на них (для последующего разбора HTTP-запросов и ответов), выявление действий уровня логики функционирования веб-приложения (модель маршрутизации запросов), определение наборов параметров и допустимых значений параметров для данных действий (модель параметров действий веб-приложения), и построение моделей для сценариев использования веб-приложения и правил контроля доступа к ресурсам и функциям веб-приложения. Кроме того, интеллектуальный сетевой экран также производит выявление ложных срабатываний (для сигнатурных правил обнаружения атак или отдельных модулей обнаружения аномалий) и выявление запросов к статическим ресурсам веб-приложения с построением шаблонов URL адресов этих запросов.
При этом, по крайней мере, построение моделей синтаксиса и семантики HTTP- запросов и ответов на них, построение модели маршрутизации запросов, выявление запросов к статическим ресурсам веб-приложения (с построением шаблонов URL адресов данных запросов) и выявление ложных срабатываний (сигнатурных правил обнаружения атак или отдельных модулей обнаружения аномалий) производятся с помощью методов машинного обучения (например, посредством иерархической кластеризации) и анализа данных (например, статистического корреляционного анализа). Построение данных моделей, шаблонов URL адресов запросов к статическим ресурсам и списка сигнатурных правил с высоким уровнем ложных срабатываний производится в полностью автоматическом режиме, без участия оператора и\или администратора интеллектуального сетевого экрана. КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Признаки и преимущества настоящего технического решения станут очевидными из приводимого ниже подробного описания и прилагаемых чертежей, на которых:
Ошибка! Источник ссылки не найден, иллюстрирует общую архитектуру системы, реализующей способ защиты веб-приложений при помощи интеллектуального сетевого экрана с использованием автоматического построения моделей приложений. Ошибка! Источник ссылки не найден, иллюстрирует вариант осуществления способа защиты веб-приложений при помощи интеллектуального сетевого экрана с использованием автоматического построения моделей приложений.
Фиг. 3 иллюстрирует способ построения моделей защищаемого веб-приложения в одном из вариантов исполнения способа.
Фиг. 4 иллюстрирует вариант осуществления частичного дерева разбора запроса к веб- приложению.
Фиг. 5 иллюстрирует другой вариант осуществления дерева разбора запроса к веб- приложению.
Фиг. 6 иллюстрирует способ построения дерева разбора запроса.
Фиг. 7 иллюстрирует пример осуществления дерева решений для разбора запросов.
Фиг.8 иллюстрирует способ построения дерева решений для разбора запросов по множеству деревьев разбора запросов.
Фиг. 9 иллюстрирует таблицу применимости декодеров, применяемую в процессе кластеризации деревьев запросов при построении дерева решений для разбора запросов.
Фиг. 10 иллюстрирует способ построения модели маршрутизации запросов веб- приложения.
Фиг. 11 иллюстрирует способ выявления запросов к статическим ресурсам веб- приложения и построения шаблонов URL адресов запросов к статическим ресурсам веб-приложения.
Фиг. 12 иллюстрирует способ поиска множества URL адресов статических ресурсов веб-приложения на основе множества пар запросов к веб-приложению и ответов веб- приложения.
Фиг. 13 иллюстрирует пример осуществления конечного автомата, моделирующего сценарий использования веб-приложения.
Фиг. 14 иллюстрирует способ выявления ложных срабатываний для сигнатурных правил обнаружения атак и отдельных модулей обнаружения аномалий, создания журнальных сообщений о ложных срабатываниях и генерации настроек для исключения данных сигнатурных правил из дальнейшей обработки на этапе защиты веб-приложения.
Фиг. 15 иллюстрирует общий способ обработки единичного запроса к веб- приложению на этапе защиты веб-приложения системой.
ПОДРОБНОЕ ОПИСАНИЕ
Ниже будут описаны понятия и определения, необходимые для подробного раскрытия осуществляемого технического решения.
Данное техническое решение может быть реализовано в виде распределенной компьютерной системы.
В данном решении под системой подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, чётко определённую последовательность операций (действий, инструкций).
Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы).
Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические носители (CD, DVD и т.п.).
Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.
Позитивная модель безопасности (также известны как «белые списки») - модели безопасности, которые в явном виде специфицируют набор разрешенных действий и запрещают все остальные действия (т.е. те действия, которые не входят в список разрешенных).
Логика функционирования веб-приложения - набор решаемых веб-приложением прикладных задач, выраженный в терминах объектов предметной области веб- приложения, действий (логических манипуляций) над ними и ограничениях, отражающих допустимые сценарии использования веб-приложения и права различных категорий его пользователей. Например, веб-приложение, поддерживающее интернет блог, предоставляет пользователем возможности создания, просмотра, редактирования и удаления записей и комментариев к ним - каждая такая возможность представляет собой отдельное действие уровня логики функционирования веб-приложения.
Примерами объектов предметной области веб-приложения являются, например, товары в интернет-магазине, записи в блоге, счёта пользователя в платежных системах и т.п.
Компьютерная атака - целенаправленное несанкционированное воздействие на информацию, на ресурс информационной системы или получение несанкционированного доступа к ним с применением программных или программно- аппаратных средств.
Логическая атака - компьютерная атака на уровень логики функционирования веб- приложения, т.е. такая атака, в ходе которой не происходит нарушений синтаксиса и семантики HTTP-запросов к веб-приложению, но происходит выполнение от лица злоумышленника тех действий уровня логики функционирования веб-приложения, которые не должны быть ему доступны по замыслу разработчиков.
Межсетевой экран (МЭ), брандмауэр, защитная система, сетевой экран, "огненная стена" - система (аппаратная или программная) или комбинация систем, образующая в целях защиты границу между двумя или более сетями, предохраняя от несанкционированного попадания в сеть или предупреждая выход из неё пакетов данных.
Веб-приложение - клиент-серверное приложение, в котором клиентом выступает браузер, а сервером — веб-сервер. Логика веб-приложения распределена между сервером и клиентом, хранение данных осуществляется, преимущественно, на сервере, обмен информацией происходит по сети.
Сбор обучающих данных - в данном техническом решении процесс сбора запросов к веб-приложению, ответов веб-приложения (и, опционально, сообщений о срабатывании сигнатурных правил обнаружения атак) в течении заранее заданного оператором и\или администратором системы временного периода, во время которого функционирование веб-приложения считается «нормальным» (отражает допустимые сценарии использования).
Этап защиты веб-приложения - данный этап реализует режим защиты веб- приложения от возможных атак на него со стороны злоумышленников. Выполнение данного этапа начинается после перевода системы в режим защиты веб-приложения, осуществляемого автоматически после завершения этапа обучения и построения моделей функционирования веб-приложения или по команде оператора и\или администратора системы.
Общая архитектура системы, реализующей предлагаемый способ, проиллюстрирована на Фиг. 1. Система состоит из следующих компонентов:
компонент анализа данных (Analyzer), который предназначен для получения и анализа трафика защищаемого веб-приложения (запросов к веб-приложению и ответов веб- приложения), его анализа с целью выявления атак на веб-приложение (включая атаки уровня логики функционирования веб-приложения) и реагирования на данные атаки, включая блокировку атакующих запросов и\или генерацию и сохранение сообщений об обнаруженных атаках;
компонент хранения данных (Database), который предназначен для долговременного хранения в базе данных разнообразной информации, включая по крайней мере: обучающие данные (запросы к веб-приложению и ответы веб-приложения, собранные на этапе сбора обучающих данных), построенные модели функционирования веб- приложения, журнальные сообщения, сгенерированные в процессе функционирования системы и различные настройки системы;
компонент построения моделей функционирования веб-приложения (Learning), который предназначен для автоматического построения моделей функционирования веб-приложения на основе информации, сохраненной в базе данных компонента Database;
компонент графического интерфейса (Web dashboard), который предназначен для реализации графического интерфейса оператора и\или администратора системы.
Компоненты, используемые в системе, могут быть реализованы с помощью электронных компонент, используемых для создания цифровых интегральных схем. Не ограничиваясь, могут использоваться микросхемы, логика работы которых определяется при изготовлении, или программируемые логические интегральные схемы (ПЛИС), логика работы которых задаётся посредством программирования. Для программирования используются программаторы и отладочные среды, позволяющие задать желаемую структуру цифрового устройства в виде принципиальной электрической схемы или программы на специальных языках описания аппаратуры: Verilog, VHDL, AHDL и др. Альтернативой ПЛИС являются: программируемые логические контроллеры (ПЛК), базовые матричные кристаллы (БМК), требующие заводского производственного процесса для программирования; ASIC — специализированные заказные большие интегральные схемы (БИС), которые при мелкосерийном и единичном производстве существенно дороже. Также компоненты могут быть реализованы с помощью постоянных запоминающих устройств (см. Лебедев О.Н. Микросхемы памяти и их применение. - М.: Радио и связь, 1990. - 160 с; Большие интегральные схемы запоминающих устройств: Справочник/ А.Ю.Горденов и др. - М: Радио и связь, 1990. - 288 с).
Таким образом, реализация всех используемых компонентов достигается стандартными средствами, базирующимися на классических принципах реализации основ вычислительной техники.
Названия компонентов на английском языке предоставлены для более ясного понимания сущности технического решения и не ограничивают сущность или реализацию технического решения.
Компонент Analyzer реализует следующую функциональность:
• захват трафика защищаемого веб-приложения (запросы к веб-приложению и ответы веб-приложения);
• сбор обучающих данных (запросов к веб-приложению и ответов веб- приложения) на этапе обучения системы и их сохранения в базу данных компонента Database;
• сохранение информации о запросах к веб-приложению и ответах веб- приложения в базе данных компонента Database на этапе защиты веб- приложения;
• анализ трафика на этапе защиты веб-приложения, включая классификацию запросов на нормальные или аномальные, в том числе классификацию отдельных аномальных запросов как атак на веб-приложение;
• принятие решений по передаче запроса веб-приложению или его блокировке;
• генерация журнальных сообщений об обнаруженных аномалиях и атаках, и запись данных сообщений в базу данных компонента Database.
Компонент Analyzer состоит, по крайней мере, из трех следующих служебных компонентов:
• компонент активного захвата трафика (HTTP reverse proxy), который реализует логику обратного HTTP прокси для перехвата запросов к защищаемому веб-приложению и ответов от веб-приложения;
• компонент пассивного захвата трафика (Passive HTTP proxy), который реализует функциональность пассивного получения копии трафика между защищаемым веб-приложением и его пользователями через сетевое ответвление (network ТАР); • компонент анализа запросов и ответов веб-приложения и принятия решений (Analyzer Core), который реализует функциональность сбора информации о запросах к веб-приложению и ответов веб-приложения, анализа запросов к веб-приложению с использованием построенных моделей функционирования веб-приложения, классификации запросов на нормальные и аномальные (включая классификацию запроса, как атаки на веб-приложение), и принятие решения по передаче запроса к защищаемому веб-приложению или его блокированию.
Служебный компонент HTTP reverse proxy представляет собой обратный прокси- сервер для перехвата HTTP трафика. В одном из вариантов исполнения и размещения системы предполагается функционирование системы в режиме обратного HTTP прокси. В данном режиме служебный компонент HTTP reverse proxy обеспечивает перехват запросов к защищаемому веб-приложению, передачу информации о данных запросах служебному компоненту Analyzer Core и ожиданию от данного служебного компонента решения по обработке запроса.
В качестве решений по обработке запроса возможны, по крайней мере, передача запроса к защищаемому веб-приложению, либо блокирование и сброс запроса. В одном из вариантов реализации возможно также решение по предоставлению пользователю веб-приложения специального ответа, содержащего проверку посредством теста САРТСНА (Completely Automated Public Turing test to tell Computers and Humans Apart— полностью автоматизированный публичный тест Тьюринга для различения компьютеров и людей). В такой ситуации пользовательский запрос может быть передан защищаемому веб-приложению только после успешного решения теста САРТСНА пользователем веб-приложения.
В одном из вариантов исполнения системы компонент HTTP reverse proxy может также реализовывать логику автоматической классификации запросов на запросы к статическим и динамическим ресурсам веб-приложения. Данным поведением компонента HTTP reverse proxy управляют особые настройки, сформированные в ходе процесса обучения системы компонентом Learning, сохраненные в базе данных компонента Database и переданные компоненту HTTP reverse proxy компонентом Analyzer Core. При классификации поступившего запроса как запроса к статическому ресурсу защищаемого веб-приложения, запрос передается защищаемому веб- приложению без дальнейшей обработки служебным компонентом Analyzer Core, что снижает вычислительную нагрузку. При классификации запроса, как запроса к динамическому ресурсу защищаемого веб-приложения, передача запроса откладывается до принятия служебным компонентом Analyzer Core соответствующего решения по обработке запроса (передача веб-приложению, блокирование или предоставление пользователю теста САРТСНА).
Компонент Passive HTTP sniffer отвечает за захват копии трафика к защищаемому веб- приложению, получаемого с сетевого ответвления. В варианте исполнения системы, предполагающем работу с копией трафика, компонент Passive HTTP sniffer обеспечивает извлечение из копии сетевого трафика потока запросов к защищаемому веб-приложению и ответов от веб-приложения и передачу информации о них компоненту Analyzer Core. В данном варианте исполнения системы для копии сетевого трафика блокировка аномальных (или атакующих) запросов (и ответов веб-сервера на эти запросы) не является возможной, хотя сбор обучающих данных на этапе обучения системы и анализ запросов и ответов на этапе защиты веб-приложения (с генерацией соответствующих журнальных сообщений для оператора и\или администратора системы) остаются доступными.
В одном из вариантов исполнения системы компонент Passive HTTP sniffer может также реализовывать логику автоматической классификации запросов на запросы к статическим и динамическим ресурсам веб-приложения. Данным поведением компонента Passive HTTP sniffer управляют особые настройки, сформированные в ходе процесса обучения системы компонентом Learning, сохраненные в базе данных компонента Database и переданные компоненту Passive HTTP sniffer компонентом Analyzer Core. При классификации поступившего запроса как запроса к статическому ресурсу защищаемого веб-приложения, информация о запросе не передается компоненту Analyzer Core, что снижает вычислительную нагрузку. При классификации запроса, как запроса к динамическому ресурсу защищаемого веб- приложения, информация о запросе передается компоненту Analyzer Core для дальнейшего анализа.
Компонент Analyzer Core обеспечивает анализ запросов к защищаемому веб-серверу и ответов от веб-сервера и принятие решений по обработке запроса на основе результатов анализа. Компонент Analyzer Core состоит из набора модулей, в число которых входят:
• модуль взаимодействия с компонентом активного захвата трафика (Proxy Adapter)— отвечает за взаимодействие со служебным модулем HTTP reverse proxy в части:
о получения от него информации о запросах и ответах веб-приложения; о передачи компоненту HTTP reverse proxy решений по дальнейшей обработке поступившего запроса;
о передачи компоненту HTTP reverse proxy настроек для классификации запросов к защищаемому веб-приложению на запросы к статическим и динамическим ресурсам веб-приложения в одном из возможных вариантов исполнения системы;
• модуль взаимодействия с компонентом пассивного захвата трафика (PassiveAdapter) - отвечает за взаимодействие со служебным модулем Passive HTTP sniffer в части:
о получения от него информации о запросах и ответах веб-приложения; о передачи компоненту Passive HTTP sniffer настроек для классификации запросов к защищаемому веб-приложению на запросы к статическим и динамическим ресурсам веб-приложения в одном из возможных вариантов исполнения системы;
• модуль взаимодействия с компонентом хранения данных (MessageDumper) - отвечает запись в базу данных информации о запросах к веб-приложению и ответов веб-приложения на этапах сбора обучающих данных и защиты веб- приложения, а также за запись журнальных сообщений об обнаруженных аномалиях и\или атаках на веб-приложение;
• модуль разбора HTTP запросов и ответов (DecisionTreeParser) - отвечает за разбор поступающих запросов к веб-приложению и ответов от веб- приложения в соответствии с построенными синтаксическими и структурными моделями разбора HTTP-запросов и ответов веб-приложения;
• модуль распознавания действий уровня логики функционирования веб- приложения (ActionDeterminer) - отвечает за анализ запросов к веб- приложению для идентификации действий уровня логики функционирования веб-приложений, в соответствии с моделью маршрутизации запросов;
• модуль распознавания результата выполнения действия уровня логики функционирования веб-приложения (ActionStatusDeterminer) - отвечает за анализ ответов веб-приложения для идентификации успешности или неуспешности выполнения инициированного ранее действия уровня логики функционирования веб-приложения, в соответствии с моделью маршрутизации запросов в веб-приложении;
• модуль отслеживания сессий (SessionTracker) - отвечает за анализ запросов к веб-приложению и ответов веб-приложения, для отслеживания сессий и пользователей, в соответствии с моделью маршрутизации запросов в веб- приложении и вспомогательных моделей, описывающих признаки успешного и неуспешного выполнения запросов;
• модуль принятия решений по обработке запроса (DecisionMaker) - отвечает за анализ запросов к веб-приложению, выполняя по крайней мере:
о оценку степени нормальности или аномальности запроса на основе построенных моделей синтаксиса и семантики параметров для конкретного действия уровня логики функционирования веб- приложения;
о классификацию запроса на нормальный, аномальный или атаку на веб- приложение на основе оценок аномальности запроса, сгенерированных модулями компонента Analyzer Core и правил оценки аномальности запроса, заданных оператором и\или администратором системы;
о принятие решение по обработке запроса на основе построенных автоматически или сформулированным оператором и\или администратором системы правил контроля доступа и проведенной ранее классификации запроса на нормальный, аномальный или атаку на веб-приложение.
В одном из вариантов исполнения системы компонент Analyzer Core может так же включать модуль обнаружения атак на веб-приложение с помощью инструментального средства ModSecurity (ModsecurityDetector). Данный модуль является средством анализа HTTP-запросов к веб-приложению, основанным на применении набора сигнатурных правил. Данное средство разработано третьей стороной и доступно публично в виде исходных кодов и набора сигнатурных правил. В рамках системы модуль ModsecurityDetector анализирует запросы к защищаемому веб-приложению с помощью набора сигнатурных правил и генерирует журнальные сообщения о срабатывании определенных сигнатур. Данные сообщения могут быть записаны в базу данных компонента Database, а также использоваться компонентом DecisionMaker при классификации запроса.
В одном из вариантов исполнения системы компонент Analyzer Core может так же включать модуль обнаружения атак на веб-приложение с помощью инструментального средства Libinjection (LibinjectionDetector). Данный модуль является средством анализа HTTP-запросов к веб-приложению, основанным на оценке степени аномальности запроса по факту наличия признаков атаки в предварительно разобранном запросе. Данное средство разработано третьей стороной и доступно публично в виде исходных кодов и набора сигнатурных правил. В рамках системы модуль LibinjectionDetector анализирует запросы к защищаемому веб-приложению, осуществляя разбор запроса и поиск в нем признаков атаки, и генерирует журнальные сообщения с оценкой степени аномальности данного запроса. Данные сообщения могут быть записаны в базу данных компонента Database, а также использоваться модулем DecisionMaker при классификации запроса.
В одном из вариантов исполнения системы компонентом Learning может быть выполнен этап выявления ложных срабатываний отдельных сигнатурных правил обнаружения атак, и сформированы настройки для модулей ModsecurityDetector и LibinjectionDetector, которые позволяют исключить данные сигнатурные правила из дальнейшего применения при анализе запросов.
Все модули компонента Analyzer Core обмениваются информацией через общую шину обмена данными, которая может быть реализована различными способами в зависимости от варианта исполнения системы.
Компонент Database представляет собой базу данных, предназначенную для долговременного хранения всей информации, необходимой для функционирования системы. Данная информация включает в себя по крайней мере:
• информацию о характеристиках нормальных запросов к веб-приложению (включая сами HTTP-запросы) и ответов веб-приложения, собранных на этапе обучения системы;
• построенные в результате функционирования компонента Learning модели функционирования веб-приложения, включая модели синтаксиса и семантики HTTP-запросов и различные модели уровня логики функционирования веб-приложения;
• журнальные сообщения об аномалиях и атаках на защищаемое веб- приложение, обнаруженных в процессе функционирования компонента Analyzer, а также сопутствующие им запросы к веб-приложению;
• настройки системы в части правил построения моделей функционирования веб-приложения, правил классификации поступающих запросов на нормальные и аномальные и правил реагирования на обнаруженные аномалии в запросах;
• настройки системы в виде списка сигнатурных правил обнаружения атак с высоким уровнем ложных срабатываний, которые подлежат исключению из обработки на этапе защиты веб-приложения; • разнообразную служебную информацию системы.
В зависимости от варианта воплощения, для реализации компонента Database могут быть выбраны различные варианты СУБД, на основе которых может быть реализован данный компонент, и различные варианты архитектуры компонента Database (например, централизованная или распределенная база данных).
Компонент Learning предназначен для автоматического построения моделей функционирования веб-приложения на основе собранной информации о характеристиках нормальных запросов к веб-приложению и правил построения моделей веб-приложения. Информация о характеристиках нормальных запросов к веб- приложению сохраняется в базе данных компонента Database и обновляются компонентом Analyzer на этапе сбора обучающих данных. Правила построения моделей хранятся в базе данных компонента Database и могут быть добавлены в неё или модифицированы оператором и\или администратором системы с помощью компонента Web dashboard. Процесс построения моделей функционирования веб- приложения может быть запущен автоматически по окончанию временного периода, выделенного на сбор обучающих данных. Построенные компонентом Learning модели функционирования веб-приложения сохраняются далее в базе данных компонента Database.
В одном из вариантов исполнения системы компонент Learning также может включать функциональность выявления ложных срабатываний (сигнатурных правил обнаружения атак или отдельных модулей обнаружения аномалий) при помощи статистических методов. В данном варианте исполнения, компонент Learning использует данные, собранные компонентом Analyzer на этапе сбора обучающих данных и сохраненные в базе данных компонента Database для выявления сигнатурных правил и отдельных модулей обнаружения аномалий, имеющих высокий уровень ложных срабатываний. Также он создает журнальные сообщения о ложных срабатываниях и формирует новые настройки для сигнатурных модулей компонента Analyzer, с помощью которых данные сигнатурные правила исключаются из последующего использования.
Компонент Web dashboard реализует функции графического интерфейса для оператора и\или администратора системы с целью мониторинга обстановки и реагирования на инциденты. Этот компонент предназначен для реализации по меньшей мере следующих функций: • предоставление оператору и\или администратору информации о текущем состоянии защищаемого веб-приложения, включая данные по текущим запросам к веб-приложению;
• уведомление оператора и\или администратора об обнаруженных аномалиях в запросах к защищаемого веб-приложению или атаках на веб-приложение и предпринятых системой действиях;
• просмотр статистической информации по функционированию защищаемого веб-приложения за выбранный временной период в прошлом и просмотр информации о ранее обнаруженных аномалиях в запросах или об атаках на защищаемое веб-приложение;
• модификация существующих правил, управляющих построением моделей веб-приложения, правил классификации запросов к веб-приложению на нормальные и аномальные (включая пометку отдельных запросов как атак на веб-приложение), и правил реагирования на обнаруженные аномальные запросы и атаки, а также создания новых правил указанных видов;
• настройка отдельных параметров функционирования прочих компонентов системы.
Компонент Web dashboard получает всю необходимую информацию от компонента Database. В случае создания оператором и\или администратором новых правил построения моделей, классификации запросов или реагирования на аномалии и атаки, либо модификации существующих правил, данные изменения сохраняются в базу данных компонента Database.
Фиг. 2 иллюстрирует основной способ работы системы в одном из вариантов осуществления. Он состоит из этапа сбора обучающих данных, этапа построения моделей защищаемого веб-приложения, этапа выявления ложных срабатываний и этапа защиты веб-приложения.
На этапе сбора обучающих данных компонентом Analyzer производится сбор запросов к защищаемому веб-приложению и ответов веб-приложения и их запись в базу данных компонента Database. На данном этапе компонентом Analyzer также производится запись в базу данных информации о срабатывании сигнатурных правил, если в состав компонента Analyzer входит по крайней мере один модуль обнаружения атак на веб- приложение, основанный на наборе сигнатурных правил обнаружения.
На этапе построения моделей функционирования веб-приложения компонентом Learning производится построение указанного ранее множества моделей функционирования веб-приложения на основе множества запросов и ответов, собранных на этапе сбора обучающих данных. Построенные модели сохраняются в базе данных компонента Database.
На этапе выявления ложных срабатываний компонентом Learning производится выявление сигнатурных правил обнаружения атак и отдельных модулей обнаружения аномалий, которые имеют высокий уровень ложных срабатываний. Для выявленных сигнатурных правил с высоким уровнем ложных срабатываний компонент Learning генерирует и сохраняет в базе данных настройки для модулей обнаружения атак, использующих сигнатурные правила, с помощью которых сигнатурные правила с высоким уровнем ложных срабатываний исключаются из дальнейшего использования на этапе защиты веб-приложения. Для выявленных ложных срабатываний также создаются журнальные сообщения, позволяющие оператору и\или администратору системы проанализировать причины ложных срабатываний модулей обнаружения аномалий и инициировать этап обучения системы повторно или вручную внести необходимые изменения в построенные модели функционирования веб-приложения.
Наконец на этапе защиты веб-приложения компонент Analyzer получает от компонента Database построенные модели функционирования веб-приложения и использует их для анализа новых поступающих запросов к веб-приложению и его ответов, оценки степени нормальности или аномальности данных запросов и принятия решения по их дальнейшей обработке (блокирование или разрешение запроса).
Компонент Analyzer также использует построенные модели функционирования веб- приложения для настройки служебных компонентов HTTP reverse proxy и Passive HTTP sniffer, чтобы обеспечить передачу для анализа компоненту Analyzer Core только таких запросов (и ответов) веб-приложения, которые являются запросами (и ответами) к динамическим ресурсам защищаемого веб-приложения. При этом анализ запросов к статическим ресурсам веб-приложения (и ответов на эти запросы) на этапе защиты веб-приложения не производится с целью снижения вычислительной сложности и повышения производительности системы.
Фиг. 3 иллюстрирует способ построения моделей функционирования защищаемого веб-приложения. Данный способ исполняется компонентом Learning на основе информации о запросах и ответах веб-приложения, полученной на этапе сбора обучающих данных. Результатами различных шагов этого способа являются построенные модели различных аспектов функционирования защищаемого веб- приложения. Данный способ состоит из следующих основных шагов: • построение деревьев разбора для всех запросов к защищаемому веб- приложению и ответов от веб-приложения;
• построение дерева решений разбора запросов к веб-приложению и дерева решений разбора ответов веб-приложения;
• построение модели маршрутизации запросов (т.е. выявление различных действий уровня логики функционирования веб-приложения);
• построение модели для извлечения идентификаторов сессии и пользователя из запросов и ответов веб-приложения;
• построение моделей синтаксиса и семантики параметров действий уровня логики функционирования веб-приложения;
• выявление запросов к статическим ресурсам веб-приложения и построение шаблонов URL запросов к статическим ресурсам;
• построение модели сценариев использования веб-приложения;
• построение модели для контроля доступа к ресурсам веб-приложения.
В зависимости от варианта исполнения системы, часть моделей функционирования защищаемого веб-приложения строится компонентом Learning в полностью автоматическом режиме, другая часть моделей функционирования защищаемого веб- приложения строится в автоматизированном или ручном режиме, с участием оператора и\или администратора системы. Список шагов способа и соответствующих моделей защищаемого веб-приложения, построение которых производится системой в полностью автоматическом режиме, включает по меньшей мере следующие шаги:
• построение деревьев разбора для всех запросов и ответов;
• построение дерева решений разбора запросов к веб-приложению и дерева решений для разбора ответов веб-приложения;
• построение модели маршрутизации запросов;
• выявление запросов к статическим ресурсам веб-приложения и построение шаблонов URL адресов запросов к статическим ресурсам веб-приложения.
Построенные на этапе обучения системы модели сохраняются в базе данных компонента Database и используются далее на этапе защиты веб-приложения для анализа запросов и ответов веб-приложения. Оператор и\или администратор системы имеет возможность ручного редактирования и настройки всех построенных моделей с помощью использования компонента Web dashboard. Первым шагом, применяемым на этапе построения моделей функционирования веб- приложения, является построение деревьев разбора для всех запросов к защищаемому веб-приложению и ответов от веб-приложения, собранных на этапе сбора обучающих данных. Для создания HTTP-запроса к веб-приложению современные браузеры кодируют структурированные данные, подлежащие передаче, с помощью последовательного применения различных способов кодировки. Деревья разбора моделируют конкретные результаты разбора веб-приложением поступающих к нему HTTP-запросов с помощью применения набора соответствующих декодеров и восстановления исходных структурированных данных. Деревья разбора внутренним представлением HTTP-запросов к веб-приложению и используются в других моделях веб-приложения.
Деревом разбора для запроса называется представление запроса к веб-приложению в виде корневого дерева, однозначным образом отражающего структуру запроса и его содержимое и полученного в результате последовательного применения к запросу и его частям различных функций декодирования данных (например, x-www-form- urlencode, json и т.п.).
Фиг. 4 иллюстрирует процесс применения к строковым данным (в данном примере, query string HTTP-запроса) декодировщика x-ww-form-urlencode. В результате применения данного декодировщика было получено корневое дерево разбора, дуги которого соответствуют именам отдельных параметров query string, а вершины - значениям данных параметров.
Листья частично построенного дерева разбора в свою очередь могут быть структурированными данными, полученными с помощью какого-либо способа кодировки. Применение к ним надлежащего декодера модифицирует частичное дерево, заменяя данную листовую вершину на новое корневое дерево разбора. Данный процесс продолжается до тех пор, пока полученные листовые вершины дерева разбора не оказываются простыми данными (числами, строками и т.п.), к которым более невозможно применение декодеров.
Фиг.5 иллюстрирует дерево разбора HTTP GET запроса, полученное в результате последовательного применения трех декодеров.
Фиг. 6 иллюстрирует способ построения дерева разбора для произвольного запроса к веб-приложению, множество которых было получено на этапе сбора обучающих данных. Для каждого запроса создаётся корневое дерево из единственной листовой вершины, которая добавляется в список для обработки. Предложенный способ далее выбирает одну из корневых вершин для обработки и пытается найти декодер, применение которого к содержимому вершины приводит к успешному разбору и построению дочернего дерева разбора. Данная вершина затем заменяется на найденное дерево и помечается соответствующим примененным декодером. Листовые вершины построенного дерева добавляются в список для дальнейшей обработки. Процесс завершается, когда список вершин для обработки становится пуст.
Для моделирования ответов веб-приложения используется аналогичный механизм деревьев разбора, и аналогичный способ построения деревьев разбора для всех ответов веб-приложения, полученных на этапе сбора обучающих данных.
Различные запросы к веб-приложению (и ответы на них) могут иметь различную внутреннюю структуру. Это означает, что для разных запросов (и ответов) будут построены различные деревья разбора, отличающиеся не только содержимым листовых вершин, но и структурой самого дерева. Для того, чтобы на этапе защиты веб-приложения иметь возможность быстрого получения деревьев разбора для наблюдаемых запросов и ответов веб-приложения, используются дерево решений разбора запросов (и аналогичное дерево решений разбора ответов). Данное дерево моделирует логику разбора запросов защищаемым веб-приложением.
Дерево решений разбора запросов представляет собой корневое дерево, все пути от корня к листьям которого соответствуют одной из возможных цепочек применения декодеров для разбора HTTP-запроса к веб-приложению. Вершины этого дерева размечены парой, состоящей из:
• декодера, который должен быть применен на очередном шаге разбора запроса к одной из листовых вершин текущего дерева разбора;
• и элемента текущего дерева разбора, к которой следует применить данный декодер.
Дуги дерева решений разбора запросов размечены наборами предикатов. Данные предикаты определены над текущим деревом разбора и могут проверять условия по крайней мере следующих видов:
• наличие в текущем дереве разбора пути с заданной меткой;
• совпадение значения листовой вершины по заданному пути в текущем дереве разбора с заданной константой;
• соответствие значения листовой вершины в текущем дереве разбора регулярному выражению из ограниченного предопределенного набора.
Предикаты, которыми размечены дуги дерева решений разбора запросов, управляют в процессе разбора запроса выбором следующей вершины дерева решений (т.е. выбором следующего применяемого декодера и элемента текущего дерева разбора, к которому следует применить данный декодер). Иными словами, в процессе разбора запроса после выбора очередной вершины дерева разбора и применения её декодера для исходящих из этой вершины дуг последовательно производится вычисление предикатов. Если для очередной дуги все предикаты принимают истинное значение, то входящая вершина для данной дуги становится очередной вершиной дерева решений, применяемой для разбора запроса. Данный процесс разбора производится до достижения листовой вершины дерева решений, либо до обнаружения ошибки при разборе (ситуации, когда ни для одной из дуг текущей вершины предикаты не принимали истинного значения).
Фиг. 7 иллюстрирует пример дерева решений для разбора запросов. В приведенном примере веб-приложение обрабатывает информацию из GET и POST запросов по стандартной схеме, кроме ситуации, когда производится обращение к скрипту jsonjmport.php, который обрабатывает j son- данные из тела запроса.
Фиг. 8 иллюстрирует способ построения дерева решений разбора запросов на основе множества деревьев разбора запросов, построенных на первом шаге способа построения моделей функционирования веб-приложения. Данный способ состоит из следующих шагов:
• взять пустое дерево решений с одной корневой вершиной и множество деревьев разбора;
• из исходного множества деревьев разбора построить вспомогательное множество деревьев разбора, соответствующее текущему виду дерева решений;
• если вспомогательное множество деревьев не совпадает с исходным, найти и построить дочерние вершины для текущих листовых вершин дерева решения, для чего выполнить следующие шаги:
о идентифицировать и отсеять псевдослучайные токены во вспомогательных деревьях разбора запросов;
о выполнить кластеризацию вспомогательного множества деревьев разбора по принципу применимости к ним различных декодеров;
о выполнить классификацию построенных кластеров с помощью автоматического построения набора предикатов;
о по построенным наборам предикатов и кластеров вспомогательного набора деревьев разбора модифицировать текущее дерево решений. о идентификация псевдослучайных токенов деревьев разбора важна для того, чтобы выявить и отсеять те элементы дерева разбора запроса, которые не влияют на синтаксический и структурный разбор запроса веб-приложением, а значит не должны использоваться в предикатах дерева решений разбора запроса. Примерами таких псевдослучайных токенов являются по крайней мере:
идентификаторы сессий;
CSRF-токены;
случайные строки, применяемые для предотвращения кэширования данных;
идентификаторы объектов предметной области веб- приложения;
^ временные метки.
Для данных токенов запросов характерны два признака: их наличие в большей части запросов и высокая вариативность значений. Идентификация всех таких токенов и их отсев производятся с помощью следующих шагов способа:
• для каждой листовой вершины вспомогательных деревьев разбора (идентифицируемой по пометкам пути) подсчитывается число деревьев разбора, в которых есть данная вершина;
• для каждой листовой вершины деревьев разбора подсчитывается число уникальных значений, встречающихся в данной вершине;
• заменяются на символ wildcard те листовые вершины, для которых выполнены два условия:
о доля деревьев разбора с данной вершиной превышает заданное пороговое значение;
о количество уникальных значений данной вершины превышает заданное пороговое значение.
Для кластеризации множества деревьев разбора применяется следующие шаги способа:
• построить таблицу, столбцы которой соответствуют всем возможным декодерам, строки - всем существующим путям в текущих вспомогательных деревьях разбора, а в ячейках находятся число вспомогательных деревьев разбора, к листовым вершинам которых по заданному пути применим данный декодер; • найти строки таблицы, где есть преобладающие наборы декодеров, т.е. такие наборы, которые применимы для большей части листовых вершин по заданному пути для вспомогательного множества деревьев разбора;
• для выбранных строк разбить вспомогательное множество деревьев разбора на кластеры, сопоставив отдельный кластер каждому из применимых декодеров.
Фиг. 9 иллюстрирует описанную выше таблицу применимости декодеров к листовым вершинам вспомогательного множества деревьев разбора и критерий преобладания набора декодеров в некоторой строке такой таблицы.
Для классификации построенного множества кластеров вспомогательного множества деревьев разбора применяется существующий алгоритм decision list learning, предложенный Ривестом. Результатом работы этого способа является выделение набора предикатов над элементами текущих вспомогательных деревьев разбора, позволяющих различать различные кластеры между собой.
Последовательность шагов построения вспомогательного множества деревьев решений, идентификации и отсева псевдослучайных токенов, кластеризации вспомогательных деревьев решений и их классификации продолжается до тех пор, пока множество вспомогательных деревьев разбора (получаемое как результат применения к запросам текущего дерева решений) не совпадет с исходным множеством деревьев разбора. Это будет означать, что построенное дерево решений разбора запросов позволяет разобрать любой из запросов, наблюдавшихся на этапе сбора обучающих данных.
Построение дерева решений разбора ответов веб-приложения производится аналогичным образом.
Модель маршрутизации запросов предназначена для того, чтобы сопоставить запросам к веб-приложению действия уровня логики функционирования веб-приложения, которые должны быть выполнены в результате обработки данного запроса веб- приложением. Различные действия уровня логики функционирования веб-приложения реализуются различными функциями обработки запросов в веб-приложении, а выбор данной функции в веб-приложении определяется наличием заданного множества параметров запроса (влияющих на маршрутизацию запроса) и значений данных параметров. В процессе своего функционирования веб-приложение разбирает запрос, применяет к нему набор проверок-предикатов и выбирает нужную функцию обработки запроса (реализующую требуемое действие) в зависимости от того, какой предикат принял истинное значение. Задача построения модели маршрутизации запросов, таким образом сводится к тому, чтобы автоматически, с помощью методов машинного обучения, вычислить данный набор предикатов на основе множества запросов, полученных на этапе сбора обучающих данных. Фиг. 10 иллюстрирует способ построения модели маршрутизации запросов в виде множества предикатов, применяемых к запросам (точнее, деревьям разбора запросов) веб-приложения с целью идентификации отдельных действий уровня логики функционирования веб-приложения. Данный способ включает следующие шаги:
• вначале инициализируется пустое множество предикатов, образующих модель маршрутизации запросов;
• далее итеративно, пока остаются деревья разбора запросов, для которых не применился ни один из построенных предикатов, выполняются следующие шаги:
о среди деревьев разбора, не классифицированных с помощью имеющегося набора предикатов, производится выборка случайного набора из заданного количества деревьев разбора;
о данная выборка деревьев разбора подвергается кластеризации с использованием метрики дистанции, основанной на мерах сходства и различия деревьев разбора;
о из построенного множества кластеров выбираются кластеры, размер которых превышает заданное пороговое значение;
о для каждого из данных кластеров находится максимальное общее поддерево. По данному максимальному общему поддереву строится предикат, как конъюнкция условий двух типов:
условия первого типа проверяют наличие вершины с заданным путем. Данные условия строятся для всех листовых вершин максимального общего поддерева;
условия второго типа проверяют значение в вершине с заданным путем (равенство значения константе). Данные условия строятся для всех листовых вершин максимального общего поддерева, если все деревья кластера имеют одно и то же общее значение в данной вершине;
о осуществляют фильтрацию построенного множества предикатов- кандидатов. В ходе фильтрации из множества предикатов-кандидатов удаляются те предикаты, которые срабатывают на деревьях из других кластеров - таким образом обеспечивается отсутствие пересечений между предикатами;
о успешно прошедшие фильтрацию предикаты-кандидаты добавляются в строящееся множество предикатов модели маршрутизации запросов, и производится новая итерация;
• производится сохранение построенного множества предикатов, которое и является моделью маршрутизации запросов.
Способ построения модели маршрутизации запросов исполняется компонентом Learning в полностью автоматическом режиме, без участия оператора и\или администратора системы. Оператор и\или администратор системы, однако, имеет возможность в дальнейшем просмотреть и отредактировать построенное множество предикатов, например, с целью присвоения каждому из них осмысленного человеко- читаемого названия, по которому идентифицируется конкретное действие уровня логики функционирования веб-приложения. Данный шаг выполняется исключительно для удобства задания последующих моделей функционирования веб-приложения (модели сценариев использования и набора правил контроля доступа к ресурсам и функциям веб-приложения).
Модель для извлечения идентификаторов сессии и пользователя из запросов и ответов веб-приложения предназначена для использования в механизмах отслеживания пользовательских сессий веб-приложения. В рамках данной модели каждому из действий уровня логики функционирования веб-приложения сопоставляется набор параметров данного действия (путей в дереве разбора запросов к веб-приложению или ответов веб-приложения), значения которых содержат идентификаторы сессии веб- приложения или идентификатор пользователя, осуществляющего данное действие. Отслеживание пользовательских сессий и действий уровня логики функционирования веб-приложения, выполнение которых приводит к инициализации или завершению пользовательской сессии, важно для применения в модели сценариев использования веб-приложений и в качестве служебной информации для идентификации запросов к статическим ресурсам веб-приложения.
Модель для извлечения идентификаторов сессии и пользователя строится на основе полученной ранее модели маршрутизации запросов и дерева решений разбора запросов и ответов. Построение этой модели может производиться оператором и или администратором системы вручную или в автоматизированном режиме при взаимодействии с компонентом Learning. Модели синтаксиса и семантики параметров действий веб-приложения предназначены для того, что идентифицировать параметры действий уровня логики функционирования веб-приложения, определить типы и диапазоны допустимых значений для данных параметров и выявить объекты предметной области веб- приложения. Модель синтаксиса параметров действий веб-приложения применяется на этапе защиты веб-приложения для выявления аномалий в значениях параметров действий, а модель семантики параметров используется при построении модели сценариев использования веб-приложения для определения зависимостей по данным между действиями и в модели контроля доступа к ресурсам для задания прав доступа пользователя веб-приложения к объектам предметной области веб-приложения.
К числу параметров действия веб-приложения относятся параметры запросов к веб- приложению, идентифицированные на этапе построения деревьев разбора, за вычетом следующего множества параметров запроса:
• параметров, непосредственно идентифицирующих само действие уровня логики функционирования веб-приложения;
• параметров, идентифицирующих сессию веб-приложения и пользователя веб-приложения;
• части служебных параметров, таких как CSRF-токены и т.п.
При построении модели синтаксиса параметров для каждого из параметров действия определяется его тип и допустимый диапазон значений. В качестве распознаваемых типов могут использоваться, по крайней мере следующие типы:
• нетипизированные строковые данные;
• числовое значение;
• константа или перечислимый тип данных;
• дата и\или время;
• email адрес;
• URL адрес;
• регулярные выражения;
• произвольные текстовые данные.
Диапазон допустимых значений параметров действий определяет правила проверки значения параметра на этапе защиты веб-приложения. Значения параметров, которые не являются допустимыми для параметра данного типа, увеличивают оценку аномальности запроса в соответствии с заданными правилами проверки синтаксиса и семантики параметров действий веб-приложения. Тем самым на этапе обучения для каждого из параметров должны быть определены ограничения на диапазон допустимых значений этого параметра:
• для нетипизированных строковых данных вычисляется длина данных в байтах в виде выборочного среднего и среднеквадратичного отклонения;
• для числовых значений устанавливается, является ли данное число целочисленным или дробным;
• для констант или перечислимых типов данных определяется множество конкретных значений, которые может принимать данный параметр;
• для даты и\или времени определяется допустимый временной интервал, значения из которого может принимать параметр;
• для параметров, содержащих URL адреса, устанавливается допустимая схема URL адреса, допустимость абсолютных или относительных URL адресов и наличие query string части URL адреса;
• для регулярных выражений строятся одномерные и многомерные модели распределений Гаусса, описывающие по крайней мере характеристики следующих параметров: длину параметра, количество отдельных «слов», количество отдельных символов различных классов (букв, цифр, символов пунктуации, прочих ASCII символов) и максимальное количество идущих подряд символов из каждой категории;
• для произвольных текстовых данных ограничений на допустимый диапазон значений не накладывается.
При построении модели семантики параметров выявляются объекты уровня предметной области веб-приложения, идентифицируемые значениями некоторых подмножеств параметров действий веб-приложения.
Модели синтаксиса и семантики параметров действий веб-приложения строятся на основе полученной ранее модели маршрутизации запросов и дерева решений разбора запросов. Построение синтаксической модели может производиться автоматическим образом, на основе данных, полученные на этапе сбора обучающих данных. Построение модели семантики параметров производится оператором и\или администратором системы вручную или в автоматизированном режиме при взаимодействии с компонентом Learning.
Выявление запросов к статическим ресурсам веб-приложения и построение шаблонов URL запросов к статическим ресурсам веб-приложения производится с целью выявить множество статических ресурсов веб-приложения в виде набора шаблонов URL адресов запросов к данным ресурсам. Данное множество шаблонов URL адресов запросов используется далее на этапе защиты веб-приложения для повышения производительности компонента Analyzer. Способ выявления запросов к статическим ресурсам и построения шаблонов URL адресов запросов к статическим ресурса проиллюстрирован на Фиг. 11 и состоит из следующих основных шагов:
• получения множества URL адресов статических ресурсов из множества пар запросов к веб-приложению и ответов веб-приложения на эти запросы;
• токенизации URL адресов статических ресурсов;
• построения щаблонов URL адресов статических ресурсов с помощью иерархической кластеризации;
• сохранения полученного множества шаблонов URL адресов запросов к статическим ресурсам в базе данных компонента Database.
Фиг. 12 иллюстрирует способ получения множества URL адресов статических ресурсов на основе анализа множества пар запросов к веб-приложению и ответов веб- приложения, полученных на этапе сбора обучающих данных. Данный способ основан на классификации запросов на запросы к статическим или динамическим ресурсам с помощью анализа характерных признаков запросов и ответов веб-приложения и включает следующие основные шаги:
• построение пустого множества дескрипторов URL адресов и пустого множества статических URL адресов;
• последовательный просмотр всех пар запросов и ответов веб-приложения, для добавления новых дескрипторов URL адресов или уточнения характеристик построенных дескрипторов;
• просмотр множества построенных дескрипторов URL адресов запросов и добавление во множество статических URL тех URL адресов, которые помечены как статические и для которых счётчик числа уникальных пользователей превышает заданное пороговое значение.
В процессе своей работы способ строит множество дескрипторов URL ресурсов, наполняя его записями о новых обнаруженных URL адресах запросов, и помечает дескрипторы URL как статические или не статические, в зависимости от характеристик наблюдаемых URL запросов к веб-приложению и ответов веб- приложения, а также подсчитывает число уникальных пользователей, обратившихся к ресурсу по данному URL адресу. Для каждой очередной обрабатываемой пары запрос- ответ выполняются следующие шаги:
• найти дескриптор для URL данного запроса или создать новый дескриптор для данного URL;
• для статус-кода ответа веб-приложения, отличного от 304 (требование взять ресурс из кэша браузера) пометить дескриптор как нестатический, если тип или длина тела данных ответа на запрос (content-type и content-length заголовки) отличаются от ранее сохраненных в дескрипторе значений;
• проверить значение заголовка content-type и статус-кода ответа веб-приложения ответу на запрос к статическому ресурсу, пометить дескриптор URL адреса как нестатический в случае недопустимых значений (отличных от 2хх и Зхх);
• подсчитать дисперсию времени обработки запроса (разница между временами запроса и ответа), пометить дескриптор URL адреса как нестатический при превышении дисперсией заданного порогового значения;
• проверить наличие заголовков запроса, которых являются признаками запроса к динамическому ресурсу (заголовок Authorization и т.п.), пометить дескриптор запроса соответствующим образом;
• для дескриптора URL, сохранившего пометку как URL статического ресурса, увеличить число уникальных пользователей, обратившихся к ресурсу, если текущая пара запрос-ответ принадлежит новому пользователю.
Выявление запросов к статическим ресурсам веб-приложения и построение шаблонов URL адресов запросов к статическим ресурсам производится компонентом Learning полностью автоматически, без участия оператора и\или администратора системы. Модель сценариев использования веб-приложения предназначена для моделирования допустимых сценариев использования веб-приложения в виде зависимости одних действий уровня логики функционирования веб-приложения от успешного выполнения других действий, а также возможных зависимостей данных действий по данным. Для моделирования сценариев использования веб-приложения используется механизм конечных автоматов, состояния которого моделируют логические состояния веб-приложения при взаимодействии с пользователем, и существует два типа переходов между состояниями:
• переходы, происходящие при успешном выполнении пользователем некоторого действия уровня логики функционирования веб-приложения;
• переходы, происходящие автоматически, по срабатыванию таймера. Фиг. 13 иллюстрирует пример модели для сценария использования веб-приложения и последовательность действий пользователя с указанием допустимых и не допустимых действий в зависимости от логического состояния модели сценария использования. Показанная в примере модель сценариев использования описывает систему, в которой изначально возможен только доступ к стартовой странице веб-приложения (действие «View index»), затем после ввода учетных данных (действие «Password auth») и авторизации по криптоключу (действие «Токеп auth») пользователь получает возможность просматривать данные о счетах (действие «View account»), а для выполнения действия по переводу средств (« Transfer funds ») пользователю требуется еще и ввести одноразовый sms-код.
Данные модели сценариев использования могут быть заданы в виде правил, описывающих по крайней мере:
• логические состояния веб-приложения в виде разрешенных в данном состоянии действий уровня логики функционирования веб-приложения (или же пререквизитов данных действий);
• правила перехода в логическое состояние в виде успешного выполнения действия уровня логики функционирования веб-приложения;
• правила перехода в предыдущие логические состояния при срабатывании таймера и\или попытки выполнения недопустимых действий.
На этом же уровне могут выделять объекты уровня предметной области веб- приложения (например, счета, профили пользователей, записи на форуме и т.п.), идентифицируемые в виде значений соответствующих параметров действий веб- приложения.
Построение модели сценариев использования веб-приложения производится автоматизированным образом при взаимодействии с компонентом Learning.
Модель для контроля доступа к ресурсам веб-приложения предназначена для проверки прав доступа пользователя веб-приложения к запрошенным ресурсам и логическим функциям веб-приложения. Данная модель представляет собой набор правил контроля доступа, каждое из которых представляет собой набор предикатов над значениями параметров данного действия уровня логики функционирования веб-приложения и решения о разрешении или запрещении доступа к запрошенному ресурсу или логической функции. В одном из вариантов исполнения системы данные правила контроля доступа могут быть описаны в терминах предикатов над объектами уровня предметной области веб-приложения, идентифицированными на этапе построения моделей синтаксиса и семантики параметров действий веб-приложения.
Построение модели для контроля доступа к ресурсам веб-приложения производится оператором и\или администратором системы вручную или частично автоматизированным образом при взаимодействии с компонентом Learning.
Фиг. 14 иллюстрирует способ, применяемый компонентом Learning на этапе выявления ложных срабатываний для автоматического выявления сигнатурных правил обнаружения атак и отдельных модулей обнаружения аномалий, имеющих высокий уровень ложных срабатываний, создания журнальных сообщений о ложных срабатываниях и создания настроек, исключающих данные сигнатурные правила из дальнейшего использования на этапе защиты веб-приложения. Данный способ выполняется системой полностью автоматически, без участия оператора и\или администратора системы.
Данный способ использует в качестве входных данных множество запросов к веб- приложению и информацию о срабатывании сигнатурных правил обнаружения атак и отдельных модулей обнаружения аномалий, полученные на этапе сбора обучающих данных. Для автоматического выявления ложных срабатываний применяется корреляционный анализ. Для этого на первом шаге способ производит разделение общего временного периода этапа сбора обучающих данных на отдельные равные временные интервалы. Далее на втором и третьем шагах способа для каждого из временных интервалов подсчитывается общее число запросов к веб-приложению и число срабатываний каждого отдельного сигнатурного правила обнаружения атак и модуля обнаружения аномалий за каждый из временных интервалов.
На четвертом шаге для каждого из временных интервалов строятся ранги для данных сигнатурных правил и модулей, как порядковые номера в последовательности, упорядоченной по возрастанию числа срабатываний каждого из сигнатурных правил или модулей обнаружения аномалий.
На пятом шаге способ подсчитывает на заданных временных интервалах коэффициенты корреляции между рангами и числом запросов к веб-приложению. Для данного подсчёта применяется ранговый коэффициент корреляции Спирмена, вычисляемый по формуле: р = где * _ среднее значение
Figure imgf000034_0001
последовательности рангов, п - количество наблюдений (число временных интервалов), xt - значение наблюдаемой величины на i-ом временном интервале, а sx = /-^-Σ?=ι(*£ — х)2 - стандартное отклонение наблюдаемой величины. Далее множество сигнатурных правил обнаружения атак и модулей обнаружения аномалий просматривается последовательно, и вычисленное значение коэффициента корреляции сравнивается с пороговым значением. В случае превышения порогового значение создается журнальное сообщение о ложном срабатывании, а для сигнатурных правил обнаружения атак дополнительно производится создание настроек, исключающих дальнейшее применение данного сигнатурного правила.
Наконец, производится сохранение множества созданных настроек и журнальных сообщений в базу данных компонента Database.
Величины временных интервалов, на которые разбивается временной период сбора обучающих данных, и пороговое значение коэффициента корреляции, установлены в ходе предварительных экспериментов и являются частью настроек, сохраняемых в базе данных компонента Database. Данные настройки могут быть при необходимости изменены оператором и\или администратором системы с помощью компонента Web dashboard.
Фиг. 15 иллюстрирует общий способ обработки запроса к защищаемому веб- приложению на этапе защиты веб-приложения в одном из возможных вариантов исполнения системы. Различные шаги этого способа исполняются различными модулями компонента Analyzer Core после получения очередного запроса к веб- приложению через модуль Proxy Adapter или PassiveAdapter, в зависимости от варианта исполнения системы и её размещения. На различных шагах этого способа используются различные модели функционирования веб-приложения, построенные ранее на этапе обучения системы.
На первом шаге модуль DecisionTreeParser производит синтаксический и структурный разбор HTTP-запроса. На данном шаге используется дерево решений разбора запросов. Для успешно разобранных запросов на втором шаге происходит идентификация действия уровня логики функционирования веб-приложения и параметров этого действия. Данный шаг производится модулем ActionDeterminer с помощью модели маршрутизации запросов веб-приложения.
На третьем шаге производится идентификация сессии и пользователя, которым принадлежит данный запрос. Данный шаг выполняется модулем SessionTracker, выявляющим среди параметров запроса параметры, отвечающие за идентификацию сессии и пользователя.
На четвертом шаге проверяется допустимость выполнения действия с точки зрения сценариев использования веб-приложения. Данный шаг выполняется модулем DecisionMaker с использованием модели сценариев использования веб-приложения. Для допустимых действий на пятом шаге производится проверка синтаксиса (типов и допустимых значений) и семантики параметров действия и выявляются аномалии в значениях параметров. Данный шаг производится модулем DecisionMaker с использованием моделей синтаксиса и семантики параметров действий веб- приложения.
На шестом шаге модуль DecisionMaker проверяет правила контроля доступа к ресурсам веб-приложения с помощью сформированных оператором и\или администратором набора правил контроля доступа.
На седьмом и восьмом шагах способа используются модули LibinjectionDetector и ModsecurityDetector, отвечающие за обнаружение атак на веб-приложение с помощью настроенных ранее сигнатурных правил. Переход на данные шаги происходит также в случае невозможности разбора запроса (выполнявшегося на первом шаге способа), и невозможности идентифицировать действие уровня логики функционирования веб- приложения (выполнявшего на втором шаге способа).
Результаты, полученные на седьмом и восьмом шагах способа, агрегируются вместе с аномалиями, обнаруженными при проверке типов и значений параметров действия (на шестом шаге способа), формируя интегральную оценку «аномальности» запроса.
На десятом шаге способа модуль DecisionMaker принимает решение о классификации запроса как нормального, аномального или атаки на веб-приложение, исходя из интегральной оценки его аномальности и результатов проверки допустимости данного действия в рамках модели сценариев использования веб-приложения и правил контроля доступа. На основании классификации запроса происходит принятие решения о дальнейшей обработке (передача запроса защищаемому веб-приложению, блокирование, выдача пользователю теста САРТСНА и т.п.) и передача этого решения модулю Proxy Adapter (если используется вариант размещения системы в виде обратного HTTP прокси сервера).
Информация о запросе и принятом решении (сам запрос и журнальное сообщение и об обнаруженных аномалиях и принятом решении) далее сохраняется в базу данных компонента Database для сбора статистики и уведомления оператора и\или администратора системы об инцидентах.
Если было принято решение о блокировании запроса - способ завершается. В ином случае последовательно выполняются еще четыре шага способа.
Во-первых, происходит получение ответа веб-приложения на запрос и разбор данного ответа модулем DecisionTreeParser. Далее модулем ActionStatusDeterminer производится определение результата выполнения действия на основе модели анализа ответов веб-приложения. И наконец, производится обновление информации о состоянии пользовательской сессии с точки зрения модели сценариев использования веб-приложения. После выполнения этих шагов способ завершается.

Claims

ФОРМУЛА ИЗОБРЕТЕНИЯ
1. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак, включая логические атаки, основанный на автоматическом построении моделей функционирования веб-приложения и включающий в себя следующие шаги:
• осуществляют автоматический сбор обучающих данных о функционировании веб-приложения;
• формируют по меньшей мере одну модель функционирования веб- приложения посредством разбора и анализа обучающих данных, полученных на предыдущем шаге;
• выявляют ложные срабатывания для правил обнаружения атак на веб- приложения на основании обучающих данных и сформированных моделей функционирования веб-приложения;
• включают режим защиты веб-приложения, в котором анализируют новые поступающие запросы к веб-приложению и его ответы, оценивают степень нормальности или аномальности данных запросов, после чего принимают решения по их дальнейшей обработке.
2. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1 , характеризующийся тем, что обучающими данными является множество запросов к веб-приложению и/или множество ответов веб-приложения и/или множество срабатываний правил обнаружения атак на веб-приложения.
3. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что осуществляют автоматический сбор обучающих данных посредством интеллектуального сетевого экрана.
4. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что осуществляют автоматический сбор обучающих данных в течение заранее заданного интервала времени.
5. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что при осуществлении сбора обучающих данных собирают запросы к защищаемому веб-приложению и ответы веб- приложения с последующей их записью в базу данных.
6. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что формируют модель функционирования веб- приложения по окончанию временного периода, выделенного на сбор обучающих данных.
7. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что формируют модель функционирования веб- приложения с помощью методов машинного обучения.
8. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что выявляют ложные срабатывания для правил обнаружения атак на веб-приложения с помощью статистических методов.
9. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что дополнительно создают настройки для исключения правил обнаружения атак с высоким уровнем ложных срабатываний из дальнейшей обработки.
10. Компьютерно-реализуемый способ защиты веб-приложений от различных классов атак по п.1, характеризующийся тем, что в режиме защиты веб-приложения аномальные запросы блокируют.
11. Система защиты веб-приложений от различных классов атак, содержащая следующие компоненты:
• компонент хранения данных, выполненный с возможностью хранения обучающих данных, построенных моделей функционирования веб- приложения, журнальных сообщений, сгенерированных в процессе функционирования системы и различных настроек системы;
• компонент графического интерфейса, предназначенный для реализации графического интерфейса пользователя системы;
• компонент построения моделей функционирования веб-приложения, выполненный с возможностью формирования по меньшей мере одной модели функционирования веб-приложения посредством разбора и анализа обучающих данных;
• компонент анализа данных, выполненный с возможностью получения и анализа трафика защищаемого веб-приложения, его анализа с целью выявления атак на веб-приложение и реагирования на данные атаки, включая блокировку атакующих запросов и\или генерацию и сохранение сообщений об обнаруженных атаках, который включает:
о модуль активного захвата трафика,
о модуль пассивного захвата трафика,
о модуль анализа запросов и ответов веб-приложения и принятия решений.
PCT/RU2017/000194 2017-01-17 2017-03-31 Способ защиты веб-приложений с использованием автоматического построения моделей приложений WO2018135964A1 (ru)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP17892571.5A EP3550789A4 (en) 2017-01-17 2017-03-31 METHOD FOR PROTECTING WEB APPLICATIONS USING AUTOMATIC CONSTRUCTION OF APPLICATION MODELS

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2017101441A RU2659482C1 (ru) 2017-01-17 2017-01-17 Способ защиты веб-приложений при помощи интеллектуального сетевого экрана с использованием автоматического построения моделей приложений
RU2017101441 2017-01-17

Publications (1)

Publication Number Publication Date
WO2018135964A1 true WO2018135964A1 (ru) 2018-07-26

Family

ID=62815758

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2017/000194 WO2018135964A1 (ru) 2017-01-17 2017-03-31 Способ защиты веб-приложений с использованием автоматического построения моделей приложений

Country Status (3)

Country Link
EP (1) EP3550789A4 (ru)
RU (1) RU2659482C1 (ru)
WO (1) WO2018135964A1 (ru)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109978141A (zh) * 2019-03-28 2019-07-05 腾讯科技（深圳）有限公司 神经网络模型训练方法和装置、自然语言处理方法和装置
US20210194852A1 (en) * 2019-12-19 2021-06-24 Radware, Ltd. System and method for analytics based waf service configuration
CN113645238A (zh) * 2021-08-11 2021-11-12 码客工场工业科技(北京)有限公司 一种面向Handle标识体系的DDoS防御方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2716029C1 (ru) * 2019-07-04 2020-03-05 Общество с ограниченной ответственностью «Инлексис» (ООО «Инлексис») Система мониторинга качества и процессов на базе машинного обучения

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7472413B1 (en) 2003-08-11 2008-12-30 F5 Networks, Inc. Security for WAP servers
US8051484B2 (en) 2005-06-14 2011-11-01 Imperva, Inc. Method and security system for indentifying and blocking web attacks by enforcing read-only parameters
US20120110174A1 (en) * 2008-10-21 2012-05-03 Lookout, Inc. System and method for a scanning api
US20120278851A1 (en) 2010-10-29 2012-11-01 F5 Networks, Inc. Automated policy builder
WO2013015691A1 (en) * 2011-07-26 2013-01-31 Security Matters B.V. Method and system for classifying a protocol message in a data communication network
RU2580027C1 (ru) * 2014-10-17 2016-04-10 Закрытое акционерное общество "Лаборатория Касперского" Система и способ формирования правил поиска данных, используемых для фишинга
US20160366160A1 (en) * 2000-09-25 2016-12-15 Blue Coat Systems, Inc. Systems and Methods for Processing Data Flows

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2477929C2 (ru) * 2011-04-19 2013-03-20 Закрытое акционерное общество "Лаборатория Касперского" Система и способ предотвращения инцидентов безопасности на основании рейтингов опасности пользователей
RU123561U1 (ru) * 2012-04-27 2012-12-27 Общество с ограниченной ответственностью "Бизнес Центр "Видео Интернешнл" Интернет-портал с полным циклом автоматизированного размещения рекламы на различных рекламоносителях и автоматизированная система создания, оплаты, проверки и размещения рекламной кампании

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160366160A1 (en) * 2000-09-25 2016-12-15 Blue Coat Systems, Inc. Systems and Methods for Processing Data Flows
US7472413B1 (en) 2003-08-11 2008-12-30 F5 Networks, Inc. Security for WAP servers
US8051484B2 (en) 2005-06-14 2011-11-01 Imperva, Inc. Method and security system for indentifying and blocking web attacks by enforcing read-only parameters
US20120110174A1 (en) * 2008-10-21 2012-05-03 Lookout, Inc. System and method for a scanning api
US20120278851A1 (en) 2010-10-29 2012-11-01 F5 Networks, Inc. Automated policy builder
WO2013015691A1 (en) * 2011-07-26 2013-01-31 Security Matters B.V. Method and system for classifying a protocol message in a data communication network
RU2580027C1 (ru) * 2014-10-17 2016-04-10 Закрытое акционерное общество "Лаборатория Касперского" Система и способ формирования правил поиска данных, используемых для фишинга

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3550789A4

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109978141A (zh) * 2019-03-28 2019-07-05 腾讯科技（深圳）有限公司 神经网络模型训练方法和装置、自然语言处理方法和装置
CN109978141B (zh) * 2019-03-28 2022-11-25 腾讯科技（深圳）有限公司 神经网络模型训练方法和装置、自然语言处理方法和装置
US20210194852A1 (en) * 2019-12-19 2021-06-24 Radware, Ltd. System and method for analytics based waf service configuration
US11991149B2 (en) * 2019-12-19 2024-05-21 Radware, Ltd. System and method for analytics based WAF service configuration
CN113645238A (zh) * 2021-08-11 2021-11-12 码客工场工业科技(北京)有限公司 一种面向Handle标识体系的DDoS防御方法
CN113645238B (zh) * 2021-08-11 2023-04-25 码客工场工业科技(北京)有限公司 一种面向Handle标识体系的DDoS防御方法

Also Published As

Publication number Publication date
EP3550789A1 (en) 2019-10-09
RU2659482C1 (ru) 2018-07-02
EP3550789A4 (en) 2019-12-04

Similar Documents

Publication Publication Date Title
US10560471B2 (en) Detecting web exploit kits by tree-based structural similarity search
CN110855676B (zh) 网络攻击的处理方法、装置及存储介质
CN110881044B (zh) 一种计算机防火墙动态防御安全平台
CN110602029B (zh) 一种用于识别网络攻击的方法和系统
CN109274637B (zh) 确定分布式拒绝服务攻击的系统和方法
Maggi et al. Protecting a moving target: Addressing web application concept drift
Li et al. Block: a black-box approach for detection of state violation attacks towards web applications
Appelt et al. Behind an application firewall, are we safe from SQL injection attacks?
CN103593609B (zh) 一种可信行为识别的方法和装置
RU2659482C1 (ru) Способ защиты веб-приложений при помощи интеллектуального сетевого экрана с использованием автоматического построения моделей приложений
CN101971591A (zh) 分析网址的系统及方法
JP2012527691A (ja) アプリケーションレベルセキュリティのためのシステムおよび方法
Khalaf et al. Web Attack Detection Using the Input Validation Method: DPDA Theory.
CN109768992A (zh) 网页恶意扫描处理方法及装置、终端设备、可读存储介质
CN110602021A (zh) 一种基于http请求行为与业务流程相结合的安全风险值评估方法
Lambert II Security analytics: Using deep learning to detect Cyber Attacks
Crişan et al. Detecting malicious URLs based on machine learning algorithms and word embeddings
Ben Jaballah et al. A grey-box approach for detecting malicious user interactions in web applications
Kakavand et al. O-ADPI: online adaptive deep-packet inspector using Mahalanobis distance map for web service attacks classification
Aliero et al. Review on SQL injection protection methods and tools
US10235450B2 (en) Semantic layer for processing machine data
Liljebjörn et al. Mantis the black-box scanner: Finding XSS vulnerabilities through parse errors
RU2813242C1 (ru) Способ обнаружения фишинговых сайтов и система его реализующая
RU2811375C1 (ru) Система и способ формирования классификатора для обнаружения фишинговых сайтов при помощи хешей объектов DOM
Surendhar et al. Detection of payload injection in Firewall Using Machine Learning

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17892571

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017892571

Country of ref document: EP

Effective date: 20190703

NENP Non-entry into the national phase

Ref country code: DE