这种消毒不安全吗?它是否容易受到 SQL 注入的攻击? [英] Is this sanitization unsafe? Is it vulnerable to SQL Injection?
问题描述
Function RemoveSuspeitos(ByVal strTXT)
Dim txtAux As String
txtAux = strTXT
txtAux = Replace(txtAux, chr(34), "")
txtAux = Replace(txtAux, "'", "")
RemoveSuspeitos = txtAux
End Function
数据库:MSSQL
1) 忘记上面代码中的语法错误，我不是 VB 专家.
1) Forget syntax errors in the above code, I am not expert in VB.
2) 假设我总是使用单引号或双引号，即使对于 int 值也是如此(例如:'" + $int_id + "').
2) Lets say I always use single or double quotes, even for int values (e.g.: '" + $int_id + "').
这种消毒不安全吗?如果是，为什么?请给我看一个真实的漏洞利用场景.
Is this sanitization unsafe? If yes, why? Please show me a real exploit scenario.
推荐答案
这是我的尝试.
漏洞的问题在于它们不像大多数用户认为的那样直接.
实际上，生产代码的增长与人工的、完全受控的示例略有不同.
In reality, production code grows slightly different from the artificial, totally controlled example.
因此，这里出现的不是技术漏洞，而是方法漏洞.去年我花了很多精力研究这个问题，以下是我的结论
So, here not technological, but methodological vulnerabilities are coming into the scene. I made a vast effort researching this matter last year, and here are my conclusions
让我们从一个比喻开始:
Let's start from a metaphor:
人们必须始终使用安全带.没有例外.是的，你总是可以说你开车很安全，不可能发生事故.但是，不幸的是，统计数据对您不利.还有其他人参与了交通.有突然的障碍.有不可预见的破损.这就是为什么您应该始终系好安全带的原因.保护代码完全一样.
One have to always use a seat belt. No exceptions. Yes, you can always say that you drive so safely that no crash ever be possible. But, unfortunately, statistics is against you. There are other people involved in the traffic. There are sudden obstacles. There are unforeseen breakages. That's why you should always wear a seat belt. Exactly the same thing with protecting your code.
这里让我发布一段我的研究的摘录:
Here let me post an excerpt from my research:
因为它是手动的.手动 == 容易出错.这要看程序员的功力、脾气、心情、昨晚喝了多少啤酒等等.事实上，手动格式化是世界上大多数注入案例的唯一原因.为什么?
Because it's manual. Manual == error prone. It depends on the programmer's skill, temper, mood, number of beers last night and so on. As a matter of fact, manual formatting is the very and the only reason for the most injection cases in the world. Why?
手动格式化可能不完整.
让我们以 Bobby Tables 的案例为例.这是一个不完整格式的完美例子:我们添加到查询中的字符串被引用但没有转义！虽然我们刚刚从上面了解到引用和转义应该始终一起应用(以及为转义函数设置正确的编码).但是在单独进行 SQL 字符串格式化的普通 PHP 应用程序中(部分在查询中，部分在其他地方)，很可能某些部分格式化可能被简单地忽略了.
Manual formatting can be incomplete.
Let's take Bobby Tables' case. It's a perfect example of incomplete formatting: string we added to the query were quoted but not escaped! While we just learned from the above that quoting and escaping should be always applied together (along with setting the proper encoding for the escaping function). But in a usual PHP application which does SQL string formatting separately (partly in the query and partly somewhere else), it is very likely that some part of formatting may be simple overlooked.
手动格式化可以应用于错误的文字.
只要我们使用完整格式，这没什么大不了的(因为它会导致可以在开发阶段修复的即时错误)，但结合不完整的格式，这是一场真正的灾难.Stack Overflow 的伟大站点上有数百个答案，建议以与字符串相同的方式转义标识符.这是完全没用的，直接导致注射.
Manual formatting can be applied to wrong literal.
Not a big deal as long as we are using complete formatting (as it will cause immediate error which can be fixed at development phase), but combined with incomplete formatting it's a real disaster. There are hundreds of answers on the great site of Stack Overflow, suggesting to escape identifiers the same way as strings. Which is totally useless and leads straight to injection.
手动格式化本质上是非强制性措施.
首先，存在明显缺乏注意的情况，在这种情况下，可以简单地忘记正确的格式.但是有一个非常奇怪的情况——许多 PHP 用户经常故意拒绝应用任何格式，因为直到今天他们仍然将数据分为干净"和不干净"、用户输入"和非用户输入"等意味着安全"数据不需要格式化.这简直是胡说八道——记住莎拉·奥哈拉(Sarah O'Hara).从格式的角度来看，目的地很重要.开发人员必须注意SQL 文字的类型，而不是数据源.这个字符串会进入查询吗?然后必须格式化.不管是来自用户输入还是只是在代码执行过程中神秘地出现.
Manual formatting is essentially non-obligatory measure.
First of all, there is obvious lack of attention case, where proper formatting can be simply forgotten. But there is a real weird case - many PHP users often intentionally refuse to apply any formatting, because up to this day they still separating data to "clean" and "unclean", "user input" and "non-user input", etc. Means "safe" data don't require formatting. Which is a plain nonsense - remember Sarah O'Hara. From the formatting point of view, it is destination that matters. A developer have to mind the type of SQL literal, not the data source. Is this string going to the query? It have to be formatted then. No matter, if it is from user input or just mysteriously appeared amidst the code execution.
手动格式化可能与实际查询执行相距很远.
最被低估和忽视的问题.但最重要的是，如果不遵守，仅此一项就会破坏所有其他规则.
几乎每个 PHP 用户都想在远离实际查询执行的地方完成所有清理"工作，而这种错误的做法是无数错误的根源:
Most underestimated and overlooked issue. Yet most essential of them all, as it alone can spoil all the other rules, if not followed.
Almost every PHP user is tempted to do all the "sanitization" in one place, far away from the actual query execution, and this false approach is a source of innumerable faults:
- 首先，由于手头没有查询，我们无法判断这条特定数据将代表什么样的 SQL 文字——因此同时违反了格式规则 (1) 和 (2).
- 有不止一个地方进行消毒，我们呼吁灾难，因为一个开发人员会认为它是由另一个人完成的，或者已经在其他地方完成，等等.
- 有多个地方进行清理，我们引入了另一种危险，即双重清理数据(例如，一个开发人员在入口点对其进行了格式化，另一个在查询执行之前对其进行了格式化)
- 过早的格式化很可能会破坏源变量，使其无法在其他任何地方使用.
<小时>
如您所见，如果您总是将值放在引号中，则前两项可能被视为不适用.但是最后两个来了.总是"这个词太自以为是了.我们是人，我们都会犯错.您不仅是从事该项目的人.即使您个人做的一切都是正确的，其他用户也可能不会与您一样信任.比如说，他们中的一些人可能有一种普遍的错觉，好像只有用户输入必须被消毒"——因此暴露在二阶注入的危险中.
As you can see, first two items can be considered inapplicable if, as you say, you're always putting your values in quotes. But here come last two. "Always" is too presuming a word. We are humans and we all make mistakes. You are not only one who is working on the project. And even if you personally doing everything right, other users may not share your confidence. Say, some of them may share a widespread delusion as though only user input have to be "sanitized" - and thus expose to the danger of second order injection.
这就是为什么应该有一个机制，如果严格遵守，可以保证 100% 安全，无论开发者是否理解.对查询中的每个动态文字使用占位符就是这样一种机制.
This is why there ought to be mechanism that may guarantee 100% safety if strictly followed, no matter if developer understands it or not. And using placeholders for the EVERY dynamical literal in the query IS such a mechanism.
这篇关于这种消毒不安全吗?它是否容易受到 SQL 注入的攻击?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
