Protecting documents from cross-site scripting attacks

In various implementations, an embedded document receives untrusted content from a containing document, where the embedded document is in the containing document. In some cases, the untrusted content is received by the containing document from a server and is forwarded to the embedded document without rendering the untrusted content in the containing document. Instead, the untrusted content is rendered in the embedded document. A sandbox policy is enforced on the embedded document such that the rendered untrusted content is restricted from accessing data associated with the containing document. The untrusted content may comprise malicious code that when rendered executes an XXS attack that attempts to access the data associated with the containing document. However, because the untrusted content is rendered in the embedded document, the malicious code may be denied access to the data, thereby preventing the XSS attack from succeeding.

BACKGROUND

Cross-Site Scripting (XSS) is a computer security vulnerability typically found in web applications. XSS allows malicious users, or attackers, to inject code into web pages that are loaded by other users. In some cases, the injected code can allow an attacker to access sensitive data, such as private user data. For example, the attacker may gain access to a user's login credentials, which may be stored as a hash value in a cookie. With such private data, the attacker may perform illicit actions by being authenticated using the user's login credentials or otherwise appropriating the user's private user data. Such attacks may be especially troublesome where the user whose private data was compromised is an administrator or superuser.

XSS vulnerabilities have been exploited and reported since the 1990s. Various approaches have been employed to protect against XSS attacks. In some cases, developers may turn to web document authoring tools, such as Adobe® Experience Manager, to assist in authoring web sites that are more resilient to XSS attacks. However, year after year, XSS continues to be ranked as one of the most prevalent computer security vulnerabilities. It has therefore become apparent that XSS vulnerabilities are likely to exist even where substantial measures are taken to protect against XSS attacks.

SUMMARY

In accordance with aspects of the present disclosure, untrusted content, which may or may not include malicious code capable of an XSS attack, is received by a containing document (e.g. a web page), such as a HyperText Markup Language (HTML) document. The containing document forwards the untrusted content to an embedded document, which can be in an inline frame (iframe) of the containing document, without rendering the untrusted content in the containing document. The untrusted content may instead be rendered in the embedded document. A sandbox policy is enforced such that even if the rendered untrusted content comprises malicious code, the rendered untrusted content is unable to access sensitive data associated with the containing document. As such, the rendered untrusted content may be unable to access cookies, local storage (e.g. HTML local storage), or other repositories that may include sensitive data.

In addition to untrusted content, in some implementations, the containing document may optionally provide trusted content to the embedded document, which is rendered in the embedded document. Furthermore, the embedded document may be initially provided and/or loaded with content. The content provided by the containing document, and/or the initial content (e.g. from a server) may comprise one or more forms, stylings, and/or or other elements that may be rendered in the embedded document. One or more forms in the embedded document may be utilized to receive new untrusted content, and/or modifications to the untrusted content that was received from the containing document, or other content of the embedded document. The new and/or modified content may be sent by the embedded document to the containing document. The containing document may forward the content to a server without rendering the content. Thus, the sensitive data is further protected from any malicious code that could be included in the new and/or modified content.

DETAILED DESCRIPTION

Various terms are used throughout this description. Definitions of some terms are included below to provide a clearer understanding of the ideas disclosed herein:

The term “containing document” refers to a document that includes one or more other documents embedded therein.

An “embedded document” refers to a document that is embedded in a containing document. In some cases, a document may be both an embedded document and a containing document, where another document is embedded in the document.

A “sandbox policy” refers to a policy that restricts how a document can interact with a resource of another document. The sandbox policy can be enforced by a document viewer used to view the documents. An example, of a sandbox policy is a same-origin policy that restricts how a document or script loaded from one origin can interact with a resource from another origin. Typically, documents subject to a sandbox policy, such as those loaded from different origins, are isolated from each other in terms of access to each other's resources.

A “document authoring tool” refers to software that one or more authors can utilize to construct a document, such as a web document. Among other things, a document authoring tool may be used by an author to add components to a document. The components can each include blocks of preconfigured content (e.g. markup, JavaScript, and/or other code), which may optionally be modified and/or supplemented by the author.

The term “trusted content” or “trusted data” refers to content data from a trusted source.

