Do you find that when you work with a new technology that you're never quite sure what security gaps your leaving in your code?
您是否发现当您使用新技术时，您无法确定您在代码中留下的安全漏洞？
I've been working with ASP.Net Web Forms for about 5 years now and am fairly confident my code is at least secure enough to stop most known attacks. Looking back a lot of my early code I have unknowingly left gaps in a lot of the security areas especially query strings and viewstate but I feel over time I learnt what the vulnerabilities were and made sure I didn't make the same mistakes again.
我已经使用ASP.Net Web Forms大约5年了，我相当自信我的代码至少足够安全，可以阻止大多数已知的攻击。回顾我早期的很多代码，我不知不觉地在许多安全领域留下了空白，特别是查询字符串和viewstate，但我觉得随着时间的推移我学会了漏洞，并确保我没有再犯同样的错误。
However I've recently started a new project in ASP.Net MVC and I really have no idea what security holes I'm leaving open. This reason alone is almost putting me off going forth with this. I'm reading up on it like crazy at the minute but am sure I've not learnt nearly enough to make it as secure as I could with Web Forms. What do you guys do to make sure you don't leave yourself open to attack?
但是我最近在ASP.Net MVC中开始了一个新项目，我真的不知道我要打开哪些安全漏洞。仅仅这个原因几乎让我无法继续前进。我现在正在疯狂地读它，但我确信我没有学到足够的东西来使它像Web Forms一样安全。你们做了什么来确保你不会让自己受到攻击？
Edit : Starting Bounty as Curious to see if there are any more opinions
编辑：将Bounty视为好奇，看看是否还有其他意见
10 个解决方案
#1
13
This is a very difficult question with probably no great answer. However, there are a couple things you can do to increase the possibility of keeping yourself safe when using new technologies.
这是一个非常困难的问题，可能没有很好的答案。但是，在使用新技术时，您可以采取一些措施来增加保护自己安全的可能性。
- Keep the following in mind: there are three types of vulnerabilities. Ones that are unique to the framework you are using (e.g. Ruby on Rails public controller problems), ones that are unique to the type of application you building (e.g. Web Applications have to worry about XSS), and ones that are unique to your application in particular.
- 请记住以下几点：有三种类型的漏洞。您正在使用的框架所特有的（例如Ruby on Rails公共控制器问题），您构建的应用程序类型所特有的（例如Web应用程序必须担心XSS），以及您的应用程序独有的那些尤其是。
- Identify how the new technology you are using mitigates application type security vulnerabilities. For example, how does ASP.Net MVC mitigate XSS? How does it mitigate SQL Injection? If there is no answer in the documentation, then figure out how you are going to address these common classes of vulnerabilities. Also, take pause because if the framework doesn't mitigate these issues then maybe the frameworks developers haven't prioritized security and may not have written a very robust framework.
- 确定您使用的新技术如何减轻应用程序类型的安全漏洞。例如，ASP.Net MVC如何缓解XSS？它如何减轻SQL注入？如果文档中没有答案，那么请弄清楚如何解决这些常见的漏洞类别。此外，暂停，因为如果框架没有缓解这些问题，那么框架开发人员可能没有优先考虑安全性，也可能没有编写一个非常强大的框架。
- Figure out why you need security and what you are trying to protect. For example: Does your application require authorization before viewing sensitive data? If so, determine what features the framework provides for authorization.
- 弄清楚为什么需要安全性以及您要保护的内容。例如：在查看敏感数据之前，您的应用程序是否需要授权？如果是，请确定框架为授权提供的功能。
- Look for a security section in the documentation. Often known issues are documented but people focus so much on getting their problem solved that they don't look for it.
- 在文档中查找安全性部分。通常已知问题已记录在案，但人们非常关注如何解决他们的问题，而不是寻找问题。
- Code defensively and be aware of how user input is used. Be generous in defining what is user input. For example, the querystring or post fields are obvious, but in many MVC frameworks the URL dictates what code runs (e.g. see Ruby Routes vulnerability). Be very aware of how the data is handled
- 防御性地编码，并了解用户输入的使用方式。慷慨地定义什么是用户输入。例如，querystring或post字段很明显，但在许多MVC框架中，URL指示运行的代码（例如，参见Ruby Routes漏洞）。非常了解数据的处理方式
- Stress test your business logic and figure out how it could potentially be abused.
- 压力测试您的业务逻辑并找出它可能被滥用的方式。
So in short: Handle user input carefully, read the existing documentation, determine what security you require, and figure out how the framework mitigates common vulnerability classes. Being aware that security is a priority and paying attention is 50% of the fight.
简而言之：仔细处理用户输入，阅读现有文档，确定所需的安全性，并找出框架如何减轻常见的漏洞类。意识到安全是一个优先事项，关注是战斗的50％。
#2
4
I think a LOT of what you learned about with ASP.NET is transferable to ASP.NET MVC. It's still HTML (exploits: XSS) over HTTP (exploits: all input [cookies, URL parameters, form input, headers] can be forged, session hijacking, CSRF) with a database back end (exploits: SQL injection).
我认为您在ASP.NET中学到的很多东西都可以转移到ASP.NET MVC。它仍然是HTTP上的HTML（漏洞利用：XSS）（利用：所有输入[cookie，URL参数，表单输入，标题]可以伪造，会话劫持，CSRF）与数据库后端（漏洞利用：SQL注入）。
I would recommend Steve Sanderson's book on ASP.NET MVC titled Pro ASP.NET MVC Framework. It has an entire chapter dedicated to these topics.
我会推荐史蒂夫桑德森关于ASP.NET MVC的书，名为Pro ASP.NET MVC Framework。它有一整章专门讨论这些主题。
Check out Chapter 13 'Security and Vulnerability' from the Table of Contents for the book.
从本书的目录中查看第13章“安全性和漏洞”。
#3
3
all the time.
the more you learn, the more you can prevent security holes in the future.
每时每刻。学的越多，未来就越能防止安全漏洞。
you said it yourself, your old code is ripe with security holes that you would never add to anything you write new. This is a great testament to your ability to learn and adapt to what you are working with.
你自己说过，你的旧代码已经成熟，安全漏洞是你永远不会添加到你写的新东西。这是您学习和适应您正在使用的内容的能力的一个很好的证明。
I think you are on the right track with your thinking, remember, no one gets it right the first time (at least I don't) that's why re-factoring is so cool.
我认为你的想法是正确的，记住，没有人第一次就做对了（至少我没有）这就是为什么重新分解是如此酷。
don't let this deter you from learning something new, just do your best, read up on security threats for your technology and go. (try http://www.securityfocus.com)
不要让这阻止你学习新的东西，只要尽力，阅读你的技术的安全威胁，然后去。 （试试http://www.securityfocus.com）
peer reviews can help with this and there are tools out there that can make finding security holes easier.
同行评审可以帮助解决这个问题，并且有一些工具可以帮助您更轻松地找到安全漏洞。
#4
3
The technologies you use may change, but the underlying problems of security don't. If anything, I would expect fewer security holes in code that uses newer libraries, because they're designed with common attacks in mind. For example, SQL injection just Doesn't Happen with the classes VS2008 generates via DBML.
您使用的技术可能会发生变化，但安全性的根本问题却没有。如果有的话，我会期望使用更新库的代码中的安全漏洞更少，因为它们的设计考虑了常见的攻击。例如，SQL注入只是不会发生VS2008通过DBML生成的类。
#5
3
I guess do what we do whenever we learn something new like when you are a confident bike rider and switch to motorbikes you never take it on the freeway on day 1. In my exp prototyping helps a lot. Put your code to test by actually trying to break it. Reading up on the new technology is extremely important. I have seen people jump into new technologies just because it sounds cool.
我想我们做什么，每当我们学到新东西时，比如当你是一个自信的自行车骑手并切换到摩托车，你永远不会在第1天把它带到高速公路上。在我的exp原型设计有很大帮助。通过实际尝试破解它来测试代码。阅读新技术非常重要。我看到人们跳进新技术只是因为它听起来很酷。
Do a bit of research and find any OSS built on the same technology. Playing around with it may reveal a lot of things.
做一些研究，找到任何基于相同技术的OSS。玩弄它可能会揭示很多东西。
EDIT: ASP.NET MVC OSS ?? Look at the nerddinner.com source code and play with it. Contributors are top notch and I assume they must have given a thought to security while creating this!
编辑：ASP.NET MVC OSS ??查看nerddinner.com源代码并使用它。贡献者是一流的，我认为他们必须在创建时考虑安全性！
#6
2
Tip specifically for ASP.NET MVC:
专门针对ASP.NET MVC提示：
In your views, use the HtmlHelper methods as much as possible (e.g. Html.BeginForm, Html.TextBox, Html.ActionLink, etc), versus raw HTML tags. The helpers will automatically HTML encode the values you pass into it, reducing the chances of creating an XSS vulnerability.
在您的视图中，尽可能使用HtmlHelper方法（例如Html.BeginForm，Html.TextBox，Html.ActionLink等），而不是原始HTML标记。帮助程序将自动对您传递给它的值进行HTML编码，从而减少创建XSS漏洞的可能性。
For all other input that you are playing back in your view, always use Html.Encode.
对于您在视图中播放的所有其他输入，请始终使用Html.Encode。
#7
2
Again, specific to ASP.NET MVC, really watch the use of Model Binding. You should always explicitly specify the properies that will be bound.
再次，具体到ASP.NET MVC，真正关注模型绑定的使用。您应该始终明确指定要绑定的属性。
Failing to do this can lead to some unexpected side effects (as I found out..!) and may allow someone to maliciously alter model properties.
如果不这样做会导致一些意想不到的副作用（正如我发现的那样......！）并且可能允许某人恶意改变模型属性。
#8
2
A lot of MVC is the same as WebForms - they both sit on Asp.net, as @GuyIncognito has already said, most of it is the same.
许多MVC与WebForms相同 - 他们都坐在Asp.net上，正如@GuyIncognito已经说过的，大多数都是相同的。
The main difference is that WebForms can validate their postback - they have unique keys in the page content that confirm that each postback has come from the page served.
主要区别在于WebForms可以验证其回发 - 它们在页面内容中具有唯一键，用于确认每个回发都来自所提供的页面。
Only it doesn't, it can be hacked, the viewstate wastes loads of space and it can never completely be turned off. I find best practice with WebForms is never to assume that the postback is definitely from the page served and re-check security anyway.
只有它没有，它可以被黑客攻击，视图状态浪费了大量的空间，它永远不会被完全关闭。我发现WebForms的最佳实践永远不会假设回发肯定来自所提供的页面并且无论如何都要重新检查安全性。
With MVC postbacks are to different actions, with models and model-binders encapsulating the content in type-safe objects. The checks still need to be done, as spoofing the postback is now much easier. So:
MVC回发是针对不同的操作，模型和模型绑定器将内容封装在类型安全的对象中。检查仍然需要完成，因为现在更容易欺骗回发。所以：
- Never assume that the model is from a particular source.
- 永远不要假设模型来自特定来源。
- Assume that the model may be corrupted and don't rely on it.
- 假设模型可能已损坏且不依赖于它。
- Treat MVC controller actions as you would WebMethod or service calls - a hack attempt can call any of them, in any order, with any parameters.
- 像处理WebMethod或服务调用一样处理MVC控制器操作 - 黑客尝试可以使用任何参数以任何顺序调用它们中的任何一个。
All of this is best-practice in WebForms anyway, it's just easier to attempt this type of hack in MVC now.
所有这些都是WebForms中的最佳实践，现在更容易在MVC中尝试这种类型的hack。
MVC includes anti forgery token support, here's an excellent article on them. it helps, but I still wouldn't rely on it.
MVC包括防伪代码支持，这里有一篇很好的文章。它有所帮助，但我仍然不会依赖它。
Everything else (encode all user generated output, parametrise all Sql input, etc) is the same.
其他一切（编码所有用户生成的输出，参数化所有Sql输入等）是相同的。
#9
1
Simple, never trust anything that comes in to your application :) Some people have already made some great posts here about the fact that you can fake any posts to the framework easily, but this should be no different from webforms anyway since it can be done.
简单，永远不要相信你的应用程序中的任何内容:)有些人已经在这里发表了一些很好的帖子，关于你可以轻松伪造任何帖子到框架这一事实，但这应该与webforms无异，因为它可以完成。
ASP.NET MVC has some nice features for validating your data, especially with v2. Here's Scott Gu's post about v2 that shows how to do validation in a really neat way. Also note that you can easily implement your own validation methods in the same way.
ASP.NET MVC具有一些很好的功能来验证您的数据，尤其是v2。这是Scott Gu关于v2的帖子，它展示了如何以一种非常简洁的方式进行验证。另请注意，您可以以相同的方式轻松实现自己的验证方法。
Authorization is also the same, you can decorate your Controller or Action with the Authorize attribute and specify which roles are allowed to access it. This uses .NET's authentication framework just like web forms, so you can implement your own security here as well.
授权也是相同的，您可以使用Authorize属性修饰Controller或Action，并指定允许哪些角色访问它。这就像Web表单一样使用.NET的身份验证框架，因此您也可以在此处实现自己的安全性。
Overall I really find these(most) things much easier to work with in the MVC Framework as there is no magic going on behind the scenes. You can replace almost anything in the framework and you are in full control. It might require a little getting used to though if you have been working with webforms, but I'm sure you'll love it once you do.
总的来说，我真的觉得这些（大多数）事情在MVC框架中更容易使用，因为幕后没有任何魔力。您可以替换框架中的几乎任何内容，并且您可以完全控制。如果你一直在使用webforms，可能需要一点点习惯，但我相信你一旦爱上它就会爱上它。
#10
0
One simple solution: Assume there are security holes in your application, and plug them up outside of your application. For example, restrict access (via IIS) to "unsafe" URLS with SSL and/or IP restrictions.
一个简单的解决方案：假设您的应用程序中存在安全漏洞，并将其插入应用程序之外。例如，使用SSL和/或IP限制将访问（通过IIS）限制为“不安全”URL。
#1
13
This is a very difficult question with probably no great answer. However, there are a couple things you can do to increase the possibility of keeping yourself safe when using new technologies.
这是一个非常困难的问题，可能没有很好的答案。但是，在使用新技术时，您可以采取一些措施来增加保护自己安全的可能性。
- Keep the following in mind: there are three types of vulnerabilities. Ones that are unique to the framework you are using (e.g. Ruby on Rails public controller problems), ones that are unique to the type of application you building (e.g. Web Applications have to worry about XSS), and ones that are unique to your application in particular.
- 请记住以下几点：有三种类型的漏洞。您正在使用的框架所特有的（例如Ruby on Rails公共控制器问题），您构建的应用程序类型所特有的（例如Web应用程序必须担心XSS），以及您的应用程序独有的那些尤其是。
- Identify how the new technology you are using mitigates application type security vulnerabilities. For example, how does ASP.Net MVC mitigate XSS? How does it mitigate SQL Injection? If there is no answer in the documentation, then figure out how you are going to address these common classes of vulnerabilities. Also, take pause because if the framework doesn't mitigate these issues then maybe the frameworks developers haven't prioritized security and may not have written a very robust framework.
- 确定您使用的新技术如何减轻应用程序类型的安全漏洞。例如，ASP.Net MVC如何缓解XSS？它如何减轻SQL注入？如果文档中没有答案，那么请弄清楚如何解决这些常见的漏洞类别。此外，暂停，因为如果框架没有缓解这些问题，那么框架开发人员可能没有优先考虑安全性，也可能没有编写一个非常强大的框架。
- Figure out why you need security and what you are trying to protect. For example: Does your application require authorization before viewing sensitive data? If so, determine what features the framework provides for authorization.
- 弄清楚为什么需要安全性以及您要保护的内容。例如：在查看敏感数据之前，您的应用程序是否需要授权？如果是，请确定框架为授权提供的功能。
- Look for a security section in the documentation. Often known issues are documented but people focus so much on getting their problem solved that they don't look for it.
- 在文档中查找安全性部分。通常已知问题已记录在案，但人们非常关注如何解决他们的问题，而不是寻找问题。
- Code defensively and be aware of how user input is used. Be generous in defining what is user input. For example, the querystring or post fields are obvious, but in many MVC frameworks the URL dictates what code runs (e.g. see Ruby Routes vulnerability). Be very aware of how the data is handled
- 防御性地编码，并了解用户输入的使用方式。慷慨地定义什么是用户输入。例如，querystring或post字段很明显，但在许多MVC框架中，URL指示运行的代码（例如，参见Ruby Routes漏洞）。非常了解数据的处理方式
- Stress test your business logic and figure out how it could potentially be abused.
- 压力测试您的业务逻辑并找出它可能被滥用的方式。
So in short: Handle user input carefully, read the existing documentation, determine what security you require, and figure out how the framework mitigates common vulnerability classes. Being aware that security is a priority and paying attention is 50% of the fight.
简而言之：仔细处理用户输入，阅读现有文档，确定所需的安全性，并找出框架如何减轻常见的漏洞类。意识到安全是一个优先事项，关注是战斗的50％。
#2
4
I think a LOT of what you learned about with ASP.NET is transferable to ASP.NET MVC. It's still HTML (exploits: XSS) over HTTP (exploits: all input [cookies, URL parameters, form input, headers] can be forged, session hijacking, CSRF) with a database back end (exploits: SQL injection).
我认为您在ASP.NET中学到的很多东西都可以转移到ASP.NET MVC。它仍然是HTTP上的HTML（漏洞利用：XSS）（利用：所有输入[cookie，URL参数，表单输入，标题]可以伪造，会话劫持，CSRF）与数据库后端（漏洞利用：SQL注入）。
I would recommend Steve Sanderson's book on ASP.NET MVC titled Pro ASP.NET MVC Framework. It has an entire chapter dedicated to these topics.
我会推荐史蒂夫桑德森关于ASP.NET MVC的书，名为Pro ASP.NET MVC Framework。它有一整章专门讨论这些主题。
Check out Chapter 13 'Security and Vulnerability' from the Table of Contents for the book.
从本书的目录中查看第13章“安全性和漏洞”。
#3
3
all the time.
the more you learn, the more you can prevent security holes in the future.
每时每刻。学的越多，未来就越能防止安全漏洞。
you said it yourself, your old code is ripe with security holes that you would never add to anything you write new. This is a great testament to your ability to learn and adapt to what you are working with.
你自己说过，你的旧代码已经成熟，安全漏洞是你永远不会添加到你写的新东西。这是您学习和适应您正在使用的内容的能力的一个很好的证明。
I think you are on the right track with your thinking, remember, no one gets it right the first time (at least I don't) that's why re-factoring is so cool.
我认为你的想法是正确的，记住，没有人第一次就做对了（至少我没有）这就是为什么重新分解是如此酷。
don't let this deter you from learning something new, just do your best, read up on security threats for your technology and go. (try http://www.securityfocus.com)
不要让这阻止你学习新的东西，只要尽力，阅读你的技术的安全威胁，然后去。 （试试http://www.securityfocus.com）
peer reviews can help with this and there are tools out there that can make finding security holes easier.
同行评审可以帮助解决这个问题，并且有一些工具可以帮助您更轻松地找到安全漏洞。
#4
3
The technologies you use may change, but the underlying problems of security don't. If anything, I would expect fewer security holes in code that uses newer libraries, because they're designed with common attacks in mind. For example, SQL injection just Doesn't Happen with the classes VS2008 generates via DBML.
您使用的技术可能会发生变化，但安全性的根本问题却没有。如果有的话，我会期望使用更新库的代码中的安全漏洞更少，因为它们的设计考虑了常见的攻击。例如，SQL注入只是不会发生VS2008通过DBML生成的类。
#5
3
I guess do what we do whenever we learn something new like when you are a confident bike rider and switch to motorbikes you never take it on the freeway on day 1. In my exp prototyping helps a lot. Put your code to test by actually trying to break it. Reading up on the new technology is extremely important. I have seen people jump into new technologies just because it sounds cool.
我想我们做什么，每当我们学到新东西时，比如当你是一个自信的自行车骑手并切换到摩托车，你永远不会在第1天把它带到高速公路上。在我的exp原型设计有很大帮助。通过实际尝试破解它来测试代码。阅读新技术非常重要。我看到人们跳进新技术只是因为它听起来很酷。
Do a bit of research and find any OSS built on the same technology. Playing around with it may reveal a lot of things.
做一些研究，找到任何基于相同技术的OSS。玩弄它可能会揭示很多东西。
EDIT: ASP.NET MVC OSS ?? Look at the nerddinner.com source code and play with it. Contributors are top notch and I assume they must have given a thought to security while creating this!
编辑：ASP.NET MVC OSS ??查看nerddinner.com源代码并使用它。贡献者是一流的，我认为他们必须在创建时考虑安全性！
#6
2
Tip specifically for ASP.NET MVC:
专门针对ASP.NET MVC提示：
In your views, use the HtmlHelper methods as much as possible (e.g. Html.BeginForm, Html.TextBox, Html.ActionLink, etc), versus raw HTML tags. The helpers will automatically HTML encode the values you pass into it, reducing the chances of creating an XSS vulnerability.
在您的视图中，尽可能使用HtmlHelper方法（例如Html.BeginForm，Html.TextBox，Html.ActionLink等），而不是原始HTML标记。帮助程序将自动对您传递给它的值进行HTML编码，从而减少创建XSS漏洞的可能性。
For all other input that you are playing back in your view, always use Html.Encode.
对于您在视图中播放的所有其他输入，请始终使用Html.Encode。
#7
2
Again, specific to ASP.NET MVC, really watch the use of Model Binding. You should always explicitly specify the properies that will be bound.
再次，具体到ASP.NET MVC，真正关注模型绑定的使用。您应该始终明确指定要绑定的属性。
Failing to do this can lead to some unexpected side effects (as I found out..!) and may allow someone to maliciously alter model properties.
如果不这样做会导致一些意想不到的副作用（正如我发现的那样......！）并且可能允许某人恶意改变模型属性。
#8
2
A lot of MVC is the same as WebForms - they both sit on Asp.net, as @GuyIncognito has already said, most of it is the same.
许多MVC与WebForms相同 - 他们都坐在Asp.net上，正如@GuyIncognito已经说过的，大多数都是相同的。
The main difference is that WebForms can validate their postback - they have unique keys in the page content that confirm that each postback has come from the page served.
主要区别在于WebForms可以验证其回发 - 它们在页面内容中具有唯一键，用于确认每个回发都来自所提供的页面。
Only it doesn't, it can be hacked, the viewstate wastes loads of space and it can never completely be turned off. I find best practice with WebForms is never to assume that the postback is definitely from the page served and re-check security anyway.
只有它没有，它可以被黑客攻击，视图状态浪费了大量的空间，它永远不会被完全关闭。我发现WebForms的最佳实践永远不会假设回发肯定来自所提供的页面并且无论如何都要重新检查安全性。
With MVC postbacks are to different actions, with models and model-binders encapsulating the content in type-safe objects. The checks still need to be done, as spoofing the postback is now much easier. So:
MVC回发是针对不同的操作，模型和模型绑定器将内容封装在类型安全的对象中。检查仍然需要完成，因为现在更容易欺骗回发。所以：
- Never assume that the model is from a particular source.
- 永远不要假设模型来自特定来源。
- Assume that the model may be corrupted and don't rely on it.
- 假设模型可能已损坏且不依赖于它。
- Treat MVC controller actions as you would WebMethod or service calls - a hack attempt can call any of them, in any order, with any parameters.
- 像处理WebMethod或服务调用一样处理MVC控制器操作 - 黑客尝试可以使用任何参数以任何顺序调用它们中的任何一个。
All of this is best-practice in WebForms anyway, it's just easier to attempt this type of hack in MVC now.
所有这些都是WebForms中的最佳实践，现在更容易在MVC中尝试这种类型的hack。
MVC includes anti forgery token support, here's an excellent article on them. it helps, but I still wouldn't rely on it.
MVC包括防伪代码支持，这里有一篇很好的文章。它有所帮助，但我仍然不会依赖它。
Everything else (encode all user generated output, parametrise all Sql input, etc) is the same.
其他一切（编码所有用户生成的输出，参数化所有Sql输入等）是相同的。
#9
1
Simple, never trust anything that comes in to your application :) Some people have already made some great posts here about the fact that you can fake any posts to the framework easily, but this should be no different from webforms anyway since it can be done.
简单，永远不要相信你的应用程序中的任何内容:)有些人已经在这里发表了一些很好的帖子，关于你可以轻松伪造任何帖子到框架这一事实，但这应该与webforms无异，因为它可以完成。
ASP.NET MVC has some nice features for validating your data, especially with v2. Here's Scott Gu's post about v2 that shows how to do validation in a really neat way. Also note that you can easily implement your own validation methods in the same way.
ASP.NET MVC具有一些很好的功能来验证您的数据，尤其是v2。这是Scott Gu关于v2的帖子，它展示了如何以一种非常简洁的方式进行验证。另请注意，您可以以相同的方式轻松实现自己的验证方法。
Authorization is also the same, you can decorate your Controller or Action with the Authorize attribute and specify which roles are allowed to access it. This uses .NET's authentication framework just like web forms, so you can implement your own security here as well.
授权也是相同的，您可以使用Authorize属性修饰Controller或Action，并指定允许哪些角色访问它。这就像Web表单一样使用.NET的身份验证框架，因此您也可以在此处实现自己的安全性。
Overall I really find these(most) things much easier to work with in the MVC Framework as there is no magic going on behind the scenes. You can replace almost anything in the framework and you are in full control. It might require a little getting used to though if you have been working with webforms, but I'm sure you'll love it once you do.
总的来说，我真的觉得这些（大多数）事情在MVC框架中更容易使用，因为幕后没有任何魔力。您可以替换框架中的几乎任何内容，并且您可以完全控制。如果你一直在使用webforms，可能需要一点点习惯，但我相信你一旦爱上它就会爱上它。
#10
0
One simple solution: Assume there are security holes in your application, and plug them up outside of your application. For example, restrict access (via IIS) to "unsafe" URLS with SSL and/or IP restrictions.
一个简单的解决方案：假设您的应用程序中存在安全漏洞，并将其插入应用程序之外。例如，使用SSL和/或IP限制将访问（通过IIS）限制为“不安全”URL。