Revision [1761]
This is an old revision of WikkaBugs made by JavaWoman on 2004-10-08 22:08:13.
Bugs/Issues discovered in Wikka!
Related pages:
- for resolved bugs/issues see: WikkaBugsResolved
- for issues related to Wikka layout refer to: WikkaCSS
Security bug in UserSettings (minor)
[Moved this back up again and edited since as of 1.1.5.3 it's only half fixed: only one of the assignments has been changed into a comparison operator. Sorry, I should have noticed before]The file actions/usersettings.php contains a function for a logged in user to change their password; looking at the code, the apparent intention is to verify the user's current password before accepting the new one:
Line 35:
<?php ...
else if (($user["password"] = md5($_POST["oldpass"])) || ($user["password"] == $_POST["oldpass"]))
?>
else if (($user["password"] = md5($_POST["oldpass"])) || ($user["password"] == $_POST["oldpass"]))
?>
Unfortunately, this test always succeeds since it does an assignment instead of a comparison - and since the boolean operator is OR (
) it doesn't matter if the second term is (now) a comparison: just the single assignment in the first term will make it always evaluate as TRUE. This presents a security risk in (semi) public situations where someone might "take over" a logged-in user's account. The code should be corrected as: <?php ...
else if (($user["password"] == md5($_POST["oldpass"])) || ($user["password"] == $_POST["oldpass"])) ?> -- JavaWoman Email AddressesFound several issues with how email addresses are validated / accepted / used; outlined on WikkaAndEmail - and I'm working on solutions. (Email is complicated and there's a whole bunch of standards (RFCs) involved.)First part of the solutions now in WikkaEmailToolkit; while the toolkit is still incomplete, what's there now can be used as presented there (no dependencies on later components). -- JavaWoman I'm being picky here (again!). I've noticed that the double-click edit event is used on the BODY tag. One issue I've experienced is that while entering a comment, I couldn't double-click a word (to highlight and replace it) without triggering the edit screen. My suggestion is to put it on the DIV class="page" tag. -- Sam Bugs I've found:
Thanks - Sam I'm actually not sure if this is a Wikka Bug or not, but I'll put it out there. If the Character Set encoding in Internet Explorer 6 is set to Unicode (UTF-8) the Wikiedit Toolbar does not display and a JavaScript Runtime Error occurs on the page. (You have to doubleclick the little yellow exclamation point icon in the bottom left corner to see the actual error message.) If you right click in the page, select encoding, and change the encoding to Western European (ISO), then the Wikiedit Toolbar appears. If I configure the Default CharSet to be iso-8859-1 in my httpd.conf file, then everything works fine. If I set the default charset to be UTF-8, then I get the error. Is this normal behavior with UTF-8 encoding? -- RichardTerry
Interwiki is brokenInterwiki links are broken if they are not CamelCased, like WikiPedia:Albert_Einstein will not work, but WikiPedia:CamelCase would. Wikipedia heavily relays on FreeLinks, which converts "Albert Einstein" to "Albert_Einsten". --DavidCollantesPassword change problemIf spaces are entered on passwords, it does not works and no feedback is given to users. I tried on the "Change Password" part, not on the new user registration. --DavidCollantesSimple fix: Around line 96 in actions/usersettings.php change this: <?php
if (isset($error)) { print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n"); } ?> to this: <?php
if (isset($passerror)) { print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n"); } ?> -- JavaWoman CategoryDevelopment |