Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#5880 closed (fixed)

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

Reported by: roland.illig@… 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)

5880.diff (2.5 KB ) - added by Gary Wilson 17 years ago.
5880.2.diff (2.5 KB ) - added by Gary Wilson 17 years ago.
removed print statement from last patch

Download all attachments as: .zip

Change History (11)

by Gary Wilson, 17 years ago

Attachment: 5880.diff added

by Gary Wilson, 17 years ago

Attachment: 5880.2.diff added

removed print statement from last patch

comment:1 by Gary Wilson, 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 Gary Wilson, 17 years ago

Has patch: set
Triage Stage: UnreviewedAccepted

comment:3 by Malcolm Tredinnick, 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 roland.illig@…, 17 years ago

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

comment:5 by jdetaeye@…, 17 years ago

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.

comment:6 by Gary Wilson, 17 years ago

Resolution: fixed
Status: newclosed

Fixed in [6691].

comment:7 by roland.illig@…, 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 roland.illig@…, 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 Malcolm Tredinnick, 17 years ago

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

Note: See TracTickets for help on using tickets.
Back to Top