毕业设计（论文）-ASP.NET高铁车票订票系统—前台设计

毕业设计（论文）-ASP.NET高铁车票订票系统—前台设计 苏州高博软件技术职业学院毕业设计(论文) 高铁车票订票系统—前台设计 摘 要 本文是针对高铁车票订票实际情况，按照软件工程的结构化设计思想,经过项目的可行性研究和需求)数据库设计)总体设计)详细设计，以及代码的实现和测试等步骤设计开发了高铁车票订票系统。运用了数据流图和数据字典)E-R图和数据库逻辑结构)层次图)系统流程图以及程序流程图，对该系统的数据需求)数据库)系统软件结构)系统流程)以及处理过程等进行了分析和设计。 软件工具应用了asp.net和Microsoft SQL Server 2005数据库来开发这个高铁车票订票系统。该系统可以解决的是高铁车票订票系统所要解决的问题，可以基本满足高铁车票订票的基本要求，包括会员注册、车次查询、车票预订、费用在线支付、订单查询/修改、个人信息维护模块、留言板、订票须知、信息公告，其中主要实现了查询、订票、退票等三个方面的功能。该系统能运用到高铁的订票工作中,可以根据用户的需求设者其权限,方便快捷的为用户提供服务。 关键词:信息管理;高铁售票;asp.net ;Microsoft SQL Server 2005 1 苏州高博软件技术职业学院毕业设计(论文) High iron ticket system —front desk design Abstract This article focuses on the actual situation of high-speed rail ticket booking， structured according to the software engineering design, talked about the project feasibility study and needs analysis 、Overall Design, Database Design, detailed design, and code implementation and testing procedures designed and developed high-speed railway ticket booking system。The use of a data flow diagram and ER diagrams and data dictionary ) logical structure or hierarchy database ) system flow chart diagram and process flow chart, the data needs of the system software 、 database structure or system processes ) and processing were analyzed And design。 The asp.net application software development tools and Microsoft SQL Server The system can 2005 database to develop the high-speed railway ticket booking system。 solve the problem of high-speed rail ticket booking system to solve the problem。You can basically meet the high-speed rail ticket booking, the basic requirements, including membership registration, train number, ticket booking, for online payment, order inquiry / modification Personal information maintenance module, message board, booking instructions, information bulletin, mainly to achieve the query, ticketing, refunds and other three functions。The system can be applied to work in high-speed rail bookings, according to the needs of users who set their permissions to provide users with convenient and efficient service. Keywords: information management; high-speed rail ticketing; asp.net; Microsoft SQL Server 2005 2 苏州高博软件技术职业学院毕业设计(论文) 目 录 第1章 绪论 ........................................................................................................................................... 5 1.1 引言 ............................................................................................................................................ 5 1.2 国内外现状................................................................................................................................. 5 1.3 课题意义 .................................................................................................................................... 6 1.4 应用范围 .................................................................................................................................... 6 第2章 系统地可行性研究与需求分析 .................................................................................................. 7 2.1 可行性分析................................................................................................................................. 7 2.1.1 法律方面的可行性 .......................................................................................................... 7 2.1.2 使用方面的可行性 .......................................................................................................... 7 2.1.3 经济可行性 ...................................................................................................................... 7 2.1.4 技术可行性 ...................................................................................................................... 7 2.1.5 操作可行性 ...................................................................................................................... 7 2.2 需求分析 .................................................................................................................................... 7 2.2.1 功能需求 .......................................................................................................................... 7 2.2.2 数据需求 .......................................................................................................................... 9 2.2.3 性能需求 .......................................................................................................................... 9 2.2.4 数据流图 ........................................................................................................................ 10 2.2.5 数据字典 ........................................................................................................................ 10 2.2.6 实体–联系图 .................................................................................................................. 11 第3章 数据库设计 ............................................................................................................................... 13 3.1 SQL Server 2005数据库简介 ................................................................................................... 13 3.2 系统数据库结构设计 ............................................................................................................... 13 3.2.1 车次表............................................................................................................................ 13 3.2.2 订单表............................................................................................................................ 13 3.2.3 售票表............................................................................................................................ 14 3.2.4 系统表............................................................................................................................ 14 3.2.5 退票表............................................................................................................................ 14 第4章 系统的总体设计........................................................................................................................ 15 4.1 系统软件的结构设计 ............................................................................................................... 15 4.1.1 软件结构 ........................................................................................................................ 15 4.1.2 模块算法 ........................................................................................................................ 15 4.2 系统流程图............................................................................................................................... 17 第5章 系统的详细设计........................................................................................................................ 19 5.1 用户操作业务流程图 ............................................................................................................... 19 5.1.1 用户系统主程序流程图。如图5.1 所示: ................................................................. 19 5.1.2 车次信息查询业务流程图.如图5.2所示: ................................................................... 20 5.1.3 订票处理流程图.如图5.3所示: ................................................................................... 21 5.1.4 订票信息查询处理流程图.如图5.4所示: ................................................................... 22 5.1.5 退票处理流程图.如图5.5所示: ................................................................................... 23 5.2 接口设计 .................................................................................................................................. 24 3 苏州高博软件技术职业学院毕业设计(论文) 5.2.1 用户接口 ........................................................................................................................ 24 5.2.2 外部接口 ........................................................................................................................ 24 5.2.3 内部接口 ........................................................................................................................ 24 5.3 详细页面设计........................................................................................................................... 24 5.4 物理结构设计要点 ................................................................................................................... 24 5.4.1 系统登录主界面 ............................................................................................................ 25 5.4.2 售票车票系统的主界面 ................................................................................................ 25 5.4.3 车票预定系统主界面 .................................................................................................... 25 5.4.4 退票系统主界面 ............................................................................................................ 27 第6章 测试 ........................................................................................................................................... 28 6.1 数据与数据库完整性的测试 ................................................................................................... 28 6.2 功能的测试............................................................................................................................... 28 6.3 业务周期测试........................................................................................................................... 28 6.4 用户界面的测试....................................................................................................................... 29 结 论 ..................................................................................................................................................... 30 致 谢 ..................................................................................................................................................... 31 参 考 文 献 ........................................................................................................................................... 32 附录A 译文 .......................................................................................................................................... 33 附录B 外文原文 .................................................................................................................................. 40 4 苏州高博软件技术职业学院毕业设计(论文) 第1章 绪论 1.1 引言 1969年，美国IBM公司首次宣布除操作系统继续随计算机配送外，其余软件一律计价出售，从此开创了软件成为独立商品的先河。短短四十几年的时间，计算机软件的重要性与日俱增。从PC机到笔记本电脑，从因特网到移动电话，从先进的武器到现代的家电，计算机软件几乎无处不在，无时不在。世界上最大的软件公司微软公司及其创始人，已成为全球知名度最高的企业之一。在很多发达国家，软件产业已成为社会的支柱产业，软件工程师也成为最受青睐的一种职业。 正是由于软件的发展，使计算机应用逐步渗透到社会生活的各个角落，使各行各业都发生了很大的变化。这同时也促使人们对软件的品种，数量，功能和质量等提出了越来越高的要求。然而，软件的规模越大，越复杂，人们的软件开发能力越显得力不从心。于是，人们开始重视软件开发过程，方法，工具和环境的研究，软件工程应运而生。 软件工程技术历经四十多年的发展，目前已进入成熟期。软件过程改善的热潮使软件企业对软件工程技术的认识有了质的飞跃，正在被越来越广泛地接收。过程改善和技术提升的结合是软件产业发展的趋势。软件复用和软件构件技术，再工程技术及领域工程技术正逐步成为主流软件技术，是软件工程化，工业化生产技术的核心技术。也推动了一些行业的发展，比如说票务方面，本次设计我选择了具有比较典型的并且有一定实际应用价值的课题----高铁车票订票系统。 1.2 国内外现状 “目前，从技术上看，软件开发的主要模式仍以手工作坊式为住，但工程化技术的采用呈稳步上升趋势。软件企业的过程改善，规范化，规模化正成为一种趋势。推行软件的工程化，工业化生产技术和模式是软件企业发展并形成规模经济的必由之 路，这已成为学术界和产业界的共识。” 当前，学术界和产业界的共识是:在注重软件工程技术研究的同时应注重软件过程的研究;软件开发单位不仅需要技术创新(采用先进技术)，更需要将其过程改善放在首位。过程改善和技术的紧密结合才是完善的软件开发解决方案。 5 苏州高博软件技术职业学院毕业设计(论文) 进入九十年代以来，软件过程研究及企业过程改善成为热潮，和软件工程技术研究及企业技术创新受到同等重视，两方面都得到了长足的发展。在技术方面，软件工程技术不断发展，软件工具市场不断扩大。 我国政府支持的国家重点科技攻关项目青鸟工程长期从事对软件工程技术的研究，在上述几方面及其集成上均有卓有成效的成果，保持了和国际前沿同步，同时，为我国软件产业基础设施建设以及软件工程学科建设做出了积极贡献。 1.3 课题意义 随着高铁的兴起,火车站市场的管理和规范问题,已经是困扰我们多年的一个老问题,也是政府部门管理中的一个重点、难点.订票是客运业务中的一个最最基本的业务,从表面上来看,它只是高铁业务中的一个简单部分,但是它涉及到管理与客户服务等多方面的问题,因此,过去传统的售票方式远远不能够满足现代客运业务流量急速增长的趋势,这就要求研发出一种全新的订票方式来满足客户的需要,那就是网上订票,这种方式可以大大地缓解车票订购高峰时期的客运压力,并可以为用户提供方便快捷的订票服务. 1.4 应用范围 高铁车票的管理和规范问题，是困扰我们多年的一个老问题，也是政府管理中的一个难点，订票是客运业务中的一个最基本的业务，表面上看，它只是长途客运业务的一个简单的部分，但是它涉及到管理与客户服务等多方面，因此，过去传统的售票方式已经不能满足现代客运业务流量剧增的客观要求，这就要求一种全新的订票方式——网上订票，来缓解订票高峰时期的客运压力，并为用户提供方便快捷的订票服务。本次设计便是利用开发工具asp和SQL Server 2005数据库共同开发的一个高铁车票订票系统，它能方便快捷地运用在订票业务的营运之中。 本系统设计主要是根据订票业务的基本流程进行的，系统功能主要包括如下几个方面:查询:分为对信息的查询和客户对已订车票信息的查询订票:通过查询系统，客户根据自己的需求找到满意的车次，直接通过网上订票确定已预订选中的高铁车票。 6 苏州高博软件技术职业学院毕业设计(论文) 第2章 系统地可行性研究与需求分析 2.1 可行性分析 该阶段主要通过对系统目标地初步调研和分析,从而提出可行性方案并进行研究 我在这主要从法律方面的可行性、使用方面的可行性、经济可行性、技术可行论证. 性、操作可行性五方面进行分析论证。 2.1.1 法律方面的可行性 该系统的开发和研制,将不会侵犯他人、集体和国家的利益,不会违反国家的相关政策和法律。 2.1.2 使用方面的可行性 该系统操作简单,需要高铁售票人员熟悉业务流程,一般的工作人员即可胜任。 2.1.3 经济可行性 由于本系统是为了高铁车票订票所使用的系统,安装该应用程序,即可马上使用此系统,系统成本主要集中在系统软件的开发上,当系统投入运行后,可以节省大量的人力、财力、物力,所带来的经济效益是远远大于系统软件的开发成本。所以,从经济的角度来看,是完全可行的。 2.1.4 技术可行性 开发工具: asp.net 数据库环境: Microsoft SQL Server 2005 系统环境: Microsoft Windows 2005或以上版本 系统实现依靠开发工具asp.net和Microsoft SQL Server 2005数据库系统,其基本操作实质还是对数据库进行查找、删除、添加等操作,暂时没有技术问题。 2.1.5 操作可行性 界面设计时,充分考虑了使用人员的习惯,界面友好简洁,操作方便;数据输入简单、迅速、规范、可靠;统计、计算准确等优点。 2.2 需求分析 需求分析是软件设计的一个极其重要的环节。本阶段将对高铁车票订票系统的应用情况作出全面了解,以确保系统的目标,并对系统所需要的相关数据以及数据处理要求进行分析,从而确保用户的需求。用户对系统的需求我将从以下几方面进行分析。 2.2.1 功能需求 7 苏州高博软件技术职业学院毕业设计(论文) 本高铁车票订票系统应该具备如下功能: (1) 会员注册 此系统通过注册会员成为本系统的会员,来获得用户名和密码,才能进入本系统。 (2) 车次查询 车次查询分为对车次信息的查询和客户对已订车票信息的查询.要求: 1) 对车次的查询,可以按照发车车次进行查询。 2) 车次信息包括:车号、出发地、目的地、发车日期、开出时刻、票价。 3) 座位类型设定:软座和硬座。 4) 车次信息只允许用户查询,不能修改。 (3) 预定车票 通过查询系统,客户根据自己的需求找到满意并适合自己的车次,再输 入个人信息后直接通过网上订票确定并预定选中的车票.要求: 订票记录包括:车号、种类、开车时间、车票价格。 (4) 取消预订 由于某些原因,或者突发情况,无法赶到预定车票的时间,客户通过退 回车票,可以找到预定的车票,可以通过取消预定来退去已购车票。 (5) 留言板 通过留言板你可以发表心中的疑惑,对高铁的一切情况,也可以发表自 己的见解.对售票人员的服务满意度,对高铁上服务人员的看法等问题都可 以通过留言板来留言,让管理人员及时了解情况,以便迅速做出调整,做到每 一个乘客满意放心。 (6) 订票须知 通过订票须知,可以回答你一些简单的疑惑,如高铁上不允许带的违禁 物品,坐高铁要注意的事项,多少升高以下的儿童可以免票等相应的情况, 你可以通过订票须知知道.因此,在订票之前,不妨仔细阅读一下须知,详细 了解乐坐高铁的种种事项后,再开始订票。 (7) 信息公告 8 苏州高博软件技术职业学院毕业设计(论文) 通过信息公告,可以让乘客知道高铁是否运行,有时可能由于天气原因 等情况,火车站会采取停止高铁的运行,这些信息可以通过信息公告来知道, 以便乘客能够及时知晓,对订票有很大的帮助。 2.2.2 数据需求 数据需求,即在系统中需要处理的数据.根据对高铁车票订票系统的分析,本系统的数据需求。如表2.1所示: 信息输入 信息处理 信息输出 用户输入所需车次 检索系统数据库 显示出符合用户需求的车次 及相关 信息 用户输入个人信息及所需订 更新系统中的订票信息， 操作反馈(如订票成功) 购的车票信息 将新信息存入系统数据库 用户输入自己的名字、身份 检索系统数据库 符合用户需求的订票信息 证号;或交易的订单号 用户输入自己的名字 检索系统数据库以得到订票 显示出操作反馈(如退票成 记录，删除用户请求的订票 功等) 记录，更新系统数据库 表2.1 信息输入输出 2.2.3 性能需求 为了保证系统能够长期、安全、稳定、可靠、高效的运行，本系统应该满足以下的性能需求。 (1) 准确性和及时性 系统处理的准确性和及时性是系统的必要性能。系统应能及时而且准确的根据用户权限及所输入的信息做出响应。由于本系统的查询功能对于整个系统的功能和性能完成举足轻重。作为系统的很多数据来源，而车票的数量和时间又影响用户的决策活动，其准确性和及时性很大程度上决定了系统的成败。在系统开发过程中，必须采用一定的方法保证系统的准确性和及时性。 (2) 易用性 本系统是直接面对用户的，而用户往往对计算机并不是非常熟悉。这就要求系统能够提供良好的用户接口，易用的人机交互界面。要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面，从而保证系统的易用性。 (3) 安全性 9 苏州高博软件技术职业学院毕业设计(论文) 网上订票系统中涉及到的数据是客运公司相当重要的信息，系统要保证用户的权限，对于车次等信息用户只享有查询服务，不得更改;系统还要提供方便的手段供系统维护人员进行数据备份、日常安全管理、以及系统意外崩溃时数据的恢复等工作。同时系统还要保证对数据库进行及时更新，保证数据一致性。 2.2.4 数据流图 本系统的数据流图如图2.2所示: 车次信息 用 车次 反 用 事务 事务 事务 事务 更新 信息 订 接收 接收 更新 数据 馈 户 户 票 事务 事务 数据 库 库 用户信息 订单信息 用户信息 订单信息 接收事务 事务 事务 接收事务 事务 用 反馈 事务 事务 事务 更新 接收事务 户 退票 查询订单 数据 库 事务 用 反馈 事务 更新数据库 修改订单 户 图2.2 数据流图 2.2.5 数据字典 如图2.3—2.5所示: 名字:车次信息 别名: 描述:存放车次信息的文件，以供用户查询 定义:车次信息=车号+出发地+目的地+发车日期+开出时刻+到达时刻+ 坐位类型+ 票价 位置:输出到CRT终端或类似的显示部件 10 苏州高博软件技术职业学院毕业设计(论文) 图2.3 车次信息数据字典 名字:订票信息 别名:订单信息 描述:存放订单信息的文件，以供用户查询，并作相应操作 定义:订票记录=用户名+车号+发车日期+订购日期+订购票数+总价 位置:输出到CRT终端或类似的显示部件 图2.4 订票信息数据字典 名字:会员信息 别名:用户信息 描述:存放会员信息的文件，以供会员方便的查询订单信息，进而做出相应的操 作 定义:会员信息=真实姓名+身份证号+性别+籍贯+联系电话 位置:输出到CRT终端或类似的显示部件 图2.5 会员信息数据字典 2.2.6 实体–联系图 用户的需求具体体现在各种信息的提供、保存、更新和查询，这就要求数据库结构能充 分满足各种信息的输出和输入。 针对火车站网上订票系统，通过对网上订票工作的过程、内容以及数据流程分析，设计 如下所示的数据项和数据结构: 1)车次信息包括:车号、出发地、目的地、发车日期、开出时刻、剩余座位数、票价。 2)订票记录包括:订单号、身份证号、车号、订购日期、订购票数、总价。 3)会员信息包括:真实姓名、身份证号、性别、籍贯、联系电话。 E-R图如图2.2所示: 11 苏州高博软件技术职业学院毕业设计(论文) 真实姓性别 名 籍贯 电话 车 会员 次 m 1 1 退票 查询 订票 票坐位类 n n 价 n 型 车次 订票信息 总价 订单号 开出 订购票数 目的地 车号 发车日期 时刻 订购日期 用户身份证号 发车日期 出发地 图2.6 实体–联系图(E-R图) 12 苏州高博软件技术职业学院毕业设计(论文) 第3章 数据库设计 3.1 SQL Server 2005数据库简介 Microsoft的SQL Server作为众多数据库软件的一种，是网络世界的一个支撑。 从20世纪80年代后期开发SQL Server,到2005年底SQL Server 2005的发布，Microsoft经历十几年的磨练,使SQL Server从无到有，从小到大，而且新一代的SQL Server已经开始逐渐成为Windows操作系统未来的核心，成为主流数据库软件。 SQL Server 是一个关系数据库管理系统。它最初是由Microsoft Sybase 和Ashton-Tate三家公司共同开发的，于1988 年推出了第一个OS/2 版本。在Windows NT 推出后，Microsoft与Sybase 在SQL Server 的开发上就分道扬镳了。Microsoft 将SQL Server 移植到Windows NT系统上，专注于开发推广SQL Server 的Windows NT 版本。Sybase 则较专注于SQL Server在UNIX 操作系统上的应用。到了2005年底，Microsoft公司经过5年的努力，推出了其最新版本SQL Server 2005。 3.2 系统数据库结构设计 高铁车票订票系统数据库忠各个表格的设计结果如下表所示.每个表格分别表示在数据库中的一个表. 3.2.1 车次表 字段名 数据类型 是否可空 Cid int NOT NULL 车号(主键)0 Carname varchar(50) NOT NULL 车名 CType varchar(50) NOT NULL 车次类型 表 3.1 车次表 3.2.2 订单表 字段名 数据类型 是否可空 说明 Oid int NOT NULL 订单号(主键) OCar varchar(50) NOT NULL 车号(外键) Oticketype varchar(10) NOT NULL 订票类型 ObuyTime datetime NOT NULL 订单时间 13 苏州高博软件技术职业学院毕业设计(论文) Ousetime datetime NOT NULL 发车时间 Omoney money NOT NULL 价格 Oadmin varchar(50) NOT NULL 用户名 表3.2 订单表 3.2.3 售票表 字段名 数据类型 是否可空 说明 Sid int NOT NULL 车号(主键) SCar varchar(50) NOT NULL 车次(外键) SticketType varchar(10) NOT NULL 车次类型(外键) Stime datetime NOT NULL 发车日期(外键) Smoney money NULL 价格 Sadmin varchar NULL 用户名 表3.3 售票表 3.2.4 系统表 字段名 数据类型 是否可空 说明 Sysid in NOT NULL 车号(主键) SysBuyTime varchar(50) NULL 买票时间 SysOrderTime varchar(50) NULL 订票时间 SysuipiaoTime Varchar(50) NULL 退票时间 表3.4 系统表 3.2.5 退票表 字段名 数据类型 是否可空 说明 Tid int NOT NULL 退票车号 Tname varchar(50) NOT NULL 退票类型 Ttime datetime NOT NULL 退票时间 Tmoney money NULL 退票价格 表3.5 退票表 14 苏州高博软件技术职业学院毕业设计(论文) 第4章 系统的总体设计 4.1 系统软件的结构设计 4.1.1 软件结构 本高铁车票订票系统可划分为信息查询、网上订票、取消订票三个部分。其 中信息查询又可分为车次查询和订单查询两个部分。其层次图如图4.1所示。 火车票网上订票系统 网上订票 信息查询 取消订票 车次查询 订票查询 图4.1 高铁车票订票系统层次图 4.1.2 模块算法 1.各级别算法 1) 界面级算法 处理输入信息，产生相应任务。如图4.2所示: 输入数据 信息反馈 客户端校验数据 信息加工 产生任务 数据 图4.2 界面级算法示意图 15 苏州高博软件技术职业学院毕业设计(论文) 2) 数据库级算法 执行相应数据库操作,并直接返回信息反馈.如图4.3所示: 任务数据校验，调用相关模块功能 用户界面级模块 底层数据库操作(封装) 图4.3 数据库级算法示意图 3) 任务级算法 执行所需功能,满足用户需求.如图4.4所示: 生成数据请求 数据处理 任务触发 并记录 并反馈 权限校验 失败 界面显示 图4.4任务级算法示意图 2. 调用关系 1)界面模块调用任务模块 2)任务模块调用数据模块 3)数据模块调用界面模块显示 16 苏州高博软件技术职业学院毕业设计(论文) 4.2 系统流程图 系统顶层流程图如图3.5所示。图4.6—图4.9为各模块详细系统流程图。 事务 查询程序 订票程序 退票程序 火车站网上订票系统 系统数据库 相应信息 操作反馈 图4.5 系统顶层流程图 输入所符合用户 事务 查询程序 需车次需求的车 的重要次信息 信息 系统数据库 图4.6 车次信息查询系统流程图 符合用户 输入查 需求的订 事务 查询程序 询条件 票信息 系统数据库 图4.7 订单信息查询系统流程图 17 苏州高博软件技术职业学院毕业设计(论文) 输入订 操作反馈 订票程序 事务 票信息 系统数据库 图4.8 订票系统流程图 输入退 操作反馈 退票程序 事务 票信息 系统数据库 图4.9退票系统流程图 18 苏州高博软件技术职业学院毕业设计(论文) 第5章 系统的详细设计 5.1 用户操作业务流程图 5.1.1 用户系统主程序流程图。如图5.1 所示: 开始 登录框 登录，确定访问权限 主界面 N 选择订 票窗口 选择查询 N 窗口 Y Y 选择退 N 查询 票窗口 订票 界面 界面 Y 退票 查询 查询 界面 车次 订票 信息 信息 Y Y 订票 退票 退票 订票 N N 退出 图5.1 用户程序主流程图 Y 结束 19 苏州高博软件技术职业学院毕业设计(论文) 5.1.2 车次信息查询业务流程图.如图5.2所示: 开始 查询 界面 N 查询车次信息 Y 用户输入要 查询条件 N 查询 Y 返回主页 读数据文件 输出查询结果 N 关闭窗口 Y 继续查询 车次信息 N 订票 Y Y N 订票 界面 订票 结束 图5.2车次信息查询业务流程图 20 苏州高博软件技术职业学院毕业设计(论文) 5.1.3 订票处理流程图.如图5.3所示: 开始 订票 界面 N 订票 Y 输入订 票信息 N 提交 返回主页 Y N 错误提示 信息有效性 Y 继续订票 Y N 修改数据文件 N 关闭窗口 Y 结束 图5.3订票处理流程图 21 苏州高博软件技术职业学院毕业设计(论文) 5.1.4 订票信息查询处理流程图.如图5.4所示: 开始 查询 界面 查询订 N 票信息 Y 读数据文件 返回主页 Y 输出查询结果 主界面 N 关闭窗口 N 退票 Y 继续查询 Y Y 订票信息 退票 N 界面 退票 结束 图 5.4订票信息查询处理流程图 22 苏州高博软件技术职业学院毕业设计(论文) 5.1.5 退票处理流程图.如图5.5所示: 开始 退票 界面 N 退票 Y 输入退票 信息 N 提交 Y 返回主页 N 错误提示 信息有效性 Y Y 继续退票 N 关闭窗口 N Y 结束 图5.5退票处理流程图 23 苏州高博软件技术职业学院毕业设计(论文) 5.2 接口设计 5.2.1 用户接口 用户通过界面接口来实现参数的输入，进入相应的界面后输入提示的信息即可产生相应的任务;在用户登录时，如果用户输入的信息是非法的系统会提示有错误信息。 5.2.2 外部接口 本系统得数据库是用SQL，然后在计算机上创建OLEDB数据源，然后用的asp的几个数据库连接来实现与数据库的连接。 5.2.3 内部接口 本系统包括如下几个方面:登陆界面，订票，车票时刻信息查询。需要的数据表有:Admin、Car、OrderTicket等表，这几个数据表都有自己的主键，表之间通过主键实现连接。 5.3 详细页面设计 本身这个系统主要包括两个登录窗口:一个乘客登录窗口，一个管理员登录窗口。 当一个乘客访问这个页面的时候，他首先可看到的是主页面上有3个基本功能:销售车票，预定车票，退回车票。你通过售票车票，可以查询车次，价格等信息。乘客订票是需要乘客进行注册后才能拥有的功能，而第3个功能就是乘客订票，通过输入车次等信息，可以进行订票。管理员登录窗口，我们设为初始值，管理员登录后拥有线路的添加，删改的功能。 5.4 物理结构设计要点 给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系(索引、设备、存储区域)、设计考虑和保密条件。 设计系统界面，主要界面如下: 24 苏州高博软件技术职业学院毕业设计(论文) 5.4.1 系统登录主界面 5.4.2 售票车票系统的主界面 5.4.3 车票预定系统主界面 25 苏州高博软件技术职业学院毕业设计(论文) 26 苏州高博软件技术职业学院毕业设计(论文) 5.4.4 退票系统主界面 27 苏州高博软件技术职业学院毕业设计(论文) 第6章 测试 6.1 数据与数据库完整性的测试 测试目标 确保数据库访问和进程正常进行，数据不会遭到损坏 技术 调用各个数据库访问方法和进程，并在其中填充有效和无效的数 据 (或对数据的请求)。检查数据库，确保数据已按预期的方式填充， 并且所有的数据库事件已正常发生;或者检查所返回的数据，确保为 正当的理由检索到了正确的数据。 完成 所有的数据库访问和进程都按照设计的方式运行，数据没有遭到 损坏。 需考虑的特殊事进程应该以手工方式调用应使用小型或最小的数据库来使所有 项 无法接受的事件具有更大的可视度 6.2 功能的测试 测试目标 确保功能正常，其中包括导航，数据输入，处理和检索等功能 技术 用有效的和无效的数据来执行各个用例。 1在使用有效的数据时得到预期的结果 2在使用无效的数据时显示相应的错误信息和警告消息 3各业务规则都得到了有效的应用 完成标准 所有的测试全部执行 所发现的缺陷全部解决 需考虑的特殊事产品已完成功能的提交是否在测试的范围内 项 6.3 业务周期测试 业务周期测试是模拟一段时间内系统的运行情况 28 苏州高博软件技术职业学院毕业设计(论文) 6.4 用户界面的测试 测试目标 系统的界面美观，得体，功能正常，符合用户的要求，窗口 的对象和特征符合标准。 技术 人工测试或自动化测试工具进行测试，模拟用户的操作，确 保界面能够正确的浏览，在不同的浏览器下显示正常。 完成标准 核实页面达到用户的标准 需考虑的特殊事不同浏览器，不同的窗口大小的显示。 项 29 苏州高博软件技术职业学院毕业设计(论文) 结 论 二十一世纪是一个高速、快捷的年代。在这个高速发展的年代里，速度成了我们追求的目标;二是提高工作效率;三是降低成本。因此，办公自动化的高速度、高效率、高便捷、低成本便成了我们的目的，为此开发了这个高铁车票订票系统。本系统可以大大简化退票、订票、查询等十分繁琐的工作，简化办公环节，提高工作效率，而且易学、易用，满足客户需求。 这次系统的设计从最开始的可行性研究，需求分析，到系统的总体设计，详细设计，再到编码、测试等的一个整体过程，使我真正明白了要做一个软件的难度，特别是要做一个真正可用的软件，就更难了。在老师和同学的帮助下，我把以往所学的软件工程、数据库知识结合起来，利用asp开发工具，加上SQL Server 2005数据库系统，完成了本次课程设计，尽量使它能满足各个方面的要求。当然，我的个人能力有限，还有很多不足的地方，敬请谅解。 在这次课程设计过程中我遇到了不少的难题，比如数据库操作问题，界面设计问题，函数使用与实现问题，消息处理问题等等。其中，最关键的是在最初对系统的需求分析做的不透彻，导致后续设计工作乃至编码时的修改工作量变大。以至于为了能按时完成设计任务，我一连度过了几个通宵。尤其，越接近结束，就越是时常出现问题。所以，通过这次课程设计我深刻体会到软件工程还是必须学精通点、学透彻点。 通过这次课程设计，我学会了如何对所学课程综合运用，巩固了软件工程的一般规范，对数据库的使用也有了更进一步了解。总体来说，课程设计让我学了不少知识。 我认为课程设计是我们学习生涯中相当重要的一课,除了验证学生的学习成果外,也是训练一个人独立思考及解决问题的能力.在这里，我要感谢指导老师和同学在这次课程设计中对我的帮助。 30 苏州高博软件技术职业学院毕业设计(论文) 致 谢 在论文完成之际，我要特别感谢我的指导老师李月峰老师的热情关怀和悉心指导。在我撰写论文的过程中，李老师倾注了大量的心血和汗水，无论是在论文的选题、构思和资料的收集方面，还是在论文的研究方法以及成文定稿方面，我都得到了李老师悉心细致的教诲和无私的帮助，特别是他广博的学识、深厚的学术素养、严谨的治学精神和一丝不苟的工作作风使我终生受益，在此表示真诚地感谢和深深的谢意。 在论文的写作过程中，也得到了许多同学的宝贵建议，同时还得到许多在工作过程中许多同事的支持和帮助，在此一并致以诚挚的谢意。 感谢所有关心、支持、帮助过我的良师益友。 最后，向在百忙中抽出时间对本文进行评审并提出宝贵意见的各位老师表示衷心地感谢～ 31 苏州高博软件技术职业学院毕业设计(论文) 参 考 文 献 1 张孝祥;徐明华 等著.ASP.NET基础与开发详解.第1版.北京:清华大学出版社，2009 2 康会光，王俊伟，张瑞萍.SQL Server 2005 中文版标准教程. 第1版.北京:清华大学出版社，2007 3 四维科技，曹衍龙.数据库开发实用工程案例精选.北京:人民邮电出版社，2004 4 飞思科技产品研发中心.NET核心技术——高级特性.第1版.北京:电子工业出版社，2002 5 陈豫龙.DELPHI 6数据库系统开发实例导航.[J]第I版.北京:人民邮电出版社，2002,20(11):35-36 6 萨师煊，王珊.数据库系统概论.北京:高等教育出版社，2000年 7 张立厚等著，管理信息系统，世界图书出版公司，2002,28(8):38-40 8 陈淑珍，杨涛.基于Internet的远程教学系统设计与实现.现代教育技术，2001,(36) :34-35 9 胡延平,卢晓庆,冯明东,王慧;基于.Net架构的交通旅游售票系统的设计与实现[J];计算机工程与设计;2005年01期 ,王庆玲;用.NET实现系统整合的关键技术[J];计算机工程与应用;2003年24期 10 邱岩 11 于松涛.精通SQL server 2000数据库管理与开发[M].北京:人民邮电出版社，2003.10 12 孙涌.《现代软件工程》.北京希望电子出版社,2003年8月:1-246 32 苏州高博软件技术职业学院毕业设计(论文) 附录A 译文 模拟测试 模糊测试(Fuzz testing )是一项对代码质量有着深远影响的简单技术。在本文中，Elliotte Rusty Harold 故意将随机的坏数据插入应用程序，以观察发生的结果。他也解释了如何使用如校验和、XML 数据存储及代码验证等防护性编码技术，来加固您的程序以抵制随机数据。他以一个练习进行总结，在练习中他以一个代码破坏者的角度进行思考 —— 这是一种用于防护代码的至关重要的技术。 多年来，我惊叹于有如此大量能够使 Microsoft Word 崩溃的坏文件。少数字节错位，会使整个应用程序毁于一旦。在旧式的、无内存保护的操作系统中，整个计算机通常就这样崩溃掉了。Word 为什么不能意识到它接收到了坏的数据，并发出一条错误信息呢,为什么它会仅仅因为少数字节被损坏就破坏自己的栈、堆呢,当然，Word 并不是惟一一个面对畸形文件时表现得如此糟糕的程序。 本文介绍了一种试图避免这种灾难的技术。在模糊测试中，用随机坏数据(也称做 fuzz)攻击一个程序，然后等着观察哪里遭到了破坏。模糊测试的技巧在于，它是不符合逻辑的:自动模糊测试不去猜测哪个数据会导致破坏(就像人工测试员那样)，而是将尽可能多的杂乱数据投入程序中。由这个测试验证过的失败模式通常对程序员来说是个彻底的震憾，因为任何按逻辑思考的人都不会想到这种失败。模糊测试是一项简单的技术，但它却能揭示出程序中的重要 bug。它能够验证出现实世界中的错误模式并在您的软件发货前对潜在的应当被堵塞的攻击渠道进行提示。 模糊测试的实现是一个非常简单的过程: 1. 准备一份插入程序中的正确的文件。 2. 用随机数据替换该文件的某些部分。 3. 用程序打开文件。 4. 观察破坏了什么。 可以用任意多种方式改变该随机数据。例如，可以将整个文件打乱，而不是仅替换其中的一部分，也可以将该文件限制为 ASCII 文本或非零字节。不管用什么方式 33 苏州高博软件技术职业学院毕业设计(论文) 进行分割，关键是将大量随机数据放入应用程序并 观察出故障的是什么。 测试基于 C 的应用程序 可以手动进行初始化测试，但要想达到最佳的当字符串包含额外的零时，许效果则确实需要采用自动化模糊测试。在这种情况多用 C 编写的程序都会出问下，当面临破坏输入时首先需要为应用程序定义适题 —— 这类问题太过频繁以当的错误行为。(如果当输入数据被破坏时，您发至于额外的零能够彻底隐藏代 现程序正常运行，且未定义发生的事件，那么这就码中其他的问题。一旦验证出是第一个 bug。)随后将随机数据传递到程序中直程序存在零字节问题，就可以到找到了一个文件，该文件不会触发适当的错误对移除它们，从而让其他的问题话框、消息、异常，等等。存储并记录该文件，这浮现出来。 样就能在稍后重现该问题。如此重复。 尽管模糊测试通常需要一些手动编码，但还有 一些工具能提供帮助。例如，清单 1 显示了一个简单的 Java? 类，该类随机更改文件的特定长度。我常愿意在开始的几个字节后面启动模糊测试，因为程序似乎更可能注意到早期的错误而不是后面的错误。(您的目的是想找到程序未检测到的错误，而不是寻找已经检测到的。) 清单 1. 用随机数据替换文件部分的类 import java.io.*; import java.security.SecureRandom; import java.util.Random; public class Fuzzer { private Random random = new SecureRandom(); private int count = 1; public File fuzz(File in, int start, int length) throws IOException { 34 苏州高博软件技术职业学院毕业设计(论文) byte[] data = new byte[(int) in.length()]; DataInputStream din = new DataInputStream(new FileInputStream(in)); din.readFully(data); fuzz(data, start, length); String name = "fuzz_" + count + "_" + in.getName(); File fout = new File(name); FileOutputStream out = new FileOutputStream(fout); out.write(data); out.close(); din.close(); count++; return fout; } // Modifies byte array in place public void fuzz(byte[] in, int start, int length) { byte[] fuzz = new byte[length]; random.nextBytes(fuzz); System.arraycopy(fuzz, 0, in, start, fuzz.length); } } 35 苏州高博软件技术职业学院毕业设计(论文) 模糊测试文件很简单。将其传至应用程序通常关于代码 不那么困难。如 AppleScript 或 Perl 脚本语言通我可以用很多种方式优化 清常是编写模糊测试的最佳选择。对于 GUI 程序，单 1 中的代码。例如，有着 最困难的部分是辨认出应用程序是否检测出正确java.nio 的内存映射文件是一的故障模式。有时，最简单的方法是让一个人坐在 个相当不错的选择。我也能够程序前将每一个测试通过或失败的结果都标记下改进这个错误处理及可配置来。一定要将所有生成的随机测试用例单独地命名性。因为不想让这些细节混淆并保存下来，这样就能够重现这个过程中检测到的这里所要说明的观点，所以我任何故障。 将代码保持了原样。 可靠的编码遵循了这样的基本原则:绝不会让 程序中插入未经过一致性及合理性验证的外部数据。 如果从文件中读入一个数字并期望其为正数，那么，在使用其进行进一步处理前对其先验证一下。如果期望字符串只包含 ASCII 字母，请确定它确实是这样。如果认为文件包含一个四字节的整数倍的数据，请验证一下。一定不要假设任何外部提供的数据中的字符都会如您所料。 最常见的错误是做出这样的假设:因为程序将该数据写出，该程序就能不用验证再一次将该数据读回去。这是很危险的～因为该数据很可能已经被另一个程序在磁盘上复写过了。它也可能已经被一个故障磁盘或坏的网络传输所破坏了或已经被另一个带 bug 的程序更改过了。它甚至可能已经被故意更改过以破坏程序的安全性。所以不要假设任何事，要进行验证。 当然，错误处理及验证十分令人生厌，也很不方便，并被全世界程序员们所轻视。计算机的诞生已进入了六十个年头，我们仍旧没有检查基本的东西，如成功打开一个文件及内存分配是否成功。让程序员们在阅读一个文件时测试每一个字节和每一个不变量似乎是无望的 —— 但不这样做就会使程序易被模糊攻击。幸运的是，可以寻求帮助。恰当使用现代工具和技术能够显著减轻加固应用程序的痛苦，特别是如下三种技术更为突出: 1. 校验和 2. 基于语法的格式，如 XML 36 苏州高博软件技术职业学院毕业设计(论文) 3. 验证过的代码如 Java 能够保护程序抵御模糊攻击的最简单的方法是将一个检验和添加到数据中。例如，可以将文件中所有的字节都累加起来，然后取其除以 256 的余数。将得到的值存储到文件尾部的一个额外字节中。然后，在输入数据前，先验证检验和是否匹配。这项简单模式将未被发现的意外故障的风险降低到约 1/256 。 健壮的校验和算法如 MD5 和 SHA 并不仅仅取其除以 256 的余数，它完成的要多得多。在Java 语言中，java.security.DigestInputStream 和 java.security.DigestOutputStream 类为将一个校验和附属到数据中提供了便捷的方式。使用这些校验和算法中的一种可以将程序遭受意外破坏的机率降低到少于十亿分之一(尽管故意攻击仍有可能)。 将数据以 XML 形式存储是一种避免数据损坏的好方法。XML 最初即着力于 Web 页面、书籍、诗歌、文章及相似文档，它几乎在每个领域都获取了巨大的成功，从金融数据到矢量图形到序列化对象等等。 使 XML 格式抵制模糊攻击的关键特征是一不切实际的限定 个对输入不做任何 假设的解析器。这就是真正想如果真想要破坏一个 XML 在一个健壮的文件格式中所获得的。设计 XML 解析器，有几种方法可以试试。解析器是为了让任何输入(格式良好的或无格式例如，大多数 XML 解析器服的，有效的或无效的)都以定义好的形式处理。从于特定的最大尺寸。如果一XML 解析器能够处理任何 字节流。如果数据首 个元素名长度超过 22 亿字符先通过了 XML 解析器，则仅需要准备好接受解(Java String 的最大尺寸)，析器所能提供的东西。例如，不需要检查数据是否SAX 解析器将 失败。尽管如包含空字符，因为 XML 解析器绝不会传送一个此，在实践中这些极限值如此空值。如果 XML 解析器在其输入中看到一个空之高，以至于在达到之前内存字符，它就会发出异常并停止处理。当然还需要处就已经耗尽。 理这个异常，但编写一个 catch 块来处理检测到的 错误比起编写代码来检测所有可能的错误来说要简单得多。 为使程序更加安全，可以用 DTD 和/或模式来验证文档。这不仅检查了 XML 是否格式良好，而且至少与所预期更加接近。验证并不会告知关于文档所需了解的一切， 37 苏州高博软件技术职业学院毕业设计(论文) 但它却使编写大量简单检查变得很简单。用 XML，很明显能够将所接受的文档严格地限定为能够处理的格式。 尽管如此，还有多段代码不能用 DTD 或模式进行验证。例如，不能测试发票上商品的价格是否和数据库中库存商品的价格一致。当从客户接收到一份包含价格的订单文档时，不论其是 XML 格式或是其他格式，在提交前通常都会检查一下，以确保客户并未修改价格。可以用定制代码实现这些最后的检查。 使 XML 能够对模糊攻击具有如此的抵御能力的是其使用巴科斯-诺尔范式(Backus-Naur Form，BNF)语法仔细且标准地定义的格式。许多解析器都是使用如 JavaCC 或 Bison 等解析器-生成器工具直接从此语法中构建的。这种工具的实质是阅读一个任意的输入流并确定其是否符合此语法。 如果 XML 并不适合于您的文件格式，您仍可以从基于解析器的解决方案的健壮性中获益。您必须为文件格式自行编写语法，随后开发自己的解析器来阅读它。相比使用唾手可得的 XML 解析器，开发自己的解析器需要更多的工作。然而它是一个更为健壮的解决方案，而不是不根据语法正式地进行验证就将数据简单地装载到内存中。 由模糊测试导致的许多故障都是内存分配错误及缓冲器溢出的结果。用一种安全的垃圾收集语言(在如 Java 或 managed C# 等虚拟机上执行的)来编写应用程序避免了许多潜在问题。即使用 C 或 C++ 来编写代码，还是需要使用一个可靠的垃圾收集库。在 2006 年，台式机程序员或服务器程序员不应该还需要管理内存。 Java 运行时对其自身的代码起到了额外保护层的作用。在将一个 .class 文件装载到虚拟机之前，该文件要由一个字节符验证器或一个可选SecurityManager 进行验证。Java 并不假设创建 .class 文件的编译器没有 bug 且运转正常。设计 Java 语言之初就是为了允许在一个安全沙箱中运行不信任的、潜在恶意的代码。它甚至不信任其自身编译过的代码。毕竟，也许有人已经用十六进制编辑器手工修改了字节符，试图触发缓冲器溢出。我们大家都应该对我们的程序也有对输入这样的偏执。 之前介绍的每项技术都在阻止意外破坏方面造诣颇深。将它们综合起来恰当地实现，会将未被发现的非蓄意破坏发生的可能性几乎减少到零。(当然，并不会减少到零，但其发生的可能性就如同一束偏离轨道的宇宙射线将您 CPU 运算 1+1 的结果 38 苏州高博软件技术职业学院毕业设计(论文) 变为 3 的可能性一样微乎其微。)但不是所有的数据损坏都是非蓄意的。如果有人故意引入坏数据来破坏程序的安全性又该如何呢,以一个攻击者的角度进行思考是防护代码的下一个步骤。 转回到一个攻击者的角度进行思考，假设要攻击的应用程序是用 Java 编程语言编写的、使用非本地代码且将所有额外数据都以 XML(在接受前经过彻底验证)形式存储，还能成功攻击吗,是的，能。但用随机改变文件字节的低级方法显然不行。需要一种更为复杂的方法来说明程序自身的错误检测机制及路径。 当测试一个抵御模糊攻击的应用程序时，不可能做纯黑盒测试，但通过一些明显的修改，基本的想法还是可以应用的。例如，考虑校验和，如果文件格式包含一个校验和，在将文件传至应用程序前仅仅修改此校验和就可以使其同随机数据相匹配。 对于 XML，试着模糊单独的元素内容和属性值，而不是从文档中挑选一部分随机的字节进行替换。一定要用合法的 XML 字符替换数据，而不要用随机字节，因为即使一百字节的随机数据也一定是畸形的。也可以改变元素名称和属性名称，只要细心地确保得到的文档格式仍是正确的就可以了。如果该 XML 文档是由一个限制非常严格的模式进行检查的，还需要计算出该模式没有 检查什么，以决定在哪里进行有效的模糊。 一个结合了对剩余数据进行代码级验证的真正严格的模式也许不会留下可操纵的空间。这就是作为一个开发人员所需要追求的。应用程序应能够处理所发送的任何有意义的字节流，而不会因权利上(de jure)无效而拒绝。 模糊测试能够说明 bug 在程序中的出现。并不证明不存在这样的 bug。而且，通过模糊测试会极大地提高您对应用程序的健壮性及抵御意外输入的安全性的自信心。如果您用 24 小时对程序进行模糊测试而其依然无事，那么随后同种类型的攻击就不大可能再危及到它。(并不是不可能，提醒您，只是可能性很小。)如果模糊测试揭示出程序中的 bug，就应该进行修正，而不是当 bug 随机出现时再对付它们。模糊测试通过明智地使用校验和、XML、垃圾收集和/或基于语法的文件格式，更有效地从根本上加固了文件格式。 模糊测试是一项用于验证程序中真实错误的重要工具，也是所有意识到安全性问题且着力于程序健壮性的程序员们的工具箱中所必备的工具。 39 苏州高博软件技术职业学院毕业设计(论文) 附录B 外文原文 Fuzz testing Fuzz testing is a simple technique that can have a profound effect on your code quality. In this article, Elliotte Rusty Harold shows what happens when he deliberately injects random bad data into an application to see what breaks. He also explains how to use defensive coding techniques such as checksums, XML data storage, and code verification to harden your programs against random data. He concludes with an exercise in thinking like a code cracker -- a crucial technique for defending your code. For years, I've been astounded by the number of corrupt files that can crash Microsoft Word. A few bytes out of place and the whole application goes down in flames. On older, non-memory-protected operating systems, the whole computer usually went down with it. Why can't Word recognize when it's received bad data and simply put up an error message? Why does it corrupt its own stack and heap just because a few bits got twiddled? Of course, Word is hardly the only program that behaves atrociously in the face of malformed files. This article introduces you to a technique that attempts to avert just this sort of disaster. In fuzz testing, you attack a program with random bad data (aka fuzz), then wait to see what breaks. The trick of fuzz testing is that it isn't logical: Rather than attempting to guess what data is likely to provoke a crash (as a human tester might do), an automated fuzz test simply throws as much random gibberish at a program as possible. The failure modes identified by such testing usually come as a complete shock to programmers because no logical person would ever conceive of them. Fuzz testing is a simple technique, but it can nonetheless reveal important bugs in your programs. It can identify real-world failure modes and signal potential avenues of attack that should be plugged before your software ships. Fuzz testing is a very simple procedure to implement: 1. Prepare a correct file to input to your program. 2. Replace some part of the file with random data. 40 苏州高博软件技术职业学院毕业设计(论文) 3. Open the file with the program. 4. See what breaks. You can vary the random data in any number of ways. For example, you might randomize the entire file rather than replacing just a part of it. You could limit the file to ASCII text or non-zero bytes. Any way you slice it, the key is to throw a lot of random data at an application and see what fails. Many programs written in C have trouble when strings contain extra zeroes -- so much so that extra zeroes can completely hide other problems in the code. Once you've identified a program's problems with zero-bytes, you might wish to remove them to allow other problems to surface. While you can do initial tests manually, you should really automate fuzzing for maximum effect. In this case, you first need to define the proper error behavior for the application when faced with corrupt input. (If you discover the program hasn't bothered to define what happens when the input data is corrupt, well, there's your first bug.) Then you simply pass random data into the program until you find a file that doesn't trigger the proper error dialog, message, exception, etc. Store and log that file so you can reproduce the problem later. Repeat. Although fuzz testing usually requires some manual coding, there are tools that can help. For example, Listing 1 shows a simple Java? class that randomly modifies a certain length of a file. I usually like to start fuzzing somewhere after the first few bytes because programs seem more likely to notice an early mistake than a later one. (You want to find the errors the program doesn't check, not the ones it does.) Listing 1. A class that replaces part of a file with random data import java.io.*; import java.security.SecureRandom; import java.util.Random; public class Fuzzer { 41 苏州高博软件技术职业学院毕业设计(论文) private Random random = new SecureRandom(); private int count = 1; public File fuzz(File in, int start, int length) throws IOException { byte[] data = new byte[(int) in.length()]; DataInputStream din = new DataInputStream(new FileInputStream(in)); din.readFully(data); fuzz(data, start, length); String name = "fuzz_" + count + "_" + in.getName(); File fout = new File(name); FileOutputStream out = new FileOutputStream(fout); out.write(data); out.close(); din.close(); count++; return fout; } // Modifies byte array in place public void fuzz(byte[] in, int start, int length) { byte[] fuzz = new byte[length]; random.nextBytes(fuzz); System.arraycopy(fuzz, 0, in, start, fuzz.length); } } There are many ways I could optimize the code in Listing 1. For instance, it's a really good candidate for a memory mapped file with java.nio. I could also improve its error 42 苏州高博软件技术职业学院毕业设计(论文) handling and configurability. Because I don't want to let those details get in the way of the ideas I'm presenting here, I've left it as is. Fuzzing the file is easy. Passing it to the application is normally not much harder. Scripting languages like AppleScript or Perl are often the best choice for writing this part of the fuzz test. For GUI programs, the hardest part can be recognizing whether the application indicated the right failure mode. Sometimes it's simplest to have a human sit in front of the program and mark each test as pass or fail. Be sure to individually name and save all the random test cases generated so you can reproduce any failures you detect with this procedure. Solid code follows this fundamental principle: Never accept external data into your program without verifying it for consistency and sanity. If you read a number from a file and expect it to be positive, check that it is before further processing with that number. If you expect a string to contain only ASCII letters, be sure that it does. If you think a file contains an integral multiple of four bytes, then check that. Never assume that any characteristic of externally-supplied data is as you expect. The most common mistake is to assume that because an instance of your program wrote the data out, it can read that data back in again without verifying it. This is dangerous! The data could have been overwritten on disk by another program. It could have been corrupted by a failing disk or a bad network transfer. It could have been modified by another program that had a bug. It could even have been deliberately modified in an effort to subvert your program's security. Assume nothing. Verify everything. Of course, error handling and verification is ugly, annoying, inconvenient, and thoroughly despised by programmers the world over. Sixty years into the computer age, we still aren't checking basic things like the success of opening a file or whether memory allocation succeeds. Asking programmers to test each byte and every invariant when reading a file seems hopeless -- but failing to do so leaves your programs vulnerable to fuzz. Fortunately, help is available. Properly used, modern tools and technologies can 43 苏州高博软件技术职业学院毕业设计(论文) significantly alleviate the pain of hardening your applications. In particular, three techniques stand out: , Checksums , Grammar based formats such as XML , Verified code such as Java The simplest thing you can do to protect against fuzzing is add a checksum to your data. For example, you can sum up all the bytes in the file and then take the remainder when dividing by 256. Store the resulting value in one extra byte at the end of the file. Then, before trusting the input data, verify that the checksum matches. This very simple scheme reduces the risk of undetected accidental failure to about 1 in 256. Robust checksum algorithms like MD5 and SHA do much more than simply take the remainder when dividing by 256. In the Java language, the java.security.DigestInputStream and java.security.DigestOutputStream classes provide convenient means for attaching a checksum to your data. Using one of these checksum algorithms reduces the chance of accidental corruption to less than one in a billion (though deliberate attacks are still a possibility, as you'll see). Storing your data in XML is an excellent way to avoid problems with data corruption. While XML was originally intended for Web pages, books, poems, articles, and similar documents, it has found broad success in almost every field ranging from financial data to vector graphics to serialized objects. If you really wanted to break an XML parser, there are a few ways you could try to do it. For instance, most XML parsers are subject to certain maximum sizes. SAX parsers will fail if an element name is more than 2.2 billion characters long (the maximum size of a Java String). In practice, however, these limits are so high that you'll run out of memory long before reaching them. The key characteristic that makes XML formats resistant to fuzz is that an XML parser assumes nothing about the input. This is precisely what you want in a robust file format. XML parsers are designed so that any input (well-formed or not, valid or not) is 44 苏州高博软件技术职业学院毕业设计(论文) handled in a defined way. An XML parser can process any byte stream. If your data first passes through an XML parser, all you need to be ready for is whatever the parser can give you. For instance, you don't need to check whether the data contains null characters because an XML parser will never pass you a null. If the XML parser sees a null character in its input, it throws an exception and stops processing. You still need to handle this exception of course, but writing a catch block to handle a detected error is much simpler than writing code to detect all possible errors. For further security you can validate your document with a DTD and/or a schema. This checks not only that the XML is well-formed, but that it's at least close to what you expect. Validation will rarely tell you everything you need to know about a document, but it makes it easy to write a lot of simple checks. With XML, it is very straightforward to strictly limit the documents you accept to the formats you know how to handle. Still, there will be pieces of the code you can't validate with a DTD or schema. For example, you can't test whether the price of an item in an invoice is the same as the price for that item in your inventory database. When receiving an order document from a customer that contains the price, whether in XML or any other format, you should always check to make sure the customer hasn't modified the price before submitting it. However, you can implement these last checks with custom code. One characteristic that makes XML so fuzz-resistant is that the format is carefully and formally defined using a Backus-Naur Form (BNF) grammar. Many parsers are built directly from this grammar using parser-generator tools such as JavaCC or Bison. The nature of such a tool is to read an arbitrary input stream and determine whether or not it satisfies the grammar. Many of the crashes resulting from fuzz testing are direct results of memory allocation mistakes and buffer overflows. Writing your application in a safe, garbage-collected language that executes in a virtual machine such as Java or managed C# eliminates many potential problems. Even if you're writing your code in C or C++, you should use a reliable garbage-collection library. In 2006, no desktop or server programmers 45 苏州高博软件技术职业学院毕业设计(论文) should be managing their own memory. The Java runtime features an additional layer of protection for its own code. Before a .class file is loaded into the virtual machine, it is verified by a bytecode verifier and optionally a SecurityManager. Java does not assume that the compiler that created the .class file was non-buggy or behaving correctly. The Java language was designed from day one to allow the execution of untrusted, potentially malicious code in a secure sandbox. It doesn't even trust the code it, itself, has compiled. After all, someone could have changed the bytecode manually with a hex editor to attempt to trigger a buffer overflow. We should all have this level of paranoia about input to our programs. Each of the previous techniques goes a long way toward preventing accidental damage. Taken together and implemented properly, they reduce the chance of undetected, unintentional damage to essentially zero. (Well, not quite zero, but of the same order of magnitude as the chance of a stray cosmic ray causing your CPU to add 1+1 and come up with 3.) But not all data corruption is unintentional. What if someone is deliberately introducing bad data in the hopes of breaching your program's security? Thinking like a cracker is the next step in defending your code. Switching back to an attacker's mode of thinking, let's suppose the application you're attacking is written in the Java programming language, uses non-native code, and stores all external data in XML, which is thoroughly validated before acceptance. Can you still attack it successfully? Yes, you can. A naive approach that randomly changes bytes in the file is unlikely to succeed, however. You need a more sophisticated approach that accounts for the program's built-in error-detection mechanisms and routes around them. When you're testing a fuzz-resistant application, you can't do pure blackbox testing, but with some obvious modifications, the basic ideas still apply. For example, consider checksums. If a file format contains a checksum, then you simply modify the checksum so it matches your random data before passing the file to the application. For XML, try fuzzing individual element content and attribute values rather than selecting a random section of the bytes in the document to replace. Be careful to replace 46 苏州高博软件技术职业学院毕业设计(论文) data with legal XML characters rather than random bytes, because even a hundred bytes of random data is almost certain to be malformed. You can change element and attribute names too, as long as you're careful to make sure the resulting document is still well formed. If the XML document is checked against a very restrictive schema, you'll need to figure out what the schema isn't checking to determine where you can productively fuzz. A really restrictive schema combined with code-level verification of the remaining data may leave you with no room to maneuver. As a developer, this is what you should strive for. The application should be able to process meaningfully any stream of bytes you send it that it does not reject as de jure invalid. Fuzz testing can demonstrate the presence of bugs in a program. It doesn't prove that no such bugs exist. Nonetheless, passing a fuzz test greatly improves your confidence that an application is robust and secure against unexpected input. If you've fuzzed your program for 24 hours and it's still standing, then it's unlikely that further attacks of the same sort will compromise it. (Not impossible, mind you, just less likely.) If fuzz testing does reveal bugs in your programs, you should fix them. Rather than plugging random bugs as they appear, it may be more productive to fundamentally harden the file format through the judicious use of checksums, XML, garbage collection, and/or grammar-based file formats. Fuzz testing is a crucial tool for identifying real errors in programs, and one that all security-aware and robustness-oriented programmers should have in their toolboxes. 47