常见(XSS|CSRF)六大Web安全攻防解析

时间 2019-11-30

标签常见 xss csrf 六大 web 安全攻防解析栏目 JavaScript 繁體版

原文原文链接

前言

在互联网时代，数据安全与我的隐私受到了史无前例的挑战，各类新奇的攻击技术层出不穷。如何才能更好地保护咱们的数据？本文主要侧重于分析几种常见的攻击的类型以及防护的方法。php

1、XSS
html

XSS (Cross-Site Scripting)，跨站脚本攻击，由于缩写和 CSS重叠，因此只能叫 XSS。跨站脚本攻击是指经过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。前端

跨站脚本攻击有可能形成如下影响:mysql

利用虚假输入表单骗取用户我的信息。git
利用脚本窃取用户的Cookie值，被害者在不知情的状况下，帮助攻击者发送恶意请求。github
显示伪造的文章或图片。web

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

XSS 的攻击方式变幻无穷，但仍是能够大体细分为几种类型。正则表达式

1.非持久型 XSS（反射型 XSS ）

非持久型 XSS 漏洞，通常是经过给别人发送带有恶意脚本代码参数的 URL，当 URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。sql

举一个例子，好比页面中包含有如下代码：

攻击者可直接经过URL (相似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) 注入可执行的脚本代码。不过一些浏览器如Chrome其内置了一些XSS过滤器，能够防止大部分反射型XSS攻击。

非持久型 XSS 漏洞攻击有如下几点特征：

即时性，不通过服务器存储，直接经过 HTTP 的 GET 和 POST 请求就能完成一次攻击，拿到用户隐私数据。
攻击者须要诱骗点击,必需要经过用户点击连接才能发起
反馈率低，因此较难发现和响应修复
盗取用户敏感保密信息

为了防止出现非持久型 XSS 漏洞，须要确保这么几件事情：

Web 页面渲染的全部内容或者渲染的数据都必须来自于服务端。
尽可能不要从 URL，document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染。
尽可能不要使用eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可执行字符串的方法。
若是作不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数作 escape 转义。
前端渲染的时候对任何的字段都须要作 escape 转义编码。

2.持久型 XSS（存储型 XSS）

持久型 XSS 漏洞，通常存在于 Form 表单提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面得到后端从数据库中读出的注入代码时，刚好将其渲染执行。

举个例子，对于评论功能来讲，就得防范持久型 XSS 攻击，由于我能够在评论中输入如下内容

主要注入页面方式和非持久型 XSS 漏洞相似，只不过持久型的不是来源于 URL，referer，forms 等，而是来源于后端从数据库中读出来的数据 。持久型 XSS 攻击不须要诱骗点击，黑客只须要在提交表单的地方完成注入便可，可是这种 XSS 攻击的成本相对仍是很高。

攻击成功须要同时知足如下几个条件：

POST 请求提交表单后端没作转义直接入库。
后端从数据库中取出数据没作转义直接输出给前端。
前端拿到后端数据没作转义直接渲染成 DOM。

持久型 XSS 有如下几个特色：

持久性，植入在数据库中
盗取用户敏感私密信息
危害面广

3.如何防护

对于 XSS 攻击来讲，一般有两种方式能够用来防护。

1) CSP

CSP 本质上就是创建白名单，开发者明确告诉浏览器哪些外部资源能够加载和执行。咱们只须要配置规则，如何拦截是由浏览器本身实现的。咱们能够经过这种方式来尽可能减小 XSS 攻击。

一般能够经过两种方式来开启 CSP：

设置 HTTP Header 中的 Content-Security-Policy
设置 meta 标签的方式

这里以设置 HTTP Header 来举例：

只容许加载本站资源

Content-Security-Policy: default-src 'self'复制代码

只容许加载 HTTPS 协议图片

Content-Security-Policy: img-src https://*复制代码

容许加载任何来源框架

Content-Security-Policy: child-src 'none'复制代码

