Web常见安全漏洞

1 越权漏洞

越权指主体逾越权限访问资源。比如用户张三取消了用户李四的外卖订单、商户营业员查看了财务信息（假定角色营业员没有财务权限）。

越权的分类：
水平越权：如上述张三取消李四外卖订单。数据越权需从数据层面考虑，映射到关系数据库中的表，应该需要增加行控制（归属校验），即表中该订单记录关联的用户是张三时，张三才有权限。
垂直越权：如上述营业员查看财务信息。功能越权需从功能层面考虑，往往需要从接口层面限制，比如在Java程序种接口方法添加角色校验注解，程序处理注解检查当前登录用户是否具有相应的权限。

1.1 水平权限漏洞

Web应用程序接收到用户请求，修改某条数据时，没有判断数据的所属人，或判断数据所属人时，从用户提交的request参数（用户可控数据）中，获取了数据所属人id，导致恶意攻击者可以通过变换数据ID，或变换所属人id，修改不属于自己的数据。恶意用户可以删除或修改其他人数据。

攻击示例：

示例1（来自xx客户端的一个case）：

http://api.mobile.xx.com/dianying/comment/78404/440549.json?UComment=XXX（后面参数省略）

44059是一个评论id, 当用户修改自己的评论内容时，如果改变上述id值，则可以修改相应id所对应评论的内容。

防御思想：
需要保证“数据归属与主体”，至于如何做需要结合业务场景来执行。比如上述删除评论场景，通常会查询评论确保评论存在，在执行删除之前，可以检查所查询评论关联的用户与当前用户是否一致。

1.2 垂直权限漏洞

由于Web应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升目的。此类漏洞有可能使普通用户具有管理员权限。

防御思想：
需要保证“主体拥有该权限”，当前往往是居于角色定义权限。

2 SQL注入攻击漏洞

”SQL注入“拆字理解，即SQL + 注入
SQL，即Structured Query Language；
注入，即在SQL中参数夹带了SQL。

攻击示例：
一个在线商场系统，其中一个功能是商品搜索,用户输入关键字搜索上面信息，SQL是这样的：

SELECT xx,yy,...,FROM `product` WHERE `name` LIKE '%' + keyword + '%';

用户搜索iphone，请求https://mall.example.com/search?keyword=iphone

此时待执行SQL为：

SELECT xx,yy,...,FROM product WHERE name LIKE '%iphone%';

如果用户输入keyword=iphone’ or 1+1=2 and ‘%’='呢，那么待执行SQL将变成：

SELECT xx,yy,...,FROM product WHERE name LIKE '%iphone' or 1+1=2 and '%'='%';

待执行SQL发生了变化，插入（注入）了两个逻辑判断，搜索结果就不是预期的了。
或者输入keyword=iphone’; drop table goods;–,待执行代码变成：

SELECT xx,yy,...,FROM product WHERE name LIKE '%iphone'; drop table goods;--%';

表goods将被删除。

漏洞危害：
SQL注入本质上代码和数据分离的问题，在上面的场景中，预期用户输入数据，但是数据和代码的界线被打破了，导致数据携带了代码。数据可能会泄漏、数据可能被篡改、数据可能被删除…
除此之外，因数据库系统的差异，利用SQL注入，攻击者可能还可以读文件、写文件、执行系统命令等。

3 客户端页面展示安全问题

3.1 跨站脚本攻击XSS

跨站脚本攻击，英文全称是Cross Site Script，为了有别于Cascading Style Sheet(CSS)，简称XSS。
跨站脚本攻击本质是“HTML注入”，更加宽泛而言是”数据和代码没有分离”，即原本应当作为数据的输入夹带了代码。

跨站脚本攻击主要有以下3种形式：
反射型跨站脚本攻击（Reflected XSS)
一般来说，反射型 XSS 的恶意代码直接存在于 URL 链接中，通过混淆技术（如短地址转换）改变外观形态后，直接诱骗用户点击链接，从而触发浏览器执行恶意代码。

存储型跨站脚本攻击（Stored XSS)
存储型 XSS 又称为持久型 XSS，恶意代码通过 Web 应用提交到服务器端数据库，当其他用户浏览该数据的展示页面时，浏览器会执行载入的恶意代码。
常见攻击场景，如留言板等。

