pmwiki at solidgone.com
Wed Jun 25 19:39:59 CDT 2008
The way I read this is that you'd need to have authform active, and
allow people login access, or access to the login form -- which your
test site doesn't appear to do. From there, we can apparently call the
login routine and append bogus php command:
which will get executed. This page has a info on a similar issue for WP
http://www.matasano.com/log/1019/funny/. Not exactly the same, but
should be enough to get started.
In terms of XSS, what could be done is rather than simply executing php
as above you could force an execution of any remotely hosted cgi script
on the pmwiki server. Refer:
If you're disputing the 'serious' rating, then I'd probably agree with you.
For a few more similar, but not the same, exploits:
~ ~ Dave
Petko Yotov wrote:
> On Wednesday 25 June 2008 16:12:35 Greg T. Grimes wrote:
>> I am fairly new to PmWiki development and bug tracking. Can someone
>> explain the process of getting this bug fixed? I see someone "voted" a 5
>> for it, does this mean the person agrees? Again, I'm new and just
>> wondering. Thank you.
> I am copying my question to the list:
> How could possibly the current $_SERVER['REQUEST_URI'] variable be a serious
> cross-site scripting vulnerability for anyone else than the browser which is
> calling the login form with an invalid url (non-stripped tags...)? What
> exactly client-side code could be executed?
> Feel free to demonstrate the vulnerability on my wiki which is located at
> http://galleries.accent.bg/Cookbook .
> Thanks a lot.
> pmwiki-devel mailing list
> pmwiki-devel at pmichaud.com
More information about the pmwiki-devel