Can federated login (OpenID, e.g.) pose SQL injection risk?

Question

Can all identity providers be safely assumed to sanitize user information, or could one create an account or identity provider to deliver malicious usernames, emails, contact lists, etc?

Answer 1

The trustworthiness of existing providers is irrelevant. An attacker can write their own identity provider and use that to send you whatever they want. You should practically never trust third-party data.

Answer 2

Never assume someone else is going to sanitise data for you. Do it yourself, or (better) interface to your database in a way that prevents SQL injection by proper encoding of parameters.

Answer 3

Even if they do not allow such characters, even if the specification forbade such characters, you should not rely on that.

Make sure, when you receive the data, that it follows your expectations. Also, play safe and always use prepared statements/parameterized queries with no need for escaping the arguments or, if not possible, escape the query arguments. Do this by habit and you won't have nasty surprises.

Answer 4

We have several people that have apostrophes in their email address, this is not invalid...the problem is not the apostrophe but that the coders are not using parameterized queries and or stored procedures. Really nobody should be using inline SQL and be concatenating string these days, that would prevent almost all SQL Injection attacks

If you do have to use dynamic SQL in for example SQL Server then use sp_executeSQL with parameters and not EXEC....