DOM型跨站脚本攻击（DOM Based XSS）
通常情况下，Web 开发者会在 HTML 页面中，通过定义一段 JavaScript 代码，根据用户的输入，显示一段 HTML 代码，而此时，攻击者可以在输入时，插入一段恶意脚本，最终展示时，会执行恶意脚本。
DOM 跨站和以上两个跨站攻击的差别是，DOM 跨站是纯页面脚本的输出，只有规范使用 JavaScript，才可以防御。

攻击示例：
Web编程，第一个Demo是输入名字，返回打招呼信息，交互如下：
Client（浏览器）：http://example/hi?name=xiaoming
Server：获取name参数值，输出页面（HTML），Hi，${name}，返回页面
Client（浏览器）：渲染，展示

正常情况下，name参数是一个普通的字符串，但是如果输入的是JavaScript脚本或者HTML标签呢？比如name=，将会导致“HTML注入”，即不在当普遍的字符展示，而是作为HTML代码执行。

XSS漏洞危害：
窃取会话凭证（比如文章上面说的Cookie）
篡改页面（比如广告）
钓鱼攻击
浏览器挖矿

3.2 跨站脚本伪造攻击漏洞CSRF

Cross-Site Request Forgery , 跨站请求伪造攻击, 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 Cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 Cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 Cookie 的浏览器端）发起用户所不知道的请求。
要完成一次 CSRF 攻击，受害者必须依次完成两个步骤：
登录受信任网站A，并在本地生成 Cookie。
在不登出 A 的情况下，访问危险网站 B。

攻击过程：

CSRF主要的攻击方式有GET型的CSRF和 POST型的CSRF两种类型。

攻击示例：
示例1：
银行网站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中的以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作。

示例2：
为了杜绝上面的问题，银行决定改用POST请求完成转账操作。
银行网站A的WEB表单如下：

<form action="Transfer.php" method="POST">
　　　　<p>ToBankId: <input type="text" name="toBankId" /></p>
　　　　<p>Money: <input type="text" name="money" /></p>
　　　　<p><input type="submit" value="Transfer" /></p>
</form>

后台处理页面Transfer.php如下：

<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　    buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
?>

危险网站B，仍然只是包含那句HTML代码：

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

和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果…和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了${}_{R}EQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用${}_{G}ET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

示例3：
经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　    buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
?>

然而，危险网站B与时俱进，它改了一下代码：

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 iframe = document.frames["steal"];
　　     　　      iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>
​
　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块…因为这里危险网站B暗地里发送了POST请求到银行。

总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。

理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

4 URL重定向攻击

URL重定向攻击是指Web应用程序接收到用户提交的URL参数后，没有对参数做“可信任URL”的验证，就向用户浏览器返回跳转到该URL的指令。
漏洞示例：
用户未登录的前提下访问订单列表。典型流程是引导用户登录之后，重定向到订单列表页面。
Client（浏览器）：http://example/orders
Server：重定向 302 Location=http://example/login?redirect=/orders
…登录流程
Server：重定向 302 Location=/orders
Client（浏览器）：访问 http://example/orders

攻击者引诱用户访问 http：//example/login?redirect=www.fake-target.site，如果server没有检查，那么用户登录之后就重定向到www.fake-target.site，这可能是一个钓鱼页面，受害用户可能在该页面中输入自己账户信息等敏感信息，也可能是欺诈页面。

防御思想：
从本质出发，打破“攻击者可控”，后端对待跳转地址进行可信检查–检查域名是否在白名单中，比如是否是.alibaba.com，.alisports.com公司域名。在某些特殊业务场景下，可能无法预知待跳转地址，也就无法做可信检查。这时候通常是风险告知，客户端发起重定向之前提示用户即将跳转到第三方地址，让用户选择确认或者取消。

篇幅有限，其他一些漏洞就不一一介绍了（文件上传下载漏洞、代码注入、CORS配置不当等），感兴趣可自行了解~
攻击者引诱用户访问 http：//example/login?redirect=www.fake-target.site，如果server没有检查，那么用户登录之后就重定向到www.fake-target.site，这可能是一个钓鱼页面，受害用户可能在该页面中输入自己账户信息等敏感信息，也可能是欺诈页面。