Command line interface and smart proxy employing a plurality of protocols for dynamic application security testing of a target application on a privately hosted network

Abstract

The present disclosure relates to a system and a method to scan a target application on a privately hosted network by tools located outside the privately hosted network, wherein the communication between the tools and the target application are wrapped in a first protocol and a second protocol for transfer, such as tunneling, by a smart proxy. In one exemplary configuration, a security testing system employs DAST tools running outside a privately hosted network, wherein the DAST tools can be unmodified, or substantially unmodified, materially unmodified open source (as well as closed source) DAST tools.

Description

COMMAND LINE INTERFACE AND SMART PROXY EMPLOYING A PLURALITY OF PROTOCOLS FOR DYNAMIC APPLICATION SECURITY TESTING OF A TARGET APPLICATION ON A PRIVATELY HOSTED NETWORKTECHNICAL FIELD

[0001] The present disclosure relates to a system and a method to scan a target application on a privately hosted network by tools located outside the privately hosted network, wherein the communication between the tools and the target application are wrapped in a first protocol and a second protocol for transfer, such as tunneling, by a smart proxy.BACKGROUND

[0002] The fundamental basis of dynamic application security testing (DAST) of websites is having a tool that sends hypertext transfer protocol (HTTP) requests to the website, receives HTTP responses from the website, and analyzes the HTTP responses for indicators of security vulnerabilities. When using a DAST tool to scan a public website for vulnerabilities, the DAST tool is able to directly communicate with the website.

[0003] However, oftentimes it is desirable to test a website without publishing the website to the public internet. That is, the website is “running’’ on a privately hosted network and the available DAST tools do not have access to the privately hosted network and hence the website. The DAST tools need to run on a computer that has access to the privately hosted network, which might be on a developer’s laptop computer, a private cloud network, or in a continuous integration (CI) system.

[0004] Therefore, the need exists for a security testing system and method for testing a target application on a privately hosted network, wherein the security testing system can gain access to the privately hosted network, and securely expose the target application to DAST tools running outside the privately hosted network.BRIEF SUMMARY

[0005] Generally, the present disclosure provides for a system and method for security testing. In one exemplary configuration, a security testing system employs DAST tools running outside a privately hosted network, wherein the DAST tools can be unmodified, or substantially unmodified, materially unmodified open source (as well as closed source) DAST tools, and wherein in one exemplary configuration the DAST tools are running on a serverless computer service that runs the DAST tools in response to events and automatically manages the computer resources, thus providing serverless applications, such as but not limited to Amazon Web Sendees (AWS) Lambda functions. The present system provides for these DAST tools to scan targetapplications running on the Internet or on the privately hosted networks such as developer’s laptop computers or in their continuous integration and continuous deliver CI / CD pipelines.

[0006] The present system envelopes (or wraps) DAST requests in a first protocol, which is in turn enveloped (wrapped) in a second protocol to pass through a preestablished tunnel with a smart proxy for passage to the privately hosted network and an interrogation of a target application within the privately hosted network, wherein responses from the target application are wrapped in the first and second protocol and passed through the tunnel and the smart proxy to be unwrapped and the responses analyzed by DAST tools outside the privately hosted network.

[0007] In one exemplary configuration, a provided command-line interface (CLI) is installed on a privately hosted network. The installed CLI connects to an implementing application programming interface (API) to initiate a scan of a target application, such as a website, on the privately hosted network using a workflow of the present system. The implementing API returns a scan execution ID to the installed CLI. The installed CLI then starts an internal SOCKS server running the first protocol and connects to a smart proxy over a predetermined second protocol, such as HTTP / 3 (version three of the hypertext transfer protocol). The smart proxy provides the scan execution ID as a query string parameter. The smart proxy maintains this open connection in-memory and updates the workflow execution with information about which specific smart proxy is to be used for connections in this scan execution. The workflow then executes predetermined AWS Lambda functions, which themselves connect to the smart proxy over HTTP / 3. For example, a AWS Lambda layer mimics a SOCKS server and passes SOCKS connections over the smart proxy to the privately hosted network.

[0008] The present system including the smart proxy allows tools, such as open source or closed source DAST tools, executed out of the privately hosted network, such as in a serverless environment, including, AWS Lambda functions to connect to a target application, such as a web application, on the privately hosted network. As the target application remains on the privately hosted network, there is no exposure of the target application to the public Internet.

