Detection of cross-site scripting attacks using deep learning models

Abstract

A web server can detect XSS attacks in requests received for servicing by a web app. One or more deep learning models can be trained to output a probability score indicating a likelihood that a particular parameter in a received request is malicious. The web server can classify the parameter as suspect (likely malicious) or not, based on the probability score(s) of the deep learning model(s). Where two or more different deep learning models are used, a voting scheme can be employed to determine whether to classify the parameter as suspect. A request can be sanitized by removing or modifying any suspect parameters prior to routing the request to the web app.

Description

DETECTION OF CROSS-SITE SCRIPTING ATTACKS USING DEEP LEARNING MODELSCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 520,307, filed August 17, 2023, the disclosure of which is incorporated herein by reference.BACKGROUND

[0002] This disclosure relates generally to detection of malicious computer code and in particular to detection of cross-site scripting (XSS) attacks using deep learning models.

[0003] Web-based applications, or “web apps,” are application programs stored on server systems and delivered to clients via a web browser interface based on HTML and scripting languages. To interact with a web app, the client sends requests to the server, which executes the request by providing webpage content to the client. This content may include executable scripts (written in scripting languages such as JavaScript, ActionScript, SQL, or the like) that are provided by the server to the client and executed by the client; such scripts are referred to as “client-side” scripts. In some instances, a client-side script may include a remote, or “cross-site,” script that may send information to (or retrieve data or instructions from) a server other than the server that hosts the web app. Including such scripts in a web app can enable more dynamic and / or context-sensitive behavior.

[0004] However, allowing cross-site scripts can render a client vulnerable to cross-site scripting attacks, also referred to as “XSS attacks.” In an XSS attack, an attacker inserts malicious content into the payload of a request that is delivered to the server, such as a request to add information to a record in a database maintained at the server that may later be retrieved by other clients. The malicious content can be, for example, a malicious command string or a reference (e.g., URL) to a malicious script. The attacker intends that the server will store the information, including the malicious content, in the database and subsequently provide the malicious content to unsuspecting clients in response to future requests. When an unwitting client retrieves and processes the malicious content, the script will be executed,resulting in malicious behavior at the client side. Examples of malicious behavior that can be implemented via XSS attack include causing clients to download keystroke loggers, which can be used to collect sensitive information such as passwords or credit card data; redirecting a client browser to a malicious website (where, for instance, the user of the client may be prompted to enter personal information into a fake form); launching browser-based exploits; obtaining browser cookies that may provide login access to various websites; and so on.

[0005] In efforts to prevent XSS attacks, various countermeasures have been deployed. For instance, a server can apply predefined rules to sanitize URLs or other payloads received from clients, e.g., by replacing special characters with corresponding escape codes or limiting use of HTML tags. On the client side, scripts can be disabled. While effective at preventing XSS attacks, such brute-force measures may also result in limiting the functionality of the web app. Another approach to XSS threat detection is based on maintaining a database of known XSS attack payloads and using pattern matching to detect and reject suspicious payloads while accepting other payloads. However, attackers can thwart pattern matching by creating new XSS attack payloads. Improved techniques for detecting and blocking XSS attacks are therefore desirable.SUMMARY

[0006] Certain embodiments disclosed herein relate to server-side detection of XSS attacks in requests sent to a web server for servicing by a web app. The web server can perform threat detection (e.g., in a middleware layer) on received requests, to identify parameters in the request that may be malicious. Specifically, one or more deep learning models can be trained to output a probability score indicating likelihood that a particular parameter is malicious. The web server can classify the parameter as suspect (likely malicious) or not, based on the probability score(s) of the deep learning model(s). In some embodiments, two or more different deep learning models can each be separately trained on a dataset, and a voting scheme can be used to determine whether to classify the parameter as suspect. The request can be sanitized by removing or modifying any suspect parameters, then forwarded to the web app.

[0007] Certain embodiments relate to methods for processing requests at a web server. Such methods can include: receiving, at a web server, a request from a client, the request including a payload directed to a web application hosted by the web server; extracting, by the web server, a parameter from the payload; providing, by the web server, the parameter to oneor more deep learning models that have been trained to provide respective probability scores indicating a probability that the parameter is malicious; receiving, by the web server, one or more respective probability scores from the one or more deep learning models; determining, by the web server and based on the one or more respective probability scores, whether the parameter is a suspect parameter; in response to determining that the parameter is a suspect parameter: performing, by the web server, a sanitization operation on the request to produce a sanitized request, the sanitization operation including removing the suspect parameter; and sending, by the web server, the sanitized request to the web application; and in response to determining that the parameter is not a suspect parameter, sending, by the web server, the request including the parameter to the web application.

[0008] Various deep learning models and combinations of models can be used. For example, the one or more deep learning models can include a first deep learning model that includes a feedback connection and a second deep learning model that does not include a feedback connection. The first model can be a model that incorporates feedback paths, such as a long short-term memory (LSTM) model, while the second model can be a feed-forward model, such as a multilayer perceptron model.

[0009] In embodiments where multiple models are used, determining whether the parameter is a suspect parameter can include applying voting logic, wherein the respective probability score of each deep learning model is compared to a model-specific threshold to determine a vote from each deep learning model.

[0010] In these and other embodiments, determining whether the parameter is a suspect parameter can include: determining whether a first probability score from the first deep learning model exceeds a first threshold; determining whether a second probability score from the second deep learning model exceeds a second threshold; responsive to determining that the first probability score exceeds the first threshold and the second probability score exceeds the second threshold, determining to treat the parameter as malicious; responsive to determining that the first probability score does not exceed the first threshold and the second probability score does not exceed the second threshold, determining to not treat the parameter as malicious; and responsive to all other cases: calculating a net probability score based on the first probability score, the second probability score, the first threshold, and the second threshold; and determining whether to treat the parameter as malicious based on the net probability score.

