如何评估和使用Web应用程序安全测试工具？
“XXX不玩消消乐”通过精心收集，向本站投稿了6篇如何评估和使用Web应用程序安全测试工具？，这次小编给大家整理后的如何评估和使用Web应用程序安全测试工具？，供大家阅读参考。
篇1：如何评估和使用Web应用程序安全测试工具？
前些日子的安全事件大多与Web应用程序密切相关，许多单位和个人也由此看到了采取必要措施防护Web应用程序安全的重要性，笔者觉得有必要在采取防范措施之前先对自己的系统进行一次严格的渗透测试。因为一些专业的应用程序渗透测试工具和服务有助于防止自己的网站变成 和恶意软件的桥头堡。
有人认为单位的网站有了Web防火墙的保护就不需要其它保护措施了。这是错误的，因为最近的攻击以及将来的攻击将越来越依赖存在于Web应用程序中的缺陷，这些缺陷通常都包含着易于被利用的漏洞。据有关数据统计显示，如今多数支持外部访问的应用程序都是基于Web的，而其中的多数又都包含着可被利用的漏洞。
所以，在将Web应用程序推向实际使用之前，最好先借助Web应用程序渗透工具测试一下。目前，这类工具多数都可以执行Web应用程序的自动扫描，它们可以实施一些威胁模式测试，从而揭示一些常见的漏洞，例如许多程序可以揭示Sql注入式攻击漏洞、跨站脚本攻击等。有时，这些工具还可以提供一些参数供用户修正所发现的漏洞。
用户需要在攻击者实施破坏之前先对自己“狠”一点。当今的Web 渗透测试已经被多数机构看作是一个保障Web应用程序安全的关键步骤,这种安全测试已经成为机构风险管理的至关重要的部分。否则，单位就是将这种“测试”拱手交给了 。
而如今的安全测试市场并没有绝对的标准，所以有必要探讨一些评估和使用这些工具的服务和方法。(本文所涉及的Web应用程序渗透测试工具也指Web应用程序扫描工具)
三个要素
1、使用者：
由于其复杂性，将保障Web应用程序的安全性的责任分配给适当的人员并不是一件简单的事情。对开发人员和咨询人员来讲，这可谓是一个新的概念。安全管理成员也许更熟悉网络问题，而不是应用程序问题。那么，谁来做这件事情呢？笔者认为，由安全专家们实施测试，然后将结果交给开发人员的做法并不明智，甚至难以实施。不过，这正是目前许多公司正在使用的方法，至少在开发人员乐意使用这种工具之前是这样的。
如有的信息安全专家就承担了Web应用程序安全的责任，他们相信维护和保障企业网络安全最终是他们的责任，所以不必由应用程序的开发人员解决漏洞问题。如果开发人员说，不要紧，我检查一下，应该没事儿的。你怎么办呢？
试想如果我们将测试工具将由开发人员使用，他检查出来的安全报告篇幅又较长，还不把他们给吓坏了？实际上，安全团队可以帮助开发人员使用这种工具。安全人员由于具备了专业的知识和技能，也就能够区分安全问题的优先顺序和严重程度，并可以编辑这些报告，从而便于开发人员实施修正措施。如果由开发人员自己解决这些问题，如果发现了200个问题，他又如何判断哪些是高风险的漏洞，哪些是低风险的呢？
所以，先要决定这种漏洞扫描程序给什么人用的问题。
2、这种扫描的性质:
也就是要看它是一种工具还是一种服务？用户可以购买相关工具，并投入资源来打造一个强健的测试机制，或者通过一个厂商来远程扫描企业的Web应用程序，验证所发现的问题并生成一份安全聚焦报告。但由于控制、管理和商业秘密的原因，许多公司喜欢自己实施渗透测试和扫描，但专业的扫描服务将会不断发展壮大。
公司也可以选择兼而用之。如有的安全管理人员自己先不使用安全测试，而是委托其它的专业厂商进行。特别是在发现自己的公司并没有这方面的专业人员来管理安全测试所生成的海量数据时，这应该是一个明智的选择。否则，企业会发现受到许多似是而非的东西的影响，并不能得到真正漏洞的完整报告分析。企业可以求助于专业的公司分析测试结果，并与开发人员协商来修正问题。在逐渐熟悉这种服务或工具之后，企业可以扩展这种工具的使用，并且可以采取一种三步走的方法，
第一步，开发人员测试代码，并与安全测试厂商协调。第二步，安全管理人员用安全测试工具进一步测试程序。第三步，将应用程序推向互联网，由专业的测试公司或工具来实施测试。
3、如何整合？
这些工具在通过本地化方式或通过应用程序接口（API）与开发人员或咨询团队所使用的其它系统整合后，运行起来将达到最佳状态。如与内容管理工具、项目管理工具等工具的整合，从而也便于跟踪并修正其它方面的代码缺陷。如与微软的可视化开发开台Visual Studio.net的集成，就可使开发人员从其桌面上执行扫描，它的使用界面类似于其开发工具的界面。
最好的工具应当能够将结果直接导出到一个静态代码扫描工具中。这正是Web应用程序测试工具可以告诉用户是什么性质的漏洞，但却并不查明代码中是哪个位置有问题的原因。
10个评估标准
一款优秀的测试工具总有其自身的独特性，但不同厂商的扫描技术原理大同小异，其不同点也不过在于下面的这些特性：
1、与软件开发、生产过程、平台的高度集成。
2、可管理部署的多种扫描器。
3、针对不同环境进行调整的能力。
4、提供除应用程序扫描之外的特性和服务，如扫描源代码、其它的一致性分析、自动漏洞修正等，还可对进程设计提供帮助等。
5、漏洞检测和纠正分析。不但应当报告漏洞，还应当以一种开发人员可以理解的语言和方式来提供改正建议。这种扫描器应当能够确认被检测到漏洞的网页。并尽量排除那些似是而非的东西。
6、持续有效地更新其漏洞数据库。因为时过境迁，总有新的攻击出现，供应商应当根据新出现的漏洞更新其数据库。
7、报告和分析。这种工具应当能够有助于对检测到的漏洞进行分类，并根据其严重程度对其等级评定。此外，还要有漏洞的详细解释、建议的解决方案、到达现有补丁的链接等。这种报告最好还能够满足应用程序开发人员和不同水平的安全专业人士的需要。
8、非安全专业人士也易于上手。
9、协议支持：如今的多数扫描器仅使用HTTP协议来探测支持Web的应用程序。然而，如果它还支持其它协议的话，如增加SOAP协议等。就会极大地增加其可用性。
10、这种工具应当支持常见的Web服务器平台，如IIS和Apache，以及ASP、JSP、ASP.net等网络技术。
使用渗透测试工具的四个注意事项
首先，要保证贵公司不仅仅要投资于扫描工具，还要加强培训、员工管理，并围绕着发现和修正漏洞制定强健的进程。有些单位在拿到工具之后，不管三七二十一，就针对Web应用程序实施扫描和测试，却没有教育测试人员如何测试，也不花费点时间来教育员工如何配置，如何使用相关的插件来强化这种测试。这是盲动的表现。
第二、不要期望开发人员马上就喜欢这种工具。许多开发人员可能对这些工具所提示的安全状态不感兴趣或不屑一顾。企业应当关注如何让员工认识到所揭示内容的严重性和风险。
第三、要认识到这种工具的局限性。一些人相信，只要这些工具没有发现问题，他们就可以高枕无忧了。但笔者要说的是，这只能说明你的系统也许并不存在这些特定的问题。因为任何工具都不可能包含过去和未来的所有漏洞清单，所以这种工具并不是包治百病，从一定意义上讲，它们有时确实无能为力。单靠一种工具并不能发现所有的问题，经常出现这种情况，用一种漏洞扫描工具发现的漏洞，用另外一种漏洞扫描工具却无法发现。所以还需要人力资源来确认问题的存在。
第四、要真正认识到，安全并不是权宜之计，不是忙完了这阵子就算完。因为Web应用程序是动态变化的，企业需要经常地、不断地测试和检查，以保障不会出现新的漏洞。如有的单位每隔一个星期就扫描一下。笔者认为，只要人力、物力许可经常检测应当是一件好事。
篇2：Web应用程序和Web网站
在牛腩接近尾声调试代码时，有时调试半天也调不出个什么效果，无奈之举，先和源码对比一下，发现我的web层中每个网页下面多个aspx.designer.cs 文件（设计器文件），网上说有这个文件说明你这个项目是web应用程序而不是WEB网站，而普通的WEB网站是aspx（网页信息）+cs（后台代码）的，这是什么情况？我都快哭了，难不成从开始我建立的项目就是错的，又回头看视频中最开始建立项目的阶段，后来证明我的假设是对的，疑问又来了，可是我的绝大部分功能也都可以实现的啊，那他们两个究竟有什么不同，相互之间能不能转换？原来原来他们都是设计asp网页的，web项目有两种,一种webapplication生成aspx.designer.cs 文件文件，一种website是不生成designer.cs的。
一、不同：
1、前者在添加aspx窗体时会有一个默认的命名空间，而web网站Web网站在引用后出现一个bin文件夹那里存放dll
2、前者有重新生成和发布两项；Web网站只有一个发布网站。
3、前者可以作为类库被引用；Web网站则不可以作为类库被引用。
4、前者可以添加ASP.Net文件夹中不包括bin、App_Code；Web网站可以添加ASP.Net文件夹包括bin、App_Code。
5、前者序添加网页后页面文件中默认codeBehind，而网站中则是coddfile
至此我中间遇到的疑惑都消除了，为什么我的网页下面多了designer.cs文件，为什么我的cs代码中有命名空间，页面文件中是codebehind。<?www.2cto.com/kf/ware/vc/“ target=”_blank“ class=”keylink“>vcD4KPHA+PGltZyBzcmM9”www.2cto.com/uploadfile/Collfiles/1031/20141031090204126.jpg“ alt=”\“>
二、各自优点：
1、网站：
动态编译该页面，马上可以看到效果，不用编译整个站点（主要优势）；可以使错误的部分和使用的部分不相干扰（可以要求只有编译通过才能签入）；可以每个页面生成一个程序集（不会采用这种方式）；可以把一个目录当做一个Web应用来处理，直接复制文件就可以发布，不需要项目文件；可以把页面也编译到程序集中
2、应用程序：
编译和发布速度中，明显变快，发布的时候一开始就可以设置是否覆盖，
原来的网站要升级过来，需要生成一个设计类代码页。有了此文件，编译的时候，编译器就不用再分析aspx页面了。明显加快了编译速度。且只生成一个程序集。执行的速度页快了 。
参考：web应用程序与web网站区别，aspx.designer.cs文件
三、相互转化
1、网站转化为应用程序：
VSSP1内置了转换程序，可以非常方便的从WebSite转换到WebApplication，只需要复制文件，右键执行“转换为Web应用程序”即可。
2、应用程序转化为网站：
删除所有*.designer.cs，将*.aspx、*.ascx、*.master页面文件中的Codebehind=”FileList.aspx.cs“ 批量替换CodeFile=”FileList.aspx.cs“即可。
最后就是大网站比较适合用WebApplication项目，小网站比较适合用WebSite项目。
感受：现在只能理解到这里，总之这次的不认真换来了不少的收获，算是歪打正着吧，学习中抱着一种不将就的态度。
篇3：网站安全检测：推荐8款免费的Web安全测试工具WEB安全
随着 Web 应用越来越广泛，Web 安全威胁日益凸显， 利用网站操作系统的漏洞和Web服务程序的 SQL 注入漏洞等得到Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，更为严重的则是在网页中植入恶意代码，使得网站访问者受到侵害。这也使得越来越多的用户关注应用层的安全问题，对 Web 应用安全的关注度也逐渐升温。下面向大家推荐8款非常有用的免费Web安全测试工具。
N-Stalker Free Version
N-Stalker Web 应用程序安全免费版本能够为您的 Web 应用程序清除该环境中大量常见的漏洞，包括跨站脚本（XSS）、SQL 注入（SQL injection）、缓存溢出（Buffer Overflow）、参数篡改 （Parameter Tampering）等等。
Netsparker Community Edition
Netsparker Community Edition 是一款 SQL 注入扫描工具，是Netsparker的社区免费版本，提供了基本的漏洞检测功能。使用友好，灵活。
Websecurify
Websecurify 是一款开源的跨平台网站安全检查工具，能够帮助你精确的检测 Web 应用程序安全问题，
Wapiti
Wapiti 是 Web 应用程序漏洞检查工具。它具有“暗箱操作”扫描，即它不关心 Web 应用程序的源代码，但它会扫描网页的部署，寻找使其能够注入数据的脚本和格式。
Skipfish
Skipfish 是 Google 公司发布的一款自动 Web 安全扫描程序，以降低用户的在线安全威胁。和 Nikto 和 Nessus 等其他开源扫描工具有相似的功能。
Exploit-Me
Exploit-Me 是一套 Firefox 的 Web 应用程序安全测试工具，轻量，易于使用。
OWASP WebScarab Project
WebScarab 一个用来分析使用HTTP和HTTPS协议的应用程序框架，通过记录它检测到的会话内容（请求和应答）来帮助安全专家发现潜在的程序漏洞。
X5s
x5s 是一款 Fiddler 插件，用于辅助渗透测试人员发现跨站点脚本（XSS）漏洞。
篇4：Web安全测试知多少
1. 数据验证流程：一个好的web系统应该在IE端，server端，DB端都应该进行验证，但有不少程序偷工减料，script验证完了，就不管了;app server对数据长度和类型的验证与db server的不一样，这些都会引发问题。有兴趣的可参看一下script代码，设计一些case，这可是你作为一个高级测试人员的优秀之处哦。我曾修改了页面端的script代码，然后提交了一个form，引发了一个系统的重大漏洞后门。
2. 数据验证类型： 如果web server端提交sql语句时，不对提交的sql语句验证，那么一个 就可暗喜了。他可将提交的sql语句分割，后面加一个delete all或drop database的之类语句，能将你的数据库内容删个精光!我这一招还没实验在internet网站上，不知这样的网站有没有，有多少个。反正我负责的那个web系统曾经发现这样的问题。
3. 网络加密，数据库加密不用说了吧。
WEB软件最常碰到的BUG为：
1、SQL INJETION
2、对文件操作相关的模块的漏洞
3、COOKIES的欺骗
4、本地提交的漏洞
SQL INJETION的测试方法
原理：
如有一新闻管理系统用文件news.asp再用参数读取数据库里的新闻譬如
www.xxx.com/news.asp?id=1这一类网站程序
如果直接用
rs.open ”select * from news where id=“ &
cstr(request(”id“)),conn,1,1
数据库进行查询的话即上面的URL所读取的文章是这样读取的
select * from news where id=1
懂得SQL语言的就知道这条语言的意思是在news读取id为1的文章内容。
但是在SQL SERVER里select是支持子查询和多句执行的。如果这样提交URL的话
www.xxx.com/news.asp?id=1and 1=(select count(*) from admin
where left(name,1)=a)
SQL语句就变成了
select * news where id=1 and 1=(select count(*)
from admin where left(name,1)=a)
意思是admin表里如果存在字段字为name里左边第一个字符是a的就查询news表里id为1的内容，news表里id为1是有内容的，从逻辑上的角度来说就是1&P。只要P为真，表达式就为真，页面会返回一个正确的页面。如果为假页面就会报错或者会提示该id的文章不存在。 利用这点就可以慢慢得试用后台管理员的用户和密码，
测试：
测试存不存在SQL INJETION很简单如果参数为整数型的就在URL上分别提交www.xxx.com/news.asp?id=1and 1=1 和www.xxx.com/news.asp?id=1and 1=2
如果第一次返回正确内容，第二次返回不同页面或者不同容内的话表明news.asp文件存在SQL INJETION。如何利用就不多说了，毕竟我们都不是为了入侵。
对文件操作相关的模块的漏洞在测试
原理：
如一上传文件功能的程序upload.asp如果程序员只注重其功能上的需求没有考虑到用户不按常规操作的问题。如上传一个网页木马程序上去，整个网站甚至整个服务器的架构和源码都暴露而且还有一定的权限。
测试：
试上传asp,php,jsp,cgi等网页的文件看是否成功。
补充：
还有像 www.xxx.com/download/filespath.asp?path=../abc.zip
下载功能的软件如果
www.xxx.com/download/filespath.asp?path=../conn.asp
很可能下载到这些asp的源码数据库位置及用户密码都可能暴露。
其它还有很多，就不一一举例了。
COOKIES的欺骗
原理：
COOKIES是WEB程序的重要部分，COOKIES有利有弊。利在于不太占用服务器的资源，弊在于放在客户端非常容易被人修改加以利用。所以一般论坛前台登陆用COOKIES后台是用SESSION，因为前台登陆比较频繁，用SESSION效率很低。但如论坛程序管理员用户在前台也有一定的权限，如果对COOKIES验证不严的话，严重影响了WEB程序的正常工作。如前期的LEADBBS，只有后台对COOKIES验证严格，前台的位置只是从COOKIES读取用户的ID，对用户是否合法根本没有验证。
测试：
推荐使用MYBROWER浏览器，可即时显示及修改COOKIES。尝试一下修改里面的对应位置。
本地提交表单的漏洞
原理：
Action只接爱表单的提交，所以表单是客户WEB程序的接口。先举一个例子，一个投票系统，分A，B，C，D各项的VALUE是100,80,60,40。
但是如果先把些页面以HTML形式保存在本地硬盘里。然后修改其VALUE，再向其ACTION提交，ACTION会不会接受呢?
测试：
如一投票系统，把投票的页面保存在本地硬盘，用记事本打开，找到对应项的VALUE值，对其修改，然后提交。
强制后台浏览：绕过登陆页面，直接提交系统文件夹或文件页面。不完善的系统如果缺少index.html就可能被绕过登陆验证页面。在系统文件夹中保留一些公司机密内容也会造成不可估计的损失。
跨站脚本攻击：基本上这个我只是在论坛――各种形式的论坛里看到过，具体的一个例子，比如这段代码可以被填在任何输入框里 “”，如果未对一些字符，如 “<”、”>“进行转换，就会自动执行这个脚本。百度快照所提供的网页都自动将代码执行了。不信大家搜一点JS的代码，看看你能不能看到。
堆栈溢出攻击：完全的不了解，只是在某个网站上看到，可以对现在的、XP、进行攻击，非常恐怖，MS应该打了补丁了吧?
篇5：确保PHP应用程序的安全[4]WEB安全
浏览器内的数据操纵
有一类浏览器插件允许用户篡改页面上的头部元素和表单元素，使用 Tamper Data（一个 Mozilla 插件），可以很容易地操纵包含许多隐藏文本字段的简单表单，从而向 PHP 和 MySQL 发送指令。
用户在点击表单上的Submit之前，他可以启动 Tamper Data。在提交表单时，他会看到表单数据字段的列表。Tamper Data 允许用户篡改这些数据，然后浏览器完成表单提交。
让我们回到前面建立的示例。已经检查了字符串长度、清除了 HTML 标记并删除了十六进制字符。但是，添加了一些隐藏的文本字段，如下所示：
清单 17. 隐藏变量
if ($_POST['submit'] == ”go“){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing....
}
function cleanHex($input){
$clean = \
preg_replace(”![\][xX]([A-Fa-f0-9]{1,3})!“, ”“,$input);
return $clean;
}
?>
”
“text” name=“name” id=“name” size=“20” maxlength=“40”/>
注意，隐藏变量之一暴露了表名：users。还会看到一个值为create的action字段。只要有基本的 SQL 经验，就能够看出这些命令可能控制着中间件中的一个 SQL 引擎。想搞大破坏的人只需改变表名或提供另一个选项，比如delete。
图 1 说明了 Tamper Data 能够提供的破坏范围。注意，Tamper Data 不但允许用户访问表单数据元素，还允许访问 HTTP 头和 cookie。
图 1. Tamper Data 窗口
要防御这种工具，最简单的方法是假设任何用户都可能使用 Tamper Data（或类似的工具）。只提供系统处理表单所需的最少量的信息，并把表单提交给一些专用的逻辑。例如，注册表单应该只提交给注册逻辑。
如果已经建立了一个通用表单处理函数，有许多页面都使用这个通用逻辑，那该怎么办？如果使用隐藏变量来控制流向，那该怎么办？例如，可能在隐藏表单变量中指定写哪个数据库表或使用哪个文件存储库。有 4 种选择：
不改变任何东西，暗自祈祷系统上没有任何恶意用户。 重写功能，使用更安全的专用表单处理函数，避免使用隐藏表单变量。 使用md5或其他加密机制对隐藏表单变量中的表名或其他敏感信息进行加密。在 PHP 端不要忘记对它们进行解密。 通过使用缩写或昵称让值的含义模糊，在 PHP 表单处理函数中再对这些值进行转换，
例如，如果要引用users表，可以用u或任意字符串（比如u8y90x0jkL）来引用它。
后两个选项并不完美，但是与让用户轻松地猜出中间件逻辑或数据模型相比，它们要好得多了。
现在还剩下什么问题呢？远程表单提交。
远程表单提交
Web 的好处是可以分享信息和服务。坏处也是可以分享信息和服务，因为有些人做事毫无顾忌。
以表单为例。任何人都能够访问一个 Web 站点，并使用浏览器上的File >Save As建立表单的本地副本。然后，他可以修改action参数来指向一个完全限定的 URL（不指向 formHandler.php，而是指向 www.yoursite.com/formHandler.php，因为表单在这个站点上），做他希望的任何修改，点击Submit，服务器会把这个表单数据作为合法通信流接收。
首先可能考虑检查$_SERVER['HTTP_REFERER']，从而判断请求是否来自自己的服务器，这种方法可以挡住大多数恶意用户，但是挡不住最高明的 。这些人足够聪明，能够篡改头部中的引用者信息，使表单的远程副本看起来像是从您的服务器提交的。
处理远程表单提交更好的方式是，根据一个惟一的字符串或时间戳生成一个令牌，并将这个令牌放在会话变量和表单中。提交表单之后，检查两个令牌是否匹配。如果不匹配，就知道有人试图从表单的远程副本发送数据。
要创建随机的令牌，可以使用 PHP 内置的md5()、uniqid()和rand()函数，如下所示：
清单 18. 防御远程表单提交
session_start();
if ($_POST['submit'] == “go”){
//check token
if ($_POST['token'] == $_SESSION['token']){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing....
}else{
//stop all processing! remote form. posting attempt!
}
}
$token = md5(uniqid(rand(), true));
$_SESSION['token']= $token;
function cleanHex($input){
$clean = preg_replace(“![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
?>
这种技术是有效的，这是因为在 PHP 中会话数据无法在服务器之间迁移。即使有人获得了您的 PHP 源代码，将它转移到自己的服务器上，并向您的服务器提交信息，您的服务器接收的也只是空的或畸形的会话令牌和原来提供的表单令牌。它们不匹配，远程表单提交就失败了。
篇6：确保PHP应用程序的安全[3]WEB安全
缓冲区溢出攻击
缓冲区溢出攻击试图使 PHP 应用程序中（或者更精确地说，在 Apache 或底层操作系统中）的内存分配缓冲区发生溢出，请记住，您可能是使用 PHP 这样的高级语言来编写 Web 应用程序，但是最终还是要调用 C（在 Apache 的情况下）。与大多数低级语言一样，C 对于内存分配有严格的规则。
缓冲区溢出攻击向缓冲区发送大量数据，使部分数据溢出到相邻的内存缓冲区，从而破坏缓冲区或者重写逻辑。这样就能够造成拒绝服务、破坏数据或者在远程服务器上执行恶意代码。
防止缓冲区溢出攻击的惟一方法是检查所有用户输入的长度。例如，如果有一个表单元素要求输入用户的名字，那么在这个域上添加值为 40 的maxlength属性，并在后端使用substr()进行检查。清单 13 给出表单和 PHP 代码的简短示例。
清单 13. 检查用户输入的长度
if ($_POST['submit'] == “go”){
$name = substr($_POST['name'],0,40);
//continue processing....
}
?>
$_SERVER['PHP_SELF'];?>“ method=”post“>
”name“ id=”name“ size=”20“ maxlength=”40“/>
为什么既提供maxlength属性，又在后端进行substr()检查？因为纵深防御总是好的。浏览器防止用户输入 PHP 或 MySQL 不能安全地处理的超长字符串（想像一下有人试图输入长达 1,000 个字符的名称），而后端 PHP 检查会确保没有人远程地或者在浏览器中操纵表单数据。
正如您看到的，这种方式与前一节中使用strlen()检查GET变量pid的长度相似。在这个示例中，忽略长度超过 5 位的任何输入值，但是也可以很容易地将值截短到适当的长度，如下所示：
清单 14. 改变输入的 GET 变量的长度
$pid = $_GET['pid'];
if (strlen($pid)){
if (!ereg(”^[0-9]+$“,$pid)){
//if non numeric $pid, send them back to home page
}
}else{
//empty $pid, so send them back to the home page
}
//we have a numeric pid, but it may be too long, so let's check
if (strlen($pid)>5){
$pid = substr($pid,0,5);
}
//we create an object of a fictional class Page, which is now
//even more protected from evil user input
$obj = new Page;
$content = $obj->fetchPage($pid);
//and now we have a bunch of PHP that displays the page
//......
//......
?>
注意，缓冲区溢出攻击并不限于长的数字串或字母串。也可能会看到长的十六进制字符串（往往看起来像\xA3或\xFF）。记住，任何缓冲区溢出攻击的目的都是淹没特定的缓冲区，并将恶意代码或指令放到下一个缓冲区中，从而破坏数据或执行恶意代码。对付十六进制缓冲区溢出最简单的方法也是不允许输入超过特定的长度。
如果您处理的是允许在数据库中输入较长条目的表单文本区，那么无法在客户端轻松地限制数据的长度。在数据到达 PHP 之后，可以使用正则表达式清除任何像十六进制的字符串。
清单 15. 防止十六进制字符串
if ($_POST['submit'] == ”go“){
$name = substr($_POST['name'],0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing....
}
function cleanHex($input){
$clean = preg_replace(”![\][xX]([A-Fa-f0-9]{1,3})!“, ”“,$input);
return $clean;
}
?>
您可能会发现这一系列操作有点儿太严格了，
毕竟，十六进制串有合法的用途，比如输出外语中的字符。如何部署十六进制regex由您自己决定。比较好的策略是，只有在一行中包含过多十六进制串时，或者字符串的字符超过特定数量（比如 128 或 255）时，才删除十六进制串。
跨站点脚本攻击
在跨站点脚本（XSS） 攻击中，往往有一个恶意用户在表单中（或通过其他用户输入方式）输入信息，这些输入将恶意的客户端标记插入过程或数据库中。例如，假设站点上有一个简单的 来客登记簿程序，让访问者能够留下姓名、电子邮件地址和简短的消息。恶意用户可以利用这个机会插入简短消息之外的东西，比如对于其他用户不合适的图片或将 用户重定向到另一个站点的 JavaScript，或者窃取 cookie 信息。
幸运的是，PHP 提供了strip_tags()函数，这个函数可以清除任何包围在 HTML 标记中的内容。strip_tags()函数还允许提供允许标记的列表，比如或。
清单 16 给出一个示例，这个示例是在前一个示例的基础上构建的。
清单 16. 从用户输入中清除 HTML 标记
if ($_POST['submit'] == ”go“){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing....
}
function cleanHex($input){
$clean = preg_replace\
(”![\][xX]([A-Fa-f0-9]{1,3})!“, ”“,$input);
return $clean;
}
?>
”
“text” name=“name” id=“name” size=“20” maxlength=“40”/>
从安全的角度来看，对公共用户输入使用strip_tags()是必要的。如果表单在受保护区域（比如内容管理系统）中，而且您相信用户会正确地执行他们的任务（比如为 Web 站点创建 HTML 内容），那么使用strip_tags()可能是不必要的，会影响工作效率。
还有一个问题：如果要接受用户输入，比如对贴子的评论或来客登记项，并需要将这个输入向其他用户显示，那么一定要将响应放在 PHP 的htmlspecialchars()函数中。这个函数将与符号、<和>符号转换为 HTML 实体。例如，与符号（&）变成&。这样的话，即使恶意内容躲开了前端strip_tags()的处理，也会在后端被htmlspecialchars()处理掉
【如何评估和使用Web应用程序安全测试工具？】相关文章：
3.职业评估测试
文档为doc格式