[0009] Generally, the present disclosure provides a method for security testing a target application on a privately hosted network, the method including passing an instruction from a CLI program on the privately hosted network to a smart proxy to prompt a scanning function by a set of DAST tools operating outside the privately hosted network, such as in a serverless container; initiating, from the set of DAST tools operating outside the privately hosted network, such as in the serverless container, a request in a first protocol; receiving the request at the smart proxy, the smart proxy, via the proxylayer, wrapping / encapsulating the request in a second protocol to generate a wrapped / encapsulated request; transmitting, via a tunnel, the wrapped request to theCLI; unwrapping, at the CLI, the wrapped request to generate a first protocol request, passing the first protocol request from the CLI to the web application under test; receiving, at the CLI, a first response to the first protocol request from the target application under test; wrapping, at the CLI, the first response in the second protocol to generate a wrapped first response; passing the wrapped first response through the tunnel to the smart proxy; unwrapping, via the smart proxy, the wrapped first response to generate an unwrapped first response in the first protocol; passing the unwrapped first response in the first protocol, from the smart proxy to the set of D AST tools operating outside the privately hosted network, such as in the serverless container; and evaluating, by the set of DAST tools operating outside the privately hosted network, such as in the serverless container, the unwrapped first response in the first protocol to assess the target application under test.

[0010] In one exemplary configuration, the present disclosure provides a method of security testing a system under test run on a privately hosted network, the method including passing to a smart proxy a first request in a first protocol, the first request initiated from a set of DAST tools operating outside the privately hosted netw ork, such as in a serverless container; wrapping, by the smart proxy comprising the proxylayer, the first request in a second protocol to generate a wrapped first request; passing the wrapped first request through a tunnel to a CLI in the privately hosted network; unwrapping, at the CLI, the wrapped first request to generate an unwrapped first request in the first protocol; passing the unwrapped first request in the first protocol from the CLI to the system under test; receiving, at the CLI, a first response from the system under test to the unwrapped first request in the first protocol; wrapping, at the CLI, the first response from the system under test in the second protocol to generate a wrapped first response; passing, through the tunnel, the wrapped first response from the CLI to the smart proxy; unwrapping, at the smart proxy, the wrapped first response to generate an unwrapped first response; receiving, outside the privately hosted network, such as at a predetermined port of the serverless container, the unwrapped first response; and analyzing, by the set of DAST tools operating outside the privately hosted network, such as in the serverless container, the unw rapped first response.BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0011] The accompanying draw ings are incorporated herein as part of the specification. The drawings described herein illustrate embodiments of the presently disclosed subject matter and are illustrative of selected principles and teachings of the present disclosure. However, the drawings do not illustrate all possible implementations of the presently disclosed subject matter and are not intended to limit the scope of the present disclosure in any way.

[0012] FIG. 1 is a process diagram of the communication of the components of a security testing system according to an exemplary embodiment of the presently disclosed subject matter.

[0013] FIG. 2 is a schematic diagram of an unadorned HTTP request.

[0014] FIG. 3 is a schematic diagram of an HTTP request where the SOCKS5 proxy wraps an original HTTP request message inside a SOCKS5 envelope according to an exemplar}' embodiment of the presently disclosed subject matter.

[0015] FIG. 4 is a schematic diagram of an implementation of the security' testing system according to an exemplary' embodiment of the presently disclosed subject matter.

[0016] FIG. 5 is a schematic diagram of an implementation of the security testing system according to an exemplary embodiment of the presently disclosed subject matter.

[0017] FIG. 6 is a flowchart of an implementation of the security testing system according to an exemplary embodiment of the presently disclosed subject matter.DETAILED DESCRIPTION

[0018] It is to be understood that the invention may assume various alternative orientations and step sequences, except where expressly specified to the contrary'. It is also to be understood that the specific assemblies and systems illustrated in the attached drawings and described in the following specification are simply exemplary embodiments of the inventive concepts defined herein. Hence, specific physical characteristics relating to the embodiments disclosed are not to be considered as limiting, unless expressly stated otherwise. Also, although they may not be, like elements in various embodiments described herein may be commonly referred to with like reference numerals within this section of the application.

[0019] One skilled in the relevant art will recognize that the elements and techniques described herein can be practiced without one or more of the specific details, or with other methods, components, etc. In some instances, well-known structures or operations are not shown or described in detail to avoid obscuring certain aspects of the present disclosure. Reference throughout the specification to “one embodiment." “an embodiment,” “an exemplary’ embodiment / ’ “one configuration,” “one exemplary configuration” or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearance of the phrase in “one embodiment,” “an embodiment,” “an exemplary embodiment.” “one configuration,” “one exemplary configuration,” or the like, throughout the specification is not necessarily referring to the same embodiment. However, the particular features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments.

[0020] Where used herein, the terms ‘'first”, “second”, and so on, do not necessarily denote any ordinal, sequential, or priority relation, but are simply used to more clearly distinguish one element or set of elements from another, unless specified otherwise.

[0021] The present disclosure is directed to application security testing to identify potential vulnerabilities, and more particularly testing web applications on a privately hosted network from analysis tools running outside the privately hosted network.