The term “untrusted content” or “untrusted data” refers to content data from an untrusted source that can include an XSS attack payload. Examples include immediate user input, data received from a server that may have been provided to the server by a malicious user, as well as values obtained from a history token read from a uniform resource locater (URL) fragment.

“Sensitive data” refers to data comprising information protected against unwarranted disclosure. Examples of sensitive data include private data, personal data, confidential data, classified data, financial data, federally protected data, state protected data, user passwords, answer's to security questions, social security numbers, and more.

Cross-Site Scripting (XSS) is a computer security vulnerability typically found in web applications. XSS allows malicious users, or attackers, to inject code into web pages that are loaded by other users. In some cases, the injected code is malicious code that attempts to provide the attacker with access to sensitive data, such as private user data. The injected code can be included in untrusted content provided to the web pages. Although various approaches have been employed to protect against XSS attacks, XSS continues to be ranked as one of the most prevalent computer security vulnerabilities.

Aspects of the present disclosure relate to protecting documents from XSS attacks. In certain respects, an embedded document is included in a containing document. In some cases, the embedded document may be in an inline frame (iframe) of the containing document, which can be a markup language document, such as a HyperText Markup Language (HTML) document. The containing document includes a content handler that can receive untrusted content and optionally trusted content, and can forward at least some of the content to the embedded document. The embedded document also includes a content handler, which can receive the content sent by the content handler of the containing document. A content processor of the embedded document can process at least some of the received content and can be used to render untrusted content, and optionally trusted content, received from the containing document.

In further respects, the containing document can forward the untrusted content to the embedded document without rendering the untrusted content. Furthermore, a sandbox policy, such as a same-origin policy, can restrict the embedded document from accessing one or more resources of the containing document. As such, even if the untrusted content includes malicious code that attempts an XSS attack, the containing document is protected, as the rendered untrusted content is unable to access sensitive data associated with the containing document. In some cases, the sandbox policy is established by providing the embedded document in a different domain as the containing document. However, in some implementations, even where the embedded document is in the same domain, the sandbox policy can be enforced. For example, a sandbox policy may be established by treating the embedded document as having a different origin than the containing document.

In some cases, one or more forms in the embedded document may be utilized to receive new untrusted content, and/or modifications to the untrusted content that was received from the containing document, or other content of the embedded document (e.g. content from a server). The forms may be rendered from trusted and/or untrusted content received by the embedded document, and/or from content initially provided and/or loaded on the embedded document. The new and/or modified content may be processed by the content processor of the embedded document and sent by the content handler of the embedded document. The content handler of the containing document may receive the content and forward the content to a server without rendering the content. Thus, sensitive data associated with the containing document is further protected from malicious code that could be included in the new and/or modified content.

Among other components not shown, system100includes any number of user devices, such as user devices102aand102bthrough102n, network104, and one or more servers, such as servers106aand106bthrough106n. It should be understood that any number of servers and user devices may be employed within system100within the scope of the present disclosure. Each may comprise a single device or multiple devices cooperating in a distributed environment. Additionally, other components not shown may also be included within the distributed environment.

It should further be understood that system100shown inFIG. 1is an example of one suitable computing system architecture. Each of the servers and user devices shown inFIG. 1may be implemented via a computing device, such as computing device500, later described with reference toFIG. 5, for example. The components may communicate with each other via network104. Network104may be wired, wireless, or both. Network104may include multiple networks, or a network of networks, but is shown in simple form so as not to obscure aspects of the present disclosure. By way of example, network104can include one or more wide area networks (WANs), one or more local area networks (LANs), one or more public networks, such as the Internet, and/or one or more private networks. Where network104includes a wireless telecommunications network, components such as a base station, a communications tower, or even access points (as well as other components) may provide wireless connectivity. Networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. Accordingly, network104is not described in significant detail.

In various implementations, user devices102aand102bthrough102nare computing devices that are capable of accessing the Internet, such as the World Wide Web. As such, the user devices might take on a variety of forms, such as a personal computer (PC), a laptop computer, a mobile phone, a tablet computer, a wearable computer, a personal digital assistant (PDA), an MP3 player, a global positioning system (GPS) device, a video player, a handheld communications device, a smart phone, a smart watch, a workstation, any combination of these delineated devices, or any other suitable device.

