第11讲：MVC程序安全限定

2010.9.11 苏鹏

内容介绍

-常见网络安全攻击隐患

-针对ASP.Net MVC防御体系

 

预备知识

-安装Visual Studio 2010 Express

-了解ASP.Net

-了解Ajax基础知识

-了解设计模式基本概念

 

安全性策略

-SQL注入

-脚本注入

ASP.Net时代使用了WebForm，所有的WebForm写的时候都已经提供了非常完善的过滤机制。虽然如此，但是WebForm它太重量级了。所以ASP.Net MVC也是有很大需求的。在做MVC安全性考虑时，我们有四点原则：

1.任何接收用户输入的时候都要做好Encode，把输入的Html标记都去了

2.永远不要对任何人不加检查地使用Html输入。例如白名单，有些超级管理员角色就不加过滤地使用其输入，这样也不好，因为他的身份容易被盗用

3.对Cookies进行验证

4.尽可能防范XSS的类库，即跨站脚本攻击

 

永远不要相信用户的输入是安全的

 

攻击者是谁，想干嘛？

-白帽黑客

主要是开发操作系统漏洞，打补丁

-黑帽黑客

 

攻击是如何进行的

-社会工程学和凯文.米特尼克

1.黑客先要确定目标，用基本的嗅探器嗅探目标状态，然后扫描目标开放的端口，看看端口所使用的服务，看看开了哪些其它的服务，然后在网上找各种已知的漏洞

2.黑客进行攻击

 

黑客攻击的武器

-不间断的尝试

-各种专用设备

-社会工程学技巧（最有利）

 

垃圾邮件

广告发布和木马攻击的桥梁

 

常见攻击方式及其防范

1.跨站脚本攻击

针对网站用户的一种攻击方式，攻击者使用一些技巧在网站上发布一些带有恶意脚本的信息每个无辜的访问者在访问网站的时候出于对网站本身的信任，就被攻击到了。

2.跨站请求

本质上是一种欺骗性攻击，手段是制造从用户端请求的假象，欺骗服务器来源。这是让服务器认为是来自于它相信的客户，而实际上不是那个客户来发起的。

3.Cookie窃取

Cookie能被读就能被写，能被写就能被窜改，能被窜改就能被攻击。所以它是非常有潜在安全隐患的。

4.超载攻击方式

 

Cross-Site Scripting（XSS）

跨站脚本攻击

主要有两种：

1.某用户输入一信息，里面有恶意脚本，这一信息没有过滤就保存到数据库里边了。任何用户通过网页访问都会看到这个信息，结果就导致被攻击了。这种我们称为被动攻击，因为被攻击者需要自己去查看信息。

2.直接把信息推到用户端，这种我们称为主动攻击。

 

-被动攻击

对Url的安全性验证很多网站都有问题。

黑客首先测试在Url中输入Html标记

这个<是暗藏杀机，它是Html脚本的开始。但如果它被做了Encode处理的话，这个<会被转义，在提交以后这个<能被显示出来，这说明它被过滤掉了。

下面的结果是没有过滤，那么Url里面就可以带尖括号的内容并且不会被Encode。

下面我们就可以构建一个特殊的Url

这里为了演示，我们是用iframe嵌入一个图片。真正攻击者一般都会放一个0尺寸的图片，然后src指向一个远程的悄无声息的内容。

我们可以这么干：

我们可以使用一个JavaScript，JavaScript脚本是一个远程脚本，然后我们再把"<a href"完全封装掉。这样用户看到的实际将是一个很普通的链接，但是，这个链接已经把"<a href"这个标签给注释掉了，并且在前面默认加载了JavaScript脚本。

这个脚本能做任何恶意的事，只要他想。这就是一个XSS跨站脚本攻击的简单示例。由于Blog那边没有过滤，结果导致实现了这样的操作。这是被动攻击的典型代表。

 

-主动攻击

主动攻击是赤裸裸地通过欺骗用户访问。这种攻击方式要求攻击着自己有一个域名和网站。它一个特点就是把自己伪装成被攻击网站的一部分，诱导用户下载他们不想下载的东西。这在国外叫主动攻击，但在国外叫生财之道。

 

避免XSS的办法

使用Html.Encode来实现格式化所有内容

在MVC架构中，可以不必写Html.Encode(Model.FirstName)而是直接简写成:Model.FirstName)即可，这是ASP.Net MVC2的一个特质，它保证直接和上面等价。

在ASP.Net WebForm中不需要做这种事，是因为在每个控件提交数据和显示数据的时候都内建了这种Encode模式。

