Arran Cudbard-Bell via Freeradius-Users <freeradius-users@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