User devices102aand102bthrough102ncan include one or more processors, and one or more computer-readable media. The computer-readable media may include computer-readable instructions executable by the one or more processors. The instructions may correspond to one or more applications, such as document viewer108, shown on user device102b. It is noted that document viewer108could at least partially be on one or more servers. Additionally, although document viewer108is described any suitable application may be employed for implementing aspects of the present disclosure.

Document viewer108can comprise a browser, such as a web browser capable of viewing web pages. Document viewer108is configured to communicate with one or more servers106aand106bthrough106nvia network104, which may comprise the Internet. In doing so, document viewer108can receive content from one or more servers and can render the content for a user in the form of a document, such as containing document110inFIG. 1. Document viewer108can further be used to render one or more documents in containing document110, such as embedded document112.

In the present implementation, containing document110is a markup language document, and more particularly an HTML document. Embedded document112is within an iframe of containing document110. In accordance with implementations of the present disclosure, a sandbox policy is enforced on embedded document112that restricts the embedded document from accessing one or more resources of containing document110.

The sandbox policy can be enforced by document viewer108and can isolate containing document110and embedded document112from each other in terms of access to each other's resources, or at least may prevent embedded document112from accessing resources of containing document110. Thus, for example, embedded document112may be unable to access sensitive data associated with containing document110, which may be included in one or more cookies (e.g. authentication cookies), tokens (e.g. authentication tokens), and local storage (e.g. HTML local storage) of containing document110. As an example, embedded document112may be unable to access a document model object (DOM) of containing document110.

The sensitive data associated with containing document110can comprise private user data. For example, a user on user device102bmay log into a user account via document viewer108, such that private user data is accessible to containing document110. The private user data may include an authentication hash for the user account that could be in an authentication cookie. If malicious code were run in document viewer108the private user data may be compromised. For example, an XSS attack could be executed to provide an attacker with the private user data. With such private data, the attacker may perform illicit actions by being authenticated using the user's login credentials or otherwise appropriating the user's private user data. However, the sandbox policy can prevent malicious code executed in embedded document112from accessing the sensitive data.

In some implementations, the sandbox policy is established by providing embedded document112in a different domain as containing document110. In doing so, document viewer108may enforce the sandbox policy on embedded document112and containing document110as a same-origin policy. However, in some implementations, even where the embedded document is in the same domain, the sandbox policy can be enforced. For example, a sandbox policy may be established by treating the embedded document as having a different origin than the containing document. For example, code (e.g. a selection value) in the containing document may indicate to document viewer108that a sandbox policy should be enforced on embedded document112. As one specific example, HTML5 includes a sandbox attribute that enables a set of extra retractions for the content in an iframe. The sandbox attribute can be used with allow-same-origin disabled, such that iframe content is not treated as being from the same origin as containing document110. In this way, document viewer108may selectively impose a sandbox policy, such as the same-origin policy on embedded document112and/or other embedded documents included in containing document110.

While the sandbox policy can protect containing document110from malicious code in embedded document112, malicious code running on containing document110could still have access to sensitive data of containing document110. For example, untrusted content received by containing document110could include malicious code capable of executing an XSS attack if run on containing document110. In accordance with implementations of the present disclosure, untrusted content received by containing document110not run on containing document110. Instead, the untrusted content may be forwarded to embedded document112without rendering the untrusted content on containing document110. The untrusted content may be rendered on embedded document112and subject to the sandbox policy.

In some implementations, embedded document112, and optionally other embedded documents in containing document110that are subject to a sandbox policy, are displayed in document viewer108without a visual indication that the embedded document is a separate document from containing document110. In this way, the untrusted content may be rendered to appear as being rendered on containing document110, while actually being rendered on the embedded document. Thus, containing document110may be protected from XS S attacks in a manner that is visually unnoticeable to the user.

Referring now toFIG. 2A,FIG. 2Aillustrates exemplary containing and embedded documents in accordance with implementations of the present disclosure. In particular, containing document210and embedded document212correspond respectively to containing document110and embedded document112inFIG. 1.

In the implementation shown, containing document210includes content handler220and optionally content processor222. Embedded document212includes content handler224and content processor226. Content handler220is configured to receive content from one or more content inputs, such as content input230. At least some of the content received by content handler220can comprise untrusted content. Furthermore, content handler220may optionally receive at least some trusted content.