[0022] Generally, the testing can include dynamic application security testing (DAST), a blackbox testing technique that scans a target application for vulnerabilities while the target application is running. In DAST testing there is no access to the target application source code. Typically, DAST tools send simulated user traffic to the target application and look for any vulnerabilities, unexpected, or malicious behavior. This traffic can include things like SQL injection, cross-site scripting (XSS), and denial-of-service (DoS) attacks.

[0023] The fundamental basis of DAST for websites (target websites or target applications) is having a tool that sends HTTP requests to the target website and analyzes the received HTTP responses for indicators of security vulnerabilities.

[0024] Oftentimes it is advantageous to test a website without publishing the website to the public Internet. That is, the website is run on a privately hosted website, rather than the public internet. The privately hosted website might be on a developer’s laptop computer (also referred to herein as a “laptop”), a private cloud network or in a CI system. Thus, the DAST tools need to run on a computer that has access to the privately hosted site. The present system provides a smart proxy for implementing the DAST tools running on a computer outside of the privately hosted network that has the target website.

[0025] The present system includes or cooperates with the following components, a target application, DAST tools, an installed CLI, a smart proxy, an implementing API, and proxylayer serverless container extension.

[0026] [Target Application] The application or website under test (herein referred to as the target website or target application) is the subject of the requests from the DAST tools, which are running outside the privately hosted network. The target application is the piece of software that is being tested for security vulnerabilities. Typically, the target application will be software that is being custom-built. For example, the target application can be a program that a developer is running on their laptop computer. Further, in one configuration, the target application resides on a privately hosted network.

[0027] [DAST Tools] In one exemplary configuration, the DAST tools are third party code, and particularly open source DAST tools such as, but not limited to, ZAP, Nuclei, Dalfox, SQLMap, Katana, Arachni, Wapiti, and Gospider. By employing commercially available DAST tools (sometimes referred to as programs) without modification, the present system provides for the scanning of the target application without requiring the development of separate DAST tools.

[0028] In one exemplary configuration, the DAST tools (including but not limited to programs) are in an at least a substantially unmodified state, wherein the DAST tools can be open source and are located in a serverless compute sendee or serverless container that runs the provided code in response to events and automatically manages the compute resources, such as but not limited to AWS Lambda functions. For example, the DAST tools can be run inside AWS Lambda functions in a private cloud network. In one configuration, the DAST tools are unmodified from what is otherwise publicly available. However, it is understood there may be some modifications to the open source DAST tools (programs), but such modifications are typically less than 5 % of the total number of lines of code of the open source DAST tool. It is further contemplated the DAST tools can be proprietary, or non-open source. Thus, the available or employed DAST tools can include open source tools, modified open source tools, proprietary (or closed source) tools, as well as a combination of any these tools.