下面这种方式是没有使用Encode处理Url地址的

下面是处理过Url地址的

 

JavaScript编码

这段代码看起来好像没什么问题，但是，假设我们的用户构造一个Url如下：

这是用Url的Encode转义后的内容，实际上它是一个alert，输出pwnd的信息。这虽然没有做任何邪恶的事，但它可以做邪恶的事。我们应该对Url进行过滤。

有两种方式可以解决：

1.AjaxJavaScriptStringEncode函数可以对JavaScript进行编码，这一方法就跟Html里面使用Html.Encode方法是一样的。对它进行编码之后可以过滤这一问题。

2.AntiXss.CodePlex.com它有一个AntiXss.Library.dll的库，把它引入之后，我们的ASP.Net MVC的过程当中Html.Encode和Html.AttributeEncode方法就可以用AntiXss.Encode和AntiXss.AttributeEncode来代替。这两个能过滤更多的JavaScript脚本。

 

跨站请求

跨站请求本身也是实现了跨站的脚本，但是它实现的方法是欺骗一个无辜用户的浏览器来实现的。攻击者通过构造恶意代码，让浏览者替代攻击者去攻击其他网站，即借刀杀人。

下面是一个注销登录的Action

假设有用户来访问我们的网站，浏览器就会加载这个img图片。浏览器实际上就是去尝试请求这个Url了。这个Url如果没有加校验（实际上我们所有的Url都要加校验），那么用户就从这个论坛登出了。这实际上是开个玩笑，我们可以做更多的事。

 

避免跨站欺骗攻击

操作身份认证

避免使用Get

Http来源认证

可以使用Post方法提交数据；可以在Action前面加一些身份认证；可以在页面中加一些隐秘字段，字段是随机生成的数，保证连接是来自于隐秘字段的。

 

盗用Cookies

Cookies功能是网站登录常用的功能。如果禁用它网站登录就失败了。例如想在网站上投票刷票。网站投票主要是靠Cookies，如果想刷票，就要把Cookies禁用。在IE隐私设置里面可以把某一网站的Cookies拒收。设置后，这个网站每点一次Cookies都不会被记录，再找一个按键精灵去点票，这样票就成功的刷上去了。

没禁用的Cookies是一个小的文本文件，它存在IE的临时文件夹里面。但这个文件夹是很安全的，因为IE下载的临时文件不能访问其它的Cookies。比如A网站的进程想访问B网站的Cookies，这是不允许的。一般应用程序想访问这个文件夹也不行，因为它是系统级文件夹。

Cookies有两种：

1.Session Cookies

用于记录和服务器通讯的一系列指标。因为和服务器通讯可能不是持续的，中间可能断开。用Session Cookies就能知道断开重新连接之后还是你。内存里就有一段地址来存放这么一段信息。

2.序列化Cookies

保存在磁盘本地，被偷走的Cookies十有八九也是它。

 

持久化Cookies的窃取

-跨站XSS脚本

参数中c就等于Cookies就被传到网页里面了。这一提交你Cookies文本的内容就全泄露了。它就可以用Request方法拿到你文本的内容，细细地加以分析琢磨，然后构造一个Cookies，或者进行窜改。被修改Cookies的用户就成为傀儡用户，就可以拿他进行攻击了。

当然，要窃取Cookies需要用到跨站脚本攻击的方法。没有这个攻击注入，后面的Cookies是拿不到的。

 

避免Cookie被盗

用HttpOnly等于True这种方式。意思是说Cookies禁用客户端对它进行写操作，只有服务器端对它进行写操作才认可。这是非常有效的办法。另外一定要从根本上避免Cookies被盗，也就是避免被跨站请求攻击。

 

关于重复提交

可以使用Bind这种白名单的方式，限制能修改的属性。

 

避免暴露错误信息

如果把它设置为off，那么用户就能看见你代码第几行错误了。就能看见源代码。如果是数据库连接错误，他就能看到你数据库的链接地址、数据库名字等，这些都是非常大的潜在威胁。所以在发布网站的时候，一定要把这个属性改为on。readonly意思是远程用户看到的信息和本地用户不一样。一般来说这种情况也不足够安全，所以最好发布的时候改成on。

 

保护你的Controller

-[Authorize]来锁定你的Action

对于可以暴露的Action，该授权就授权。

-[nonaction]来锁定所有不开放的Action

不能把Action随便暴露。如果Action函数只是在Controller里面作为内部Service来调用的话，一定要把它写成NonAction，避免别人来猜到。

 

总结

-安全要靠自己

2010.10.4