|
|
Web扫描器SeachPlan的设计与实现
姓名 李波
2014年6月
中图分类号：TP311.
UDC分类号：004.
Web漏洞扫描器SeachPlan的设计与实现
作 者 姓 名 李波
学 院 名 称 软件学院
指 导 教 师 XXX
答辩委员会主席 XXX 教授
申 请 学 位 工程硕士
学 科 专 业 软件工程
学位授予单位 北京理工大学
论文答辩日期 2014年6月
Design and Implementation of SeachPlan Scanner
Candidate Name： li bo
School or Department: Software School
Faculty Mentor: XXX
Chair, Thesis Committee：Prof. XXX
Degree Applied: Master of Engineering
Major： Software Engineering
Degree by: Beijing Institute of Technology
The Date of Defence： June，2014
研究成果声明
本人郑重声明：所提交的学位论文是我本人在指导教师的指导下进行的研究工作获得的研究成果。尽我所知，文中除特别标注和致谢的地方外，学位论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得北京理工大学或其它教育机构的学位或证书所使用过的材料。与我一同工作的合作者对此研究工作所做的任何贡献均已在学位论文中作了明确的说明并表示了谢意。
特此申明。
签 名： 日期：
关于学位论文使用权的说明
本人完全了解北京理工大学有关保管、使用学位论文的规定，其中包括：①学校有权保管、并向有关部门送交学位论文的原件与复印件；②学校可以采用影印、缩印或其它复制手段复制并保存学位论文；③学校可允许学位论文被查阅或借阅；④学校可以学术交流为目的,复制赠送和交换学位论文；⑤学校可以公布学位论文的全部或部分内容（保密学位论文在解密后遵守此规定）。
签 名： 日期：
导师签名： 日期：
摘要
随着近代以来计算机技术与信息技术的迅速发展，Web应用愈来愈普及。然而，伴随而来的Web的安全状态也发生了很大的变化。虽然随着人们安全意识的提高，部分漏洞已经得到了修复，但是随着各种新技术的不断涌现，特别是Web2.0、HTML5、云服务以及无线互联网的推出。Web应用开发周倜短，而Web开发人员又缺乏充分的安全意识，因此，如可评估Web应用系统的安全性，是Web安全领域的当务之急。
Web应用程序是基于HTTP(S)协议的，是一种应用层协议。传统的防火墙和入侵检测系统是从网络层保护Web应用程序，而Web扫描器SearchPlan是从应用层保护Web应用程序，二者互补，更加固了Web应用程序的安全。
Web漏洞扫描器，是在Web产品正式发布之前对Web应用程序进行扫描检测。借助Web漏洞的常见签名，对Web应用程序进行大量重复的安全检测。从而提前发现应用程序中可能存在的漏洞，做到早发现、早预防，从而大幅度的降低Web应用程序的安全隐患和维护成本。
论文首先分析了Web应用程序的发展历程，然后分析了国内外Web安全的严峻形势，之后分析了Web漏洞产生的主要原因，并讲解了Web漏洞的分类与检测技术、总结了Fuzzing技术、SQL注入、XSS、路径遍历的漏洞检测方法；在此基础之上，设计出了易扩展的、效率高的基于爬虫技术的Web漏洞扫描器SerachPlan，分析了漏洞扫描器的基本原理和实现了漏洞扫描器的大致原型，并对原型加以实现，最后分析了扫描器SearchPlan的不足之处和下一步的工作。
关键词： Web安全，漏洞检测，Web扫描器，爬虫技术，Fuzzing技术，SQL注入，XSS，路径遍历漏洞
Abstract
With the rapid development of Computer Technology and information technology,Web applications have become more and more popular.However, accompanying with it, Web security status has undergone great changes. Although with the improvement of people's sense of safety, some vulnerabilities have been fixed, with the continuous emergence of new technologies,especially Web2.0,HTML5,Cloud services and Wireless Internet available.Web Application Development Week is short, but Web developers lack adequate safety awareness, so how to evalute the security of Web applications is the urgent priority.
Web applications are based on HTTP (S) protocol,which is an application layer protocol. Traditional firewalls and intrusion detection systems to protect Web applications from the network layer , while the Web scanner SearchPlan protect Web applications from the application layer , the two complement each other, so more solid security for Web applications .
Web vulnerability scanner is working before the official product launch Web application. Based on common Web vulnerabilities signature and then send a large request to evaluated Web application security. With Web scanner,we can detect its vulnerabilities before its launched.Early detection ,early prevetion, thereby greatly reducing the security risks and maintenance costs of Web applications .
First the paper analyzes the development process of Web applications , Web security and then analyzed the grim situation at home and abroad , after the analysis of the main reasons of Web vulnerabilities generated and explained the Web vulnerabilities classification and detection technology, then summed up the SQL injection , XSS, Path Traversal vulnerability detection methods;on this basis , to design a scalable , high- efficiency technology, Web -based vulnerability scanner reptiles SerachPlan, analyzes the basic principle and implementation of a vulnerability scanner vulnerability scanner prototype roughly , and the prototype to be realized , the final analysis of the shortcomings of the scanner SearchPlan and future work .
Key Words: Web Security,Vulnerability Detection,Web scanner,Crawler technology, SQL injection, XSS, Path Traversal Vulnerability
目录
第1章 绪论... 1
1.1 XXXX.. 1
1.2 XXXX.. 1
1.3 论文组织结构... 1
第2章 图表及表达式... 2
2.1 图... 2
2.2 表... 2
2.2.1 XXXXX.. 3
2.2.2 XXXXX.. 3
2.3 表达式... 3
第3章 参考文献... 5
3.1 参考文献的标注格式... 5
3.2 参考文献的著录标准及格式... 5
第4章 量和单位... 9
第5章 学位论文的排版及打印要求... 10
5.1 图纸张要求及页面设置... 10
5.2 封面... 10
5.2.1 XXXXX.. 10
5.2.2 XXXXX.. 10
5.3 题名页... 11
5.4 书脊... 11
5.5 中英文摘要... 12
5.6 目录... 12
5.7 正文... 12
5.8 其他... 13
第6章 其他注意事项... 14
结论... 15
参考文献... 16
附录... 18
攻读学位期间发表的论文与研究成果清单... 19
致谢... 20
第1章 绪论
1.1 研究背景
1.1.1Web的发展历程
在因特网早期阶段，万维网(World Wide Web)仅有Web站点构成，这些站点基本上是包含静态文本的信息库。随后人们发明了Web浏览器，通过它来检索和现实文档。这些相关信息流仅由服务器向浏览器单向传送。多数站点不验证用户的合法性，因为根本没这个必要。
如今的万维网与早期的万维网已经完全不同，Web上的大多数站点实际上是应用程序。它功能强大，在服务器和浏览器之间进行信息的双向传送。它支持注册和登陆、金融交易、搜索以及用户创作的内容。
同时，Web应用程序也带来了重大的安全威胁。应用程序各不相同，所包含的漏洞也各不相同。许多应用程序是由开发人员独立开发的，然而许多开发人员对他们所编写的代码可能引起的安全问题只是略知一二。为了实现核心功能，Web应用程序通常需要月内不仅算计建立连接。这些系统中保存着高度敏感数据。这也就使Web应用程序前附着重大的危机。
1.1.2Web面对的严峻形势
随着计算机科学和信息技术的迅速发展，Web应用在各个领域得到了广泛的应用。Web应用程序也进而成为当今安全的当务之急，也是值得关注的话题。对相关领域，这一问题显得至关重要。这里的相关领域包括因特网业务收入日益增长的公司、向Web应用程序托付敏感信息的用户，以及通过窃取支付信息或入侵银行账户偷窃巨额资金的犯罪分子。因特网的发展大大超过了人们的想象。防火墙、操作系统安全和最新的 补丁，都能被针对Web应用的简单绕过。据Gartner Group报道说，75%的攻击都在Web应用层面上，而且对超过300个站点的审计表名97%的站点都拥有会被攻击的弱点。恶意攻击的新闻头条越来越常见，政府对伪电脑安全措施进行调查的情况越来越多。然而现实是，绝大多数的企业将大量的投资话费在网络和服务器的安全上，没有真正意义上重视网络的安全，这恰恰给黑客以可乘之机。根据2013年WASP（Open Web Application Security Project）的Top10漏洞中，目录遍历漏洞占首位，XSS（Cross Site Scripting）漏洞位居第二位，SQL Injection(盲注)占第三问，SQLInjection占第四位。
近年来，国内的众多行业逐渐把主要业务转移到Web上，如银行、电力、金融、物流、购物等。Web应用的比重越来越高，而Web安全的重视度却相对很低。这也使得越来越多的黑客从攻击操作系统与服务器上逐渐转向对Web的攻击。因此Web安全已经成为安全的当务之急。
虽然今年来Web安全也引起了人们的重视，如使用安全套接层(Secure Socket Layer,SSL)技术，而实际上，大多数的Web应用程序并不安全。虽然SSL已得到广泛使用，且会定期进行PCI扫描。可这些技术都不能再用户输入上得到良好的应用。Web应用时基于HTTP(S)请求的,而这些请求，并不被防火墙，操作系统等仔细检查。从长远的角度来看，应该在开发阶段消除安全隐患。因此对Web漏洞扫描器的研究使用重要的理论意义和实用价值的，也是应该引起越来越多的研究者关注的。
1.2 研究的目的、内容和目标
1.2.1研究的目的
Web应用系统开发周期短，而开发人员参差不齐，Web应用程序是在所难免的。Web应用程序的安全问题，集中表现以下几个方面：
(1) 不成熟的安全意识
近年来，人们对Web应用程序的安全问题的意识有所增强，但与网络和操作系统这些发展更加完善的领域相比，人们对Web应用程序安全问题的意识还远远不够成熟。虽然大多数IT安全人员掌握了相当多的网络安全知识，但他们对Web应用程序安全有关的许多核心概念仍然不甚了解，甚至存在误区。
(2) 独立开发
大多数Web应用程序都有企业的员工或者合作公司独立开发。即使应用程序采用第三方组件，通常情况下也只是拼凑在一起。在这种情况下，每个应用程序都各不相同，并且可能包含独有的缺陷。
(3) 资源与时间限制
由于独立。一次性开发的影响，许多Web应用程序受到时间和资源的限制。
基于以上原因，研究Web的漏洞并开发一个自动的Web扫描器是十分必要的。Web扫描器SearchPlan是对Web应用程序的主动监测。它是工作在HTTP协议上，模拟黑客的攻击技术，利用典型的Web漏洞签名，构造HTTP请求，主动向Web发送构造数据，然后从Web服务器的回应中检测漏洞签名。和传统的防火墙。入侵检测系统从网络层保护Web应用程序，共同完成对Web应用程序的防护。可以在Web受攻击前检测到潜在的Web漏洞，从而以最低的成本维护Web安全。Web安全是网络安全中最严重的安全之一，是一项十分有意义的工作。本课题的研究是设计一个具有可扩展、高效率的Web扫描工具，并作出准确的判断。
1.2.2研究内容
本论文是以Web安全漏洞的检测技术和常见的Web安全检测方法为主要内容，具体的研究内容如下：
（1） 研究Web常见应用技术
（2） 研究URL提取技术
（3） 研究页面爬虫技术
（4） 研究Fuzzing技术，对网站进行模糊测试，初步定位漏洞
（5） 研究SQL注入技术，对网站再次测试，确定注入类型，和危险程度
（6） 研究XSS技术，对网站再次测试，确定跨站注入点
（7） 研究命令执行漏洞，对网站再次测试，确定命令执行发生点
1.2.3研究目标
本课题主要完成以下研究目标：
1．对Web应用程序进行无缝爬虫，全面的抓取Web页面、CSS、JavaScript脚本，并对其进行分析
2.对Web应用程序进行全面扫描，并能给出较为详细的测试报告，结果无误报与漏报
3.具有较高的运行效率，具有良好的扩展性，具有自学习能力
4.具有良好的用户交互界面
1.3 论文组织结构
本文总共分为六章：
第一章：第一章简要分析研究方向的背景知识，研究方向的选向，以及论文即将开始的工作。
第二章：主要介绍了Web应用程序的安全现状，Web应用程序的常见漏洞，和Web安全检测技术的发展，常见Web扫描器简介。
第三章：主要介绍了Fuzzing检测技术、SQL注入检测技术、XSS检测技术、命令执行检测技术的原理，并对Web扫描器SearchPlan的基础框架进行了设计。
第四章：主要介绍了SearchPlan的详细设计过程，并结合具体漏洞，介绍了其实现的详细设计与实现。
第五章：主要介绍Web安全扫描器SearchPlan的运行情况，以及AppSuite测试应用程序的设计，以及对SearchPlan的测试情况。
第六章：对论文的基本贡献和不足之处作出总结，并提出下一步的工作设想、
最后是致谢和参考文献
第2章 Web应用程序安全与风险
随着新技术的不断涌现，Hacker攻击技术的不断更新，Web应用程序的安全现状令人堪忧。到目前为止，Web应用程序的漏洞带来的危害性越来越多被企业认识。这些常见的漏洞包括SQL注入、XSS（跨站脚本攻击）、系统(OS)命令执行、动态命令执行等等。随着Web应用的越来越广泛，越来越多的漏洞也会被发现。
2.1 Web应用程序的安全现状
随着Web2.0、AJAX、社交网络、微博等等一系列新型的互联网产品的诞生，基于Web环境的互联网应用越来越广泛，企业信息化的过程中各种应用都架设在Web平台上，Web业务的迅速发展也引起黑客们的强烈关注，接踵而至的就是Web安全威胁的凸显，黑客利用网站操作系统的漏洞和Web服务程序的SQL注入漏洞等得到Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，更为严重的则是在网页中植入恶意代码，使得网站访问者受到侵害。这也使得越来越多的用户关注应用层的安全问题，对Web应用安全的关注度也逐渐升温。
目前很多业务都依赖于互联网，例如说网上银行、网络购物、网游等，很多恶意攻击者出于不良的目的对Web 服务器进行攻击，想方设法通过各种手段获取他人的个人账户信息谋取利益。正是因为这样，Web业务平台最容易遭受攻击。同时，对Web服务器的攻击也可以 说是形形色色、种类繁多，常见的有挂马、SQL注入、缓冲区溢出、嗅探、利用IIS等针对Webserver漏洞进行攻击。
一方面，由于TCP/IP的设计是没有考虑安全问题的，这使得在网络上传输的数据是没有任何安全防护的。攻击者可以利用系统漏洞造成系统进程缓冲区溢出，攻击者可能获得或者提升自己在有漏洞的系统上的用户权限来运行任意程序，甚至安装和运行恶意代码，窃取机密数据。而应用层面的软件在开发过程中也没有过多考虑到安全的问题，这使得程序本身存在很多漏洞，诸如缓冲区溢出、SQL注入等等流行的应用层攻击，这些均属于在软件研发过程中疏忽了对安全的考虑所致。
另一方面，用户对某些隐秘的东西带有强烈的好奇心，一些利用木马或病毒程序进行攻击的攻击者，往往就利用了用户的这种好奇心理，将木马或病毒程序捆绑在一些艳丽的图片、音视频及免费软件等文件中，然后把这些文件置于某些网站当中，再引诱用户去单击或下载运行。或者通过电子邮件附件和QQ、MSN等即时聊天软件，
图2-1常见攻击种类数据统计
将这些捆绑了木马或病毒的文件发送给用户，利用用户的好奇心理引诱用户打开或运行这些文件。
浏览器成为各种Web应用的集中平台，对于使用者而言是一大福音，但是另一方面也预示着Web将成为网络威胁的最大风险来源之一，Web安全威胁将成为今后全球性的一大安全课题。
从2010年开始到20012年底的三次《Symantec Internet Security Threat Report》统计数据可以看出，与WEB应用相关的漏洞比例飞速上升，占新增漏洞比例分别为48％，59％和69％。
根据《Web Hacking Incidents Database》的统计数据，2012年基于WEB的攻击次数是2011年的1.88倍。2006年的 WEB安全事件名单上，google、hotmail、yahoo等知名大型网站的名字已经数次出现。图2-1是WHID 2012年的有关攻击种类的统计数据。
2.2 Web应用程序常见安全漏洞
2.2.1 SQL注入漏洞
几乎每一个Web应用程序都使用数据库来保存所需的各种信息。例如，网上零售商所用的Web应用程序使用数据库保存一下信息：
1) 用户账户、证书、个人信息；
2) 所销售商品的介绍与价格
3) 订单、账单和支付细节
4) 每名应用程序用户的权限
数据库中的信息通过SQL(Structured Query Language，结构化查询语言)访问。SQL可用于读取、更新、增加或删除数据库保存的信息。
SQL是一种解释型语言，Web应用程序经常建立合并用户提交的数据的SQL语句。因此，如果建立语句的方法不安全，那么应用程序可能易于收到SQL注入攻击。这种缺陷是困扰Web应用程序最臭名昭著的漏洞之一。在最严重的情形中，匿名攻击者可利用SQL注入读取并修改数据库保存的所有数据，甚至完全控制数据库的服务器。
随着Web应用程序安全意识的日渐增强，SQL注入漏洞越来越少，同时也变得更加难以检测和利用。许多主流应用程序采用API来避免SQL注入，如果使用得当，这些API能够有效阻止SQL注入攻击。随着这种趋势的变化，查找并利用SQL注入漏洞的方法也在不断的改进，通常使用更加微妙的漏洞指标以及更加完善与强大的利用技巧。
SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。
下面是一个典型的SQL注入案例：
有如图2-2登陆界面，加入我们输入正常的用户名与密码，服务端可以正常判断，并现实对应的处理结果：
图2-2 登场登陆界面
假入输入如图2-3，因为后端处理逻辑没有对SQL注入进行防御，就会产生详细的错误信息，如图2-4：
图2-3 带有SQL注入的输入
图2-4 产生详细的错误信息
通过一个单引号(‘)可以简单测试SQL注入的存在与否，表2-1，2-2列出了常见字符、常见数据库错误信息
表2.1 识别SQL注入漏洞的常见字符
|
字符 |
和SQL关系 |
|
‘ |
单引号。用来分割字符串。一个不匹配的单引号会产生错误 |
|
; |
结束一个语句。提前结束查询会产生一个错误 |
|
/* |
注释分隔符。注释分隔符内的文字会被忽略 |
|
--%20 |
可以用来提前终止一个查询 |
|
( ) |
圆括号。用来组合逻辑语句。不匹配的括号或产生一个错误 |
|
a |
如果在数字比较中，任何字母字符都会产生一个错误。举个例子，WhERE TaskID =1是合法的，因为TaskID列是数字而1是数字。而如果是1a则不正确，因为1a不是数字 |
表2-2 常见数据库错误信息
|
平台 |
错误字符串示例 |
|
ODBC，ASP |
Microsoft OLE DB Provider for ODBC Drivers error ‘80040e21’ |
|
ODBC, C# |
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotaion mark |
|
.NET |
Stack Trace:[SqlException (0x80131904)]; |
|
Oracle,JDBC |
SQLException:ORA-01722:invalid number |
|
ColdFusion |
Invalid data for CFSQLTYPE |
|
MySQL,PHP |
Warning:mysql_errno():supplied argument is not a valid MySQL |
|
PostgreSQL |
Warning:PostgreSQL query failed |
2.2.2 跨站点脚本(XSS)漏洞
XSS脚本攻击，是一种针对其他用户的重量级攻击。从某种程度来说，XSS是在Web应用程序中发现的最为普遍的漏洞，困扰着现在绝大多数的应用程序，包括因特网上一些最为注重安全的应用程序，如电子银行使用的应用程序。
最初，当XSS在Web应用程序安全社区广为人们所知时，一些专业的渗透测试人员倾向于将XSS当做一种“次要”的漏洞。这一部分原因是因为改漏洞在Web应用程序中广为常见，也因为与服务器端命令注入漏洞相比，XSS并不能独立被黑客直接用于攻击应用程序。隋卓时间的推移，这种观点也发生了改变，如今，XSS已被视为Web应用程序面临的最主要的安全威胁。随着对客户端攻击研究的不断深入，人们开始讨论各种其他复杂性与利用XSS漏洞的攻击不相上下的攻击。与此同时，现实世界中也出现了大量利用XSS漏洞攻破知名机构的攻击。
通常情况下，XSS是一类主要的应用程序安全缺陷，它常常与其他漏洞一起造成破坏性的后果。有时，XSS攻击也能转换为某种病毒或能够自我繁殖的 蠕虫病毒 ，这种攻击确实十分严重。
XSS漏洞表现为各种形式，并且可分为3种类型：反射型、保存型和基于DOM的XSS漏洞。虽然这些漏洞具有一些相同的特点，但在如何确定这些漏洞方面，任然存在一些重要的差异：
□反射型XSS漏洞
如果一个应用程序使用动态页面向用户显示错误消息，就会造成一种常见的XSS漏洞。通常改页面会使用一个包含消息文本的参数，并在响应中将这个文本返回给用户。
图2-4、2-5验证了反射型XSS攻击。
图2-4 动态显示用户信息
图2-5 一次概念验证反射型XSS漏洞
如图2-6展示了反射型XSS攻击的实施步骤
图2-6 反射型XSS攻击的实施步骤
□保存型XSS漏洞
如果一名用户提交的数据被保存到应用程序中（通常保存在一个后端数据库中），然后不经过适当的过滤或净化就显示给其他用户，此时就会出现这种漏洞。
在支持终端用户交互的应用程序中，或者在具有管理权限的员工访问同一个应用程序的用户记录和数据的应用程序中，保存型XSS漏洞比较常见。例如，以一个拍卖应用程序为例，它允许买家提出与某件商品有关的问题，然后由卖家回答。如果一名用户提出一个专门设计的问题，在任何查看该问题的用户的浏览器执行任意脚本。在这种情况下，攻击者就可以让不知情的用户区竞标一件它不想要的商品；或者让一位卖家接受他提出的低价，结束竞标。
一般情况下，利用保存型XSS漏洞的攻击至少需要向应用程序提出两个请求。攻击者在第一次请求中传送一些专门设计的数据，其中包含恶意代码，应用程序接受并保存这些数据。在第二个请求中，一名受害者查看包含攻击者的数据的页面，这时恶意代码开始执行。为此，这种漏洞有时也叫二阶跨站点脚本。如2-7展示了保存型XSS漏洞的实施步骤。
图2-7 保存型XSS漏洞的实施步骤
□基于DOM的XSS漏洞
由于客户端JavaScript可以访问浏览器的文本对象模型（Documents Object Model,DOM）,因此它能够决定用于加载当前页面的URL。由应用程序发布一段脚本可以从URL中提取数据，对这些数据进行处理，然后更新一面的内容。如果这样，应用程序易受到基于DOM的XSS攻击。
基于DOM的XSS漏洞大致过程如图2-8：
图2-8 基于DOM的XSS攻击的实施步骤
2.2.3 路径遍历漏洞
如果应用程序使用用户可控制的数据、以危险的方式访问位于应用程序服务器或者其他后端中的文件和目录，就会出现路径遍历漏洞。通过提交专门设计的输入，攻击者就可以再被访问的文件系统中读取或者写入任意的内容。这种漏洞往往使攻击者能够从服务器上读取敏感信息或者重写敏感信息，并最终在服务器上执行任何指令。
在下面的示例中，应用程序使用一个动态页面向客户端返回静态图像。被请求的路径在查询字符串中指定：
http://localhost:8080/filestore/Getfile.jsp?filename=lb.jpg
当服务器处理这个请求时，它执行以下操作：
（1） 从查询字符串中提取filename参数值
（2） 将这个值附加在C:filestore参数之后
（3） 用这个名称打开文件
（4） 读取文件的内容并将其返回给客户端
漏洞之所以会发生，是因为攻击者可以将路径遍历序列(path traversal sequence)放入文件内，从低（2）步指定的图像目录向上回溯，从而访问服务器的任何文件。众所周知，路径遍历的表示为”点-点-斜线”(..),一个典型的攻击如下：
http://localhost:8080/filestore/Getfile.jsp?filename=..windowswin.ini
2.2.4命令执行注入
Shell注入(Shell Injection)，也被称为命令注入(Command Injection)，通常情况下，Web应用程序会有需要执行shell命令的时候，有可能只是使用Unix sendmail程序发送电子邮件，或运行指定的Perl和C + +程序。从开发的角度来看，这样做可以减少程序的开发时间。然而，如果数据是通过一个用户界面传递到这些程序中，则攻击者可能能够注入shell命令到这 些后台程序。
举一个简单的例子：
<?php
echo shell_exec('cat '.$_GET['filename']);
?>
看起来很好用，我们需要输出文件内容，直接用cat输出，比如同目录下有一个my_great_content.txt文件，那么请求的url就为：
www.mysite.com/viewcontent.php?filename=my_great_content.txt
开发只需要一行代码，就可以达到期望的功能。
但是不幸的是，这段代码是不安全的，攻击者只需要使用一个分号（;）就可以继续执行其他的命令。
www.mysite.com/viewcontent.php?filename=my_great_content.txt;ls
该页面除了返回文件内容之外呢，还返回了当前目录下的文件
2.2.5其他漏洞
其他漏洞的描述，如表2-3：
表2-3常见漏洞描述
|
内容 |
说明 |
|
任意文件执行 |
Web应用程序引入来自外部的恶意文件并执行 |
|
不安全的对象直接引用 |
攻击者利用Web应用程序本身的文件操作功能读取系统上任意文件或重要资料 |
|
信息泄露 |
Web应用程序的执行错误信息中包含敏感资料，可能包括系统文件路径，内部IP地址等 |
|
Session管理缺陷 |
Web应用程序中自行撰写的身份验证相关功能有缺陷 |
|
无URL限制 |
某些网页因为没有权限控制，可透过网址直接存取 |
2.3安全检测技术的发展
在Web应用出现的同时就伴随着Web安全漏洞问题了，只是早期阶段被发现的Web漏洞比较少。因此早期的Web漏洞检测一般是由Web管理员或者开发人员检测。
之后，伴随着Web应用的不断扩大，仅靠手工检测已经难以完成漏洞检测的任务，于是便出现了基于管理员角度的主机检测系统。再后来便出现了，基于攻击者角度的Web漏洞检测系统。
从以上可知，Web安全检测技术大致经历了三个阶段：手工检测阶段，基于管理的检测系统和基于攻击者的检测系统。一下对这三个阶段检测描述：
- 手工检测阶段
这是人们在早期的Web应用中的漏洞检测方法，由于当时Web应用规模还比较小，且当时被发现的漏洞比较少，因此管理员可以自己精湛的技术和经验对Web系统进行评估检测。但这种技术存在很大的认为因素，且和个人的经验密切相关，而且工作量很大。随着Web应用规模的不断增大，单靠管理员进行检测已经不可能了。
- 基于管理员角度的Web漏洞检测阶段
这是在手工检测阶段之后出现的一种检测技术。人们通过开发一种系统，从管理员的角度来设计检测系统。这种系统一般安装在需要扫描的系统之上，典型的有COPS，Tripewrite,Triger等。
这种系统是安装在本地上运行，可以减少网络流量，并且可以检测出更多的漏洞。
然而这种系统有着许多的不足，因为这种系统一般要安装在被检测的Web系统之上，而从服务器的角度来看，并不希望安装不确定的软件，而且大中型Web应用一般安装在分布式系统上，这也显然增加了检测成本。
- 基于攻击者的检测技术
这种方法是从“黑客”的角度出发，通过网络来扫描目标系统，进而发现网络服务，网络协议，操作系统等存在的安全威胁。
2.4 Web应用漏洞的检测方法
下面是几类常见的Web漏洞扫描器的检测技术：
2.4.1 模糊测试（Fuzzing）技术
模糊测试的主要目的是初步判定漏洞的存在，如果在模糊测试中判断存在漏洞，可以假设其危险等级为低度危险等级，并为后面的其他测试提供标准；若在其后的测试中确认其确实存在漏洞，更具不同的漏洞，来设置其危险等级。
许多重要的漏洞由无法预测的用户输入出发，并可能出现在应用程序的任何位置。用一组攻击字符串模糊测试每个请求的每一个参数，是在应用程序中检测这种漏洞的有效方法。如图2-9：
图2-9 模糊测试
模糊测试的步骤：
（1） 检查应用程序解析过程中获得的结果，确定所有提交给服务器应用程序处理的特殊客户参数。相关参数分别位于URL查询字符串、请求主题及HTTP cookie中。
（2） 对这些参数进行模糊测试。测试一系列可在特定的专门设计的输入的反常响应中轻易确定的常见漏洞。可以使用一组有效载荷测试一些常见的漏洞。
l SQL注入
‘
‘--
‘;waitfor delay ‘0:30:0’--
1;waitfor delay ‘0:30:0’ –
l XSS与消息头注入
xsstest
“><script>alert(‘xss’></script>
l OS命令注入
|| ping –i 30 127.0.0.1;x || ping –n 30 127.0.0.1&
| ping –i 30 127.0.0.1 |
& ping –i 30 127.0.0.1&
& ping –n 30 127.0.0.1&
; ping 127.0.0.1;
%0a ping –i 30 127.0.0.1 %0a
` ping 127.0.0.1 `
l 路径遍历
../../../../../../../ect/passwd
..............etcpasswd
../../../../../../../boot.ini
..............oot.ini
l 脚本注入
;echo 111111
echo 111111
response.write 111111
:response write 111111
l 文件包含
http://<your server name>/
http://<nonexistend IP address>/
（3） 在响应中寻找常见的错误消息，例如
Error
Exception
Xss
Illegal
Fail
Statck
Access
Directory
File
Not found
Varchar
ODBC
SQL
SELECT
111111
根据这些错误信息，可以快速定位漏洞的类型，比如Error,Exception,ODBC,Varchar，SQL,SELECT这些字符串可以初步判定存在SQL注入，若为Access，Directory，Not found可以初步判定存在为路径遍历或者文件包含，若为Xss可以初步判定存在跨站，若为111111可以初步判定为存在脚本注入
（4） 监控响应时间，更具响应时间的时差，初步判定OS命令执行
2.4.2 SQL注入检测技术
如果经过模糊测试后，标记为存在SQL注入，则进行如下测试，以确认SQL注入的存在。因为SQL注入分为数字型注入和字符型注入，因此需要对每个参数测试以下请求：
（1）orig-0
（2）orig-0-0
（3）orig-0-9
（4）[orig]’”
（5）[orig]’”
（6）[orig]\’\”
其中orig指的是初始的请求参数。用r表示请求结果。如果r(1)==r(2) and r(1)!=r(3)
则可以判断存在数字型SQL注入，如果r(4)!=r(5) and r(5)!=r(6)可以判断存在字符型SQL注入。
2.4.3跨站检测技术
如果经过模糊测试后，标记为存在XSS漏洞，则进行如下测试，以确认存在XSS漏洞，对于每一个参数，需要发送两个请求：
（1）>">'>'"<sp>
（2）.hacks>">'>'"<sp>
如果返回的状态码不是503,504，并且页面中含有(1)和（2）的参数，则可以确认含有跨站。
2.4.4目录遍历漏洞
如果经过模糊测试后，标记为存在目录遍历漏洞，则进行如下测试，以确认存在目录遍历漏洞，这里也分为两种，一种对于目录的，一种对于参数的：
对于目录的请求，包含5个:
（1）/
（2）/./
（3）/.sp/
（4）.
（5）.sp
如果r(1)!=r(2) and r(2)!=r(3)，这说明可能存在目录遍历漏洞，即可以遍历一个隐藏的漏洞；同样，如果r(1)!=r(4) and r(4)!=r(5)，也表明存在目录遍历漏洞
对于参数的请求，包含4个：
（1）…/known_val
（2）./known_val
（3）…known_val
（4）.known_val
如果r(1)!=r(2)或者r(3)!=r(4),表明我们的程序可能存在bug
2.4.5 命令执行漏洞的检测技术
如果模糊测试后，标记为命令执行漏洞，则进行如下9个请求，确认是否含有命令执行漏洞：
（1）`true`
（2）`false`
（3）`uname`
（4）"`true`"
（5）"`false`"
（6）"`uname`"
（7）'`true`'
（8）"`false`"
（9）'`uname`'
如果r(1)==r(2) and r(1)!=r(3),则可以确认含有命令执行漏洞，同理，对于其他项。
2.5本章小结
本章首先分析了Web应用程序的安全现状，然后给出了Web常见漏洞和漏洞的表现形式，之后介绍了Web安全检测技术的发展，最后介绍了Fuzzing检测技术，SQL注入检测技术，XSS检测技术，路径遍历检测技术和命令执行检测技术。
第3章 Web漏洞扫描器SearchPlan的关键技术
Web漏洞扫描器的关键技术包括两个方面：一个方面是页面请求/响应信息，一方面是响应处理信息。页面请求信息主要是通过加载有效载荷，构造HTTP请求（包括GET/POST请求），通过一定的技术，高效快速的向Web服务器发送有一定恶意字符的请求。通过这些特殊的请求来判断页面是否存在漏洞。页面处理信息是对页面响应的原始字符串进行处理，其中包括：提取URL，提取Javascript脚本，提取CSS，提取表单等。这些信息都会被页面渲染，是漏洞检测的基础。
3.1 页面抓取的目标与技术研究
3.1.1页面抓取的目标
页面抓取是扫描器SearchPlan的重要组成部分，页面抓取的全面性与高效性，直接影响着漏洞检测的质量和扫描器的运行速度，因此一个高效的页面抓取引擎是至关必要的。然而，网站页面错综复杂，页面链接直接没有固定的规律。假如仅是靠从一个链接种子开始，页面迅速回产生许许多多的分支，分支之间很可能有重复的链接，这些链接会构成一个网，使抓取变得无穷无尽；而且对于扫描器而言，扫描的目标往往仅仅是本站点，如果不考虑域外链接也会是扫描进入一个无穷尽的过程；而且链接直接有一定的重要程度。因此，如何设计一个扫描器引擎：既能抓取全面，又不会进入死循环，且能区分一定重要程度的引擎，是扫描器引擎设计的关键。
综上分析，扫描器引擎主要完成以下目标：
（1） 网站页面及其资源的完整性扫描。与搜索引擎的目标不同，扫描器的引擎，不仅要抓取搜索引擎能抓取到的页面，也要抓取到搜扫引擎抓取不到的页面，如robots.txt文件中的目录，因为这些目录往往使黑客们比较关注的地方，也是漏洞的常发区。
（2） 指定范围的扫描。与搜索引擎不同，扫描器引擎往往是对一个或几个站点进行扫描，因此不会像搜索引擎一样要处理海量数据。因此，扫描器引擎的抓取主要是在同域名的链接，并且是抓取页面响应的详细信息。
（3） 扫描引擎的高效性。Web服务是基于请求响应的，如果每次仅仅能发送一个请求，就会带来延迟，致使扫描器的效率很低。与扫描器的处理速度相比，网络延迟是扫描器效率的瓶颈，因此，更高的利用网络带宽是扫描引擎的一大目标。为了达到这个目标，可以使用网络异步套接字与多线程来完成。
3.1.2爬虫原理与抓取的技术选择
（1）网络爬虫的基本原理
爬虫就是一个自动下载网页的程序，它是扫描引擎的重要组成部分。爬虫是从一个或几个URL开始，然后获取指定URL的页面，并在此提取URL放入链表，这样一直进行下去，直到满足一定的终止条件为止。爬虫的工作流程比较复杂，需要根据一定的页面分析算法过滤与主题无关的连接，保留有用的连接，并将其放入待抓取链表中。然后根据一定的搜索策略，不断的重复以上过程，直到终止。其原理，可用如下流程图3-1表示：
图3-1 页面爬虫的基本原理
（2）网页搜索策略
网页抓取的搜索策略分为广度优先搜索策略，深度优先搜索策略和最佳搜索策略和网页重要度衡量四种。由于深度优先搜索策略会导致爬虫陷入深度过深，因此目前常见的是广度优先和最佳优先方法和网页重要度衡量。
1、广度优先策略
广度优先搜索策略是指在抓取过程中，在完成当前层次的搜索后，才进行下一层次的搜索。该算法的设计和实现相对简单。在目前为覆盖尽可能多的网页，一 般使用广度优先搜索方法。也有很多研究将广度优先搜索策略应用于聚焦爬虫中。其基本思想是认为与初始URL在一定链接距离内的网页具有主题相关性的概率很大。另外一种方法是将广度优先搜索与网页过滤技术结合使用，先用广度优先策略抓取网页，再将其中无关的网页过滤掉。这些方法的缺点在于，随着抓取网页的增多，大量的无关网页将被下载并过滤，算法的效率将变低。
图3-2中的数字显示了广度优先搜索顶点被访问的顺序
图3-2广度优先搜索顺序
实现广度优先搜索，要遵守三个规则：
(1) 访问下一个未来访问的邻接点，这个顶点必须是当前顶点的邻接点，标记它，并把它插入到队列中。
(2) 如果因为已经没有未访问顶点而不能执行规则1时，那么从队列头取一个顶点，并使其成为当前顶点。
(3) 如果因为队列为空而不能执行规则2，则搜索结束。
2、最佳优先策略
最佳优先搜索策略按照一定的网页分析算法，预测候选URL与目标网页的相似度，或与主题的相关性，并选取评价最好的一个或几个URL进行抓取。它只访问经过网页分析算法预测为“有用”的网页。存在的一个问题是，在爬虫抓取路径上的很多相关网页可能被忽略，因为最佳优先策略是一种局部最优搜索算法。因此需要将最佳优先结合具体的应用进行改进，以跳出局部最优点。研究表明，这样的闭环调整可以将无关网页数量降低30%~90%。
3、网页重要度度量
在面对海量网页数据的时候，如何尽可能的先抓取重要性的网页，这就要求爬虫在抓取网页时遵循一定的网页抓取规则。网页重要性通常由链接欢迎度、链接重要度、平均链接度这三个方面来决定。
² 链接欢迎度IB(P)，它可以通过反向链接的数目和质量来衡量。如果有很多网页指向一个网页，那表示其他网页对该网页的认可度很高。另外，如果有很多重要性高的网页指向它，那它的重要度也越高。
² 链接重要度IL(P),是一个关于URL字符串的函数，考察的是字符串本身，比如，认为包含顶级域名（如.com,home）等的URL重要性高，以及层次较少的URL重要度高。
² 平局链接深度ID(P),它表示网页离初始站点的距离，通常这个距离越短，表明该网页越容易被访问到，因此可以认为其重要度高。
网页重要度I(P)可以通过以上两个量化值线性觉得，即：
I(P)=a*IB(P)+b*IL(P)
上述的策略在网页抓取中被广泛应用，然而对于一个Web扫描器，在众多的页面中确定网页的重要度和最佳方案是十分困难的，而广度优先遍历，在多线程程序中，很难确保某个线程的结束来确认其深度，因此一般选用深度遍历策略。网络扫描器一般是从Web站点的根域名开始，这就保证了能够按照页面的URL逐层遍历网站。基于这些原因，本论文的设计是以广度优先作为扫描的策略。链接队列的实现主要是用一个双向链表来实现的，由于不同网页中可能包含指向同一网页的链接，因此在每次加入连接时都要判断是否已经在链表中出现。
3.2HTTP协议的研究与分析
HTTP 是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTP协议的主要特点可概括如下：
1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
HTTP协议协议消息结构图，如图3-2
图3-3 HTTP协议消息结构
3.2.1URL
http(s)(超文本传输协议)是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。
HTTP(S) URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：
http(s)://host[":"port][abs_path]？param1=value1&parm2=value2
http(s)表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，若为http,为空则使用缺省端口80；若为https，为空则使用缺省端口 443；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作 浏览器自动帮我们完成。后面的值，是请求的参数，第一个参数与路径直接用?连接，其后以param=value的键值对连接，两个参数之间用&连接
eg:
1、输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/search.jsp ？param=libo
3.2.2 HTTP请求
http请求由三部分组成，分别是：请求行、消息报头、请求正文，HTTP协议-请求报文格式如图3-4：
图3-4HTTP协议的请求报文格式
1、 请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF
其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。
2、 请求方法（所有方法全为大写）有多种，各个方法的解释如下：
GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET /form.html HTTP/1.1 (CRLF)
POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。
eg：POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,... (CRLF)
...
HOST:www.guet.edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) //该CRLF表示消息报头已经结束，在此之前为消息报头
user=jeffrey&pwd=1234 //此行以下为提交的数据
HEAD方法与GET方法几乎是一样的，对于HEAD请求的回应部分来说，它的 HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利用这个方法，不必传输整个资源内容，就可以得到Request-URI所标识的资源的 信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。
2、请求报头后述
3、请求正文(略)
3.2.3 HTTP响应
在接收和解释请求消息后，服务器返回一个HTTP响应消息。HTTP协议-相应报文格式如图3-5：
图3-5 HTTP协议-相应报文格式
HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文
1、状态行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
2、响应报头后述
3、响应正文就是服务器返回的资源的内容
3.3页面响应的提取
在得到页面的原始响应数据后，最重要的就是页面响应的提取，因为页面提取的内容一方面关乎着引擎的继续执行，一方面也是漏洞检测的基础。在页面的响应与提取中，主要完成提取新的链接并添加到链表、CSS的判断、JS的判断并判断XSS、搜集表单数据、提取响应状态码与表头信息。
3.3.1 URL的解析
根据以上的分析，一个标准的URL如下：
http(s)://host[":"port][abs_path]？param1=value1&parm2=value2
对于一些页内的URL可能为如下形式：
/Search？param1=value1¶m2=value2
对于第一种，我们可以根据：协议://主机:端口/路径？参数键值对来解析，对于第二种我们可以从它的参照格式中得到赋值，这个参照一般为父节点或者父父节点得到。
URL解析的主要目的是为攻击请求向量准备参数。在够杂请求参数时，根据转换请求的攻击向量逐个遍历替换请求参数，来达到自动构造的目的。URL的长度在各个浏览器中，都设置了一个默认的最大请求长度，因此我们需要对URL的长度加以限制。URL的解析是扫描器运行中的十分重要的一步，其大致过程如下：
(1) 判断URL是否大于最大URL长度MAX_LENGTH
(2) 寻找http:,若找到，则设请求协议为PROTO_HTTP,并使指针下移5个位置；若为https: 则设清楚协议为PROTO_HTTPS,并使指针下移6个位置;其它，则从参考URL中获取请求协议；如下示例：
初始URLhttp://localhost:8080/QR?param1=value1¶m2=value2
移动指针之后
URL为//localhost:8080/QR?param1=value1¶m2=value2
(3) 若当前两个字符不是//,则从参考链接中获得主机，地址与端口，否则，步骤（4）
(4) 寻找//,并移动当前指针2个位置，然后寻找是否含有下列字符串及其位置：:/?#；从当前位置到:/?#出现的地方为主机,并移动指针
初始URL为//localhost:8080/QR?param1=value1¶m2=value2
移动指针后URL为localhost:8080/QR?param1=value1¶m2=value2
Host为localhost，
移动指针后URL为:8080/QR?param1=value1¶m2=value2
(5) 若当前字符为：，用atoi函数把它转换为数字，记录为端口；若没有：，则若为http,设其端口号为80；若为https，设其端口号为443
(6) 寻找？,在当前位置之后，？之前，递归寻找/,并记录路径；若不存在？，整个作为路径
当前位置之后，？之前：/QR
(7) 在？之后，递归寻找&,寻找参数键值对
?之后，param1=value1¶m2=value2
其流程图如下：
图3-6 URL的解析
3.3.2URL的提取
URL提取的第一步，是分清URL在页面出现的位置，这样才能更加全面的提取链接。URL接主要出现在一下几个位置：
² 消息头中URL
（1） Location 响应头用于重定向接受者到一个新的位置
HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 12:55:57 GMT
X-Powered-By: ASP.NET
Location: 1.htm
Content-Length: 121
Content-Type: text/html
（2） Refresh 客户端向服务器发送该请求所属的网页的URL地址
例如：Refresh:http:www.baidu.com/
这类URL的提取，只需要找到对应对应标签所在行，然后提取“标签:”后的内容作为判断新URL的字符串
² 消息体URL
（1） meta标签，例子如下
<meta http-equiv="refresh" content="5; url=http://www.dreamdu.com/" />
这类URL的判断，首先用ISTAG()判断他是meta标签，然后查找”content=”,
如果存在，则在之后的字符串中提取”URL=”后的值，作为判断新URL的字符串
Object标签，例子如下：
<object classid="xxx "
codebase="http://download.macromedia.com/pub/ #version=6,0,0,0"
width="xxx" height="xxx" id="xxx" >
Embed标签，例子如下
<embed src="xxx "
type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer">
</embed>
Iframe标签，例子如下
<iframe id='iframe1' src='c1.html'></iframe>
Applet标签，例子如下：
<applet code="xx " width="350" height="350" codebase=”index.htm”>
一个绘制气泡动画的Java applet程序
</applet>
这类标签，首先用ISTAG()判断是这类标签，然后寻找”src=”出现的位置，提取”src=”后的值作为新的URL，如果“src=”不存在，寻找”codebase=”,然后提取之后的值，作为判断新URL的字符串
（2） Img标签，例子如下：
<img src="http://www.baidu.com"/>
这类URL的提取，首先用ISTAG()判断是IMG标签，然后提取”src=”的值作为判断新URL的字符串
（3） param 标签，例子如下：
<param name="movie" value="../../image/clock.swf" />
这类标签，首先用ISTAG()判断是PARAM标签且有“movie”属性，则提取“value=”的值，作为判断新URL的字符串
（4） script标签，例子如下：
<script type="text/javascript" src="index.html"></script>
这类标签，首先用ISTAG()判断是script标签，则提取“src=”的值，作为判断新URL的字符串
（5） link标签，例子如下：
<link rel="stylesheet" type="text/css" href="wgi.css"/>
这类标签，首先用ISTAG()判断是link标签且其含属性“stylesheet”，则提取“href=”的值，作为判断新URL的字符串
（6） form标签，例子如下：
<form action=”index.jsp” method=”post”></form>
这类标签，首先用ISTAG()判断是form标签，则提取“action=”的值，作为判断新URL的字符串
（7） 其他标签，如a,bgsound,例子如下
<a href=”index.jsp”></a>
这类标签，首先用ISTAG()判断是这类标签，则提取“href=”的值，作为判断新URL的字符串
² URL判断与添加
把以上可能是URL的字符串，传给parse_url函数解析URL，如果解析成功，则为正确的URL，然后调用maybe_add_pivot函数判断是否已经出现在链表中，如果没有出现，则添加到链表尾。
3.3.3 CSS的判断
由于CSS可能包含XSS，直接跳转，401,500错误，以及异常信息，因此我们需要一个函数，来判断这段字符串是否为CSS。
Css基本上分为两种情况：
（1） 外部CSS导入，即含有@import或者@charset字符串，这明显表明含Css，因此这类CSS的判断，只需要判断字符串中是否含有这些标签即可
（2） 页面内CSS，如
foo, .bar { ... }
* { ... }
foo#bar { ... }
foo[bar~="baz"] { ... }
foo > bar { ... }
这类CSS的判断，首先要判断字符处中是否含有.#_-*这些字符串，如果含有，就做一个标记，并且移动当前指针，如果当前指针的值已经不再是数字或者字符且含有:,.#_-*[]~="'>，表明它不是一个CSS，否则继续移动指针，直到当前字符为{,且前一个字符不是-_]*，则表明为CSS，判断的流程图如下：
图3-7 CSS判断流程图
3.3.4 Javascript脚本的判断
Javscript脚本的判断也包含两种，一种是含JSON数据的JS脚本，一种常规的Javascript脚本。我们的判断要在判断是CSS之后才有意义，因为CSS的语法中由于JS重叠的地方。我们可以定义一个静态字符串来判断常规的安全JSON脚本的前缀，
static const char* json_safe[] = {
"while(1);", /* Parser looping */
"while (1);", /* ... */
"while(true);", /* ... */
"while (true);", /* ... */
"&&&", /* Parser breaking */
"//OK[", /* Line commenting */
"{"", /* Serialized object */
"{{"", /* Serialized object */
"throw 1; <",/* Magical combo */
")]}'", /* Recommended magic */
0
};
普通的JS脚本的判断，是在当前字符中查找({["'，或者在当前字符之后查找=;，如果含有这些字符可以确认为Javascript脚本，流程图如图
图3-8 JS脚本判断
3.3.5表单数据的提取
Form表单的主要作用是：在网页中主要负责数据采集功能。一个表单有三个基本组成部分： 表单标签：这里面包含了处理表单数据所用CGI程序的URL以及数据提交到服务器的方法。表单域：包含了文本框、密码框、隐藏域、多行文本框、复选框、单选框、下拉选择框和文件上传框等。 表单按钮：包括提交按钮、复位按钮和一般按钮；用于将数据传送到服务器上的CGI脚本或者取消输入，还可以用表单按钮来控制其他定义了处理脚本的处理工作。
表单数据的提取主要是提取表单的各个属性，然后把这些数据放入到我们定义的结构体中，这样我们就可以逐个遍历表单数据，然后构造攻击向量，进而对页面进行测试。
页面参数的获得主要来自两个方面：一个方面是来自URL中，从URL获取请求参数，一类是来自表单。
一个典型的Form表单页面如图3-5：
图3-9 一个典型的Form表单
提取我们需要的信息，经过简化后，其页面的HTML代码如下：
<form method="post" name="register" action="register_yes.action" method=”POST”>
<input type="hidden" value="register_new" name="register"/>
用户名 *<input type="text" id="username" name="username" />
密码 *<input type="password" name="password" />
安全提问<select id="questionid" name="questionid" ><option value="0">无安全提问</option>
性别<input type="radio" name="gender" value="1"/> 男</label>
自我介绍<textarea rows="5" cols="30" id="bio" name="bio" ></textarea>
<input type="submit" value="提交" name="submit"/>
</form>
由上可知，对于表单的提取，我们主要关注的是form表单提交方法，form表单的action属性，input的name、value、type，select的name、id,option的value等。
Form表单的提取过程如下：
（1） 寻找开始位置<,与结束位置>，找不到，结束
（2） 寻找form,若找不到，结束
（3） 判断当前标签值是否为input,textarea,button,select,不是，结束
（4） 寻找name,value,type的位置
（5） 若name不存在，结束下面查找，继续进行下一标签查找
（6） 提取name的值，并对其html解码
（7） 提取value值，若value不存在，设为空
（8） 提取type值，若type不存在，设为text
（9） 请求参数数量增1
（10）判断type属性，若type为file,设其传输方式为post;若type为reset,请求参数数量减1；若type为submit或者button,如果存在value值，则使用其value值，若不存在，则设为空；若参数为checkbox,则设其参数为on,
（11）若字符串没有结束，转向（3）
其流程图，如图3-6：
图3-10 表单提取的流程图
3.4请求数据的构造
请求数据的构造，主要是按照GET,POST等数据的格式，附加上请求的参数来构成的。在请求参数中，会包含请求的主机名、请求的资源等具体内容。如上分析，请求主要有：请求行、消息报头、请求正文三部分组成。在构造请求时，必须考虑请求格式的正确性和浏览器之间的差异性。如果不考虑请求的格式，Web服务器是不能解析请求的；如果不考虑浏览器的差异，Web服务器会认为这也许是一个攻击性请求，而不语理睬。一个请求，除包含扫描器构造的请求载荷外，还应该包含以下参数：
Accept-Encoding：是浏览器发给服务器,声明浏览器支持的编码类型
Connection：与浏览器的连接状态；一般情况下，一旦web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了 Connection:keep-alive，则TCP连接在发送后仍将保持打开状态，于是，浏览器可以继续通过相同的连接发送请求，保持连接节省了为每 个请求建立新连接所需要的时间，还节约了网络带宽。
User-Agent：提供与浏览器或其他生成请求的客户端软件有关的消息。
Accept-Encoding：表示浏览器支持的压缩算法
Referer：表示请求的地址，也就是从那个页面来的
Cookie:是浏览器相服务器发送和当前网站关联的Cookie，这样在服务器端也能读取到浏览器端的Cookie了
Range: HTTP头中一般断点下载时用到Range, 指定第一个字节的位置和最后一个字节的位置，如（Range：200-300）
不同的浏览器，在请求输入的前后顺序是由差异的，这些在构造请求时也必须注意，如图3-11是Firefox的请求正文格式：
图3-11火狐请求正文格式
如图3-12是IE请求正文的格式：
图3-12 IE请求正文格式
可以看出两者的请求消息头的顺序是不一样的，且消息头中的默认参数时不一样的，作为一个扫描器，应该考虑这些差异性，且用户可以选择所使用的浏览器进行漏洞扫描。
通过以上的分析，构造HTTP请求的大致步骤如下：
（1） 用函数serialize_path序列化请求路径，放入path
如序列化后为：/auth/Details?uid=12
（2） 判断请求方法，若存在，使用请求方法；若为空，使用GET请求；按照请求格式加入path
如构造后：GET /auth/Details?uid=12 HTTP/1.1
（3） 加入主机名与协议端口
构造后：GET /auth/Details?uid=12 HTTP/1.1
Host: localhost:8080
（4） 判断所使用的浏览器类型，根据不同浏览器，加入Accept-Encoding, Connection, User-Agent等信息；
设使用浏览器为Firefox,则构造后为：
GET /auth/Details?uid=12 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 SF/29.0
（5） 指定Range范围，构造后如下：
GET /auth/Details?uid=12 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 SF/29.0
Range: bytes=0-25535
（6） 判断是否有Referer消息头，有，并判断是HTTP还是HTTPS，然后加入Referer，构造后：
GET /auth/Details?uid=12 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 SF/29.0
Range: bytes=0-25535
Referer: http://localhost
（7） 如果有Cookie,递归迭代加入Cookie载荷
构造后：
GET /auth/Details?uid=12 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 SF/29.0
Range: bytes=0-25535
Referer: http://localhost
Cookie:SessionID=88734834;username=898987
（8） 如果是POST请求，添加空行，递归迭代添加请求载荷，添加Content-Type属性，构造后：
POST /auth/Details HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 SF/29.0
Range: bytes=0-25535
Referer: http://localhost
Cookie:SessionID=88734834;username=898987
Username=libo&password=libo
构造请求的流程图，如3-13
图3-13 请求数据的构造
3.5辅助工具
在构造请求数据和解析请求数据的参数时，都是经过URL编码与解码的，因此，需要一个工具函数来完成URL的编码与解码的过程。许多网页中的请求数据，需要经过base64编码，因此也需要base64的编码函数。在分析漏洞时，往往要经过页面的比较，而如果仅仅是全部比较，不仅得不到想要的结果(如日期时间一定不一样)，而且效率低下，因此也需要一个页面比较的函数。在与字符串交互时，我们需经常涉及到内存的分配与回收，因此，我们需要一组安全的内存管理函数。
3.5.1 URL请求参数的编码与解码
² URL参数 decode
这里所做的事情是十分简单的，如果字符为"这样的字符，转换如下：
"代表”;
'代表’;
<代表<;
>代表>;
&代表&;
如果字符串是使用十进制ASCII码进行HTML编码，例如"代表”,'代表’,这种情况取&#之后的数字，然后把它转换为十进制数即可；
如果是使用十六进制数编码的ASCII编码（以x为前缀），如"代表”,'代表’,这种情况取&#x之后的数字，按十六进制数取出，即可解码。
从以上的分析可知，URL decode的大致过程如下：
(1) 判断当前字符是否为&，如果不是，却是 或者 ,则继续，否则直接把当前值作为转码结果
(2) 在当前字符后，若为amp;quot;lt;gt;直接转换为对应字符&,’,<,>
(3) 若当前字符之后的一个字符为#，且紧接其后的字符为x,把其转换为对应的十六进制数并加空格
(4) 若不是x,转换为对应十进制数，见空格
² URL参数 encode
URL参数encode的过程，是decode的一个反过程，由于篇幅的原因，不再赘述
² URL标示的decode
在URL中，用+代表空格，用%3d代表=，用%25代表%，它是这样一种对应关系，如果是+号，则直接转换为空格(‘ ’)，如果是以%开头的且长度大于等于3的话的话，取%后一个字符（即第二个）查找其离十六进制字符表（0123456789abcdef）的距离，右移四位，在找第三位与十六进制字符表的距离，两者取“或”运算，记得到其对应ACSII码，例如：
%3d,3在表0123456789abcdef的距离为3，左移4位为48，d与表0123456789abcdef距离为13，两者取“或”为61，对应的ASCII字符为=
² URL标示encode
是URL标示encode的反运算，不再赘述
3.5.2 Base64的编码与解码
早期邮件中都是明文,这在英语国家,并且没有附件的情况下是合适的 (那里网络还不是很普及 并且网络速度很慢),但是后面随着internet的发展 人们希望传送除了英语以外的其它东西 如应用程序等 同时其它国家也希望使用自己本国语言来写邮件因此产生了对在邮件中传送二进制的要求,邮件的传送是以明文方式传送的
如果直接传送二进制 那邮全服务器可能会理解错 如把正文中内容错理解成指令(想想二进行中的 等特殊字符) 所以发明了base64编码,使用64个可打印字符对内容进行编码,这64个字符是
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
在网页传输中，许多URL同样是经过Base64编码的，比如迅雷的链接，都是Base64编码的。由于要对Web应用程序全面的扫面，因此需要Base64编码解码工具。
编码原理是: 把3个字节使用上面的字母进行转换，转换成4个字节，每个字节都只有6bit
第一个字节由第一个byte的高6位组成
第二个字节的高位由第一个byte的低二位组成，低4位由第二个byte的高4位组成
第三个字节的高位由第二个byte的低四位组成，低2位由第三个字节的高2位组成
第四个字节是剩下的bit
代码的实现，由于篇幅原因不再赘述
3.6 本章小结
本章首先讲述了网页抓取的技术选择，以及本扫描器抓取的选择；然后讲述了HTTP请求与相应的格式；之后分析了URL的格式与解析；之后分析了页面响应的处理：CSS的判断，JS的判断，表单的搜集；之后分析了请求的构造以及不同浏览器之间的差异；最后分析了一些常用的工具，URL的编码与解码与Base64的编码与解码。
第四章 Web扫描器SearchPlan的概要设计
4.1 Web漏洞扫描器的基本原理
在设计Web漏洞扫描器之前，有必要对对扫描器的基本原理加以研究与分析。Web漏洞扫描器的扫描工作原理是，首先探测目标系统的活动主机，对活动主机发送构造的请求数据，然后通过网络应用程序取到Web服务器的响应数据。然后解析应用程序的内容，并浏览其功能。之后提取它的每一个参数，并在每一个参数中提交一个测试字符串，然后分析应用程序的响应，从中查找常见漏洞的签名。接下来，扫描器生成一个报告，描述它发现的每一个漏洞。通常这份报告中包括用于诊断每一个被发现的漏洞的请求与响应，允许经验丰富的用户对它们进行手工调查，确认漏洞是否存在。
4.2Web漏洞扫描器SearchPlan的概要设计
通过以上的分析，一个Web漏洞扫描器至少完成以下功能：
（1） 应用程序的抓取
（2） 漏洞的准确检测
（3） 报表的生成与漏洞描述
除了以上特点外，一个Web漏洞扫描器还应满足高效，能在较短时间内做大量测试，并且易扩展、易操作。基于这些要求，SearchPlan的大致设计如下：
图4-1 SearchPlan的总体框图
SearchPlan的各个模块的功能如下：
引擎调度模块：主要是负责各个攻击向量的分发请求，以及漏洞的判断。无论扫描模块增多或者是减少，都不会影响扫描器的执行，是一个独立的模块。
页面分析模块：主要是被各个攻击向量模块调用，一方面用于页面的提取，一方面用于漏洞的判断。
网络模块：主要利用网络API，完成请求的发送与接收。
配置模块：主要是配置加载资源的顺序以及暴力破解的资源
数据中心模块：主要是完成数据的读写，排序，配置资源的加载以及暴力破解关键字的加载。
报表模块：主要更具引擎调度模块的扫描结果，按照某种格式写文件
结论
结论作为学位论文正文的最后部分单独排写，但不加章号。
结论是对整个论文主要结果的总结。在结论中应明确指出本研究的创新点，对其应用前景和社会、经济价值等加以预测和评价，并指出今后进一步在本研究方向进行研究工作的展望与设想。结论部分的撰写应简明扼要，突出创新性。
参考文献
[1] 中华预防医学会慢性病预防与控制分会. 慢性病的流行形势治对策[J]. 中国慢性病预防与控制, 2005, 13(1): 1-3.
[2] 中国疾病预防控制中心. 中国慢性病报告[Z]. 2006.5.
[3] 骆华伟. 慢性心脑血管病的健康管理模式探讨[J]. 浙江预防医学,2006,18(9): 56-57.
[4] 陈建勋, 马良才, 于文龙. “健康管理”的理念和实践[J]. 中国公共卫生管理,2006,22(1): 7-10.
[5] MB Rosenman, AM Holmes, RT Ackermann, et al. The Indiana Chronic Disease Management Program[J]. Milbank Q, 2006,84(1): 135-163.
[6] 赖秀江等. 虹口区肿瘤防治计算机数据管理系统的设计和应用[J]. 上海预防医学杂志, 2000, (1).
[7] 上海市虹口区卫生防疫站. 脑血管疾病防治体系[J]. 中国公共卫生学报, 1996,(15).
[8] 王柏兴等.上海市虹口区1574例高血压患者的死因分析[J]中国慢性病预防与控制杂志,1995, 3(6).
[9] 龚沛曾等. Visual Basic程序设计教程[M]. 北京:高等教育出版社, 1998.
[10] 认证信息系统安全专家教程. [美] Ed Tittel, Mike Chapple, James Michael Stewaret, 赵著, 魏巍等译. 北京: 电子工业出版社, 2000.
[11] 马晓玉, 孙岩, 孙汪玮等著. 数据库管理应用与开发标准教程. 清华大学出版社. 2007.
[12] NIST/ITL Bulletin, AN INTRODUCTINO TO ROLE一BASEADCCESS CONTROL. http : // csrc. nist.gov/rbac/, 2004, 01.
[13] David Ferraiol&oRichard Kuhn . Role一Based Access Controls.15th Nationa1 Computer Security Conference, 1992.
[14] R.Chandramouli&R.Sandhu, Role-Based Access Contro1 Features in Commercial Database Management Systems. Zlst National Information Systems Security Conference, 1998.
[15] 趣京. 数据库课程设计案精编. 中国水利水电出版社. 2006.
[16] 柴晓路, 梁宇奇著. Web Services技术、架构和应用: 电子工业出版社, 2003.1.
[17] Web服务概念性体系结构(WSCA). httpJ/www-90O. erLibm. com/ developerworks/ cn/ webservices/ws-wsca/part4/index.shtml,2002.
[18] 邵敏, 李力鸿. XML编程实践一网络上的世界语, 清华大学出版社, 2002.1.
[19] 曾铮, 吴明晖, 应晶. 简单对象访问协议SOAP综述. 计算机应用研究, 2002.02.
[20] William Stallings. Cryptography and network security principles and practice second edition(M). Beijing: Publishing House of Electronics Industry, 2000.
[21] Kent S and Atkinson R. IP encapsulating security payload (ESP)(S). RFC 2406, November 1998.
[22] M.T.Ozsu and P.Valduriez, Principles of Distributed Database Systems, Prentice-Hall, Englewood Cliffs NJ.
[23] 林丰, 李嫒, 李绿漪, 陈余凤. 基于Web技术的大众健康管理系统设计及意义初探.医学信息, 2006, 19(9): 1492.
[24] Peter B.Southard, Soongoo Hong,Keng Siau.Information Technology in the Health Care Industry: A Primer.IEEE Symposium on Computer-Based Medical Systems(CMB01): 79—88.
附录
有些材料编入文章主体会有损于编排的条理性和逻辑性，或有碍于文章结构的紧凑和突出主题思想等，这些材料可作为附录另页排在参考文献之后，也可以单编成册。下列内容可作为附录：
（1）为了整篇论文材料的完整，但编入正文有损于编排的条理性和逻辑性的材料，这一类材料包括比正文更为详尽的信息、研究方法和技术等更深入的叙述，以及建议可阅读的参考文献题录和对了解正文内容有用的补充信息等；
（2）由于篇幅过大或取材的复制资料不便于编入正文的材料；
（3）不便于编入正文的罕见珍贵资料；
（4）一般读者无须阅读，但对本专业同行有参考价值的资料；
（5）某些重要的原始数据、推导、计算程序、框图、结构图、注释、统计表、计算机打印输出件等。
附录的序号用A，B，C……系列，如附录A，附录B，……。附录中的公式、图和表的编号分别用各自的附录序号后标1，2，3……系列来表示，如A1，A2，……系列；图A1，图A2，……系列；表A1，表A2，…系列。每个附录应有标题。
攻读学位期间发表的论文与研究成果清单
应列出攻读学位期间发表的与学位论文内容相关的学术论文和研究成果，按发表的时间顺序列出，研究成果可以是在学期间参加的研究项目、获得专利、获奖情况等。
致谢
致谢是对下列方面致谢：资助和支持者；协助完成研究工作和提供便利条件者；在研究工作中提出建议和提供帮助者；给予转载和引用权的资料、图片、文献、研究思想和设想的所有者；其他应感谢者。致谢语言要诚恳、恰当、简短。