Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
In the remarks filed on 06/30/2026. The applicant amended claims 1, 4, 5, 10, 11, 15, 20-21, and 23 are amended. No claims were added.
With respect to claim objections:
Applicant’ claim amendments and remarks filed on 06/30/2026 have been fully considered and overcame the claim objections as presented in the non-final office action filed 03/25/2026. Therefore, objections have been withdrawn.
With respect to 35 U.S.C. §102 and 103 rejections:
Applicant's arguments filed on 06/30/2026 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 7-12, with respect to the rejection (s) of independent claims 1,10 and 11 have been fully considered.
Applicant argues that Johns merely propagates taint metadata between complementary taint engines and therefore does not teach an injected indicator string itself reaching a security sensitive sink as a result of execution of injected client side code. The argument is not persuasive because the rejection does not equate Johns’s taint metadata with the claimed indicator string. Rather, Johns is relied upon for teaching dynamic tracking of attacker controlled data from an attacker controlled source to a security sensitive sink during execution. In particular, Johns teaches analyzing whether “attacker controlled data eventually reaches a security sensitive sink”, [0044], describes taint tracking as dynamically detecting and mitigating “the flow of tainted information through a program during execution”, [0046], and expressly teaches detecting flows from attacker controlled sources to security sensitive sinks, [0050-0053]. Johns further teaches that client side JavaScript may access tainted regions of the DOM and that the corresponding data may reach a security sensitive API sink, [0056]. Thus, Johns teaches the claimed execution based source to sink propagation framework.
Applicant further argues that Johns does not itself inject a non-malicious indicator string. This argument doesn’t address the rejection as a whole. Gallagher is relied upon for this feature. Gallagher teaches supplying readily identifiable, non-malicious test data and further teaches injecting a non-malicious signaling script containing readily identifiable text, executing the signaling script at the client, and monitoring for successful execution, see Gallagher Col 2, lines 26-43, col 8 lines 25-53, and col 9 lines 17-37. Accordingly, in the proposed combination, Gallagher’s readily identifiable indicator constitutes the particular attacker controlled data dynamically tracked using John’s source to sink tracking technique.
Applicant also argues that Gallagher’s preliminary tracer value is distinct from Gallagher’s subsequently injected signaling payload. The examiner aggress that Gallagher describes an initial tracer phase followed by a signaling script phase; however, the rejection does not require the preliminary plain text tracer to constitute the claimed indicator string. Gallagher expressly teaches that subsequently injected non malicious signaling script itself contains readily identifiable text, such as “Cross site ScriptingVulnerabiltyFoundByCSSSProbe”, and that execution of the script causes that identifiable text to be produced and detected, see Galagher, Col 8, lines 25-53, Col 9, lines 17-37. Such readily identifiable text reasonably corresponds to the claimed non malicious indicator string.
Applicant further argues that Gallagher merely detects a tracer in server generated output and does not detect an indicator string at a security sensitive sink during client side execution during client side execution. This argument again considers Gallagher apart from the teaching for which Johns is relied upon. Johns expressly provides the security sensitive client side sink and the dynamic detection of attacker controlled data reaching that sink during execution, [0044], [0046], [0051-0053], [0056]. Gallagher provides the particular readily identifiable test data combined in injected client side code. Thus, in the proposed combination, John’s tracked attacker controlled data is Gallagher’s readily identifiable indicator string.
Applicant additionally argues that the amended limitation requires “the same indicator string to reach the security sensitive sink as a result of the execution of the injected client side code.” The examiner agrees that the claim requires the indicator string to reach the sink as a result of execution. However, the cited combination reasonably teaches this feature. Johns expressly teaches tracking attacker controlled information “through a program during execution” and detecting such information when it reaches a security sensitive sink, [0046][0056]. Gallagher teaches executing injected client side code containing the readily identifiable indicator. Accordingly, when Gallagher’s indicator containing input is employed as the attacker controlled data in Johns, execution of the client side code causes that indicator containing data to propagate through John’s identified data flow to the security sensitive sink. Thus, the combined teaching reasonably meet the amended limitation.
Applicant further contends that incorporating Gallagher into Johns would require replacing John’s taint metadata/complementary engine architecture with entirely different indicator string architecture, the examiner respectfully disagrees. The proposed modification doesn’t replace John’s taint engines, taint metadata, or source to sink detection architecture. Gallagher’s readily identifiable indicator merely provides the particular attacker controlled input being tracked by Johns. Johns may continue to mark, propagate, and detect the data using its disclosed taint tracking mechanisms. Accordingly, the proposed combination doesn’t require bodily incorporation of Gallagher’s complete testing architecture into Johns or abandoning John’s operation.
Applicant also argues that Johns has no need for Gallagher’s indicator because Johns already determines whether data is tainted. However, obviousness does not require that the primary reference be incapable of functioning without the secondary reference. Galagher teaches the known benefit of using readily identifiable test data to determine whether a supplied input propagates into a potentially vulnerable context and to confirm XSS exploitability. It would have been obvious to POSITA to use Gallagher’s readily identifiable , non-malicious test indicator as the attacker controlled data dynamically tracked by Johns in order to facilitate identification and correlation of supplied test input with downstream security sensitive processing. Such use would have produced the predictable result of tracking a known, readily identifiable teat value through John’s existing source to sink analysis. Applicant’s assertion that Johns and Gallagher address different mechanism is also unpersuasive. Both reference concern detection of cross site scripting/injection vulnerabilities involving attacker controlled web input. Therefore, applicant’s arguments do not establish that the amended limitation is absent from the combined teachings of Johns and Gallagher, and the rejection of claim 1 under 103 is maintained.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-16, 18-20, and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over Johns (US 20170318045 A1) in view of Gallagher (US 7343626 B1).
Regarding claim 1, Johns teaches a for detecting document object model cross-site scripting (DOM-XSS) vulnerability comprising:
identifying at least one data flow in a client-side code, wherein each of the at least one data flow is between an attacker-controllable source and a security sensitive sink, (Johns, a system that can precisely track taint information for attacker-controlled sources to security-sensitive application programming interface API sinks. This taint tracking system may be configured to span boundaries between client and server execution environments to enable end-to-end taint-tracking of injection vulnerabilities in web applications, [0018] For client-side, the XSS may be referred to as Document Object Model (“DOM”) based XSS that is caused by client-side code, i.e., legitimate JavaScript routines executed in the client's web browser, [0039] client-side XSS attacks are caused by malicious inputs to the client-side (i.e., any attacker controllable data in a web application's DOM), [0040] how data is processed within the application and whether attacker-controlled data eventually reaches a security sensitive sink, needs to be analyzed. This kind of information flow analysis is a well-understood field and many different techniques exist to implement information flow analysis, [0044] client-side sources (data sources through which potentially malicious string data enters the client-side JavaScript code) including document.URL and document.location, Referrer, PostMessage, and XMLHttpRequest responses, [0050] a flow from an attacker-controlled source (either server- or client-side) into a sink (either server- or client-side) occurs, where sufficient validation or sanitization of the transported string data is not applied, a code injection vulnerability can exist., client-side sinks may including APIs that alter the web page's DOM (innerHTML, document.write), APIs, such as eval, that convert strings into executable code, and APIs that access client-side storage (localStorage, document.cookie, etc.) [0051-0052] taint tracking approaches detect injection vulnerabilities through detecting flows from attacker controlled sources to security sensitive sinks, [0053]) [Examiner interprets that system disclosing dynamic taint tracking by identifying how propagates through execution, tracking flows from source such as HTTP parms, DOM inputs to sensitive sink such as APIs like eval , inner HTML, including client side java script and DOM sinks and propagation, as limitation above];
wherein the client-side code operates on a DOM representation of a web page based on the client-side code (Johns, For client-side, the XSS may be referred to as Document Object Model (“DOM”) based XSS that is caused by client-side code, i.e., legitimate JavaScript routines executed in the client's web browser, [0039] client-side XSS attacks are caused by malicious inputs to the client-side (i.e., any attacker controllable data in a web application's DOM), [0040] a flow from an attacker-controlled source (either server- or client-side) into a sink (either server- or client-side) occurs, where sufficient validation or sanitization of the transported string data is not applied, a code injection vulnerability can exist., client-side sinks may including APIs that alter the web page's DOM (innerHTML, document.write), APIs, such as eval, that convert strings into executable code, and APIs that access client-side storage (localStorage, document.cookie, etc.) [0051-0052] The client browser may then be able to mark attacker-influenced regions in the HTTP response as tainted and propagate this information when a Document Object Model (“DOM”) is generated, As a consequence, if a client-side JavaScript accesses any tainted regions of the DOM, the taint information can be correctly obtained by the client-side taint engine 220 and processed accordingly in cases when the data reaches a security sensitive API sink, [0056]) [Examiner interprets that system generating DOM and then has client side Java script access regions of that DOM as the client side operates on the DOM representation].
detecting an indicator string in the security sensitive sink of the at least one data flow (Johns, how data is processed within the application and whether attacker-controlled data eventually reaches a security sensitive sink, needs to be analyzed. This kind of information flow analysis is a well-understood field and many different techniques exist to implement information flow analysis, [0044] The term “taint tracking” describes a class of dynamic approaches that detect and mitigate the flow of tainted information through a program during execution, [0046] a flow from an attacker-controlled source (either server- or client-side) into a sink (either server- or client-side) occurs, where sufficient validation or sanitization of the transported string data is not applied, a code injection vulnerability can exist., client-side sinks may including APIs that alter the web page's DOM (innerHTML, document.write), APIs, such as eval, that convert strings into executable code, and APIs that access client-side storage (localStorage, document.cookie, etc.) [0051-0052] if a client-side JavaScript accesses any tainted regions of the DOM, the taint information can be correctly obtained by the client-side taint engine 220 and processed accordingly in cases when the data reaches a security sensitive API sink, [0056])
performing mitigation action (Johns, As soon as one of the parsers 225 and 226 encounter a tainted code token, the parsing process can be stopped and a security exception can be asserted. The attacker injected code can be reliably prevented from being executed because the attacker-injected syntax never leaves the parsing process. As long as both components (both the server and the browser) are used together and the mitigation option is enabled, the system described in this disclosure is not susceptible to string-based injection attacks. This means, vulnerabilities such as XSS, SQL injection or Command Injection are not exploited, [0059] If the taint information indicates tainted content has been detected in the response body, process 600 can be configured to determine not to execute the tainted content or to report the source of the tainted content to a user of the client system, or both (operation 609). The client system can also mark the tainted segments of the standard network transfer protocol response body as tainted (operation 610), generate a document object model (operation 611) and propagate the marked tainted segments into the document object model (operation 612), [0094]) [Examiner interpret that system preventing execution, stop parsing, arising exception once the tainted data has been detected as performing mitigation action]
Although, Johns marks /tags input data (i.e., taint) and taint propagates through execution, executing of client-side code, taint propagating during execution and detecting of tainted data reaching sinks and performing mitigation upon detection of the taint, Thus, Johns does not appear to explicitly teach:
injecting a non-malicious indicator string in the attacker-controllable source of the client-side code; executing an injected client-side code, wherein the injected client-side code includes the indicator string; detecting the indicator string in the security sensitive sink of the at least one data flow; and performing mitigation action upon detecting the indicator string
However, Gallagher teaches:
injecting a non-malicious indicator string in the attacker-controllable source of the client-side code (Gallagher, The user-supplied data may be returned inside of a SCRIPT tag, such as "var Request_redir_url=`/isapi/acssrv.dll?action=error&commid=`;". The value for the redir_url from the URL becomes the value of the JavaScript variable named Request_redir_url, (Col 8, lines 25-32)The automated software tool submits a tracer value as input to a web site, and monitors the web page returned by the web site as a result of submitting the tracer value. When the tracer value is present in the returned web page, the automated software tool knows that the web site might be vulnerable to a cross-site scripting (XSS) attack. To confirm whether the web site is indeed vulnerable to a XSS attack, based on the location of the returned tracer value, the automated software tool submits a signaling script as input to the web site, and monitors the subsequently returned web page to determine whether the signaling script is executed by the local computer when the subsequently returned web page loads on the local computer. If the script is executed, the automated software tool knows that the web site is vulnerable to a XSS attack corresponding to the format of the script submitted based on the determined location of the tracer value, (Col 2, lines 26-43) FIG. 8, the automated software tool attempts in step 823 to exploit the web site by injecting a non-malicious script as described above. In an illustrative embodiment of the invention, a script such as <SCRIPT>alert("Cross-siteScriptingVulnerabilityFoundByCSSPr- obe.")</SCRIPT> is used. Any other readily identifiable text may alternatively be used, (Col 9, lines 17-24) in step 813 the automated software tool selects the first (or next) key-value pair, referred to as the current key-value pair. For each current key-value pair, the automated software tool performs steps 815 835. In step 815, the automated software tool injects a plain text tracer, e.g., CSSTESTTAG, as the value of the current key-value pair, and submits the resulting URL via the new browser window opened in step 809. For example, assuming the current key-value pair is the first key-value pair, the automated software tool initially submits in step 815 the URL illustrated in FIG. 9, (Col 6, lines 56-65))[Examiner interprets that system describing “readily identifiable text” such as “Cross-siteScriptingVulnerabilityFoundByCSSPr- obe” as non-malicious signaling script and supplied as attacker controllable web input as non-malicious indicator string injected in an attacker controllable source]
executing an injected client-side code, wherein the injected client-side code includes the indicator string (Gallagher, To confirm whether the web site is indeed vulnerable to a XSS attack, based on the location of the returned tracer value, the automated software tool submits a signaling script as input to the web site, and monitors the subsequently returned web page to determine whether the signaling script is executed by the local computer when the subsequently returned web page loads on the local computer, (Col 2, lines 33-40) The user-supplied data may be returned inside of a SCRIPT tag, such as "var Request_redir_url=`/isapi/acssrv.dll?action=error&commid=`;". The value for the redir_url from the URL becomes the value of the JavaScript variable named Request_redir_url…. The automated software tool successfully injects the script (i.e., alert("Cross-siteScriptingVulnerabilityFoundByCSSProbe.")), by including "var strBogus=`gotcha" after it because some web servers (e.g., MSN) always append "`;" after the user-supplied data, (Col 8, lines 25-53) FIG. 8, the automated software tool attempts in step 823 to exploit the web site by injecting a non-malicious script as described above. In an illustrative embodiment of the invention, a script such as <SCRIPT>alert("Cross-siteScriptingVulnerabilityFoundByCSSPr- obe.")</SCRIPT> is used. Any other readily identifiable text may alternatively be used, Thus, if the exploit is successful, the resulting HTML returned to the browser window will cause a pop up window to display the text "Cross-siteScriptingVulnerabilityFoundByCSSProbe," such as is illustrated in FIG. 11. (Col 9, lines 17-24)) [Examiner interprets that same identifiable string is physically part of the client-side Java Script that is executed as limitation above];
detecting the indicator string of the at least one data flow (Gallagher, The automated software tool submits a tracer value as input to a web site, and monitors the web page returned by the web site as a result of submitting the tracer value. When the tracer value is present in the returned web page, the automated software tool knows that the web site might be vulnerable to a cross-site scripting (XSS) attack, (see Col 2, lines 26-32), The user-supplied data may be returned inside of a SCRIPT tag, such as "var Request_redir_url=`/isapi/acssrv.dll?action=error&commid=`;". The value for the redir_url from the URL becomes the value of the JavaScript variable named Request_redir_url…. The automated software tool successfully injects the script (i.e., alert("Cross-siteScriptingVulnerabilityFoundByCSSProbe.")), by including "var strBogus=`gotcha" after it because some web servers (e.g., MSN) always append "`;" after the user-supplied data, (Col 8, lines 25-53) FIG. 8, the automated software tool attempts in step 823 to exploit the web site by injecting a non-malicious script as described above. In an illustrative embodiment of the invention, a script such as <SCRIPT>alert("Cross-siteScriptingVulnerabilityFoundByCSSPr- obe.")</SCRIPT> is used. Any other readily identifiable text may alternatively be used, Thus, if the exploit is successful, the resulting HTML returned to the browser window will cause a pop-up window to display the text "Cross-siteScriptingVulnerabilityFoundByCSSProbe," such as is illustrated in FIG. 11. In step 825, the automated software tool determines whether the exploit succeeded by monitoring the local system for the pop-up window. If the pop-up window is not displayed within a predetermined amount of time, e.g., by the time the returned HTML has finished loading or shortly thereafter, the automated software tool determines that the exploit was unsuccessful and proceeds to step 829. If, however, the pop-up window is displayed within the predetermined amount of time, the automated software tool determines that the exploit was successful, (Col 9, lines 17-37)) [Examiner interprets that system’s readily identifiable text as the indicator string and system detecting the same text resulting from processing of the injected script at the client side location as limitation above];
wherein the indicator string reached the sink of the at least one data flow as a result of the execution of the injected client-side code (Gallagher, To confirm whether the web site is indeed vulnerable to a XSS attack, based on the location of the returned tracer value, the automated software tool submits a signaling script as input to the web site, and monitors the subsequently returned web page to determine whether the signaling script is executed by the local computer when the subsequently returned web page loads on the local computer, (Col 2, lines 33-40) FIG. 8, the automated software tool attempts in step 823 to exploit the web site by injecting a non-malicious script as described above. In an illustrative embodiment of the invention, a script such as <SCRIPT>alert("Cross-siteScriptingVulnerabilityFoundByCSSPr- obe.")</SCRIPT> is used. Any other readily identifiable text may alternatively be used, Thus, if the exploit is successful, the resulting HTML returned to the browser window will cause a pop up window to display the text "Cross-siteScriptingVulnerabilityFoundByCSSProbe," such as is illustrated in FIG. 11. (Col 9, lines 17-24) In step 825, the automated software tool determines whether the exploit succeeded by monitoring the local system for the pop up window. If the pop up window is not displayed within a predetermined amount of time, e.g., by the time the returned HTML has finished loading or shortly thereafter, the automated software tool determines that the exploit was unsuccessful and proceeds to step 829. If, however, the pop up window is displayed within the predetermined amount of time, the automated software tool determines that the exploit was successful, (Col 9, lies 24-37)) [Examiner interprets that system dynamically confirming that the same indicator string included in the injected client side code is processed through the executable client side path as a result of execution of that code because execution of the indicator containing script causes the same identifiable text to be produced and detected]
performing mitigation action upon detecting the indicator string (Gallagher, if the exploit is successful, the resulting HTML returned to the browser window will cause a pop-up window to display the text "Cross-siteScriptingVulnerabilityFoundByCSSProbe,"… determines that the exploit was successful, and proceeds to step 827 where exploit data is written to the log file with information sufficient to identify the type of XSS attack to which the web site is susceptible. The log file may be reviewed by a user at a later time, e.g., to assist in debugging the subject web site, (Col 9, lines 24-42) the automated software tool may halt testing as soon as a first vulnerability is detected, (Col 10, lines 57-58)) [Examiner interprets system logging the exploit, identifying vulnerability type, assisting debugging, and halting testing upon detection as limitation above].
Examiner notes: Johns teaches detecting data reaching a security sensitive client-side sink during execution, [0044], [0046], [0051-0052], [0056] and Gallagher teaches providing the tracked input as readily identifiable non malicious text included in injected client-side code and detecting successful processing of that same identifiable text . Therefore, in combination Gallagher’s indicator sting is used as the particular data dynamically tracked through John’s identified source to security sensitive sink flow.
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Johns to include a concept of injecting a non-malicious indicator string; executing an injected client-side code, wherein the injected client-side code includes the indicator string; detecting the indicator string in the sink; wherein the indicator string reached the sink of the at least one data flow as a result of the execution of the injected client-side code performing mitigation action upon detecting the indicator string as taught by Gallagher for the purpose of submitting a tracer value as input to a web site, and monitors the web page returned by the web site as a result of submitting the tracer value. When the tracer value is present in the returned web page, the automated software tool knows that the web site might be vulnerable to a cross-site scripting (XSS) attack, [Gallagher: (Col 2, lines 26-32)].
Regarding claim 2, Johns and Gallagher teaches the method of claim 1, wherein the indicator string includes characters commonly used in hypertext markup language (HTML) (Johns, The web browser 102 may be configured to process HTML, CSS, or JavaScript languages, as well as such languages, [0020] The injected content may be crafted in such a way that a browser interprets it as client-side code or markup without the user's consent. This includes JavaScript injection, Hypertext Markup Language (“HTML”) injection, Cascading Style Sheets (“CSS”) injection, and the injection of other past or upcoming client-side scripting or markup languages (e.g., VBScript, SVG, etc.), [0031] HTML Injection: this type of attack allows the injection of malicious HTML tags. Hence, XSS is not limited to the injection of scripts, but can include injection of anything that can be expressed with HTML .This of course includes JavaScript enclosed in script tags or event handlers, and all the other tags that can be used for attacks (such as defacement or phishing). , [0035]) [Examiner interprets that tainted string including HTML tags/JS content as limitation above].
Although Johns teaches HTML injection and HTML tags but not an indicator string that includes HTML used characters, Johns does not explicitly teach:
the indicator string includes characters commonly used in hypertext markup language (HTML)
However, Gallagher further teaches:
the indicator string includes characters commonly used in hypertext markup language (HTML) (Gallagher, If the tracer value is not found within the HTML DOM, then the tool proceeds to step 819. However, if the tracer value is found within the HTML DOM,.. attempt to exploit the web site using a different tracer value to inject a custom HTML tag into the DOM, (Col 7, lines 16-29), Tracer value returned in an HTML tag. When a tracer value is returned in an HTML tag, the resulting HTML may appear similar to the following illustration where the tracer value was submitted as an input value: <INPUT type="text" value="CSSTESTTAG"> (Col 7, lines 42-46) Tracer value returned as attribute of IMG or A HREF tag, (Col 7, lines 64-65)) [Examiner interprets that system using tracer (i.e., indicator string) and tracer appearing in HTML/Dom context, injecting into HTML tags, attributes, scripts etc. as limitation above] Same motivation applies as claim 1.
Regarding claim 3, Johns and Gallagher teaches the method of claim 1, wherein the indicator string includes a unique character that indicates a specific attacker-controllable source of the at least one data flow (Johns, CTTP enables the server to report this information to the client and to report the source and other useful information when tainted content is encountered, [0060] the CTTP response first part 334 comprises a content type header 335, a global headers section 336, a taint version header 337 and taint information 338 in the body of the CTTP response. The taint information in this embodiment includes a taint range and an identifier of the source of the potentially tainted content, [0062] The CTTP response 505 further includes the taint information comprising the content type, taint range for the HTTP response body, and identifies the source of the tainted content, [0087] the taint information may include a taint range and an identifier of a source from which the tainted content originated, [0095]) [Examiner interprets that system using unique identifier for source tracking].
Although Johns teaches source identification but not the indicator string itself, Johns does not explicitly teach:
the indicator string includes a unique character that indicates a specific attacker-controllable source of the at least one data flow
However, Gallagher teaches:
the indicator string includes a unique character that indicates a specific attacker-controllable source of the at least one data flow (Gallagher, If the tracer value is not found within the HTML DOM, then the tool proceeds to step 819. However, if the tracer value is found within the HTML DOM,.. attempt to exploit the web site using a different tracer value to inject a custom HTML tag into the DOM, (Col 7, lines 16-29), Tracer value returned in an HTML tag. When a tracer value is returned in an HTML tag, the resulting HTML may appear similar to the following illustration where the tracer value was submitted as an input value: <INPUT type="text" value="CSSTESTTAG"> (Col 7, lines 42-46) Tracer value returned as attribute of IMG or A HREF tag, (Col 7, lines 64-65)) [Examiner interprets that system using specific tracer value such as “CSSTESTTAG” as limitation above] Same motivation applies as claim 1.
Regarding claim 4, Johns and Gallagher teaches the method of claim 1, further comprising: generating a notification, based on detection of the indicator string, to indicate detection of the DOM-XSS vulnerability (Johns, CTTP enables the server to report this information to the client and to report the source and other useful information when tainted content is encountered that suggests a vulnerability (detection). This may allow the verification of a potential vulnerability and facilitate debugging of the origin (source) of the data chunk depending on the taint information provided. The client web browser can then choose not to execute specific content included in the tainted chunks (mitigation). This additional information can be provided using a protocol that defines multiple response formats which differ in their verbosity of the server-side taint information, [0060] If the taint information indicates tainted content has been detected in the response body, process 600 can be configured to determine not to execute the tainted content or to report the source of the tainted content to a user of the client system, or both (operation 609). The client system can also mark the tainted segments of the standard network transfer protocol response body as tainted (operation 610), generate a document object model (operation 611) and propagate the marked tainted segments into the document object model (operation 612), [0094]) [Examiner interprets that system facilitating debugging of the origin, and reporting the source of the tainted content to a user as limitation above].
Although Johns clearly teaches reporting/indicating detection of a vulnerability to a user (i.e., notification) but for tainted content but not indicator string, Johns does not explicitly teach:
generating a notification, based on detection of the indicator string, to indicate detection of the DOM-XSS vulnerability
However, Gallagher teaches:
generating a notification, based on detection of the indicator string, to indicate detection of the DOM-XSS vulnerability (Gallagher, if the exploit is successful, the resulting HTML returned to the browser window will cause a pop-up window to display the text "Cross-siteScriptingVulnerabilityFoundByCSSProbe,"… determines that the exploit was successful, and proceeds to step 827 where exploit data is written to the log file with information sufficient to identify the type of XSS attack to which the web site is susceptible. The log file may be reviewed by a user at a later time, e.g., to assist in debugging the subject web site, (Col 9, lines 24-42) the log file is written as an HTML document which a user can review upon completion of the testing cycle… entries may be color coded to indicate whether each web page is vulnerable or safe….the log file may be any type of file sufficient to indicate to a user the type of exploit to which each Web page is vulnerable, (Col 9, lines 44-51)) [Examiner interprets that system creating log file (notification/report) that includes vulnerability type (i.e., detailed reporting) as limitation above]. Same motivation applies as claim 1.
Regarding claim 5, Johns and Gallagher teaches the method of claim 4, wherein the notification includes at least one of: the at least one data flow, the attacker-controllable source, the security sensitive sink, and a sanitization effectiveness. (Johns, CTTP enables the server to report this information to the client and to report the source and other useful information when tainted content is encountered that suggests a vulnerability (detection). This may allow the verification of a potential vulnerability and facilitate debugging of the origin (source) of the data chunk depending on the taint information provided. The client web browser can then choose not to execute specific content included in the tainted chunks (mitigation). This additional information can be provided using a protocol that defines multiple response formats which differ in their verbosity of the server-side taint information, [0060] The taint information in this embodiment includes a taint range and an identifier of the source of the potentially tainted content, [0062] The CTTP response 505 further includes the taint information comprising the content type, taint range for the HTTP response body, and identifies the source of the tainted content. The web browser 102 then receives at operation 506, the CTTP response including the taint information provided by the web server 105, [0087]) [Examiner interprets that system including source in report, and the tracking taint from end to end (data flow context) as limitation above].
Regarding claim 6, Johns and Gallagher teaches the method of claim 1, further comprising: retrieving the client-side code from a server; and downloading the client-side code (Johns, In response to the URL request 101 from the user, the web browser 102 may generate an HTTP request 104 and communicate that request to a web server 105 over a network such as over a TCP/IP connection 106, [0021] The web server 105 can then include the requested information into an HTTP response 108, which is then communicated back to the web browser 102, and provided to the user via displaying 113 a web page, image, video, or other online content. The HTTP response 108 may also comprise an HTTP response header and an HTTP response body, [0022] The CTTP response 505 further includes the taint information comprising the content type, taint range for the HTTP response body, and identifies the source of the tainted content. The web browser 102 then receives at operation 506, the CTTP response including the taint information provided by the web server 105, [0087] the response is received at a taint engine of the client system that is complementary to the taint engine of the server. The client system can then parse the taint information of the first subpart of the multipart network transfer protocol response in accordance with a content type stored in the content type header of the second subpart of the multipart network transfer protocol response (operation 607) and apply the taint information to the standard network transfer protocol response body (operation 608), [0093]) [Examiner interprets that system browsing requesting a URL and receiving server response content including HTML/JavaScript content for client side execution, client side being transmitted from server to browser in HTTP response as limitation above].
Regarding claim 8, Johns and Gallagher teaches the method of claim 1, wherein identifying the data flow further comprises: identifying at least one input string from a plurality of sinks; searching the at least one input string in a plurality of potential sources; and determining a pair of the attacker-controllable source and the security sensitive sink based on identifying the at least one input string in the attacker-controllable source, wherein the attacker-controllable source is selected from the plurality of potential sources (Johns, A necessary precondition of an XSS vulnerability is that an attacker can inject data (e.g., HTML tags, JavaScript code, or CSS markup) into a given web application and this data is later executed. Hence, XSS can be treated as an information flow problem. In a first step, sources that an attacker can potentially control need to be identified. Afterwards, how data is processed within the application and whether attacker-controlled data eventually reaches a security sensitive sink, needs to be analyzed. This kind of information flow analysis is a well-understood field and many different techniques exist to implement information flow analysis, [0044] upon receiving the message, the receiving environment can first parse the taint information and apply it to the received string data in the message. After this operation, the content of the network transfer protocol message can be processed at one or more corresponding parsers, such as taint-aware parsers 225 and 226. Thus, taint information belonging to the sent string data may be present at the beginning of the process. As a consequence, ..can reliably track the flow of potentially attacker-controlled data even where the data flow spans more than one execution environment (e.g., at both the client and server side), [0055] The taint information in this embodiment includes a taint range and an identifier of the source of the potentially tainted content, [0062]) {Examiner interprets that system identifying string segments (taint ranges), tracking propagation, and associating sink occurrence with source as limitation above].
Johns does not appear explicitly teach:
the non-malicious input string
However, Gallagher teaches:
the non-malicious input string (Gallagher, The automated software tool submits a tracer value as input to a web site, and monitors the web page returned by the web site as a result of submitting the tracer value. When the tracer value is present in the returned web page, the automated software tool knows that the web site might be vulnerable to a cross-site scripting (XSS) attack, (see Col 2, lines 26-32) In step 815, the automated software tool injects a plain text tracer, e.g., CSSTESTTAG, as the value of the current key-value pair, and submits the resulting URL via the new browser window opened in step 809. For example, assuming the current key-value pair is the first key-value pair, the automated software tool initially submits in step 815 the URL illustrated in FIG. 9. In step 817, the automated software tool receives HTML data back from the Web server to which the URL was submitted (e.g., server 120, FIG. 5), and the automated server tool scans the HTML to check whether the tracer value was returned by the server, (See Col 6, lines 59-67, Col 7, lines 1-3), In step 829, the automated software tool injects a tag-based tracer value, based on the results of the exploits attempted in step 823. ….Once the tag is found within the DOM, the automated software tool replaces <CSSTESTTAG> with the script tag and the non-malicious script exploit code. In step 831 the automated software tool checks the returned HTML and/or DOM to determine whether the server returned the new tracer tag in the returned web page. If so, the automated software tool proceeds to step 833, (See, Col 9, lines 53-67 Col 10, lines 1-4) injecting a non-malicious script as described above. In an illustrative embodiment of the invention, a script such as <SCRIPT>alert("Cross-siteScriptingVulnerabilityFoundByCSSPr- obe.")</SCRIPT> is used, (Col 9, lines 19-23)) [Examiner interprets that using plain text tracer (i.e., non-malicious indicator strings) into attacker-controlled inputs to determine whether user-controlled input propagates into returned content and using the injected content (i.e., benign marker) to detect vulnerability as limitation above] Same motivation applies as claim 1.
Regarding claim 9, Johns and Gallagher teaches the method of claim 1, wherein the attacker-controllable source is selected from a predetermined list of potential attacker-controllable sources (Johns, server side sources (data sources through which potentially malicious string data enters the web application) including HTTP parameters, HTTP headers, HTTP method and request line, and HTTP body and meta data of objects contained in such bodies, [0048] client-side sources (data sources through which potentially malicious string data enters the client-side JavaScript code) including document.URL and document.location, Referrer, PostMessage, and XMLHttpRequest response, [0050]) content can be determined to be potentially tainted that originates from server-side sources including HTTP parameters, HTTP headers, HTTP method and request line, and HTTP body and metadata objects, or from client-side sources such as XMLHttpRequest responses, PostMessages, referrers, document.URL and document.location. Also, the taint information may include a taint range and an identifier of a source from which the tainted content originate, [0095]) [Examiner interprets system disclosing source categories such as document.URL, document.location, HTTP parameter etc., as limitation above].
Regarding claims 10 and 11, Claims 10 and 11 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except additional elements:
Johns further teaches:
A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process (Johns, computer-readable medium from which a computer can read computer data and instructions, [0080]) the process comprising:
A system for detecting document object model cross-site scripting (DOM-XSS) vulnerability, comprising: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry (Johns, client-side XSS attacks are caused by malicious inputs to the client-side (i.e., any attacker controllable data in a web application's DOM), [0040] computer-readable code stored on any computer-readable medium, which when executed by a computer or other data processing system, can be adapted to cause the system to perform operations, [0111]), configure the system to:
Regarding claims 12-16 and 18-19, Claims 12-16 and 18-19 recite commensurate subject matter as claim 2-6 and 8-9. Therefore, they are rejected for the same reasons.
Regarding claim 20, Johns and Gallagher teaches the method of claim 1, wherein performing mitigation action comprises at least one action other than notifying the detection of the indicator string (Johns, As the taint information of all tokens is available during parse time, and the information is precise (as discussed above), the system described in this disclosure is capable of real-time mitigation, [0058] As soon as one of the parsers 225 and 226 encounter a tainted code token, the parsing process can be stopped and a security exception can be asserted. The attacker injected code can be reliably prevented from being executed because the attacker-injected syntax never leaves the parsing process. As long as both components (both the server and the browser) are used together and the mitigation option is enabled, the system described in this disclosure is not susceptible to string-based injection attacks. This means, vulnerabilities such as XSS, SQL injection or Command Injection are not exploited, [0059] If the taint information indicates tainted content has been detected in the response body, process 600 can be configured to determine not to execute the tainted content or to report the source of the tainted content to a user of the client system, or both (operation 609). The client system can also mark the tainted segments of the standard network transfer protocol response body as tainted (operation 610), generate a document object model (operation 611) and propagate the marked tainted segments into the document object model (operation 612), [0094]) [Examiner interprets that system detecting tainted content, preventing execution and reporting the source of the tainted content (i.e., indicator string) as limitation above];
Although Johns clearly teaches performing mitigation such as stopping parsing, asserting a security exception, refusing exception, but for tainted content but not indicator string, Johns does not explicitly teach:
performing mitigation action comprises at least one action other than notifying the detection of the indicator string
However, Gallagher teaches:
performing mitigation action comprises at least one action other than notifying the detection of the indicator string (Gallagher, solutions for preventing cross site scripting attacks have been proposed, e.g., by performing validation on received input to ensure that the input does not contain any malicious code, or encoding characters with special meaning in HTML, (Col 1, lines 63-66)) [Examiner interprets that system implementing input validation and encoding (i.e., sanitization) as limitation above] Same motivation applies as claim 1.
Regarding claim 22, Johns and Gallagher teaches the method of claim 1, wherein the indicator string is not executed as code at the security sensitive sink (Johns, As soon as one of the parsers 225 and 226 encounter a tainted code token, the parsing process can be stopped and a security exception can be asserted. The attacker injected code can be reliably prevented from being executed because the attacker-injected syntax never leaves the parsing process. As long as both components (both the server and the browser) are used together and the mitigation option is enabled, the system described in this disclosure is not susceptible to string-based injection attacks. This means, vulnerabilities such as XSS, SQL injection or Command Injection are not exploited, [0059] If the taint information indicates tainted content has been detected in the response body, process 600 can be configured to determine not to execute the tainted content or to report the source of the tainted content to a user of the client system, or both (operation 609). The client system can also mark the tainted segments of the standard network transfer protocol response body as tainted (operation 610), generate a document object model (operation 611) and propagate the marked tainted segments into the document object model (operation 612), [0094]) [Examiner interprets that system detecting tainted content, preventing execution as limitation above];
Johns does not appear explicitly teach:
the non-malicious indicator string
However, Gallagher teaches:
the non-malicious indicator string (Gallagher, The automated software tool submits a tracer value as input to a web site, and monitors the web page returned by the web site as a result of submitting the tracer value. When the tracer value is present in the returned web page, the automated software tool knows that the web site might be vulnerable to a cross-site scripting (XSS) attack, (see Col 2, lines 26-32) In step 815, the automated software tool injects a plain text tracer, e.g., CSSTESTTAG, as the value of the current key-value pair, and submits the resulting URL via the new browser window opened in step 809. For example, assuming the current key-value pair is the first key-value pair, the automated software tool initially submits in step 815 the URL illustrated in FIG. 9. In step 817, the automated software tool receives HTML data back from the Web server to which the URL was submitted (e.g., server 120, FIG. 5), and the automated server tool scans the HTML to check whether the tracer value was returned by the server, (See Col 6, lines 59-67, Col 7, lines 1-3), In step 829, the automated software tool injects a tag-based tracer value, based on the results of the exploits attempted in step 823. ….Once the tag is found within the DOM, the automated software tool replaces <CSSTESTTAG> with the script tag and the non-malicious script exploit code. In step 831 the automated software tool checks the returned HTML and/or DOM to determine whether the server returned the new tracer tag in the returned web page. If so, the automated software tool proceeds to step 833, (See, Col 9, lines 53-67 Col 10, lines 1-4) injecting a non-malicious script as described above. In an illustrative embodiment of the invention, a script such as <SCRIPT>alert("Cross-siteScriptingVulnerabilityFoundByCSSPr- obe.")</SCRIPT> is used, (Col 9, lines 19-23)) [Examiner interprets that using plain text tracer (i.e., non-malicious indicator strings) into attacker-controlled inputs to determine whether user-controlled input propagates into returned content and using the injected content (i.e., benign marker) to detect vulnerability as limitation above] Same motivation applies as claim 1.
Regarding claim 23, Johns and Gallagher teaches the method of claim 1, wherein the indicator string is not executed as code. (Johns, CTTP enables the server to report this information to the client and to report the source and other useful information when tainted content is encountered that suggests a vulnerability (detection). This may allow the verification of a potential vulnerability and facilitate debugging of the origin (source) of the data chunk depending on the taint information provided. The client web browser can then choose not to execute specific content included in the tainted chunks (mitigation). This additional information can be provided using a protocol that defines multiple response formats which differ in their verbosity of the server-side taint information, [0060] If the taint information indicates tainted content has been detected in the response body, process 600 can be configured to determine not to execute the tainted content or to report the source of the tainted content to a user of the client system, or both (operation 609). The client system can also mark the tainted segments of the standard network transfer protocol response body as tainted (operation 610), generate a document object model (operation 611) and propagate the marked tainted segments into the document object model (operation 612), [0094]) [Examiner interprets that client choosing not to execute specific content as limitation above].
Johns does not appear explicitly teach:
the non-malicious indicator string
However, Gallagher teaches:
the non-malicious indicator string (Gallagher, The automated software tool submits a tracer value as input to a web site, and monitors the web page returned by the web site as a result of submitting the tracer value. When the tracer value is present in the returned web page, the automated software tool knows that the web site might be vulnerable to a cross-site scripting (XSS) attack, (see Col 2, lines 26-32) In step 815, the automated software tool injects a plain text tracer, e.g., CSSTESTTAG, as the value of the current key-value pair, and submits the resulting URL via the new browser window opened in step 809. For example, assuming the current key-value pair is the first key-value pair, the automated software tool initially submits in step 815 the URL illustrated in FIG. 9. In step 817, the automated software tool receives HTML data back from the Web server to which the URL was submitted (e.g., server 120, FIG. 5), and the automated server tool scans the HTML to check whether the tracer value was returned by the server, (See Col 6, lines 59-67, Col 7, lines 1-3), In step 829, the automated software tool injects a tag-based tracer value, based on the results of the exploits attempted in step 823. ….Once the tag is found within the DOM, the automated software tool replaces <CSSTESTTAG> with the script tag and the non-malicious script exploit code. In step 831 the automated software tool checks the returned HTML and/or DOM to determine whether the server returned the new tracer tag in the returned web page. If so, the automated software tool proceeds to step 833, (See, Col 9, lines 53-67 Col 10, lines 1-4) injecting a non-malicious script as described above. In an illustrative embodiment of the invention, a script such as <SCRIPT>alert("Cross-siteScriptingVulnerabilityFoundByCSSPr- obe.")</SCRIPT> is used, (Col 9, lines 19-23)) [Examiner interprets that using plain text tracer (i.e., non-malicious indicator strings) into attacker-controlled inputs to determine whether user-controlled input propagates into returned content and using the injected content (i.e., benign marker) to detect vulnerability as limitation above] Same motivation applies as claim 1.
Claim 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Johns (US 20170318045 A1) in view of Gallagher (US 7343626 B1) in further view of Yampolskiy (US 20160173521 A1).
Regarding claim 7, Johns and Gallagher teaches the method of claim 1, further comprising:
Johns and Gallagher does not explicitly teach:
periodically repeating the detection of the DOM-XSS vulnerability
However, Yampolskiy teaches:
periodically repeating the detection of the DOM-XSS vulnerability (Yampolskiy, the security signal collection module 210 comprises a continuous Internet scans module 212 for performing continuous scans of Internet data to collect data associated with an entity. The security signal collection module 210 can also comprises a real-time scans collection module 213 for collecting data in real time, such as collecting real-time threat intelligence/data and collecting data in real time from a malicious IP feed, which can include digesting 2000+ bad (IPS) per second, [0039] common vulnerabilities which can be detected includes cross-site scripting (XSS), DOM-based Cross Site Scripting (DOM-XSS), [0055] the scorecard system 200 can calculate, for example on a periodic basis, updated cybersecurity risk scores for the entity based on data collected from the one or more data sources. The scorecard system 200 can then compare one or more of the updated cybersecurity risk scores to a threshold. In some embodiments, if the one or more updated cybersecurity risk scores is below the threshold, the scorecard system 200 can transmit, via the cybersecurity risk assessment portal, an alert, [0092] a job can be invoked periodically, wherein each job can be responsible for downloading, parsing, and storing data, such as at block 408, from data sources 406. Each job may download, parse, and store data collected from a security signal collection feed, such as, for example, a hacker forum site, [0093]) [Examiner interprets that system detecting DOM XSS vulnerabilities by performing such detection repeatedly via periodically invoked jobs, periodic recalculation of cybersecurity risk scores , continuous and real time scanning mechanisms as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Johns and Gallagher to include a concept of periodically repeating the detection of the DOM-XSS vulnerability as taught by Yampolskiy for the purpose of detecting cross-site scripting (XSS), DOM-based Cross Site Scripting (DOM-XSS), [Yampolskiy : 0055].
Regarding claim 17, Claim 17 recite commensurate subject matter as claim 7. Therefore, it is rejected for the same reasons.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Johns (US 20170318045 A1) in view of Gallagher (US 7343626 B1) in further view of Berger (US 20220100869 A1).
Regarding claim 21, Johns and Gallagher teaches the method of claim 1, wherein performing the mitigation action includes at least one of the group consisting of: inserting a sanitizing code, updating code to perform filtering, adding code for input validation, and adding a content security policy (CSP) (Berger, When data reaches code that interacts with a data sink, its trust and sanitization status may be checked to determine whether unchecked/not sanitized data reaches the data sink. Detection of not sanitized input data at data sinks may be reported by the monitoring system as vulnerability, [0019] instrumentation of payload code may be performed by manipulating payload code at run-time of the application e.g., when the payload code is loaded for execution…. inject corresponding sensor code to the loaded code. The sensor code may then detect the receipt, manipulation, sanitization, and usage of input data. Further, placed sensors and the agent may cooperate to track the propagation of input code through the monitored application, [0038] Sanitization is performed with respect to usage in specific data sinks. Sanitization directed to the usage of sanitized data by a data base may be different to sanitation directed to the usage of sanitized data e.g., to create the content of a web page. The sanitization may analyze and manipulate the received input data 114 to neutralize potential vulnerable portions of the received input data for a specific type of data sink. The sanitization method may create a sanitized version 115 of the input data, [0045] The sink sensor may, in some embodiments, also perform countermeasures to prevent detected attacks. Sink sensor may either perform an on-demand sanitization of identified malicious data, prevent the potentially malicious interaction with the data sink but otherwise continue normal program execution, or terminate normal program execution before the interaction with the data sink is performed, e.g., by throwing an exception, [0049]) [Examiner interprets that system performing mitigation actions including sanitization of input data and injection of sensor code into application at runtime and the injected code analyzing and manipulating input data to neutralize vulnerable portions as inserting a sanitizing code, adding code for input validation/ or filtering].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Johns and Gallagher to include a concept of performing the mitigation action includes at least one of the group consisting of: inserting a sanitizing code, updating code to perform filtering, adding code for input validation, and adding a content security policy (CSP) as taught by Berger for the purpose of performing countermeasures to prevent detected attacks [Berger:0049].
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.N.P./Examiner, Art Unit 2436
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights