关于我的这个question，我得到了以下答案，将其添加到Web配置文件中。它也解决了我面临的问题。但现在我的问题是，是否有任何形式的安全威胁？如果是的话，可能会有多严重？它可能是什么样的威胁？你在这里建议别的吗？我可以使用Web服务面对哪种安全威胁？
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
默认情况下禁用HttpGet和HttpPost的原因是您可以轻松地将其用于XSS攻击。来自http://msdn.microsoft.com/en-us/library/ff648667.aspx：
通过禁用不必要的协议，包括HttpPost和HttpGet，可以减少攻击面积。例如，外部攻击者可能会在电子邮件中嵌入恶意链接，以使用最终用户的安全上下文执行内部Web服务。禁用HttpGet协议是一种有效的对策。在很多方面，这与XSS攻击类似。这种攻击的一种变体使用可公开访问的网页上的标签将GET调用嵌入到Intranet Web服务中。这两种攻击都可以让外人调用内部Web服务。禁用协议可以降低风险。
有关XS攻击的更多信息，请参见http://en.wikipedia.org/wiki/Cross-site_scripting。
我通常避免使用HttpGet和HttpPost是可能的。如果它是以任何方式管理金钱的网络服务，我不惜一切代价避免它。尽可能使用SOAP Web服务。
一般来说，当你实现一个基本的SOAP Web服务时，你将服务暴露给世界，无论好坏。您在代码中必须考虑的主要问题是验证输入。天真地接受字符串可能会非常有害。如果有任何值可能是您无法处理的数字，请查找它并且不要继续。如果你接受字符串，确保你彻底清理它们（寻找和非常怀疑分号，并逃脱你看到的每一个“特殊字符”）。
对于在SQL查询中使用unsanitized字符串的天真服务的常见攻击可能看起来像“ABC”; drop database master;“。如果你的代码注入到SQL查询中而没有注意到伪造的查询终止和恶意脚本，你可能在第二天清理你的桌面。解决方案非常简单;转义单引号，用ASCII或Unicode表示法替换分号，您可以将其翻译回来（或简单地将其除去），并且服务调用将它视为垃圾。
这提出了第二点;即使它们是你的代码，你的Web服务也应该成为你系统其他部分非常怀疑的主题。 Web服务应该使用DB身份验证，它提供尽可能少的权限来完成他们的工作。如果您的服务使用管理员或DBO登录，则几乎肯定是错误的;上面的查询，如果它通过，实际上会被执行，并且您的主数据库不再能够使您的数据库服务器无法运行。如果你的服务使用了一个非常严格地将权限控制在服务所需要的权限的登录名，那么SQL Server会陷入困境，但是这比失去你的主数据库要好得多。
另外，要非常小心异常处理。通过SOAP返回的形式很差的异常，就像一个有效的结果一样，可能包含机密信息，鼓励攻击者尝试让您的服务抛出一个异常，其中包含有关服务背后实现的有用信息。 SQL/ADO例外对攻击者特别有用，因为它们提供了可能被利用来造成麻烦的数据结构信息。寻找可能会导致无法控制的异常的事情，并在CLR或其他层比代码更深的层次之前优雅地处理这种情况。捕获所有异常在其他地方通常是不好的做法，但是在某些情况下，带有一些消毒功能的“catch-and-release”可能是一个好主意，而通常指示异常陷阱的非常通用的500错误重定向在webosphere中是很常见的做法。如果您想要或必须在代码中抛出异常，请仔细制作它，并且不要包含任何您不希望世界知道的信息。
从建筑的角度来看，想想你的服务就像墙上的电源插座。插头是让你想要的东西（电源）离开墙壁的唯一途径。你知道有J-box，导管，开关等，但是如果没有很多（文字）黑客攻击，你就无法访问它们。按照这个比喻，你的端点应该被设置为在指定的已知端口上进行监听，而系统的其他部分应该看起来像从外面看到的墙;所有其他港口应该关闭。
我想你应该迁移到基于WCF的Web服务。除了WCF对asmx的所有其他好处之外，WCF 4还具有基于HTTP Accept头的自动响应格式选择（json或xml），或者与请求消息格式不同。
一般来说，如果你有面向公众的网络服务，那么DOS攻击是你应该担心的。在最坏的情况下，它可能会导致你的服务崩溃，最好它会拒绝你的WS的合法呼叫者。格式错误的SOAP消息，XML bombs可用于DOS攻击。
Web服务威胁我的狗一次.. – 2010-09-01 16:12:10