使用新技术时的安全问题

时间:2009-06-04 15:36:28

标签: .net asp.net asp.net-mvc security

您是否发现当您使用新技术时,您无法确定您在代码中留下的安全漏洞?

我已经使用ASP.Net Web Forms大约5年了,我相信我的代码至少足够安全,可以阻止大多数已知的攻击。回顾我的许多早期代码,我在不知不觉中在许多安全领域留下了空白,特别是查询字符串和viewstate,但我觉得随着时间的推移我了解了漏洞是什么,并确保我没有再犯同样的错误。

但是我最近在ASP.Net MVC中开始了一个新项目,我真的不知道我要打开哪些安全漏洞。仅仅这个原因几乎让我不顾一切。我现在正在疯狂地阅读它,但我确信我没有学到足够的东西来使它像Web Forms一样安全。你们做了什么来确保不让自己受到攻击?

编辑:将Bounty视为好奇,看是否还有其他意见

10 个答案:

答案 0 :(得分:13)

这是一个非常困难的问题,可能没有很好的答案。但是,在使用新技术时,您可以采取一些措施来增加保护自己安全的可能性。

  1. 请记住以下几点:有三种类型的漏洞。您正在使用的框架所独有的(例如Ruby on Rails公共控制器问题),您构建的应用程序类型所特有的(例如Web应用程序必须担心XSS),以及您的应用程序独有的那些特别是。
  2. 确定您使用的新技术如何减轻应用程序类型的安全漏洞。例如,ASP.Net MVC如何缓解XSS?它如何缓解SQL注入?如果文档中没有答案,那么请弄清楚如何解决这些常见的漏洞类别。此外,暂停,因为如果框架没有缓解这些问题,那么框架开发人员可能没有优先考虑安全性,也可能没有编写非常强大的框架。
  3. 找出您需要安全性的原因以及您要保护的内容。例如:您的应用程序在查看敏感数据之前是否需要授权?如果是,请确定框架为授权提供的功能。
  4. 在文档中查找安全性部分。通常已知问题已记录在案,但人们非常关注如何解决他们的问题,而他们并不寻求解决问题。
  5. 防御性地编码,并了解用户输入的使用方式。慷慨地定义什么是用户输入。例如,querystring或post字段很明显,但在许多MVC框架中,URL指示运行的代码(例如,参见Ruby Routes漏洞)。非常了解数据的处理方式
  6. 压力测试您的业务逻辑并弄清楚它可能会被滥用。
  7. 简而言之:仔细处理用户输入,阅读现有文档,确定所需的安全性,并弄清楚框架如何减轻常见的漏洞类别。意识到安全是一个优先事项,并且注意力是战斗的50%。

答案 1 :(得分:4)

我认为您在ASP.NET中学到的很多东西都可以转移到ASP.NET MVC。它仍然是HTTP上的HTML(漏洞利用:XSS)(利用:所有输入[cookie,URL参数,表单输入,标题]可以伪造,会话劫持,CSRF)与数据库后端(漏洞利用:SQL注入)。

我建议将Steve Sanderson's本书放在名为Pro ASP.NET MVC Framework的ASP.NET MVC上。它有一整章专门讨论这些主题。

查看本书Table of Contents的第13章“安全性和漏洞”。

答案 2 :(得分:3)

一直以来 学的越多,未来就越能防止安全漏洞。

你自己说过,你的旧代码已经成熟,安全漏洞你永远不会添加到你写的新内容中。这是您学习和适应您正在使用的内容的能力的一个很好的证明。

我认为你的想法是正确的,记住,没有人第一次就做对了(至少我没有)这就是为什么重新分解是如此酷。

