Is my vendor vulnerable to sql injection?

Question

The company I work for has recently moved to an external vendor for payroll services. We did an initial upload of data from our old system to the new vendor. I noticed that our employees that have apostrophes in their names (O’Riley for example) were no longer matching up with other systems. The new payroll vendor had removed the apostrophes. We are able to manually add the apostrophe back in via the web based front end, and running a report immediately after the change shows the apostrophe, but the character is removed by the next day.

When I inquired with the payroll vendor about the removed characters, I was informed that "The system will automatically remove quotes as they are problematic in the database itself." It was recommended that we use the grave (backward single quote) character instead because it looks similar to a single quote.

My question is this: Does the inability to handle quotes (single or double) in a database indicative of vulnerability to sql injection and is there a safe and legal way to prove or disprove this vulnerability?

This is a payroll system and I am hesitant to attempt to discover any vulnerability on the live system and I do not have access to a test system.

Answer 1

I haven't worked with payroll systems and I don't know how old the one you have is. I do know that they often have to support ancient data formats so it could be that they need to do this for compatibility. Even so, this is indicative of a flawed system and a company that does not have the resources to fix their software. It does not immediately follow that it is vulnerable to SQL injection. It is worth checking out, though.

It is written into the contracts we have with vendors that they allow a security assessment if we want to.

My advice is to ask them for documentation of their security assessments and if you are not satisfied, then tell them you need to do your own security assessment. Unless they've hired an outside firm and have a complete report (longer than a page, say), and can show a history of assessments and improvements, then you probably shouldn't be satisfied. Then you can hire someone to do it or do it yourself if you feel comfortable doing that.

Answer 2

It doesn't necessarily mean that they are vulnerable. They may have removed it just for paranoia.

However, in my book it is a bad practise to do that. You are changing the name, it's not like an identifier where a character restriction wouldn't matter too much, and it doesn't even mean you are safe.

Moreover, the fact that it was removed the day after you changed it suggests it isn't a filtering done on input, but that they have a vulnerable nightly process that broke due to the ' and someone then removed it.

I agree it is worth enquiring their security practises. Also note it is better to discover issues early than late. I'm sure that -if needed- you could migrate back from that system, whereas in one year a problem that led to lose of all payroll data stored there might not.

Answer 3

It is cause for serious suspicion and possibly indicative of other issues, however:

If the system were, in this instance, vulnerable to SQL injection your update would have failed:

UPDATE users SET first_name = '?' WHERE user_id = ?;
UPDATE users SET first_name = 'O'Henry' WHERE user_id = 1; //substituting without escaping

As you can see the SQL parser sees first_name = 'O' but since Henry doesn't match a control word it will throw an error.