前端常见安全漏洞

xss跨站脚本攻击

以"文章发布系统"为例

• input输入框输入字符串后使用v-html渲染成HTML显示在当前页面

• 当input输入script(sc里面的js不会执行)

  <script>alert(document.cookie)</script>
  

• 当input输入img标签的onerror回调(弹出cookie)

  <img src="test" onerror="alert(document.cookie)">
  

• 当文章发布后保存到数据库中,当别人浏览这篇文章的时候,就会弹出自己cookie(里面可能存着用户id)

• 假如是一段恶意的ajax请求,会把用户的信息泄露给第三方网站

• 解决:特殊字符转义(<转移为&lt,>转义为&gt)->xss包->use xss(htmlString)

• 然是xss攻击千变万化，要想彻底的杜绝他们，仅仅依靠编程的hack方法是十分麻烦的。所以，浏览器就提出了一个从根本上解决xss攻击的方法：CSP。

csp的全称是内容安全策略。是Content Security Policy的简称。

csp的策略和上面我们提到的白名单策略比较相似，开发者要明确的告诉客户端哪些脚本可以被执行。它的解析和执行都是由客户端决定的，而开发者所需要做的就是告诉浏览器可执行的脚本规则即可。

csrf->xsrf跨站请求伪造攻击

• img标签的src可以跨域

<img src="https://www.baidu.com/img/PCtm_d9c8750bed0b3c7d089fa7d55720d6cf.png">

此时访问百度的图片,也会请求百度下面的cookie

• CSRF是Cross-site request forgery的首字母拼写，中文一般称为跨站请求伪造，是指利用受害者尚未失效的身份认证信息（cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害者的身份向（身份认证信息所对应的）服务器发送请求，从而完成非法操作（如转账、改密等）。

• CSRF与XSS的区别

  • 很多人会疑惑这跟XSS攻击有什么不同吗？关于这点，我们从攻击方式和应对手段上分别来说说。
  • CSRF 和 XSS 可以理解为两个不同维度上的分类。XSS 是实现 CSRF 的其中一种方式。通常习惯把通过 XSS 来实现的 CSRF 称为 XSRF。

• CSRF 攻击原理举例

  • CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。
  1. 比如说，受害者 张三 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=张三&amount=1000000&for=张三2 可以使 张三 把 1000000 的存款转到 张三2 的账号下。
  2. 通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 张三 是否已经成功登录。
  3. 黑客 李四 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。
  4. 李四 可以自己发送一个请求给银行：http://bank.example/withdraw?account=张三&amount=1000000&for=李四。
  5. 但是这个请求来自 李四 而非 张三，他不能通过安全认证，因此该请求不会起作用。这时，李四 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=张三&amount=1000000&for=李四 ”，并且通过广告等诱使 张三 来访问他的网站。
  6. 当 张三 访问该网站时，上述 url 就会从 张三 的浏览器发向银行，而这个请求会附带 张三 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 张三 的认证信息。但是，如果 张三 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 张三 的认证信息。
  7. 这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 张三 的账号转移到 李四 的账号，而 张三 当时毫不知情。等以后 张三 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 李四 则可以拿到钱后逍遥法外。

• 解决

  1. 加短信验证码之类反复确认
  2. 使用post

SSRF服务端请求构造

外网 通过web服务 转发 某些内网资源

• 请求web服务接口:www.xxx.com/test?url=dict://10.1.10.2

• 后端业务逻辑: return getUrlContent(url)

• web服务和内网都是在一个网络环境的,客户可以通过修改公网web服务参数绕过防火墙访问内网资源

• 一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。

• 利用file协议读取文件

• 利用dict协议查看端口开放

• 常见的过滤

  • 过滤开头不是http://xxx.com的所有链接
  • 过滤格式为ip的链接，比如127.0.0.1
  • 结尾必须是某个后缀

点击劫持

• 点击劫持（ClickJacking）是一种视觉上的欺骗手段。大概有两种方式，

  • 一是攻击者使用一个透明的iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，此时用户将在不知情的情况下点击透明的iframe页面；eg 贴吧欺骗关注
    
  • 二是攻击者使用一张图片覆盖在网页，遮挡网页原有位置的含义；
    • 图片覆盖攻击（Cross Site Image Overlaying），攻击者使用一张或多张图片，利用图片的style或者能够控制的CSS，将图片覆盖在网页上，形成点击劫持。当然图片本身所带的信息可能就带有欺骗的含义，这样不需要用户点击，也能达到欺骗的目的。

    <a href="http://tieba.baidu.com/f?kw=%C3%C0%C5%AE">
        <img src="XXXXXX" style="position:absolute;top:90px;left:320px;" />
    </a>
    

  • 第三方网站都是通过iframe来引用的

• 点击劫持算是一种很多人不大关注的攻击，他需要诱使用户与页面进行交互，实施的攻击成本更高。另外开发者可能会觉得是用户犯蠢，不重视这种攻击方式。

• 我在经常看小说过程中会点击下一章,总会跳到xxx网站

• 解决方案：

  • 修改web服务器配置iframe，添加X-Frame-Options响应头。赋值有如下三种：
  1. DENY：不能被嵌入到任何iframe或者frame中。
  2. SAMEORIGIN：页面只能被本站页面嵌入到iframe或者frame中
  3. ALLOW-FROM uri：只能被嵌入到指定域名的框架中

sql注入

• SQL注入简介
  SQL注入是网站存在最多也是最简单的漏洞，主要原因是程序员在开发用户和数据库交互的系统时没有对用户输入的字符串进行过滤，转义，限制或处理不严谨，导致用户可以通过输入精心构造的字符串去非法获取到数据库中的数据。

• SQL注入原理
  一般用户登录用的SQL语句为：

SELECT * FROM user WHERE username='admin' AND password='passwd'，

此处admin和passwd分别为用户输入的用户名和密码，如果程序员没有对用户输入的用户名和密码做处理，就可以构造万能密码成功绕过登录验证，如用户输入''or 1#,SQL语句将变为：

SELECT * FROM user WHERE username=''or 1#' AND password=''，

‘’or 1为TRUE，#注释掉后面的内容，所以查询语句可以正确执行。

• 解决

1. 检查变量数据类型和格式
2. sql预编译

• mybatis中的#和$的区别：
  1. #将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。
  2. $将传入的数据直接显示生成在sql中。
  3. #方式能够很大程度防止sql注入，$方式无法防止Sql注入。