
定位应用架构中的薄弱点
|
135
输出到页面,如果检测到任何脚本执行,则拒绝消息的有效载荷。在数据库
层或客户端层不可能出现涉及无标头浏览器的防护措施。
不同的机制也可以检测到不同的攻击载荷。无标头浏览器可能会检测到脚本
的执行,但如果特定浏览器的
API
有
bug
,脚本可能会绕过这个机制。这种
情况可能会发生,因为有效载荷不会在无标头浏览器中执行,而只会在用户
端有漏洞的浏览器中执行(与服务器上测试时用的浏览器或浏览器版本不同)。
所有这些例子表明,最安全的
Web
应用需在许多层引入安全机制,而不安全
的
Web
应用只在一到两层引入安全机制。在测试
Web
应用程序时,你希望在
应用程序中寻找使用少数安全机制或需要很多层数才能实现的功能(因此很
可能安全机制相对层数的比例较低)。如果你能隔离并确定哪些功能符合这
个标准,那么在寻找漏洞时,应该令其优先于其他功能,因为它更容易被漏
洞利用。
7.3
采纳和重构
最后一个需要注意的风险因素是开发者对现有技术进行再创新的愿望。一般
来说,这并不是作为一个架构问题开始的。相反,它通常是一个组织方面的
问题,这在应用架构中得到了反映和体现。
这种情况在许多软件公司中很常见,因为从开发的角度来看,重塑工具或功
能会带来很多好处,包括:
•
避免软件许可过于复杂。
•
为该功能添加额外的功能。
•
将新工具或新功能作为特色进行宣传。
除此之外,从头开始创建一个功能通常比重新利用现有的开源或付费工具要
有趣得多,也更具挑战性。但是,再创造也不一定是坏事,所以必须对具体
案例进行单独评估。