如需了解更多属性，请查看Content-Security-Policy文档

对于这种方式来讲，只要开发者配置了正确的规则，那么即便网站存在漏洞，攻击者也不能执行它的攻击代码，而且 CSP 的兼容性也不错。

2) 转义字符

用户的输入永远不可信任的，最广泛的作法就是转义输入输出的内容，对于引号、尖括号、斜杠进行转义

可是对于显示富文原本说，显然不能经过上面的办法来转义全部字符，由于这样会把须要的格式也过滤掉。对于这种状况，一般采用白名单过滤的办法，固然也能够经过黑名单过滤，可是考虑到须要过滤的标签和标签属性实在太多，更加推荐使用白名单的方式。

以上示例使用了 js-xss 来实现，能够看到在输出中保留了 h1 标签且过滤了 script 标签。

3) HttpOnly Cookie。

这是预防XSS攻击窃取用户cookie最有效的防护手段。Web应用程序在设置cookie时，将其属性设为HttpOnly，就能够避免该网页的cookie被客户端恶意JavaScript窃取，保护用户cookie信息。

2、CSRF

CSRF(Cross Site Request Forgery)，即跨站请求伪造，是一种常见的Web攻击，它利用用户已登陆的身份，在用户绝不知情的状况下，以用户的名义完成非法操做。

1.CSRF攻击的原理

下面先介绍一下CSRF攻击的原理：

完成 CSRF 攻击必需要有三个条件：

用户已经登陆了站点 A，并在本地记录了 cookie
在用户没有登出站点 A 的状况下（也就是 cookie 生效的状况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。
站点 A 没有作任何 CSRF 防护

咱们来看一个例子：当咱们登入转帐页面后，忽然眼前一亮惊现"XXX隐私照片，不看后悔一生"的连接，耐不住心里躁动，立马点击了该危险的网站（页面代码以下图所示），但当这页面一加载，便会执行submitForm这个方法来提交转帐请求，从而将10块转给黑客。

2.如何防护

防范 CSRF 攻击能够遵循如下几种规则：

Get 请求不对数据进行修改
不让第三方网站访问到用户 Cookie
阻止第三方网站请求接口
请求时附带验证信息，好比验证码或者 Token

1) SameSite

能够对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送，能够很大程度减小 CSRF 的攻击，可是该属性目前并非全部浏览器都兼容。

2) Referer Check

HTTP Referer是header的一部分，当浏览器向web服务器发送请求时，通常会带上Referer信息告诉服务器是从哪一个页面连接过来的，服务器籍此能够得到一些信息用于处理。能够经过检查请求的来源来防护CSRF攻击。正常请求的referer具备必定规律，如在提交表单的referer一定是在该页面发起的请求。因此经过检查http包头referer的值是否是这个页面，来判断是否是CSRF攻击。

但在某些状况下如从https跳转到http，浏览器处于安全考虑，不会发送referer，服务器就没法进行check了。若与该网站同域的其余网站有XSS漏洞，那么攻击者能够在其余网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。出于以上缘由，没法彻底依赖Referer Check做为防护CSRF的主要手段。可是能够经过Referer Check来监控CSRF攻击的发生。

3) Anti CSRF Token

目前比较完善的解决方案是加入Anti-CSRF-Token。即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token，并在服务器创建一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会进行校验该请求当中的token和cookie当中的token值是否都存在且相等，才认为这是合法的请求。不然认为此次请求是违法的，拒绝该次服务。

这种方法相比Referer检查要安全不少，token能够在用户登录后产生并放于session或cookie中，而后在每次请求时服务器把token从session或cookie中拿出，与本次请求中的token 进行比对。因为token的存在，攻击者没法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时，当某个页面消耗掉token后，其余页面的表单保存的仍是被消耗掉的那个token，其余页面的表单提交时会出现token错误。

4) 验证码

