在南昌网站建设中，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注入检测。如果你觉得这些内容不好理解，随时可以来电咨询百恒网络，本公司专业从事南昌网站建设、微信开发、手机APP开发等服务，经验丰富，实力强，南昌做网站，就选百恒网络！
