July 4, 2017 at 10:00The problem of continuous protection of web applications. View from researchers and operators
Today we have an unusual article. As follows from the title, it is devoted to the problems of continuous protection of web applications and is divided into two parts reflecting two views on the problem: from the position of WAF developers (Andrey Petukhov, SolidLab) and from the point of view of the center for monitoring and countering cyber attacks that uses WAF to provide customer service (@avpavlov, Solar JSOC).
We will start with the developers, and in a week we will give the floor to the WAF operators.
We are from SolidLab. Our main expertise is application security in all its forms - offensive (analysis of the security of applications, infrastructures, processes) and defensive (building SDLC and certain aspects of this - for example, manual code analysis, training courses and seminars, implementation of security tools in general and our WAF in particular).
To begin with, we would like to talk about trends in the world of the development and operation of web applications that define the threat landscape and protection methods. We believe that discussions about SOC, continuous monitoring and WAFs will soon be inseparable from discussions about continuous development and the features of this process for a particular application / service. Let's start with the obvious tendency to shorten the release cycle. Interesting Facts:
Short release cycles lead to a rethinking of the reasons and motives that made it appropriate to use traditional events - attracting external consultants to find shortcomings (no matter what method - the “white” or “black” box), manual testing with your own QA- or security-team: scheme “I checked the release code and live quietly for six months until the next” no longer works. In the development with short release cycles, the listed “traditional” events are already considered more mature: as a source of feedback on the processes and providing them with everything necessary - tools, people, methods, and not as a way to get some protected state of the application and fix it.
Note that the continuity of processes (especially in terms of testing and deployment) implies a transition to a high degree of automation of routine tasks. Automation perfectly helps to reduce the frequency of typical (understandable for all development participants) flaws in the product:
We note right away that modern web platforms and frameworks (RoR, Django, Spring, Struts, ASP.NET MVC, etc.) try to take on themselves, not giving developers a chance to shoot themselves in the foot, implementing, for example, , own protection against CSRF or a template engine based on find / replace. Accordingly, as new web platforms adapt in the future, we can expect a decrease in the probability of introducing flaws in the code that allow for attacks such as CSRF, SQL injection, XSS. What can I say, even most XML parsers today by default prohibit the resolution of external entities (i.e. apply the safe defaults principle).
Not so straightforward from an ideological point of view is the tactics of combating the shortcomings of other types:
For completeness, it is important to mention the options for solving these problems within the framework of sSDLC methods, alternative to monitoring.
Atypical flaws can be eliminated through whateverbox analysis from a third-party organization, carried out with a certain periodicity, or through mass popular continuous testing aka Bug Bounty. The disadvantages of the third type at the assembly stage can be eliminated by implementing an analysis of external dependencies (see Vulners, WhiteSource, OWASP dependency-check), and at the operational stage by performing the same checks with the same tools, but as a separate task and with a higher frequency. My colleagues and I will talk more about defense against attacks through continuous monitoring and response.
From the point of view of managing the development process, the security parameters of the created software / service are the targets to be planned. The tactics for achieving these indicators, in a good way, are determined at the initialization stage of the project (or at the stage of its reform) and depends on the threat model and risk assessment, limitations (budget, time and others), available production resources (qualification, methodological support) and so on Further. Our vision is that properly organized monitoring of the web application during the operation phase will provide not only a reduction in the risks associated with the implementation of threats through the shortcomings of the web application and its environment (which is obvious), but also a reduction in the risks associated with incorrect management decisions, which are accepted during the development process,
In other words, the presence of proper monitoring increases the number of degrees of freedom in determining the tactics for achieving the security parameters of the created software / service at the initial stage.
From the reasoning above it can be seen that, among others, proper monitoring should solve the following key tasks of protecting web applications:
In addition to the listed tasks, which, in our opinion, should be solved by proper monitoring (and by any WAF as the main tool for building such a process), we also offer a list of archive features for WAFs.
Unlike the task of comparing WAFs in general (according to functional or performance criteria) and talking about efficiency in general (more than one benchmark WAFs have not been recognized by the community, everyone has been decently criticized), we want to pay attention to the properties of tools that allow you to evaluate whether this tool is suitable for protecting a specific application. The statement of the problem is precisely this - to evaluate the applicability of WAF for a specific application on a specific technology stack.
WAF must understand the application protocol of the protected application
Here a simple rule applies: if WAF cannot figure out how parameter values are transmitted, it will not be able to detect manipulations with these values (injection / tampering).
By application application protocol we mean:
Thus, the analysis of the protocol of the protected application by WAF is to determine for each HTTP request what function of the application is called or what resource is requested, with what parameters and on whose behalf, if it is a closed zone of the application that is accessible after authentication.
An example of interesting parameter transfer protocols is the following:
If in the first two examples a protocol analysis was required to determine the values of the input parameters, then in applications of this type, WAF must additionally understand what operation or resource is being requested. Note that no one bothers APEX application developers in the parameters x01, x02, ... to transmit, for example, XML / JSON encoded in base64, or, as in the last picture, serialized X-WWW-URLENCODED parameters.
WAF should have granularity in the level of operations of the protected application.
APEX applications perfectly illustrate the following thesis: WAF should apply its mechanisms / policies / rules not with the granularity of HTTP protocol entities (URL sections, headers and their values, parameter names and their values), but with granularity of application functions and their input parameters.
Indeed, for an APEX application, the parameters are x01, x02, etc. will be a transport of values for all its functions, but:
It turns out that from the WAF mechanisms we want the following:
The authors of this article met a situation when User Tracking [1] didn’t work on an APEX application on WAF just because the rules for separating a successful login action, an unsuccessful login action, a logout action, and others actions could not be specified with the expressive means provided — these were regular expressions over the HTTP request fields.
The above considerations are true, of course, not only for APEX applications, but also for various applications with complex routing not based on URLs: XML-RPC, JSON-RPC, SOAP, etc.
WAF should be able to set policies at the level of operations and objects of the protected application
It is no secret that the main methods for detecting attacks on web applications are parsing to detect syntactic anomalies (corresponds to injection attacks) and statistical analysis to detect anomalies associated with too many requests (password / token / OTP selection, dirbasting, enumeration of objects applications - for example, existing users, smart DoS, and so on). Attacks that do not cause syntactic or statistical anomalies are much more difficult to catch - a typical example would be querying foreign objects (the English Insecure Direct Object Reference). Such attacks are often called “logical” or attacks on business logic.
A fair question arises - at what level of abstraction do anomalies occur during attacks of this type?
We believe that the anomalies that occur during attacks on business logic are anomalies in the level of operations and objects of the protected application, which requires understanding the application usage scenarios, the life cycle and belonging of its objects to application users, and calculating data and object dependencies between separate steps one use case or between different use cases, it is possible to identify anomalies that occur during attacks at the logic level.
In our opinion, the prospect for the development of WAFs as monitoring tools is precisely understanding the level of the application subject area, working at the level of operations and objects, building dependencies between them and, as a result, detecting attacks on scripting logic in this subject area.
We will start with the developers, and in a week we will give the floor to the WAF operators.
We are from SolidLab. Our main expertise is application security in all its forms - offensive (analysis of the security of applications, infrastructures, processes) and defensive (building SDLC and certain aspects of this - for example, manual code analysis, training courses and seminars, implementation of security tools in general and our WAF in particular).
To begin with, we would like to talk about trends in the world of the development and operation of web applications that define the threat landscape and protection methods. We believe that discussions about SOC, continuous monitoring and WAFs will soon be inseparable from discussions about continuous development and the features of this process for a particular application / service. Let's start with the obvious tendency to shorten the release cycle. Interesting Facts:
- The tendency to reduce the release cycle of the software precisely as a new trend was noted back in 2001 in an article by Microsoft Research (visionaries?).
- The Wikipedia article on Continuous delivery appeared in December 2011.
- In 2014, the Continuous Delivery Conference appeared.
- In the last 5 years, scientific articles (see Google Scholar) have appeared in large numbers on the study of observed phenomena (for example, “Continuous Software Engineering and Beyond: Trends and Challenges”) with an analysis of their own experience (for example, “Continuous delivery? Easy! Just change everything ( well, maybe it is not that easy) ”).
Short release cycles lead to a rethinking of the reasons and motives that made it appropriate to use traditional events - attracting external consultants to find shortcomings (no matter what method - the “white” or “black” box), manual testing with your own QA- or security-team: scheme “I checked the release code and live quietly for six months until the next” no longer works. In the development with short release cycles, the listed “traditional” events are already considered more mature: as a source of feedback on the processes and providing them with everything necessary - tools, people, methods, and not as a way to get some protected state of the application and fix it.
Note that the continuity of processes (especially in terms of testing and deployment) implies a transition to a high degree of automation of routine tasks. Automation perfectly helps to reduce the frequency of typical (understandable for all development participants) flaws in the product:
- The disadvantages under which the tests were written.
- The disadvantages under which the rules for the static / dynamic analyzer were written.
- Disadvantages that are a consequence of the human factor (automatic preparation of the environment, configuration and deployment): the probability of their introduction is minimized by automation and competent change management in those automation scripts.
We note right away that modern web platforms and frameworks (RoR, Django, Spring, Struts, ASP.NET MVC, etc.) try to take on themselves, not giving developers a chance to shoot themselves in the foot, implementing, for example, , own protection against CSRF or a template engine based on find / replace. Accordingly, as new web platforms adapt in the future, we can expect a decrease in the probability of introducing flaws in the code that allow for attacks such as CSRF, SQL injection, XSS. What can I say, even most XML parsers today by default prohibit the resolution of external entities (i.e. apply the safe defaults principle).
Not so straightforward from an ideological point of view is the tactics of combating the shortcomings of other types:
- Atypical flaws in the logic level in individual modules (functions that the web platform cannot take on). For example, the disadvantages associated with incorrect / insufficient authorization when accessing objects (English Insecure Direct Object Reference).
- Disadvantages that appear at the junction of responsibilities of various groups: for example, developers of various services in microservice architecture, arising in the absence of explicit contracts, or administrators and devops). Examples are deficiencies associated with importing or downloading files (Eng. Insecure File Upload), as well as disadvantages associated with incorrect integration (for example, SSO, payment system, cloud chat).
- Disadvantages associated with using 3rd-party libraries / platforms / frameworks with published vulnerabilities. The considerations include binary libraries, the wrappers over which the application uses, and utilities that run as separate processes (a vivid example would be the vulnerabilities in ImageMagic - CVE-2016-3714, CVE-2016-3715, CVE-2016-3716, CVE -2016-3717, CVE-2016-3718) or ffmpeg. The importance of timely protection against attacks on flaws in 3rd-party components can hardly be overestimated. In 2017, the practical feasibility of massive automated attacks across the entire Internet does not raise questions. Examples are recent raids on Joomla (e.g. CVE-2016-8870 + CVE-2016-8869) or Apache Struts (CVE-2017-5638).
For completeness, it is important to mention the options for solving these problems within the framework of sSDLC methods, alternative to monitoring.
Atypical flaws can be eliminated through whateverbox analysis from a third-party organization, carried out with a certain periodicity, or through mass popular continuous testing aka Bug Bounty. The disadvantages of the third type at the assembly stage can be eliminated by implementing an analysis of external dependencies (see Vulners, WhiteSource, OWASP dependency-check), and at the operational stage by performing the same checks with the same tools, but as a separate task and with a higher frequency. My colleagues and I will talk more about defense against attacks through continuous monitoring and response.
From the point of view of managing the development process, the security parameters of the created software / service are the targets to be planned. The tactics for achieving these indicators, in a good way, are determined at the initialization stage of the project (or at the stage of its reform) and depends on the threat model and risk assessment, limitations (budget, time and others), available production resources (qualification, methodological support) and so on Further. Our vision is that properly organized monitoring of the web application during the operation phase will provide not only a reduction in the risks associated with the implementation of threats through the shortcomings of the web application and its environment (which is obvious), but also a reduction in the risks associated with incorrect management decisions, which are accepted during the development process,
In other words, the presence of proper monitoring increases the number of degrees of freedom in determining the tactics for achieving the security parameters of the created software / service at the initial stage.
From the reasoning above it can be seen that, among others, proper monitoring should solve the following key tasks of protecting web applications:
- Real-time protection against 1-day attacks on application components. The goal is to prevent an attack on a 1-day vulnerability (and preferably on a 0-day) if, for some reason, the attack came before the update.
- Adaptation to constant changes in the application (both functional and technological). The goal is to be able at every moment of time to effectively control client interactions with changed aspects of the application (see attacks, be able to granular block, be able to granularly configure).
- Detection of logical attacks on the application. The goal is to minimize the consequences of atypical (logical) errors that fall into the prod. It is rational to proceed from the assumption that such errors are almost impossible to completely eliminate by automated procedures within the framework of sSDLC, and, therefore, there are two working options: Bug Bounty and monitoring with response.
In addition to the listed tasks, which, in our opinion, should be solved by proper monitoring (and by any WAF as the main tool for building such a process), we also offer a list of archive features for WAFs.
Unlike the task of comparing WAFs in general (according to functional or performance criteria) and talking about efficiency in general (more than one benchmark WAFs have not been recognized by the community, everyone has been decently criticized), we want to pay attention to the properties of tools that allow you to evaluate whether this tool is suitable for protecting a specific application. The statement of the problem is precisely this - to evaluate the applicability of WAF for a specific application on a specific technology stack.
WAF must understand the application protocol of the protected application
Here a simple rule applies: if WAF cannot figure out how parameter values are transmitted, it will not be able to detect manipulations with these values (injection / tampering).
By application application protocol we mean:
- A way to address application functions / resources. In the simplest applications, this is part of the PATH in the URL. Sometimes there are applications where the URL path is always the same (for example, / do), functions are addressed by a parameter of type “action”, and resources are addressed by a parameter of type “page” or “res”. In the general case, a function / resource can be addressed by an arbitrary set of HTTP request attributes.
- A method of transmitting input parameters that parameterize application functions. Note that the specification of the HTTP protocol does not limit the imagination of web developers in choosing a method of transporting the necessary data through the structure of an HTTP request.
Thus, the analysis of the protocol of the protected application by WAF is to determine for each HTTP request what function of the application is called or what resource is requested, with what parameters and on whose behalf, if it is a closed zone of the application that is accessible after authentication.
An example of interesting parameter transfer protocols is the following:
- 3D-Secure. At one of the protocol steps, encapsulation is as follows: a POST request with the content type application / x-www-form-urlencoded arrives at the server, there is a PaReq parameter in the request body. The PaReq parameter is an XML document compressed using the DEFLATE algorithm, then encoded in Base64 and URL encoded. Accordingly, real application parameters are passed in the tags and attributes of this XML document. If WAF cannot reveal such a “nesting doll” and apply analysis policies to parameters inside XML (and / or validate its structure), then WAF essentially works in Fail Open mode. Other examples in the same series are numerous XML in JSON and vice versa, of course, not without the help of packaging in BASE64.
- Google Web Toolkit and other protocols using native serialization (not JSON / XML / YAML / ...). Instead of a thousand words, one example request:
Accordingly, if WAF cannot obtain the final parameter values from which the protected application is operating, then WAF does not work. Note that there are a decent number of ways to serialize binary objects (and you can also gash your own!). - Oracle Application Express (APEX). APEX application URLs look something like this:
http://apex.app:8090/apex/f?p=30:180:3426793174520701::::P180_ARTICLE_ID:5024
POST requests in the URL part are similar, and the parameters are transmitted in the body (x-www-urlencoded), but the names, regardless of the operation being called, are the same: x01 = val1 & x02 = val2 ... etc. Here is an example request:
If in the first two examples a protocol analysis was required to determine the values of the input parameters, then in applications of this type, WAF must additionally understand what operation or resource is being requested. Note that no one bothers APEX application developers in the parameters x01, x02, ... to transmit, for example, XML / JSON encoded in base64, or, as in the last picture, serialized X-WWW-URLENCODED parameters.
WAF should have granularity in the level of operations of the protected application.
APEX applications perfectly illustrate the following thesis: WAF should apply its mechanisms / policies / rules not with the granularity of HTTP protocol entities (URL sections, headers and their values, parameter names and their values), but with granularity of application functions and their input parameters.
Indeed, for an APEX application, the parameters are x01, x02, etc. will be a transport of values for all its functions, but:
- The encapsulation of the values of these parameters can be different (see x01 values in the screenshots above).
- As a result, the types, ranges of values and semantics of these parameters for each application function will also differ.
It turns out that from the WAF mechanisms we want the following:
- The subsystem for constructing and applying positive models should build not one general positive model based on all observed values of the parameter x01, but N models according to the number of application functions taking this parameter.
- The signature analysis subsystem should apply to the parameter x01 not the same set of signatures, but K sets (K < N) depending on the wishes of the operator to cover the x01 values for actions or their groups with signatures.
- If the operator wants to configure some additional rule for parameter x01 (for example, suppressing false positives), then he should be able to choose the scope of this rule not in terms of the HTTP protocol (regular expression over the URL, for example), but again in in terms of application functions that accept x01 (for example, apply in the registration function, but not in the password reset function).
The authors of this article met a situation when User Tracking [1] didn’t work on an APEX application on WAF just because the rules for separating a successful login action, an unsuccessful login action, a logout action, and others actions could not be specified with the expressive means provided — these were regular expressions over the HTTP request fields.
The above considerations are true, of course, not only for APEX applications, but also for various applications with complex routing not based on URLs: XML-RPC, JSON-RPC, SOAP, etc.
WAF should be able to set policies at the level of operations and objects of the protected application
It is no secret that the main methods for detecting attacks on web applications are parsing to detect syntactic anomalies (corresponds to injection attacks) and statistical analysis to detect anomalies associated with too many requests (password / token / OTP selection, dirbasting, enumeration of objects applications - for example, existing users, smart DoS, and so on). Attacks that do not cause syntactic or statistical anomalies are much more difficult to catch - a typical example would be querying foreign objects (the English Insecure Direct Object Reference). Such attacks are often called “logical” or attacks on business logic.
A fair question arises - at what level of abstraction do anomalies occur during attacks of this type?
We believe that the anomalies that occur during attacks on business logic are anomalies in the level of operations and objects of the protected application, which requires understanding the application usage scenarios, the life cycle and belonging of its objects to application users, and calculating data and object dependencies between separate steps one use case or between different use cases, it is possible to identify anomalies that occur during attacks at the logic level.
In our opinion, the prospect for the development of WAFs as monitoring tools is precisely understanding the level of the application subject area, working at the level of operations and objects, building dependencies between them and, as a result, detecting attacks on scripting logic in this subject area.
- The User Tracking mechanism allows you to associate requests sent by users of the application after authentication with their logins. To configure this mechanism, tools usually require criteria for a successful login, an unsuccessful login, and criteria for invalidating a session (timeout for inactivity if available, new login under the same user, sending a logout request to a given URL, etc.).
- The picture before kata was taken from gamer.ru