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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/26/2026 has been entered.
Response to Amendment
In the response filed on 01/26/2026. The applicant amended claims 6 is amended. Claims 22 and 23 are added.
Response to Arguments
With respect to claims objections:
Applicant’ claim amendments and remarks filed on 01/26/2026 have been fully considered and overcame the claim objections as presented in the final office action filed 10/24/2025. Therefore, objections have been withdrawn.
With respect to 135 U.S.C. §103 rejections:
Applicant's arguments filed on 01/26/2026 have been received and entered. Applicant's arguments with respect to the newly amended independents “Claim Rejections - 35 USC § 103” remarks pages 1-6, have been considered but are moot in view of the newly find prior art presented below.
Claim Objections
Claim 4 is objected to because of the following informalities: The phrase “based on the detecting of the indicator string” is grammatically improper. It should read as “based on the detection of the indicator string”. Appropriate correction is required.
Claims 5 and 15 are objected to because of the following informalities: The phrase “sanitization effectivity” should read as “sanitization effectiveness ”. Appropriate correction is required.
Claim 20 is objected to because of the following informalities: The phrase “performing the mitigation action performs” and “notifying of the detecting” are unnecessary repetitive and grammatically improper. Examiner suggests “wherein the mitigation action comprises at least one action other than notifying of detection of the indicator string”. Appropriate correction is required.
Claim 21 is objected to because of the following informalities: The phrase “at least one of the groups consisting of” is grammatically unclear. The claim recites only single group of alternatives. It is unclear whether the claim intends to selects one or mor groups or one or more actions within a group. Appropriate correction is required.
Claim 23 is objected to because of the following informalities: The phrase “the client” lacks proper antecedent basis. The independent claim recites “client-side code” but does not introduce a client as claim element. Thus, it is unclear what “the client” refers to. Appropriate correction is required.
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, wherein the client-side code includes a DOM representation of a web page (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] 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];
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 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].
executing an injected client-side code, wherein the injected client-side code includes the 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) 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 35-42) 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 43-46) 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,", (Col 9, lines 24-26) 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, (Col 9, lines 65-67, col 10 lines 1-3))[Examiner interprets that system submitting injected code to the website and returning in a page loaded by browser , checking whether the script is executed by the local computer when the page loads, and disclosed alerts such as Cross-siteScriptingVulnerabilityFoundByCSSProbe is identifiable marker embedded in executable code, thus reads the limitation];
detecting the indicator string in the security sensitive sink 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), 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…, in order to ensure that the web site being scanned will behave exactly as in a user's browser window, the automated software tool scans the document object model (DOM) of the web page. The DOM of the returned HTML web page is exposed by Internet Explorer's HTML Rendering Engine (e.g., using mshtml.dll, dispex.dll, iesetup.dll, mshtml.tlb, mshtmled.dll, and mshtmler.dll), (See Col 6, lines 65-67, Col 7, lines 1-10), However, if the tracer value is found within the HTML DOM, the automated software tool also analyzes in step 817 where the tracer value was found, (See Col 7, lines 17-20), Examples of locations that are indicative of known exploits include: examples 1-5 tracer value returned as text displayed in body of web page, in an HTML tag, as attribute of IMG or A HERF tag, as part of block of script, in HTML comments (i.e., security sensitive sink), (See Col 7, lines 30-67, Col 8, lines 1-65) in step 821, the automated software tool determines whether the location in which the tracer value was found corresponds to a special case for which a known exploit exists. If so, the automated software tool attempts in step 823 to exploit the Web site's vulnerability to a cross site scripting attack based on the location in which the tracer value was found in step 817, (See col 7, lines 20-26)) [Examiner interprets that system injecting a tracer into an input parameter , checking whether that same tracer appears in the returned HTML/DOM, detecting the indicator by parsing the returned DOM and identifying specific DOM locations such as HTML contents, attributes, script blocks (i.e., sinks) where tracer appears, analyzing the location where it appears as limitation above].
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].
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; 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 the detecting 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 the detecting of the indicator string, to indicate detection of the DOM-XSS vulnerability
However, Gallagher teaches:
generating a notification, based on the detecting 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 effectivity (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 the mitigation action performs at least one action other than notifying of the detecting 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 the mitigation action performs at least one action other than notifying of the detecting of the indicator string
However, Gallagher teaches:
performing the mitigation action performs at least one action other than notifying of the detecting 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 at the client (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 groups 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 groups 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 8949990 B1: “relates to using scripts executed by web browsers to detect XSS vulnerabilities in dynamic URLs (Uniform Resource Locator) and collect XSS vulnerable URLs”
US 20180198807 A1: “relates to a client, a network, a method and a product for detecting client-side attacks in a web application”
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
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436