<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3132" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2>For arrayvalidator issue, I think it is easy to
solve.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2>We can extended arrayvalidator class to add
"element rules".</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2>Let those elements rules to validate each element of the
passing array. The psudo code may looks like</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2>$arrayValidator = new ArrayValidator();</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2>$arrayValidator->addElementRule( new IntRule()
);</FONT></SPAN></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2><SPAN
class=538554404-17072007></SPAN></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2><SPAN class=538554404-17072007>$validateOk = <SPAN
class=538554404-17072007><FONT face=新細明體 color=#0000ff
size=2>$arrayValidator->validate( $ourArray
);</FONT></SPAN></SPAN></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=538554404-17072007><FONT face=新細明體
color=#0000ff size=2>Mark</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=zh-tw dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> plog-svn-bounces@devel.lifetype.net
[mailto:plog-svn-bounces@devel.lifetype.net] <B>On Behalf Of </B>Matt
Wood<BR><B>Sent:</B> Tuesday, July 17, 2007 11:14 AM<BR><B>To:</B>
plog-svn@devel.lifetype.net<BR><B>Subject:</B> Re: [pLog-svn] [Lifetype]
Multiple SQL Injections in Admin PostsList interfaces & a XSS
vuln<BR></FONT><BR></DIV>
<DIV></DIV>Firstly,<BR><BR>I would like to thank Oscar and the other devs for
putting lots of hard work into the development of this project. By posting this
information I am not trying to deride or attack Lifetype/pLog at all, I use this
software plenty, and have been around for a while. So guys don't take this the
wrong way... I'm just trying to use my expertise to contribute and point out
what I see; hopefully making this a better software platform. <BR><BR>And part
II commences...<BR><BR>Any (admin especially) action that relies solely on the
ArrayValidator does not actually have any validation occur. Assuming that if the
data passed in parses into an array is not sufficient, it is just as easily to
attack with an array of values. <BR><BR>With this you can arbitrarily insert sql
into something when deleting post IDs [for example]. This can lead to the
destruction of tables since at least mysql allows multiple delete commands. If
the user has delete permission on anything in the database, he/she can
effectively delete anything at all. <BR><BR>Again this only matters if you have
untrusted users.<BR><BR>-Matt<BR><BR>
<DIV><SPAN class=gmail_quote>On 7/16/07, <B class=gmail_sendername>Matt Wood</B>
<<A href="mailto:matt@woodzy.com">matt@woodzy.com</A> > wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">I
was playing with the new ajax "build" earlier today and the new pretty YUI
components and found a couple problems with stuff unrelated & related to
the ajax stuff [which I noticed that most inputs were verified by oscar :),
from those plog-svn change-sets]. <BR><BR>I've verified these attacks work but
truthfully the only important cases exist when you allow public registration
for a blog through the lifetype core (or have an untrusted user base), since
in order to exploit these vulnerabilities you must have a valid session.
<BR><BR>There are many parameters passed into AdminPostsListView from
AdminEditPostsAction.class.php which are not validated and lead to SQL
injection attacks (recovering the admin's md5 password hash for
example).<BR><BR>in the performAjax() and perform()
methods<BR>---<BR>lifetype-1.3-ajax/class/action/admin/admineditpostsaction.class.php:
<BR>
"showMonth" => $this->_request->getValue( "showMonth" ),
<BR>---<BR>which is passed into the following, again
unverified...<BR>---<BR>lifetype-1.3-ajax/class/view/admin/adminpostslistview.class.php:
$thi<BR>s->_showMonth = $this->_getParameter( $params, "showMonth",
$this->_locale->form <BR>atDate( new Timestamp(), "%Y%m"
));<BR>---<BR>This leads to sql injection on almost all of the variables
here... You can easily verify this by checking the mysql logs and by looking
at the query string before its sent to the database. Since this injection is
in the WHERE clause where many bad things can occur. The most pervasive of
which are blindsql attacks on the password hashes. <BR><BR><BR>These
parameters are also echo'ed onto the web page unfiltered...
<BR>---<BR>lifetype-1.3-ajax/class/view/admin/adminpostslistview.class.php:
<BR> $pager = new Pager(
"?op=editPosts&amp;showMonth={$this->_showMonth}&amp
<BR>;showStatus={$this->_showStatus}&amp;showCategory={$this->_showCategory}&amp;sho<BR>wUser={$this->_showUser}&amp;searchTerms={$this->_searchTerms}&amp;showLocation=<BR>{$this->_locationId}&amp;page="
<BR>---<BR>leading to XSS with some clever parameters that require the pager
to actually display links.<BR><BR><BR>On the severity...<BR>The xss vuln not
really that important... but even with a semi-trusted userbase the sql
injections could lead to the admin having his password discovered. <BR><SPAN
class=sg><BR><BR>-Matt<BR></SPAN></BLOCKQUOTE></DIV><BR></BODY></HTML>