[0029] As referenced above, an AWS Lambda function is a relatively small, self-contained code unit that can be triggered by events. Lambda functions are serverless and can be used to perform a variety of tasks, such as: processing data; executing business logic; responding to API requests; sending emails; and scheduling tasks. For purposes of this description, AWS Lambda is a serverless compute service, operating as a serverless container, that runs provided code in response to events and automatically manages the compute resources, thus providing serverless applications. The serverless container is a lightweight environment (relatively small memorj' footprint, having reduced CPU usage which decreases the required processing power to run the application, reduced or minimal dependencies on external libraries or frameworks thus reducing conflicts with other software components, and directed to a limited set of core functionality), which is isolated for running the code, and deploys the code in a serverless manner. The serverless container is effectively decoupled from the underlying system infrastructure. The serverless containers are triggered by events, such as HTTP requests, data changes, or scheduled tasks, and can be automatically scale up or down based on demand. In addition, in select configurations, the serverless container allows for a pay only for utilization of compute resources consumed during container execution. In addition, the serverless container is typically stateless as the container does not maintain data between invocations.

[0030] Although the present configuration is set forth in terms of serverless containers, it is recognized that other commercially available instances can be employed including, but not limited to, cloud based secure, resizable compute capacity' (e.g., Amazon Elastic Compute Cloud (Amazon EC2)). as well as instances of containerized applications in a Kubemetes cluster independent of managing or provisioning an underlying infrastructure (such as Fargate EKS, a combination of Amazon Fargate and Amazon Elastic Kubemetes Service (EKS)).

[0031] [CLI] Referring now to FIG. 1, the installed CLI is a command-line interface program provided or distributed to users of the presently disclosed security testing system. For example, the installed CLI is downloaded from a predetermined website and then runs on the privately hosted network. In one example, the system running the installed CLI is a developer's laptop computer, which is on the privately hosted network. However, it should be understood that the installed CLI could equally well be a server in a cloud network of the privately hosted network, or anywhere else the user deems appropriate. The installed CLI is run when the user wants to scan the target application on the privately hosted network for security vulnerabilities. As set forth below, the installed CLI generally opens a tunnel to the smart proxy, and then the installed CLI instructs the implementing API, to start a scan of the target application, such as the target application on the privately hosted network, by the DAST tools running outside the privately hosted network.

[0032] [Smart Proxy Service] The smart proxy is the proxy that the system deploys to the public Internet. The smart proxy accepts connections from the installed CLI running on the privately hosted network. The connection between the installed CLI on the privately hosted network and the smart proxy are authenticated using an open standard (such as RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties, such as but not limited to a JSON object (JWT) that the implementing API provides to the installed CLI. The smart proxy also accepts connections from a '‘proxylayer” which in one configuration can be deployed to the serverless container, such as the AWS Lambda functions, such as in a cloud network.

[0033] Typically, the smart proxy includes the functionality to inspect and analyze the content of network traffic to apply routing decisions, such as distribute network traffic across multiple servers or network paths to optimize performance and prevent bottlenecks. The smart proxy can monitor server load and network latency to determine an efficient routing path, as well as apply specific optimization techniques based on the t pe of application. As set forth below, the smart proxy can comprise the proxylayer for providing the functionality of facilitating communication between the DAST tools and the smart proxy. For example, the proxylayer can be integrated intothe smart proxy to implement the wrapping and unwrapping of the first and second protocols. Thus, the proxylayer can be configured to provide that the remote DAST tools connect to the proxylayer as though the proxylayer were the intended network endpoint.

[0034] In one configuration, the smart proxy manages a plurality of compute sources, wherein a plurality7of threads can be running on each compute source. The smart proxy provides for communication of a plurality of threads over a single connection. That is, the smart proxy establishes and maintains a dedicated pathway for the single connection between the target application and the plurality of compute sources, wherein a plurality of threads can be simultaneously accommodated in the connection. For example, a plurality of DAST scans can be sent to a single target application on the privately hosted network on a single connection, wherein the smart proxy can employ multiplexing, context switching, as well as resource management. Thus, the smart proxy can implement the execution of multiple DAST scans (requests / tests) against a plurality of target applications, each target application on a separate privately hosted network, from sources in the cloud (or outside the privately hosted network).

[0035] [Implementing API] With continued reference to FIG. 1, the implementing API is responsible for at least starting the scans, viewing lists of scans, and viewing the results of a given scan. The implementing API is the other service that the present system has deployed to the public Internet. The installed CLI connects to the implementing API to start the scans of the target application.

[0036] [‘proxylayer’ Lambda Extension] In one configuration, the proxylayer integrated in the smart proxy is a ‘‘proxylayer'’ extension in the serverless container and can be a Lambda extension as an AWS Lambda extension that runs inside the same serverless container, such as the Lambda function, providing virtual machine that runs the DAST tools. The “proxylayer” Lambda extension converts from the first protocol, such as SOCKS5 (expected by the DAST tools) to the second protocol of the smart proxy, such as HTTP / 3, as set forth below. Thus, in one configuration, the proxylayer is a specific Lambda extension that provides the DAST tools access to the smart proxy. The proxylayer can provide authentication, authorization, encryption, and traffic manipulation, as well as wrapping the SOCKS (first) protocol requests from the DAST tools in the HTTP / 3 (second) protocol for compatibility7with the smart proxy. Similarly, the proxylayer can unwrap messages in HTTP / 3 (second) protocol to expose the SOCKS (first) protocol for delivery to the DAST tools.

[0037] [SOCKS5] SOCKS5 is a fifth version of the SOCKS protocol. SOCKS5 supports both the transmission control protocol (TCP) and the user datagram protocol (UDP). However, SOCKS5 can be considered a "dumb pipe" for transmitting packets, in that it does not inspect ormodify the data it transmits, nor does it provide encryption of the data. The primary function of SOCKS5 is to route network traffic through the proxy server. While SOCKS5 can offer some privacy benefits by masking the user's IP address, it does not inherently protect the confidentiality' or integrity of the data being transmitted.

[0038] The installed CLI and smart proxy are directed to providing for the scanning of target applications that are not on the internet, but rather on the privately hosted network. While the target application can be on the internet and be scanned by the present security testing system, the present security testing system provides for the scanning of the target application that may be running on the privately hosted network as accessed by a laptop computer of a developer or in continuous integration continuous development (CI / CD) pipelines in the privately hosted network. Target applications, including websites, that are not on the Internet require special connectivity, as provided by the present disclosure.

[0039] Generally, the installed CLI connects the privately hosted network to the implementing API to initiate a DAST scan using a predetermined workflow in the Lambda functions, such as a Step Function workflow. The implementing API returns a scan execution ID. The installed CLI then starts an internal SOCKS server and connects to the smart proxy over HTTP / 3. The installed CLI provides the scan execution ID as a query string parameter. The smart proxy maintains this open connection in-memory and updates the Step Function execution with information about which specific proxy server to be used for connections in the given scan execution. The Step Function then executes the Lambda functions, which themselves connect to the smart proxy over HTTP / 3, the second protocol. The system includes a Lambda layer that mimics a SOCKS server and passes SOCKS connections over the smart proxy to the installed CLI on the privately hosted network. Although set forth in terms of step functions, it is understood the present system can employ linear workflows, or directed acyclic graph (DAG), or distributed microservices.

[0040] In the simplest configuration, the DAST tools connect “directly” to the application under test (target application) via standard HTTP(S) over TCP ports 80 or 443. This “direct” connection works when either the DAST tools are on the same network as the application under test (target website), or the target application is hosted on the public Internet.

[0041] As schematically illustrated in FIG. 2, the unadorned HTTP request can be represented as a message on a piece of paper, passed straight from the DAST tool to the target application:DAST tool HTTP request — > WebsiteHowever, the present system provides for running the DAST tools from outside the privately hosted network to scan the target application running on the privately hosted network.

[0042] The DAST tools also support a proxy protocol such as SOCKS5, a general-purpose proxy protocol that can be used to route traffic for any type of application, not just web applications. SOCKS5 supports multiple authentication methods, UDP traffic, and the ability to tunnel traffic through multiple proxies. SOCKS5 provides a mechanism for a program to connect to its ultimate destination via an intermediary, the SOCK.S5 proxy itself. The SOCKS5 proxy wraps the original HTTP request message inside a SOCKS5 envelope. The present system uses this to control the stream of requests sent by the DAST tool.

[0043] The address is the IP address and port that the SOCKS5 proxy should forw ard the payload. One exemplar}' configuration of the communication is schematically illustrated in FIG. 3. SOCKS5 has significant industry acceptance and is broadly supported. However, the SOCKS5 protocol is subject to some limitations as the protocol has limited options for authentication and no support for metadata. In addition, the SOCKS5 protocol is also often blocked by corporate firewalls, because an employee using SOCKS is typically indicative of someone trying to subvert an internet filter.

[0044] For these reasons, the present smart proxy does not directly use the SOCKS5 protocol. Instead, the present smart proxy, via the proxylayer, employs a second protocol, such as an HTTP / 3 protocol. The HTTP / 3 protocol is employed, as HTTP is a very well-supported protocol and version HTTP / 3 includes the feature WebTransport. WebTransport is a web API that uses the HTTP / 3 protocol as a transport layer for two-way communication. Thus, WebTransport supports multiplexing many data streams over a single HTTP connection. WebTransport allows multiple streams of data to be sent, and it allows streams of data to be started in both directions. Without WebTransport, when a WebSocket connection is opened, there is only one stream of data that can be passed on the connection. In contrast, w ith WebTransport, the installed CLI can open a single connection to the smart proxy, and that one connection can hold many live threads. Thus, with respect to the number of scans that can be simultaneously run, if the transport layer is single ay communications, then only one request can be run at a time, which would render the system extremely slow; The present configuration allows for multiple Lambda functions, each Lambda function running a plurality of scans (requests). Thus, the present system can provide for multiple simultaneous requests (scans).

[0045] The bi-directional capacity of the WebTransport allow s for both the client and the server to initiate data streams, in contrast to prior systems in which a web browser (the client) initiates requests and the server responds. With WebTransport, the Lambda functions (effectively the DAST tools) acting as a server can initiate a request to the local client (on the privately hosted network). For example, the present system employs a Lambda extension which is just anotherprogram that runs inside the Lambda container, to listen on a given or predetermined port, such as but not limited to port 1080.

[0046] The DAST tools, running outside the privately hosted network such as inside the Lambda container, are instructed to connect to the predetermined port. Thus, when a Lambda function is invoked, the extension connects to the smart proxy. That is, the present system opens its own tunnel to the smart proxy and then it listens to the DAST tool and presents as a SOCKS5 server. Any connections the smart proxy receives from the DAST tool are accommodated by the smart proxy. The smart proxy will forward the requests to the installed CLI.

[0047] The DAST tools running inside Lambda functions initiate issuing requests including requesting connection to the target application (system under test). The requests are sent to the proxylayer and the smart proxy. In one configuration, the requests are in the first protocol, as SOCKS requests to the SOCKS server, wherein the request specifies the type of connection that the (SOCKS) client wants to make as well as at least the destination address and port.

[0048] All the DAST tools employed by the present system support a SOCKS5 proxy being specified. This allows the smart proxy to effectively insert itself into the stream of requests sent by the DAST tool. Thus, in one configuration, the smart proxy acts as a SOCKS5 proxy.

[0049] Thus, there is HTTP protocol inside SOCKS5 protocol inside HTTP / 3 protocol.

[0050] While the HTTP / 3 and WebTransport are employed in one configuration, it is understood it is not required to use HTTP / 3 and WebTransport. The installed CLI can include code to first tty HTTP / 3 and then fallback to HTTP / 1.1, upon failure of the HTTP / 3. That is, if the HTTP / 3 protocol is blocked in some environments using outdated or overly restrictive firewalls, then the installed CLI can employ the HTTP / 1. 1 protocol.

[0051] HTTP’s support for metadata (in the form of request headers) allows the present system to specify extra information on the wrapping of the protocol. When the installed CLI connects to the smart proxy, it is assigned a “relay ID”. The relay ID is essentially treated as an address, and the relay ID gets included on the wrapping of the second protocol, such as the WebTransport of the HTTP / 3 protocol envelopes sent by the proxylayer Lambda extension. This allows the smart proxy to associate the active scan with a corresponding DAST request. Additional metadata can be optionally included such as, but not limited to Lambda request IDs, scan IDs, as well as identifiers, such as variable name, function name, class name, object ID and thread ID.

[0052] One exemplary implementation of the security testing system is schematically illustrated in FIG. 4. Another exemplary7implementation of the security testing system is schematically illustrated in FIG. 5. Initially, the installed CLI is loaded or run on a computer in the privatelyhosted network. The installed CLI opens a WebTransport session with the smart proxy. The HTTP / 3 response headers include a “relay ID”. This session stays open for the duration of the scan. That is, generally, the installed CLI opens up a tunnel to the smart proxy.

[0053] Tunneling is a method of using a protocol that allows for the secure movement of data between networks. In one example, tunneling involves allowing private network communications to be sent across a public network, such as the Internet, through a process called encapsulation or wrapping. The encapsulation process allows for data packets to appear as though they are of a public nature to a public network when they are actually private data packets, allowing them to pass through unnoticed. In one example, a tunneling protocol allows a network user to access or provide a network service that the underlying network does not support or provide directly. One important use of a tunneling protocol is to allow a foreign protocol to run over a network that does not support that particular protocol. Tunneling includes repackaging traffic data into a different form, for example, with encryption as standard; accordingly, a third use of tunneling is to hide the nature of the traffic data that is run through the tunnel. The tunneling protocol works by using the data portion of a packet or frame (the payload) to cany’ the packets or frames that actually provide the sendee or request.

[0054] The installed CLI further initiates the implementing API running inside the AWS Lambda functions (outside the privately hosted network), to initiate a DAST scan of the target application (which can be on the private network), and the API instructs the DAST tools to start a scan of the target application.

[0055] The installed CLI then calls the implementing API to initiate a scan. When starting the scan, implementing API passes along the previously received relay ID.

[0056] The implementing API creates a scan object in its database and assigns it a “scan ID”.

[0057] The implementing API calls the AWS Step Functions API to start an execution of the ' scanner-top’ state machine. The execution can be started with some JSON that includes the scan ID and relay ID.

[0058] The Step Functions state machine executes a series of Lambda functions. The first Lambda function is one that uses the relay ID to look up which specific ECS container is responsible for this particular relay ID - as there can be multiple load-balanced containers running, but only one is responsible for a given scan.

[0059] The DAST tool Lambda functions are invoked with a payload that includes (among other data) the scan ID, the relay ID, the internal IP address of the smart proxy container.

[0060] The DAST tool Lambda function makes a local call to the 'proxylayer' Lambda extension with the relay information necessary to establish a WebTransport session (the second protocol) to the right container. The request header for the session includes the relay ID. The session lives for the duration of the Lambda invocation.

[0061] The Lambda function then invokes the underlying DAST tool. It specifies a SOCKS5 proxy listening on a predetermined port, such as 127.0.0.1 : 1080' — the proxylayer Lambda extension. The DAST tools inside the Lambda functions begin issuing requests (in the SOCKS5 protocol) including request to connect to the target application. These SOCKS5 protocol requests are passed to the smart proxy.

[0062] The proxylayer Lambda extension accepts connections on port 1080 and forwards them to the smart proxy via the already established WebTransport session. Each SOCKS connection has its own WebTransport stream inside the protocol of the WebTransport session.

[0063] Upon each Lambda-initiated WebTransport stream being opened, the smart proxy uses the relay ID to look up which CLI session it should open a new stream on. The smart proxy opens a client stream and then copies packets back and forth from the Lambda-initiated stream to the client stream in the privately hosted network (and vice-versa).

[0064] The installed CLI waits for new WebTransport streams to be opened by the smart proxy. The installed CLI accepts each new stream request and then processes the forwarded SOCKS connections in an internal SOCKS proxy server. The raw, proxied HTTP connections are forwarded to the target application (website under test).

[0065] When the step function execution terminates in the Lambda container (whether successfully or due to an error), a serverless event bus. such as EventBridge, invokes a Lambda function that calls the implementing API to inform it of the scan status update.

[0066] The installed CLI has been polling the implementing API every few seconds during this time. When the installed CLI sees the scan status has changed to a terminal status, the installed CLI closes the WebTransport session and exits the program.

[0067] Thus, the present disclosure provides for the use of multiple layers of protocol wrapping. In one configuration, the disclosure includes the wrapping of HTTP / 3 and SOCKS layers.

[0068] Referring now to FIG. 6, generally in the presently disclosed method 100 for security testing a target application on a privately hosted network, the installed CLI opens a tunnel to the smart proxy and the installed CLI instructs the implementing API to start a scan of the target application (e g., website) in step 102.

[0069] In step 104, the implementing API instructs the DAST tools running inside the Lambda functions, or running outside the privately hosted network, to begin issuing requests including a request, in a first protocol, such as the SOCKS protocol, to connect to the target application. In step 106, the requests from the DAST tools are received at the smart proxy which can comprise the proxylayer. As set forth above, the smart proxy manages the routing, load balancing, and the secure tunneling of the requests. The smart proxy can also select the appropriate protocol based on predetermined parameters including, but not limited to network conditions. The proxylayer wraps the SOCKS requests (requests in the first protocol) in HTTP / 3 (the second protocol) and, in step 108, passes them through the tunnel that was established by the installed CLI. In step 110, the installed CLI then unwraps the wrapped requests, and then, in step 112, sends the requests to the target application in the HTTP protocol, wherein as set forth above, the target application can be on the same privately hosted network as the installed CLI. In step 114, the target application will respond with HTTP responses back to the installed CLI. In step 116, the installed CLI receives the responses, the first and second protocol are applied, and, in step 118. the responses pass back through the tunnel to the smart proxy. In step 120, the smart proxy unpacks the responses, and, in step 122, sends the unwrapped request to the Lambda function. In step 124, the DAST tools, such as open source or partly open source code in the Lambda function, determines if the response is indicative of a problem in the target application or code.

[0070] In an exemplary configuration, the present disclosure provides a method for security testing a target application on a privately hosted network, including passing an instruction from a command line interface program (CLI) on the privately hosted network to a smart proxy to prompt a scanning function by a set of DAST tools operating outside the privately hosted network; initiating, from the set of DAST tools operating outside the privately hosted network, a request in a first protocol; receiving the request at the smart proxy, the smart proxy wrapping / encapsulating the request in a second protocol to generate a wrapped / encapsulated request; transmitting, via a tunnel, the wrapped request to the CLI; unwrapping, at the CLI, the wrapped request to generate a first protocol request, passing the first protocol request from the CLI to the web application under test; receiving, at the CLI. a first response to the first protocol request from the web application under test; wrapping, at the CLI, the first response in the second protocol to generate a wrapped first response; passing the wrapped first response through the tunnel to the smart proxy; unwrapping, via the smart proxy, the wrapped first response to generate an unwrapped first response in the first protocol; passing the unwrapped first response in the first protocol, from the smart proxy to the set of DAST tools operating outside the privately hosted network; andevaluating, by the set of DAST tools operating outside the privately hosted network, the unwrapped first response in the first protocol to assess the web application under test.

[0071] In an exemplary configuration, the present disclosure provides a method of security testing a system under test in a privately hosted network, including passing a first request in a first protocol to a smart proxy, the first request initiated from a set of DAST tools operating outside the privately hosted network; wrapping, via the smart proxy, the first request in a second protocol to generate a wrapped first request; passing the wrapped first request through a tunnel to the CLI; unwrapping, at the CLI, the wrapped first request to generate an unwrapped first request in the first protocol; passing the unwrapped first request in the first protocol from the CLI to the system under test; receiving, at the CLI, a first response from the system under test to the unwrapped first request in the first protocol; wrapping, at the CLI. the first response from the system under test in the second protocol to generate a wrapped first response; passing, through the tunnel, the wrapped first response from the CLI to the smart proxy; unwrapping, at the smart proxy, the wrapped first response to generate an unwrapped first response; receiving, at a predetermined port outside of the privately hosted network, the unwrapped first response; and analyzing, by the set of DAST tools operating outside of the privately hosted network, the unwrapped first response.

[0072] The drawings schematically depict one more example processes in the form of a flowchart. It should be understood that the described processes and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0073] While various embodiments of the present disclosure are described in detail herein, it should be understood that they are presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant arts that the disclosed subject matter may be embodied in other specific forms, variations, and modifications without departing from the scope, spirit, or essential characteristics thereof. One or more features of the embodiments described herein may be combined to create additional embodiments which are not depicted. The embodiments described herein are therefore to be considered in all respects as illustrative, and not restrictive. The scope of the invention is indicated by the appended claims, and all changes that come within the meaning and range of equivalents thereof are intended to be embraced therein.