Content received by content handler220can be from one or more servers, such as servers106aand106bthrough106n. As an example, a user could log into a user account, for example, on containing document110, and can receive at least some of the content from an authenticated communication with a server based on the user's login credentials. In addition, or instead, content may be received from an unauthenticated communication with the server.

As another option, at least some of the content received by content handler220may be from immediate user input. For example, a user could enter the content into containing document110during a browsing session. The content may be entered as input via one or more forms on containing document110, such as an HTML form, or a web form. The forms may be rendered trusted content initially loaded with containing document110, or from trusted content later received by content handler220, such as trusted content236. Content entered into one or more forms on containing document110may be provided to a server, such as any of servers106aand106bthrough106nin an authenticated or unauthenticated manner by content handler220. Content received in this manner may be untrusted content that is not rendered on containing document110.

Where trusted content is received by content handler220, content handler220may optionally provide at least some of the trusted content to content processor222for processing. An example of such trusted content is trusted content236, shown inFIG. 2A. Trusted content236may be processed by content processor222to render trusted content236on containing document210.

Where untrusted content is received by content handler220, content handler220may forward at least some of the untrusted content to embedded document212. The untrusted content can be forwarded without being rendered on containing document210. An example of such untrusted content is untrusted content232shown inFIG. 2A. At least some trusted content received by content handler220may optionally also be forwarded to embedded document212, and may or may not be rendered on containing document210. An example of such trusted content is trusted content234, shown inFIG. 2A.

Content handler224can receive content from content handler220and can provide the received content to content processor226, as shown. Content processor226can process the content, which can include rendering the content on embedded document212. Examples of rendered content are shown as rendered content240a,240b, and240c, although more or fewer rendered content may be on embedded document212.

In some implementations, content handlers220and224are implemented using respective scripts, which may be JavaScript, or other code in containing document210and embedded document212that allows containing document210and embedded document212to communicate with one another. In various implementations, content can be sent from one content handler to the other utilizing one or more messages, such as message242in cross-document communication. In some implementations, each message comprises a string that corresponds to the content. In some cases, the string comprises markup (e.g. HTML), JavaScript Object Notation (JSON), and/or other information corresponding to the content. Content processor226can extract the code and/or values from the one or more messages to provide the rendered content.

In some implementations, content handlers220and224can implement messaging using postMessage functions for cross-document communication between containing document210and embedded document212(e.g. using message events). The postMessage functions may be provided by an HTML application programming interface (API), such as the window.postMessage API. Content handlers220and224may further comprise one or more event listeners for receiving message events corresponding to the messages. The event listeners may also be provided using an HTML API. Using the event listeners, an event bus may be established between the documents, where the event bus is a one way bus in some implementations, or is a two way bus in other implementations.

In implementations where multiple embedded documents are included in containing document210, content handler220may be capable of communicating with each of the embedded documents, which may optionally be over respective event busses. In some cases, content handler220may determine which received content to send to which embedded document. However, at least some of the content may be provided to multiple embedded documents. For example the same trusted content may optionally be provided to and rendered by multiple embedded documents. In some cases, the content processor in an embedded document determines whether or not received content is intended for the embedded document. The content processor may render the content based on the content being intended for the embedded document or may refrain from rendering based on the content not being intended for the embedded document.

Rendered content240a,240b, and240cmay be rendered from untrusted and/or trusted content. In being executed, any of the rendered content may attempt an XSS attack. However, due to the sandbox policy, sensitive data in containing document210is protected from being accessed in the XSS attack.

Rendered content can generally comprise any content capable of being rendered in an embedded document, such as an iframe. As indicated above, the content may be received by content processor226as a string in one or more messages. In some cases, the content (e.g. the string) comprises one or more values, which can be provided as input to code that generates the rendered content. At least some of the code could optionally be provided by the same one or more messages as the string. In addition, or instead, at least some of the code could be provided by one or more different messages, either as untrusted and/or trusted content. In some cases, at least some of the code corresponds to content that was initially provided by a server in loading embedded document112, or could otherwise be from a source other than containing document210, such as another embedded document, or immediate user input to embedded document112. Content228is an example of such content.

As indicated above, in addition to, or instead of comprising one or more values, the content (e.g. the string) can include code for the rendered content. The code may comprise markup that is extracted from one or more messages by content processor226. The code may be at least partially incorporated into rendered content. In some cases, that code may modify rendered content in embedded document212, content processor226, and/or content handler224.

