当web应用向后台数据库传递SQL语句进行数据库操作时。如果对用户输入的参数没有经过严格的过滤处理,那么攻击者就可以构造特殊的SQL语句,直接输入数据库引擎执行,获取或修改数据库中的数据。
SQL注入网上的讲解很多,我认为的SQL注入其实就是可以人为的控制代码与数据库进行交互的地方,对参数进行修改并执行恶意代码来达到控制数据库的目的。
在所有的代码与数据库进行交互的地方都有可能出现SQL注入,如(登录,注册,查询,读取新闻页面,等等等等)
sql注入不一定都在 ?id=1 这种参数后面出现,有时候也会在类似于读取新闻页面出现sql注入如: http://127.0.0.1/index/goods/goods/pid/29/token/123123123123.html 这种读取数据库信息的时候在 29 那里也会出现sql注入。所以有时候在测sql注入的时候尽量不要盲目的只是在?参数后面测试。
获取后台账号密码,获取用户信息,获取mysql账号密码(有时候可能没有),读写文件(读写函数开启的情况)
猜解后台数据库:这是利用最多的方式,盗取网站的敏感信息。
绕过认证:例如绕过验证登陆网站后台。
后台登录语句:SELECT * FROM admin WHERE Username='user' and Password='pass' (万能密码绕过:'or '1'='1)#
注入可以借助数据库的存储过程进行提权等操作
种马(如一句话木马)、dos
一般我都会在参数后面加如下字符: ’ " / ( ) ; 如果出现报错的话根据报错信息来判断此处是否存在SQL注入
如果没有报错可以使用盲注来进行判断,但是一般都有限制进行一些语句绕过就好了如: 1 select sleep(10) --+ 页面延迟10秒左右的话就存在
判断需不需要加单引号或者双引号可以使用:?id=3-2 如果返回页面跟输入1是一样的则不需要加引号。不一样则需要
1、SQL注入点探测。
2、收集后台数据库信息。
3、猜解用户名和密码。
4、查找Web后台管理入口。
5、入侵和破坏。
过滤输入内容就是在数据提交到数据库之前,就把用户输入中的**不合法字符剔除掉。**可以使用编程语言提供的处理函数或自己的处理函数来进行过滤,还可以使用正则表达式匹配安全的字符串。
如果值属于特定的类型或有具体的格式,那么在拼接 SQL 语句之前就要进行校验,验证其有效性。比如对于某个传入的值,如果可以确定是整型,则要判断它是否为整型,在浏览器端(客户端)和服务器端都需要进行验证。
**参数化查询目前被视作是预防 SQL 注入攻击最有效的方法。**参数化查询是指在设计与数据库连接并访问数据时,在需要填入数值或数据的地方,使用参数(Parameter)来给值。
MySQL 的参数格式是以“?”字符加上参数名称而成,如下所示:
UPDATE myTable SET c1 = ?c1, c2 = ?c2, c3 = ?c3 WHERE c4 = ?c4
在使用参数化查询的情况下,数据库服务器不会将参数的内容视为 SQL 语句的一部分来进行处理,而是在数据库完成 SQL 语句的编译之后,才套用参数运行。因此就算参数中含有破坏性的指令,也不会被数据库所运行。
除了开发规范,还需要合适的工具来确保代码的安全。我们应该在开发过程中应对代码进行审查,在测试环节使用工具进行扫描,上线后定期扫描安全漏洞。通过多个环节的检查,一般是可以避免 SQL 注入的。
有些人认为存储过程可以避免 SQL 注入,存储过程在传统行业里用得比较多,对于权限的控制是有一定用处的,但如果存储过程用到了动态查询,拼接 SQL,一样会存在安全隐患。
下面是在开发过程中可以避免 SQL 注入的一些方法。
避免将用户的输入数据直接放入 SQL 语句中,最好使用准备好的语句和参数化查询,这样更安全。
加密存储在数据库中的私有/机密数据,这样可以提供了另一级保护,以防攻击者成功地排出敏感数据。
将数据库用户的功能设置为最低要求;这将限制攻击者在设法获取访问权限时可以执行的操作。
攻击者可以使用这些错误消息来获取有关数据库的信息。
一些编程框架对于写出更安全的代码也有一定的帮助,因为它提供了一些处理字符串的函数和使用查询参数的方法。但同样,你仍然可以编写出不安全的 SQL 语句。所以归根到底,我们需要有良好的编码规范,并能充分利用参数化查询、字符串处理和参数校验等多种办法来保护数据库和程序的安全。