Database encoding about php-auth HOT 2 CLOSED

No it's not. DB encoding shouldn't be relied on for a security control, you should always sanitize input on receipt (from any data source eg user input), db read and write etc.

This lib uses PDO which has some protection against common sql vulnerabilities, but there are several other ways your code can be vulnerable. Have a look at my other posts for an example, such as JavaScript into the DB.

Note, I don't speak for the project

from php-auth.

Thanks for your question!

Yes, there may be security implications when using the broken utf8 instead of the proper utf8mb4, but I'm currently not aware of any. That being said, if you follow the README and do what the examples suggest, you should be safe using utf8.

For utf8mb4 support, you only need MySQL 5.5.3+ or a recent MariaDB version, which have been available for quite some time now (several years). As a recommendation, I would thus say you should upgrade your database engine's version, which you ultimately have to do at some point, anyway.

One thing that you will definitely experience is data loss. If non-BMP characters are used in usernames, email addresses or other strings passed to this library, it depends on MySQL's settings what happens. If MySQL is in "strict mode", it should throw an error. Otherwise, MySQL will probably accept the input and fail silently, simply truncating everything starting with the first non-BMP character. So foo💩bar might become just foo.

If we have learned anything from the past, especially from problems with null bytes, it's that silent data truncation is often dangerous.

For international products on global markets, with support for the non-English world, including any minor languages, probably also for emoji support, utf8mb4 is a must!

Apart from data loss, the only implication for security that I could imagine right now is truncated email addresses that cause unexpected behavior. Something like

[email protected]💩.evil.example.com

becoming

[email protected]

in the database while the verification email goes to the evil.example.com host. You would have to check the specifications for the local part and domain part of email addresses to check what's really possible here.

That should, however, be prevented by the internal syntax checks for email addresses, which are performed automatically. The effectiveness of those checks will depend on the behavior of PHP's \filter_var function with the \FILTER_VALIDATE_EMAIL flag, though, which might change in future versions.

Hope that helps!

from php-auth.