Plans Cross Site Scripting (XSS) vulnerabilities

NoseyNick · Guest

Plans has a number of XSS security holes.
I have put together a proof-of-concept on my site
Lloyd told me I should post on the forums to get folks thinking about security concerns.

Discuss Smile

NoseyNick

daltonlp · Site Admin Joined: 24 Nov 2003 Posts: 1499

To sum up:

- Only the demo site on planscalendar.com is vulnerable to the exploit described above. Not user sites.

(Unless those user sites have the "choose_themes" option turned on. But this will be rare, because this option is not present (not just turned off, but missing entirely) from the default install.)

However, there well be other types of vulnerabilities. I can think of one right now - when you create an event, you can put html in the details. If you had an untrustworthy plans user, they could craft an event which would steal viewer's cookies.

- Lloyd

NoseyNick · Guest

daltonlp · Site Admin Joined: 24 Nov 2003 Posts: 1499

Discussing here is ok. XSS vulnerabilities are a level or two below holes that let an attacker direct access to the hosting server, but I'd prefer to have even that class of security hole discussed in public.

This vulnerability involves passing a malformed value for the display_type argument, like so:

http://www.planscalendar.com/demo/plans.cgi?display_type="><script>document.write('NASTYCODE')</script><A NAME="

Other arguments besides display_type are probably also susceptible to this vulnerability.

- Lloyd

NoseyNick · Guest

Cool. I know some people would rather have a bit of time to release fixes for these problems BEFORE the public know too many details.

I notice the forum is kinda confused about that URL too Smile

In case any other coders are reading, I'll repeat in this forum what I just sent to you by email...

Basically having got $q->param('display_type') you should almost never be using it directly, always pattern-matching and using that. In this case, it's supposed to be a numeric arg I believe, so maybe something like:

$q->param('display_type') =~ /^(\d+)$/
or die "stop trying to hack plans";
$display_type = $1;

Might even be worth writing a wrapper around $q->param() which can be given a pattern of acceptable input:

sub get_me_a_param {
my ($name, $pat) = @_;

$q->param($name) =~ /^($pat)$/
or return "";
return $1;
}

... and then avoid the temptation to get_me_a_param("name", ".*") unless you REALLY know what you're doing. You're POSSIBLY safe to get_me_a_param("name", "[^<>]*") but I'm not even 100% sure about that.

Oh, and thanks again, I DO really like plans, and hope I haven't upset the applecart too much discovering these security issues Smile

daltonlp · Site Admin Joined: 24 Nov 2003 Posts: 1499

I had fixes for these XSS holes in the development version of Plans, but a more serious security hole was discovered by Gary Lewis. Plans 6.7.1 includes the XSS fixes and a fix for the mySQL password hole.

Please upgrade ASAP. Please review if possible.

- Lloyd

daltonlp · Site Admin Joined: 24 Nov 2003 Posts: 1499

Actually, just to be clear - 6.7.1 doesn't fix the XSS hole in the demo site, just other holes that applied to all installations.

- Lloyd

NoseyNick · Joined: 29 Apr 2005 Posts: 18 Location: Surrey, UK

NoseyNick · Joined: 29 Apr 2005 Posts: 18 Location: Surrey, UK

http://planscalendar.com/demo/plans.cgi?active_tab=1&add_edit_event=edit&&evt_id=133%22%3E%3Cscript%3Edocument.write(%22NASTYCODE%22)%3C/script%3E%3Cinput%20type=%22hidden%22%20name=dummy%20value=%22

Need the ^ and $ in event_id checks.

daltonlp · Site Admin Joined: 24 Nov 2003 Posts: 1499

Hoo boy, what a rookie mistake. Very Happy

Version 6.7.2 fixes this. At this rate, I'm going to run out of version numbers...

- Lloyd

NoseyNick · Joined: 29 Apr 2005 Posts: 18 Location: Surrey, UK