SQL注入或SQLi漏洞指的是攻击者可以修改从Web应用发送到数据库的SQL语句。今天，南昌网络公司小编就来为大家介绍一下Web 应用中常规SQL注入检测方法。

首先要说的是SQL注入攻击可以根据bug的不同分为不同类别。通常来说，可以按照HTTP响应返回的数据种类来区分注入。如果返回的是类似下面这样的SQL错误，就可以实施基于错误的SQLi：

You have an error in your SQL syntax; check the

manual that corresponds to your MySQL server version

for the right syntax to use near ''' at line 1

某些情况下，即使SQL语句中包含错误，Web应用也根本不会返回错误。这种类型的SQLi通常叫作Blind SQLi，因为从数据库或应用得不到任何错误。

此时，通过对比正常请求和恶意请求的HTTP响应之间的区别，也可以检测到SQLi是否会影响某些资源。前述区别可以分为两种。一种是内容长度不同，也就是返回的响应体的内容不同。另一种是响应时间不同，比如常规响应时间是1秒，而恶意响应却需要5秒。下面来看一段Ruby代码，这段代码是可以被SQL注入的：

get "/" do

@config = ConfigReader.instance.config

# 从GET请求中取得book_id参数

book_id = params[:book_id]

# MySQL连接池

pool = Mysql2::Client.new(

:host => @config['db_host'],

:username => @config['restricted_db_user'],

:password => @config['restricted_db_userpasswd'],

:database => @config['db_name']

)

begin

if book_id == nil

@rs = pool.query "SELECT * FROM books;"

else

# 若找到一个特定的book_id参数

# 就执行以下未加密查询

query = "SELECT * FROM books WHERE id=" + book_id + ";"

@rs = pool.query query

end

erb :"sqlinjection"

rescue Exception => e

@rs = {}

@error_message = e.message

erb :"sqlinjection"

end

end

如果将一个类似/page?book_id=1'的GET请求发送给这段代码中的处理程序，那么数据库就会返回类似前面的错误信息。只要发送像下面这样检索MySQL数据库版本的查询，就可以利用这种基于错误的SQLi：

/page?book_id=1+UNION+ALL+SELECT+NULL%2C%40%40VERSION%2CNULL%23

最终的SQL语句会被攻击者在SELECT * FROM books WHERE id=1后面追加上UNION ALL SELECT NULL, @@VERSION, NULL。Web应用的那个拼接的查询(query = "SELECT * FROM books WHERE id=" + book_id + ";")之所以不安全，是因为参数值book_id未经输入验证就被用于字符串拼接。这种[没有预处理语句(Prepared Statements)18]的查询结果，会使应用面临SQL注入的风险。

再考虑一种情况。假设前面存在漏洞的代码除了把底部的一行(@error_message = e.message)删除之外，其余都相同，那么此时仍然可以被SQL注入攻击，只不过变成了Blind。

假设你事先并不知道这一点，而想要检测某个资源是否可以实施SQLi。可以发送下面这个GET请求：

/page?book_id=1+AND+SLEEP(5)

然后，经过大约5秒钟，你才会收到HTTP响应。这么长的响应时间意味着该资源存在SQL注入漏洞，因为SLEEP语句被成功执行了。

以上内容便是南昌网络公司小编为大家介绍的关于SQL注入的检测方法，这些只是比较浅显的SQL注入检测，想进一步了解这方面知识的朋友，欢迎关注本公司官网动态，更多技术性文章与您来分享。此外，如有需要关于南昌网站建设、微信开发、手机APP开发等方面的服务，百恒网络随时为您效劳!