Vulnerabilities Found in WordPress Blogging Tool

ZuperDee writes "According to this Netcraft article, 'Security vulnerabilities have been found in WordPress, the popular PHP-based open source blogging application. Some scripts in WordPress are not properly validated, leaving the program open to cross-site scripting (XSS) attacks in which third parties could insert content into a WordPress-driven site.'"

Comments

all output should be HTML-escaped by default

[Anonymous Coward]

Ahhh, a good opportunity for my little rant:

Not HTML-escaping all template output is a serious problem in almost every template system out there. "raw" output should only be used explicitly, when needed.

Programmers don't seem interested in this issue. The point to some HTML-escaping function and say "use it". That's not a solution! I have reported this as a bug in several toolkits and have been ignored. Now I don't bother reporting the bug, I develop and maintain my own set of patches.

Let's be clear: not HTML-escaping all template output by default is a bug and should be reported as such.

The following systems that I've used all have this bug:

• PHP
• Smarty (the last version I used had an *option* to escape everything, but it *did nothing* because no code checked the flag)
• HTML::Template
• ERb
• eruby
• Template Toolkit

Some of these offer functions that escape output. If a designer or developer is presented two methods of output which produce identical results 99% of the time, guess which he will eventually use all the time?

• method 1: <%= $var %>
• method 2: <%= htmlentities($var) %>

Method 1 (insecure) will be used.

It only takes one forgotten escape to create an avenue for XSS.

Not only is it possible to do XSS attacks, it's sloppy UI. A customer or user should not have to know that certain characters are "magic". They should be able to type, for instance, "<grin>" without having it disappear. Ever try to post HTML examples on a programming blog and wonder if your text will be eaten?

Another reason to escape by default: if you escape when you shouldn't (for instance in HTML output), you will see the problem immediately (because you'll see HTML code all over the place). If you forget to escape when you should (for instance when you view a customer's name in your app), you won't know until you read about it on Bugtraq.

So I call on all template system authors reading this: take a stand and do the right thing and HTML-escape all template output by default.

For ASP-like kits, I propose the following syntax:

• <% %> - execute code
• <%# %> - comment
• <%= %> - output HTML-escaped
• <%! %> - output raw
• <%% %> - output a <% %> (handy for code generators)

For systems that can be used outside of HTML for general template use, allow a user-defined filter function for the <%= %> construct, and in all your examples, be sure to remind them that for HTML use, that filter function should do HTML entity escaping.

For backwards compatibility, entrenched systems like PHP could offer a flag to turn the feature on and off, much like PHP offers flags to turn off many of the design errors of early PHP.

As a reminder, these are the entities that should be used. No other substitutions are needed.

• < - &lt;
• > - &gt;
• " - &quot;
• ' - &apos;

Thanks for reading.

-Anon.

Re:all output should be HTML-escaped by default

[Anonymous Coward]

As a reminder, these are the entities that should be used. No other substitutions are needed.

• < - &lt;
• > - &gt;
• " - &quot;
• ' - &apos;

You forgot "& - &amp;".

(Even though you probably had to type it four times to get that list - !)

I don't get it

[Profane MuthaFucka]

So, Microsoft doesn't make this software? I don't get it then.

Stupid design. That's what it is.

[Spy der Mann]

As a web developer, I _ALWAYS_ escape my output, and _ALWAYS_ preprocess my input.

No input ever goes unfiltered either way. Anyone with some experience on multi-tier programming should know this.

Now the problem with content-management systems is, we need a _GOOD_ wysiwyg editor with filtering capabilities.

i.e. make the thing output XML. Then use your favorite XSLT stylesheet to filter it.

Oh well...

Re:Stupid design. That's what it is.

[SecretAgentDog]

Well, what do you expect from a 19 year old?

Re:Stupid design. That's what it is.

[Anonymous Coward]

As a web developer, I _ALWAYS_ escape my output, and _ALWAYS_ preprocess my input.

As a C developer I _ALWAYS_ check my array indexes, and _ALWAYS_ allocate buffers of the right length.

Except, not every developer is as smart as you or I. Plus I get tired of typing that escape function, yah know?

After every freakin' PHP app on the planet has an XSS attack, then maybe people will figure this out.

i.e. make the thing output XML. Then use your favorite XSLT stylesheet to filter it.

Oh yeah, that makes a lot of sense for a 1-page PHP script.

Programmer ego shouldn't get in the way of solving an obvious problem.

Uh... This is News?

[angst_ridden_hipster]

If you read Bugtraq and/or Websec, you'll see a dozen of this kind of vulnerability each week.

There's still a lot of XSS bugs in a lot of products. And new ones get added all the time.

Just be careful out there, kids. Don't trust input. Barely trust output.

Re:Uh... This is News? Totally...

[Anonymous Coward]

That's funny -- I reported an three injection vulnerabilities to bugtraq on this product a few months ago and it didn't get slashdotted. It took ten seconds to find them (I put a semicolon at the end of the url and got an error back) and about half an hour to craft a url to expose private posts (granted, I could have done much worse).

--Seth Woolley

They should have used C

[Anonymous Coward]

They should have used a secure language like C rather than one of those fancy scripting languages which are always full of vulnerabilities.

can mod_security help?

[scaturan]

i'm using mod_security, but not sure if it'll prevent or slow down XSS attacks. can anyone advice me on this? or do i have to wait for WP developers for a patch.