113122 2013-03-22 17:44:22 -0700 Honor the setting for whether JavaScript markup is enabled 2013-03-27 20:23:15 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 112999 1 ggaren ggaren abarth dbates dcheng enrica eric esprehn+autocc esprehn inferno mjs ojan.autocc rniwa sam tony webkit.review.bot oldest_to_newest 862032 0 ggaren 2013-03-22 17:44:22 -0700 Honor the setting for whether JavaScript markup is enabled 862047 1 194673 ggaren 2013-03-22 18:04:22 -0700 Created attachment 194673 Patch 862156 2 194673 rniwa 2013-03-22 23:07:53 -0700 Comment on attachment 194673 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=194673&action=review Looks good but maybe eseidel or abarth can comment on the HTMLConstructionSite and HTMLTreeBuilder changes. > LayoutTests/editing/unsupported-content/script-markup-enabled-setting-expected.txt:4 > +PASS: frames[0].document.getElementsByTagName("script").length should be 0 and is. > +PASS: frames[1].document.getElementsByTagName("script").length should be 0 and is. These output doesn't tell us what each line is testing. Why don't we give frames some descriptive ids such as frameWithHTMLScriptElement and frameWithSVGScriptElement so that the output is self-evident. > LayoutTests/editing/unsupported-content/script-markup-enabled-setting.html:10 > +function shouldBe(aDescription, a, b) Why don't we just use js-test-pre.js? > LayoutTests/editing/unsupported-content/script-markup-enabled-setting.html:14 > + log("PASS: " + aDescription + " should be " + b + " and is."); > + return; Nit: tab characters. > LayoutTests/editing/unsupported-content/script-markup-enabled-setting.html:24 > +if (window.testRunner) > + testRunner.dumpAsText(); > + > +if (window.internals) > + window.internals.settings.setScriptMarkupEnabled(false); These two if's can be combined. 862200 3 194705 ggaren 2013-03-23 09:09:20 -0700 Created attachment 194705 Patch 862202 4 ggaren 2013-03-23 09:11:52 -0700 > These output doesn't tell us what each line is testing. Why don't we give frames some descriptive ids such as > frameWithHTMLScriptElement and frameWithSVGScriptElement so that the output is self-evident. Fixed. > Why don't we just use js-test-pre.js? I think js-test-pre.js is an anti-pattern. It has two major problems: (1) Everything executes through eval. This makes testing specific JavaScript details impossible. (2) It's a huge pile of code. The purpose of a reduced test case is to be the opposite. The first thing I always have to do when I diagnose a test failure in a test that uses js-test-pre.js is to make a reduction of the test. We shouldn't have to make reductions of our reduced test cases! > Nit: tab characters. Fixed. > These two if's can be combined. Fixed. 862231 5 194705 eric 2013-03-23 11:53:03 -0700 Comment on attachment 194705 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=194705&action=review Is this a setting only for WebKit embedders? Only on Mac? If so, it seems we should consider wrapping this in #ifdef MAC > Source/WebCore/html/parser/HTMLConstructionSite.cpp:466 > + if (scriptingContentIsAllowed(m_parserContentPolicy) || !toScriptElement(element.get())) > + attachLater(currentNode(), element, token->selfClosing()); So the goal here is to drop the <script> tag on the floor when scripting content is disallowed? 862237 6 194705 eric 2013-03-23 12:28:50 -0700 Comment on attachment 194705 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=194705&action=review > Source/WebCore/ChangeLog:20 > + (This bug has existed for copy/paste for a long time, but other bugs and > + quirks in SVG copy/paste papered over it. It's a serious issue now > + that non-paste clients will rely on this mode.) Could you talk a bit about what clients, and if these include browsers/the-web? The idea of running the parser in a mode whereby it will not produce certain tags seems reasonable. I'm not 100% convinced the parser wants the complexity, and that this is the right solution for your needs. But we already do something a bit similar for the XSSAuditor, but that's for attributes (it produces, them but them empties them in a follow-up pass). It's a little unfortunate that the parser has to know any of this, since it's job is really just to produce a DOM. The TreeBuidler passes each sript over to the HTMLScriptRunner, which actually knows what to do with the script. It doesn't currently modify script contents, but might be reasonable to make the HTMLScriptRunner instead just null out the innerHTML of the passed script tag. >> Source/WebCore/html/parser/HTMLConstructionSite.cpp:466 >> + attachLater(currentNode(), element, token->selfClosing()); > > So the goal here is to drop the <script> tag on the floor when scripting content is disallowed? Maybe the ScriptRunner should do this instead of the construction site? The construction site is a pretty low level primative. > Source/WebCore/html/parser/HTMLTreeBuilder.cpp:2872 > + if (scriptingContentIsAllowed(m_tree.parserContentPolicy())) > + m_scriptToProcess = m_tree.currentElement(); I think teaching the HTMLScriptRunner about this instead of the parser would make it easier to make sure you don't miss some later script tag. 862238 7 eric 2013-03-23 12:33:43 -0700 I guess I find it hard to engage about this change. There was an off-on-the-wrong-foot webkit-dev thread about this change. I feel like I'm not really needed here, as I get the sense there is time-pressure for this change, and you don't need my approval to twiddle bits on your own servers. :) My limited understanding is that you're trying to fix potential security bugs in Mail. Which seems like a reasonable desire. I'm not sure this is the right place to fix the behavior. I wonder how gmail strips script tags. :) Presumably not in WebKit. I'm happy to offer further thoughts, but it may be easier for all involved if I just de-CC myself and live a happier life. 862243 8 194705 rniwa 2013-03-23 12:52:52 -0700 Comment on attachment 194705 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=194705&action=review >>> Source/WebCore/html/parser/HTMLConstructionSite.cpp:466 >>> + attachLater(currentNode(), element, token->selfClosing()); >> >> So the goal here is to drop the <script> tag on the floor when scripting content is disallowed? > > Maybe the ScriptRunner should do this instead of the construction site? The construction site is a pretty low level primative. HTMLConstructionSite::insertScriptElement, which is the function that appears right above this one, does this check already. But unifying these scriptingContentIsAllowed checks at one place like ScriptRunner makes a lot of sense since they're scattered across HTML & XML parsers at the moment. Perhaps we should do it in a separate patch? 862245 9 rniwa 2013-03-23 12:56:36 -0700 (In reply to comment #7) > I guess I find it hard to engage about this change. There was an off-on-the-wrong-foot webkit-dev thread about this change. I feel like I'm not really needed here, as I get the sense there is time-pressure for this change, and you don't need my approval to twiddle bits on your own servers. :) My understanding is that this patch is nothing to do with that webkit-dev thread. That one was a discussion about implementing CSP or features like CSP by stripping scripts at parsing time. This patch is about fixing an existing feature in WebKit so that other applications such as Mail can use it as we've exposed it via settings in the bug 112999. 862248 10 rniwa 2013-03-23 13:00:00 -0700 I'll note that the "existing feature" is stripping scripting contents when pasting contents from clipboard. 862249 11 rniwa 2013-03-23 13:02:30 -0700 I'll further note that this is about fixing a bug that already exists for pasting from clipboard case. For whatever reason, we could not come up with a reduction for erroneously executing scripts when pasting from clipboard because of some bug in editing code or parsing SVG (Geoff would know). 862253 12 ggaren 2013-03-23 13:28:07 -0700 > Is this a setting only for WebKit embedders? Only on Mac? If so, it seems we should consider wrapping this in #ifdef MAC This is a setting that's appropriate for mail, newsfeed, and chat apps, which digest markup but don't want to risk script injection attacks. I don't think there's anything special about Mac apps that make them want protection from script injection any more than Linux or Windows apps. Do you? A side-benefit of this setting is that it allows us to regression test WebKit's copy/paste and drag/drop script injection protection without going through contortions in the test to copy the content and then paste it. For example, that's how I discovered the SVG script injection bug, even though it can't be reproduced by a copy operation in WebKit. I don't think WebKit wants less regression testing on Linux or Windows than on Mac. Do you? > So the goal here is to drop the <script> tag on the floor when scripting content is disallowed? That's right: We want to parse exactly "as if" the tag had been there, obeying whatever effect it would have had on the tag soup, without ever executing it or inserting it into the DOM. 862254 13 ggaren 2013-03-23 14:03:29 -0700 > Could you talk a bit about what clients, and if these include browsers/the-web? The parsing feature -- stripping scripts to avoid script injection attacks -- is used by browsers when executing paste and drop commands. See our regression tests in LayoutTests/editing/pasteboard for some examples. WebKit browsers have worked this way since 2010. The bug fix in this feature -- the one for SVG scripts -- is intended for all WebKit clients, including browsers. The setting, which allows a client to opt into script injection protection all the time, instead of just when pasting or dropping, is intended for mail, newsfeed, and chat apps, which digest markup but don't want to risk script injection attacks. > The idea of running the parser in a mode whereby it will not produce certain tags seems reasonable. > I'm not 100% convinced the parser wants the complexity, and that this is the right solution for your needs. I want to clarify that the parser has had this feature since 2010, in order to solve a general problem in WebKit. If there's a better way to do things, let's do it, and make WebKit better. > It's a little unfortunate that the parser has to know any of this, since it's job is really just to produce a DOM. I might be upside-down about this, but that's actually why I chose the parser: The goal of the feature is to change the generated DOM, by eliminating tags and attributes that map to scripts at runtime. The reason we want to remove these from the DOM is that down the line, after parsing, we don't want an editing operation, or a DOM clone or move operation, to accidentally inject that script-y DOM, thereby allowing it to execute. > The TreeBuidler passes each sript over to the HTMLScriptRunner, which actually knows what to do with the script. It doesn't currently modify script contents, but might be reasonable to make the HTMLScriptRunner instead just null out the innerHTML of the passed script tag. I have to admit that I tried a bunch of different options before I settled on the parser, so I won't argue that the current solution is self-evident. The HTMLScriptRunner appealed to me at one point, but I ran into two challenges: (1) It's a little insecure to leave even an empty script element in the DOM. If an editing operation accidentally inserted text into that element's text content, it could execute as script. I tried to improve this by just having the script runner remove the whole element from its parent, but that sometimes happens at an inconvenient time for the parser's state machine, causing crashes. (2) The HTMLScriptRunner doesn't control script-y attributes getting added to DOM nodes. Once I decided that the parser had to be in charge of the attributes part of this feature, it seemed natural to keep responsibility for the elements part of this feature in the same place. (3) When parsing document fragments (paste and drop commands), there is no HTMLScriptRunner. Given these challenges, do you still think the HTMLScriptRunner is the best place to do this? How would you address these issues? > > Source/WebCore/html/parser/HTMLTreeBuilder.cpp:2872 > > + if (scriptingContentIsAllowed(m_tree.parserContentPolicy())) > > + m_scriptToProcess = m_tree.currentElement(); > > I think teaching the HTMLScriptRunner about this instead of the parser would make it easier to make sure you don't miss some later script tag. I share this concern. I wonder if there's a reasonable belt-and-suspenders approach here, that takes advantage of HTMLScriptRunner being a bottleneck for script execution at parse time. For example, we could arrange for HTMLScriptRunner to always be NULL if script markup is disabled, instead of only when parsing document fragments, or we could add a RELEASE_ASSERT to HTMLScriptRunner. What do you think? 862256 14 ggaren 2013-03-23 14:23:17 -0700 (In reply to comment #9) > My understanding is that this patch is nothing to do with that webkit-dev thread. This is a bit of an overstatement. I started the webkit-dev thread because Maciej convinced me that stripping script markup was more secure than leaving it in the DOM, and it occurred to me that it would be a security improvement, and a reduction in complexity, to use this technique in all cases where WebKit wanted to disable scripts, instead of just these two or three cases. So, this patch is related because it motivated me to start that discussion. However, Jochen Eisinger pointed out that we can't use a single technique everywhere because Chromium's script blocking UI requires special hooks in WebKit. And Adam Barth pointed out that we can't use a single technique everywhere because the more secure technique is incompatible with the current draft spec for CSP. So, now this patch returns to its humble roots, and fixes the original bug I intended to fix, without making any broader changes in WebKit. 862258 15 194719 rniwa 2013-03-23 15:06:26 -0700 Created attachment 194719 Attempt to create a reduction with copy & paste There appears to be some other mechanism by which we're stripping script content. Maybe inferno and others in the security team can help us making an actual reduction for this case. I've started to wonder if this bug should be moved to the security component or not but I guess we can wait 'til we get an actual reduction? 862259 16 rniwa 2013-03-23 15:08:44 -0700 +dcheng & +tony^work since they've worked on the clipboardData/dataTransfer code recently. 862294 17 esprehn 2013-03-23 19:42:32 -0700 (In reply to comment #13) >... > > I have to admit that I tried a bunch of different options before I settled on the parser, so I won't argue that the current solution is self-evident. The HTMLScriptRunner appealed to me at one point, but I ran into two challenges: > > (1) It's a little insecure to leave even an empty script element in the DOM. If an editing operation accidentally inserted text into that element's text content, it could execute as script. I tried to improve this by just having the script runner remove the whole element from its parent, but that sometimes happens at an inconvenient time for the parser's state machine, causing crashes. > This is definitely not the case. A script element can only run once, per the "already started" flag, as specified in the HTML5 spec. http://www.w3.org/html/wg/drafts/html/master/scripting-1.html#prepare-a-script This flag even persists through cloning. 862318 18 mjs 2013-03-23 22:50:28 -0700 (In reply to comment #17) > (In reply to comment #13) > >... > > > > I have to admit that I tried a bunch of different options before I settled on the parser, so I won't argue that the current solution is self-evident. The HTMLScriptRunner appealed to me at one point, but I ran into two challenges: > > > > (1) It's a little insecure to leave even an empty script element in the DOM. If an editing operation accidentally inserted text into that element's text content, it could execute as script. I tried to improve this by just having the script runner remove the whole element from its parent, but that sometimes happens at an inconvenient time for the parser's state machine, causing crashes. > > > > This is definitely not the case. A script element can only run once, per the "already started" flag, as specified in the HTML5 spec. > > http://www.w3.org/html/wg/drafts/html/master/scripting-1.html#prepare-a-script > > This flag even persists through cloning. It doesn't persist through serializing/deserializing though, so if you accidentally put text in a <script>, it's no longer safe to copy/paste the content containing it. Or if you remove and reinsert this script by assigning its parents innerHTML to itself. In any case, since stripping scripting constructs at parse time is an existing WebKit feature, and this patch just exposes it for a new use, proposals for how to change the way we strip scripting constructs maybe should go in another bug. 862321 19 esprehn 2013-03-23 23:15:44 -0700 (In reply to comment #18) > ... > > This is definitely not the case. A script element can only run once, per the "already started" flag, as specified in the HTML5 spec. > > > > http://www.w3.org/html/wg/drafts/html/master/scripting-1.html#prepare-a-script > > > > This flag even persists through cloning. > > It doesn't persist through serializing/deserializing though, so if you accidentally put text in a <script>, it's no longer safe to copy/paste the content containing it. Or if you remove and reinsert this script by assigning its parents innerHTML to itself. > Scripts inserted through innerHTML never run. It's not clear to me why we don't just drop the text from inside script elements and attributes in the deserializer (or just disable all inline script like CSP). > In any case, since stripping scripting constructs at parse time is an existing WebKit feature, and this patch just exposes it for a new use, proposals for how to change the way we strip scripting constructs maybe should go in another bug. I really don't think this is the right way to fix the issue for desktop apps, but it's important to note that doing this on the open web can, and does, break pages: <script></script> <span>...</span> <style>script + div { color: red; }</script> or even more common: <div> <script></script> <span>...</span> </div> <style>div:nth-child(2) { color: red; }</style> Why doesn't Mail or Adium just use CSP though, or a sandboxed iframe that doesn't allow scripts? 862331 20 rniwa 2013-03-24 00:56:44 -0700 (In reply to comment #18) > (In reply to comment #17) > > > > This is definitely not the case. A script element can only run once, per the "already started" flag, as specified in the HTML5 spec. > > > > http://www.w3.org/html/wg/drafts/html/master/scripting-1.html#prepare-a-script > > > > This flag even persists through cloning. > > It doesn't persist through serializing/deserializing though, so if you accidentally put text in a <script>, it's no longer safe to copy/paste the content containing it. It is. Our paste code disables script elements. > Or if you remove and reinsert this script by assigning its parents innerHTML to itself. Apparently we don't do this. setInnerHTML strips the script element's content so the script element doesn't do anything. (In reply to comment #19) > It's not clear to me why we don't just drop the text from inside script elements and attributes in the deserializer (or just disable all inline script like CSP). We do do that. > > In any case, since stripping scripting constructs at parse time is an existing WebKit feature, and this patch just exposes it for a new use, proposals for how to change the way we strip scripting constructs maybe should go in another bug. > > I really don't think this is the right way to fix the issue for desktop apps, but it's important to note that doing this on the open web can, and does, break pages: > > <script></script> > <span>...</span> > <style>script + div { color: red; }</script> > > or even more common: > > <div> > <script></script> > <span>...</span> > </div> > > <style>div:nth-child(2) { color: red; }</style> That's a very good point. This will indeed be a problem for Mail. 862339 21 mjs 2013-03-24 03:44:54 -0700 (In reply to comment #20) > > > > I really don't think this is the right way to fix the issue for desktop apps, but it's important to note that doing this on the open web can, and does, break pages: > > > > <script></script> > > <span>...</span> > > <style>script + div { color: red; }</script> > > > > or even more common: > > > > <div> > > <script></script> > > <span>...</span> > > </div> > > > > <style>div:nth-child(2) { color: red; }</style> > > That's a very good point. This will indeed be a problem for Mail. As a point of comparison, in GMail and MobileMe Mail (I cold not get YahooMail to work) both strip red from minimally corrected versions of the above snippets. Is such a construct actually involving the presence of scripts common on the web? Evidence seems to be that it's not common enough that mail clients care more about it than about stripping script tags. - Maciej <div>...</div> 862398 22 esprehn 2013-03-24 12:21:31 -0700 (In reply to comment #21) > ... > > > > That's a very good point. This will indeed be a problem for Mail. > > As a point of comparison, in GMail and MobileMe Mail (I cold not get YahooMail to work) both strip red from minimally corrected versions of the above snippets. Is such a construct actually involving the presence of scripts common on the web? Evidence seems to be that it's not common enough that mail clients care more about it than about stripping script tags. > > - Maciej > > <div>...</div> Outlook 2007+ has such crippled CSS support that I don't know if people depend on that much. I have seen some internal apps at Google break when Google Feedback's page copier which is used to make an inert copy of a page removed script tags though. rniwa and I have debunked the theoretical exploits here: innerHTML never runs scripts, editing drops the contents of scripts on paste, scripts never run more than once in the document. I don't understand what this patch is attempting to solve, nor is it clear why Mail isn't using a sandboxed iframe if you were really paranoid that all the protections we already have are not enough. 862401 23 rniwa 2013-03-24 12:29:50 -0700 We can't always use sandboxed iframe for this feature because some OS X applications inject scripts into the document. 862418 24 194769 ggaren 2013-03-24 15:08:30 -0700 Created attachment 194769 Script injection attack examples Test case showing some script injection attacks, and how CSP and other mechanisms do not protect against them. 862423 25 ggaren 2013-03-24 15:21:02 -0700 > A script element can only run once, per the "already started" flag, as specified in the HTML5 spec. As Maciej mentioned, the already started flag does not protect against serialization / deserialization attacks. See the attached test case. > Why doesn't Mail or Adium just use CSP though, or a sandboxed iframe that doesn't allow scripts? (1) CSP blocks user/host-injected JavaScript, which breaks apps that implement features in JavaScript. (2) CSP is subject to script injection attacks. See the attached test case. > doing this on the open web can, and does, break pages It sounds like you're objecting to WebKit's existing behavior for paste and drop. I would be surprised if it broke the web, since we haven't gotten any bug reports about it over the past three years. That said, the specifics of how we should handle paste and drop are not really germane to this bug, which just exposes WebKit's paste/drop protection as a setting for native apps. > I have seen some internal apps at Google break when Google Feedback's page copier which is used to make an inert copy of a page removed script tags though. Fair enough. But that's not the open web. Maciej's examples seem to indicate that the de fact standard on the open web is for mail clients to wholly strip script elements. Do you have any examples of web-based mail clients that leave script elements in the document? 862431 26 rniwa 2013-03-24 15:58:19 -0700 (In reply to comment #25) > > > doing this on the open web can, and does, break pages > > It sounds like you're objecting to WebKit's existing behavior for paste and drop. I would be surprised if it broke the web, since we haven't gotten any bug reports about it over the past three years. That said, the specifics of how we should handle paste and drop are not really germane to this bug, which just exposes WebKit's paste/drop protection as a setting for native apps. It's probably safer to strip the contents of the script element and leave empty script elements alone just like what we do in setInnerHTML than removing the script elements entirely per Elliot's examples. On the other hand, editing code is almost completely broken for cases where we have such style rules so I'm not certain if it's something we should really be concerned about. 862924 27 194891 ggaren 2013-03-25 11:11:01 -0700 Created attachment 194891 Specific demonstration of why an empty script element is dangerous 862929 28 ggaren 2013-03-25 11:19:03 -0700 > It's probably safer to strip the contents of the script element and leave empty script elements alone just like what we do in setInnerHTML than removing the script elements entirely per Elliot's examples. I've attached an additional test case demonstrating the specific attack an empty script element opens our users up to. Which approach is more compatible with the web all depends on what other mail, chat, etc. content viewers do on the web. So far, we have two examples of mail content viewers that strip the script element, and zero examples of mail content viewers that preserve it. The evidence says that stripping the script element is both more secure and more compatible. All of that being said, I'll repeat: This patch just exposes WebKit's existing behavior as a setting, and fixes an oversight that prevented that behavior from covering svg script elements. This patch did not invent the behavior, and ideas for changing the behavior are not germane to this patch. 864800 29 ggaren 2013-03-27 13:07:38 -0700 Ryosuke mentioned that some Google engineers said on IRC that they thought stripping scripts from emails was something unique to Apple Mail. Let me re-re-state: GMail does it too. 864804 30 esprehn 2013-03-27 13:12:48 -0700 (In reply to comment #29) > Ryosuke mentioned that some Google engineers said on IRC that they thought stripping scripts from emails was something unique to Apple Mail. Let me re-re-state: GMail does it too. That's not what I said. I said that the examples given here are effectively eval() and that the whole argument of this bug is that Apple's Mail.app engineers are apparently incapable of writing safe JS so we need to protect them at the platform level. Making every nested iframe CSP, or having Mail.app put the sandbox attribute on every nested iframe, and CSP at the top level (which seems totally reasonable) also fixes this bug. I can't fathom a reason that Mail.app would put the HTML contents of an email into anything _but_ a sandboxed iframe. :) Anyway, I don't want to block this patch, but I do object to claiming that Adium needs to turn this feature on to be safe. They can be just as safe by using CSP and sandbox and not have the surprising parser magic, and indeed this is what Chrome OS does to be secure. 864815 31 ggaren 2013-03-27 13:28:54 -0700 > Making every nested iframe CSP, or having Mail.app put the sandbox attribute on every nested iframe, and CSP at the top level (which seems totally reasonable) also fixes this bug. I guess you didn't notice my comments above, where I explained why that wouldn't work. 864820 32 rniwa 2013-03-27 13:33:46 -0700 Give that Gmail also strips script elements, the point Elliot made against this approach that some CSS rules may apply differently is now an argument for this approach. If we didn't strip the script element, Maill will render an email differently than on Gmail. 864825 33 esprehn 2013-03-27 13:37:44 -0700 (In reply to comment #32) > Give that Gmail also strips script elements, the point Elliot made against this approach that some CSS rules may apply differently is now an argument for this approach. If we didn't strip the script element, Maill will render an email differently than on Gmail. Seems reasonable. 864829 34 rniwa 2013-03-27 13:42:32 -0700 I'll also note that clipboard API working draft has HTML paste sanitation algorithm (http://www.w3.org/TR/clipboard-apis/#cross-origin-html-paste-sanitization-algorithm). This algorithm has been removed from the latest editor's draft due to lack of implementations but our behavior matches this algorithm's behavior at least for script element and on* attributes. I've emailed public-webapps to define what UAs are allowed to address security concerns so that, specifically, things like CSS rules dependent on script element being present in the pasted content won't be an issue for us. 864978 35 ggaren 2013-03-27 16:43:17 -0700 Committed r147018: <http://trac.webkit.org/changeset/147018> 865025 36 mjs 2013-03-27 17:14:07 -0700 (In reply to comment #32) > Give that Gmail also strips script elements, the point Elliot made against this approach that some CSS rules may apply differently is now an argument for this approach. If we didn't strip the script element, Maill will render an email differently than on Gmail. I did more testing - in addition to Gmail, the following all completely strip scripts in mail messages: iCloud Mail, YahooMail, Microsoft Live Mail. None of these appear to put HTML emails in a sandboxed iframe, nor do they appear to use CSP, even on browsers that support these features. As others have concluded, it's probably better for Mail.app to be compatible with popular webmail clients than to do something different and more complicated. 865130 37 rniwa 2013-03-27 20:23:15 -0700 Debug tester fixed in http://trac.webkit.org/changeset/147050. 194673 2013-03-22 18:04:22 -0700 2013-03-23 09:09:15 -0700 Patch bug-113122-20130322180009.patch text/plain 6891 ggaren SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDE0NjY5MikKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDMyIEBACisyMDEzLTAzLTIyICBHZW9mZnJl eSBHYXJlbiAgPGdnYXJlbkBhcHBsZS5jb20+CisKKyAgICAgICAgSG9ub3IgdGhlIHNldHRpbmcg Zm9yIHdoZXRoZXIgSmF2YVNjcmlwdCBtYXJrdXAgaXMgZW5hYmxlZAorICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTEzMTIyCisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBkb20vU2NyaXB0YWJsZURvY3VtZW50 UGFyc2VyLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlNjcmlwdGFibGVEb2N1bWVudFBhcnNlcjo6 U2NyaXB0YWJsZURvY3VtZW50UGFyc2VyKTogQXBwbGllZCB0aGUKKyAgICAgICAgc2V0dGluZyBo ZXJlLCBzbyBhbGwgZG9jdW1lbnQgcGFyc2luZyB3b3VsZCBiZSBjb3ZlcmVkLiBUaGlzIGlzIHNp bWlsYXIKKyAgICAgICAgdG8gd2hhdCB3ZSBkbyBmb3IgcGx1Zy1pbiBzdHJpcHBpbmcuCisKKyAg ICAgICAgKiBodG1sL3BhcnNlci9IVE1MQ29uc3RydWN0aW9uU2l0ZS5jcHA6CisgICAgICAgIChX ZWJDb3JlOjpIVE1MQ29uc3RydWN0aW9uU2l0ZTo6aW5zZXJ0Rm9yZWlnbkVsZW1lbnQpOiBGaXhl ZCBhIGJ1ZyB3aGVyZQorICAgICAgICB3ZSB3b3VsZCBpbnNlcnQgYW4gU1ZHIHNjcmlwdCBlbGVt ZW50IGludG8gdGhlIGRvY3VtZW50IGV2ZW4gaW4gc2NyaXB0CisgICAgICAgIG1hcmt1cCBkaXNh YmxlZCBtb2RlLgorCisgICAgICAgIChUaGlzIGJ1ZyBoYXMgZXhpc3RlZCBmb3IgY29weS9wYXN0 ZSBmb3IgYSBsb25nIHRpbWUsIGJ1dCBvdGhlciBidWdzIGFuZAorICAgICAgICBxdWlya3MgaW4g U1ZHIGNvcHkvcGFzdGUgcGFwZXJlZCBvdmVyIGl0LiBJdCdzIGEgc2VyaW91cyBpc3N1ZSBub3cK KyAgICAgICAgdGhhdCBub24tcGFzdGUgY2xpZW50cyB3aWxsIHJlbHkgb24gdGhpcyBtb2RlLikK KworICAgICAgICAqIGh0bWwvcGFyc2VyL0hUTUxUcmVlQnVpbGRlci5jcHA6CisgICAgICAgIChX ZWJDb3JlOjpIVE1MVHJlZUJ1aWxkZXI6OnByb2Nlc3NUb2tlbkluRm9yZWlnbkNvbnRlbnQpOiBG aXhlZCB0aGUgc2FtZQorICAgICAgICBidWcgLS0gdGhpcyB0aW1lIGluIHRoZSBwYXJ0IG9mIHRo ZSBwYXJzZXIgdGhhdCBleGVjdXRlcyBzY3JpcHRzIGFzIHRoZXkKKyAgICAgICAgcGFyc2UuCisK KyAgICAgICAgSSBhZG9wdGVkIHRoZSB0b1NjcmlwdEVsZW1lbnQoKSBjb252ZW50aW9uIGZvciB0 ZXN0aW5nIGZvciBhIHNjcmlwdAorICAgICAgICBlbGVtZW50IHRvIG1hdGNoIHRoZSBYTUwgcGFy c2VyLgorCiAyMDEzLTAzLTIyICBSb2dlciBGb25nICA8cm9nZXJfZm9uZ0BhcHBsZS5jb20+CiAK ICAgICAgICAgVW5yZXZpZXdlZC4gRml4IEFwcGxlV2luIHBvcnQgZm9sbG93aW5nIGh0dHBzOi8v YnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xMTMxMDAuCkluZGV4OiBTb3VyY2UvV2Vi Q29yZS9kb20vU2NyaXB0YWJsZURvY3VtZW50UGFyc2VyLmNwcAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3Vy Y2UvV2ViQ29yZS9kb20vU2NyaXB0YWJsZURvY3VtZW50UGFyc2VyLmNwcAkocmV2aXNpb24gMTQ2 NjYyKQorKysgU291cmNlL1dlYkNvcmUvZG9tL1NjcmlwdGFibGVEb2N1bWVudFBhcnNlci5jcHAJ KHdvcmtpbmcgY29weSkKQEAgLTQwLDYgKzQwLDkgQEAgU2NyaXB0YWJsZURvY3VtZW50UGFyc2Vy OjpTY3JpcHRhYmxlRG9jdQogewogICAgIGlmICghcGx1Z2luQ29udGVudElzQWxsb3dlZChtX3Bh cnNlckNvbnRlbnRQb2xpY3kpICYmICghZG9jdW1lbnQtPnNldHRpbmdzKCkgfHwgZG9jdW1lbnQt PnNldHRpbmdzKCktPnVuc2FmZVBsdWdpblBhc3RpbmdFbmFibGVkKCkpKQogICAgICAgICBtX3Bh cnNlckNvbnRlbnRQb2xpY3kgPSBhbGxvd1BsdWdpbkNvbnRlbnQobV9wYXJzZXJDb250ZW50UG9s aWN5KTsKKworICAgIGlmIChzY3JpcHRpbmdDb250ZW50SXNBbGxvd2VkKG1fcGFyc2VyQ29udGVu dFBvbGljeSkgJiYgKGRvY3VtZW50LT5zZXR0aW5ncygpICYmICFkb2N1bWVudC0+c2V0dGluZ3Mo KS0+c2NyaXB0TWFya3VwRW5hYmxlZCgpKSkKKyAgICAgICAgbV9wYXJzZXJDb250ZW50UG9saWN5 ID0gZGlzYWxsb3dTY3JpcHRpbmdDb250ZW50KG1fcGFyc2VyQ29udGVudFBvbGljeSk7CiB9CiAK IH07CkluZGV4OiBTb3VyY2UvV2ViQ29yZS9odG1sL3BhcnNlci9IVE1MQ29uc3RydWN0aW9uU2l0 ZS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvaHRtbC9wYXJzZXIvSFRNTENvbnN0 cnVjdGlvblNpdGUuY3BwCShyZXZpc2lvbiAxNDY2NjIpCisrKyBTb3VyY2UvV2ViQ29yZS9odG1s L3BhcnNlci9IVE1MQ29uc3RydWN0aW9uU2l0ZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTQ2Miw3 ICs0NjIsOCBAQCB2b2lkIEhUTUxDb25zdHJ1Y3Rpb25TaXRlOjppbnNlcnRGb3JlaWduCiAgICAg bm90SW1wbGVtZW50ZWQoKTsgLy8gcGFyc2VFcnJvciB3aGVuIHhtbG5zIG9yIHhtbG5zOnhsaW5r IGFyZSB3cm9uZy4KIAogICAgIFJlZlB0cjxFbGVtZW50PiBlbGVtZW50ID0gY3JlYXRlRWxlbWVu dCh0b2tlbiwgbmFtZXNwYWNlVVJJKTsKLSAgICBhdHRhY2hMYXRlcihjdXJyZW50Tm9kZSgpLCBl bGVtZW50LCB0b2tlbi0+c2VsZkNsb3NpbmcoKSk7CisgICAgaWYgKHNjcmlwdGluZ0NvbnRlbnRJ c0FsbG93ZWQobV9wYXJzZXJDb250ZW50UG9saWN5KSB8fCAhdG9TY3JpcHRFbGVtZW50KGVsZW1l bnQuZ2V0KCkpKQorICAgICAgICBhdHRhY2hMYXRlcihjdXJyZW50Tm9kZSgpLCBlbGVtZW50LCB0 b2tlbi0+c2VsZkNsb3NpbmcoKSk7CiAgICAgaWYgKCF0b2tlbi0+c2VsZkNsb3NpbmcoKSkKICAg ICAgICAgbV9vcGVuRWxlbWVudHMucHVzaChIVE1MU3RhY2tJdGVtOjpjcmVhdGUoZWxlbWVudC5y ZWxlYXNlKCksIHRva2VuLCBuYW1lc3BhY2VVUkkpKTsKIH0KSW5kZXg6IFNvdXJjZS9XZWJDb3Jl L2h0bWwvcGFyc2VyL0hUTUxUcmVlQnVpbGRlci5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dl YkNvcmUvaHRtbC9wYXJzZXIvSFRNTFRyZWVCdWlsZGVyLmNwcAkocmV2aXNpb24gMTQ2NjYyKQor KysgU291cmNlL1dlYkNvcmUvaHRtbC9wYXJzZXIvSFRNTFRyZWVCdWlsZGVyLmNwcAkod29ya2lu ZyBjb3B5KQpAQCAtMjg2OCw3ICsyODY4LDggQEAgdm9pZCBIVE1MVHJlZUJ1aWxkZXI6OnByb2Nl c3NUb2tlbkluRm9yZQogICAgICAgICAgICAgYWRqdXN0U1ZHVGFnTmFtZUNhc2UodG9rZW4pOwog CiAgICAgICAgIGlmICh0b2tlbi0+bmFtZSgpID09IFNWR05hbWVzOjpzY3JpcHRUYWcgJiYgbV90 cmVlLmN1cnJlbnRTdGFja0l0ZW0oKS0+aGFzVGFnTmFtZShTVkdOYW1lczo6c2NyaXB0VGFnKSkg ewotICAgICAgICAgICAgbV9zY3JpcHRUb1Byb2Nlc3MgPSBtX3RyZWUuY3VycmVudEVsZW1lbnQo KTsKKyAgICAgICAgICAgIGlmIChzY3JpcHRpbmdDb250ZW50SXNBbGxvd2VkKG1fdHJlZS5wYXJz ZXJDb250ZW50UG9saWN5KCkpKQorICAgICAgICAgICAgICAgIG1fc2NyaXB0VG9Qcm9jZXNzID0g bV90cmVlLmN1cnJlbnRFbGVtZW50KCk7CiAgICAgICAgICAgICBtX3RyZWUub3BlbkVsZW1lbnRz KCktPnBvcCgpOwogICAgICAgICAgICAgcmV0dXJuOwogICAgICAgICB9CkluZGV4OiBMYXlvdXRU ZXN0cy9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCShyZXZp c2lvbiAxNDY2OTQpCisrKyBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHdvcmtpbmcgY29weSkKQEAg LTEsMyArMSwxMyBAQAorMjAxMy0wMy0yMiAgR2VvZmZyZXkgR2FyZW4gIDxnZ2FyZW5AYXBwbGUu Y29tPgorCisgICAgICAgIEhvbm9yIHRoZSBzZXR0aW5nIGZvciB3aGV0aGVyIEphdmFTY3JpcHQg bWFya3VwIGlzIGVuYWJsZWQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19i dWcuY2dpP2lkPTExMzEyMgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgor CisgICAgICAgICogZWRpdGluZy91bnN1cHBvcnRlZC1jb250ZW50L3NjcmlwdC1tYXJrdXAtZW5h YmxlZC1zZXR0aW5nLWV4cGVjdGVkLnR4dDogQWRkZWQuCisgICAgICAgICogZWRpdGluZy91bnN1 cHBvcnRlZC1jb250ZW50L3NjcmlwdC1tYXJrdXAtZW5hYmxlZC1zZXR0aW5nLmh0bWw6IEFkZGVk LgorCiAyMDEzLTAzLTIyICBTdGVwaGVuIENoZW5uZXkgIDxzY2hlbm5leUBjaHJvbWl1bS5vcmc+ CiAKICAgICAgICAgW0Nocm9taXVtXSBUZXN0IGV4cGVjdGF0aW9ucyBhZnRlciBTa2lhIGNoYW5n ZXMKSW5kZXg6IExheW91dFRlc3RzL2VkaXRpbmcvdW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQt bWFya3VwLWVuYWJsZWQtc2V0dGluZy1leHBlY3RlZC50eHQKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0 VGVzdHMvZWRpdGluZy91bnN1cHBvcnRlZC1jb250ZW50L3NjcmlwdC1tYXJrdXAtZW5hYmxlZC1z ZXR0aW5nLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2VkaXRpbmcv dW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQtbWFya3VwLWVuYWJsZWQtc2V0dGluZy1leHBlY3Rl ZC50eHQJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSw1IEBACitUaGlzIHRlc3QgdmVyaWZpZXMg dGhhdCBzY3JpcHQgZWxlbWVudHMgYXJlIG5vdCBpbnNlcnRlZCBpbnRvIHRoZSBkb2N1bWVudCBp ZiB0aGUgV2ViQ29yZSBzY3JpcHRNYXJrdXBFbmFibGVkIHNldHRpbmcgaXMgZmFsc2UuCisKK1BB U1M6IGZyYW1lc1swXS5kb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IikubGVu Z3RoIHNob3VsZCBiZSAwIGFuZCBpcy4KK1BBU1M6IGZyYW1lc1sxXS5kb2N1bWVudC5nZXRFbGVt ZW50c0J5VGFnTmFtZSgic2NyaXB0IikubGVuZ3RoIHNob3VsZCBiZSAwIGFuZCBpcy4KKyAKSW5k ZXg6IExheW91dFRlc3RzL2VkaXRpbmcvdW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQtbWFya3Vw LWVuYWJsZWQtc2V0dGluZy5odG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2VkaXRpbmcv dW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQtbWFya3VwLWVuYWJsZWQtc2V0dGluZy5odG1sCShy ZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMvZWRpdGluZy91bnN1cHBvcnRlZC1jb250ZW50L3Nj cmlwdC1tYXJrdXAtZW5hYmxlZC1zZXR0aW5nLmh0bWwJKHdvcmtpbmcgY29weSkKQEAgLTAsMCAr MSwzNiBAQAorPHA+VGhpcyB0ZXN0IHZlcmlmaWVzIHRoYXQgc2NyaXB0IGVsZW1lbnRzIGFyZSBu b3QgaW5zZXJ0ZWQgaW50byB0aGUgZG9jdW1lbnQgaWYgdGhlIFdlYkNvcmUgc2NyaXB0TWFya3Vw RW5hYmxlZCBzZXR0aW5nIGlzIGZhbHNlLjwvcD4KKzxwcmUgaWQ9ImxvZyI+PC9wcmU+CisKKzxz Y3JpcHQ+CitmdW5jdGlvbiBsb2cocykKK3sKKwlkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgibG9n IikuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUocyArICJcbiIpKTsKK30KKwor ZnVuY3Rpb24gc2hvdWxkQmUoYURlc2NyaXB0aW9uLCBhLCBiKQoreworCWlmIChhID09IGIpIHsK KwkJbG9nKCJQQVNTOiAiICsgYURlc2NyaXB0aW9uICsgIiBzaG91bGQgYmUgIiArIGIgKyAiIGFu ZCBpcy4iKTsKKwkJcmV0dXJuOworCX0KKworCWxvZygiRkFJTDogIiArIGFEZXNjcmlwdGlvbiAr ICIgc2hvdWxkIGJlICIgKyBiICsgIiBidXQgaW5zdGVhZCBpcyAiICsgYSArICIuIik7Cit9CisK K2lmICh3aW5kb3cudGVzdFJ1bm5lcikKKwl0ZXN0UnVubmVyLmR1bXBBc1RleHQoKTsKKworaWYg KHdpbmRvdy5pbnRlcm5hbHMpCisgICAgd2luZG93LmludGVybmFscy5zZXR0aW5ncy5zZXRTY3Jp cHRNYXJrdXBFbmFibGVkKGZhbHNlKTsKK2Vsc2UKKyAgICBsb2coIlRoaXMgdGVzdCBkZXBlbmRz IG9uIHRoZSBKYXZhU2NyaXB0TWFya3VwRW5hYmxlZCBzZXR0aW5nIGJlaW5nIGZhbHNlLiIpOwor Cit3aW5kb3cub25sb2FkID0gZnVuY3Rpb24gdGVzdCgpCit7CisJc2hvdWxkQmUoJ2ZyYW1lc1sw XS5kb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IikubGVuZ3RoJywgZnJhbWVz WzBdLmRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCJzY3JpcHQiKS5sZW5ndGgsIDApOwor CXNob3VsZEJlKCdmcmFtZXNbMV0uZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoInNjcmlw dCIpLmxlbmd0aCcsIGZyYW1lc1sxXS5kb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2Ny aXB0IikubGVuZ3RoLCAwKTsKK30KKzwvc2NyaXB0PgorCis8aWZyYW1lIHNyY2RvYz0iPHNjcmlw dD52YXIgcHduZWQgPSAxOzwvc2NyaXB0PiI+PC9pZnJhbWU+Cis8aWZyYW1lIHNyY2RvYz0iPHN2 Zz48c2NyaXB0PnZhciBwd25lZCA9IDE7PC9zY3JpcHQ+PC9zdmc+Ij48L2lmcmFtZT4K 194705 2013-03-23 09:09:20 -0700 2013-03-27 15:45:20 -0700 Patch bug-113122-20130323090506.patch text/plain 7014 ggaren SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDE0NjY5MikKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDMyIEBACisyMDEzLTAzLTIyICBHZW9mZnJl eSBHYXJlbiAgPGdnYXJlbkBhcHBsZS5jb20+CisKKyAgICAgICAgSG9ub3IgdGhlIHNldHRpbmcg Zm9yIHdoZXRoZXIgSmF2YVNjcmlwdCBtYXJrdXAgaXMgZW5hYmxlZAorICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTEzMTIyCisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBkb20vU2NyaXB0YWJsZURvY3VtZW50 UGFyc2VyLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlNjcmlwdGFibGVEb2N1bWVudFBhcnNlcjo6 U2NyaXB0YWJsZURvY3VtZW50UGFyc2VyKTogQXBwbGllZCB0aGUKKyAgICAgICAgc2V0dGluZyBo ZXJlLCBzbyBhbGwgZG9jdW1lbnQgcGFyc2luZyB3b3VsZCBiZSBjb3ZlcmVkLiBUaGlzIGlzIHNp bWlsYXIKKyAgICAgICAgdG8gd2hhdCB3ZSBkbyBmb3IgcGx1Zy1pbiBzdHJpcHBpbmcuCisKKyAg ICAgICAgKiBodG1sL3BhcnNlci9IVE1MQ29uc3RydWN0aW9uU2l0ZS5jcHA6CisgICAgICAgIChX ZWJDb3JlOjpIVE1MQ29uc3RydWN0aW9uU2l0ZTo6aW5zZXJ0Rm9yZWlnbkVsZW1lbnQpOiBGaXhl ZCBhIGJ1ZyB3aGVyZQorICAgICAgICB3ZSB3b3VsZCBpbnNlcnQgYW4gU1ZHIHNjcmlwdCBlbGVt ZW50IGludG8gdGhlIGRvY3VtZW50IGV2ZW4gaW4gc2NyaXB0CisgICAgICAgIG1hcmt1cCBkaXNh YmxlZCBtb2RlLgorCisgICAgICAgIChUaGlzIGJ1ZyBoYXMgZXhpc3RlZCBmb3IgY29weS9wYXN0 ZSBmb3IgYSBsb25nIHRpbWUsIGJ1dCBvdGhlciBidWdzIGFuZAorICAgICAgICBxdWlya3MgaW4g U1ZHIGNvcHkvcGFzdGUgcGFwZXJlZCBvdmVyIGl0LiBJdCdzIGEgc2VyaW91cyBpc3N1ZSBub3cK KyAgICAgICAgdGhhdCBub24tcGFzdGUgY2xpZW50cyB3aWxsIHJlbHkgb24gdGhpcyBtb2RlLikK KworICAgICAgICAqIGh0bWwvcGFyc2VyL0hUTUxUcmVlQnVpbGRlci5jcHA6CisgICAgICAgIChX ZWJDb3JlOjpIVE1MVHJlZUJ1aWxkZXI6OnByb2Nlc3NUb2tlbkluRm9yZWlnbkNvbnRlbnQpOiBG aXhlZCB0aGUgc2FtZQorICAgICAgICBidWcgLS0gdGhpcyB0aW1lIGluIHRoZSBwYXJ0IG9mIHRo ZSBwYXJzZXIgdGhhdCBleGVjdXRlcyBzY3JpcHRzIGFzIHRoZXkKKyAgICAgICAgcGFyc2UuCisK KyAgICAgICAgSSBhZG9wdGVkIHRoZSB0b1NjcmlwdEVsZW1lbnQoKSBjb252ZW50aW9uIGZvciB0 ZXN0aW5nIGZvciBhIHNjcmlwdAorICAgICAgICBlbGVtZW50IHRvIG1hdGNoIHRoZSBYTUwgcGFy c2VyLgorCiAyMDEzLTAzLTIyICBSb2dlciBGb25nICA8cm9nZXJfZm9uZ0BhcHBsZS5jb20+CiAK ICAgICAgICAgVW5yZXZpZXdlZC4gRml4IEFwcGxlV2luIHBvcnQgZm9sbG93aW5nIGh0dHBzOi8v YnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xMTMxMDAuCkluZGV4OiBTb3VyY2UvV2Vi Q29yZS9kb20vU2NyaXB0YWJsZURvY3VtZW50UGFyc2VyLmNwcAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3Vy Y2UvV2ViQ29yZS9kb20vU2NyaXB0YWJsZURvY3VtZW50UGFyc2VyLmNwcAkocmV2aXNpb24gMTQ2 NjYyKQorKysgU291cmNlL1dlYkNvcmUvZG9tL1NjcmlwdGFibGVEb2N1bWVudFBhcnNlci5jcHAJ KHdvcmtpbmcgY29weSkKQEAgLTQwLDYgKzQwLDkgQEAgU2NyaXB0YWJsZURvY3VtZW50UGFyc2Vy OjpTY3JpcHRhYmxlRG9jdQogewogICAgIGlmICghcGx1Z2luQ29udGVudElzQWxsb3dlZChtX3Bh cnNlckNvbnRlbnRQb2xpY3kpICYmICghZG9jdW1lbnQtPnNldHRpbmdzKCkgfHwgZG9jdW1lbnQt PnNldHRpbmdzKCktPnVuc2FmZVBsdWdpblBhc3RpbmdFbmFibGVkKCkpKQogICAgICAgICBtX3Bh cnNlckNvbnRlbnRQb2xpY3kgPSBhbGxvd1BsdWdpbkNvbnRlbnQobV9wYXJzZXJDb250ZW50UG9s aWN5KTsKKworICAgIGlmIChzY3JpcHRpbmdDb250ZW50SXNBbGxvd2VkKG1fcGFyc2VyQ29udGVu dFBvbGljeSkgJiYgKGRvY3VtZW50LT5zZXR0aW5ncygpICYmICFkb2N1bWVudC0+c2V0dGluZ3Mo KS0+c2NyaXB0TWFya3VwRW5hYmxlZCgpKSkKKyAgICAgICAgbV9wYXJzZXJDb250ZW50UG9saWN5 ID0gZGlzYWxsb3dTY3JpcHRpbmdDb250ZW50KG1fcGFyc2VyQ29udGVudFBvbGljeSk7CiB9CiAK IH07CkluZGV4OiBTb3VyY2UvV2ViQ29yZS9odG1sL3BhcnNlci9IVE1MQ29uc3RydWN0aW9uU2l0 ZS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvaHRtbC9wYXJzZXIvSFRNTENvbnN0 cnVjdGlvblNpdGUuY3BwCShyZXZpc2lvbiAxNDY2NjIpCisrKyBTb3VyY2UvV2ViQ29yZS9odG1s L3BhcnNlci9IVE1MQ29uc3RydWN0aW9uU2l0ZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTQ2Miw3 ICs0NjIsOCBAQCB2b2lkIEhUTUxDb25zdHJ1Y3Rpb25TaXRlOjppbnNlcnRGb3JlaWduCiAgICAg bm90SW1wbGVtZW50ZWQoKTsgLy8gcGFyc2VFcnJvciB3aGVuIHhtbG5zIG9yIHhtbG5zOnhsaW5r IGFyZSB3cm9uZy4KIAogICAgIFJlZlB0cjxFbGVtZW50PiBlbGVtZW50ID0gY3JlYXRlRWxlbWVu dCh0b2tlbiwgbmFtZXNwYWNlVVJJKTsKLSAgICBhdHRhY2hMYXRlcihjdXJyZW50Tm9kZSgpLCBl bGVtZW50LCB0b2tlbi0+c2VsZkNsb3NpbmcoKSk7CisgICAgaWYgKHNjcmlwdGluZ0NvbnRlbnRJ c0FsbG93ZWQobV9wYXJzZXJDb250ZW50UG9saWN5KSB8fCAhdG9TY3JpcHRFbGVtZW50KGVsZW1l bnQuZ2V0KCkpKQorICAgICAgICBhdHRhY2hMYXRlcihjdXJyZW50Tm9kZSgpLCBlbGVtZW50LCB0 b2tlbi0+c2VsZkNsb3NpbmcoKSk7CiAgICAgaWYgKCF0b2tlbi0+c2VsZkNsb3NpbmcoKSkKICAg ICAgICAgbV9vcGVuRWxlbWVudHMucHVzaChIVE1MU3RhY2tJdGVtOjpjcmVhdGUoZWxlbWVudC5y ZWxlYXNlKCksIHRva2VuLCBuYW1lc3BhY2VVUkkpKTsKIH0KSW5kZXg6IFNvdXJjZS9XZWJDb3Jl L2h0bWwvcGFyc2VyL0hUTUxUcmVlQnVpbGRlci5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dl YkNvcmUvaHRtbC9wYXJzZXIvSFRNTFRyZWVCdWlsZGVyLmNwcAkocmV2aXNpb24gMTQ2NjYyKQor KysgU291cmNlL1dlYkNvcmUvaHRtbC9wYXJzZXIvSFRNTFRyZWVCdWlsZGVyLmNwcAkod29ya2lu ZyBjb3B5KQpAQCAtMjg2OCw3ICsyODY4LDggQEAgdm9pZCBIVE1MVHJlZUJ1aWxkZXI6OnByb2Nl c3NUb2tlbkluRm9yZQogICAgICAgICAgICAgYWRqdXN0U1ZHVGFnTmFtZUNhc2UodG9rZW4pOwog CiAgICAgICAgIGlmICh0b2tlbi0+bmFtZSgpID09IFNWR05hbWVzOjpzY3JpcHRUYWcgJiYgbV90 cmVlLmN1cnJlbnRTdGFja0l0ZW0oKS0+aGFzVGFnTmFtZShTVkdOYW1lczo6c2NyaXB0VGFnKSkg ewotICAgICAgICAgICAgbV9zY3JpcHRUb1Byb2Nlc3MgPSBtX3RyZWUuY3VycmVudEVsZW1lbnQo KTsKKyAgICAgICAgICAgIGlmIChzY3JpcHRpbmdDb250ZW50SXNBbGxvd2VkKG1fdHJlZS5wYXJz ZXJDb250ZW50UG9saWN5KCkpKQorICAgICAgICAgICAgICAgIG1fc2NyaXB0VG9Qcm9jZXNzID0g bV90cmVlLmN1cnJlbnRFbGVtZW50KCk7CiAgICAgICAgICAgICBtX3RyZWUub3BlbkVsZW1lbnRz KCktPnBvcCgpOwogICAgICAgICAgICAgcmV0dXJuOwogICAgICAgICB9CkluZGV4OiBMYXlvdXRU ZXN0cy9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCShyZXZp c2lvbiAxNDY2OTQpCisrKyBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHdvcmtpbmcgY29weSkKQEAg LTEsMyArMSwxMyBAQAorMjAxMy0wMy0yMiAgR2VvZmZyZXkgR2FyZW4gIDxnZ2FyZW5AYXBwbGUu Y29tPgorCisgICAgICAgIEhvbm9yIHRoZSBzZXR0aW5nIGZvciB3aGV0aGVyIEphdmFTY3JpcHQg bWFya3VwIGlzIGVuYWJsZWQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19i dWcuY2dpP2lkPTExMzEyMgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgor CisgICAgICAgICogZWRpdGluZy91bnN1cHBvcnRlZC1jb250ZW50L3NjcmlwdC1tYXJrdXAtZW5h YmxlZC1zZXR0aW5nLWV4cGVjdGVkLnR4dDogQWRkZWQuCisgICAgICAgICogZWRpdGluZy91bnN1 cHBvcnRlZC1jb250ZW50L3NjcmlwdC1tYXJrdXAtZW5hYmxlZC1zZXR0aW5nLmh0bWw6IEFkZGVk LgorCiAyMDEzLTAzLTIyICBTdGVwaGVuIENoZW5uZXkgIDxzY2hlbm5leUBjaHJvbWl1bS5vcmc+ CiAKICAgICAgICAgW0Nocm9taXVtXSBUZXN0IGV4cGVjdGF0aW9ucyBhZnRlciBTa2lhIGNoYW5n ZXMKSW5kZXg6IExheW91dFRlc3RzL2VkaXRpbmcvdW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQt bWFya3VwLWVuYWJsZWQtc2V0dGluZy1leHBlY3RlZC50eHQKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0 VGVzdHMvZWRpdGluZy91bnN1cHBvcnRlZC1jb250ZW50L3NjcmlwdC1tYXJrdXAtZW5hYmxlZC1z ZXR0aW5nLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2VkaXRpbmcv dW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQtbWFya3VwLWVuYWJsZWQtc2V0dGluZy1leHBlY3Rl ZC50eHQJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSw1IEBACitUaGlzIHRlc3QgdmVyaWZpZXMg dGhhdCBzY3JpcHQgZWxlbWVudHMgYXJlIG5vdCBpbnNlcnRlZCBpbnRvIHRoZSBkb2N1bWVudCBp ZiB0aGUgV2ViQ29yZSBzY3JpcHRNYXJrdXBFbmFibGVkIHNldHRpbmcgaXMgZmFsc2UuCisKK1BB U1M6IGRvY3VtZW50V2l0aFNjcmlwdC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IikubGVu Z3RoIHNob3VsZCBiZSAwIGFuZCBpcy4KK1BBU1M6IGRvY3VtZW50V2l0aFNWR1NjcmlwdC5nZXRF bGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IikubGVuZ3RoIHNob3VsZCBiZSAwIGFuZCBpcy4KKyAK SW5kZXg6IExheW91dFRlc3RzL2VkaXRpbmcvdW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQtbWFy a3VwLWVuYWJsZWQtc2V0dGluZy5odG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2VkaXRp bmcvdW5zdXBwb3J0ZWQtY29udGVudC9zY3JpcHQtbWFya3VwLWVuYWJsZWQtc2V0dGluZy5odG1s CShyZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMvZWRpdGluZy91bnN1cHBvcnRlZC1jb250ZW50 L3NjcmlwdC1tYXJrdXAtZW5hYmxlZC1zZXR0aW5nLmh0bWwJKHdvcmtpbmcgY29weSkKQEAgLTAs MCArMSwzNyBAQAorPHA+VGhpcyB0ZXN0IHZlcmlmaWVzIHRoYXQgc2NyaXB0IGVsZW1lbnRzIGFy ZSBub3QgaW5zZXJ0ZWQgaW50byB0aGUgZG9jdW1lbnQgaWYgdGhlIFdlYkNvcmUgc2NyaXB0TWFy a3VwRW5hYmxlZCBzZXR0aW5nIGlzIGZhbHNlLjwvcD4KKzxwcmUgaWQ9ImxvZyI+PC9wcmU+CisK KzxzY3JpcHQ+CitmdW5jdGlvbiBsb2cocykKK3sKKyAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJ ZCgibG9nIikuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUocyArICJcbiIpKTsK K30KKworZnVuY3Rpb24gc2hvdWxkQmUoYURlc2NyaXB0aW9uLCBhLCBiKQoreworICAgIGlmIChh ID09IGIpIHsKKyAgICAgICAgbG9nKCJQQVNTOiAiICsgYURlc2NyaXB0aW9uICsgIiBzaG91bGQg YmUgIiArIGIgKyAiIGFuZCBpcy4iKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKworICAgIGxv ZygiRkFJTDogIiArIGFEZXNjcmlwdGlvbiArICIgc2hvdWxkIGJlICIgKyBiICsgIiBidXQgaW5z dGVhZCBpcyAiICsgYSArICIuIik7Cit9CisKK2lmICh3aW5kb3cudGVzdFJ1bm5lcikgeworICAg IHRlc3RSdW5uZXIuZHVtcEFzVGV4dCgpOworICAgIHdpbmRvdy5pbnRlcm5hbHMuc2V0dGluZ3Mu c2V0U2NyaXB0TWFya3VwRW5hYmxlZChmYWxzZSk7Cit9IGVsc2UKKyAgICBsb2coIlRoaXMgdGVz dCBkZXBlbmRzIG9uIHRoZSBKYXZhU2NyaXB0TWFya3VwRW5hYmxlZCBzZXR0aW5nIGJlaW5nIGZh bHNlLiIpOworCit3aW5kb3cub25sb2FkID0gZnVuY3Rpb24gdGVzdCgpCit7CisJdmFyIGRvY3Vt ZW50V2l0aFNjcmlwdCA9IGZyYW1lc1swXS5kb2N1bWVudDsKKyAgICBzaG91bGRCZSgnZG9jdW1l bnRXaXRoU2NyaXB0LmdldEVsZW1lbnRzQnlUYWdOYW1lKCJzY3JpcHQiKS5sZW5ndGgnLCBkb2N1 bWVudFdpdGhTY3JpcHQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoInNjcmlwdCIpLmxlbmd0aCwgMCk7 CisKKyAgICB2YXIgZG9jdW1lbnRXaXRoU1ZHU2NyaXB0ID0gZnJhbWVzWzFdLmRvY3VtZW50Owor ICAgIHNob3VsZEJlKCdkb2N1bWVudFdpdGhTVkdTY3JpcHQuZ2V0RWxlbWVudHNCeVRhZ05hbWUo InNjcmlwdCIpLmxlbmd0aCcsIGRvY3VtZW50V2l0aFNWR1NjcmlwdC5nZXRFbGVtZW50c0J5VGFn TmFtZSgic2NyaXB0IikubGVuZ3RoLCAwKTsKK30KKzwvc2NyaXB0PgorCis8aWZyYW1lIHNyY2Rv Yz0iPHNjcmlwdD52YXIgcHduZWQgPSAxOzwvc2NyaXB0PiI+PC9pZnJhbWU+Cis8aWZyYW1lIHNy Y2RvYz0iPHN2Zz48c2NyaXB0PnZhciBwd25lZCA9IDE7PC9zY3JpcHQ+PC9zdmc+Ij48L2lmcmFt ZT4K 194719 2013-03-23 15:06:26 -0700 2013-03-23 15:06:26 -0700 Attempt to create a reduction with copy & paste 113122.html text/html 699 rniwa PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8Ym9keT4KPGRpdiBpZD0ic291cmNlIiBvbmNvcHk9InBh c3RlU2NyaXB0KGV2ZW50KSIgY29udGVudGVkaXRhYmxlPmNvcHkgbWU8L2Rpdj4KPGRpdiBpZD0i ZGVzdGluYXRpb24iIG9ucGFzdGU9InBhc3RlZCh0aGlzKSIgY29udGVudGVkaXRhYmxlPnBhc3Rl IGl0IGhlcmU8L2Rpdj4KPHNjcmlwdD4KCmZ1bmN0aW9uIHBhc3RlU2NyaXB0KGV2ZW50KSB7CiAg ICBldmVudC5wcmV2ZW50RGVmYXVsdCgpOwogICAgZXZlbnQuY2xpcGJvYXJkRGF0YS5zZXREYXRh KCd0ZXh0L2h0bWwnLCAnPHN2ZyB2aWV3Qm94PSIwIDAgMTAwIDEwMCIgd2lkdGg9IjEwcHgiIGhl aWdodD0iMTBweCIgdmVyc2lvbj0iMS4xIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9z dmciPjxzY3JpcHQ+YWxlcnQoInB3bmQhIik8L3NjcicgKyAnaXB0Pjwvc3ZnPicpCn0KCmZ1bmN0 aW9uIHBhc3RlZChlbGVtZW50KSB7CiAgICBzZXRUaW1lb3V0KGZ1bmN0aW9uICgpIHsKICAgICAg ICBhbGVydChlbGVtZW50LmlubmVySFRNTCk7CiAgICB9LCAwKTsKfQoKc2V0VGltZW91dChmdW5j dGlvbiAoKSB7CiAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnc291cmNlJykuZm9jdXMoKTsK ICAgIGRvY3VtZW50LmV4ZWNDb21tYW5kKCdzZWxlY3RBbGwnKTsKfSwgMCk7Cgo8L3NjcmlwdD4K PC9ib2R5Pgo8L2h0bWw+ 194769 2013-03-24 15:08:30 -0700 2013-03-24 15:08:30 -0700 Script injection attack examples scratch.html text/html 1002 ggaren PGlmcmFtZSBpZD0ic291cmNlMSIgc2FuZGJveD0iYWxsb3ctc2FtZS1vcmlnaW4iIHNyY2RvYz0i PHNjcmlwdD5hbGVydCgnU2NyaXB0IGluamVjdGlvbiBhdHRhY2sgc3VjY2VlZGVkICg8c2NyaXB0 PikuJyk8L3NjcmlwdD48aW1nIHNyYz0nZGF0YTppbWFnZS9naWY7YmFzZTY0LFIwbEdPRGxoQVFB QkFJQUFBT1RtN0FBQUFDSDVCQUVBQUFBQUxBQUFBQUFCQUFFQUFBSUNSQUVBT3c9PScgb25sb2Fk PSdhbGVydCgmcXVvdDtTY3JpcHQgaW5qZWN0aW9uIGF0dGFjayBzdWNjZWVkZWQgKDxpbWc+KS4m cXVvdDspJz48L2ltZz4iPjwvaWZyYW1lPgo8aWZyYW1lIGlkPSJkZXN0aW5hdGlvbjEiPjwvaWZy YW1lPgo8aWZyYW1lIGlkPSJkZXN0aW5hdGlvbjIiPjwvaWZyYW1lPgo8aWZyYW1lIGlkPSJkZXN0 aW5hdGlvbjMiPjwvaWZyYW1lPgoKPHNjcmlwdD4KZnVuY3Rpb24gcmVwb3J0U2NyaXB0KCkKewoJ YWxlcnQoJ1NjcmlwdCBpbmplY3Rpb24gYXR0YWNrIHN1Y2NlZWRlZCAoPHNjcmlwdD4pLicpOwp9 CgpmdW5jdGlvbiByZXBvcnRJbWFnZSgpCnsKCWFsZXJ0KCdTY3JpcHQgaW5qZWN0aW9uIGF0dGFj ayBzdWNjZWVkZWQgKDxpbWc+KS4nKQp9CgpmdW5jdGlvbiAkKGlkKQp7CglyZXR1cm4gZG9jdW1l bnQuZ2V0RWxlbWVudEJ5SWQoaWQpOwp9Cgp3aW5kb3cub25sb2FkID0gZnVuY3Rpb24oKSB7Cgkk KCJkZXN0aW5hdGlvbjEiKS5jb250ZW50RG9jdW1lbnQud3JpdGUoCgkJJCgic291cmNlMSIpLmNv bnRlbnREb2N1bWVudC5maXJzdENoaWxkLmlubmVySFRNTCk7CgoJJCgiZGVzdGluYXRpb24yIiku c2V0QXR0cmlidXRlKCJzcmNEb2MiLAoJCSQoInNvdXJjZTEiKS5jb250ZW50RG9jdW1lbnQuZmly c3RDaGlsZC5pbm5lckhUTUwpOwoKCSQoImRlc3RpbmF0aW9uMyIpLnNldEF0dHJpYnV0ZSgic3Jj IiwKCQkiZGF0YTp0ZXh0L2h0bWwsICIgKyAkKCJzb3VyY2UxIikuY29udGVudERvY3VtZW50LmZp cnN0Q2hpbGQuaW5uZXJIVE1MKTsKfQo8L3NjcmlwdD4K 194891 2013-03-25 11:11:01 -0700 2013-03-25 11:11:01 -0700 Specific demonstration of why an empty script element is dangerous scratch.html text/html 780 ggaren PGlmcmFtZSBpZD0ic291cmNlIiBzYW5kYm94PSJhbGxvdy1zYW1lLW9yaWdpbiIgc3JjZG9jPSI8 Ym9keT48c2NyaXB0Pjwvc2NyaXB0PjxwPlVyZ2VudDogUmVwbHkgdG8gdGhpcyBlbWFpbC48L3A+ PHA+LS0gWW91ciBCYW5rIChUTSk8L3A+PC9ib2R5PiI+PC9pZnJhbWU+CjxpZnJhbWUgaWQ9ImRl c3RpbmF0aW9uIj48L2lmcmFtZT4KCjxzY3JpcHQ+CmZ1bmN0aW9uICQoaWQpCnsKCXJldHVybiBk b2N1bWVudC5nZXRFbGVtZW50QnlJZChpZCk7Cn0KCmZ1bmN0aW9uIGFyYml0cmFyeVNvdXJjZSgp CnsKCXJldHVybiAiYWxlcnQoJ1NjcmlwdCBpbmplY3Rpb24gYXR0YWNrIHN1Y2NlZWRlZCAoPHNj cmlwdD4pLicpIjsKfQoKd2luZG93Lm9ubG9hZCA9IGZ1bmN0aW9uKCkgewoJLy8gRWRpdGluZyBv cGVyYXRpb24gdG8gaW5zZXJ0IHRvIHRoZSBmcm9udCBvZiB0aGUgZG9jdW1lbnQuCgkkKCJzb3Vy Y2UiKS5jb250ZW50RG9jdW1lbnQuYm9keS5maXJzdENoaWxkLmlubmVyVGV4dCA9IGFyYml0cmFy eVNvdXJjZSgpOwoKCS8vIE9vcHMhIFRoYXQgd2FzIGFuIHVuc2FmZSBpbnNlcnRpb24gcG9pbnQs IGFuZCBub3cgdGhlIDxzY3JpcHQ+IGVsZW1lbnQgaGFzIHRleHQgY29udGVudC4KCgkvLyBOb3cs IGNvcHlpbmcgb3V0IG9mIHRoZSBzYW5kYm94ZWQgZG9jdW1lbnQgd2lsbCBydW4gc2NyaXB0LgoJ JCgiZGVzdGluYXRpb24iKS5jb250ZW50RG9jdW1lbnQud3JpdGUoJCgic291cmNlIikuY29udGVu dERvY3VtZW50LmJvZHkuaW5uZXJIVE1MKTsKfQo8L3NjcmlwdD4K