Symphony.

Hi folks

Currently evaluating Symphony for a range of projects.

Spotted the following statement in a thread on database abstraction:

However the MySQL class receives SQL statements as text strings since these are concatenated and built throughout the entire system, including third party extensions.

Concerned that this sounds like a recipe for injection vulnerabilities.

Can anyone reassure me that the engineering of Symphony conforms to good security practice?

I know big sites that run on Symphony that are required to run intrusion tests every four weeks and they haven’t come up with any concerns yet.

Of course, this only speaks for the extensions and core-version used there. Every extension opens for potential new security holes but in general most of them are of very high quality.

Concerned that this sounds like a recipe for injection vulnerabilities.

If not done strictly, it can be. I presume string concatenation is favoured over parametised stored procedures to keep the barrier to entry low (both for server requirements, maintenance and contribution). Because Symphony is a big abstraction, SQL statements do genuinely need to be built using string concatenation at runtime.

Concatenation in the core uses the sprintf() function as a way to replace strings. Therefore something like this:

sprintf("SELECT * FROM sym_entries WHERE entry_id=%d", $_GET['id']);

The %d placeholder will only accept a number, therefore you can’t force an SQL injection into this position.

Similarly Symphony’s MySQL class employs a cleanValue($string) function (which wraps around a standard PHP function) to escape characters in strings to mitigate SQL injection attacks.

Whether or not third party extension adhere to using these functions is up to them, so it’s something you should review each time to install one.

Nick

I appreciate the response. Not entirely comforting though - seems to me that any CMS should give high priority to ensuring that extensions have to comply with good query practice. I agree that stored procedures would be too clunky a way to go, but there are alternatives, I think. Not sure about MySQL, but with Postgres you can create parametised queries at runtime. In my own work I’ve created a database access layer that pretty much forces good practice, given a modicum of discipline on the part of the developer. Direct database access that bypasses the access layer is verboten…

Direct database access that bypasses the access layer is verboten

functionally, or just conceptually?

Functionally, pretty much. DB account password is encrypted within the app, and only accessible by the db access layer. It could be hacked, with effort, but the idea is to prevent developer laziness, and it is much easier to use the nice db api!