On 21/09/12 13:14, Arran Cudbard-Bell wrote:
I'm presuming that properly escaped strings will be converted back to there unescaped form when they get inserted into the database?
Yes. If the NAS sends: User-Name = "foo'bar" Some-Attr = "some\ntext" ...then then SQL escape function will generate a string (depending on what the DB driver does for escaping): insert into x (username,msg) values (E'foo''bar', E'some<newline> text') ...and the value in the SQL column will be: foo'bar some<newline>text
Applications that relied on FreeRADIUS to do the escaping of special characters would then be vulnerable to various other kinds of injection attacks.
The idea would be that by using the DB escape code, you eliminate *all* vulnerability to injection attacks. Xlat will always generate correctly quoted strings. But I think you're talking about other apps that then *read* the data FR has inserted, in which case see below.
I've copied the safe character code into another xlat function (could you pull and update that as part of your patch set too). In your second patch set please wrap user modifiable attributes e.g. User-Name/User-Password where they're used in INSERT/UPDATE queries with %{encode:}, this should minimise the risk of administrators inadvertently exposing other applications to raw user provided data.
My intention was to make the escaping mode a setting on the SQL instance that defaults to safe-characters, but can be set to "native".