Opened 9 years ago

Closed 9 years ago

Last modified 9 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: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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


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

Attachments (2)

5880.diff (2.5 KB) - added by gwilson 9 years ago.
5880.2.diff (2.5 KB) - added by gwilson 9 years ago.
removed print statement from last patch

Download all attachments as: .zip

Change History (11)

Changed 9 years ago by gwilson

Changed 9 years ago by gwilson

removed print statement from last patch

comment:1 Changed 9 years ago by gwilson

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.


comment:2 Changed 9 years ago by gwilson

  • Has patch set
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 9 years ago by mtredinnick

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 Changed 9 years ago by 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?


comment:5 Changed 9 years ago by 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.

comment:6 Changed 9 years ago by gwilson

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [6691].

comment:7 Changed 9 years ago by 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.


comment:8 Changed 9 years ago by 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


comment:9 Changed 9 years ago by mtredinnick

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