[POLL] Escaping behaviour in SQL/LDAP/regexes

[Bjørn Mork]

Arran Cudbard-Bell via Freeradius-Users
<freeradius-users at lists.freeradius.org> writes:

> We'd appreciate it if FreeRADIUS users could look over the policy
> snippets below and indicate what you expect the SQL statement to be
> _as executed_ (not the result of evaluating the statement).

I'm not sure if you're asking what I expect from a sane sql client or
what I believe FreeRADIUS will do.  I'll answer based on the first
alternative since thaẗ́s what I care about.


> Assume the value of User-Name is: Bob'; DROP TABLE users;--
>
> Possible answers:
>
> a) SELECT * FROM my-table WHERE Service-Type = 'Framed-User' AND User-Name = 'Bob'; DROP TABLE users;--'
> b) SELECT * FROM my-table WHERE Service-Type = \'Framed-User\' AND User-Name = 'Bob\'; DROP TABLE users;--'
> c) SELECT * FROM my-table WHERE Service-Type = 'Framed-User' AND User-Name = 'Bob\'; DROP TABLE users;--'
> d) Other.  Please write expected, expanded, SQL statement.


My expectation is always a prepared statement in the form

  SELECT * FROM my-table WHERE Service-Type = 'Framed-User' AND User-Name = ?

called with the current User-Name variable value as a bound parameter.

This will of course not work with "%{sql_condition}" as a variable.  But
then I don't expect "%{sql_condition}" to be a variable either.  Why
would it?  Better write the complete statement.

And if you have two almost identical statements in the configuration,
then you have two almost identical statements in the configuration.
Nothing to gain by combining them with some made up variable
part. That's only confusing, and adding unnecessary risk of screwing up
quoting/expansion.



Bjørn