| 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 | 11/18/09 (6056 days ago) |
| Due | |
| Updated | 5/4/10 (5889 days ago) |
| Assigned | 4/21/10 (5902 days ago) |
| Resolved | 5/4/10 (5889 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | 4.3.6 |
| Patch | No |
State ⇒ Resolved
Git commit:
http://lists.horde.org/archives/commits/2010-May/003766.html
FW_3 CVS commit:
http://cvs.horde.org/diff.php/framework/Text_Filter/Filter/Attic/xss.php?sa=1&r1=1.1.2.19&r2=1.1.2.20
State ⇒ Assigned
New Attachment: xss_8715_v2.diff
Attached a patch in case the link has two hrefs with data URLs
patch it's working, at least for me.
New Attachment: xss_8715.diff
Attached a patch in case the link has two hrefs with data URLs
Bug: 8715Fix XSS vulnerability.
http://cvs.horde.org/diff.php/framework/Text_Filter/Filter/Attic/xss.php?rt=horde&r1=1.1.2.18&r2=1.1.2.19&ty=u
http://cvs.horde.org/diff.php/horde/docs/CHANGES?rt=horde&r1=1.515.2.583&r2=1.515.2.584&ty=u
Bug: 8715changelog
http://cvs.horde.org/diff.php/horde/docs/CHANGES?rt=horde&r1=1.1288&r2=1.1289&ty=u
Bug #8715: Fix XSS vulnerability.create mode 100644
framework/Text_Filter/test/Horde/Text/Filter/fixtures/xss96.html
http://git.horde.org/diff.php/framework/Text_Filter/lib/Horde/Text/Filter/Xss.php?rt=horde-git&r1=b985abda1822ab9fde68d9e4dc7dcd16b6d6ebbc&r2=14d802ae6bf6ae4e7d8721deeb3fd7ffab66a97a
http://git.horde.org/diff.php/framework/Text_Filter/package.xml?rt=horde-git&r1=f40aebaffdde11d95282b77c9ca7018cffcb61dd&r2=14d802ae6bf6ae4e7d8721deeb3fd7ffab66a97a
http://git.horde.org/co.php/framework/Text_Filter/test/Horde/Text/Filter/fixtures/xss96.html?rt=horde-git&r=14d802ae6bf6ae4e7d8721deeb3fd7ffab66a97a
http://git.horde.org/diff.php/framework/Text_Filter/test/Horde/Text/Filter/xss.phpt?rt=horde-git&r1=8459795203b644a096720099c4f22d4cdc39dc49&r2=14d802ae6bf6ae4e7d8721deeb3fd7ffab66a97a
comment that blacklisting can be dangerous.
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.
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>
<!--a75c305b1c0a6022--><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.
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".
New Attachment: 0001-Add-test.patch
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".
New Attachment: 0002-Bug-8715-Fix-XSS-vulnerability[1].patch
State ⇒ Feedback
New Attachment: 0002-Bug-8715-Fix-XSS-vulnerability.patch
New Attachment: Message Source.eml
Assigned to
State ⇒ Assigned
Milestone ⇒ 4.3.6
Priority ⇒ 3. High
Type ⇒ Bug
Summary ⇒ XSS vulnerability
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed