正确转义不受信任的数据

本文介绍了正确转义不受信任的数据的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

嗨伙计们， 关于注射攻击的线程非常有启发性，但似乎在一个有趣的点上耗尽了b $ b。现在你们好心地告诉我这些问题的真实性质，我可以再问一下 什么是有效的逃避真正意味着什么？ 是否在PHP，Tcl等API中找到了标准的转义函数 Postgres防弹？是否有任何编码可以通过 并在Postgres内部转换为恶意字符串？怎么样功能 喜欢convert（）：它们可以用来通过 转义函数来滑动吗？ 我不喜欢我真的对这个领域有足够的知识，对自己的实验结果充满信心。任何技术上更精明的建议都会非常感激。 ------------------ Geoff Caplan Vario Software Ltd （+44）121-515 1154 ----- ----------------------（播出结束）----------------------- ---- 提示9：如果您的 加入列的数据类型不匹配，计划者将忽略您选择索引扫描的愿望

Hi folks, The thread on injection attacks was very instructive, but seemed to run out of steam at an interesting point. Now you guys have kindly educated me about the real nature of the issues, can I ask again what effective escaping really means? Are the standard escaping functions found in the PHP, Tcl etc APIs to Postgres bombproof? Are there any encodings that might slip through and be cast to malicious strings inside Postgres? What about functions like convert(): could they be used to slip something through the escaping function? I don''t really have enough knowledge in this area to be confident in the results of my own experiments. Any advice from the more technically savvy would be much appreciated. ------------------ Geoff Caplan Vario Software Ltd (+44) 121-515 1154 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column''s datatypes do not match

推荐答案

Geoff Caplan< ge *** @ variosoft>写道： Geoff Caplan <ge***@variosoft> writes: PHP，Tcl等API中发现的标准转义函数是否具有防爆功能？ 我不知道;你可能想看看你计划使用的每个人的来源，无论如何，如果你是偏执狂的话。只要他们退出''和'\\'他们应该没问题。如果您的源语言允许 嵌入空值（\ 0）在字符串中，您可能也想要拒绝它们。 是否有任何编码可能会通过并在Postgres内部转换为恶意字符串？ 所有支持的编码都是ASCII的超集，所以我不认为 存在任何此类风险。在相反的方向存在风险 我认为：如果转义函数不知道正在使用的编码 它可能会认为多字节字符的一个字节是'或或\\和 试图逃避它，从而打破数据。这不可能发生在 " sane"然而，像UTF-8这样的编码只是在一个或两个远东元件b $ b编码中，允许多字节字符包含字节< = 0x7F。 自你作为应用程序员可以控制使用什么样的客户端 编码，这里最简单的答案是确保你使用合理的编码，或者b $ b至少转义函数知道你正在使用的编码。 如convert（）这样的函数：它们可以用来滑动某些东西吗？通过逃避功能？ Are the standard escaping functions found in the PHP, Tcl etc APIs to Postgres bombproof? I dunno; you''d probably want to look at the source for each one you planned to use, anyway, if you''re being paranoid. As long as they escape '' and \ they should be okay. If your source language allows embedded nulls (\0) in strings you might want to reject those as well. Are there any encodings that might slip through and be cast to malicious strings inside Postgres? All the supported encodings are supersets of ASCII, so I don''t think there is any such risk. There is a risk in the opposite direction I think: if the escaping function doesn''t know the encoding being used it might think that one byte of a multibyte character is '' or \ and try to escape it, thereby breaking the data. This could not happen in "sane" encodings like UTF-8, however, just in the one or two Far Eastern encodings that allow multibyte characters to contain bytes <= 0x7F. Since you as the application programmer can control what client-side encoding is used, the simplest answer here is just to be sure you''re using a sane encoding, or at least that the escaping function knows the encoding you''re using. What about functions like convert(): could they be used to slip something through the escaping function?

不知道怎么做。问题是要确保向后端传送 的查询字符串将按照您的预期方式进行解释。当任何服务器端函数执行时， 时间太晚，无法更改 解释。 问候，tom车道 ---------------------------（播出结束）----- ---------------------- 提示6：您是否搜索了我们的列表档案？ archives.postgresql

Don''t see how. The issue is to be sure that the query string traveling to the backend will be interpreted the way you expected. By the time any server-side function executes it is far too late to change that interpretation. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? archives.postgresql

<

Geoff Caplan写道： Geoff Caplan wrote: PHP，Tcl等API中发现的标准转义函数是否具有防爆功能？是否有任何编码可能会滑过并在Postgres内部转换为恶意字符串？那些函数怎么样像convert（）：它们可以用来通过转义函数来滑动吗？ Are the standard escaping functions found in the PHP, Tcl etc APIs to Postgres bombproof? Are there any encodings that might slip through and be cast to malicious strings inside Postgres? What about functions like convert(): could they be used to slip something through the escaping function?

如何编写nessus插件（ s）或这些 逃避问题的特定扫描仪？我不知道这样的事情是否已经存在...... - 奥利维尔 ---------------------------（广播结束）------------------ --------- 提示7：别忘了增加免费空间地图设置

What about writing nessus plugin(s) or a specific scanner for these escaping issues ? I don''t know if a such thing already exists... -- Olivier ---------------------------(end of broadcast)--------------------------- TIP 7: don''t forget to increase your free space map settings

汤姆， 迟来的感谢信息（我已离开办公桌）。 非常有帮助。 ------------------ Geoff Caplan Vario Software Ltd （+44）121-515 1154 ---------------------------（广播结束）--------------------------- 提示7：别忘了增加你的费用免费空间地图设置 Tom, Belated thanks for the info (I''ve been away from my desk). Very helpful. ------------------ Geoff Caplan Vario Software Ltd (+44) 121-515 1154 ---------------------------(end of broadcast)--------------------------- TIP 7: don''t forget to increase your free space map settings