Claims

CLAIMSWhat is claimed is:

1. A method for security testing a target application on a privately hosted network, the method comprising:(a) passing an instruction from a command line interface program (CLI) on the privately hosted network to a smart proxy to prompt a scanning function by a set of DAST tools operating outside the privately hosted network;(b) initiating, from the set of DAST tools operating outside the privately hosted network, a request in a first protocol;(c) receiving the request at the smart proxy, the smart proxy wrapping the request in a second protocol to generate a wrapped request;(d) transmitting, via a tunnel, the wrapped request to the CLI;(e) unwrapping, at the CLI, the wrapped request to generate a first protocol request;(!) passing the first protocol request from the CLI to the target application under test;(g) receiving, at the CLI, a first response to the first protocol request from the target application under test;(h) wrapping, at the CLI, the first response in the second protocol to generate a wrapped first response;(i) passing the wrapped first response through the tunnel to the smart proxy;(j) unwrapping, via the smart proxy, the wrapped first response to generate an unwrapped first response in the first protocol; k) passing the umvrapped first response in the first protocol, from the smart proxy to the set of DAST tools operating outside the privately hosted network; and(1) evaluating, by the set of DAST tools operating outside the privately hosted network, the unwrapped first response in the first protocol to assess the target application under test.

2. The method according to claim 1, wherein the tunnel provides bidirectional communication.