[0011] In these and other embodiments, the web server can hose a plurality of web applications, and the one or more deep learning models can be trained across all of the web applications.

[0012] Certain embodiments relate to computer systems that can include a network interface, a memory, and a processing subsystem coupled to the network interface and configured to execute a plurality of web apps. The processing subsystem can be further configured to execute: an interface layer process to receive requests directed to the web apps from a plurality of clients via the network interface, at least one of the requests including an input payload, and to extract one or more parameters from the input payload; a threat analysis process to analyze the one or more parameters using one or more trained deep learning models that generate respective probability scores indicating a probability that each of the one or more parameters is malicious; a decision logic process to receive the respective probability scores from the one or more trained deep learning models and to determine, based on the respective probability scores, whether the input payload includes at least one suspect parameter; a sanitization process to perform a sanitization operation on the input payload to produce a sanitized payload in response to the decision logic process determining that the input payload includes at least one suspect parameter; and a routing process to route an output to a destination one of the web apps, wherein the output includes the sanitized payload in the event that the input payload includes at least one suspect parameter and wherein the output includes the input payload in the event that the input payload includes no suspect parameters.

[0013] In some embodiments, the one or more trained deep learning models can include at least two different deep learning models. Each of the at least two different deep learning models can be separately trained using supervised learning with known malicious payloads and known benign payloads.

[0014] In these and other embodiments, the sanitization operation can include removing the at least one suspect parameter and / or replacing one or more of the at least one suspect parameter with a benign parameter.

[0015] In these and other embodiments, the one or more trained deep learning models can include a plurality of deep learning models, and the decision logic process can include voting logic.

[0016] Certain embodiments relate to computer-readable storage media having stored therein program code instructions. When executed by a processor in a computer system, the program code instructions can cause the processor to perform a method comprising: receiving a request from a client, the request including a payload; extracting a parameter from the payload; providing the parameter to one or more deep learning models that have been trained to provide respective probability scores indicating a probability that the parameter is malicious; receiving one or more respective probability scores from the one or more deep learning models; determining, based on the one or more respective probability scores, whether the parameter is a suspect parameter; in response to determining that the parameter is a suspect parameter: performing a sanitization operation on the request to produce a sanitized request, the sanitization operation including removing the suspect parameter; and sending the sanitized request to a web application; and in response to determining that the parameter is not a suspect parameter, sending the request including the parameter to the web application.

[0017] In some embodiments, the one or more deep learning models can include a first deep learning model that includes a feedback connection and a second deep learning model that does not include a feedback connection. For example, the first deep learning model can be a long short-term memory (LSTM) model, and the second deep learning model can be a multilayer perceptron model.

[0018] In these and other embodiments, determining whether to treat the parameter as malicious can include: determining whether a first probability score from the first deep learning model exceeds a first threshold; determining whether a second probability score from the second deep learning model exceeds a second threshold; responsive to determining that the first probability score exceeds the first threshold and the second probability score exceeds the second threshold, determining to treat the parameter as malicious; responsive to determining that the first probability score does not exceed the first threshold and the second probability score does not exceed the second threshold, determining to not treat the parameter as malicious; and responsive to all other cases: calculating a net probability score based on the first probability score, the second probability score, the first threshold, and the second threshold; and determining whether to treat the parameter as malicious based on the net probability score.

[0019] In these and other embodiments, the computer system can host a plurality of web applications, and the one or more deep learning models can be trained across all of the web applications.

[0020] In these and other embodiments, the sanitization operation can include removing the suspect parameter and / or replacing the suspect parameter with a benign parameter.

[0021] The following detailed description, together with the accompanying drawings, will provide a better understanding of the nature and advantages of the claimed invention.BRIEF DESCRIPTION OF THE DRAWINGS

[0022] FIG. 1 shows an operating environment for detection of cross-site scripting (XSS) attacks according to some embodiments.

[0023] FIG. 2 shows a simplified block diagram of XSS attack detection logic according to some embodiments.

[0024] FIG. 3 shows a flow diagram of a process for detecting and sanitizing requests containing malicious parameters according to some embodiments.

[0025] FIG. 4 is a flow diagram of a voting logic process according to some embodiments.TERMS

[0026] The following terms may be used herein.

[0027] A “computer system” refers generally to a device or apparatus that is capable of executing program code (also referred to as “instructions”). A computer system can include a processor and a memory, as well as other components such as user interfaces that enable human interaction with the computer system and / or communication interfaces that enable computer systems to exchange information-bearing signals with other computer systems.

[0028] A “processor” may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to achieve a desired function. The processor may include a CPU that comprises at least one high-speed data processor adequate to execute program components for executing user and / or system generated requests. The CPU may be a microprocessor such as AMD’s Athlon, Duron and / or Opteron; IBM and / or Motorola’s PowerPC; IBM’s and Sony’s Cell processor; Intel’s Celeron, Itanium, Pentium, Xenon, and / or Xscale; and / or the like processor(s). A processorcan also include one or more co-processors that operate under control of a CPU to perform specific tasks; examples include graphics processors, neural processors, and the like.

[0029] A “server computer,” or “server,” may refer to a computer or cluster of computers. A server computer may be a powerful computing system, such as a large mainframe. Server computers can also include minicomputer clusters or a group of servers functioning as a unit. In one example, a server computer can include a database server coupled to a web server. In another example, a server computer can include a collection of processors, a communication interface that receives requests to execute jobs using the processors, and a control system that assigns jobs to specific processors. A server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing requests from one or more client computers.

