我们有一个较旧的ASP.NET WebForms应用程序,它通过$.ajax()在客户端使用jQuery 调用来执行AJAX请求,在使用[WebMethod]属性修饰的页面代码隐藏中调用静态方法.
如果在WebMethod中发生未处理的异常,则它不会触发Application_Error事件,因此我们的错误记录器(ELMAH)不会将其捕获.这是众所周知的而不是问题 - 我们将所有WebMethod代码包装在try-catch块中,并将异常手动记录到ELMAH.
但是,有一个案例令我难过.如果格式错误的Json发布到WebMethod URL,它会在输入我们的代码之前抛出异常,我找不到任何方法来捕获它.
例如,这个WebMethod签名
[WebMethod]
public static string LeWebMethod(string stringParam, int intParam)
通常使用Json有效负载调用,如:
{"stringParam":"oh hai","intParam":37}
我尝试使用Fiddler进行测试,将有效负载编辑为格式错误的Json:
{"stringParam":"oh hai","intPara
并ArgumentException从JavaScriptObjectDeserializer发送到客户端获得以下错误响应(这是在本地运行的简单测试应用程序,没有自定义错误):
{"Message":"Unterminated string passed in. (32): {\"stringParam\":\"oh hai\",\"intPara","StackTrace":" at
System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeString()\r\n at
System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeMemberName()\r\n at
System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeDictionary(Int32 depth)\r\n at
System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeInternal(Int32 depth)\r\n at
System.Web.Script.Serialization.JavaScriptObjectDeserializer.BasicDeserialize(String input, Int32 depthLimit, JavaScriptSerializer serializer)\r\n at
System.Web.Script.Serialization.JavaScriptSerializer.Deserialize(JavaScriptSerializer serializer, String input, Type type, Int32 depthLimit)\r\n at
System.Web.Script.Serialization.JavaScriptSerializer.Deserialize[T](String input)\r\n at
System.Web.Script.Services.RestHandler.GetRawParamsFromPostRequest(HttpContext context, JavaScriptSerializer serializer)\r\n at …是否有任何清洁的方法可以建立常规链接：
<a href="[8]">Click here to read more...</a>
就像按钮一样
<button id="[8]">Click here to read more...</button>
谢谢 ！
在关注点分离方面,我想知道您对处理SQL注入攻击的问题是否是系统A或系统B的关注的看法,让我解释一下:
系统A - 您被要求实施Web界面,负责确定身份验证,这是确定用户是否存在且密码是否匹配.要执行此操作,您要告知,要确定用户是否存在且有效(密码验证),您必须调用Web服务(系统B).
因此,系统A只是一个接口HTML和JS,它将数据发送到服务器代码,例如PHP页面,然后从PHP页面接收输入并将其传递给Web服务,然后等待响应.
之后,您假设您可以与之通信,并且只获得一些统计数据.要记住用户,请使用cookie.
系统B - Web服务,不是你的责任,是一个以前开发的系统已经工作了很长时间,除了它的WSDL规范之外你对它一无所知.
稍后,一个安全团队,测试你的界面并说'嘿,你允许SQL注入,你的界面有问题,它应该清理输入,以防止SQL注入!!!'.
题 ？
所以,知道你了解情况,我问你们,在网络安全最佳实践和分离问题方面,如果系统A,对Web服务一无所知的接口/代理,强调持久性技术, SQL注入与否？!
如果有一些最好的做法与我的意见相矛盾,你能指点我吗？
我的看法
我的观点是,NO,在这种情况下,接口是责任委托者,并且旨在成为用户复杂规范(WSDL)和更简单的接口(Web页面)之间的代理,它不是用于此接口的Web服务和客户端之间的某种防火墙(客户端> Web服务器> Web服务).
假设
1)浏览器和Web服务器通信受SSL连接(HTTPS)保护.
2)建立WebServer和WebService之间的连接的网络被认为是可信网络,假设您在Web服务器网络(DMZ)和Web服务网络(特权网络)之间有某种防火墙.
3)Web服务当然只能在Web服务器的同一网络中访问.
4)任何人都可以与Web服务进行交谈,因为它不对您可以联系到他的机器执行任何类型的身份验证,尽管这不是系统A的关注,所以这只是让您知道,不需要想一想.