糟糕的代码：为什么这很危险？

发布于 2024-09-10 00:37:45 字数 510 浏览 7 评论 0原文

可能的重复：
我可以防范 SQL 注入吗通过转义单引号并用单引号包围用户输入？

     String badInput = rawInput.replace("'","''");
     ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE col1 = '"+badInput+"'";

有没有办法做一个“Bobby表”对这段代码的类似攻击？

原文

Possible Duplicate:
Can I protect against SQL Injection by escaping single-quote and surrounding user input with single-quotes?

     String badInput = rawInput.replace("'","''");
     ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE col1 = '"+badInput+"'";

Is there any way to do a "Bobby Tables"-like attack on this code?

分享到QQ

分享到微博

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

发布评论

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

做个少女永远怀春 2024-09-17 00:37:45

根据所有解释命令的过程中的不同步骤，可能有可能传递 %27 （例如）并将其充当单引号，在替换时不被注意地传递。

但即使可以涵盖所有此类情况，并且对于这一单一问题实际上是安全的，但其不足之处在于无法统一实施。其他人可能会想添加 AND int1 = var1，并注意到您已经考虑过 SQL 注入，因此他们只是以与您完全相同的方式修改代码

String badInput = rawInput.replace("'","''");
String badInteger = rawInteger.replace("'","''");
ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE" +
 "int1 = " + badInteger + " OR col1 = '"+badInput+"'");

......仅使用整数它不再是您想要保护自己免受的报价！在这里，很明显任何事情都可能出错。因此，虽然这是一个需要有人实施得不好的问题，但我认为这是设计的最大问题——它只涵盖了一小部分情况。

能够只说“以下是一个变量。无论它包含什么，都将其视为一个值，并且不要尝试将其部分用作代码并执行该代码”，这总是更好。

Depending on the different steps along the way that all have to interpret the command, there may be some possibility to pass %27 (for instance) and have it act as a single quote, passing unnoticed through your replace.

But even if all such cases could be covered, and it was actually safe for this single question, it is lacking in that it cannot be uniformely implemented. Somebody else may come along and want to add AND int1 = var1, and notices that you have thought about SQL injection, so they just modify the code in the exact manner that you have

String badInput = rawInput.replace("'","''");
String badInteger = rawInteger.replace("'","''");
ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE" +
 "int1 = " + badInteger + " OR col1 = '"+badInput+"'");

...only with integers it is no longer quotes you want to protect yourself from! Here, it is plain to see that anything could go wrong. So while that's a problem that requires somebody to implement it poorly, I think it's the biggest problem of the design - it only covers a narrow set of cases.

It will always be better to be able to just say "the following is a variable. whatever it contains, treat it as a value, and do not try to use parts of it as code and execute that code."

回复收藏 0 原文

以歌曲疗慰 2024-09-17 00:37:45

在 MySQL 中，如果 NO_BACKSLASH_ESCAPES 选项没有设置我相信这是可以做到的。

\'); DROP

或者类似的东西。您的代码将使 ' 加倍。第一个 ' 将通过反斜杠转义，第二个将关闭允许 SQL 注入的字符串。

为了安全起见，我通常更喜欢坚持准备好的陈述。

In MySQL if the NO_BACKSLASH_ESCAPES option is not set I believe it is possible to do.

\'); DROP

Or something similar. Your code will double the '. The first ' will be escaped by the backslash and the second will close the string allowing SQL injection.

I usually prefer to stick to prepared statements to be on the safe side.

回复收藏 0 原文

人事已非 2024-09-17 00:37:45

我最近向我兄弟介绍了准备语句。在他当前的项目中实现它后，他发现

他可以摆脱所有混乱的转义
他可以摆脱所有混乱的字符串连接
他的代码运行得更快。

为什么有人不使用prepare？

回复收藏 0 原文

美人如玉 2024-09-17 00:37:45

您可以尝试：

badInput = "\\'; drop records; --";

如果您的转义字符恰好设置为 '\'。

You might try:

badInput = "\\'; drop records; --";

in case your escape character happens to be set to '\'.

回复收藏 0 原文

旧人 2024-09-17 00:37:45

或许。取决于 replace 方法实际执行的操作，尤其是当它遇到 unicode 代理对或组合标记时 - 以及类似的数据库访问技术如何处理此类对。如果 replace 在字符级别工作，那么如果攻击者向您提供有效的高位代理，后跟单引号字符，您可能会用一对单引号替换该单引号 - 在效果，在稍后可能通过编码并被解释为无效代理对的内容后面附加单引号，留下裸露的单引号字符。

或许。

您是否足够了解该替换方法的 unicode 特征以及您的代码与数据库连接另一端的 SQL 执行引擎之间的每个中间字符串处理库？

你觉得幸运吗？

使用参数化查询。

回复收藏 0 原文

情栀口红 2024-09-17 00:37:45

我不是安全专家，但 char() 不会有效绕过您的安全措施吗？

例如：从记录表中获取所有内容

SELECT * FROM records WHERE col1 = char(39,97,39)

例 2：将信息写入不带单引号的文件

SELECT * FROM records WHERE col1 = concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39)) into outfile concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39))

来源：SQL注射备忘单

I'm not a security expert but won't char() effectively bypass your safety measures?

Eg: Getting everything from the records table

SELECT * FROM records WHERE col1 = char(39,97,39)

Eg 2: Writing info into files without single quotes

SELECT * FROM records WHERE col1 = concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39)) into outfile concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39))

Source here: SQL Injection Cheat Sheet

回复收藏 0 原文