[0030] A “client computer,” or “client,” may refer to a computer or cluster of computers that receives some service from a server computer (or another computing system). The client computer may access this service via a communication network such as the Internet or any other appropriate communication network. A client computer may make requests to server computers including requests for data or requests to execute a job (or program). As some examples, a client computer can send a request to a server to process a batch of transaction data, a request to modify content of a database maintained at the server (e.g., adding or updating database records), or a request to retrieve data from a database maintained at the server. A client computer may comprise one or more computational apparatuses and may use a variety of computing structures, arrangements, and compilations for performing its functions, including requesting and receiving data or services from server computers.

[0031] A “web app” may refer to an application program that is implemented using a web browser interface, with a client sending HTTP (hypertext transfer protocol) requests to a server that hosts the web app. The server receives the HTTP requests and executes application-specific code to generate responses. The HTTP requests can include URLs, instructions, parameters, and the like and can include structured data (e.g., in JSON, XML, or other syntax).

[0032] A “web server” may refer to a server that hosts one or more web apps. A web server can have an “interface layer” that receives requests from clients and transmits responses to clients and a “backend” that executes one or more web apps. The interface layer can direct requests to the backend for processing. One or more “middleware” layers can beprovided between the interface layer and the backend. A middleware layer can support services common across web apps, including security-related services such as user authentication and threat detection.

[0033] An “XSS attack,” or “cross-site scripting attack,” may refer to an attack in which a malicious URL is provided to a server for subsequent delivery to one or more clients. A “malicious URL” can include any HTTP request that causes execution of a malicious script and / or redirection to a malicious site. An “attacker” may refer to an entity that attempts an XSS attack.

[0034] “Malicious” is used herein to refer to scripts, URLs, or other code objects (or components thereof, such as parameters) that are designed to cause a client computer that receives the object to execute an operation that may compromise information security (e.g., by revealing user data to an attacker) or adversely affect operation of the client computer, generally before the user becomes aware that the operation is occurring. “Benign” is used herein to refer generally to scripts, URLs, or other code objects that are not malicious. The terms “Suspect” and “safe” are used herein to refer to determinations made by an automated process designed to detect malicious parameters, examples of which are described below. A “suspect” parameter is one that the process determines should be treated as malicious, and a “safe” parameter is one that the process determines should be treated as benign.

[0035] “Sanitizing” a request may refer to modifying a request to remove suspect portions, e.g., by replacing one or more parameters (which may be a character or a specific sequence of characters) in the request with known non-malicious parameters and / or removing one or more parameters from the request.

[0036] A “machine learning model” may refer to a file, program, software executable, instruction set, etc., that has been “trained” to recognize patterns or make predictions. For example, a machine learning model can take transaction data records as an input, and classify each transaction data record as corresponding to a legitimate transaction or a fraudulent transaction. As another example, a machine learning model can take weather data as an input and predict if it will rain later in the week. A machine learning model can be trained using “training data” (e.g., to identify patterns in the training data) and then apply this training when it is used for its intended purpose. A machine learning model may be defined by “model parameters,” which can comprise numerical values that define how the machine learning model performs its function. Training a machine learning model can comprise aniterative process used to determine a set of model parameters that achieve the best performance for the model.

[0037] A “multi-layer perceptron” may refer to a machine learning model based on a feedforward neural network in which each node receives multiple inputs, applies a weighting function, and generates an output according to an activation function, such as ReLU (Rectified Linear Unit) or sigmoid. The model can be trained to make binary or probabilistic classification decisions on input objects using suitably labeled training data. The trainable model parameters include the weights at each node.

[0038] “LSTM,” or “Long short-term memory” may refer to a machine learning model that includes feedback as well as feed-forward connections.DETAILED DESCRIPTION

[0039] The following description of exemplary embodiments is presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the claimed embodiments to the precise form described, and persons skilled in the art will appreciate that many modifications and variations are possible. The embodiments have been chosen and described in order to best explain their principles and practical applications to thereby enable others skilled in the art to best make and use various embodiments and with various modifications as are suited to the particular use contemplated.System Overview

[0040] FIG. 1 shows an operating environment 100 for detection of cross-site scripting (XSS) attacks according to some embodiments. A web server 102, which can be a server computer system, communicates with various client computer systems 104 via a network 106 (e.g., the internet). Web server 102 hosts one or more web apps 110. Web apps 110 can include any application program that provides a browser-based interface to one or more client computer systems (also referred to as clients) 104. For example, a web app 110 may provide clients 104 with access to data stored in a database 130. By sending appropriate requests to web server 102, a client 104 can retrieve data from database 130 and / or add to or modify data in database 130. Numerous examples of web apps are known in the art, and embodiments described herein can be used in connection with any web app or any combination of web apps that may be hosted by a server such as web server 102.

[0041] In a cross-site scripting (XSS) attack, an attacker using a first client 104 can send a request that includes a malicious payload to be added to a record in database 130. Subsequently, when another client 104 retrieves the data record from database 130, the malicious payload can be delivered to the other client 104, which can become a victim of the XSS attack. Depending on the particular content of the malicious payload, the victim client may engage in various undesirable behaviors. For instance, the client may display a pop-up with malicious links; redirect a browser to a spoofed (or otherwise malicious) website that enables the attacker to obtain client data, e.g., via a spoofed form; install a keylogger or other spy ware; etc. According to various embodiments described herein, web server 102 can detect malicious payloads in received requests and can sanitize the malicious payload (e.g., by removing suspect parameters) prior to delivering the requests to web apps 110. In this manner, XSS attacks can be prevented.

