Savant 2.4.0 Released

FYI: David Mytton of Olate Ltd has written a great introduction to and review of Savant over at SitePoint. Thanks, David! 🙂

And now, back to our regularly-scheduled blog entry:

After a bit of kerfluffle over cross-site scripting attacks, and working to sanitize some template output, I realized it how useful it would be for Savant to help automate escaping of values for output. After a few days of mailing-list discussion about how such functionality should work, I’ve released Savant 2.4.0 with a handful of new methods built-in:

  • setEscape() and addEscape() to define what callbacks to use when escaping output
  • getEscape() to retrieve the array of escaping callbacks
  • $this->escape() to escape-and-return a value
  • $this->_() to escape-and-echo a value

The default escaping callback is htmlspecialchars(), but you can add any number of your own. For example, after instantiating Savant, you can do something like this:

$savant =& new Savant2();
    array('StaticClass', 'method'),
    array($objectInstance, $objectMethod)

Each of the parameters is callback suitable for call_user_func(), and you can use an arbitrary number of parameters.

These callbacks are applied, in order, whenever you use the $this->_() or $this->escape() methods in your Savant templates (which are, of course, just PHP scripts dedicated to presentation logic). For example, instead of echo htmlspecialchars($this->value), you would call $this->_($this->value) (and the default htmlspecialchars escaping will be applied).

In addition, you can override the default escaping. You may optionally pass an arbitrary number of added parameters to escape() or _(), and these will be treated as callbacks to apply to the value instead of the default escaping callbacks. For example, $this->_($this->value, 'strip_tags', 'my_escape_function', array('StaticClass', 'method')) will override the default escaping with the callbacks listed as the added parameters.

Update: The documentation on the Savant site has been updated: all examples using “echo” have been changed to “$this->_()”, and the escaping methods themselves have also been documented.

Yawp 1.1.0 released

Stefan Esser of discovered simple but potentially serious flaw in the Yawp 1.0.6 release of February 2005. Version 1.1.0 has been released to correct it. All users of Yawp and YaWiki are strongly encouraged to upgrade immediately.

The change notes for the release are:

* BACKWARDS COMPATIBILITY BREAK: Removed the $GLOBALS[‘_Yawp’][‘conf_path’] variable, as it can be the source of serious security problems when register_globals is turned on in combination with other circumstances. In its place, use define(‘YAWP_CONF_PATH’, ‘/path/to/Yawp.conf.php’) to set up a custom configuration file location.

* Added htmlspecialchars() to the trigger_error() messages generated when the configuration file cannot be read or found.

Regarding ethics: Stefan dowloaded Yawp/YaWiki and installed it himself, noticed the flaw, and contacted me privately about it with a full description and list of consequences. Under five hours later, we have a new release. Thanks, Stephan.

Incidentally, this illustrates two related reasons to try to write well-commented straightforward code, adhere to a common coding standard, and write end-user documentation: (1) it becomes much easier for other developers to understand what’s going on and discover flaws, and (2) it becomes much easier to fix and release patched versions quickly.

YaWiki 0.21.1 Released

This is a security upgrade. You can download it from the usual location at

Arnaud Limbourg performed a full code audit for $_GET, $_POST, and $_SERVER usage. He discovered some instances of unescaped $_SERVER values in the controller scripts (not the templates). Escaping has been applied to those instances, even in some cases where it does not appear immediately necessary. The flaws have no reported exploit in the wild, but users are strongly encouraged to upgrade regardless.

Thanks, Arnaud. 🙂

YaWiki 0.21 beta released

This is a security-fix release; all users are strongly encouraged to upgrade to the new version. You can get it from The change notes are:

* Security Fix: In the default template set, added a paranoid number of htmlspecialchars() to help prevent cross-site scripting attacks; it should only matter in the one specific template, but you never know.

* Schema Change: Added a column to yawiki_areas. Run the “docs/MIGRATE_020_021” SQL code against your database.

* Added file “changes.php” for quick change listings (thanks Del!)

* Area administrators can now clear page locks via the area_pages.php script (thanks Del!)

* The top-level navigation elements are now always populated, even for pages not on the AreaMap

* Added file “referrals.php” to show external referrals

And now for a few words spoken more from anger and frustration than from anything else:

