1

Let's say I have a web application that gets input from the user and saves it in a database. Let's further assume that there are no security vulnerabilities -- it correctly escapes user input, uses bind parameters, whatever.

Must data retrieved from the database be treated with suspicion (i.e. as potentially tainted/malicious)?

Example (not sure of the result because I'm afraid to try it). This is the database:

create table mytable (id int primary key, name varchar(50));

create table othertable (name varchar(50), xyz int, 
    ... `name` is an fk ...);

insert into mytable (id, name) values(1, '"abc"; drop table mytable;');

insert into othertable (name, xyz) values('"abc"; drop table mytable;', 45475);

Then I run this pseudo-code (maybe from PHP, for example):

# run query 'select * from mytable where id = 1';

# put the `name` in $name

# run query 'select * from othertable where name = $name'
# $name is not escaped, no other precautions taken
Matt Fenwick
  • 48,199
  • 22
  • 128
  • 192

2 Answers2

1

You MUST escape again. All escaping does is say 'SQL, this isn't a command oriented ', it's a part of the data'. So if you escape " 'one' ", SQL will store " \'one\' ", and output... " 'one' ". Which means that you have to escape all over again.

Better yet, instead of using the regular mysql_ functions, use prepared statements from either mysqli_ or PDO. I'm moving my own programming approaches over because they obviate the need for escaping. (The basic idea is that instead of sending a query string which has to be parsed with the data 'in place', you send over a query string with placeholders, and then tell SQL 'remember that query I gave you earlier? Use values X, Y, and Z in it. As a result, the values never have a chance to corrupt the processing of the actual query)

RonLugge
  • 5,086
  • 5
  • 33
  • 61
0

The vulnerability happens at the point where you substitute the $name. Always escape before substituting.

Raymond Hettinger
  • 216,523
  • 63
  • 388
  • 485