[0042] In some embodiments, web server 102 can be implemented with multiple software layers, including interface layer 112, middleware layer 114, and backend layer 116. Some or all of the software layers of web server 102 can be implemented using web server software such as the Apache Software Foundation’s open-source Apache software, Microsoft’s Internet Information Service for Windows (IIS) software, or any other appropriate software. Backend layer 116 can execute web apps 110. Depending on implementation, web apps 110 can include “first-party” apps developed and maintained by the same entity responsible for web server 102 and / or “third-party” apps developed by other entities and hosted on web server 102.

[0043] Interface layer 112 can manage communication with clients 104, including a TCP / IP stack and the like. For instance, interface layer 112 can receive requests from clients 104 and route each request, via middleware layer 114, to the appropriate web app 110. Interface layer 112 can also direct responses generated by web apps 110 to the requesting clients 104.

[0044] Middleware layer 114 can provide services to facilitate operation of web apps 110, including security-related services such as user authentication and threat detection. According to some embodiments, middleware layer 114 can implement XSS attack detection logic 120 to detect and block malicious content that may be contained within a request to a web app 110. In some embodiments, XSS attack detection logic 120 can identify specific parameters in a request as being suspect (that is, possibly or probably malicious) and cansanitize requests, e.g., by removing suspect parameters while allowing the rest of the request to proceed to web app 110. In this manner, XSS attack detection logic 120 can prevent XSS attacks. For instance, XSS attack detection logic 120 can prevent malicious content from being stored in database 130, thereby preventing the malicious content from being retrieved by clients 104. Example implementations of XSS attack detection logic 120 are described below.

[0045] A computer system such as web server 102 or client 104 can include a plurality of components or subsystems such as processors, memory systems, communication interfaces and so on, which can be connected together by external interfaces or by an internal interface (e.g., a system bus). In some embodiments, computer systems, subsystems, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another computer a server, where each can be part of a same computer system or different computer systems. A client and a server can each include multiple systems, subsystems, or components. Computer systems can be implemented in a variety of form factors and devices ranging from server farms to desktop or laptop computers to special purpose devices such as point-of-sale (POS) terminals to mobile devices such as smart phones, tablets, or wearable devices. In some embodiments, a computer system includes a single computer apparatus, where the subsystems can be components of the computer apparatus. In other embodiments, a computer system can include multiple computer apparatuses, each being a subsystem, with internal components.XSS Attack Detection Logic

[0046] According to some embodiments, middleware implemented in a web server such as web server 102 of FIG. 1 can include XSS attack detection logic 120, which can detect suspect parameters (that is, parameters that may be part of an XSS attack or otherwise malicious in nature) in payloads of received requests and, when a suspect parameter is detected, sanitize the request (e.g., by removing or replacing the suspect parameter) before passing the request through to the backend web apps.

[0047] FIG. 2 shows a simplified block diagram of XSS attack detection logic 200 according to some embodiments. XSS attack detection logic 200 can be implemented, for example, in a middleware layer of a web server such as web server 102 of FIG. 1. XSS attack detection logic 200 can include a data preprocessing module 202, a deep-learningbased XSS threat analysis module 204, decision logic module 206, sanitizer module 208, androuting logic module 210. The various modules can be implemented using computer- readable program code and executed as processes in an appropriate processing subsystem, which may include one or more microprocessors. In some embodiments, special-purpose or custom processors or other logic circuits may be used to implement all or part of some or all of the modules.

[0048] In operation, XSS attack detection logic 200 receives an input 220 that can include an XSS payload. Depending on implementation, input 220 can include a complete request received from a client or just a “payload” portion of the request. As used herein, the payload of a request can include any data that a client provides to be stored by a web app for later retrieval by a client (which can be the same client or a different client) or any other data that can be used to initiate an XSS attack.

[0049] Data preprocessing module 202 can perform initial processing on input 220. For instance, data preprocessing module 202 can extract one or more parameters from input 220. The parameters can include tokens such as characters or character strings that represent objects or constructs such as URLs, tags, commands, regular expressions, or the like. In some embodiments, data preprocessing module 202 can generate word vectors or the like to represent the parameters. Such word vectors can be generated using trained language models (e.g., word embeddings) or other techniques as desired. Accordingly, data preprocessing module 202 can produce a representation of one or more parameters 222, e.g., as a sparse matrix (or vector, which can be regarded as a one-dimensional matrix) or other format appropriate for input to threat analysis module 204.

[0050] Threat analysis module 204 can apply one or more pre-trained deep learning models 230 to parameters 222 to determine a probability that one or more of parameters 222 is malicious in nature (meaning that the parameter could be part of an XSS attack). Where multiple parameters 222 are extracted from a single request, deep learning models 230 can asses the parameters separately and / or jointly.

[0051] Deep learning models 230 can include any number (one or more) of separately trained deep learning models. The deep learning models can be classifier-type models that distinguish between two classes of input, in this case “malicious” inputs that correspond to XSS attacks and “benign,” or non-malicious, inputs that do not correspond to XSS attacks. In some embodiments, multiple different types of deep learning models can be used in parallel. For example, a first deep learning model can be a multilayer perceptron model or other feed-forward neural network, while a second deep learning model can be a long short-term memory model (LSTM) or other network that incorporates feedback as well as feed-forward connections. As another example, one deep learning model can take a single parameter 222 as input (and can be applied separately to each parameter 222 extracted from a request) while another deep learning model can take all parameters 222 extracted from a request as input (and can be applied to the combination of parameters). Each deep learning model 230 can output a probability score 224. In some embodiments, each probability score 224 can be a number (e.g., normalized to the range from 0 to 1) indicating a probability that the parameter 222 is malicious. If multiple parameters are extracted from a single request, each deep learning model 230 can provide a probability score 224 for each parameter, or a deep learning model 230 can be trained to provide a single probability score 224 based on all of the parameters in a request payload. Accordingly, the number of probability scores 224 produced for a given request or payload depends on the number of parameters 222, the number of deep learning models 230, and whether each deep learning model 230 operates on individual parameters extracted from a payload or jointly on all of the parameters extracted from the payload. In some embodiments where multiple deep learning models 230 are used, ensemble machine learning techniques that combine outputs of multiple classifiers (which can include weak classifiers) to provide a stronger classifier, can be applied to learn an optimal combination of the outputs of the deep learning models 230. Examples of ensemble techniques include gradient booster, AdaBoost, and the like. The ensemble output is a combined probability score 224, which can be provided in addition to or instead of probability scores from individual deep learning models 230.

