[#8715] XSS vulnerability
Summary XSS vulnerability
Queue IMP
Queue Version FRAMEWORK_3
Type Bug
State Resolved
Priority 3. High
Owners Horde Developers
Requester Michael Slusarz <slusarz (at) horde (dot) org>
Created 11/18/09 (120 days ago)
Due
Updated 11/30/09 (108 days ago)
Assigned 11/24/09 (114 days ago)
Resolved 11/30/09 (108 days ago)
Attachments Message Source.eml Download
0002-Bug-8715-Fix-XSS-vulnerability[1].patch Download
0001-Add-test.patch Download
Milestone 4.3.6
Patch No

History
11/30/09 Michael Slusarz State ⇒ Resolved
 
11/25/09 CVS Commit Comment #12 Reply to this comment
11/25/09 CVS Commit Comment #11 Reply to this comment
11/25/09 CVS Commit Comment #10 Reply to this comment
11/25/09 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.
11/25/09 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".
11/24/09 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".
11/24/09 Michael Slusarz Comment #6 (Private)
New Attachment: 0002-Bug-8715-Fix-XSS-vulnerability[1].patch Download
[Hidden]
11/24/09 Michael Slusarz Deleted Attachment: 0002-Bug-8715-Fix-XSS-vulnerability.patch
 
11/24/09 Michael Slusarz Comment #5
New Attachment: 0002-Bug-8715-Fix-XSS-vulnerability.patch
State ⇒ Feedback
Reply to this comment
How about this?
11/18/09 Michael Slusarz Comment #4 (Private)
[Hidden]
11/18/09 Jan Schneider Comment #3 (Private)
[Hidden]
11/18/09 Jan Schneider Version ⇒ FRAMEWORK_3
 
11/18/09 Michael Slusarz Comment #2 (Private)
New Attachment: Message Source.eml Download
Milestone ⇒ 4.3.6
State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
[Hidden]
11/18/09 Michael Slusarz Comment #1
State ⇒ Unconfirmed
Patch ⇒
Milestone ⇒
Queue ⇒ IMP
Summary ⇒ XSS vulnerability
Type ⇒ Bug
Priority ⇒ 3. High
Reply to this comment
.