前端技术演进（三）：前端安全

时间  2019-12-08
标签 前端 技术 演进 安全 栏目 系统安全 繁體版
原文   原文链接
这个来自以前作的培训，删减了一些业务相关的，参考了不少资料（ 参考资料列表），谢谢前辈们，么么哒 😘

Web前端安全方面涵盖的内容较多，也是前端项目开发中必需要关注的一个重要部分。在Web站点开发中，若是没有很好的安全防御措施，不只可能由于攻击者的恶意行为影响站点页面功能、泄露用户投权隐私，甚至还可能会直接带来用户经济上的损失。javascript

安全固然不仅是前端的事情，这里主要介绍和前端相关的一些安全知识。php

XSS

跨站脚本攻击（Cross Site Script，XSS攻击），一般指黑客经过“HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。html

XSS的本质是一种“HTML注入”，用户的数据被当成了HTML代码一部分来执行，从而产生了新的语义。前端

根据攻击脚本引入的位置，XSS能够分为三类：java

反射型XSS

非持久化，将用户输入的数据反射给浏览器，通过后端，不通过数据库。黑客须要诱使用户“点击”一个恶意连接，才能攻击成功。python

image.png | center | 734x479

存储型XSS

持久化，代码储存在数据库中，通过后端，通过数据库。如在我的信息或发表文章等地方，假如代码，若是没有过滤或过滤不严，那么这些代码将储存到数据库中，用户访问该页面的时候触发代码执行。jquery

好比一个表单，输入用户签名，前端直接把签名内容展现在页面上，若是没有进行XSS处理，假设输入：git

<script>alert(1)</script>

浏览器显示用户签名的时候，可能就会触发弹框。注意这里的脚本只是演示，在攻击时，脚本可能会执行各类动做，好比获取Cookie或全部本地存储并发送到某处，打开一个非法网址等等。github

DOM Based XSS

经过修改页面的DOM节点造成的XSS，不通过后端。web

好比前端直接经过获取URL参数渲染页面DOM：

http://localhost:8080/dvwa/vulnerabilities/xss_d/?default=English<script>alert(1)</script>

页面弹窗：

image.png | center | 827x500

XSS攻击挑战：https://xss-game.appspot.com

解法：https://gist.github.com/pbssubhash/2f99644a4f24e8fe6b3e

防护方式

通常使用对HTML字符编码转义来防范XSS，好比：