3. The method according to claim 1, wherein the set of DAST tools are independent of the smart proxy.

4. The method according to claim 1, wherein the set of DAST tools are open source.

5. The method according to claim 1, wherein the instruction passes through the tunnel.

6. The method according to claim 1, wherein a serverless container resides on a network outside the privately hosted network.

7. The method according to claim 6, wherein the serverless container is an AWS Lambda container.

8. The method according to claim 1, wherein the first protocol is SOCKS5 and the second protocol is HTTP / 3.

9. The method according to claim 1 , wherein smart proxy comprises a proxylay er configured to wrap a request of a first protocol in a different second protocol.

10. The method according to claim 1, wherein the set of DAST tools reside in a serverless container.

11. The method according to claim 1, wherein a portion of the set of DAST tools are open source.

12. The method according to claim 1, wherein a portion of the set of DAST tools are proprietary or closed source code.

13. The method according to claim 1, wherein the target application is a web application.

14. A method of security testing a system under test in a privately hosted network, the method comprising:(a) passing to a smart proxy a first request in a first protocol, the first request initiated from a set of DAST tools operating outside the privately hosted network;(b) wrapping, by the smart proxy, the first request in a second protocol to generate a wrapped first request;(c) passing the wrapped first request through a tunnel to the CLI;(d) unwrapping, at the CLI, the wrapped first request to generate an unwrapped first request in the first protocol;(e) passing the unwrapped first request in the first protocol from the CLI to the system under test;(f) receiving, at the CLI, a first response from the system under test to the unwrapped first request in the first protocol;(g) wrapping, at the CLI, the first response from the system under test in the second protocol to generate a wrapped first response;(h) passing, through the tunnel, the wrapped first response from the CLI to the smart proxy;(i) unwrapping, at the smart proxy, the wrapped first response to generate an unwrapped first response;(j) receiving, at a predetermined port outside of the privately hosted network, the unwrapped first response; and(k) analyzing, by the set of DAST tools operating outside of the privately hosted network, the unwrapped first response.

15. The method according to claim 14, wherein the unwrapped first response is in the first protocol.

16. The method according to claim 14, wherein the first response from the system under test to the unwrapped first request in the first protocol is in the first protocol.

17. The method according to claim 14, wherein the unwrapped first response is in the first protocol.

18. The method according to claim 14, wherein the tunnel is a bidirectional tunnel between a CLI and a smart proxy.

19. The method according to claim 14, wherein the set of DAST tools operate from a serverless container outside the privately hosted netw ork.

20. The method according to claim 14, wherein receiving, at the predetermined port outside of the privately hosted network, includes receiving at the port of a serverless container.

21. The method according to claim 19, wherein analyzing, by the set of DAST tools operating outside of the privately hosted network, includes analyzing in the serverless container.

22. A security testing system for applications on a privately hosted network, comprising dynamic application security testing (DAST) tools located outside the privately hosted network, wherein the DAST tools are configured to run in response to one or more predetermined events; a target application operating on the privately hosted network; a command-line interface (CLI) installed on the privately hosted network and connected to an implementing application programming interface (API) to initiate a scan of the target application, wherein the CLI includes an internal SOCKS server configured to operate a first protocol; and a smart proxy connected with the SOCKS server via a second protocol.

Images