Apostrophe in username
Dom Latter
freeradius-users at latter.org
Fri Nov 2 12:32:28 CET 2018
On 02/11/2018 11:04, Alan DeKok wrote:
> On Nov 2, 2018, at 6:06 AM, Dom Latter <freeradius-users at latter.org>
> wrote:
>> Or just using conventional escape mechanisms (e.g.
>> mysql_real_escape_string()).
>
> Which, IIRC, wasn't available when the rlm_sql module was written...
> in 2000 or so.
Yes, I suspected that.
> I think there's a misconception here. The issue is *not* about
> apostrophes in the DB. The issue is apostrophes in SQL queries.
> And, apostrophes which come from *untrusted user input*.
>
> That untrusted user input MUST be escaped for it to be safe. Either
> that, or passed to a stored procedure.
>
> Adding apostrophe to the list of safe characters means that any user
> can own your database. It is absolutely and 100% the wrong thing to
> do.
I am very aware of all this - I should have made myself clearer in the
first place. Adding apostrophe to the list was purely an experiment;
I had vague hopes that it might have been escaped with a backslash.
>> It's a long time since I wrote in C but I am guessing that the
>> following added to sql_escape_func() inside rlm_sql.c would sort
>> it:
>
> That's pretty much what the "safe-characters" code already does.
I beg to differ - it mime-encodes.
I note that
https://dev.mysql.com/doc/refman/5.7/en/mysql-real-escape-string.html
says:
"Characters encoded are \, ', ", NUL (ASCII 0), \n, \r, and Control+Z.
Strictly speaking, MySQL requires only that backslash and the quote
character used to quote the string in the query be escaped."
So if I have understood, the safe_characters code could be replaced
with the snippet I just posted, a similar one for \, and no mime-
encoding at all....
More information about the Freeradius-Users
mailing list