如何消除网站安全的七大风险

以工作中某项目的安全改善过程为例，分享了常用网站安全性的典型问题和解决对策，希望对网站开发者有借鉴意义。

有过网站开发经验的朋友都知道网站安全是构建网站时必须要考虑的一个因素，网站安全的重点在于服务器的安全配置管理以及程序脚本的完善性。值得注意的是，如果服务器的账号和权限由于管理不善而泄露了，即使技术上网站系统再安全，也不可避免会受到攻击。

在 笔者曾经参与过的一个项目中，客户方邀请了专业的第三方安全测试公司进行了安全性的全面检测，同时也针对性地进行了安全性的改善，特别是在应用程序方面。 此文将分享改善过程中的几个典型问题的分析和解决对策，包括SQL注入攻击、跨站点脚本攻击、验证码绕过等，希望能够为大家在改善网站安全方面的工作提供 参考，并采取相应的防范措施。

项目背景

该项目使用的技术和平台：

OS：Windows 2008 Server, Enterprise Edition 64-bit

Database：Microsoft SQL 2005 Server, Standard Edition

WebServer：IIS7.0

开发平台：.NET Framework 2.0

考虑到网站安全的跨平台和通用性，文中讨论时仅提供对应策略不使用实际代码，这里所有的项目网站用到的域名统一用example.com代替。

改善之前

第三方专业安全测试公司进行测试，其中的重点问题列表如下：

问题1：易受到SQL注入攻击

风险 ： 攻击者可以通过应用程序发送数据库命令，这些命令将被服务器执行。这可以用来对数据库进行完全控制。这些SQL注入漏洞可以通过在其中一个区域插入“and 7 = 7 -”或“and 8 = 9 -”，并比较结果进行判断。

分析 ： SQL 注入攻击是由于服务器对参数检查不够，而导致攻击者借此获得敏感信息。因此，需要使用参数化查询以确保攻击者无法操作数据库的SQL查询语句。例如，如果 应用程序要求输入名称，那它应该只接受字母字符、空格和撇号，而不接受任何其他字符。也就是说，在应用程序中的所有输入域实施服务器端白名单技术。特别是 所有用于SQL语句的输入域，需要空格的都应该用引号括起来。

改善 ： 在程序中所有可接受外部参数的地方进行逐一识别，以过滤危险字符。如在全局函数中定义“禁止字符串列表”，该表中列出所要过滤出的SQL攻击代码可能包含的字符串。

and |exec |insert |select |delete |update |count | * |chr |mid |master |truncate |char |declare |<|>|’|(|)|{|}

//当然可以根据网站的特点完善和修改本列表

接下来做如下处理：

 

 

问题2：易受到跨站点脚本攻击

风险 ： 此漏洞可以被用来获取身份验证Cookie，攻击管理员账户，或使应用程序的用户攻击其他服务器和系统。该漏洞可以通过在某区域中插入“<script>alert(‘23389950’);</script>”来判断。

分析 ： 这也需要在本网站的所有输入域实施服务器端白名单技术。如果需要特殊字符，应该转换为更安全的形式。如适用于各种语言的HTML转码：

• &应转换为 &；
• “应转换为”；
• ‘应转换为&39；
• >应转换为>；
• <应转换为<。

改善 ： 除 了这些标准的HTML转码之外，对于可疑字符串也要进行强化检查和转化，并进一步执行以下操作：（1）对各页面的输入参数进行强化检查；（2）对原来只在 客户端判断的参数，在服务器端进一步强化检查;（3）最终提供了全局的转码和过滤的函数。当然这需要在性能和扩展性以及安全性方面的平衡综合考虑。

问题3：非安全的CrossDomain.XML文件

风险 ： 为 解决Flash/Flex系统中的跨域问题，提出了crossdomain.xml跨域策略文件。虽然可以解决跨域问题，但是也带来了恶意攻击的风险，如 果该策略文件里允许访问任何域，就可能允许发起对网络服务器的跨站点请求伪造和跨站点脚本攻击。比如，不安全Flash应用程序可能会访问本地数据和用户 保存的网页记录，甚至传播病毒和恶意代码。

分析 ： 考虑如何确保只对提供安全资源的可信域开放允许。

改善 ： 经过调查，发现在程序目录下的crossdomain.xml文件里的配置如下：

<?xml version=”1.0″?>

<!DOCTYPE cross-domain-policy SYSTEM ”http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd”>

<cross-domain-policy>

<allow-access-from domain=”*” />

</cross-domain-policy>

文件中的allow-access-from 实体设置为星号设置为允许任何域访问，将其修改为 <allow-access-from domain=”*.example.com” />，表示只允许本域访问，该问题就解决了。

问题4：Flash参数AllowScript-Access 已设置为always

风险 ： 当AllowScriptAccess为always时，表明嵌入的第三方Flash文件可以执行代码。攻击者此时就可以利用该缺陷嵌入任意第三方Flash文件而执行恶意
代码。

分析 ： AllowScriptAccess 参数可以是“always”、”sameDomain”或“never”。三个可选值中，“always” 表示Flash文件可以与其嵌入到 的 HTML 页进行通信，即使该Flash文件来自不同于HTML页的域也可以。当参数为“sameDomain”时，仅当Flash文件与其嵌入到的 HTML页来自相同的域时，该Flash文件才能与该HTML页进行通信，此值是AllowScriptAccess 的默认值。而当 AllowScriptAccess为 “never”时，Flash文件将无法与任何HTML页进行通信。

