1769

<div dir="ltr" style="text-align: left;" trbidi="on">
<h2>
Cross-Site Scripting
(XSS) </h2>
Cross-site scripting (XSS) is a vulnerability that permits an attacker
to inject code (typically HTML or Javascript) into contents of a
website not under the attacker's control. When a victim views such a
page, the injected code executes in the victim's browser. Thus, the
attacker has bypassed the
browser's <a href="http://www.google.com/search?q=same+origin+policy">same
origin policy</a> and can steal victim's private information
associated with the website in question.
<br />

In a <b>reflected XSS</b> attack, the attack is in the request itself
(frequently the URL) and the vulnerability occurs when the server
inserts the attack in the response verbatim or incorrectly escaped or
sanitized. The victim triggers the attack by browsing to a malicious
URL created by the attacker. In a <b>stored XSS</b> attack, the attacker
stores the attack in the application (e.g., in a snippet) and the
victim triggers the attack by browsing to a page on the server that
renders the attack, by not properly escaping or sanitizing the stored
data.
<br />

<div style="margin-left: 18pt;">
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> More details </h4>
<div id="xss_desc" style="display: block;">

To understand how this could happen: suppose the
URL <code>http://www.google.com/search?q=flowers</code> returns a page
containing the HTML fragment
<br />

<pre><p>Your search for 'flowers'
returned the following results:</p>
</pre>
that is, the value of the query parameter <code>q</code> is inserted
verbatim into the page returned by
Google. If <code>www.google.com</code> did not do any validation or
escaping of <code>q</code> (it does), an attacker could craft a link
that looks like this:<br />
<br />
<pre>http://www.google.com/search?q=flowers+%3Cscript%3Eevil_script()%3C/script%3E
</pre>
and trick a victim into clicking on this link. When a victim loads
this link, the following page gets rendered in the victim's browser:

<pre><p>Your search for 'flowers<script>evil_script()</script>'
returned the following results:</p>
</pre>
And the browser executes <code>evil_script()</code>. And since
the page comes
from <code>www.google.com</code>, <code>evil_script()</code> is
executed in the context of <code>www.google.com</code> and has access
to all the victim's browser state and cookies for that domain.
<br />

Note that the victim does not even need to explicitly click on the
malicious link. Suppose the attacker
owns <code>www.evil.example.com</code>, and creates a page with an
<code><iframe></code> pointing to the malicious link; if the
victim visits <code>www.evil.example.com</code>, the attack will
silently be activated.
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="2__xss_challenge"> </a> XSS Challenges </h3>
Typically, if you can get Javascript to execute on a page when it's
viewed by another user, you have an XSS vulnerability. A simple
Javascript function to use when hacking is the <code>alert()</code>
function, which creates a pop-up box with whatever string you pass as
an argument.
<br />

You might think that inserting an alert message isn't terribly
dangerous, but if you can inject that, you can inject other scripts
that are more malicious. It is not necessary to be able to inject any
particular special character in order to attack. If you can
inject <code>alert(1)</code> then you can inject arbitrary script
using <code>eval(String.fromCharCode(...))</code>.
<br />

Your challenge is to find XSS vulnerabilities in Gruyere. You
should look for vulnerabilities both in URLs and in stored data. Since
XSS vulnerabilities usually involve applications not properly handling
untrusted user data, a common method of attack is to enter random text
in input fields and look at how it gets rendered in the response
page's HTML source. But before we do that, let's try something simpler.
<br />

<h3>
<a href="https://www.blogger.com/null" name="2__file_upload_xss"> </a> File Upload XSS </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" />
<b>Can you upload a file that allows you to execute arbitrary script
on the <code>google-gruyere.appspot.com</code> domain?</b>
<br />
<div style="margin-left: 18pt;">
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint </h4>
<div id="upload_xss_hint1" style="display: block;">

