6.0.0-git
2019-11-18

[#8715] XSS vulnerability
Summary XSS vulnerability
Queue IMP
Queue Version FRAMEWORK_3
Type Bug
State Resolved
Priority 3. High
Owners Horde Developers (at) , slusarz (at) horde (dot) org
Requester slusarz (at) horde (dot) org
Created 2009-11-18 (3652 days ago)
Due
Updated 2010-05-04 (3485 days ago)
Assigned 2010-04-21 (3498 days ago)
Resolved 2010-05-04 (3485 days ago)
Milestone 4.3.6
Patch No

History
2010-04-21 01:20:18 Chuck Hagenbuch Assigned to Michael Slusarz
State ⇒ Assigned
 
2010-04-19 17:47:04 acmpires (at) co (dot) sapo (dot) pt Comment #14
New Attachment: xss_8715_v2.diff Download
Reply to this comment
Hi,

Attached a patch in case the link has two hrefs with data URLs
This patch is not working for all cases, but this new version of the 
patch it's working, at least for me.
2010-04-19 16:18:41 acmpires (at) co (dot) sapo (dot) pt Comment #13
New Attachment: xss_8715.diff Download
Reply to this comment
Hi,

Attached a patch in case the link has two hrefs with data URLs
2009-11-30 06:53:25 Michael Slusarz State ⇒ Resolved
 
2009-11-26 00:35:31 CVS Commit Comment #11 Reply to this comment
2009-11-26 00:24:07 Michael Slusarz Comment #9 Reply to this comment
I don't have a better suggestion for you, so I just leave the 
comment that blacklisting can be dangerous.
Of course attempting to blacklist HTML attributes/elements to fix all 
security issues is dangerous.  That is why we disable HTML inline 
viewing by default.  But a large portion of users want/need this 
inline display and are willing to view these parts even with the 
understanding that the filtering may not be 100% accurate.

That being said, thanks for your examples.  It is clear that we need 
to filter *any* data information contained in the href parameter.

I'm going to go ahead and add this to git and CVS FW_3.  Will leave 
this ticket open for a few days for additional feedback.
2009-11-25 13:20:45 david (dot) a (dot) julio (at) gmail (dot) com Comment #8 Reply to this comment
Don't forget about other content types. For example, if the data is 
the base64 encoding of:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
      PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <title>Test</title>
   </head>
   <body>
     <script type="text/javascript">alert(document.cookie)</script>
   </body>
</html>

Then, the attacker can also use a link with the following URI:

data:application/xhtml+xml;base64,<encoding of above>

And this is not the only one. If the use the content types text/xml or 
application/xml, the page will be parsed as a xml document. In the 
script, document has now type XMLDocument, and doesn't have the 
property cookie. We can still write something like:

<script type="text/javascript">
if (undefined === document.cookie)
   window.location.replace(window.location.href.replace("text/xml", 
"application/xhtml+xml"))
else
   alert(document.cookie)
</script>
The same for application/xml, or more elaborate code to take care of 
various cases.

I just tested this four cases, text/html, text/xml, application/xml, 
application/xhtml+xml and I don't know if there are others.

I don't have a better suggestion for you, so I just leave the comment 
that blacklisting can be dangerous.

Thank you for your time.
Attachments are not private anyway. :)

Your patch seems to do its job, attached is a test case.

I'm not sure how far Firefox can be tricked to consider a link as a 
data scheme. I'm thinking of variants of "data:text/html".
2009-11-24 23:39:37 Jan Schneider Comment #7
New Attachment: 0001-Add-test.patch Download
Reply to this comment
Attachments are not private anyway. :)

Your patch seems to do its job, attached is a test case.

I'm not sure how far Firefox can be tricked to consider a link as a 
data scheme. I'm thinking of variants of "data:text/html".
2009-11-24 05:18:16 Michael Slusarz Comment #6 (Private)
New Attachment: 0002-Bug-8715-Fix-XSS-vulnerability[1].patch Download
[Hidden]
2009-11-24 05:17:50 Michael Slusarz Deleted Original Message
 
2009-11-24 05:17:35 Michael Slusarz Comment #5
State ⇒ Feedback
New Attachment: 0002-Bug-8715-Fix-XSS-vulnerability.patch
Reply to this comment
How about this?
2009-11-18 19:10:10 Michael Slusarz Comment #4 (Private)
[Hidden]
2009-11-18 09:40:12 Jan Schneider Comment #3 (Private)
[Hidden]
2009-11-18 09:26:22 Jan Schneider Version ⇒ FRAMEWORK_3
 
2009-11-18 06:52:12 Michael Slusarz Comment #2 (Private)
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Milestone ⇒ 4.3.6
New Attachment: Message Source.eml Download
[Hidden]
2009-11-18 06:48:28 Michael Slusarz Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ XSS vulnerability
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
Reply to this comment
.

Saved Queries