SQL注入实践 --程序猿的安全之路
Posted 点融黑帮
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了SQL注入实践 --程序猿的安全之路相关的知识,希望对你有一定的参考价值。
开篇:SQL注入介绍
“SQL攻击(SQL injection),是发生于应用程序至数据库层的安全漏洞。简而言之,是在输入的字符串之中注入SQL指令,在设计不良的程序当中忽略了检查,那么这些注入进去的指令就会被数据库服务器误认为是正常的SQL指令而运行,因此遭到破坏或是入侵。”
——维基百科
SQL注入的危害:
l 非法读取、篡改、添加、删除数据库中的数据;
l 盗取用户的各类敏感信息,获取利益;
l 通过修改数据库来修改网页上的内容;
SQL注入种类:
l 布尔注入;
通过判断页面返回情况获得想要的信息。
l 报错注入;
如果页面能够输出SQL报错信息,则可以从报错信息中获得想要的信息。
l 联合查询注入;
最快捷的方法,通过UNION查询获取到所有想要的数据,前提是请求返回后能输出SQL执行后,查询到的所有内容。
SQL注入已经是老生常谈的话题了,很多框架在设计之初已经考虑到这个问题,像hibernate、mybatis采用预编译机制,有效避免SQL注入。所以是不是就不需要研究SQL注入了呢,答复是否定的。
某前著名漏洞平台网站统计,现实网络中有很多网站存在SQL注入漏洞,笔者通过亲身实践带大家窥视这个行业。扶好把手,开始我们的SQL注入之旅。
正文:尝试攻击
踩点
现在SQL注入的漏洞没那么好找,一般利用浏览器的语法搜索,如"inurl.php?id=",下面三种类型的截图界面就是通过这个方法找到的。
布尔型注入
输入and 1=1
输入 and 1=2
可以看到页面不一致了,说明存在漏洞。
报错型注入
尝试在id=3后面输入order by 数字试出网页字段数,原理:当order by的数字大于表的字段总数时,会报错.试出的字段是为了方便后续使用union替换出数据库里的其他信息。
order by 36 显示的就是正常页面,说明这张表有36个字段。哇哈哈!!!
联合查询注入
尝试用union select1,2,3,4,5,6,7,8,9,10,11,12,13,database(),version(),user()获取数据库,版本及用户的时候,很不幸没能成功,尝试了其他绕过方法均没成功。
2. SQL注入
其实手工注入的效率还是比较低的,网上有很多工具可以大大增加效率,今天要介绍的是kali的sqlmap。sqlmap是一个开放源码的渗透工具,支持现在几乎所有的数据库。
下载安装步骤就不介绍了,此处省略5000字。
找到可疑站点后,sqlmap提供很多命令做进一步分析。
使用--dbs 暴出mysql和database name
通过--dbs命令查到了数据库下面有哪些库,接着通过-D “库名”--tables,暴出库里的表
查到表后,-D “库名” --columns暴出所有表中的列名
接下来就可以为所欲为了,-D “数据库名”–users暴出user,-D “数据库名”--dump –T “表名”暴出表内容。
sqlmap还有一些未使用到的命令,–level,–risk,–string,–not,-string,–regexp,–code,感兴趣的可以网上搜一搜。
结尾:SQL注入防范
sql注入对企业的危害特别大,尤其是对像点融所在的金融行业,作为一名程序猿心中得时刻有安全观念。防范意识不可少。
1.永远不要信任用户的输入。对用户的输入进行校验,可以通过正则表达式,或限制长度。
2.永远不要使用动态拼装sql,可以使用参数化的sql或者直接使用存储过程进行数据查询存取(通过预编译把sql注入掐死在摇篮中,java中mybatis主动防御了sql注入,通过#{param},如果使用${param}将有sql注入风险)。
3.永远不要使用管理员权限的数据库连接,为每个应用使用单独的权限有限的数据库连接。
4.不要把机密信息直接存放,加密或者hash掉密码和敏感的信息。
5.应用的异常信息应该给出尽可能少的提示,最好使用自定义的错误信息对原始错误信息进行包装。
以上是关于SQL注入实践 --程序猿的安全之路的主要内容,如果未能解决你的问题,请参考以下文章
SQLite-lab:基于SQLite设计的SQL注入实践靶场