正确转义不受信任的数据 [英] Correct escaping of untrusted data
问题描述
嗨伙计们，
关于注射攻击的线程非常有启发性，但似乎在一个有趣的点上耗尽了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.com>写道：
Geoff Caplan <ge***@variosoft.com> 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：您是否搜索了我们的列表档案？
http://archives.postgresql.org
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?
http://archives.postgresql.org
<
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
这篇关于正确转义不受信任的数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
