转义/清理从数据库检索的数据
假设我有一个 Web 应用程序，它从用户那里获取输入并将其保存在数据库中。让我们进一步假设不存在安全漏洞——它正确地转义用户输入、使用绑定参数等等。
从数据库检索的数据是否必须受到怀疑（即可能被污染/恶意）？
示例（不确定结果，因为我不敢尝试）。这是数据库：
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);
然后我运行这个伪代码（例如，可能来自 PHP）：
# 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
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你必须再次逃脱。所有转义只是说“SQL，这不是面向命令的”，它是数据的一部分。因此，如果您转义“ 'one' ”，SQL 将存储“ \'one\' ”，并输出...“ 'one' ”。这意味着你必须再次逃离。
更好的是，不要使用常规的 mysql_ 函数，而是使用 mysqli_ 或 PDO 中的准备好的语句。我正在改变我自己的编程方法，因为它们消除了转义的需要。 （基本思想是，不是发送必须用“就地”数据进行解析的查询字符串，而是发送带有占位符的查询字符串，然后告诉 SQL“还记得我之前给你的查询吗？使用值 X 、Y 和 Z 因此，这些值永远不会破坏实际查询的处理）
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)
该漏洞发生在您替换
$name的地方。替换之前一定要先逃跑。The vulnerability happens at the point where you substitute the
$name. Always escape before substituting.