随着企业数字化转型的深入,越来越多的业务应用系统被部署到互联网平台上,这吸引了网络犯罪团伙的强烈关注,以Web攻击为代表的应用层安全威胁开始凸显。通过利用网站系统和Web服务程序的安全漏洞,攻击者可以轻松获取企业Web应用系统及服务器设备的控制权限,从而进行网页篡改、数据窃取等破坏活动,严重损害企业的业务发展。
保障Web应用安全已经成为行业普遍认知。但研究人员发现,目前很多企业对Web应用安全防护还存在许多认知误区,这随时可能引发严重的安全问题和事故。
我们只是普通的企业组织,我们的Web应用系统不会被攻击。
真相:大多数网络攻击是自动化的、没有特定目标的,因此每个企业都可能成为攻击者的目标。
不管是大型企业,还是中小企业用户,普遍都认为坏事只会发生在其他机构。许多组织抱着侥幸心理,以为自己不会受到网络攻击,因此无需操心Web应用程序安全。但事实是,现在的网络攻击大都是由有组织的犯罪团伙发起,它们每天都在全球网络上进行自动攻击嗅探,一旦机器人程序发现了可被利用的安全漏洞(比如Log4Shell),其所在的企业就在劫难逃。每个企业都应该为防范Web应用攻击做好充分的准备和预案。
部署WAF就可以阻止针对Web应用系统的攻击。
真相:WAF并不能成为Web应用系统防御的唯一防线,攻击者会专门针对WAF寻找相应的绕过策略。
部署Web应用防火墙(WAF)就能够保证Web应用安全是目前最常见的认知误区之一。WAF可以被看成是Web版的网络防火墙,它可以过滤HTTP流量以检测并阻止可能存在的攻击企图。WAF还常常用作负载均衡系统,提供额外的应用安全能力,对于临时阻止突然爆发的零日漏洞很有价值。然而,它们却很难检测出所有可能的攻击,只要系统中存在未被发现的安全漏洞,攻击者就有可能会找到绕过WAF 规则的方法。
企业网站已经使用了HTTPS协议,因此Web应用系统是安全的。
真相:HTTPS只保护用户数据免受窃取和篡改,却无法防范恶意流量等威胁。
应用HTTPS表示所有Web应用流量都经过加密,这是防止中间人攻击的关键最佳实践,但却无法防范攻击者已经建立有效连接的应用程序级攻击。比如说,如果攻击者可以在易受攻击的纯HTTPS应用程序中访问或创建有效的用户账户,他们就可以随意尝试SQL注入、权限提升及其他攻击,而这一切都是在安全加密的连接中进行。
如果Web应用系统仅在企业内部网络上运行就是安全的。
真相:网络攻击者可以通过受攻击的Web服务器系统间接攻击Web应用程序,即使在内部网络中也是如此。
很多人会错误认为,没有连接互联网的内网Web应用系统就是安全的,不会受到基于Web的网络攻击。实际上,攻击者可以利用服务器端请求伪造(SSRF)之类的漏洞,以某一台被攻陷的服务器为跳板,攻击企业内网上的应用系统。特别是在云优先环境下,许多组织不再拥有完全物理隔离的内部网络,只有私有云部署的应用方式,这是另一种Web应用的安全隐患。
只允许通过VPN访问的Web应用系统是安全的。
真相:VPN是保护互联网隐私的强大工具,但不是保护Web应用安全的完整解决方案。
远程工作模式大行其道,虚拟专用网(VPN)已变成企业普遍使用的远程访问工具。尽管VPN确实提供了额外的隔离和访问控制,就像内部网络一样,但不应该将VPN视为Web应用系统的安全凭证。如果攻击者设法访问了 VPN(比如使用被盗的凭据、泄露的员工账户或某种社会工程伎俩),任何Web应用程序都可能很容易受到攻击。
浏览器内置的攻击防护机制可以保障应用安全。
真相:浏览器安全机制是应用程序安全防护的补充,但却无法取而代之。
大概十年前,因为跨站脚本漏洞的盛行,浏览器服务商尝试将XSS过滤器直接嵌入到浏览器中,这误导了一大批企业用户:新一代浏览器可以对Web应用程序进行安全防护。但实践表明,这种保护措施的效果非常有限,并且已从很多高版本浏览器中删除。实际上,浏览器安全是网络安全领域一个完全独立又至关重要的方面,永远不应依赖浏览器作为应用程序的额外防线。相反,Web开发者应竭力遵循公认的行业标准和规范,让浏览器能够正确地处理和呈现应用程序。
Web应用系统有备份,即使发生安全事件也可以快速恢复。
真相:备份对于数据存储和保持业务连续性很重要,但却无法减轻数据泄密造成的间接破坏和损失。
备份一直是企业整体安全策略的关键组成部分,拥有良好的备份和可靠的恢复方案是无可替代的。但是备份只能防止数据丢失和损坏,却无法帮助企业避免网络攻击产生的其他灾难性后果(系统停运、商业秘密泄露和品牌商誉损失等)。因此,备份是Web应用安全防护计划中不可或缺的部分,但企业在确保应用系统安全性方面的要求与随时准备数据恢复一样重要。
Web应用的开发框架是安全可靠的,因此应用系统也是安全的。
真相:高质量的开发框架可以防止许多安全漏洞,但仅靠框架还远远不够。
Web应用框架和模块库已彻底改变了Web应用系统的开发方式,提供了构建生产级站点和应用程序的基础,会大大节约应用开发的时间和资源。选择一种安全可靠的框架固然是重要的,因为它可以帮助企业避免很多类型的技术漏洞,特别是跨站脚本(XSS)类型的漏洞。但即使开发人员严格按照规范,Web开发框架不能识别所有应用场景下的漏洞,因此,使用可靠的Web开发框架只是安全编程的基础。
应用发布前已经在集成开发环境(IDE)中进行了安全检查,所以是安全的。
真相:静态代码安全检查只是确保整体应用程序安全性的手段之一。
新一代Web开发工具通常会集成代码安全检查工具,有时甚至作为免费插件。应用这种工具的好处是,可以提升开发人员的安全意识,减少人为错误导致的安全隐患。但这些工具也有其应用局限性,只能识别有限的问题,并且容易出现误报,将真正的警报淹没。虽然为IDE增添面向安全的检查工具有利于规避Web应用的安全问题,但需要认识到,它只是确保应用程序安全的众多手段之一,通过全部静态安全检查并不能保证应用程序的绝对安全,还有很多地方可能出岔子。
Web应用安全防护不是开发团队的工作。
真相:保障应用程序安全是现代Web应用开发的重要组成部分,特别是应用开发安全运营(DevSecOps)模式后更是如此。
由于应用需求的提升,导致Web应用系统变得更加复杂,保护Web的应用安全与每个人息息相关,并从开发阶段就启动安全策略。有效地发现安全漏洞并及时处理修复请求,对于避免发生严重的安全事件和节省安全防护资源至关重要。
来源: 安全牛
随着网络的普及,黑客进行网络攻击的手段越来也多,越来越复杂。前端的HTML、JavaScript、CSS、Flash等技术变成了前端攻击者和开发者的战场,网站安全问题也开始向前端倾斜。
AJAX请求真的不安全么?AJAX请求哪里不安全?怎么样让AJAX请求更安全?本文包含的内容较多,包括AJAX,CORS,XSS,CSRF等内容,要完整的看完并理解需要付出一定的时间。
第三方内容在其沙箱区域内具有强大的能力。如果你担心恶意用户诱使你的网站加载第三方资源,可以通过 CSP 用作防护手段,其可以限制加载图片,脚本和样式的来源。
检查页面隐藏或丢失的内容:检查webserver元数据文件,如:robots.txt, sitemap.xml,.DS_Store, .htaccess,检查搜索功能可能的注入或攻击方式,检查不同agent代理访问网站显示内容的是否一致
要做到无iFrame,我将使用一种类似于之前我讨论过的方法:我将创建一个弹窗,然后在设置计时器后更改弹出窗口的位置。使用这种方法,我仍然可以加载受害者的CSS,但我不再依赖于受害者是否允许iFrame。
我当前的 chrome 版本是 v68,如果是 v66 或更低版本可能提示的警告信息略有不同。印象中只对 CORS 比较熟悉,CORB 是个什么鬼?好奇心迫使我想要了解一下它到底是什么,于是暂时把手头工作放下查了一些资料并花时间汇总了一下,就有了这篇文章
大家都喜欢target=_blank, 因为新页面打开不影响原来的页面。但是这个存在安全问题, 由target=_blank打开的页面, 可以通过window.opener访问原来的窗口。遍可以简单的将网页导航到其他网站, 这就存在很多的安全隐患了, 比如钓鱼,这种问题解决起来也很简单, 在链接中加入rel=noreferrer noopener属性就可以了
Web安全测试检查单。上传功能:绕过文件上传检查功能,上传文件大小和次数限制。注册功能:注册请求是否安全传输,注册时密码复杂度是否后台检验,激活链接测试
HTTP Strict-Transport-Security,简称为HSTS。X-Frame-Options:是否允许一个页面可在<frame>、<iframe>、<object>中展现的标记。X-XSS-Protection作用:防范XSS攻击。
第三方内容在其沙箱中具有很高的影响力。 虽然图像或沙盒iframe有着非常小的沙箱,但脚本和样式的作用范围却影响你的整个页面,甚至是整个站点。如果你担心用户会欺骗你的网站去加载第三方资源,可以使用CSP(内容安全策略)保证安全
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!