function HTMLEncode(str) {
    let s;
    if (str.length === 0) return "";
    s = str.replace(/&/g, "&gt;");
    s = s.replace(/</g, "&lt;");
    s = s.replace(/>/g, "&gt;");
    s = s.replace(/ /g, "&nbsp;");
    s = s.replace(/'/g, "'");
    s = s.replace(/"/g, "&quot;");
    s = s.replace(/\n/g, "<br>");
    return s;
}

function HTMLDecode(str) {
    let s;
    if (str.length === 0) return "";
    s = str.replace(/&gt;/g, "&");
    s = s.replace(/&lt;/g, "<");
    s = s.replace(/&gt;/g, ">");
    s = s.replace(/&nbsp;/g, " ");
    s = s.replace(/'/g, "'");
    s = s.replace(/&quot;/g, "\"");
    s = s.replace(/<br>/g, "\n");
    return s;
}

可是绕过过滤的方式有不少，好比：

data协议执行javascript：

<a href=data:text/html;base64,PHNjcmlwdD5hbGVydCgzKTwvc2NyaXB0Pg==>

Jsfuck：

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

深刻游戏：http://prompt.ml/

建议使用成熟的库来防范，好比：https://github.com/leizongmin/js-xss

保护好用户的Cookie，加上HttpOnly属性，加上了这个属性的Cookie字段，js是没法进行读写的。

先后端必定都要过滤，在界面显示用户输入的内容时要谨慎。

SQL注入

SQL 注入就是指在输入的字符串中注入 SQL 语句，若是应用相信用户的输入而对输入的字符串没进行任何的过滤处理，那么这些注入进去的 SQL 语句就会被数据库误认为是正常的 SQL 语句而被执行。

好比后端代码：

$un = @$_POST['un'];
$pw = @$_POST['pw'];

// ...

$sql = "select * from user where un='$un' and pw='$pw'";

前端输入时，咱们将un赋为admin，pw赋为' or '1'='1。则整个 SQL 语句会变为：

select * from user where un='admin' and pw='' or '1'='1'

就成功绕过了身份验证。

SQL注入太知名，你们比较熟悉，这里不作过多介绍。

CSRF

CSRF（Cross-site request forgery跨站请求伪造，也被称为“One Click Attack”或者Session Riding，一般缩写为CSRF或者XSRF，是一种对网站的恶意利用。XSS利用站点内的信任用户，而CSRF则经过假装来自受信任用户的请求来利用受信任的网站。

image.png | center | 827x511

例如：
一个银行站点存在一个CSRF漏洞，用户A转帐给B用户2000元，执行转帐操做后会对银行发送一次请求：http://www.bank.com/money?use...，而后A用户就会把本身的2000元转到B的帐户下。在发送这个请求给银行服务器时，服务器首先会验证这个请求是否为一个合法的session，而且用户A确认登录才能够验证经过。

若是此时有一个恶意用户C想把A用户的钱转到本身的帐户下，那么他能够构造 http://www.bank.com/money?use... 这个请求，可是这个请求必须有A用户发出才能够生效，此时恶意用户C能够搭建一个本身的网站，在网站中写入以下代码：<img src="http://www.bank.com/money?user=A&num=2000&transfer=C">
以后诱导A用户访问本身的网站，当A访问这个网站时，这个网站就会把img标签里的URL发给银行服务器，而此时除了这个请求之外，还会把A用户的cookie一块儿发到服务器，若是此时A用户的浏览器与银行的session没有过时，那么就会在A用户绝不知情的状况下执行转帐给C的操做。

CSRF​通常会用于如下场景：

一、对网站管理员进行攻击：诱骗管理员点击存在漏洞的连接，执行增长删除网站管理帐户的操做，从而进行下一步渗透获得网站shell权限。

Discuz! X2.5 / X3 / X3.1 可CSRF删管理员帐号

发帖插入 Discuz! 代码，其中修改uidarray能够删除多个指定用户：

[img]admin.php?frame=no&action=members&operation=clean&submit=1&uidarray=1&confirmed=yes[/img]

二、修改受害网站上的用户帐户和数据：对帐户密码进行重置，改邮箱绑定，修改我的资料、我的设置，删除用户发布的文章帖子等。

美丽说网CSRF重置任意用户账号密码(已经拿到商家账号证实)

三、帐户劫持：修改密码处没有验证原有密码，无token验证，发送一个修改密码的连接便可。或者发送一个修改绑定邮箱的连接，再进行密码重置。

微信公众平台CSRF可致使公众帐号被劫持

四、传播CSRF蠕虫进行大规模攻击：此类攻击发生的场景通常在SNS站点，批量关注、发微博、改我的资料处。

新浪微博CSRF之点我连接发微博（可蠕虫）

五、利用csrf进行拖库。

Discuz可CSRF脱裤

六、利用其余漏洞进行组合拳攻击。

防护方式

一、使用验证码：

CSRF攻击通常都是在受害者不知情的状况下进行发起的，使用验证码能够有效的防止攻击，可是每次请求都要输入验证码会影响用户体验，因此一般只在用户登陆注册，还有一些特定业务场景下使用，好比银行转帐。如何使用验证码要根据业务和场景来决定。

二、验证http Referer：

http头中的referer字段记录了请求来源地址，好比从 http://www.test.com 点击连接到 http://m.test.com 以后，那么referer就是 http://www.test.com 这个地址。攻击者在对受害者进行攻击的时候，是在攻击者本身的服务器上构建本身的恶意脚本，诱骗受害者点击，因此此时的referer值就是攻击者本身的URL地址。经过以上可知，CSRF攻击都是跨域发起的，因此在服务端针对referer字段验证是否属于安全可靠的域名，可在必定程度上有效防护此类攻击。

可是此类方法并不是万无一失，在低版本存在漏洞的浏览器中，黑客能够篡改referer值。另外一种状况是CSRF结合XSS进行攻击，此时就不须要跨域发起，也能够绕过referer验证。

三、使用token

当用户第一次进行登陆的时候，客户端会经过用户名和密码去请求服务器登陆，服务端在收到请求后会验证客户端传来的用户名和密码，若是验证经过，服务器就会签发一个token发给客户端，而且将token放到session或者报文中，客户端收到token后存储到本地，之后客户端只要每次请求服务器就要带上token，通过服务器验证经过后才会返回响应数据，不然报错。

CSRF攻击成功的前提条件是攻击者能够彻底伪造出受害者的全部请求，并且请求中的验证信息都在cookie中，黑客只要使用用户的cookie经过安全验证就能够完成攻击。了解了这些以后，想要防止CSRF攻击，就要在http请求中放置黑客不能够伪造的信息，并且该信息不能够存在于cookie中，不然就无效。而token令牌最大的特色就是随机性，不可预测，而且不存在于cookie当中。

最后注意一点，若是在同域下存在XSS漏洞，那么这种使用token的防护将形同虚设。

SSRF

不少 Web 应用都提供了从其余服务器上获取数据的功能。使用用户指定的 URL，web 应用能够获取图片，下载文件，读取文件内容等。这个功能若是被恶意使用，能够利用存在缺陷的 Web 应用做为代理，攻击远程和本地服务器。这种形式的攻击成为服务器请求伪造（SSRF，Server-Side Request Forgery）。

好比下列代码：

<?php
$url = @$_GET['url'];
if($url) {
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_HEADER, 0);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    $co = curl_exec($ch);
    curl_close($ch);
    echo $co;
}

这段代码从 URL 中读取url参数，以后访问url参数所指向的 URL 资源，最后把资源显示在页面上。

咱们访问 localhost/ssrf.php?url=http://www.baidu.com：

image.png | center | 827x445

这个漏洞还能够用于访问本地的资源，咱们再访问file:///C:/Windows/win.ini

image.png | center | 827x445

如下业务场景容易出现这种漏洞：

  • 应用从用户指定的 URL 获取图片，而后把它用一个随机名称保存在硬盘上，并展现给用户。
  • 应用获取用户指定 URL 的数据（文件或者 HTML）。这个函数会使用 socket 和 服务器创建 TCP 链接，传输原始数据。
  • 应用根据用户提供的 URL，抓取用户的 Web 站点，而且自动生成移动 Wap 站。
  • 应用提供测速功能，可以根据用户提供的 URL，访问目标站点，以获取其在对应经纬度的访问速度。

好比：有道翻译某处SSRF可通网易内网

防护方式

  • 过滤返回信息，验证远程服务器对请求的响应，是比较容易的方法。若是 Web 应用获取某种类型的文件，那么能够在把返回结果展现给用户以前先验证返回信息是否符合标准。
  • 统一错误信息，避免用户根据错误信息来判断远程服务器端口状态。
  • 限制请求的端口为 HTTP 经常使用端口，好比 80、44三、8080、8090。
  • 黑名单内网 IP，避免应用被用来获取内网数据，攻击内网。
  • 禁用不须要的协议。仅仅容许 HTTP 和 HTTPS 请求。能够防止相似于file://、gopher://和ftp://等引发的问题。

劫持

不少的时候，咱们的网站不是直接就访问到咱们的服务器上的，中间会通过不少层代理，若是在某一个环节，数据被中间代理层的劫持者所截获，他们就能获取到使用你网站的用户的密码等保密数据。

HTTP劫持

HTTP劫持是指，在用户浏览器与访问的目的服务器之间所创建的网络数据传输通道中从网关或防火墙层上监视特定数据信息，当知足必定的条件时，就会在正常的数据包中插入或修改为为攻击者设计的网络数据包，目的是让用户浏览器解释“错误”的数据，或者以弹出新窗口的形式在使用者浏览器界面上展现宣传性广告或者直接显示某块其余的内容。

这种状况下通常用户请求源网站的IP地址及网站加载的内容和脚本都是正确的，可是在网站内容请求返回的过程当中，可能被ISP ( Internet Service Provider，互联网服务提供商）劫持修改，最终在浏览器页面上添加显示一些广告等内容信息。

也有多是咱们在各类饭馆里面，连一些奇奇怪怪的wifi，若是这个wifi是黑客所创建的热点wifi，那么黑客就能够截获该用户收发的全部数据，以前315也演示过这个场景。

对于这些状况，网站开发者经常就没法经过修改网站代码程序等手段来进行防范了。请求劫持惟一可行的预防方法就是尽可能使用HTTPS协议来访问目标网站。还有就是尽可能不蹭网。

DNS劫持

DNS劫持一般是指攻击者劫持了DNS服务器，经过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，致使用户对该域名地址的访问由原IP地址转入到修改后的指定IP地址的现象，其结果就是让正确的网址不能解析或被解析指向另外一网站IP，实现获取用户资料或者破坏原有网站正常服务的目的。DNS劫持通常经过篡改DNS服务器上的域名解析记录，来返回给用户一个错误的DNS查询结果实现。

image.png | center | 600x343

DNS劫持也没有好的解决方法，尽可能外出不蹭网，网站尽可能使用HTTPS协议。

点击劫持

点击劫持（ClickJacking）是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，而后诱使用户在网页上进行操做，此时用户将在不知情的状况下点击透明的iframe页面。经过调整iframe页面的位置，能够诱使用户刚好点击在iframe页面的一些功能性按钮上。

点击劫持的危害在于，攻击利用了受害者的用户身份，在其不知情的状况下进行一些操做。若是只是迫使用户关注某个微博帐号的话，看上去仿佛还能够承受，可是若是是删除某个重要文件记录，或者窃取敏感信息，那么形成的危害可就难以承受了。

点击劫持的防范主要是设置HTTP请求头(X-Frame-Options)，X-Frame-Options HTTP 响应头，能够指示浏览器是否应该加载一个iframe中的页面。网站能够经过设置X-Frame-Options阻止站点内的页面被其余页面嵌入从而防止点击劫持。

经过写JavaScript来禁止iframe嵌套也能够，不过很容易绕过：

//------------------------------------
  // 防止网站被其余网页做为iframe嵌入
  //------------------------------------

  if (self != top) {
    top.location.href = self.location.href;
  }

代码执行

因为开发人员编写源码时，没有针对代码中可执行的特殊函数入口作过滤，致使客户端能够提交恶意构造语句，并交由服务端执行。命令注入攻击中，Web 服务器没有过滤相似system、eval和exec等函数，是该漏洞攻击成功的主要缘由。

好比代码：

<?php
// code-exe.php:
$code=@$_GET['code'];//http://localhost/subject/code-exe.php?code=
echo "<center>Payload:".$code."<br/>Result:</center>
eval($code);

访问 http://localhost/code-exe.php... 就能够看到 php info 了。

百度某站点python模板远程代码执行

不安全的第三方依赖

据统计一个应用有将近80%的代码实际上是来自于第三方组件、依赖的类库等，而应用自身的代码其实只占了20%左右。不管是后端服务器应用仍是前端应用开发，绝大多数时候咱们都是在借助开发框架和各类类库进行快速开发。

举个例子，jQuery就存在多个已知安全漏洞，例如 jQuery issue 2432，使得应用存在被XSS攻击的可能。而Node.js也有一些已知的安全漏洞，好比 CVE-2017-11499，可能致使前端应用受到DoS攻击。另外，对于前端应用而言，除开使用到的前端开发框架以外，一般都还会依赖很多Node组件包，它们可能也有安全漏洞。

也可能有人恶意编写有漏洞的 JS 文件，而且把它放到 CDN 上给别人用，全部使用它的站点都会受到影响。

NPM就有过这样的例子：软件包 getcookies 潜藏后门程序，而express-cookies和http-fetch-cookies依赖于getcookies，而mailparser依赖于http-fetch-cookies。

https://blog.npmjs.org/post/173526807575/reported-malicious-module-getcookies

还有不少名称相似的项目，好比原版包名称为js-cookie，恶意做者上传js-cookies，jscookie，jscookies等包，骗取下载。在使用第三方依赖时必定要再三确认。

弱口令

弱口令没有严格和准确的定义，一般认为容易被别人（它们有可能对你很了解）猜想或被破解工具破解的口令均为弱口令。弱口令指的是仅包含简单数字和字母的口令，例如"123"、"abc"等，由于这样的口令很容易被别人破解。

普通型

普通型弱口令就是常见的密码，好比，有人特意整理了经常使用的弱口令（Top 100）：

123456 a123456 123456a 5201314 111111 woaini1314 qq123456 123123 000000 1qaz2wsx 1q2w3e4r 
qwe123 7758521 123qwe a123123 123456aa woaini520 woaini 100200 1314520 woaini123 123321 
q123456 123456789 123456789a 5211314 asd123 a123456789 z123456 asd123456 a5201314 aa123456 
zhang123 aptx4869 123123a 1q2w3e4r5t 1qazxsw2 5201314a 1q2w3e aini1314 31415926 q1w2e3r4 
123456qq woaini521 1234qwer a111111 520520 iloveyou abc123 110110 111111a 123456abc w123456 
7758258 123qweasd 159753 qwer1234 a000000 qq123123 zxc123 123654 abc123456 123456q qq5201314 
12345678 000000a 456852 as123456 1314521 112233 521521 qazwsx123 zxc123456 abcd1234 asdasd 
666666 love1314 QAZ123 aaa123 q1w2e3 aaaaaa a123321 123000 11111111 12qwaszx 5845201314 
s123456 nihao123 caonima123 zxcvbnm123 wang123 159357 1A2B3C4D asdasd123 584520 753951 147258 
1123581321 110120 qq1314520

对于网站后台而言，通常为：

  • admin
  • manager
  • root
  • root123
  • tomcat
  • jboss
  • admin123
  • admin888
  • admin666
  • ...

条件型

条件型弱口令就是和用户信息相关的密码，好比生日+手机号、姓名首字母+生日、爱人姓名首字母+生日+经常使用字母（520、1314 等）。

黑客拿到用户的信息，根据密码心理学，社会工程学之类的，来猜想密码。咱们看的不少影片，都是社会工程学，好比特工偷取工卡、伪造证件之类的，安全最大的漏洞实际上是人。

撞库型

不少用户会在各个网站上使用同一个密码，黑客利用第三方已经泄露的用户数据库中的用户名、邮件地址或者手机号等去匹配明文密码，有必定几率命中。

这里能够查询是否被搞：https://haveibeenpwned.com/

以前不少知名的社工库都被搞了，大部分都在暗网交易。能够试试这个：https://publicdbhost.dmca.gripe/

查人：https://pipl.com

注册网站找回：http://www.zhaohuini.com/

防护方式

  • 每一个网站设置不一样的密码，密码12位以上，不要和本身的我的信息相关。
  • 银行取款密码不要和生日、身份证号之类相关。
  • 千万不要在云存储中存储证件照片，特别是手持身份证照片。

文件上传

浏览器经过上传页面将文件储存到服务器中。通常这些上传页面都会有限制（好比限制格式为jpg/gif/png等等，或者限制文件大小）。漏洞页面大体分为两种，一种是不限制任何格式，随意上传，这种如今比较少了。另外一种是限制Content-type，虽然它限制了文件类型，但能够突破它。

任意文件上传

好比咱们把一句话 <?php @eval($_POST['a']) ?> 写入1.php，而后把它上传到服务器。以后，尝试直接访问所上传的文件 xxx/upload/1.php。

文件类型限制

若是只是前端作了扩展名限制，能够经过接口工具绕过。若是后端加上了校验，这个校验必须很谨慎。黑客也有可能利用服务器的已知漏洞。好比以前Nginx、Apache、IIS 都爆出过解析漏洞。

例如：假设存在漏洞的站点上有一张图片，URL 地址为：www.xxx.com/logo.jpg

咱们正常访问时，Nginx 会把它当作非脚本，直接读取并传给客户端。可是若是咱们这样访问：

www.xxx.com/logo.jpg/a.php

他就会把logo.jpg当作 PHP 文件来执行。或者是：

www.xxx.com/logo.jpg%00.php

也会致使图片执行，往图片里面加一句 <?php @eval($_POST['a']) ?> ，post参数a里的内容就会被执行。

钓鱼

钓鱼也是一种很是古老的攻击方式了。不少人会有这样的经历，QQ群里面有人发什么兼职啦、什么本身要去国外了房子车子甩卖了，详情在我QQ空间里啦，之类的链接。打开以后发现一个QQ登陆框，其实一看域名就知道不是QQ，不过作得很是像QQ登陆，不明就里的用户们，就真的把用户名和密码输入了进去，结果没登陆到QQ，用户名和密码却给人发过去了。

image.png | center | 300x532.5

还有不少钓鱼短信常会假装成银行发送的短信，通常都是警告用户的银行帐户出现了安全问题，诱使用户点击短信中的连接地址来解决。钓鱼短信会连接到一个高仿的正规网站，这个高仿网站从表面上看不管是图标仍是页面设计和官方网站同样，给用户形成一种假象，以为这个网站没问题。接着就是要求用户提供尽量多的我的信息。

image.png | center | 475x363

钓鱼邮件是指黑客假装成同事、合做伙伴、朋友、家人等用户信任的人，经过发送电子邮件的方式，诱使用户回复邮件、点击嵌入邮件正文的恶意连接或者打开邮件附件以植入木马或间谍程序，进而窃取用户敏感数据、我的银行帐户和密码等信息，或者在设备上执行恶意代码实施进一步的网络攻击活动。

image.png | center | 762x386

还有一种是鱼叉式钓鱼攻击，鱼叉式钓鱼攻击与其余类型的钓鱼式攻击的不一样之处在于，鱼叉式钓鱼针对的是特定人员或特定公司的员工。网络犯罪分子会精心收集目标对象的信息，使”诱饵”更具诱惑力。精心制做的鱼叉式钓鱼电子邮件可能很难与合法的电子邮件区分开来。因此，鱼叉式钓鱼攻击更容易使目标上钩。

以人力资源部为例。该部门员工会收到各类格式不一的大量简历，因此收来一份附件来源不明的电子邮件是很日常的事，不会引发怀疑。简历里若是再附上一些做品连接或者做品附件之类的，就很容易中招。

防护钓鱼攻击只能靠细心，别贪便宜，别轻信连接和附件，记忆经常使用域名。

越权

越权（或者说权限提高，Privilege Escalation）是指攻击者可以执行他自己没有资格执行的一些操做。简单讲，就是“超越了你你拥有的权限，干了你原本不可能干的事儿”。越权漏洞的成因主要是开发人员在对数据进行增、删、改、查时对客户端请求的数据过于信任而遗漏了权限的断定。越权漏洞和前端的关系略小，不过由于在互联网金融领域太常见，因此一块儿说下。

image.png | center | 640x387

中国金融认证中心（CFCA）抽选和分析了2017年113个电子银行系统的渗透测试结果显示，发现的306个中高风险等级的安全漏洞中，与业务安全相关的漏洞占比最大，有210个，而传统渗透测试中常见的安全漏洞，如跨站脚本攻击、SQL注入、任意文件上传、远程命令执行等WEB应用安全漏洞，在电子银行系统中存在的状况相对较少。咱们的安全级别并不比电子银行系统高多少，因此上面的漏洞都应当注意。

一般状况下，咱们使用一个web应用程序提供的功能时，流程是：登陆—>提交请求—>验证权限—>数据库查询—>返回结果。若是在“验证权限”环节存在缺陷，那么便会致使越权。一种常见的存在越权的情形是：Web应用程序的开发者安全意识不足，认为经过登陆便可验证用户的身份，而对用户登陆以后的操做不作进一步的权限验证，进而致使越权问题。好比：

一、经过隐藏URL实现访问控制：

有些应用程序仅经过URL实现访问控制。例如：使用管理员身份登陆后能够看到后台管理页面的连接，可是以普通用户登陆则看不到该连接。可是直接输入连接，好比 xx/admin/userlist 之类的，普通用户就能够访问管理页面。

二、直接对象引用：

例如，在一个网银系统中，用户可使用如下URL查询帐户信息：

https://www.onlinebank.com/viewInfo.php?accountId=12345678

其中accountId是用户本身的帐户ID。用户登陆本身的帐户后，该URL的连接会出如今用户帐户页面中，用户点击便可跳转到帐户信息页面。虽然其余用户没法看到这个连接，可是若是该网银系统的访问控制不完善，攻击者彻底能够经过枚举accountId进而构造出URL，而后越权查看他人的帐户信息。

三、多阶段功能：

应用程序的一些功能经过几个阶段执行，而且在执行过程当中向服务器依次提交多个请求。这种状况很常见，好比转帐功能、找回密码功能等，须要先验证用户的身份，验证经过后才容许用户执行后续动做。多阶段功能自己并无问题，可是若是开发者认为到达验证过程后续阶段的用户必定已经拥有了相关的权限，并在后续阶段执行操做时再也不对用户提交的请求进行验证，那么就颇有可能存在越权漏洞。攻击者彻底有可能绕过前几阶段的验证阶段，直接执行后续的动做。

好比某网站在找回密码时作了很严格的验证，须要验证姓名、手机号、身份证号等信息，验证经过了才能修改密码。校验很严格，可是该网站的“找回密码”功能被设计成了两步（提交了两个请求报文）：第一步验证用户身份，这时提交第一个请求报文，验证成功以后，进入第二步；第二步才是真正的修改密码的动做，而修改密码的POST数据包有3个请求参数，分别是新密码、确认新密码以及帐号值。问题就出在第二步，在执行修改密码的动做时，服务器并未验证被修改密码的帐户是不是第一步中经过身份验证的帐户，所以攻击者能够很容易的以本身的身份经过认证，而后修改第二步提交的报文，实现对任意帐户的密码修改！

常见的越权高发功能点有：根据订单号查订单、根据用户ID查看账户信息、修改/找回密码等。

四、静态文件：

有些Web应用程序在用户访问动态页面时会执行相应的访问控制检查，以肯定用户是否拥有执行相关操做所需的权限。可是，用户仍然会提交对静态资源的访问请求，以下载网站中的word、excel、pdf文档等。这些文档都是彻底静态的资源，其内容直接由Web服务器返回，它并不在服务器上运行。所以，静态资源自身并不能执行任何检查以确认用户的访问权限。若是这些静态资源没有获得有效的保护，那么任何知晓URL命名规则的人均可以越权访问这些静态资源。好比Google hacking一下：

image.png | center | 794x464

互联网金融的不少系统就有越权漏洞，具体不点名了。

宜信某平台多处越权及任意用户登陆

防护方式

实现应用程序的完善的访问控制不是件容易的事，所以越权漏洞防不胜防。对于开发者而言，必定要有安全意识，时刻保持警戒。好比：

  • 永远不要相信来自客户端（用户）的输入。
  • 执行关键操做前必须验证用户身份，多阶段功能的每一步都要验证用户身份。
  • 对于直接对象引用，加密资源ID，以防止攻击者对ID进行枚举。
  • 在前端实现的验证并不可靠，前端能够验证用户的输入是否合规，在服务器端验证用户权限。

注意：《网络安全法》实施以后，全部未经受权的渗透都是非法行为，so，大部分白帽子的行为都是非法的，你们不要尝试。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程