网络安全:XSS、CSRF、点击劫持、HTTPS加密:中间人攻击、泛洪攻击

一、XSS攻击

什么是 XSS 攻击?

XSS 全称是 Cross Site Scripting(即跨站脚本),为了和 CSS 区分,故叫它XSS。XSS 攻击是指浏览器中执行恶意脚本(无论是跨域还是同域),从而拿到用户的网络安全:XSS、CSRF、点击劫持、HTTPS加密:中间人攻击、泛洪攻击
这种情况如果前后端没有做好防御的话,这段评论就会被存储到数据库中,这样每个打开该页面的用户都会被攻击到。

  • 非持久型相比于前者危害就小的多了,一般通过修改 URL 参数的方式加入攻击代码,诱导用户访问链接从而进行攻击。
  • 防范措施

    1、不相信任何用户的输入!无论是在前端和服务端,都要对用户的输入进行转码或者过滤

    2、利用 CSP(Content-Security-Policy)白名单

    CSP,即浏览器中的内容安全策略,它的核心思想就是服务器决定浏览器加载哪些资源,具体来说可以完成以下功能:

    • 限制其他域下的资源加载。
    • 禁止向其它域提交数据。
    • 提供上报机制,能帮助我们及时发现 XSS 攻击。
      CSP实现方式
      • 一种是通过 HTTP 头信息Content-Security-Policy的字段。

    网络安全:XSS、CSRF、点击劫持、HTTPS加密:中间人攻击、泛洪攻击
    另一种是通过网页的标签

    <meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:"> <!--上面代码中,CSP 做了如下配置 	* 脚本:只信任当前域名 	* <object>标签:不信任任何URL,即不加载任何资源 	* 样式表:只信任cdn.example.org和third-party.org 	* 框架(frame):必须使用HTTPS协议加载 	* 其他资源:没有限制 --> 

    4、利用 HttpOnly

    很多 XSS 攻击脚本都是用来窃取Cookie, 而设置 Cookie 的 HttpOnly 属性后,JavaScript 便无法读取 Cookie 的值。这样也能很好的防范 XSS 攻击。

    二、CSRF攻击

    什么是CSRF攻击?

    CSRF(Cross-site request forgery), 即跨站请求伪造,指的是黑客诱导用户点击链接,打开黑客的网站,然后黑客利用用户目前的登录状态发起跨站请求。

    • 举个例子, 你在某个论坛点击了黑客精心挑选的小姐姐图片,你点击后,进入了一个新的页面。
      那么恭喜你,被攻击了:)
      CSRF攻击一般会有三种方式:
      自动 GET 请求
      自动 POST 请求
      诱导点击发送 GET 请求。
    • 和XSS攻击对比,CSRF 攻击并不需要将恶意代码注入用户当前页面的html文档中,而是跳转到新的页面,利用服务器的验证{% csrf_token %}

      这就是CSRF Token的典型应用。那它的原理是怎样的呢?
      首先,浏览器向服务器发送请求时,服务器生成一个字符串,将其植入到返回的页面中。
      然后浏览器如果要发送请求,就必须带上这个字符串,然后服务器来验证是否合法,如果不合法则不予响应。这个字符串也就是CSRF Token,通常第三方站点无法拿到这个 token, 因此也就是被服务器给拒绝。

      三、点击劫持

      什么是点击劫持

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

      防御措施

      1、X-FRAME-OPTIONS

      X-FRAME-OPTIONS 是一个 HTTP 响应头,在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用iframe 嵌套的点击劫持攻击。
      该响应头有三个值可选,分别是

      • DENY,表示页面不允许通过 iframe 的方式展示
      • SAMEORIGIN,表示页面可以在相同域名下通过 iframe 的方式展示
      • ALLOW-FROM,表示页面可以在指定来源的 iframe 中展示

      2、JS 防御

      对于某些远古浏览器来说,并不能支持上面的这种方式,那我们只有通过 JS 的方式来防御点击劫持了。 通过判断顶层窗口的方式来进行防御

       <head>   <style id="click-jack">     html {       display: none !important;     }   </style> </head> <body>   <script>   	//当通过 iframe 的方式加载页面时,攻击者的网页直接不显示所有内容了     if (self == top) {       var style = document.getElementById('click-jack')       document.body.removeChild(style)     } else {       top.location = self.location     }   </script> </body> 

      四、HTTPS加密:中间人攻击

      HTTPS为什么让数据传输更安全?

      谈到HTTPS, 就不得不谈到与之相对的HTTP。HTTP的特性是明文传输,因此在传输的每一个环节,数据都有可能被第三方窃取或者篡改,具体来说,HTTP 数据经过 TCP之间建立了一个中间层,当HTTP和TCP通信时并不是像以前那样直接通信,直接经过了一个中间层进行加密,将加密后的数据包传给TCP, 响应的,TCP必须将数据包解密,才能传给上面的HTTP。这个中间层也叫安全层。安全层的核心就是对数据加解密。

      加密算法

      HTTPS 解决数据传输安全问题的方案就是使用加密算法,具体来说是混合加密算法,也就是对称加密和非对称加密的混合使用,这里有必要先了解一下这两种加密算法的区别和优缺点。

      1、对称加密

      加密和解密都是使用同一个密钥,常见的对称加密算法有 DES、3DES 和 AES 等,其优缺点如下:

      优点:算法公开、计算量小、加密速度快、加密效率高,适合加密比较大的数据。
      缺点:交易双方需要使用相同的密钥,也就无法避免密钥的传输,而密钥在传输过程中无法保证不被截获,因此对称加密的安全性得不到保证。
      每对用户每次使用对称加密算法时,都需要使用其他人不知道的惟一密钥,这会使得发收信双方所拥有的钥匙数量急剧增长,密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难,主要是因为密钥管理困难,使用成本较高。

      网络安全:XSS、CSRF、点击劫持、HTTPS加密:中间人攻击、泛洪攻击

      从图中可以看出,被加密的数据在传输过程中是无规则的乱码,即便被第三方截获,在没有密钥的情况下也无法解密数据,也就保证了数据的安全。但是有一个致命的问题,那就是既然双方要使用相同的密钥,那就必然要在传输数据之前先由一方把密钥传给另一方,那么在此过程中密钥就很有可能被截获,这样一来加密的数据也会被轻松解密。那如何确保密钥在传输过程中的安全呢?这就要用到非对称加密了。

      2、非对称加密

      加密和解密需要使用两个不同的密钥:公钥(public key)和私钥(private key)。公钥与私钥是一对,如果用公钥对数据进行加密,只有用对应的私钥才能解密;如果用私钥对数据进行加密,那么只有用对应的公钥才能解密。

      优点:算法公开,加密和解密使用不同的钥匙,私钥不需要通过网络进行传输,安全性很高。
      缺点:计算量比较大,加密和解密速度相比对称加密慢很多。

      由于非对称加密的强安全性,可以用它完美解决对称加密的密钥泄露问题,效果图如下:

      网络安全:XSS、CSRF、点击劫持、HTTPS加密:中间人攻击、泛洪攻击

      在上述过程中,客户端在拿到服务器的公钥后,会生成一个随机码 (用 KEY 表示,这个 KEY 就是后续双方用于对称加密的密钥),然后客户端使用公钥把 KEY 加密后再发送给服务器,服务器使用私钥将其解密,这样双方就有了同一个密钥 KEY,然后双方再使用 KEY 进行对称加密交互数据。

      在非对称加密传输 KEY 的过程中,即便第三方获取了公钥和加密后的 KEY,在没有私钥的情况下也无法破解 KEY (私钥存在服务器,泄露风险极小),也就保证了接下来对称加密的数据安全。而上面这个流程图正是 HTTPS 的雏形,HTTPS 正好综合了这两种加密算法的优点,不仅保证了通信安全,还保证了数据传输效率。

      非对称加密,公钥加密过的数据只能用私钥解密,因此中间人就算拿到浏览器传来的数据,由于他没有私钥,照样无法解密,保证了数据的安全性。

      但仅使用非对称加密不能完全保证数据安全,公钥加密的数据可以用私钥解密,那私钥加密的数据也可以用公钥解密呀!

      服务器的数据只能用私钥进行加密(因为如果它用公钥那么浏览器也没法解密啦),中间人一旦拿到公钥,那么就可以对服务端传来的数据进行解密了,就这样又被破解了。而且,只是采用非对称加密,对于服务器性能的消耗也是相当巨大的,因此我们暂且不采用这种方案。

      HTTPS保证数据安全的措施

      使用对称加密和非对称加密的结合 + 利用CA数字证书

      可以发现,对称加密和非对称加密,单独应用任何一个,都会存在安全隐患。那我们能不能把两者结合,进一步保证安全呢?

      对称加密和非对称加密的结合的整个流程:

      1. 浏览器向服务器发送client_random和加密方法列表。
      2. 服务器接收到,返回server_random、加密方法以及公钥。
      3. 浏览器接收,接着生成另一个随机数pre_random, 并且用公钥加密,传给服务器。(敲黑板!重点操作!)
      4. 服务器用私钥解密这个被加密后的pre_random。

      现在浏览器和服务器有三样相同的凭证:client_random、server_random和pre_random。然后两者用相同的加密方法混合这三个随机数,生成最终的密钥。

      然后浏览器和服务器尽管用一样的密钥进行通信,即使用对称加密。

      这个最终的密钥是很难被中间人拿到的,为什么呢? 因为中间人没有私钥,从而拿不到pre_random,也就无法生成最终的密钥了。

      回头比较一下和单纯的使用非对称加密, 这种方式做了什么改进呢?本质上是防止了私钥加密的数据外传。单独使用非对称加密,最大的漏洞在于服务器传数据给浏览器只能用私钥加密,这是危险产生的根源。利用对称和非对称加密结合的方式,就防止了这一点,从而保证了安全。

      添加数字证书

      尽管通过两者加密方式的结合,能够很好地实现加密传输,但实际上还是存在一些问题。黑客如果采用 DNS 劫持,将目标地址替换成黑客服务器的地址,然后黑客自己造一份公钥和私钥,照样能进行数据传输。而对于浏览器用户而言,他是不知道自己正在访问一个危险的服务器的。

      事实上HTTPS在上述结合对称和非对称加密的基础上,又添加了数字证书认证的步骤。其目的就是让服务器证明自己的身份。

      传输过程

      为了获取这个证书,服务器运营者需要向第三方认证机构获取授权,这个第三方机构也叫CA(Certificate Authority), 认证通过后 CA 会给服务器颁发数字证书。

      这个数字证书有两个作用:

      1. 服务器向浏览器证明自己的身份。
      2. 把公钥传给浏览器。

      这个验证的过程发生在什么时候呢?

      当服务器传送server_random、加密方法的时候,顺便会带上数字证书(包含了公钥), 接着浏览器接收之后就会开始验证数字证书。如果验证通过,那么后面的过程照常进行,否则拒绝执行。

      HTTPS最终的加解密过程:

      网络安全:XSS、CSRF、点击劫持、HTTPS加密:中间人攻击、泛洪攻击
      认证过程

      浏览器拿到数字证书后,如何来对证书进行认证呢?

      首先,会读取证书中的明文内容。CA 进行数字证书的签名时会保存一个 Hash 函数,来这个函数来计算明文内容得到信息A,然后用公钥解密明文内容得到信息B,两份信息做比对,一致则表示认证合法。

      当然有时候对于浏览器而言,它不知道哪些 CA 是值得信任的,因此会继续查找 CA 的上级 CA,以同样的信息比对方式验证上级 CA 的合法性。一般根级的 CA 会内置在操作系统当中,当然如果向上找没有找到根级的 CA,那么将被视为不合法。

      总结

      HTTPS并不是一个新的协议, 它在HTTPTCP的传输中建立了一个安全层,利用对称加密和非对称加密结合数字证书认证的方式,让传输过程的安全性大大提高。

      五、SYN)数据包,攻击者可以淹没目标服务器计算机上的所有可用端口,从而导致目标设备缓慢响应合法流量或根本不响应。

    DOS攻击现在基本没啥作用了,因为服务器的性能都很好,而且是多台服务器共同作用,1V1的模式黑客无法占上风。

    防范措施

    1、减少SYN timeout时间

    在握手的第三步,服务器会等待30秒-120秒的时间,减少这个等待时间就能释放更多的资源。

    2、限制同时打开的SYN半连接数目

    参考文章

    浏览器灵魂之问,请问你能接得住几个?
    Content Security Policy 入门教程
    HTTPS 详解一:附带最精美详尽的 HTTPS 原理图