为什么对SQL注入的防护不是高优先级?


39

在Stack Overflow上,尽管基本解决方法已广泛使用了十多年,但我在问答中看到许多PHP代码都具有极易受到SQL注入攻击的MySQL查询。

为何今天仍在使用这些类型的代码片段?


37
归咎于写得不好的在线教程。人们经常会复制并粘贴他们在网上找到的所有代码。JavaScript也是这种做法的另一个受害者。
KJYe.Name 2011年

34
责怪博客。哦,还有W3Schools ...
Brian Driscoll

13
是的,绝对W3Schools的-见w3fools.com
DisgruntledGoat

2
我经常看到有人警告有关sql注入-所以我什至不认为这个问题的前提是正确的。这高度优先的。
GrandmasterB

3
我在很多答案中看到的是,教严重破损的PHP比教严重破损的PHP更容易。您不能接受该论点,而仍然声称PHP不是一种不好的语言
user16764 2012年

Answers:


34

我认为这主要是由于a)无知b)懒惰。初学者通常对sql注入了解不多,即使他们听说了sql注入,也还是会忽略它,因为这样编码起来非常简单。


8
我试图在其他地方纠正这种情况,只是被告知这与眼前的问题无关。因此,由于许多人更喜欢简单的技巧,而不是稍微复杂的好的解决方案,因此,不好的例子就不多了。
l0b0 2011年

6
大多数人直到真正被SQL注入时才真正关心它。然后突然,他们想知道桌子在哪里。
乔尔·埃瑟顿

1
另一个原因是,SQL注入并不总是被视为内部应用程序的相关问题。(并不是说他们是对的。)
约翰·费希尔

1
不要忘记答案在那里可以回答问题。通常,伪代码(或SQL)用于回答问题,不一定提供安全可靠的复制和粘贴解决方案(尽管实际上如何使用答案)。
大林·塞维赖特2011年

1
@ l0b0我知道有人通过实际演示针对当前生产代码的SQL注入攻击来使人们认真对待SQL注入修复。
user16764

26

PHP故意使很少了解的人可以非常轻松地创建有用的动态网页。这意味着PHP将吸引许多初学者,他们创建有用的东西,从其他有用的例子中学习,并转而教其他人如何做这个很酷的有用的东西。结果是很多错误的代码,以及大量不了解的程序员。

更糟糕的是,大部分合格的程序员都不愿与PHP无关。这减少了愿意教别人的有经验的人的基础。但是为什么他们避免使用PHP?结合多种因素。在某种程度上,他们不喜欢与语言疣打交道。部分原因是因为他们更喜欢使用良好的代码,并且那里没有很多优质的PHP。

问题的确切位置曾经造成Perl。作为一个光辉的例子,以马特·怀特(Matt Wright)为例,他是一个热情的少年,他在1990年代开始提供许多有用的,有据可查且易于安装的CGI脚本。不幸的是,他对安全一无所知,而想要使用他的东西的人也一无所知。结果就是Matt Wright脚本档案,对于早期的CGI脚本,这是无休止的安全问题源。尽管进行了http://www.scriptarchive.com/nms.html之类的工作,但直到共享托管提供商使PHP比其他任何方式都方便之前,Perl的问题才得以改善。这导致了从Perl到PHP的问题。


就像您说的那样,问题不在于perl或PHP,其原因在于这些语言使初学者​​可以做很多事情,这很好,但并不总是提供明显的好方法。
Zachary K

2
@ZacharyK:那不是默认语言的错吗?
与莫妮卡(Monica)进行的Lightness竞赛,

6
@ tomalak-geretkal:您使用“故障”一词似乎使事情得以完成是一件坏事。导致大量错误代码的相同特征也导致解决了许多实际问题。目前尚不清楚这整体上是不好的事情。
btilly 2011年

再说“故障”:如果HTML(或更确切地说,是解释它的浏览器)具有与XSL一样的容错能力,那么永远不会有万维网……
Benjol 2011年

8

不幸的是,那里有成千上万比糟糕的PHP教程,还有一些旧的PHP书也吸引了人们告诉人们编写正确的代码(不使用register_globals等)。

另外,magic_quotes_gpc由于过去启用了该功能,因此人们并不关心转义,因为“它确实起作用”。



2

作为人类和程序员,我发现犯错,忽略某些事情非常容易,尤其是在时间紧迫时。

责怪某种语言很容易,也许太诱人了,因为它本身就太容易使用了。但这将掩盖更大的人类易失性问题,而不管选择使用哪种编程语言。

诚然,自汇编语言以来,我们已经走了很长一段路,我想我会以更现代的语言(例如PHP,Python,Ruby或Java)提高生产力。

实际上,PHP(和其他脚本语言)降低了进入门槛。这可能意味着更多的编程新手将首先尝试PHP。但这当然也不意味着与其他语言的程序员相比,所有PHP程序员在某种程度上都没有资格,或者从错误中学习的能力较低。

Rasmus Lerdorf于1994年以原始形式创建了PHP,此后便有了长足的发展。以其最现代的形式,它支持面向对象的编程以及一流的框架,例如Symfony。PHP作为一种语言已摆脱了其最初的限制,并已发展为在程序员选择使用它的方式方面提供了极大的灵活性。您可以使用它来创建9,000行意大利面条代码的脚本,也可以在现代的MVC框架(例如Symfony)的上下文中使用它:这是您的选择!

