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:

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 9 years ago.
5880.2.diff (2.5 KB) - added by Gary Wilson 9 years ago.
removed print statement from last patch

Download all attachments as: .zip

Change History (11)

Changed 9 years ago by Gary Wilson

Attachment: 5880.diff added

Changed 9 years ago by Gary Wilson

Attachment: 5880.2.diff added

removed print statement from last patch

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

comment:2 Changed 9 years ago by Gary Wilson

Has patch: set
Triage Stage: UnreviewedAccepted

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

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?

Roland

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 Gary Wilson

Resolution: fixed
Status: newclosed

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.

Roland

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

Roland

comment:9 Changed 9 years ago by Malcolm Tredinnick

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