记一次SRC实战-SQL注入

什么是SQL注入漏洞

说直白点，就是前端输入字段，后端会运行SQL语句返回数据。数据库大都是支持SQL语言的，SQL语言本身是有预留关键字的，比如常用的select、update、delete等。
故意输入非正常的SQL查询语句，由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，没有执行相关验证，用户可以提交一段非法的数据库查询语句，根据程序返回的结果，获得某些他想得知的数据，轻者程序错误，代码泄露，重者直接暴库，甚至危及服务器整体安全，这就是SQL注入攻击。SQL注入本质上是一种用户输入式攻击，是程序没有对用户输入进行充分验证留下的漏洞。

很简单的一个数据库查询语句：select * from user where userid=11
用户只需要正常输入自己的用户名11，就可以获取到自己的有关信息。

那如果说程序员在设计程序的时候，没有对用户输入的字段进行过滤，产生SQL注入漏洞，那么就可以构造sql语句非法获取到全部数据库数据，甚至爆库，获取用户名和密码。
这里构造：or 1=1
select * from user where userid=11 or 1=1
就可以获取到数据表中的所有数据

防御SQL注入攻击

将常用的SQL注入字符写入到黑名单中，然后通过程序对用户提交的POST、GET请求以及请求中的各个字段都进行过滤检查，筛选威胁字符。
由于SQL注入过程中需要构造较长的SQL语句，因此，一些特定的程序可以使用限制用户提交的请求内容的长度来达到防御SQL注入的目的，但这种效果不太好。
对一些请求内容相对固定的程序，可以制定请求内容的白名单，比如：某程序接受的请求只有数字，且数字为1-100，这样可以检查程序接受的请求内容是否匹配，如果不匹配，则认为是非法请求。
根据程序要求为特定的表设置特定的权限，如：某段程序对某表只需具备select权限即可，这样即使程序存在问题，恶意用户也无法对表进行update或insert等写入操作。

实战SRC

鄙人不才，在无数个日夜中，Google漫游了无数天，终于找到了一个SQL注入的漏洞。

这里用到的工具有：Google、burp、sqlmap。

寻找可能存在的注入点，使用Google搜索：inurl:.php?id=1
找到一个网址，url后缀为?id=7，猜测可能存在SQL注入。
先使用1’ and 1=1测试，界面没有明显的变化
然后构造参数?id=1’ order by 8–+
使用burp抓一下包，发现返回的数据包发生了变化


这里就有点激动了，然后直接丢掉sqlmap中，成功爆出数据库。

随后就提交到漏洞盒子，一个中危漏洞，可能没有涉及到核心数据吧。
像这种可以放到sqlmap直接跑的注入漏洞已经可以说是弹尽粮绝了，少之又少，我也是找了好几天才找到这么一个，还是一个很古老的站点。