[0052] Different types of deep learning models may be more or less responsive to different indicia of maliciousness. Accordingly, applying multiple deep learning models of different types (e.g., models with and without feedback), rather than just one model, can reduce the likelihood that a malicious payload remains undetected. As one example, some embodiments can use two deep learning models 230. The first model can be a multilayer perceptron model. For instance, the multilayer perceptron can have two hidden layers and 512 units of outputs, with ReLU as the activation function. The second model can be an LSTM. For instance, the LSTM can have an embedding layer with 128 dimensions and an equal number of features as the input dataset, with the final output layer using a sigmoid activation function. Given a parameter 222, each deep learning model can generate a probability score 224 that is provided to decision logic module 206. Many other implementations are possible, includingdifferent configurations of the models and / or other types and combinations of classifier models such as transformer models, decision-tree models, random forest models, and so on.

[0053] Prior to deployment in XSS attack detection logic 200, deep learning models 230 can be trained to distinguish malicious from non-malicious parameters in requests to web servers. Training of a machine learning model involves optimizing internal parameters of the model, such as the weights for each node. A standard approach is to iteratively process data samples through the model and adjust the weights (or other parameters of the model), with the goal of minimizing a loss function that characterizes a difference between the output of the network for a given input and an expected result determined from a source other than the network. Loss functions can be selected based in part on the particular model. For instance, for a multi-layer perceptron or LSTM, binary-cross entropy can be used. Optimization of loss functions can proceed using various techniques, including, for example, Adams optimization. In “supervised” learning, the expected result is a ground truth result established by labeling of the data samples. For instance, human annotators can assign labels to individual data samples. In some instances, an automated process can assign the labels, e.g., based on the source of the data sample. The labeled data can be separated into training samples and testing samples, e.g., in a 70:30 ratio. Training typically occurs across multiple “epochs,” where each epoch corresponds to a pass through the training sample set.Adjustment to weights (or other parameters of the model) can occur multiple times during an epoch; for instance, the training data can be divided into “batches” or “mini-batches” and weight adjustment can occur after each batch or mini-batch. Aspects of machine learning modules and training that are relevant to understanding the present disclosure are described herein; any other aspects can be modified as desired.

[0054] For training of a given deep learning model 230, data samples representing both malicious and benign (non-malicious) payloads are used. Examples of malicious payloads can be obtained from publicly-available XSS attack data sources such as the Exploit Database (at www.exploit-db.com), GitHub, etc. In some embodiments, examples of malicious payloads or parameters can be extracted from articles reporting new XSS attacks. Extraction of the examples can be based on automated analysis of the text using a word bag, TF-IDF (Term Frequency - Inverse Document Frequency) analysis, or the like. Examples of benign payloads or parameters can be extracted from server logs and / or existing tools for generating test data for various web apps. In some embodiments, XSS attack detection logic 200 is agnostic to the particular web app to which a particular request is directed. Accordingly, thedata samples used for training of deep learning models 230 can include requests associated with a variety of different web apps. In embodiments where multiple different machine learning models are to be used, the same data samples can be provided to each model. The split into training and testing samples can be the same for all models (e.g., where ensemble learning is applied) or different for different models.

[0055] After training using the training samples, the testing samples can be used to assess performance of the trained machine learning model. More specifically, each testing sample can be input to the trained model, which produces an output that can be compared to the ground-truth label assigned to the sample. Performance of the model can be characterized using various metrics such as accuracy, precision, receiver operating curve (and area under the curve), recall, and Fl score. Such metrics can be used to guide design of the model (e.g., number of layers, number of nodes in the layers, training parameters such as learning rate) toward an optimal configuration.

[0056] In some embodiments, training of deep learning models 230 can be conducted on an ongoing basis. That is, after initial training and deployment in XSS attack detection logic 200, deep learning models 230 can be updated periodically or continually by performing additional training using updated (or new) training sets. Such training sets can reflect newly discovered XSS attacks and / or new examples of benign payloads.

[0057] Decision logic module 206 can receive the probability score(s) 224 for each parameter from threat analysis module 204 and can use the probability score(s) 224 to determine whether the parameter is “suspect” (meaning that the parameter will be treated as malicious) or “safe” (meaning that the parameter will be treated as benign). As noted above, probability score(s) 224 can be generated for each parameter extracted from input 220. For a given parameter, probability score(s) 224 can include a score provided by each deep learning model 230 and / or an ensemble score from a combination of multiple deep learning models 230. Based on probability score(s) 224, decision logic module 206 can determine whether the parameter is or is not suspect. For instance, given a single probability score, a threshold can be applied, with the parameter being designated as suspect if the probability score is above the threshold and safe (or non-suspect) if the probability score is below the threshold. In an ideal case, all malicious parameters are designated as suspect and all benign (non- malicious) parameters are designated as safe; however, in practice, this ideal may not be realized. For attack prevention, false positives (benign parameters that are designated assuspect) are generally preferable to false negatives (malicious parameters that are designated as safe), and the threshold can be selected based on avoiding false negatives. Where multiple probability scores are available for the same parameter, decision logic module 206 can implement various decision rules, examples of which are described below.