In some cases, the rendered content comprises a script, such as JavaScript, or other malicious code. The malicious code may have been injected into a document (e.g. containing document210, embedded document212, or another document) by another user and may have been stored on a server as untrusted content, such as one of servers106aand106bthrough106n. The untrusted content may have later been received by content handler220, and subsequently by content handler224as untrusted content232. As another example, the untrusted content may have been from immediate user input to containing document210.

The malicious code, when executed may attempt an XSS attack. However, due to the sandbox policy, sensitive data in containing document210is protected from being accessed in the XSS attack. For example, document viewer108may prevent embedded document212from accessing cookies, tokens, local storage, and other potential sources of sensitive data accessible to containing document210, such as the DOM of containing document210. Utilizing content handlers220and224controlled communications can be made between containing document210and embedded document212. This can allow containing document210to provide embedded document212with access to content from containing document210without embedded document212being able to directly access that content.

FIG. 2Ashows message242being provided from containing document210to embedded document212. As indicated above, and further described with respect toFIG. 2B, in some implementations, embedded document212can optionally provide one or more messages that is received by containing document210. Referring toFIG. 2B,FIG. 2Billustrates exemplary containing document210and embedded document212in accordance with implementations of the present disclosure.

An example of the one or more messages is shown as message250inFIG. 2B. Message250can be used to send content from content handler224that is received by content handler220. The content can be sent by content handler224similar to how content is sent by content handler220, as described above. Thus, a postMessage could be used to send and event message over the event bus. Furthermore, the content can be sent as a string in one or more messages and content handler220may comprise an event listener to detect the one or more messages. In some implementations, content processor226receives the content to be sent by content handler224and serializes the content into one or more strings. Each message sent by content handler224may include one of the strings.

The content sent by content handler224and received by content handler220can be from any of a variety of possible sources. In some cases, the content is received using at least one rendered content, such as rendered content240aand240c. For example, rendered content240amay comprise a form, such as a text box. As another example, rendered content240cmay comprise a text field. Content received from immediate input (e.g. as textual input) of a user into one or both of those forms may be included in untrusted content252. Unlike rendered content240aand240c, rendered content240bmay not comprise a means to obtain user input. For example, rendered content240bmay comprise text and/or other non-executable content displayed in embedded document212.

At least some of content received by content handler220of containing document210may be forwarded to a server, such as one or more of servers106aand106bthrough106n. The content can be forwarded to the same and/or different servers as used to receive content (e.g. over content input230). Content handler220is configured to forward the content from one or more content outputs, such as content output254. Content received from an embedded document, such as embedded document212may correspond to untrusted content. In particular, because rendered content in embedded document212could be based on untrusted content, content received from embedded document212may comprise malicious code capable of an XSS attack. Thus, in some implementations, content received from embedded document212is not rendered in containing document210. However, that content could later be received from a server by containing document210, or another instance of containing document210, and rendered in an embedded document, such as embedded document212, or another instance of embedded document212.

Referring toFIG. 3withFIGS. 1, 2A, and 2B,FIG. 3is a flow diagram showing method300for protecting documents from cross-site scripting attacks in accordance with implementations of the present disclosure. Each block of method300and other methods described herein comprises a computing process that may be performed using any combination of hardware, firmware, and/or software. For instance, various functions may be carried out by a processor executing instructions stored in memory. The methods may also be embodied as computer-usable instructions stored on computer storage media. The methods may be provided by a standalone application, a service or hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few.

At block380, content is received from a containing document. For example, containing document210and embedded document212may be loaded in document viewer108, where document viewer108is a web browser and embedded document212is in an iframe in containing document210. Containing document210may have been initially loaded from server106awith content handler220, and optionally content processor222and/or other content. Embedded document212may have been initially loaded from server106awith content handler224, content processor226, and optionally other content, such as content228.

Content handler224of embedded document212may receive untrusted content232from content handler220of containing document210after the documents are initially loaded. Prior to block380, content handler220of containing document210may have received untrusted content232from content input230. As one example, content input230could correspond to server106a. A user may have logged into containing document210. The user's login credentials may be in an authentication cookie, which is used to receive untrusted content232in an authenticated communication with server106a(e.g. asynchronously). Untrusted content232could comprise, for example, a post made in a forum that was stored by server106a. The post comprises JavaScript capable of executing an XSS attack when rendered in a document.

