SQL 参数 - 在哪里使用
我正在将 SQL 参数应用到我的项目中以防止 SQL 注入。
我是否向应用程序中的每个查询（包括没有任何用户交互的查询）添加参数？
例如，如果我的用户想要搜索关键字并提交了一个文本字段。我已将参数化方法添加到使用该关键字的查询中，以阻止用户添加恶意内容。但在这个查询的下面是另一个查询，它从顶部搜索中获取关键字 ID，并在其他地方运行它自己的小查询。
这就是令我困惑的地方，即使关键字 ID 不是来自用户，我是否也将参数方法添加到此查询中？
非常感谢
I'm in the midst of applying SQL parameters to my project to prevent SQL Injection.
Do I add parameters to every query in my application, including the queries that don't have any user interaction?
For example, if my user wanted to search for a keyword and submitted a text field. I've added the parameterized method to the query that used that keyword, to stop the user adding something malicious. But underneath this query, is another query, which get's the keyword ID from the top search and runs it's own little query elsewhere.
This is what's confusing to me, do I add the parameter method to this query too, even though the keyword ID wasn't from the user?
Many thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，在任何有参数的地方使用参数化查询。
今天在特定查询上没有使用用户输入这一事实并不意味着明天也会一样。代码更改。也许恶意用户会找出如何破坏第一个查询，然后破坏第二个查询。
您应该考虑纵深防御。
Yes, use parameterized queries in any place you have parameters.
The fact that today no user input is used on a specific query doesn't mean tomorrow will be the same. Code changes. Perhaps a malicious user will figure out how to compromise the first query and then the second one.
You should think about defense in depth.
是的，这也应该是一个参数。否则，您必须跟踪插入到数据库中的哪些值来自用户 - 没有什么可以阻止“'; DROP DATABASE”的名称。如果您盲目地相信数据库中的数据会被清理，那么您一定会在某些时候出错。
像这样的东西
就可以了，因为你的 SQL 引擎将在内部使用参数。其逻辑如下：
这是不正确的 - 因为应用程序没有使用外部和变量输入的参数。
Yes, that should be a parameter too. Otherwise, you have to keep track of what values that you have inserted into the db came from a user - there's nothing to prevent the name of "'; DROP DATABASE". If you're blindly trusting data from the database to be sanitized, you're bound to get it wrong at some point.
Something like:
would be ok, because your SQL engine will use parameters internally. It's the logic like:
that would be incorrect - since the application is not using parameters for external and variable input.