[0058] In instances where decision logic module 206 detects one or more suspect parameters, the input (or payload) can be provided to sanitizer module 208, together with information identifying the suspect parameters. Sanitizer module 208 can implement a rulebased sanitization procedure to remove suspect parameters from requests. For instance, a suspect parameter can simply be removed. In some embodiments, if removing the suspect parameter results in an improperly formed input to the web app, sanitizer module 208 can insert a benign string that results in properly formed input. As another example, when a suspect parameter is removed, sanitizer module 208 can insert a placeholder string indicating that a parameter has been removed. (Processing of the placeholder string can be handled by the web app that ultimately receives the request.)

[0059] Routing logic module 210 can produce an output 228 that includes a “trusted” XSS payload. For instance, if decision logic module 206 determines that input 220 includes at least one suspect parameter, then routing logic module 210 can replace the payload of input 220 with sanitized payload 226 in output 228. If decision logic module 206 determines that input 220 includes no suspect parameters, then routing logic module 210 can pass through input 220 as output 228. In some embodiments, routing logic module 210 can route output 228 as a request to the destination web app. If desired, additional processing may be performed on output 228 before delivering the request to the destination web app.

[0060] In some embodiments, all requests received at the web server pass through XSS attack detection logic 200. If desired, prefiltering can be implemented, allowing certain requests to bypass threat analysis module 204 and decision logic module 206. For example, there may be some requests that, by their nature, cannot be used to initiate an XSS attack, and such requests need not be analyzed for XSS threat. In some embodiments, such prefiltering can be implemented in data preprocessing module 202.Detection of XSS Attacks

[0061] FIG. 3 shows a flow diagram of a process 300 for detecting and sanitizing requests containing malicious parameters according to some embodiments. Process 300 can beimplemented using XSS attack detection logic 200 or in other implementations in various computer systems. In various embodiments, process 300 can be implemented in a web app or in middleware in a server of the kind described above that hosts one or more web apps.

[0062] Process 300 can begin when a request is received from a client for processing by a web app. The request can be, for instance, an HTTP request including a URL and one or more parameters, such as data values to be stored in a database by the web app. It is assumed that the request might (or might not) contain one or more malicious parameters (e.g., parameters that might cause a client that retrieves the stored data values to execute a malicious script).

[0063] At block 304, the request can be processed to extract parameters. For instance, as described above, tokens (e.g., characters or particular character strings) within the payload of a request can be extracted and analyzed to identify parameters (which can include tokens such as characters or character strings that represent objects or constructs such as URLs, tags, commands, regular expressions, or the like). In some embodiments, data preprocessing module 202 can generate word vectors or the like to represent various parameters.

[0064] At block 306, the parameters can be input to one or more trained deep learning models. A variety of models can be used, including any of the examples described above. Any number of deep learning models can be provided, and different models can be of different types. For instance, one model can define a feedforward network such as a multilayer perceptron while another model can incorporate both feedforward and feedback paths, such as an LSTM model. Each model can produce a probability score for each parameter that is input, where the probability score indicates a likelihood that the parameter is malicious.

[0065] At block 308, the probability score(s) can be received from the deep learning model(s). For instance, each model can provide a score for each parameter. In some embodiments, at least one model can provide a score for each parameter while at least one other model provides a score for the request or payload as a whole.

[0066] At block 310, a determination can be made as to whether one or more parameters of the request is suspect, e.g., using decision logic module 206 described above. Where only one probability score is available for a parameter, decision logic module 206 can apply a threshold to that score and determine that the parameter is suspect if the score exceeds the threshold; if the score is below the threshold, the parameter would not be suspect. Wheremultiple probability scores are available, decision logic module 206 can implement rules based on the multiple scores. One option is to compute an average (which can be a weighted average) of the scores and apply a threshold to the result. However, averaging may lose information such as the relative confidence of different models.

[0067] Another approach uses voting logic, in which each model’s output is compared to a threshold (which can be different for different models) to determine a “vote” from each model. The votes can be tallied, and the final decision as to whether the parameter is suspect can be based on the tally and a decision rule. Various decision rules can be implemented. For instance, in some embodiments, a majority vote may determine whether a parameter is suspect or not. In other embodiments, a parameter can be treated as suspect if any one model indicates that the parameter is suspect. More complex decision rules can also be implemented.

[0068] By way of example, FIG. 4 is a flow diagram of a voting logic process 400 according to some embodiments. Process 400 can be implemented, e.g., at block 310 of process 300. It is assumed that at least two deep learning models have been used to generate probability scores indicating a likelihood that a parameter is malicious. Process 400 can begin with a voting procedure in which each model’s score is counted as a “vote” for either suspect or safe (i.e., non-suspect). For instance, at block 402, counters for “suspect” and “safe” outcomes can be initialized, e.g., to zero. At block 404, a model is selected, and the probability score output from the selected model can be compared to a threshold for that model. As noted above, different models may have different assigned thresholds, and thresholds can be selected, e.g., to minimize false negatives in the final decision. In this example, it is assumed that scores over the threshold indicate a suspect parameter while scores below the threshold indicate a safe parameter. Accordingly, if, at block 406, the probability score is over the threshold, then at block 408, the “suspect” counter is incremented; otherwise, at block 410, the “safe” counter is incremented. At block 412, if more models remain to be considered, process 400 can return to block 404 to select another model, compare that model’s output to the appropriate threshold, and increment one counter or the other.

