企业官网建设流程全解析

测试时不仅要保障功能，同时也要注意安全方面的测试。这篇文章分享一些在web端常见的安全问题以及测试方法。

要明确的一点是：安全问题是团队里所有人需要注意的问题，我们只能从测试的角度尽量避免一些问题，开发、产品、项目经理等人也是需要从自身岗位的角度上去思考怎么应对的，只是从测试角度考虑问题不能保证安全。

越权

越权指的是没有校验权限就返回了数据/允许访问页面。这是一个很严重的问题，对用户的数据安全有很大的威胁。常见于账号之间没有做权限校验

横向越权

不同账号下的越权，A用户与B用户的级别权限是一样的，但A用户能够去查看B用户的敏感信息，或进行其它恶意操作。比较常见的有直接使用他人的userid去请求数据，如果能够直接请求成功，那么就存在越权问题

纵向越权

同一个账号下，不同身份的越权。比如：A用户是普通员工，C用户是经理，经理能看到所有人的工资，但A不能，垂直越权后A用户就有C用户的权限了。

测试方法

解决方法

一般在接口层面，通过传入的参数加token等进行身份验证。 在前端层面，要限制通过url直接跳转等方式的越权。但是这种方式未必安全，用户可以通过抓包或者修改本地缓存的方式伪造身份，最终还是要回到后端的判断上

1. 通过工具进行测试，越权测试工具：https://blog.csdn.net/m0_63878364/article/details/149329728?sharetype=blogdetail&sharerId=149329728&sharerefer=PC&sharesource=m0_63878364&spm=1011.2480.3001.8118

2. 手动调用接口进行测试

   横向越权（同级别用户）

   用两个普通账号（A、B）分别登录，A 访问自己的接口，抓包获取参数（如userId=1001），将userId改成 B 的 ID（如1002），发送请求，看是否能成功获取 B 的数据

   纵向越权（不同权限用户）

   用一个普通用户账号和一个管理员账号，普通账号访问管理员接口，如果接口返回成功或部分敏感数据，存在纵向越权

3. 浏览器直接输入url跳转到没有权限的页面，如果能跳转成功，证明存在越权

CSRF跨站攻击

原理

利用浏览器的机制，窃取网站cookie信息冒用身份进行攻击。

例如：用户访问了一个银行网站并登录了账号。在用户没有关闭页签的情况下，打开了恶意网站B，恶意网站B中有这么一段代码。<img src=”https://bank.com/transfer?to=heike”>。那么在打开这个网站的一瞬间，就会触发接口，转走用户的钱，且用户是无感知的。

讲到这里，需要说一下cookie的一个属性：SameSite

SameSite分为三个属性：Strict、Law、None

None：其他网站在通过img/link等标签发起请求的时候，会自动带上属性为None的cookie值。

Law：宽松模式,允许部分第三方网站请求携带cookiea,link标签get读取请求

Strict：严格模式,在任何情况下都不会被第三方网站链接携带

测试

以下图为例：

这是一个登录了的网站的cookie

现在构建一个测试网站，这个网站会加载一张图片，但是图片的地址其实是指向了一个登录信息的接口

在访问网站的一瞬间，我们可以看到请求里cookie里带上了上面图里几个SameSite属性为None的cookie值

上面虽然解决了几个SameSite=None的cookie，但是如果我们想要的cookie值SameSite是Law怎么办？可以通过别的办法来搞定这个问题，如下图，我们生成了一个a链接，a链接地址指向一个接口。

点击后，直接访问了对应接口的地址，可以看到，访问接口时携带的cookie中，除了SameSite=None的之外，还包含了SameSite=Law和SameSite=空的cookie，但是SameSite=Strict的值是没有携带的，测试到这里，基本也就结束了

防范措施

1. cookie中不要存放关键的信息（id、token等）即使有存放，也要使用Strict进行约束

2. 使用token替代cookie。由于CSRF是利用了浏览器自动携带cookie的机制，因此如果使用token来替代掉cookie的话，就能防御很多场景。因为token不像cookie，token是需要自己拼接并且附带到请求头中的，也就不容易被攻破。

3. Referer头部校验。csrf主要是第三方网站拿着浏览器保存的cookie去访问服务器,如果我们告诉服务器发起请求的页面地址,让服务器判断是否为第三方网站是否需要给其访问权限是不是就可以了。这就使用到了http头中的referert字段,这个字段标识了发送请求的客户端地址,后端可以通过白名单等方式对请求进行限制。