You can upload HTML files and HTML files can contain script.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="upload_xss_sol" style="display: block;">
<b>To exploit,</b> upload a <code>.html</code> file containing a script like this:
<br />
<pre><script>
alert(document.cookie);
</script>
</pre>
<b>To fix,</b> host the content on a separate domain so the script
won't have access to any content from your domain. That is, instead of
hosting user content on <code>example.com/<i>username</i></code> we
would host it at <code><i>username</i>.usercontent.example.com</code>
or <code><i>username</i>.example-usercontent.com</code>. (Including
something like "<code>usercontent</code>" in the domain name avoids
attackers registering usernames that look innocent
like <code>wwww</code> and using them for phishing attacks.)
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="2__reflected_xss"> </a> Reflected XSS </h3>
There's an interesting problem here. Some browsers have built-in
protection against reflected XSS attacks. There are also browser
extensions like NoScript that provide some protection.  If you're
using one of those browsers or extensions, you may need to use a
different browser or temporarily disable the extension to execute
these attacks.
<br />

At the time this codelab was written, the two browsers which had
this protection were IE and Chrome. To work around this, Gruyere
automatically includes a <tt>X-XSS-Protection: 0</tt> HTTP header in
every response which is recognized by IE and will be recognized by
future versions of Chrome. (It's available in the developer channel
now.) If you're using Chrome, you can try starting it with
the <tt>--disable-xss-auditor</tt> flag by entering one of these
commands:
<br />
<ul>
<li>Windows: <tt>"C:\Documents and Settings\USERNAME\Local
Settings\Application
Data\Google\Chrome\Application\chrome.exe" --disable-xss-auditor</tt>
</li>
<li>Mac: <tt>/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
--disable-xss-auditor</tt>
</li>
<li>GNU/Linux: <tt>/opt/google/chrome/google-chrome --disable-xss-auditor</tt>
</li>
</ul>
If you're using Firefox with the NoScript extension,
add <tt>google-gruyere.appspot.com</tt> to the allow list. If you still
can't get the XSS attacks to work, try a different browser.

You may think that you don't need to worry about XSS if the browser
protects against it. The truth is that the browser protection can't be
perfect because it doesn't really know your application and therefore
there may be ways for a clever hacker to circumvent that
protection. The real protection is to not have an XSS vulnerability in
your application in the first place.
<br />

<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" />
<b>Find a reflected XSS attack. What we want is a URL
that when clicked on will execute a script.</b>

What does this URL do?
<br />

<pre>http://google-gruyere.appspot.com/123/invalid
</pre>
</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="xss_url_hint2" style="display: block;">

The most dangerous characters in a URL are <code><</code>
and <code>></code>. If you can get an application to directly
insert what you want in a page and can get those characters through,
then you can probably get a script through. Try these:
<br />

<pre>http://google-gruyere.appspot.com/123/%3e%3c
http://google-gruyere.appspot.com/123/%253e%253c
http://google-gruyere.appspot.com/123/%c0%be%c0%bc
http://google-gruyere.appspot.com/123/%26gt;%26lt;
http://google-gruyere.appspot.com/123/%26amp;gt;%26amp;lt;
http://google-gruyere.appspot.com/123/\074\x3c\u003c\x3C\u003C\X3C\U003C
http://google-gruyere.appspot.com/123/+ADw-+AD4-
</pre>
This tries <code>></code> and <code><</code> in many different
ways that might be able to make it through the URL and get rendered
incorrectly using: verbatim (URL %-encoding), double %-encoding, bad
UTF-8 encoding, HTML &-encoding, double &-encoding, and
several different variations on C-style encoding. View the resulting
source and see if any of those work. (Note: literally
typing <code>><</code> in the URL is identical
to <code>%3e%3c</code> because the browser automatically %-encodes
those character. If you are trying to want a literal <code>></code>
or <code><</code> then you will need to use a tool like curl to
send those characters in URL.)
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="xss_url_sol" style="display: block;">

<b>To exploit,</b> create a URL like the following and get a
victim to click on it:
<br />

