《缺陷周话》第二期:SQL注入

代码审计是应用静态阐发发明源代码中安然缺陷的措施,能够帮助开拓或测试职员在软件上线前较为周全地懂得其安然问题,防患于未然,是以不停以来都是学术界和财产界钻研的热点,并且已经成为安然开拓生命周期 SDL 和 DevSecOps 等保障体系的紧张技巧手段。

360代码卫士团队基于自立研发的海内首款源代码安然检测商用对象,以及十余年破绽技巧钻研的积累,推出“缺陷周话”系列栏目。每周针对 CWE、OWASP 等标准中的一类缺陷,结合实例和对象应用进行具体先容,旨在为广大年夜开拓和安然职员供给代码审计的根基性标准化教程。

上一期给大年夜家懂得了空解指针的利用,本期继承带来SQL注入的先容。

一、SQL 注入

所谓 SQL 注入,便是经由过程将 SQL 敕令插入利用法度榜样的 http 哀求中,并在办事器端被接管后用于介入数据库操作,终极达到诈骗办事器履行恶意的 SQL 敕令的效果。理论上来讲,利用法度榜样中只如果与数据库稀有据交互的地方,无论是增编削查,假如数据完全受用户节制,而利用法度榜样又处置惩罚欠妥,那么这些地方都是可能存在 SQL 注入的。今朝险些所有的开拓说话如:JAVA、PHP、Python、ASP 等都可以应用SQL数据库来寄放数据,处置惩罚欠妥就可能导致SQL注入问题的发生。本篇文章以 JAVA 说话源代码为例,阐发 SQL 注入孕育发生的缘故原由以及修复措施。SQL 注入具体请见 CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)(http://cwe.mitre.org/data/definitions/89.html)。

二、SQL 注入的迫害

恶意进击者除了可以使用 SQL 注入破绽获取数据库中的信息(例如,治理员后台密码、站点的用户小我信息)之外,以致在数据库权限足够的环境下可以向办事器中写入一句话木马,从而获取 webshell 或进一步获取办事器系统权限。

2017年1月至2018年9月,CVE 中共有793条破绽信息与其相关。部分 CVE如下:

CVE-2018-13050

Zoho ManageEngineApplications Manager 13.x 中存在 SQL 注入破绽,经由过程 / j_security_check POST 哀求中的 j_username 参数可以注入sql语句。

CVE-2017-16542

Zoho ManageEngineApplications Manager 13 法度榜样可以经由过程manageApplications.do?method=insert 哀求中的 name 参数进行 SQL 注入。

CVE-2017-16849

Zoho ManageEngine Applications Manager 13容许经由过程 /MyPage.do?method=viewDashBoard 中的forpage 参数进行SQL注入。

CVE-2017-5570

在 eClinicalWorks Patient Portal 7.0 build 13 中发明MessageJson.jsp 中存在的盲注,然则只能由颠末身份验证的用户经由过程发送HTTP POST哀求来使用。并且恶意进击者可以经由过程该破绽应用诸如select_loadfile() 之类的措施将数据库数据转储到恶意办事器。

三、示例代码

3.1 缺陷代码

本章节中应用示例代码滥觞于Samate Juliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php),源文件名:CWE89_SQL_Injection__connect_tcp_execute_01.java。

在上述代码可以看到数据在 54 行被污染,在第 58 行中将污染数据通报给data,并未经任何安然处置惩罚就在第 115 行中直接用于 SQL 拼接,且介入数据库操作,从而导致 SQL 注入的孕育发生。

应用 360 代码卫士对上述示例代码进行检测,可以在文件第 115 行检出“SQL注入”缺陷,显示等级为高,同时,供给跟踪路径可以清晰阐发缺陷孕育发生的历程。如图1、图2所示:

图1SQL 注入检有缺陷的 source 点

图2SQL 注入检有缺陷的 sink 点

3.2 修复代码

在上述修复代码中的第 305 行,履行 SQL 时采纳的预编译,应用参数化的语句,用户的输入就被限定于一个参数傍边。经由过程图3可以看出,360代码卫士对修复后的代码并未检出。

图3SQL注入修复示例

4、若何避免SQL注入

[1] [2]下一页

常见的修复措施:

1. 应用预编译处置惩罚输入参数:要防御 SQL 注入,用户的输入就不能直接嵌套在 SQL 语句傍边。应用参数化的语句,用户的输入就被限定于一个参数傍边。如下所示:

2. 输入验证:反省用户输入的合法性,以确保输入的内容为正常的数据。数据反省该当在客户端和办事器端都履行,之以是要履行办事器端验证,是由于客户真个校验每每只是减轻办事器的压力和前进对用户的友好度,进击者完全有可能经由过程抓包改动参数或者是得到网页的源代码后,改动验证合法性的脚本(或者直接删除脚本),然后将不法内容经由过程改动后的表单提交给办事器等等手段绕过客户真个校验。是以,要包管验证操作确凿已经履行,独一的法子便是在办事器端也履行验证。然则这些措施很轻易呈现因为过滤不严导致恶意进击者可能绕过这些过滤的征象,必要慎重应用。

3. 差错消息处置惩罚:警备 SQL 注入,还要避免呈现一些具体的差错消息,恶意进击者每每会使用这些报错信息来判断后台 SQL 的拼接形式,以致是直接使用这些报错注入将数据库中的数据经由过程报错信息显示出来。

4.加密处置惩罚:将用户登录名称、密码等数据加密保存。加密用户输入的数据,然后再将它与数据库中保存的数据对照,这相称于对用户输入的数据进行了“消毒”处置惩罚,用户输入的数据不再对数据库有任何特殊的意义,从而也就防止了进击者注入 SQL 敕令。

上一页[1] [2]

赞(0) 打赏
分享到: 更多 (0)
免责申明:本站所有资料均来自于网络,版权归原创者所有!本站不提供任何保证,不保证真实性,并不承担任何法律责任

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

阿里云优惠网 更专业 更优惠

阿里云优惠券阿里云大礼包