应用程序和用户进行交互过程当中，特别是帐户交易这种核心步骤，强制用户输入验证码，才能完成最终请求。在一般状况下，验证码够很好地遏制CSRF攻击。但增长验证码下降了用户的体验，网站不能给全部的操做都加上验证码。因此只能将验证码做为一种辅助手段，在关键业务点设置验证码。

3、点击劫持

点击劫持是一种视觉欺骗的攻击手段。攻击者将须要攻击的网站经过 iframe 嵌套的方式嵌入本身的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。

1. 特色

隐蔽性较高，骗取用户操做
"UI-覆盖攻击"
利用iframe或者其它标签的属性

2. 点击劫持的原理

用户在登录 A 网站的系统后，被攻击者诱惑打开第三方网站，而第三方网站经过 iframe 引入了 A 网站的页面内容，用户在第三方网站中点击某个按钮（被装饰的按钮），其实是点击了 A 网站的按钮。
接下来咱们举个例子：我在优酷发布了不少视频，想让更多的人关注它，就能够经过点击劫持来实现

从上图可知，攻击者经过图片做为页面背景，隐藏了用户操做的真实界面，当你按耐不住好奇点击按钮之后，真正的点击的实际上是隐藏的那个页面的订阅按钮，而后就会在你不知情的状况下订阅了。

3. 如何防护

1）X-FRAME-OPTIONS

X-FRAME-OPTIONS是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响应头就是为了防护用 iframe 嵌套的点击劫持攻击。

该响应头有三个值可选，分别是

DENY，表示页面不容许经过 iframe 的方式展现
SAMEORIGIN，表示页面能够在相同域名下经过 iframe 的方式展现
ALLOW-FROM，表示页面能够在指定来源的 iframe 中展现

2）JavaScript 防护

对于某些远古浏览器来讲，并不能支持上面的这种方式，那咱们只有经过 JS 的方式来防护点击劫持了。

以上代码的做用就是当经过 iframe 的方式加载页面时，攻击者的网页直接不显示全部内容了。

4、URL跳转漏洞

定义：借助未验证的URL跳转，将应用程序引导到不安全的第三方区域，从而致使的安全问题。

1.URL跳转漏洞原理

黑客利用URL跳转漏洞来诱导安全意识低的用户点击，致使用户信息泄露或者资金的流失。其原理是黑客构建恶意连接(连接须要进行假装,尽量迷惑),发在QQ群或者是浏览量多的贴吧/论坛中。
安全意识低的用户点击后,通过服务器或者浏览器解析后，跳到恶意的网站中。

恶意连接须要进行假装,常常的作法是熟悉的连接后面加上一个恶意的网址，这样才迷惑用户。

诸如假装成像以下的网址，你是否可以识别出来是恶意网址呢？

2.实现方式：

Header头跳转
Javascript跳转
META标签跳转

这里咱们举个Header头跳转实现方式：

<?php
    $url=$_GET['jumpto'];
    header("Location: $url");
?>
http://www.wooyun.org/login.php?jumpto=http://www.evil.com复制代码

这里用户会认为www.wooyun.org都是可信的，可是点击上述连接将致使用户最终访问www.evil.com这个恶意网址。

3.如何防护

1)referer的限制

若是肯定传递URL参数进入的来源，咱们能够经过该方式实现安全限制，保证该URL的有效性，避免恶意用户本身生成跳转连接

2)加入有效性验证Token

咱们保证全部生成的连接都是来自于咱们可信域的，经过在生成的连接里加入用户不可控的Token对生成的连接进行校验，能够避免用户生成本身的恶意连接从而被利用，可是若是功能自己要求比较开放，可能致使有必定的限制。

5、SQL注入

SQL注入是一种常见的Web安全漏洞，攻击者利用这个漏洞，能够访问或修改数据，或者利用潜在的数据库漏洞进行攻击。

1.SQL注入的原理

咱们先举一个万能钥匙的例子来讲明其原理：

后端的 SQL 语句多是以下这样的：

