#5880 closed (fixed)
Cross-site(?) scripting when adding text via the "foreign key" popup window
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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.
Attachments (2)
Change History (11)
by , 17 years ago
by , 17 years ago
Attachment: | 5880.2.diff added |
---|
comment:1 by , 17 years ago
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?
comment:2 by , 17 years ago
Has patch: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 17 years ago
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.
comment:4 by , 17 years ago
I think the "&" should be transformed _after_ all the others in the html_unescape function.
"&quot;" should result in """, 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
comment:5 by , 17 years ago
comment:7 by , 17 years ago
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
comment:8 by , 17 years ago
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
comment:9 by , 17 years ago
Please open new tickets for new issues. One bug per ticket makes things much easier to track.
removed print statement from last patch