Rni-L Blog

Appearance

以下内容只供自身使用，大部分内容取自网上其他的文章

前端 ​

xss ​

跨站脚本攻击 - xss (cross site script)。通过注入脚本，对网站进行攻击。

xss 的本质是一种 “代码注入”，被注入的代码，在网站里执行

美团 xss讲解

反射型 xss ​

将用户输入的数据反射给浏览器，从而造成攻击

存储型 xss ​

通过将“攻击代码的数据”存入到服务器端中，然后在某页面，将该“攻击代码”展现后，浏览用户就会受到攻击

反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里

DOM Based xss ​

通过修改页面的 dom 节点，从而形成 xss

dom 的属性、内容都可以是攻击的对象

html
<div style="background: url(' javascript:eval(document.all.mycode.expr) ')"
     expr='var b = xxxxx'
/>

通过 xss 攻击，可以劫持用户的 cookie，再发送到攻击者的服务器中。

比如在某个页面，加载了一段攻击的脚本，这段脚本将当前页面的 cookie 通过 img 标签的 src ，发送到目标服务器中。

上面这个举例，只是一个简单的例子，通过设置 cookie 的 httpOnly，可以禁止客户端获取 cookie

模拟 get 和 post 请求 ​

get 请求比较简单

<img src='${url}' />

这样就会发送一个 get 请求，服务器也会有一条日志出现

post 请求，用 js 创造相应的表单，最后通过 form.submit() 提交表单，从而发送一个 post 请求

攻击者可以模拟 get、post 请求，用户使用的网页，插入了攻击的脚本后，用户某个点击，就可能造成“反射型 xss" 攻击，创建了一个请求的操作，该操作可能是删除你在该网站的某些内容等，可攻击的范围很多。

xss 防御 ​

  1. cookie 的 httpOnly，禁止客户端获取 cookie
  2. 重要的交互操作，添加验证码校验
  3. 输入检查，对关键字进行判断，输入检查的方式称为“xss filter”
  4. 限制输入内容的长度
  5. 输出检查，当变量输出到 html 的时候，使用编码或转义防御 xss 攻击
  6. 使用纯前端渲染。在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了
  7. 前端要小心使用 innerHTML、document.write 这些方法，渲染 HTML
  8. 小心 href 中的 javascript:，eval 方法
  9. 使用 csp(Content Secrity Policy)
    1. 禁止加载外域代码
    2. 禁止外域提交
    3. 禁止内联脚本执行

csrf ​

跨站请求伪造 - CSRF(Cross-site request forgery)，诱导用户进入第三方网站，向被攻击网站发送请求。利用用户的登录凭证，进行有效的请求，从而进行攻击。

GET、POST 请求的 CSRF 和伪造 url，当用户点击跳转到指定的网址，从而发起请求攻击

美团 csrf 讲解

CSRF的特点 ​

  • 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
  • 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
  • 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
  • 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。

防护策略 ​

对请求进行同源检查，添加 token 校验

  1. 添加验证码校验
  2. 检验请求头的 Origin Header 和 Referer Header
    1. Referer 可以不携带的，这两个头部检验，只是增加安全性
  3. csrf token 检验，每次请求携带相应的 token，后端检查 token 是否安全
  4. 双重 cookie 验证，利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值
    1. 这个也有局限性，由于任何跨域都会导致前端无法获取Cookie中的字段
    2. 某个子域名存在漏洞被XSS攻击（例如upload.a.com）。虽然这个子域下并没有什么值得窃取的信息。但攻击者修改了a.com下的Cookie。
    3. 攻击者可以直接使用自己配置的Cookie，对XSS中招的用户再向www.a.com下，发起CSRF攻击
  5. 严格管理所有的上传接口，防止任何预期之外的上传内容（例如HTML）。
  6. 添加Header X-Content-Type-Options: nosniff 防止黑客上传HTML内容的资源（例如图片）被解析为网页。
  7. 对于用户上传的图片，进行转存或者校验。不要直接使用用户填写的图片链接。
  8. 当前用户打开其他用户填写的链接时，需告知风险（这也是很多论坛不允许直接在内容中发布外域链接的原因之一，不仅仅是为了用户留存，也有安全考虑）

后端 ​

常见注意问题 ​

  1. 不应该将数据库的错误信息，全部返回给前端，不然攻击者可以根据错误信息去，判断你使用了什么数据库、什么框架、写了什么 sql 执行代码等。这些“错误回显”应该关闭