Skip to content

XSS(Cross Site Scripting)

跨站脚本攻击。 缩写不是CSS,避免与层叠样式表混淆,

攻击手段: 盗用cookie,获取敏感信息。

最常用的,留言板中输入<script>alert1</script>

CSP (Content Security Policy)

CSP的主要目标是减少和报告XSS攻击 可以重新约束内容被下载的域名

X-XSS-Protection

X-XSS-Protection 通过浏览器是开启XSS过滤的,比如地址栏中直接输入<script>alert(1)<script>是无效的 当然PHP中,可以设置header('X-XSS-Protection', 0)关闭保护

例子 <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://ajax.googleapis.com; style-src 'self'; img-src 'self' data:">

指定脚本的,图片和样式的来源

CSRF 或 XSRF (Cross Site Request forgery) 跨站请求伪造

XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。

通常情况下,CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任,在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器,从而在并未授权的情况下执行在权限保护之下的操作。

防御方法

  1. Cookie 的 SameSite 属性用来限制第三方 Cookie, Set-Cookie: CookieName=CookieValue; SameSite=Strict; Strict:这个规则过于严格,可能造成非常不好的用户体验。比如,当前网页有一个 GitHub 链接,用户点击跳转就不会带有 GitHub 的 Cookie,跳转过去总是未登陆状态。 Lax: Lax 规则稍稍放宽,大多数情况也是不发送第三方 Cookie,但是导航到目标网址的 Get 请求除外。

  2. 同源检测 在 HTTP 协议中,每一个异步请求都会携带两个 Header ,用于标记来源域名: Origin Header, Referer Header

这两个 Header 在浏览器发起请求时,大多数情况会自动带上,并且不能由前端自定义内容。 服务器可以通过解析这两个 Header 中的域名,确定请求的来源域。 通过校验请求的该字段,我们能知道请求是否是从本站发出的。 我们可以通过拒绝非本站发出的请求,来避免了 CSRF 攻击。

  1. 验证 Referer 或 Origin 这种方法不是非常可靠,下面两种更常见。

  2. 添加token验证 服务器将 Token 返回到前端,前端可以作为隐藏字段放到表单中,前端发请求时携带这个 Token,服务器验证 Token 是否正确

  3. 验证码

CSRF 攻击往往是在用户不知情的情况下成功伪造请求。而验证码会强制用户必须与应用进行交互,才能完成最终请求,而且因为 CSRF 攻击无法获取到验证码,因此通常情况下,验证码能够很好地遏制 CSRF 攻击。 但验证码并不是万能的,因为出于用户体验考虑,不能给网站所有的操作都加上验证码。 因此,验证码只能作为防御 CSRF 的一种辅助手段,而不能作为最主要的解决方案。

参考