Kur*_*isu 0 sql security sql-injection
我通常不会处理数据库(我为我和我的朋友写的网络应用程序管理了一些小的)所以在问我的问题之前,我将验证我是否理解了一切是如何工作的.
SQL是一个"做"数据库的程序.它管理所有表和方案以及链接,并且它响应于它接收的命令执行大多数操作.您可以手动输入这些命令,或者使用命令编写脚本,或让其他程序将这些命令发送到SQL,但命令并没有真正改变.
当Web应用程序从用户接收输入并将其发送到SQL而不先清除它时,就会发生SQL注入.如果最终用户已经足够了,那么SQL将会看到它应该看作是将数据存储在某个表中的数据的命令,从而产生了讽刺.
典型的SQL注入预防涉及清理用户输入,即删除任何会使SQL认为正在发送命令的字符,而不是数据.
现在,我的问题:
为什么SQL不为我们处理这个？为什么SQL,在每个命令上都没有查找第一个",最后一个",并忽略其中的任何一个？(我不认为)是标准SQL命令语法的一部分,它已经有一段时间了,但如果没有,可能会发生变化)当然,它会阻止你同时发送多个命令(因为第二/第三个命令会被忽略)但是在"我一次发送1个命令"规则上,这几乎是忽略最终用户可能试图拉的任何恶作剧.
我确信其他人已经想到了这一点,并将其视为因某种原因无法工作.但我不知道理解为什么,我想.
"SQL"不为我们处理它,因为"SQL"不是程序,它是一种语言:结构化查询语言.我们构建的与数据库接口的应用程序使用语言SQL作为从数据库中检索信息的手段.
我们构建的应用程序还使用某种API(应用程序程序员的接口)与数据库通信,并且API将SQL传递到数据库.(实际上是RDBMS或关系数据库管理系统,这是你可能会想到的"程序",如MySQL,Oracle,MS SQL Server或PostgreSQL)
如果API提供对预准备语句或存储过程执行的访问,则有一些更智能的API实际上可以自己处理参数清理.
当API不使用预准备语句或参数化查询(或开发人员选择不使用它们)而是直接构造SQL语言中的语句以传递给数据库时,会出现SQL注入的潜在问题.API在这个实例中的工作很简单:只需从应用程序中获取字符串并将其传递给数据库.因为SQL语句本身不需要输入(请记住,它只是一个字符串),它必须由开发人员来确保它不包含有害信息.
提供预准备语句或参数化查询的更复杂的API 确实需要输入并将输入值转换为SQL语句中的占位符,或者将信息本地传递给RDBMS以处理参数和预准备语句,或者在应用程序代码中模拟该操作,在将纯SQL字符串传递给RDBMS之前; 翻译的一部分通常涉及对有害人物的价值进行消毒.