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

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

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

在笔者曾经参与过的一个项目中，客户方邀请了专业的第三方安全测试公司进行了安全性的全面检测，同时也针对性地进行了安全性的改善，特别是在应用程序方面。此文将分享改善过程中的几个典型问题的分析和解决对策，包括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代替。

改善之前

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

未标题-2

问题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 |<|>|’|(|)|{|}

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

接下来做如下处理：

未标题-1

问题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：验证环节可以被绕过