因此需要将AllowScriptAccess参数设置为“sameDomain”，可以防止一个域中的Flash文件访问另一个域的 HTML 页内的脚本。

改善

<param

name=”allowScriptAccess” value=”always” />

改为

<param

name=”allowScriptAccess” value=“sameDomain” />

 

问题5：网站后台管理通过不安全链接实施

风险 ： 管理访问没有强制实施SSL，这可能允许攻击者监视并修改用户和服务器之间的发送的包括账户凭据在内的所有数据。如果攻击者通过代理或者路由软件拦截服务器和管理员间的通信，敏感数据可能被截获，进而管理员账户可能会受到危害。

分析 ： 管理访问没有强制实施SSL，为防止数据拦截，管理访问应该强制执行HTTPS (SSL3.0)。

改善 ： 运维对服务器进行了配置调整，单独配置支持了SSL3.0访问管理后台。

问题6：验证环节可以被绕过

风险 ： 用户发布信息时，虽然有页面的验证码防止自动恶意发布，但仍可能被绕过进行自动提交。绕过的方式之一是使用过滤和识别软件，之二是可以利用Cookie或Session信息绕过验证码。

分析 ： 图像失真机制本身不是特别强，可以很容易地使用公开的过滤和识别软件来识别。生成的图片也是可以预测的，因为使用的字符集很简单（只是数字），建议实现一个更强大的验证码系统。

Cookie或session信息处理有漏洞导致验证码被绕过, 确保每一个链接只能取得唯一的验证码，并确保每个请求产生并需要一个新的验证码。

改善 ： 根据需要增加验证码的复杂度，而不只是单数字。

经过分析发现是因为验证码被存入了Session里，而开发人员忘记在提交之后清空Session中的验证码的值，导致验证码在过期时间内一直可用，从而可能被利用多次提交。因此在提交后追加了及时清空验证码的操作。

问题7：泄露敏感信息

风险 ： 此信息只能用于协助利用其他漏洞，并不能直接用来破坏应用程序。网站的robots.txt文件里可以获得敏感目录的信息，这可能允许攻击者获得有关应用程序内部的其他信息，这些信息可能被用来攻击其他漏洞。

分析 ： robots.txt不应在提供管理界面的信息。如果robots.txt文件暴露了Web站点结构，则需要将敏感内容移至隔离位置，以避免搜索引擎机器人搜索到此内容。

改善 ： 当 然robots.txt要根据SEO的要求来处理，但也要同样注意安全性。如：disallow:/testadmin/，其中testadmin为管理 后台，就被暴露了。可以根据实际情况是否必要决定删除robots.txt文件或者把敏感目录单独配置禁止搜索引擎搜索。

其他问题汇总

除此以外，还有很多其他危害性相对较低的问题，分析如下。

问题：可能通过登录页面枚举出用户名，因为根据账户是否存在的错误信息是不同的。

对策：修改错误信息使之不带有提示性，如“您输入的邮箱或密码不对!” 并且超过一定次数则对该IP进行锁定。

问题：检测到可能泄露敏感信息或被恶意利用的冗余文件，如测试文件、bak文件、临时文件。

对策：除去服务器中的相应文件。

问题：发现潜在机密信息，如名为order的文件很容易被联想到用户订单。

对策：避免在文件名中含有完整的敏感词汇或不要在容易猜测到的文件中保存敏感信息，或者限制对它们的访问。

问题：发现内部信息泄露。

对策：除去代码中漏删的内部IP地址，内部组织，人员相关信息等。

 

共性原因分析

在 发现的问题中，71%是与应用程序相关的安全性问题。可以修改应用程序相关的安全性问题，因为它们是由应用程序代码中的缺陷造成的。29%是基础结构和平 台安全性问题，可以由系统或网络管理员来修订“基础结构和平台安全性问题”，因为这些安全性问题是由第三方产品中的错误配置或缺陷造成的。

综合主要的原因包括但不限于以下三个方面。

程序方面

• 未对用户输入正确执行危险字符清理；
• Cookie和Session使用时安全性考虑不足；
• HTML注释中或Hidden form包含敏感信息；
• 提供给用户的错误信息包含敏感信息；
• 程序员在 Web 页面上的调试信息等没有及时删除。
• Web 应用程序编程或配置不安全；

配置方面

• 在Web目录中留下的冗余文件没有及时清理；
• Web服务器或应用程序服务器是以不安全的方式配置的。
• 安全规范文档不够完善，开发人员的培训不足；
• 开发人员的安全相关经验和安全意识不足。

 

对于这些问题的解决方法-——技术之外

对于安全问题本身的解决可能只能case by case ，但为了预防更多潜在问题的引入，技术之外方面的改善也不容忽视：

1. 对于开发人员在项目初期即进行安全开发的培训，强化安全意识。

2. 建立用于共享安全经验的平台，将经验形成Checklist作为安全指南文档。

3. 将成熟的代码成果提炼出公共安全模块以备后用。

本次改善之后总结出一些常用基本安全原则供大家参考，见“非官方不完整网站开发安全原则”。

作者简介：晁晓娟，目前在互联网公司负责项目管理。InfoQ中文站SOA社区编辑，有多年的Web开发管理经验，关注项目管理、架构和产品。