3 ms·
The problem is not really syntax. Almost any syntax which embeds user supplied strings is vulnerable to syntax hacks. The only way I could see to avoid an emb
by MattPalmer1086 4y ago
The problem is not really syntax. Almost any syntax which embeds user supplied strings is vulnerable to syntax hacks.
The only way I could see to avoid an embedded string altering syntactic meaning is if the syntax either gives the length of the parameter before it, or surrounds the parameter with some unguessable values. For example:
SELECT "10:xxxxxxxxxx" FROM USERS;
SELECT "s63hfe&:xxxxxxxxxxs63hfe&" FROM USERS;
Where xxxxxxxxxx is the user supplied value.
Both of these are totally impractical of course.
- mfontani 4y ago"just" use concat or similar (depending on your database flavour) with "?": #!/usr/bin/env perl use 5.020_000; use warnings; use DBI qw<>; my $dbh = DBI->connect('dbi:SQLite:dbname=:memory:'); my $sth = $dbh->prepare('SELECT ("quux-" || ?) AS foo'); $sth->execute('bar'); say $sth->fetchrow_hashref->{foo}; ... gives: $ perl c.pl quux-bar
- projektfu 4y agoI was thinking like an application of JSON that would be more likely to be produced by stringify than by concatenation. Then escaping would come "for free". It wouldn't guarantee the right thing but it would make it much more likely.