安全：XSS和CSRF

发表于 | 分类于 | | 阅读数
字数统计: 1,126 字 | 阅读时长 ≈ 4 分钟

XSS攻击（跨站脚本攻击）

原理

恶意攻击者往web页面里插入恶意可执行网页脚本代码，当用户浏览该页面时，嵌入其中web里面的脚本代码会被执行，从而达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。

分类

  • 存储型XSS
    恶意代码存储在数据库中
  • 反射型XSS
    恶意代码存储在url中
  • DOM型XSS
    取出和执行恶意代码都是浏览器端完成

    防御

    开启CSP

    建立白名单，明确告诉浏览器哪些外部资源可以加载和执行。
  • 设置http header中的Content-Security-Policy
  • 设置meta标签
    1
    <meta http-equiv="Content-Security-Policy">

输入输出过滤

前端负责，后端也要做相同的过滤检查，因为攻击者完全可以绕过正常的输入流程，直接利用相关接口向服务器发送设置。

转义字符

转义输入输出的内容，对于引号、尖括号、斜杠进行转义。

web应用程序在设置cookie时，将其属性设为HttpOnly，这样设置的cookie，js就无法进行读写，就可以预防XSS攻击窃取用户cookie，保护用户cookie信息。

CSRF攻击（跨站请求伪造）

原理

攻击者通过一些技术手段欺骗用户的浏览器去訪问一个自己以前认证过的站点并运行一些操作。

利用用户已登录的身份，在用户毫不知情的情况下，以用户的名义完成非法操作。可以这么理解：攻击者盗用了你的身份，以你的名义发送恶意请求。

一般发起攻击的是第三方网站。是利用用户的登录凭证，冒用用户信息，不能获取用户的数据。

CSRF攻击是源于WEB的隐式身份验证机制。WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。

分类

  • get类型
    可以将get请求嵌入img标签，打开页面自动发送请求。
  • post类型
    可以利用自动提交的form表单，访问页面就会自动提交。
  • 链接型
    需要用户点击链接才会触发。

    防御

    post

    尽量使用post请求，避免get请求。

对cookie设置SameSite属性。该属性表示cookie不随跨域请求发送，可以很大程度减少csrf攻击。

token

  1. 用户访问某个表单页面。
  2. 服务端生成一个Token，放在用户的Session或者浏览器的Cookie中。
  3. 在页面表单附带上Token参数。
  4. 用户发送请求时以参数的形式带上本次页面中生成的token，服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。

    仅仅用来防御csrf攻击，当加上xss攻击时，无用

验证码

xss和csrf

  • 通常来说csrf是由xss引起的
  • xss是代码注入问题，csrf是http问题

同源策略

同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。所以a.com下的js脚本采用ajax读取b.com里面的文件数据是会报错的。

不受同源策略限制的：

  • 页面中的链接，重定向以及表单提交是不会受到同源策略限制的。
  • 跨域资源的引入是可以的。但是js不能读写加载的内容。如嵌入到页面中的script标签的src属性、img标签、link标签、iframe标签等。
  • 通过标签的方式发起的请求不受同源策略的限制。且发送请求时浏览器会携带对应的cookie。

SQL注入

原理

通过传入一些特殊字符，从而达到欺骗服务器执行恶意的SQL命令的目的。

如输入特殊的用户名

1
2
3
4
5
6
//理想中的输入：admin  password
SELECT * FROM user WHERE username='admin' AND psw='password'

//特殊用户名：admin' --
SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'
//在SQL中，--是注释后面的内容的意思

防御

  • 严格限制web应用的数据库的操作权限。
  • 后端代码检查输入的数据是否符合预期。
  • 对特殊字符进行转义处理。
-------------本文结束 感谢您的阅读-------------