这是咱们常常见到的登陆页面，但若是有一个恶意攻击者输入的用户名是 admin' --，密码随意输入，就能够直接登入系统了。why! ----这就是SQL注入

咱们以前预想的SQL 语句是:

SELECT * FROM user WHERE username='admin' AND psw='password'复制代码

可是恶意攻击者用奇怪用户名将你的 SQL 语句变成了以下形式：

SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'复制代码

在 SQL 中,' --是闭合和注释的意思，-- 是注释后面的内容的意思，因此查询语句就变成了：

SELECT * FROM user WHERE username='admin'复制代码

所谓的万能密码,本质上就是SQL注入的一种利用方式。

一次SQL注入的过程包括如下几个过程：

获取用户请求参数
拼接到代码当中
SQL语句按照咱们构造参数的语义执行成功

SQL注入的必备条件： 1.能够控制输入的数据 2.服务器要执行的代码拼接了控制的数据。

咱们会发现SQL注入流程中与正常请求服务器相似，只是黑客控制了数据，构造了SQL查询，而正常的请求不会SQL查询这一步，SQL注入的本质:数据和代码未分离，即数据当作了代码来执行。

2.危害

获取数据库信息
管理员后台用户名和密码
获取其余数据库敏感信息：用户名、密码、手机号码、身份证、银行卡信息……
整个数据库：脱裤
获取服务器权限
植入Webshell，获取服务器后门
读取服务器敏感文件

3.如何防护

严格限制Web应用的数据库的操做权限，给此用户提供仅仅可以知足其工做的最低权限，从而最大限度的减小注入攻击对数据库的危害
后端代码检查输入的数据是否符合预期，严格限制变量的类型，例如使用正则表达式进行一些匹配处理。
对进入数据库的特殊字符（'，"，\，<，>，&，*，; 等）进行转义处理，或编码转换。基本上全部的后端语言都有对字符串进行转义处理的方法，好比 lodash 的 lodash._escapehtmlchar 库。
全部的查询语句建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，即不要直接拼接 SQL 语句。例如 Node.js 中的 mysqljs 库的 query 方法中的 ? 占位参数。

6、OS命令注入攻击

OS命令注入和SQL注入差很少，只不过SQL注入是针对数据库的，而OS命令注入是针对操做系统的。OS命令注入攻击指经过Web应用，执行非法的操做系统命令达到攻击的目的。只要在能调用Shell函数的地方就有存在被攻击的风险。假若调用Shell时存在疏漏，就能够执行插入的非法命令。

命令注入攻击能够向Shell发送命令，让Windows或Linux操做系统的命令行启动程序。也就是说，经过命令注入攻击可执行操做系统上安装着的各类程序。

1.原理

黑客构造命令提交给web应用程序，web应用程序提取黑客构造的命令，拼接到被执行的命令中，因黑客注入的命令打破了原有命令结构，致使web应用执行了额外的命令，最后web应用程序将执行的结果输出到响应页面中。

咱们经过一个例子来讲明其原理，假如须要实现一个需求：用户提交一些内容到服务器，而后在服务器执行一些系统命令去返回一个结果给用户

params.repo传入的是 https://github.com/admin/admin.github.io.git 确实能从指定的 git repo 上下载到想要的代码。
可是若是 params.repo 传入的是 https://github.com/xx/xx.git && rm -rf /* && 刚好你的服务是用 root 权限起的就糟糕了。

2.如何防护

后端对前端提交内容进行规则限制（好比正则表达式）。
在调用系统命令前对全部传入参数进行命令行参数转义过滤。
不要直接拼接命令语句，借助一些工具作拼接、转义预处理，例如 Node.js 的 shell-escape npm包

参考资料

常见Web 安全攻防总结
前端面试之道
图解Http
Web安全知多少
web安全之点击劫持(clickjacking)
URL重定向/跳转漏洞
网易web白帽子

ps：转自公众号浪里行舟 IT平头哥联盟