CERT -- Malicious HTML Tags
CERT has released a fairly dire advisory on the dangers of dynamic page generation when coupled with untrusted content submission: http://www.cert.org/advisories/CA-2000-02.html Anyone care to comment on Zope's vunlerability here? For instance, the ZGotW site allows submissions in structured text, plain text, and HTML -- but now I am probably going to htmlquote() the last, which kills a lot of the point of it, no? The key issue lies in embedding <SCRIPT>...</SCRIPT> chunks (or their immoral equivalents, <OBJECT>, <EMBED>, and <APPLET>). Consider, for instance, those nasty pop-up windows launched by some "free" webspace providers; then consider what happens in Squishdot, ZGotW, or any other site which permits users to enter arbitrary HTML as part of the feedback/collaboration process. Not a pretty scene! Tres. -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com
On 2/2/00 5:56 PM, Tres Seaver at tseaver@palladion.com wrote:
Anyone care to comment on Zope's vunlerability here? For instance, the ZGotW site allows submissions in structured text, plain text, and HTML -- but now I am probably going to htmlquote() the last, which kills a lot of the point of it, no?
From my reading, the reality is that it's not a vulnerability in any specific server, but a design flaw in applications built on them. Having said that, it is perhaps desirable for Zope to provide a "cleansing" mechanism that removes tags not allowed (i.e. you give it a list of disallowed, or allowed tags, and it does th "right thing").
So having said that, there's really nothing Zope can do that is not application specific, besides providing some "validation" code that can be called as appropriate. Hopefully people understand this is a design flaw in applications. Evan mentioned XML-based, but I think that's a bit heavy, unless it's sgmlop based, perhaps? Other ideas? I like the idea of a minimal set of tags (A, B, I, EM, BR, P, UL, OL, LI perhaps?) that are allowed, all else is verbotten... any other scheme is a "bad thing" :-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
----- Original Message ----- From: Christopher Petrilli <petrilli@digicool.com>
Evan mentioned XML-based, but I think that's a bit heavy, unless it's sgmlop based, perhaps? Other ideas? I like the idea of a minimal set of tags (A, B, I, EM, BR, P, UL, OL, LI perhaps?) that are allowed, all else is verbotten... any other scheme is a "bad thing" :-)
Having now read the advisory and the slashdot discussion which followed, I now see that you have to be a little more draconian than this, even. You need to make sure that those tags are *really* bare (no onAnything="javascript:argh") and take special care with anchor hrefs. Whether sgml or xml-based, parsing shouldn't be too much of a burden unless you get a *lot* of content submitted. You only need to do it once per submission, after all, and only if it contains '<>&'s. Happily, the default Zope error page doesn't seem to have the 404 exploit exposed on slashdot. Cheers, Evan @ 4-am
On 2/3/00 2:05 AM, Evan Simpson at evan@4-am.com wrote:
----- Original Message ----- From: Christopher Petrilli <petrilli@digicool.com>
Evan mentioned XML-based, but I think that's a bit heavy, unless it's sgmlop based, perhaps? Other ideas? I like the idea of a minimal set of tags (A, B, I, EM, BR, P, UL, OL, LI perhaps?) that are allowed, all else is verbotten... any other scheme is a "bad thing" :-)
Having now read the advisory and the slashdot discussion which followed, I now see that you have to be a little more draconian than this, even. You need to make sure that those tags are *really* bare (no onAnything="javascript:argh") and take special care with anchor hrefs.
Sadly, I thought of this after sending the post, but didn't feel like getting but back side out of bed to send an extension ;-) I don't think that it's too difficult a problem, *IF* you approach it as "that which is not explicitly allowed is forbidden," which all good security models should use.
Whether sgml or xml-based, parsing shouldn't be too much of a burden unless you get a *lot* of content submitted. You only need to do it once per submission, after all, and only if it contains '<>&'s.
I believe I read that you also need to do an entity-reference expansion because of brain damage in some browsers. Did I misread this?
Happily, the default Zope error page doesn't seem to have the 404 exploit exposed on slashdot.
It's that time-machine thing :-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
On Wed, Feb 02, 2000 at 04:56:07PM -0600, Tres Seaver wrote: |The key issue lies in embedding <SCRIPT>...</SCRIPT> chunks (or their immoral |equivalents, <OBJECT>, <EMBED>, and <APPLET>). Consider, for instance, those |nasty pop-up windows launched by some "free" webspace providers; then consider |what happens in Squishdot, ZGotW, or any other site which permits users to enter |arbitrary HTML as part of the feedback/collaboration process. Not a pretty |scene! Hmmm... I wonder if a global replace of all <script .*> with <script .*> before a commit might work in the short term? Or just whack everything between script tags (and optionally alert a human via email or log). My sites have only allowed <b> and <i> tags in text and textarea for the longest time and strip everything else out. I've accidentally protected myself for once! Hoo hoo! Cheers, Jules
In article <3898B607.D7AB34C1@palladion.com>, Tres Seaver <tseaver@palladion.com> writes
The key issue lies in embedding <SCRIPT>...</SCRIPT> chunks (or their immoral equivalents, <OBJECT>, <EMBED>, and <APPLET>). Consider, for instance, those nasty pop-up windows launched by some "free" webspace providers; then consider what happens in Squishdot, ZGotW, or any other site which permits users to enter arbitrary HTML as part of the feedback/collaboration process. Not a pretty
Squishdot says this at the bottom of it's post article page: Allowed HTML <B> <I> <P> <A> <LI> <OL> <UL> <EM> <BR> <TT> <HR> <STRONG> <BLOCKQUOTE> <DIV .*> <DIV> <P .*> I must check on what Zwiki does ... ------- Regards, Graham Chiu gchiu<at>compkarori.co.nz http://www.compkarori.com/dynamo - The Homebuilt Dynamo http://www.compkarori.com/dbase - The dBase bulletin
I know this is somewhere (and trust me I have looked for a good couple of hours).. but what is the proper syntax for setting a cookie not to expire (for a few years anyway) that is good across multiple browsers? I got here: <dtml-call "RESPONSE.setCookie('name', 'value')"> JMA
On Thu, 3 Feb 2000 Jatwood@bwanazulia.com wrote:
I know this is somewhere (and trust me I have looked for a good couple of hours).. but what is the proper syntax for setting a cookie not to expire (for a few years anyway) that is good across multiple browsers?
<dtml-call "RESPONSE.setCookie('name', 'value', expire='Wed, 19 Feb 2020 14:28:00 GMT')"> Oleg. ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
Squishdot says this at the bottom of it's post article page:
Allowed HTML <B> <I> <P> <A> <LI> <OL> <UL> <EM> <BR> <TT> <HR> <STRONG> <BLOCKQUOTE> <DIV .*> <DIV> <P .*>
It says that, presumably because it looks exactly like the equivalent Slashdot form, but it doesn't seem to do anything meaningful to filter tags. I've successfully posted tables, etc. to a Squishdot 0.3.2 forum without problems. Julian.
participants (8)
-
Christopher Petrilli -
Evan Simpson -
Graham Chiu -
Jatwoodï¼ bwanazulia.com -
Jules -
Julian Melville -
Oleg Broytmann -
Tres Seaver