不要让这阻止你学习新东西,只要尽力,阅读你的技术的安全威胁,然后去。 (尝试http://www.securityfocus.com

同行评审可以帮助解决这个问题,并且有一些工具可以帮助您更轻松地找到安全漏洞。

答案 3 :(得分:3)

我想我们做什么,每当我们学到新东西时,比如当你是一个自信的自行车骑手并切换到摩托车,你从来没有在第1天在高速公路上接受它。在我的exp原型设计有很大帮助。通过实际尝试破解它来测试代码。阅读新技术非常重要。我看到人们跳进新技术只是因为它听起来很酷。

进行一些研究并找到基于相同技术的任何OSS。玩弄它可能会揭示很多东西。

编辑:ASP.NET MVC OSS?查看nerddinner.com源代码并使用它。贡献者是一流的,我认为他们必须在创建时考虑安全性!

答案 4 :(得分:3)

您使用的技术可能会发生变化,但安全性的潜在问题却不会发生变化。如果有的话,我会期望使用更新库的代码中的安全漏洞更少,因为它们的设计考虑了常见的攻击。例如,SQL注入只是不会发生VS2008通过DBML生成的类。

答案 5 :(得分:2)

专门针对ASP.NET MVC提示:

在您的视图中,尽可能使用HtmlHelper方法(例如Html.BeginForm,Html.TextBox,Html.ActionLink等)与原始HTML标记。帮助程序将自动对您传递给它的值进行HTML编码,从而减少创建XSS漏洞的可能性。

对于您在视图中播放的所有其他输入,请始终使用Html.Encode。

答案 6 :(得分:2)

再次,具体到ASP.NET MVC,真正关注模型绑定的使用。您应该始终明确指定要绑定的属性。

如果不这样做会导致一些意想不到的副作用(正如我发现的那样......!)并且可能允许某人恶意改变模型属性。

答案 7 :(得分:2)

许多MVC与WebForms相同 - 他们都坐在Asp.net上,正如@GuyIncognito已经说过的那样,大部分是相同的。

主要区别在于WebForms可以验证其回发 - 它们在页面内容中具有唯一键,用于确认每个回发都来自所提供的页面。

只有它没有,它可以被黑客攻击,视图状态浪费了大量的空间,它永远不会被完全关闭。我发现WebForms的最佳实践永远不会假设回发肯定来自所提供的页面,并且无论如何都要重新检查安全性。

MVC回发是针对不同的操作,模型和模型绑定器将内容封装在类型安全的对象中。检查仍然需要完成,因为现在更容易欺骗回发。所以:

  • 绝不假设模型来自特定来源。
  • 假设模型可能已损坏且不依赖它。
  • 像对待WebMethod或服务调用一样处理MVC控制器操作 - 黑客尝试可以使用任何参数以任何顺序调用它们中的任何一个。

无论如何,所有这些都是WebForms的最佳实践,现在在MVC中尝试这种类型的攻击会更容易。

MVC包含防伪令牌支持here's an excellent article on them。它有所帮助,但我仍然不会依赖它。

其他所有内容(编码所有用户生成的输出,参数化所有Sql输入等)都是相同的。

答案 8 :(得分:1)

简单,永远不要相信你的应用程序中的任何内容:)有些人已经在这里做了一些很棒的帖子,你可以轻松地伪造任何帖子到框架,但这应该与webforms无异,因为它可以做到。

ASP.NET MVC有一些很好的功能可用于验证您的数据,尤其是v2。这里的Scott Gu's post about v2显示了如何以非常简洁的方式进行验证。另请注意,您可以以相同的方式轻松实现自己的验证方法。

授权也是相同的,您可以使用Authorize属性修饰Controller或Action,并指定允许哪些角色访问它。这就像Web表单一样使用.NET的身份验证框架,因此您也可以在这里实现自己的安全性。

总的来说,我真的觉得这些(大多数)事情在MVC框架中更容易使用,因为幕后没有任何魔力。您可以替换框架中的几乎任何内容,并且您可以完全控制。如果你一直在使用webforms,可能需要一点点习惯,但我相信你一旦爱上它就会爱上它。

答案 9 :(得分:0)

一个简单的解决方案:假设您的应用程序中存在 安全漏洞,并将其插入应用程序之外。例如,使用SSL和/或IP限制限制访问(通过IIS)到“不安全”的URL。