高校数字化校园应用系统安全测试研究
2018-03-31李凤强
李凤强
摘要：近几年，高校数字化校园飞速发展，同时也面临巨大的风险与挑战。数据泄露、网络攻击等事件层出不穷，如何保证高校数字化校园应用系统的安全是我们亟待解决的问题。该文从安全测试人手，针对校园信息系统的特点主要从数据安全保护和网络攻击的防御技术方面进行了探讨，为保证数字化校园的健康发展提供参考。
关键词：数字化校园；安全测试；数据安全；web扫描器；web攻击
中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2018）06-0022-03
1引言
数字化校园是以数字化信息和网络为基础，在计算机和网络技术上建立起来的对教学、科研、管理、技术服务、生活服务等校园信息的收集、处理、整合、存储、传输和应用，使数字资源得到充分优化利用的一种虚拟教育环境。作为教育信息化的重要内容，数字化校园快速发展。数字化校园中集成了大量的业务系统，涵盖了学校发展的方方面面，同时安全问题也前所未有的凸显。为了保证数字化校园的健康发展，必须对数字化校园的系统进行安全测试。
2数字化校园的安全现状
为贯彻发展现代化高等教育，再造中国人才红利的国家战略，响应党中央国务院《教育信息化十年发展规划（2011-2020年）》精神，实现教育的信息化，各高校的数字化校园建设取得了巨大的成绩。在取得巨大成绩的同时，巨大的安全风险也随之而来。2017年肆掠全国的勒索病毒，其中一个高发地就是各大高校。近年来，数字化校园门户被攻陷，主页被篡改发布一些反动言论，数据信息被盗取的事件屡次发生。所以在假期，重大事件发生时候好多高校的数字校园门户和系统就会关闭对Internet的服务功能，只能在校园内网中才能访问，有的学校甚至为了安全只允许在内网访问数字化校园门户和系统。此举的目的就是防止数字化校园被攻陷产生不良的社会效应，但是此举也给广大的老师和学生使用数字化校园系统带来了极大的不方便，严重的限制了数字化校园的使用率和发展。此种现象的产生归根结底是由于大多数学校的数字化校园过分依赖于数字化校园的开发公司，校方自身的技术能力有限，对于数字化校园的安全防范能力的认知基本上也是停留在开发公司的汇报上，校方自身并沒有一个比较清楚地掌握。
3数据安全的测试
数字化校园安全问题的核心是数据安全的问题。在建设数字化校园的过程中，为了防止数据孤岛和数据不一致的情况出现，建设了统一的数据中心。所有数字化校园的应用系统都要和统一的数据中心交换数据，所以数据中心的数据一旦遭到破坏，对于整个的数字化校园来说将是严重的损失，轻则需要断网恢复数据，重则无法恢复数据导致灾难性的后果。所以数据的安全是安全测试的重中之重，必须花大力气去保证。
3.1签订合同和需求阶段
对于数据安全，我们要考虑最坏的结果，如果数据全部丢失或破坏，我们应该怎么做？别无他法，唯有数据的备份才能解决这一问题。备份有两种形式，一种是同一机房备份，既可以把数据备份到数据库所在的服务器，也可以备份到专门的服务器上，另一种就是异地备份。不同的备份各有自己的优缺点，主要的差别在于成本，所以在前期一定要把备份方式进行明确，以确定项目的成本，如果在项目后期再变动备份方式，就牵扯到很多方面，比较麻烦。
对于数据安全来说，还有一个很重要的特点就是机密性，对于一些重要数据或者是个人信息，即使数据库数据泄露，也不能使对方轻易获取信息，这就需要对数据进行加密。此类事情最著名的事件就是2011年CSDN的数据库‘脱库事件。作为著名的计算机软件行业的杂志在自己的网站中竟然用明文的形式存储了用户的登录密码，导致六百多万的用户账户信息被盗，教训非常惨痛。数字化校园的数据中心中存储的用户的登录密码，个人姓名、身份证号、手机号、工资信息等个人信息都需要保证安全，所以在需求文档中必须明确规定需要加密的字段列表。
在这个阶段，测试的重点就是检查合同和需求文档中，验证是否有具体的条款来约定备份方式和需要加密存储的信息列表。这个测试很简单，但是很重要，一定要做，问题解决越早，成本越低。
3.2验收阶段
验收阶段需要对照合同或者需求文档中约定的数据备份方式进行验收。具体做法如下：根据合同或需求文档约定在对应的服务器上查看是否有数据备份；通过对数据库中的数据进行修改，删除、新增，销毁等操作改变数据库中的数据；通过备份的数据进行数据库的数据恢复，验证数据库中的数据是否能够完全恢复，如果能够恢复，测试通过，如果不能则要求整改。
对于需要加密的字段直接进入数据库查看，如果用密文存储，验收合格，如果是明文需要开发公司整改。
4攻击手段及测试方法
对于数字化校园系统的安全隐患主要集中在以下几个方面：SQL注入攻击、文件上传漏洞、XSS攻击、CSRF攻击等。
4.1 SQL注入攻击
SQL注入攻击的本质就是把用户输入的数据当做代码执行。这里有两个关键条件，第一个是用户能够控制输入，第二个是原本程序要执行的代码，拼接了用户输人的数据。
下面我们介绍一下SQL注入的原理，我们用一个例子来演示。在很多数字化校园的门户中都有一个登录界面，需要用户提供用户名（username）和密码（password），如果这个功能是一个没有安全意识的新程序员开发的，程序如下：
a.在登录界面中的用户名输入单引号，如果系统没有做相应的处理，这时候构造的sql语句是有语法错误的，这个时候如果出现了web服务器的错误回显信息例如：[OleDbException（Ox80040e14）：字符串的语法错误在查询表达式‘UserName=‘中。]这些错误回显信息证明系统存在注入漏洞，同时也暴露了一些敏感信息，对于攻击者来说，构造SQL注入的语句就可以更加得心应手，所以如果出现错误回显信息，这时候必须要求开发公司关闭web服务器的回显信息。
b.构造SQL注入语句，对于登录界面，我们可以对用户名构造‘or‘1=1一类似这样的语句查看系统是否可以匿名登录。如果可以匿名登录，说明有SQL注入漏洞，需要整改。
c.构造SQL注入语句，比如一个应用URL：http：∥127.0.0.1：8085/items.aspx？id=1，执行的SQL语句可能为Sdect*fromitems_table where id=1，这时候我们可以构造如下条件的语句：http：∥127.0.0.1：8085/items.aspx？id=1 and 1=2，如果这个时候页面无法显示，我们继续构造http：∥127.0.0.1：8085/items.aspx？id=1 and 1=1，如果这时候页面可以正常显示，则说明存在SQL注入漏洞，需要整改。
4.2文件上传漏洞
文件上传漏洞是指用户上传了一个可以执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。做如下测试：
a.根据需求文档得到可以上传文件类型的白名单，然后用白名单外的文件类型进行上传，验证系统是否能够正确处理，如果可以上传，需要开发公司进行整改。
b.对于上面测试后不能上传的文件，将其后缀改为白名单中的文件类型，假设白名单文件中没有.aspx文件类型，有.docx文件类型，我们要上传1.aspx文件，将其改名为1.docx，这时候只是改了后缀名，文件内容并无任何变化，如果能够上传，同样需要开发公司进行整改。
4.3 XSS攻击
XSS攻击称为跨站脚本攻击，英文全称是Cross Site Script。XSS攻击是客户端脚本安全中的头号大敌。XSS攻击是指通过“HTML注人”篡改了网页，插入了恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。我们用一个例子来说明XSS攻击的原理。假设一个页面把用户输入的参数直接输出到页面上：
在正常情况下，用户向param提交的数据会展示到页面中，比如提交
http：∥127.0.0.1：8085/test.php？param=正常显示，此时查看页面源代码，可以看到
4.3.1对输入和输出进行检查
对于XSS攻击的防御方式主要有对输入和输出进行检查过滤或转义危险的特殊字符，比如<、>、等。
a.对于输入内容有限制的字段进行功能测试。比如用户名，假如限定用户名只能由数字和字母组成，这时我们就要测试输入非数字和字母的内容后能否通过检查。
b.对于输入内容无限制的，这时候我们需要构造一些包含这样的内容，看系统是否会弹出用户输人的弹出框。如果有弹出框，测试不通过，需整改。
c.针对get方式的URL构造带有执行代码的参数，例如http：∥127.0.0.1：8085/test.php？param=，看看是否有弹出框。如果有弹出框，测试不通过，需整改。
4.3.2使用HttpOnly解决XSS后的Cookie劫持
黑客可以通过XSS窃取用户的Cookie，然后登陆进该用户的账户。在这个过程中的关键就是黑客可以读取用户的Cook-ie并发给自己。HttpOnly这个属性将会使JavaScript无法读取Cookie。所以这个测试我们主要看系统是否对Cookie设置了HttpOnlv属性。我们通过在网站地址栏中输入javacript：alert（document.cookie）看是否显示cookie，如果不顯示，测试通过。如果显示则需要和开发公司确认显示的Cookie是否和登录认证有关，如果有关则需要开发公司整改。
4.4 CSRF攻击
CSRF称为跨站点请求伪造，全名是Cross Site Request Forgery.可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，转账虚拟货币等。
我们以录入学生成绩为例，教务系统A，它以GET请求来完成成绩录入的操作，如：http：∥www.jw.com/luru.php？studentid=11&shuxue;=90&yuwen;=90&zhengzhi;=90，同时还有危险网站B，它里面有一段HTML的代码如下：
。
首先，录入成绩的老师登录了教务网站A，然后访问了危险网站B，这时会发现id为11的学生成绩已经录入了系统。
应对CSRF攻击的一种主要手段就是给传递的参数增加一个Token，Token的值是随机的，这样危险网站B上的请求因为没有Token随机值将不能被执行。所以我们的测试就是在需要防止CSRF攻击的页面进行输入并提交，验证构造的参数中是否有Token参数，并查看其值是否一个随机值。
5使用测试工具
以上介绍了数字化校园应用系统中安全测试的原理和方法，但是对于攻击测试比如SQL注入，XSS攻击等技术要求比较高，而且特别繁琐，手动测试是比较困难的，因此我们需要使用对应的安全测试工具。对于数字化校园应用系统推荐两款免费的扫描器：w3af和skipfish。对于sql注入推荐SQLMAP。
6选择测试方式
在数字化校园项目验收的关键时刻，安全测试究竟该由谁来执行，一般有以下三种方式，每个学校根据自己的实际情况来进行选择。
6.1校方自行进行安全测试
此种情况的前提条件是校方自身必须具有较强的技术能力，这样校方可以自己对开发公司交付的数字化校园系统进行安全测试。此种方式由于校方的测试团队对业务需求了解得更清楚，这样的测试更有针对性，测试更全面，测试结果更可靠。
6.2聘请第三方测试团队测试
专业的测试团队，技术强、经验丰富，会最大程度的发现系统中存在的安全隐患。但此种方式需要额外的资金预算，同时需要考察测试团队的资质。
6.3让开发公司来测试
如果校方即无较强技术能力也无对应的资金预算，可以让开发公司提供安全测试报告。通过这种方式可以促使开发公司更加注意系统的安全问题，提高系统的安全性能。根据测试规律，自己测试自己的产品会陷入思维定势，有些问题难以发现。
7总结
数字化校园的快速发展是实现教育信息化的重要手段，数字化校园要更快更好的发展，必须要有安全保驾护航。做好数字化校园系统的安全测试工作，就是要尽可能提高系统的安全性，让教职工和学生在一个安全放心的环境下使用数字化校园的系统。但是世界上没有绝对的安全，做安全测试是为了尽可能地发现系统存在的安全漏洞，然后解决漏洞，安全测试不能解决所有的安全问题，只是提高攻击人员的攻击成本，降低系统的风险。攻击手段不断推陈出新，花样百出，我们要持续关注安全领域的新动向。我们要以安全工作永远在路上的态度来做好数字化校园的安全工作。