[0069] After all models have been accounted for, at block 414, process 400 can determine whether a consensus is present. In some embodiments, a consensus can be defined as a majority vote for either suspect or safe (e.g., if the “suspect” counter has a higher value thanthe “safe” counter, then the parameter is suspect; if the “safe” counter has a higher value than the “suspect” counter, then the parameter is safe). It should be noted that in embodiments with an even number of models, a tie is possible, and ties may be treated as absence of consensus. Other definitions of consensus can also be used, such as unanimous agreement (where one counter or the other is zero) or the parameter is suspect unless a supermajority vote for safe is present. (Supermajority can be defined e.g., as corresponding to 60% or two out of three models or some other level between 50%+ 1 and unanimity). If a consensus is present, then at block 416, the parameter can be designated as suspect or safe (non-suspect) according to the consensus.

[0070] If, at block 414, a consensus is not present, additional computations may be performed to determine whether the parameter is suspect. For instance, a confidence score can be defined for each model, e.g., based on how far the probability score is from the threshold for that model. At block 418, a weighted vote tally based on the confidence scores can be computed. The weight for each vote can be based on the confidence score. For instance, in the case of two models, if one model outputs a probability score well above the threshold for that model (a result indicating a suspect parameter with “high” confidence) while the other model outputs a probability score just below the threshold for that model (a result indicating a safe parameter, but with “low” confidence), then at block 418, the vote for “suspect” would outweigh the vote for “safe.” At block 420, the parameter can be designated as suspect or safe based on the weighted tally.

[0071] Process 400 is illustrative, and other decision logic processes can be used to determine whether parameters are suspect based on outputs from multiple deep learning models. As just one example, some deep learning models may output a binary classification decision and a confidence level. For models of this type, confidence levels can be used to weight the initial vote. As noted above, false positives (safe parameters classified as suspect) may be preferred over false negatives (malicious parameters classified as non-suspect), and the decision logic may be optimized to minimize false negatives. For any given request, process 400 can be applied to each parameter extracted from the request or to all of the parameters j ointly .

[0072] Referring again to FIG. 3, if, at block 312, no parameters have been designated as suspect, then at block 314, the original request (including the payload) can be routed to the web app to which it was originally directed. If, at block 312, one or more parameters havebeen designated as suspect, then at block 316, the request can be sanitized, e.g., using sanitizer module 208. As described above, sanitizing a request can include removing suspect parameters and / or replacing suspect parameters with benign strings. At block 318, the sanitized request can be sent to the web app to which it was originally directed. Depending on implementation, process 300 might or might not notify the web app that sanitization has occurred.Additional Embodiments

[0073] While the invention has been described with reference to specific embodiments, those skilled in the art will appreciate that variations and modifications are possible. For instance, different machine learning models can be used. Any number and combination of machine learning models can be used in combination with each other. In examples described above, probability scores can be defined based on probability of a parameter or payload being malicious, with higher score corresponding to greater probability that the parameter or payload is malicious. If desired, probability scores can be defined based on the probability of a parameter or payload being non-malicious (with higher score corresponds to lower probability that the parameter or payload is malicious). Thresholds and tests for determining whether a parameter is suspect can be set appropriately for any given definition of a probability score.

[0074] It should be understood that the XSS attack detection techniques described herein can be combined with other techniques for detecting and preventing XSS attacks. Multiple layers of protection can be implemented. For instance, requests that have been passed through detection and sanitization processes as described herein can be subject to further processing at the web app layer or at other layers. Thus, for instance, if a particular web app developer chooses to impose rule-based sanitization (e.g., disallowing HTML <script> tag or replacing specific characters in request payloads with escape sequences), the developer can do so.

[0075] Further, embodiments are not limited to middleware in a web server. For example, XSS attack detection and sanitization processes as described herein can be implemented within a web app or at the client side (if the client has sufficient computational resources).

[0076] All processes described herein are also illustrative and can be modified. Operations can be performed in a different order from that described, to the extent that logic permits;operations described above may be omitted or combined; and operations not expressly described above may be added.

[0077] It should be understood that any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g., an application specific integrated circuit or field programmable gate array) and / or using computer software with a generally programmable processor in a modular or integrated manner. As used herein a processor includes a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and / or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.

[0078] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable storage medium, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable storage medium may be any combination of one or more such storage devices, and suitable media may be packaged with a compatible device. Any such computer readable storage medium may reside on or within a single computer product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network.

[0079] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable transmission medium according to an embodiment of the present invention may be created using a data signal encoded with such programs, e.g., to download via the internet.

[0080] Any of the methods described herein may be totally or partially performed with a computer system including one or more processors, which can be configured to perform the steps, e.g., by providing suitable program code for execution by the processors. Thus,embodiments can involve computer systems configured to perform the steps of any of the methods described herein, potentially with different components performing a respective steps or a respective group of steps. Although presented as numbered steps, steps of methods herein can be performed at a same time or in a different order. Additionally, portions of these steps may be used with portions of other steps from other methods. Also, all or portions of a step may be optional. Additionally, and of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps.

[0081] While various components are described herein with reference to particular blocks, it is to be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. The blocks need not correspond to physically distinct components, and the same physical components can be used to implement aspects of multiple blocks. Components described as dedicated or fixed- function circuits can be configured to perform operations by providing a suitable arrangement of circuit components (e.g., logic gates, registers, switches, etc.); automated design tools can be used to generate appropriate arrangements of circuit components implementing operations described herein. Components described as processors or microprocessors can be configured to perform operations described herein by providing suitable program code. Various blocks might or might not be reconfigurable depending on how the initial configuration is obtained. Embodiments of the present invention can be realized in a variety of apparatus including electronic devices implemented using a combination of circuitry and software.

[0082] A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. The use of “or” is intended to mean an “inclusive or,” and not an “exclusive or” unless specifically indicated to the contrary.

[0083] All patents, patent applications, publications and description mentioned herein are incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

[0084] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of patent protection should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the following claims along with their full scope or equivalents.

Claims

WHAT IS CLAIMED IS:

