如果我有2个控制器动作：
[HttpGet]
public ActionResult Login()
{
//...
return View();
}
和
[HttpPost]
public ActionResult Login(FormCollection values)
{
//...
return RedirectToAction("Index","Home");
}
似乎需要Post装饰才能工作（这很有意义），但HttpGet装饰完全是可选的。无论有没有，它都能正常工作。除非另有说明，否则MVC似乎将控制器操作默认为HttpGet。
我必须决定是否希望我的代码的未来读者必须自己解决这个问题，或者我是否想要记住在任何地方添加HttpGet以保持一致性。但我的问题不是关于包含明确的装饰是否是一个好的做法，即使它已经违约了。
我的问题是：是不是总是需要用HttpGet来装饰控制器方法？如果我做或没有明确指定，有什么方法可以咬我吗？我已经搜索了这个但是我能找到的所有帖子都描述了为什么你可能想要使用这两个注释而不是特别包含HttpGet的原因。
答案 0 :(得分：10)
您不必明确指定，不。但请注意：
如果我做或没有明确指定，有什么方法可以咬我？
不太可能。我可以想象一种情况，某些东西可能会出现一些奇怪的行为，或者因为它没有按预期工作，但它很少见。
答案 1 :(得分：0)
如果我明确指定或不明确指定，是否有某种方法可以咬我？
在这里，我想就未对每种GET方法显式使用[HttpGet]的后果，得出罗恩·弗里曼（Rowan Freeman）的答案。
正如已经提到的那样，没有[HttpGet]批注的方法将接受GET和POST请求（除非存在另一种同名的方法带有[HttpPost]批注）。如果用[HttpGet]显式标注了方法，则将返回 405不允许使用方法。
我可以想象的一个结果是，如果攻击者想要通过GET请求发送大量数据，它将受到限制。没有[HttpGet]批注，此限制就不是问题，因为攻击者可以切换到POST并执行相同操作而没有任何限制。
另一个类似的情况是：
HTTPGet只能携带字符串数据，而HTTPPost可以携带字符串和二进制数据。
另一件事是，POST请求可能不会完全记录在服务器上，因此，攻击者可以以某种方式向管理员隐藏其活动，因为攻击者的有效载荷将不可见（日志中不会显示正文）。
在POST和GET（我从中引用）之间的比较可以在这里找到： ASP.NET MVC 5 – HTTPGET And HTTPPOST Method With Example
当然，所有这些情况都是很少见的，但这就是利用的目的-发现可能变成漏洞的稀有事物。
最后，总是在控制器方法中编写[HttpGet]批注是一个好习惯。这只是一条可以提高您的Web应用程序安全性的一行。