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