In the present example, content handlers220and224each comprises JavaScript provided in initially loading their respective documents. Content handler220is configured to forward untrusted content received by containing document210to embedded document212, such that the received content is never rendered on containing document210. Thus, the XSS attack from the code in untrusted content232is not executed on containing document210.

Also in the present example, content handler220provides untrusted content232to content handler224by sending a message comprising a string that corresponds to untrusted content232. In some cases, the string may have been what was provided to content handler220by server106ain a network communication. Content handler224comprises an event listener that receives the message in a message event.

At block382, the content is rendered in an embedded document, where a sandbox policy is enforced on the embedded document. Continuing with the present example, content processor226may comprise JavaScript configured to extract the string corresponding to untrusted content232from the message received by content handler224. The JavaScript may further be configured to render the string, which could be HTML or JSON, for example. As one example, in rendering the string, content processor226executes the JavaScript capable of executing the XSS attack. As another example, content processor226generates rendered content240bcomprising the text of the post in untrusted content232, as well as a button that reads “Edit Post.” When, a user clicks the button, the JavaScript capable of executing the XSS attack is executed.

The XSS attack attempts to access the authentication cookie of the user. However, document viewer108enforces a sandbox policy, such that embedded document212is denied access to the authentication cookie. Thus, containing document210is protected from the XSS attack. More particularly, in the current example, containing document210is in the domain “.adobe.com” and embedded document212is in the sub domain “.forums.adobe.com.” Thus, document viewer108isolates embedded document212from accessing resources of containing document210based on a same-origin policy. In this way, even when an XSS attack is attempted, sensitive data of containing document210is protected.

Referring toFIG. 4withFIGS. 1, 2A, and 2B,FIG. 4is a flow diagram showing method300for protecting documents from cross-site scripting attacks in accordance with implementations of the present disclosure.

At block480, content is received from an embedded document. Continuing with the example above, untrusted content may have been rendered as a text box in embedded document212, and may correspond to rendered content240c. A user may enter input into the text box and press a submit button, which automatically inserts malicious code into the input that is capable of executing an XSS attack. As an alternative, the user may have inadvertently entered the malicious code as the input. Content processor226received the input corresponding to untrusted content252and serialized the input into a string. Content handler224sent the string in a message, which is received by content handler220. For example, content handler220comprises an event listener that received the message.

Method400continues with forwarding the content to a server without rendering the received content in a containing document. For example, content handler224can forward untrusted content252to server106ain an authenticated communication (e.g. using the authentication cookie) or an unauthenticated communication. In some cases, the string corresponding to the content may be forwarded to server106awithout processing and/or rendering the string. Although untrusted content252comprises the malicious code in the present example, the malicious code is not executed on containing document210. Thus, containing document210is protected from the XSS attack. Furthermore, a method similar to method300may be employed in the future when providing untrusted content that includes the malicious code. As such, the malicious code may still be unable to successfully perform the XSS attack.

With reference toFIG. 5, computing device500includes bus510that directly or indirectly couples the following devices: memory512, one or more processors514, one or more presentation components516, input/output (I/O) ports518, input/output components520, and illustrative power supply522. Bus510represents what may be one or more busses (such as an address bus, data bus, or combination thereof). Although the various blocks ofFIG. 5are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, one may consider a presentation component such as a display device to be an I/O component. Also, processors have memory. The inventors recognize that such is the nature of the art, and reiterate that the diagram ofFIG. 5is merely illustrative of an exemplary computing device that can be used in connection with one or more embodiments of the present invention. Distinction is not made between such categories as “workstation,” “server,” “laptop,” “hand-held device,” etc., as all are contemplated within the scope ofFIG. 5and reference to “computing device.”

Memory512includes computer-storage media in the form of volatile and/or nonvolatile memory. The memory may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical-disc drives, etc. Computing device500includes one or more processors that read data from various entities such as memory512or I/O components520. Presentation component(s)516present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc.

As can be understood, implementations of the present disclosure provide for protecting documents from XSS attacks. The present invention has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the present invention pertains without departing from its scope.