4. cookie中拼接随机token

XSS注入攻击

原理

跨站脚本攻击（Cross Site Scripting）的本质是攻击者在web页面插入恶意的script代码，当用户浏览该页面之时，嵌入其中的script代码会被执行，从而达到恶意攻击用户的目的。比如读取cookie，token或者网站其他敏感的网站信息，对用户进行钓鱼欺诈等。

存储型XSS

存储型XSS可以理解为把恶意脚本内容存在了服务端的数据库里，每当用户访问页面时，就会取出数据库中的内容，拼接到html中对用户发起攻击。如图：

上面是访问页面时自动触发的一种xss攻击，还有一种方式是当插入的<script>标签无法生效时，通过html标签引导用户主动点击触发脚本的攻击方式。如果一个页面能够渲染html代码，那我们能够插入一段恶意代码

<button οnclick="alert(sessionStorage.getItem('userInfo'))">获取session的按钮</button>

这段代码会被渲染成一个按钮，当点击按钮后，就会获取到sessionStorage中的userInfo，这是很危险的

<img src="123" οnerrοr="alert(123)">

这段代码在用户访问页面的一瞬间就会触发，且会循环触发。比上面的button破坏性更大

反射型XSS

反射型XSS跟存储型XSS不太一样，反射型XSS是不存储在服务器中的，一般通过url的参数进行注入，可以结合社媒进行钓鱼攻击

url参数注入

例如以下的测试网站：https://xss.xiejiahe.com/level1?name=zhanhuasheng

你正常输入一个名称，页面是正常显示的。

但是如果你把url输入成这样https://xss.xiejiahe.com/level1?name=<script>alert(123)</script>，就能注入成功，当用户点击这个链接的时候，就会触发XSS攻击

页面元素注入

XSS攻击不止可以利用url，还可以利用页面中的元素。例如下图中，在输入框内输入内容提交后，会把value改成输入的值，那么我们可以利用标签，输入以下内容完成注入

"><script>alert(123)</script>//

原本正常的标签是这样的：

<input name="keyword" value="test">

在输入内容后就会变成

<input name="keyword" value=""><script>alert(123)</script>//">

有的时候，为了防范这种xss注入，前端会把输入的内容进行处理，例如把输入的空格转义。这个时候可以输入%0a代替空格进行尝试。通常转义都是针对尖括号、引号、空格进行处理。当你直接输入<>等内容没法注入成功的时候，可以尝试输入转义后的内容

html转义

尖括号：< 转换为 &lt; >转换为&gt;

引号：" 转换为&quot; '转换成&#39;

空格：转换成&nbsp;

url转义

尖括号：< 转换为 %3C >转换为%3E

引号：" 转换为%22 '转换成%27

空格：转换成%20或者%0a（换行符）

还有的会识别关键字进行处理，比如把script转换成scr_ipt或者自动双写script。那么可以尝试着通过输入大小写混合的ScRipt进行绕过，具体可以通过练习网站进行尝试

Xss在线练习网站：https://xss.xiejiahe.com/level1?name=good%20job!

答案：https://www.jianshu.com/p/4e3a517bc4ea

测试思路

1. 遇到需要回显数据的地方，需要注意xss注入，常见于评论、资料、商品信息等，这种地方一旦出现注入，影响面大且容易带来巨大损失

2. 涉及html、富文本的地方，也很容易出现xss注入，例如邮件、FAQ等

3. 测试时，可以先输入最简单的内容进行测试，例如<div>123</div>，如果会被直接渲染成页面元素，证明是存在xss注入风险的

4. 如果第三点是正常的，可以观察是否存在转义，例如<被转义成&lt;的情况，有时候会通过这种方法来防范xss注入，这时候可以输入&lt;来代替<进行测试。且这种处理方法有另一个问题，就是正常用户输入的<会被转义无法正常显示，是有bug的

5. 有时候回显到页面中的内容是正常的，但是value等属性也会存在注入风险，当发现自己输入的内容会被赋值到元素的属性中时，可以尝试拼接内容进行注入

6. 不止是元素，有时候还可以利用文件名称进行注入，当然这一步通常要配合抓包软件操作

7. 还有可能会遇到自动过滤特殊字符的情况，例如自动删除script的内容，这种时候可以通过输入sscriptcript这种内容来达到目的，具体要根据实际情况进行分析。

暴力破解

