-
Notifications
You must be signed in to change notification settings - Fork 7.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Procedural and PDO ODBC don't escape user input when building connection string #8300
Comments
You can also use curly braces or single quotes wrapping the password in the third arg as a weak attempt to mitigate. It also gives you other fun opportunities for injection, like:
|
Ugh, that's ugly (I don't think we should discuss details publicly, but we need to keep these in mind). Anyhow, I'm not sure what to do, though. If we would automatically escape (if that's even possible in a portable way), that could easily break code which does the escaping manually. Adding an INI setting is undesireable (same code, different behavior). For PDO_ODBC, we could add a connection attribute, though. At the very least we should properly document the current behavior, and maybe we should introduce an additional function for escaping.
So warn/error on unescaped |
So the documentation for Do agree checking for |
From the SQLDriverConnect docs:
So it looks like only semicolons are an issue. |
Looking at other ODBC bindings for other languages (Node, .NET, Erlang/OTP), I notice none of them actually use For another comparison, .NET has some facilities for building connection strings (generically and for ODBC), and actually seems to note some of the specific rules for quoting/escaping too. |
Closed via 2920a26. |
Description
The following code:
Resulted in this output:
But I expected this output instead:
PDO is also affected.
I dealt with a PHP user's issue where they had a password with a
;
in it. Unfortunately, the code that handles thector(connection string, uid, pwd)
case is naive (both for procedural and PDO) and appends without any special processing. That means the connection string will be mangled (or worse, injectable) if the user application doesn't do what PHP does behind the scenes, but better themselves (doctor("connection string;uid={uid};pwd={pwd}", null, null)
, whereas PHP only doesctor("connection string;uid=uid;pwd=pwd", null, null)
).Unfortunately, after reading unixODBC code, it seems clear that the responsibility of parsing these connection strings is at the driver level, so in theory every driver could be handling how to escape strings themselves. It seems the usual standard is
{wrap in curly braces}
, and some drivers support single quotes. There may be more escaping/quoting rules I'm not aware of (possibly covered by the ODBC standard?). The IBM i Db2 driver seems to support both, but the MariaDB driver only support curly braces.It could also be that it's not PHP's responsibility to deal with this, but it is unfortunate to have to explain
SQLConnect
vs.SQLDriverConnect
behaviour to people writing application code. If PHP can't escape, perhaps it could warn/error out if user input is problematic.PHP Version
PHP 8.2.0-dev
Operating System
Fedora 35
The text was updated successfully, but these errors were encountered: