"+" string converted to "=2B" in SQL request

[Arran Cudbard-Bell]

> On Mar 6, 2018, at 12:52 PM, Stefan Winter <stefan.winter at RESTENA.LU> wrote:
> 
> Hi,
> 
>>  And then watch people pwn your database.  Because there's no separate list of safe characters for SELECT versus INSERT.
>> 
>>  We're working on fixing this for v4.
> 
> I've become a big fan of prepared statements to avoid this kind of issue.
> 
> Is the fix in v4 doing prepared statements?

There are two ways of doing this, tainted values and prepared statements.

For SQL prepared statements are definitely the way to go as there are essentially zero side effects to using them, and they always work predictably.  Unfortunately not all datastores allow prepared statements, LDAP being the big one.

Where datastores don't support prepared statements the 'taint' state of any boxed values used to construct the query/filter/url are used to determine whether the value should be escaped.

Any value created in the config is "untainted" any value from an external source (including databases) is considered "tainted".

The major problem with this is where an attribute value could come from the network or locally depending on the contents of the packet being processed.  There you need to remember to explicitly mark up your local value as tainted if it contains characters that might need escaping.

Alan and I have had long discussions about the advantages and disadvantages of tainted values. I can see having to explicitly taint or escape any dynamic inputs to queries in the default config to get them to work reliably for everyone, at which point the scheme seems to lose some of its value.

The one big advantage is that it lets users easily control which values are escaped and which aren't via %{taint:} %{untaint:}, without needing to call explicit escape and unescape functions.

Anyway if anyone wants to help out with the prepared statement stuff it is at the stage where its per-driver code that needs writing, i.e. all the infrastructure has been completed, someone just needs to look through and figure out the correct API functions to call.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20180306/1cda20dc/attachment.sig>