Chapter 11 ■ the World Wide Web203Persistent Cross-Site Scripting
Without the ability to set the flash message through a long and ugly URL, the attacker will have to shift to injecting
their JavaScript through some other mechanism. Scanning the main page, their eyes might fall on the Memo field of
the displayed payments. What characters can they type into the memo?
Getting a memo to appear on your page is, of course, a more difficult business than providing it in a URL that they
can give you anonymously. The attacker is going to have to register with the site using fake credentials or compromise
the account of another user in order to send you a payment whose Memo field includes the
Now press the submit button. Then log out, log back in as brandon, and start hitting Reload. Every time the
brandon user visits the front page, yet another payment will be made from his account!
This persistent version of a cross-site scripting attack is, as you can see, quite powerful. Whereas the link created
earlier worked only when the user clicked it, the persistent version—where the JavaScript now appears invisibly
and runs every time they visit the site—will happen over and over again until the data on the server is cleaned or
deleted. When XSS attacks have been launched through public form messages on vulnerable sites, they have affected
hundreds and thousands of users until finally being repaired.
The reason that Listing 11-2 is vulnerable to this problem is that its author has used Jinja2 templates without
really understanding them. Their documentation makes it clear that they do no escaping automatically. Only if you
know to turn on its escaping will Jinja2 protect characters like < and > that are special in HTML.
Listing 11-8 will protect against all XSS attacks by calling Jinja2 through the Flask render_template() function,
which will turn on HTML escaping automatically when it sees that the template filenames end with the extension
html. By relying on a common pattern of the web framework instead of doing things yourself, you can be opted in to
patterns that can protect you from incautious design decisions.
Cross-Site Request Forgery
With all content now being properly escaped on your site, XSS attacks should no longer be an issue. But the attacker
has one more trick up their sleeve: attempting to submit the form from a completely different site because they really
have no reason to launch the form from your site. They can predict ahead of time what all of the field values need to
be, so they are free to launch a request to /pay from any other web page you might visit.
All they have to do is invite you to visit a page where they have hidden the JavaScript or embed it in a comment if
they find a forum thread in which you are involved on a site that does not properly escape or remove script tags from
forum comments.
You might think that the attacker will need to build a form that is ready to send them money and then make its
button a tempting target for your mouse.