指的是接口没有校验用户的访问次数，导致用户可以无限制的尝试接口，通过循环的方式破解出用户的数据的一种攻击。比较经典的场景是登录，如果允许用户无限制的尝试登录，那么就可以结合密码字典等方式把密码给暴力破解掉。

目前有很多的工具支持暴力破解，比如burp suite，也可以使用编程语言进行测试

测试思路：

1. 登录、验证码等需要校验的场景，需要做暴力破解的防范

2. 处理方式通常是一定时间内，出现多次错误则暂时锁号，但是也要考虑到有人利用该规则恶意锁定他人账号的场景，所以通常是通过ip+账号的未读进行封锁

3. 提示词的返回：以登录场景为例，密码错误、账号不存在这两个场景，返回的提示词应该都要是一样的。不能够让人通过提示词来判断出登录不上是什么原因。

DDOS

DDoS是一种网络攻击形式，攻击者通过大量分布式设备（通常是被劫持的“僵尸网络”）向目标服务器、网络或服务发送海量请求，导致目标系统无法处理正常请求，从而使其瘫痪或不可用。

原理是通过海量的请求，耗尽服务器的资源，使得正常的请求也无法被处理。

想象一家餐厅（目标服务器），它可以同时为 20 位顾客（正常用户）提供用餐服务。

一天，有一群恶作剧的人（攻击者）决定让餐厅瘫痪。 这些人（僵尸网络）组织了上百人（恶意设备），不停地占用餐桌、点菜、要求服务，但实际上他们并不吃饭。

服务员和厨房（餐厅的资源）忙得不可开交，但却没法腾出桌子或资源为真正想用餐的顾客（正常用户）服务。

最终，这家餐厅的服务能力被耗尽，真正的顾客进不来，餐厅就陷入了瘫痪状态。

测试思路：

1. 理论上，我们是没法完全解决DDOS这个问题的。但是云服务商一般能提供成熟的DDOS防御手段。在服务中通常使用ip+id等关键信息对用户身份进行识别，如果短时间内有大量的异常请求，可以直接限流或者通过验证码来拦截机器，这样可以一定程度地保障服务正常运行。

2. 在多次触发后，可以把指定ip的用户拉入黑名单，永久不让他进行访问。相对应的，公司内部都是用同一个ip，为了避免公司内部误触发，也需要设置对应白名单

3. DDOS的防护和暴力破解不同，暴力破解通常针对某个接口，但是DDOS可能从任意接口进来，特别是消耗资源多的接口。如果要防护应该从系统层面进行处理，而不是在接口逻辑里进行判断

数据脱敏

针对比较敏感的数据，在存储的时候需要加密处理，在页面上或接口上也要想办法限制，不让别人能够直接看到明文。比如下图的邮箱授权码。通常需要脱敏的数据有身份证、密码、关键的id等信息，在缓存、数据库、接口层、页面都得做限制。此外，关键信息不应该存储在cookie等地方，或者就算要存储也应该加密存储。

前端混淆加密

在某些情况，前端不得不存放一些重要的信息，例如在进行非对称加密时，前后端各自持有一份密钥。这份密钥不能依赖后端返回，只能存放在前端中，但是如果直接明文存储，用户就可以从开发者工具中找到密钥，下图是随便找的一个图片示例从哪里可以找到前端代码内容。

逻辑漏洞

针对业务逻辑进行测试，没有具体的测试点。举个例子：在进行付费时，如果接口中传输了金额，可以尝试通过抓包的方式修改金额，测试能否低价买高价商品

sql注入

原理：通过输入恶意文本篡改原有的sql语句，对数据库进行攻击的一种手段。

举例：原本的查询语句是这样的

SELECT * FROM users WHERE username = 'zhangsan' AND password = '123456';

如果用户输入恶意内容：zhangsan' -- ，语句就会变成下面这个样子。可以看到对于密码的判断已经被注释掉了，这样的话就可以绕过密码校验

SELECT * FROM users WHERE username = 'zhangsan' --' AND password = '123456';

更进一步，输入 ' OR 1=1 -- ，语句会变成这个样子。由于1=1是永远为真的，因此会暴露出所有的user数据

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '';

甚至可以输入 '; DROP TABLE users; -- ，那么语句就会变成下面这样，直接删除users表

SELECT * FROM users WHERE username = ''; DROP TABLE users; --

相关测试工具：sqlmap

https://blog.csdn.net/ewii12567/article/details/145995372