Again, sorry to all for the delay in making the final two fixes to QS 0.13. These will be made at the earliest opportunity and released for testing. The first change adds a new variable flag (boolean) to all Command classes to allow developers explicitly set whether a database connection will be instantiated. DB is not always required, and the default connection created false errors in the installer. The second change will ensure the mysql DSN string is correctly formatted. I will note again that we by no means fully support MySQL 4.1 to Mysql 5.0 – I will be testing these (now 5.0 is out) in the near future. Hopefully I can add a little glue between the Database Class and the MySQL info from the server to allow more specific support – the entire area is a little nebulous for the majority of users.

Okay, so QS 0.13 aside… It’s almost there.

Next step is QS 0.14 – I need to clean up the database which was designed back in March. Some of the more recent MySQL changes make it important and keep tight control over the length of our data fields. Specifically as an example, whitespace is no longer stripped from the varchar data type (trailing) – so when you define varchar(64), all 64 characters (including whitespace) will be stored. This makes for larger database sizes (from what I understand), so optimisation here is warranted. We won’t mention the arbitrary nature of the current schema – I’m a bit lazy in that area, so I simply bung stuff in without a thought for key constraints.

I’m also finalising data escaping. “Aha insecure!”, you said of QS 0.13 if you noticed escaping data prior to SQL statements was…well…missing. I am adding it ;-). However it’s a little more complex since it needs to be independent of the Presentation layer (yes, presentation does need escaping!). Database independence is another story, escaping under MS-SQL is again very specific compared to MySQL or Postgres.

A few other points to score:

1) We need a $_SERVER filter. It seems an almost struggle to convince PHP developers that the contents of $_SERVER are the least understood, and so the most nefarious means, of comitting XSS attacks. PHP_SELF is a prime suspect – any application using this (or its evil relatives; PATH_TRANSLATED, PATH_INFO). It requires a key server configuration to be enabled (usually pretty urls/mod_rewrite will suffice – but varies). Then you simply pass a tainted url encoded string via the url, PHP will read this in as part of PHP_SELF, and it will get included in any code which refers to PHP_SELF etc. It’s a pretty serious vulnerability – its particularly bad when experienced developers are simply not even aware it exists. Where do people think $_SERVER values come from? Thin air? ;-) Ref to a thread I posted in regards this: http://forums.devnetwork.net/viewtopic.php?t=39853&start=15

2) Need to ensure any non dynamically generated variables used within a header() call are filtered. Header injections are possible with tainted data. Think of adding a SetCookie header to what you think is a simple Location header!

After this we get back to adding content – so signups and logins will be revisited, reviewed, finalised and finished. I will also then need to look at two areas; game creation, and a game listing. I tinkered with the idea of supporting only a single game, and I think it may be something I’ll work with for the moment (simplification of work). Multiple games will be added back over time.