<pre>http://google-gruyere.appspot.com/123/<script>alert(1)</script>
</pre>
<b>To fix,</b> you need to escape user input that is displayed in
error messages. Error messages are displayed
using <code><a href="https://google-gruyere.appspot.com/code/?resources/error.gtl">error.gtl</a></code>,
but are not escaped in the template. The part of the template that
renders the message is <code>{{message}}</code> and it's missing the
modifier that tells it to escape user input. Add
the <code>:text</code> modifier to escape the user input:
<br />
<pre><div class="message">{{_message:text}}</div>
</pre>
This flaw would have been best mitigated by a design that escapes all
output by default and only displays raw HTML when explicitly tagged to
do so. There are
also <a href="http://www.google.com/search?q=XSS+auto+escaping" target="_top">autoescaping</a> features available in many template
systems.
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="2__stored_xss"> </a> Stored XSS </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Now find a stored XSS. What we want
to do is put a script in a place where Gruyere will serve it back to
another user.</b>
<br />

The most obvious place that Gruyere serves back
user-provided data is in a snippet (ignoring uploaded files which we've already discussed.)
<div style="margin-left: 18pt;">
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 1 </h4>
<div id="xss_stored_hint1" style="display: block;">

Put this in a snippet and see what you get:
<br />

<pre><script>alert(1)</script>
</pre>
There are many different ways that script can be embedded in a
document.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="xss_stored_hint2" style="display: block;">

Hackers don't limit themselves to valid HTML syntax. Try some invalid
HTML and see what you get. You may need to experiment a bit in order
to find something that will work. There are multiple ways to do this.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="xss_stored_sol" style="display: block;">

<b>To exploit,</b> enter any of these as your snippet (there
are certainly more methods):
<br />

(2) <p <script>alert(1)</script>hello

(3) </td <script>alert(1)</script>hello
</pre>
Notice that there are multiple failures in sanitizing the
HTML. Snippet 1 worked because <code>onmouseover</code> was
inadvertently omitted from the list of disallowed attributes
in <code><a href="https://google-gruyere.appspot.com/code/?sanitize.py">sanitize.py</a></code>. Snippets
2 and 3 work because browsers tend to be forgiving with HTML syntax
and the handling of both start and end tags is buggy.
<br />

<b>To fix,</b> we need to investigate and fix the sanitizing performed
on the snippets. Snippets are sanitized in <code>_SanitizeTag</code>
in the <code><a href="https://google-gruyere.appspot.com/code/?sanitize.py">sanitize.py</a></code>
file. Let's block snippet 1 by adding <code>"onmouseover"</code> to
the list of <code>disallowed_attributes</code>.
<br />

<b>Oops!</b> This doesn't completely solve the problem. Looking at
the code that was just fixed, can you find a way to bypass the fix?
<br />

Take a close look at the code in <code>_SanitizeTag</code> that
determines whether or not an HTML attribute is allowed or not.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="xss_stored_not_fixed" style="display: block;">

The fix was insufficient because the code that checks for disallowed
attributes is case sensitive and HTML is not. So this still works:
<br />

<pre>(1') <a ONMOUSEOVER="alert(1)" href="#">read this!</a>
</pre>
Correctly sanitizing HTML is a tricky
problem. The <code>_SanitizeTag</code> function has a number of
critical design flaws:
<br />

<ul>
<li> It does not validate the well-formedness of the input HTML. As we
see, badly formed HTML passes through the sanitizer unchanged. Since
browsers typically apply very lenient parsing, it is very hard to
predict the browser's interpretation of the given HTML unless we
exercise strict control on its format.
</li>
<li> It uses blacklisting of attributes, which is a bad technique. One
of our exploits got past the blacklist simply by using an uppercase
version of the attribute. There could be other
attributes <a href="http://www.w3.org/TR/html40/index/attributes.html" target="_top">missing from this list</a> that are dangerous. It is
always better to whitelist known good values.
</li>
<li> The sanitizer does not do any further sanitization of attribute
values. This is dangerous since URI attributes like <code>href</code>
and <code>src</code> and the <code>style</code> attribute can all be
used to inject javascript.
</li>
</ul>
The right approach to HTML sanitization is to:
<br />
<ul>
<li> Parse the input into an intermediate DOM structure, then rebuild
the body as well-formed output.
</li>
<li> Use strict whitelists for allowed tags and attributes.
</li>
<li> Apply strict sanitization of URL and CSS attributes if they are
permitted.
</li>
</ul>
Whenever possible it is preferable to use an already available known
and proven <a href="http://www.google.com/search?q=sanitize+html" target="_top">HTML sanitizer</a>.
<br />

</div>
</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="2__stored_xss_via_html_attribute"> </a> Stored XSS via
HTML Attribute </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /> <b>You can also do XSS by injecting a value into an
HTML attribute. Inject a script by setting the color value in a
profile.</b>
<br />
<div style="margin-left: 18pt;">

The color is rendered as <code>style='color:<i>color</i>'</code>.
Try including a single quote character in your color name.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="xss_color_hint2" style="display: block;">

You can insert an HTML attribute that executes a script.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fixes </h4>
<div id="xss_color_sol" style="display: block;">

<b>To exploit,</b> use the following for your color
preference:
<br />

<pre>red' onload='alert(1)' onmouseover='alert(2)
</pre>
You may need to move the mouse over the snippet to trigger the
attack. This attack works because the first quote ends
the <code>style</code> attribute and the second quote starts the
onload attribute.
<br />

But this attack shouldn't work at all. Take a look
at <code><a href="https://google-gruyere.appspot.com/code/?resources/home.gtl">home.gtl</a></code> where
it renders the color. It says <code>style='{{color:text}}'</code> and
as we saw earlier, the <code>:text</code> part tells it to escape
text. So why doesn't this get escaped?
In <code><a href="https://google-gruyere.appspot.com/code/?gtl.py">gtl.py</a></code>, it
calls <code>cgi.escape(str(value))</code> which takes an optional
second parameter that indicates that the value is being used in an
HTML attribute. So you can replace this
with <code>cgi.escape(str(value),True)</code>. Except that doesn't fix
it! The problem is that <code>cgi.escape</code> assumes your HTML
attributes are enclosed in double quotes and this file is using single
quotes. (This should teach you to always carefully read the
documentation for libraries you use and to always test that they do
what you want.)
<br />

You'll note that this attack uses both <code>onload</code>
and <code>onmouseover</code>. That's because even though W3C specifies
that onload events is only supported on <code>body</code>
and <code>frameset</code> elements, some browsers support them on
other elements. So if the victim is using one of those browsers, the
attack always succeeds. Otherwise, it succeeds when the user moves the
mouse. It's not uncommon for attackers to use multiple attack vectors
at the same time.
<br />

<b>To fix,</b> we need to use a correct text escaper, that escapes
single and double quotes too. Add the following function
to <code><a href="https://google-gruyere.appspot.com/code/?gtl.py">gtl.py</a></code> and call it instead
of <code>cgi.escape</code> for the <code>text</code> escaper.
<br />

<pre>def _EscapeTextToHtml(var):
  """Escape HTML metacharacters.

This function escapes characters that are dangerous to insert into
  HTML. It prevents XSS via quotes or script injected in attribute values.

It is safer than cgi.escape, which escapes only <, >, & by default.
  cgi.escape can be told to escape double quotes, but it will never
  escape single quotes.
  """
  meta_chars = {
      '"': '&quot;',
      '\'': '&#39;',  # Not &apos;
      '&': '&amp;',
      '<': '&lt;',
      '>': '&gt;',
      }
  escaped_var = ""
  for i in var:
    if i in meta_chars:
      escaped_var = escaped_var + meta_chars[i]
    else:
      escaped_var = escaped_var + i
  return escaped_var
</pre>
<b>Oops!</b> This doesn't completely solve the problem.  Even with the
above fix in place, the color value is still vulnerable.
<br />
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 1 </h4>
<div id="another_style_xss_hint1" style="display: block;">

Some browsers allow you to include script in stylesheets.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="another_style_xss_hint2" style="display: block;">

The easiest browser to exploit in this way is Internet Explorer which
supports dynamic CSS properties.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Another Exploit and Fix </h4>
<div id="another_style_xss_sol" style="display: block;">

Internet Explorer's dynamic CSS properites (aka CSS expressions) make
this attack particularly easy.
<br />

<b>To exploit,</b> use the following for your color
preference:
<pre>expression(alert(1))
</pre>
While other browsers don't support CSS expressions, there are other
dangerous CSS properties, such as Mozilla's <code>-moz-binding</code>.
<br />

<b>To fix,</b> we need to sanitize the color as a color.
The best thing to do would be to add a new output sanitizing form to
gtl, i.e., we would write <code>{{foo:color}}</code> which makes
sure <code>foo</code> is safe to use as a color. This function can be
used to sanitize:
<br />

<pre>SAFE_COLOR_RE = re.compile(r"^#?[a-zA-Z0-9]*$")

def _SanitizeColor(color):
  """Sanitizes a color, returning 'invalid' if it's invalid.

A valid value is either the name of a color or # followed by the
  hex code for a color (like #FEFFFF). Returning an invalid value
  value allows a style sheet to specify a default value by writing
  'color:default; color:{{foo:color}}'.
  """

if SAFE_COLOR_RE.match(color):
    return color
  return 'invalid'
</pre>
Colors aren't the only values we might want to allow users to
provide. You should do similar sanitizing for user-provided fonts,
sizes, urls, etc.  It's helpful to do input validation, so that when a
user enters an invalid value, you'll reject it at that time. But only
doing input validation would be a mistake: if you find an error in
your validation code or a new browser exposes a new attack vector,
you'd have to go back and scrub all previously entered values. Or, you
could add the output validation which you should have been doing in
the first place.
</div>
</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="2__stored_xss_via_ajax"> </a> Stored XSS via AJAX </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find an XSS attack that uses a bug in
Gruyere's AJAX code.</b> The attack should be triggered when you click
the refresh link on the page.
<br />

Run <code>curl</code>
on <code>http://google-gruyere.appspot.com/123/feed.gtl</code> and look at
the result. (Or browse to it in your browser and view source.)  You'll
see that it includes each user's first snippet into the response. This
entire response is then evaluated on the client side which then
inserts the snippets into the document. Can you put something in your
snippet that will be parsed differently than expected?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="xss_ajax_hint2" style="display: block;">

Try putting some quotes (<code>"</code>) in your snippet.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fixes </h4>
<div id="xss_ajax_sol" style="display: block;">

<b>To exploit,</b> Put this in your snippet:
<br />

<pre>all <span style=display:none>"
+ (alert(1),"")
+ "</span>your base
</pre>
The JSON should look like
<br />
<pre>_feed(({..., "Mallory": "snippet", ...}))</pre>
but instead looks like this:
<pre>_feed({..., "Mallory": <u>"all <span style=display:none>"</u>
+ <u>(alert(1),"")</u>
+ <u>"</span>your base"</u>, ...})</pre>
Each underlined part is
a separate expression. Note that this exploit is written to be
invisible both in the original page rendering (because of
the <code><span style=display:none></code>) and after refresh (because it inserts only an empty string). All that will appear on the screen
is <a href="http://www.google.com/search?q=all+your+base+are+belong+to+us" target="_top">all your base</a>. There are bugs on both the server
and client sides which enable this attack.

<b>To fix,</b> first, on the server side, the text is incorrectly
escaped when it is rendered in the JSON response. The template
says <code>{{snippet.0:html}}</code> but that's not enough. This text
is going to be inserted into the innerHTML of a DOM node so the HTML
does have to be sanitized. However, that sanitized text is then going
to be inserted into Javascript and single and double quotes have to be
escaped. That is, adding support for <code>{{...:js}}</code> to GTL
would not be sufficient; we would also need to support something
like <code>{{...:html:js}}</code>.
<br />
To escape quotes, use <code>\x27</code> and <code>\x22</code>
for single and double quote respectively. Replacing them
with <code>&#27;</code> and <code>&quot;</code> is incorrect
as those are not recognized in Javascript strings and will break
quotes around HTML attribute.
<br />

Second, in the browser, Gruyere converts the JSON by using
Javascript's <code>eval</code>. In general, <code>eval</code> is very
dangerous and should rarely be used. If it used, it must be used very
carefully, which is hardly the case here. We should be using the JSON
parser which ensures that the string does not include any unsafe
content. The JSON parser is available
at <a href="http://www.json.org/" target="_top">json.org</a>.
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="2__reflected_xss_via_ajax"> </a> Reflected XSS via
AJAX </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /><b>Find a URL that when clicked on will execute a
script using one of Gruyere's AJAX features.</b>
<br />

When Gruyere refreshes a user snippets page, it
uses
<br />
<pre>http://google-gruyere.appspot.com/123/feed.gtl?uid=value</pre>
and the result is the script
<pre>_feed((["user", "snippet1", ... ]))</pre>
</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="xss_ajax2_hint2" style="display: block;">

This uses a different vulnerability, but the exploit is very similar
to the previous reflected XSS exploit.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fixes </h4>
<div id="xss_ajax2_sol" style="display: block;">

<b>To exploit,</b> create a URL like the following and get a victim to click on it:
<br />

<pre>http://google-gruyere.appspot.com/123/feed.gtl?uid=<script>alert(1)</script>
http://google-gruyere.appspot.com/123/feed.gtl?uid=%3Cscript%3Ealert(1)%3C/script%3E
</pre>
This renders as
<br />
<pre>_feed((["<script>alert(1)</script>"]))</pre>
which surprisingly <i>does</i> execute the script. The bug is that
Gruyere returns all gtl files as content type <code>text/html</code>
and browsers are very tolerant of what HTML files they accept.

<b>To fix,</b> you need to make sure that your JSON content can never
be interpreted as HTML. Even though literal <code><</code>
and <code>></code> are allowed in Javascript strings, you need to
make sure they don't appear literally where a browser can misinterpret
them. Thus, you'd need to modify <code>{{...:js}}</code> to replace
them with the Javascript escapes <code>\x3c</code>
and <code>\x3e</code>.  It is always safe to
write <code>'\x3c\x3e'</code> in Javscript strings instead
of <code>'<>'</code>.  (And, as noted above, using the HTML
escapes <code>&lt;</code> and <code>&gt;</code> is incorrect.)
<br />

You should also always set the content type of your responses,
in this case serving JSON results
as <code>application/javascript.</code> This alone doesn't solve the
problem because browsers don't always respect the content type:
browsers sometimes do "sniffing" to try to "fix" results from servers
that don't provide the correct content type.
<br />

<b>But wait, there's more!</b> Gruyere doesn't set the content
encoding either. And some browsers try to guess what the encoding type
of a document is or an attacker may be able to embed content in a
document that defines the content type. So, for example, if an
attacker can trick the browser into thinking a document
is <code><a href="http://www.google.com/search?q=utf-7">UTF-7</a></code>
then it could embed a script tag as <code>+ADw-script+AD4-</code>
since <code>+ADw-</code> and <code>+AD4-</code> are alternate
encodings for <code><</code> and <code>></code>.  So always set
both the content type <i>and</i> the content encoding of your
responses, e.g., for HTML:<br />

<pre>Content-Type: text/html; charset=utf-8
</pre>
</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="2__more_about_xss"> </a> More about XSS </h3>
In addition to the XSS attacks described above, there are quite a few
more ways to attack Gruyere with XSS. Collect them all!
<br />

XSS is a difficult beast. On one hand, a fix to an XSS vulnerability
is usually trivial and involves applying the correct sanitizing
function to user input when it's displayed in a certain context. On
the other hand, if history is any indication, this is extremely
difficult to get right. <a href="http://www.kb.cert.org/vuls/" target="_top">US-CERT</a> reports dozens of publicly disclosed XSS
vulnerabilities involving multiple companies.
<br />

Though there is no magic defense to getting rid of XSS
vulnerabilities, here are some steps you should take to prevent these
types of bugs from popping up in your products:
<br />

<ol>
<li> First, make sure
you <a href="http://www.google.com/search?q=understanding+cross-site+scripting" target="_top">understand the problem</a>.
</li>
<li> Wherever possible, do sanitizing via templates features instead
of calling escaping functions in source code. This way, all of your
escaping is done in one place and your product can benefit from
security technologies designed for template systems that verify their
correctness or actually do the escaping for you. Also, familiarize
yourself with the other security features of your template system.
</li>
<li> Employ good testing practices with respect to XSS.
</li>
<li> Don't write your own template library :) </li>
</ol>
</div>

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) Cross-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or Javas...