欢迎在下方发表您的优质见解
Activity
Genzhen commentedon Jun 23, 2020
1)XSS:跨站脚本攻击
就是攻击者想尽一切办法将可以执行的代码注入到网页中。
存储型(server端):
反射型(Server端)
与存储型的区别在于,存储型的恶意代码存储在数据库中,反射型的恶意代码在URL上
Dom 型(浏览器端)
DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。
预防方案:(防止攻击者提交恶意代码,防止浏览器执行恶意代码)
Content-Security-Policy: default-src 'self'
-所有内容均来自站点的同一个源(不包括其子域名)Content-Security-Policy: default-src 'self' *.trusted.com
-允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)Content-Security-Policy: default-src https://yideng.com
-该服务器仅允许通过HTTPS方式并仅从yideng.com域名来访问文档2)CSRF:跨站请求伪造
攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的。
攻击流程举例
攻击类型
预防方案:
CSRF通常从第三方网站发起,被攻击的网站无法防止攻击发生,只能通过增强自己网站针对CSRF的防护能力来提升安全性。)
正确
-Cookie中增加了额外的字段。
-如果有其他漏洞(例如XSS),攻击者可以注入Cookie,那么该防御方式失效。
-难以做到子域名的隔离。
-为了确保Cookie传输安全,采用这种防御方式的最好确保用整站HTTPS的方式,如果还没切HTTPS的使用这种方式也会有风险。
3)iframe 安全
说明:
预防方案:
X-Frame-Options: SAMEORIGIN
4)错误的内容推断
说明:
文件上传类型校验失败后,导致恶意的JS文件上传后,浏览器 Content-Type Header 的默认解析为可执行的 JS 文件
预防方案:
设置 X-Content-Type-Options 头
5)第三方依赖包
减少对第三方依赖包的使用,如之前 npm 的包如:event-stream 被爆出恶意攻击数字货币;
6)HTTPS
描述:
黑客可以利用SSL Stripping这种攻击手段,强制让HTTPS降级回HTTP,从而继续进行中间人攻击。
预防方案:
使用HSTS(HTTP Strict Transport Security),它通过下面这个HTTP Header以及一个预加载的清单,来告知浏览器和网站进行通信的时候强制性的使用HTTPS,而不是通过明文的HTTP进行通信。这里的“强制性”表现为浏览器无论在何种情况下都直接向务器端发起HTTPS请求,而不再像以往那样从HTTP跳转到HTTPS。另外,当遇到证书或者链接不安全的时候,则首先警告用户,并且不再
用户选择是否继续进行不安全的通信。
7)本地存储数据
避免重要的用户信息存在浏览器缓存中
8)静态资源完整性校验
描述
使用 内容分发网络 (CDNs) 在多个站点之间共享脚本和样式表等文件可以提高站点性能并节省带宽。然而,使用CDN也存在风险,如果攻击者获得对 CDN 的控制权,则可以将任意恶意内容注入到 CDN 上的文件中 (或完全替换掉文件),因此可能潜在地攻击所有从该 CDN 获取文件的站点。
预防方案
将使用 base64 编码过后的文件哈希值写入你所引用的 <script> 或 标签的 integrity 属性值中即可启用子资源完整性能。
9)网络劫持
描述:
预防方案
全站 HTTPS
10)中间人攻击:
中间人攻击(Man-in-the-middle attack, MITM),指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者窃听、篡改甚至完全控制。没有进行严格的证书校验是中间人攻击着手点。目前大多数加密协议都提供了一些特殊认证方法以阻止中间人攻击。如 SSL (安全套接字层)协议可以验证参与通讯的用户的证书是否有权威、受信任的数字证书认证机构颁发,并且能执行双向身份认证。攻击场景如用户在一个未加密的 WiFi下访问网站。在中间人攻击中,攻击者可以拦截通讯双方的通话并插入新的内容。
场景
过程
使用抓包工具fiddle来进行举例说明
常见攻击方式
保护的HTTP(这对于网站非常致命)
的主机来进行通信,将MAC存入ARP缓存表。
预防方案:
11)sql 注入
描述
就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗数据库服务器执行恶意的SQL命令,从而达到和服务器
进行直接的交互
预防方案:
12)前端数据安全:
描述
反爬虫。如猫眼电影、天眼查等等,以数据内容为核心资产的企业
预防方案:
13)其他建议
Bilibiber commentedon Dec 9, 2020
总结的真好,向大佬学习
Alfred-kai commentedon Mar 4, 2021
好全面,同时还将一些公司贴出来,增强了真实性
rambo-panda commentedon Jun 7, 2022
补充一个吧
压缩导致的安全问题
https压缩 CRIME
新浏览器基本上已经杜绝,nginx也采用升级openSSL 部分解决
http gzip BREACH
数据敏感的api,如果可以不要开启压缩支持
zhangquanming commentedon Jul 12, 2022
补充一个吧
a标签跳转
<a href="xxx.xxx"></a>
攻击方式
比如A页面打开了B页面,然后B页面打开了一个钓鱼网站C页,此时C页用能访问到A页的location,C页[钓鱼网站]修改了A的location.href跳转到一个原始页一样的钓鱼网站,当用户切换回A进行操作时,就很有可能导致隐私数据的泄露。
预防方案
<a href="xxx.xxx" rel="noopener"></a>
<a href="xxx.xxx" rel="noreferrer"></a>
<a href="xxx.xxx" rel="noopener noreferrer"></a>