Cross-site(?) scripting when adding text via the "foreign key" popup window

[roland.illig@…]

When I entered the following text into a text field, a JavaScript message box popped up:

</script><script>alert('foo');</script>

You need to encode the "</script>" to prevent this from happening.

[Gary Wilson]

removed print statement from last patch

[Gary Wilson]

Description of patch:

Escaped strings passed to the response that closes the popup window to prevent XSS.
Added quotes around the second argument passed to `opener.dismissAddAnotherPopup` to make the function also work when a text field is used as the primary key.
Unescape the strings passed in to the `dismissAddAnotherPopup` javascript function so that the new option displays correctly in the dropdown box.

Thoughts?

[Malcolm Tredinnick]

By the way, if you think you've found a security hole, how about behaving responsibly and instead of posting it in the public Trac, using the documented security reported path (see contributing.txt)? That would help everybody, including yourself. Thanks.

[roland.illig@…]

I think the "&amp;" should be transformed _after_ all the others in the html_unescape function.

"&amp;quot;" should result in "&quot;", not "\"".

Besides that, it's fine. Sorry that I posted it to the public trac. Could you perhaps add a sentence about security things to the "Read this first" section on the ticket page, so that this is more unlikely to happen again?

Roland

[jdetaeye@…]

The admin ui has more situations where special characters aren't escaped properly.
See ticket #5490 for a similar issue.

An earlier ticket #5041 was put as "won't fix" since all admin development acticities should focus on the new-admin branch.

[Gary Wilson]

Fixed in [6691].

[roland.illig@…]

Thank you for fixing this issue so quickly and in depth.

I was a bit concerned since the "autoescape" tag reminded me of PHP's "magic_quotes", which only added confusion to the programmers. But after trying it out, I must say that you did a great job: My naïvely written template works exactly the same with or without the autoescape tag. No matter whether I escape the things manually or not. *bow-lowly-in-respect*

There are a few typos left:

• in templates.txt, replace "tempate" with "template"
• in templates_python.txt, replace "you filter" with "your filter"

Thank you for proving that autoescaping magic can be done in a reasonable way.

Roland

[roland.illig@…]

There's one curiosity: It seems that the autoescape mode is off by default. (This should be documented explicitly in templates.txt.)

When I trigger a TemplateSyntaxError exception (by providing an {% autoescape on %} tag but omitting the closing tag, in the error page, no escaping is done, producing lots of JavaScript boxes. This doesn't look intentional.

SVN revision 6692

Roland

[Malcolm Tredinnick]

Please open new tickets for new issues. One bug per ticket makes things much easier to track.