https://bugzilla.wikimedia.org/show_bug.cgi?id=16294
Nicholas Wilson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5577 is|0 |1 obsolete| | --- Comment #9 from Nicholas Wilson <[email protected]> 2008-12-14 23:02:25 UTC --- Created an attachment (id=5584) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=5584) more parsertests, cleared up return values from refArg (In reply to comment #8) > (Line numbers are after applying the patch) > > I see you added a 'cite_error_references_nested' error! Shouldn't the "ref > was" > part be localizable, though? Also, can the old check (lines 158-161) be > removed, or is it still useful? The old check was there to warn the user against the annoying problem of unbalanced tags, which the parser just chews up silently. There is another check to prevent the XML-valid nesting of tags (for various reasons). Before, this failed fairly silently, so the new error is there to alert the user that something is wrong. Both pieces of code are meant to be in use. > > {{#tag:ref||name=0}} fails. At line 143, it should be is_null($key) instead of > $key==false. Thanks. I have thoroughly rewritten the parser tests now to test nearly exhaustively all possible ways of producing a single error, and some ways of producing two. This should catch more of this sort of thing (but not so many false negatives) in future. Perhaps another set of tests for 'pathological positives' would be helpful sometime. > > When the ref tag has unknown parameters (e.g. <ref name="foo" value="bar">), > false is returned from refArg into $key. Instead of generating an error, these > are now all being treated as <ref name="" group="0"> would be were name="" > allowed. Either restore the check for $key===false in guardedRef, or change > refArg to silently ignore unknown parameters. The problem was just a slightly sloppy merge of a line from the stuff that had changed since the version I started working from. I have removed a few cases from refArg to neaten up the possible return values and fixed up guardedRef. > > You're not escaping the group when outputting the inline ref tags: try <ref > group="<script>alert('Pwned!')</script>">Uh-oh</ref>. Passing > $text > through htmlspecialchars in referencePlaceText seems to take care of it. Yikes! This one really is my bad. mRefs now holds dangerous text, is documented as such, and everything is escaped when written out to the page (I hope!). I think everthing is safe now, but I should not have slipped up there. Thanks for double-checking my 'late night' code! > > For the 'cite_error_references_no_text' error, you are not properly escaping > the key. But here it seems you can only inject wikitext, so it's just > aesthetic > rather than a security hole. This is fine. I had thought that anything the user types, they are happy with having echoed back at them as wikitext. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
