Re: CERT -- Malicious HTML Tags
tres seaver <tseave-@palladion.com> wrote:
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
Yes, I've been reading up on it as well. I'll be studying this issue as well WRT to Squishdot. I would probably need to add some validation to Squishdot to filter out these *malicious tags* -- if anyone in the Zope/Squishdot has ideas/code to fix this, please contact me ASAP. I've checked Squishdot so that all input fields are html-quoted, but the most vulnerable part seems to be the possible addition of javascript and other executable code -- If I build a validation mechanism that filters out <SCRIPT, <OBJECT, <APPLET and <EMBED html tags, would this solve the problem -- or is this only a partial solution? What other things would I need to filter out? I don't know about the Zope's cookie mechanism -- since we get the Cookie already as part of the namespace -- is this vulnerable too? Regards, Butch ===== Butch Landingin Squishdot maintainer http://squishdot.org squishdot@yahoo.com __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
----- Original Message ----- From: Squishdot <squishdot@yahoo.com>
tres seaver <tseave-@palladion.com> wrote:
The key issue lies in embedding <SCRIPT>...</SCRIPT> chunks (or their immoral equivalents, <OBJECT>, <EMBED>, and <APPLET>).
Yes, I've been reading up on it as well. I'll be studying this issue as well WRT to Squishdot. I would probably need to add some validation to Squishdot to filter out these *malicious tags* -- if anyone in the Zope/Squishdot has ideas/code to fix this, please contact me ASAP.
Slashdot.org has had to deal with this issue for quite some time, and is high-profile enough to attract many *cough* security testers *cough*. They forbid anything not on a short list of harmless tags. IMNSHO this is a far better approach than trying to keep a list of dangerous tags, since it is conservative; If you miss one, or a new tag is added to the HTML standard and turns out to be a security risk, you aren't vulnerable by default. Consider also that if you are running a squishdot or similar contributed-content site you probably want to "defend" against invalid HTML. An unclosed <b> or <table> can ruin a page, or even render it invisible on some browsers. What would an embedded </body> do to a discussion? Unless you want to live with *really* minimal markup, the best approach is probably to run contributed text through a full parser. Since xmllib comes with Python, it's a candidate, although I'm not sure if it would force you to require XHTML (stuff like <img src=... />). I may take a swipe at this. Cheers, Evan @ 4-am
----- Original Message ----- From: Squishdot <squishdot@yahoo.com>
tres seaver <tseave-@palladion.com> wrote:
The key issue lies in embedding <SCRIPT>...</SCRIPT> chunks (or their immoral equivalents, <OBJECT>, <EMBED>, and <APPLET>).
Yes, I've been reading up on it as well. I'll be studying this issue as well WRT to Squishdot. I would probably need to add some validation to Squishdot to filter out these *malicious tags* -- if anyone in the Zope/Squishdot has ideas/code to fix this, please contact me ASAP.
Slashdot.org has had to deal with this issue for quite some time, and is high-profile enough to attract many *cough* security testers *cough*. They forbid anything not on a short list of harmless tags. IMNSHO this is a far better approach than trying to keep a list of dangerous tags, since it is conservative; If you miss one, or a new tag is added to the HTML standard and turns out to be a security risk, you aren't vulnerable by default. Consider also that if you are running a squishdot or similar contributed-content site you probably want to "defend" against invalid HTML. An unclosed <b> or <table> can ruin a page, or even render it invisible on some browsers. What would an embedded </body> do to a discussion? Unless you want to live with *really* minimal markup, the best approach is probably to run contributed text through a full parser. Since xmllib comes with Python, it's a candidate, although I'm not sure if it would force you to require XHTML (stuff like <img src=... />). I may take a swipe at this. Cheers, Evan @ 4-am
Evan Simpson wrote:
----- Original Message ----- From: Squishdot <squishdot@yahoo.com>
tres seaver <tseave-@palladion.com> wrote:
The key issue lies in embedding <SCRIPT>...</SCRIPT> chunks (or their immoral equivalents, <OBJECT>, <EMBED>, and <APPLET>).
Yes, I've been reading up on it as well. I'll be studying this issue as well WRT to Squishdot. I would probably need to add some validation to Squishdot to filter out these *malicious tags* -- if anyone in the Zope/Squishdot has ideas/code to fix this, please contact me ASAP.
Slashdot.org has had to deal with this issue for quite some time, and is high-profile enough to attract many *cough* security testers *cough*. They forbid anything not on a short list of harmless tags.
Hoever, as demonstrated in the thread on Slashdot, if you don't convert '%nn' style characters to their actual values, malicious code can get through. Cheers... Bruce -- Bruce Elrick, Ph.D. Saltus Technology Consulting Group Personal: belrick@home.com IBM Certified Specialist Business: belrick@saltus.ab.ca ADSM, AIX Support, RS/6000 SP, HACMP
participants (3)
-
Bruce Elrick -
Evan Simpson -
Squishdot