我强烈怀疑安全漏洞不仅限于一种语言。诱使所有PHP程序员注销,因为他们的能力稍差,或者更倾向于编写不安全的代码。但是我想知道其中有多少是语言偏见,有多少是事实?


我没有说“所有PHP程序员”。
与莫妮卡(Monica)

2

我认为问题的一部分在于人们只是简单地复制代码而又不费心去学习他们在做什么,但是在我看来,我们教授porgamnming的方式被打破了,这真的是原因,这就是为什么存在如此多不良代码的原因之一。我们在上下文之外教授语法,因此初学者不知道何时使用某些内容,何时不使用某些内容,语法打算解决哪些问题以及不打算解决哪些问题。因此,当扳手会是更好的工具时,他们会使用锤子。

因此,例如,您可以像这样组织课程,而不是仅仅讲语法(显然会有更多步骤,这只是从基本问题到更复杂问题的构建的基本示例,而不仅仅是讲语法):

  1. 这是您设置基本网页的方式
  2. 这是使网页从数据库中提取数据的方式
  3. 这是您将数据从网页发送到数据库的方式
  4. 这样可以确保发送正确的数据。
  5. 这是保护数据库免受恶意数据输入的方式

这或多或少我TEACHED PHP +1的方式
雷米

1

我认为您会发现类似数量的MS SQL + ASP / ASP.NET示例,它们同样容易受到攻击。

我觉得问题部分源于以下事实:当您尝试教一些东西时,例如使用WHERE子句过滤数据,那么您真的不想通过适当地转义查询字符串或使用参数化命令来使示例混乱。

我已经培训开发人员很多年了,我可以同情那些在教程中编写可怕代码的人。有时这是最容易理解的。但是,顺便说一句,我总是指出易受攻击的代码,并将其变成一个有趣的附带主题。


6
那不应该放在一边。这应该是基本课程的一部分。可能会发出大而胖的警告,提示错误的做事方式。人们倾向于剪切和粘贴他们最初看到的内容,而您确实希望这是做事的正确方法。
btilly 2011年

当然,在.NET世界中,如今参数化非常简单,确实应该是“一页”的工作。
艾伦B

1

PHP的原始作者Rasmus Lerdorf在其臭名昭著的博客文章中倡导“无框架”开发。尽管对于SQL查询,他使用PDO,所以不存在SQL注入的风险。与具有ORM层的现代MVC框架相比,它仍然非常丑陋和过时。


5
当然,可以使用您不需要的复杂框架来过度设计站点。我想说拉斯穆斯的建议接近危险的刑事罪行,但绝对有理智的中间立场。
与莫妮卡(Monica)进行的Lightness竞赛,

如今,使用ORM并不会过度设计。这是标准的。使用MVC模式也是如此。
vartec

3
@vartec:这几乎不是“标准的”,只是因为所有的绵羊都在使用它(而且就其价值而言,甚至不是所有的绵羊都在使用它)。对于小型脚本,它很容易过度设计。
与莫妮卡(Monica)进行的Lightness竞赛,

1
@Tomalak:它是标准的,因为这是实施清洁和可持续项目的方式。随着时间的流逝,“小脚本”趋于增长,并变得难以维持。
vartec'3

2
@vartec:我认为您误解了“标准”的含义。
与莫妮卡(Monica)进行的轻量级比赛,

1

您可以将这种不良做法归咎于PHP本身。旧版PHP(直到2006年左右)将转义所有GET和POST输入变量,以便它们适合按DEFAULT进行数据库查询插值。参见http://php.net/manual/en/security.magicquotes.php


2
曾经有一段时间它会将所有变量都转义,就好像它们是否专门进入MySQL一样,无论是否曾经。语言设计师注意:当您发现自己必须执行时stripslashes(),您已经做错了。
丹·雷

0

不要混淆教程的目的,它只是为了简单地演示一些东西,以及在生产环境中应该做的事情。例如,我编写的大多数教程代码几乎没有错误/异常检查。我试图提醒读者,该代码仅演示如何执行特定任务,而不演示如何涵盖所有可能的结果。


3
抱歉,但是绝对没有示例代码应该将mySQL查询与PHP混合使用。那只是做错了。
雷诺斯2011年

1
而且是不负责任的。
与Monica进行的Lightness竞赛,

-1表示most tutorial code I have written has little or no error/exception checking.
yannis 2011年

我可以看到OP的观点。不负责任的是,当雇主雇用一个不了解SQL注入等知识的人时。
拉斐尔

我认为,如果您在代码中直接包含“不要在生产中使用此代码!”的注释,则这种方法是合理的。这样,复制/粘贴没有任何借口。
Benjol 2011年

-1

当我学习PHP时,我看了一些这些PHP + MySQL书籍,是的,我觉得它助长了这种不良做法。但是我很同情,因为他们在教语言,而不是好的编程习惯。否则它将在哪里结束?


2
但是,在讲授该语言时,仍应在示例中使用首选的API。像往常一样使用参数化形式的SQL查询,可能会带有一个脚注,例如“永远不要考虑使用插值来构建SQL。这似乎更容易一些,但极容易出现安全漏洞。”
1

是的,好点。脚注会很好地提醒您,在线教程也是如此。严格地说,如果所有语言的书籍作者都可以将OWASP的建议纳入初学者文本,那将是很好的。甚至只是作为参考。OWASP基金会做得很好。
Steve Rathbone

@indifferentDrum:您也可以教人们用脚驾驶-并不意味着这是一个好主意。
与莫妮卡(Monica)进行的轻度比赛2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.