On 02/11/2018 11:04, Alan DeKok wrote:
On Nov 2, 2018, at 6:06 AM, Dom Latter <freeradius-users@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....