Re: [POLL] Escaping behaviour in SQL/LDAP/regexes

>> 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.

These are possible answers for each of the 4 policy snippets immediately below the possible answers.

We're looking for something like:

1. a
2. b
3. c
4. d

> 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.

This is a contrived set of policies.  The point is to determine what user's expectation of how the variables in the SQL statement are expanded/interpolated, not to debate best practice in policy writing :) 

-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html