I understand that there are bad guys (“black hats”) out there who want to hijack sites and/or prove their [email protected] l33t ski11z at picking apart other people’s software. Black hats don’t give notice in advance that they are “testing” or “probing” a live site. Black hats don’t give notice after-the-fact, either, unless it’s for monetary gain.

Recently, some YaWiki-based sites, specifically those with open comments enabled, have come under attack by someone testing for cross-site scripting vulnerabilities. I’m pretty sure this person thinks he is a good guy, or a white hat, because most of the testing consists of variations on <test_xss> strings. However, he hasn’t notified any of the site owners in advance that he is testing the site, and he certainly hasn’t notified *me* of any possible flaws in the software. This places him squarely in the “black hat” category. White hats give advance notice; even better, white hats only test their own systems, not those belonging to other people (unless invited to do so).

The kicker is that I have reason to believe this person is a well-known PHP developer (at least in certain circles). If it is in fact this person, his behavior is at best profoundly unprofessional, and at worst unethical; he should be ostracized from the community until he apologizes for his actions.

Update: It’s not who I thought, thank goodness; it would have been quite a blow. However, I have one other suspect; I hope it’s not that person either, because it would be an even bigger blow. Regardless, the attacker should at least contact me and let me know what he’s found.

Update: I think Pierre-Alain has somewhat missed my point in his blog entry about this. My contention is that, if you probe a site (that is not yours) in this way, you’re not part of the solution, you’re part of the problem. Black hats are under no obligation to provide notification to the subject of their “experiments” which is part of why they’re bad guys. White hats obligate themselves to a higher standard; that’s part of why they’re good guys. Simple courtesy among community members is generally a good goal to aim for, and telling people what you’re doing is part of that courtesy.

Solar 0.6.1 Released

The Solar_Valid class had some bugs in it that were revealed by unit testing, so I had roll a new release. The change notes are all related to Solar_Valid, which now has its own test suite.

* The inList() method now strict-checks values; this helps avoid confusing (for example) ‘0’, 0, and empty strings.

* The inScope() method was broken, have replaced with an algorithm that actually works (and is incidentally more streamlined).

* The max() and min() methods no longer treat empty strings as zero.

* The nonZero() method now works properly in all tested cases, even multiple string zeros (e.g., ‘000’ is still zero).

* Per note from Chris Drozdowski about ISO 8601, the isoTime() method now allows two midnight times: “00:00:00” marks the beginning of the day, and “24:00:00” marks the end of the day.

There are no documentation changes for this release.

(Solar is a simple object library and application repository for PHP5; it is E_STRICT compliant.)

Solar: Future Plans

With the new release of Solar 0.6.0, one user has asked if there is a roadmap for future releases. (Solar is a simple object library and application repository in the spirit of PEAR and Horde.)

I’m afraid there’s no roadmap, but there is a to-do list. I wrote it specifically in response to the roadmap question, and the initial contents are as follows. As you can see, it’s relatively ambitious; if anybody would like to join the project, just contact me by email; this is a good time to for interested developers to get in on the ground floor and make a name for themselves.

  • Document and write tests for existing classes
    • which will result in API changes as discrepancies are revealed
    • may add new minor classes as refactoring occurs
  • The last of the docs and testing will be the Sql class
    • they are the most complex
    • Sql_Driver classes will be converted to PDO
    • Sql_Entity class needs refactoring (far too complicated, try separate Table and Select classes)
    • Possible addition of portable pseudo-SQL string and date functions
  • Then new classes (in no particular order)
    • Foundation classes
      • Solar_Log, universal logger (c.f. PEAR Log)
      • Solar_Event, universal event dispatcher
    • Solar_Text, text manipulation classes
      • Solar_Text_Markup, transformation for BBCode, ReST, Textile, Wiki, etc (c.f. PEAR Text_Wiki)
      • Solar_Text_Diff, difference engine (c.f. PEAR Text_Diff)
    • User classes
      • Solar_User_Prefs, user preferences collection
      • Solar_User_Perms, user permissions collection
    • Cells
      • Solar_Cell_Bayes, universal Bayes filtering (for comments, trackbacks, edits, etc)
      • Solar_Cell_Hits, hit counting for page views, visitors, referrers, etc
      • Solar_Cell_Prefs, user and application preferences storage
      • Solar_Cell_Perms, user permissions storage
  • Then new apps:
    • Solar_App_Wiki (the follow-on to YaWiki)
    • Solar_App_Blog (using the Wiki engine)

A universal content model is under development as well.