PHP / Kohana:保护搜索查询

发布于 2025-01-05 16:20:51 字数 248 浏览 1 评论 0原文

我希望允许用户执行搜索而不受任何字符的限制。

为了保护数据库免受攻击,“添加斜杠”和 /mysql_escape_chars 是否足够?

您还有什么建议?

非常感谢。

PS URI路由-> www.example.com/search/category/query 其中 query 是要搜索的术语。

I want to allow users to perform a search without restriction of any character what so ever.

Is it enough to "add slashes" and / or mysql_escape_chars in order to protect the DB from attacks?

What else would you suggest?

Thank you very much.

P.s. URI routing -> www.example.com/search/category/query where query is the term to be searched.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

一身骄傲 2025-01-12 16:20:51

如果直接传递查询,推荐的解决方案是在参数上使用 mysql_real_escape_string - 尽管这确实需要您首先打开数据库连接。这对于通过在转义时考虑数据库的字符编码来避免使用某些编码进行中间字符转义非常重要。此外,mysql_escape_string 已被弃用。

但是,如果可能的话,建议您改用 准备好的mysqli 库的语句 功能;这使您能够将查询参数作为参数传递给 PHP 方法,从而几乎保证您不会搞砸,同时无需执行转义。

假设您使用 Kohana 的内置数据库工具,您还可以使用 其准备好的语句支持或查询构建器,它也支持准备好的查询,并且不需要转义。

The recommended solution, if passing queries straight through, is to use mysql_real_escape_string on the parameters – though this does require you to open a database connection first. This is important to avoid escapes mid-character using certain encodings by taking the character encoding of the database into account when escaping. Furthermore, mysql_escape_string is deprecated.

However, if possible, it is recommended that you instead use the prepared statements feature of the mysqli library; this enables you to pass query parameters as arguments to the PHP methods, thus almost guaranteeing you won't mess up, while removing the need to perform escaping.

Assuming you are using Kohana's built-in database tools, you can also use its prepared statement support or query builder, which also supports prepared queries, and does not require escaping either.

染年凉城似染瑾 2025-01-12 16:20:51

使用 Kohana ORM / Query Builder - 它们将保护您免受 SQL 注入。唯一需要注意的情况是使用 DB::expr 时,它不会转义变量。请参阅官方文档了解更多信息。

Use Kohana ORM / Query Builder - they will protect you against SQL injection. The only case when you need to watch out is when you use DB::expr, which doesn't escape your variables. Read more in official docs.

几度春秋 2025-01-12 16:20:51

是的,这样的保护已经足够好了(如果您从文本区域插入数据,则几乎相同),但我会使用 mysql_real_escape_string 代替。并且不要忘记在 mysql 查询中的搜索字符串周围添加 '(... WHERE somecolumn LIKE 'query' 而不是 ... WHERE somecolumn LIKE query ,同样适用于 FULLTEXT 搜索)

并且请确保对 url 查询参数中的查询进行 url_encode 或 base64_encode

yes, such a protection is good enough (pretty much the same if you would insert data from a textarea ie.), but i would use mysql_real_escape_string instead. And don't forget to add 's around the search string in your mysql query (... WHERE somecolumn LIKE 'query' instead of ... WHERE somecolumn LIKE query, same goes for FULLTEXT searches)

And please make sure to url_encode or base64_encode the query in the url query parameter

鹿港小镇 2025-01-12 16:20:51

这个问题对我来说没有多大意义。

  1. 为什么搜索只是您关心的问题?采用参数的动态 SQL 查询是我们每个应用程序的基石。应该有一个通用规则(或一组规则),涵盖动态 SQL 的每一个案例,而不仅仅是一个。

  2. Kohana 当然有它自己的工具来操作 SQL。为什么使用原始“添加斜杠”/mysql_escape_chars 代替?

  3. www.example.com/search/category/query 将需要不必要的重定向。为什么不使用常规的 /search?cat=category&q=query?谷歌似乎并不认为使用此类网址进行搜索是一种耻辱 - 为什么要这样做呢?

the question makes not much sense to me.

  1. Why search is only your concern? Dynamical SQL query taking parameters is the cornerstone of every our application. There should be a general purpose rule (or set of rules) covering every single case of dynamical SQL, not just one.

  2. Kohana certainly have it's own tools to operate SQL. Why use raw "add slashes" / mysql_escape_chars instead?

  3. www.example.com/search/category/query will require unnecessary redirect. Why not to use regular /search?cat=category&q=query? Google doesn't seem to think it's a shame to use such urls for the search - why should you?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文