1. A method for processing requests at a web server, the method comprising: receiving, at the web server, a request from a client, the request including a payload directed to a web application hosted by the web server; extracting, by the web server, a parameter from the payload; providing, by the web server, the parameter to one or more deep learning models that have been trained to provide respective probability scores indicating a probability that the parameter is malicious; receiving, by the web server, one or more respective probability scores from the one or more deep learning models; determining, by the web server and based on the one or more respective probability scores, whether the parameter is a suspect parameter; in response to determining that the parameter is a suspect parameter: performing, by the web server, a sanitization operation on the request to produce a sanitized request, the sanitization operation including removing the suspect parameter; and sending, by the web server, the sanitized request to the web application; and in response to determining that the parameter is not a suspect parameter, sending, by the web server, the request including the parameter to the web application.

2. The method of claim 1 wherein the one or more deep learning models include a first deep learning model that includes a feedback connection and a second deep learning model that does not include a feedback connection.

3. The method of claim 2 wherein the first deep learning model is a long short-term memory (LSTM) model.

4. The method of claim 3 wherein the second deep learning model is a multilayer perceptron model.

5. The method of claim 2 wherein determining whether the parameter is a suspect parameter includes applying voting logic, wherein the respective probability scorefrom each deep learning model is compared to a model-specific threshold to determine a vote from each deep learning model.

6. The method of claim 2 wherein determining whether the parameter is a suspect parameter includes: determining whether a first probability score from the first deep learning model exceeds a first threshold; determining whether a second probability score from the second deep learning model exceeds a second threshold; responsive to determining that the first probability score exceeds the first threshold and the second probability score exceeds the second threshold, determining to treat the parameter as malicious; responsive to determining that the first probability score does not exceed the first threshold and the second probability score does not exceed the second threshold, determining to not treat the parameter as malicious; and responsive to all other cases: calculating a net probability score based on the first probability score, the second probability score, the first threshold, and the second threshold; and determining whether to treat the parameter as malicious based on the net probability score.

7. The method of claim 1 wherein the web server hosts a plurality of web applications and wherein the one or more deep learning models are trained across all of the web applications.

8. A computer system comprising: a network interface; a memory; and a processing subsystem coupled to the network interface and configured to execute a plurality of web apps, the processing subsystem further configured to execute: an interface layer process to receive requests directed to the web apps from a plurality of clients via the network interface, at least one of the requests including an input payload, and to extract one or more parameters from the input payload;a threat analysis process to analyze the one or more parameters using one or more trained deep learning models that generate respective probability scores indicating a probability that each of the one or more parameters is malicious; a decision logic process to receive the respective probability scores from the one or more trained deep learning models and to determine, based on the respective probability scores, whether the input payload includes at least one suspect parameter; a sanitization process to perform a sanitization operation on the input payload to produce a sanitized payload in response to the decision logic process determining that the input payload includes at least one suspect parameter; and a routing process to route an output to a destination one of the web apps, wherein the output includes the sanitized payload in the event that the input payload includes at least one suspect parameter and wherein the output includes the input payload in the event that the input payload includes no suspect parameters.

9. The computer system of claim 8 wherein the one or more trained deep learning models include at least two different deep learning models.

10. The computer system of claim 9 wherein each of the at least two different deep learning models is separately trained using supervised learning with known malicious payloads and known benign payloads.

11. The computer system of claim 8 wherein the sanitization operation includes removing the at least one suspect parameter.

12. The computer system of claim 8 wherein the sanitization operation includes replacing one or more of the at least one suspect parameter with a benign parameter.

13. The computer system of claim 8 wherein the one or more trained deep learning models include a plurality of deep learning models and wherein the decision logic process includes voting logic.

14. A computer-readable storage medium having stored therein program code instructions that, when executed by a processor in a computer system, cause the processor to perform a method comprising: receiving a request from a client, the request including a payload;extracting a parameter from the payload; providing the parameter to one or more deep learning models that have been trained to provide respective probability scores indicating a probability that the parameter is malicious; receiving one or more respective probability scores from the one or more deep learning models; determining, based on the one or more respective probability scores, whether the parameter is a suspect parameter; in response to determining that the parameter is a suspect parameter: performing a sanitization operation on the request to produce a sanitized request, the sanitization operation including removing the suspect parameter; and sending the sanitized request to a web application; and in response to determining that the parameter is not a suspect parameter, sending the request including the parameter to the web application.

15. The computer-readable storage medium of claim 14 wherein the one or more deep learning models include a first deep learning model that includes a feedback connection and a second deep learning model that does not include a feedback connection.

16. The computer-readable storage medium of claim 15 wherein the first deep learning model is a long short-term memory (LSTM) model.

17. The computer-readable storage medium of claim 16 wherein the second deep learning model is a multilayer perceptron model.

18. The computer-readable storage medium of claim 15 wherein determining whether to treat the parameter as malicious includes: determining whether a first probability score from the first deep learning model exceeds a first threshold; determining whether a second probability score from the second deep learning model exceeds a second threshold; responsive to determining that the first probability score exceeds the first threshold and the second probability score exceeds the second threshold, determining to treat the parameter as malicious;responsive to determining that the first probability score does not exceed the first threshold and the second probability score does not exceed the second threshold, determining to not treat the parameter as malicious; and responsive to all other cases: calculating a net probability score based on the first probability score, the second probability score, the first threshold, and the second threshold; and determining whether to treat the parameter as malicious based on the net probability score.

19. The computer-readable storage medium of claim 14 wherein the computer system hosts a plurality of web applications and wherein the one or more deep learning models are trained across all of the web applications.

20. The computer-readable storage medium of claim 14 wherein the sanitization operation further includes replacing the suspect parameter with a benign parameter.

Images