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