Hang's 码场

安全测试

2025/06/19

账号管理类

账号名称唯一性正常场景

测试步骤

  1. 使用管理员账号登录系统
  2. 进入新建账号的界面
  3. 新建用户名为cycle1的用户
  4. 再次新建用户名为cycle1的用户
  5. 观察是否可以新建成功

账号账号名称唯一性异常场景

测试步骤

  1. 使用管理员账号登录系统
  2. 进入新建账号界面
  3. 新建用户名为sectest的用户
  4. 将sectest用户设置为失效状态
  5. 再次新建用户名为sectest的用户
  6. 请已经失效的sectest用户设置为生效状态
  7. 观察两个相同用户名的sectest用户是否可以同时生效

确保admin用户的账号名可以修改

测试步骤

  1. 使用管理员账号登录系统
  2. 进入修改账号的界面
  3. 尝试修改账号名称
  4. 观察是否可以修改

账号删除后必须删除该帐号用户的个人数据信息

测试步骤

  1. 使用管理员账号登陆系统
  2. 进入账号删除界面
  3. 删除sectest用户信息
  4. 检查页面上是否存在sectest账号信息
  5. 检查数据库对应的用户资料表是否存在sectest的账号信息

新建同名账号不能继承已删除账号的个人信息权限数据

测试步骤

  1. 使用管理员账号登录系统
  2. 进入账号删除的界面
  3. 删除sectest用户信息
  4. 进入账号新建界面
  5. 新建用户名sectest用户
  6. 使用sectest用户登录系统
  7. 观察对应的账号信息是否继承之前同名用户的相关信息（菜单权限、个人信息、历史操作记录等）

系统应具备账号状态管理,功能账号的状态至少包含启用、锁定、停用等

测试步骤

  1. 使用sectest账号登录系统
  2. 观察是否可以正常登陆
  3. 观察登录以后是否可以正常访问界面

系统临时账号应设置有效期到期自动停用

测试步骤

  1. 使用管理员账号登录系统
  2. 进入用户管理界面
  3. 对sectest用户做锁定操作
  4. 退出系统
  5. 使用sectest登录系统
  6. 观察是否可以登录成功

长期不使用的账号,三个月未登录,自动转换到停用状态

测试步骤

  1. 使用管理员账号登录系统
  2. 进入用户管理界面
  3. 对sectest用户做锁定操作
  4. 退出系统
  5. 使用sectest登录系统
  6. 观察是否可以登录成功

默认同一账号只允许存在一个会话

测试步骤

  1. 使用管理员账号登录系统
  2. 进入用户管理界面
  3. 新建sectest2账号临时账号
  4. 对sectest设置有效期为五分钟
  5. 退出系统
  6. 五分钟后使用sectest登录系统
  7. 观察是否可以登录成功

口令管理类（验证码短信轰炸）

系统应支持配置口令复杂度以满足不同项目的要求,默认口令复杂度应至少满足以下要求

防爆破攻击机制,增加爆破难度。

  1. 口令长度至少八个字符
  2. 口令必须包含如下字符的组合每一种字符至少一个:
    • 大写字母
    • 小写字母
    • 数字
    • 特殊字符
  3. 口令不能和账号或者账号的逆序相同
  4. 不能包含超过两个连续同样的字符
  5. 禁用弱口令词典中的口令,弱口令词典:一些比较常用的口令可以放入弱口令词典中在用户设置新口令的时候进行校验
  6. 应用程序中若设置的口令不符合上述规则则必须进行警告
  7. 口令策略必须在任意需输入口令的位置进行校验,防止登录时默认不检查口令策略
  8. 出厂默认口令必须满足口令复杂度要求,产品到现场后必须修改所有账号的默认口令
  9. 如果产品的口令复杂度可配置那么在配置时必须检查口令复杂度的配置不得低于以上要求,比如配置口令最小长度时,应检查最小长度不得低于八位,说明某些场景下不能实现强口令策略,如需在营业厅密码盘上输入的自服务密码可以不适用

测试步骤

  1. 使用管理员账号登录系统。
  2. 进入口令策略配置界面。
  3. 按照原则中的12345要求配置。
  4. 进入密码修改界面。包括首次登录修改密码登录后修改密码等所有涉及到密码修改的界面。修改sectest用户的密码。
  5. 输入新密码为AB12观察系统提示。
  6. 分别输入新密码abcdef,123456,!@#$%^,ABCDEF观察系统提示。
  7. 分别输入新密码sectest, tsetcees观察系统提示。
  8. 输入新密码aaa12#观察系统提示。
  9. 输入新密码123qaz观察系统提示。

系统应支持配置口令有效期，以满足不同项目需求。默认口令有效期应满足至少以下要求。

  1. 管理员/操作员用户30天强制更换一次口令。
  2. 最终用户不用强制更新扣留。
  3. 口令超期前七天提醒修改口令。

管理员是指有权管理用户和应用程序服务器停的人员。

操作员是指使用系统功能办理业务的人员,运营商营业厅系统使用人员。

最终用户是指运营商的客户，如手机用户登录网上营业厅。那么此场景下的所有手机用户就是最终用户。

测试步骤

  1. 使用管理员账号登录系统。
  2. 进入口令有效期配置界面。
  3. 为了方便测试，将管理员账户密码有效期设置为1天，普通用户密码有效期设置为2天，口令超期设置为提前2天提醒。
  4. 被修改管理员和普通账号的密码。
  5. 休使用修改后的密码登录系统，观察是否弹出口令即将抄袭的提醒。
  6. 一天后，使用管理员账号登录系统，观察是否强制更换密码。
  7. 两天后使用普通账号登录系统，观察是否强制更换密码。

系统已经防止口令暴力破解攻击，包含用户名登录，修改密码等所有验证密码的场景，可以选择以下方式。

  1. 当用户登录重复输入错误口令次数超过系统限制时（可配置，默认三次），系统要锁定该用户账号或IP。
  2. 系统可以设置下次允许输入口令的间隔时间加倍。采用这种方式时，可以不设置自动锁定。

测试步骤

  1. 使用管理员账号登录系统。
  2. 进入口令出错配置页面。
  3. 配置出错次数为三次，或者下次输入口令间隔一分钟。
  4. 退出系统。
  5. 进入需要口令验校的页面。用户名输入框，输入正确的用户名。口令输入框，输入错误的口令，输错三次。
  6. 再次输入正确的用户名，错误的密码登录。
  7. 观察界面提示。

对于口令尝试N次失败被锁定的用户，系统用支持自动或手动解锁用户。

  1. 能够设置自动解锁时间，建议默认解锁时间为五分钟。
  2. 用户被锁时间达到预定义的时间，可自动解锁该用户。
  3. 在锁定时间内仅能允许应用安全管理员角色所属账号手动解锁该用户。

测试步骤

  1. 使用管理员账号登录系统。
  2. 进入锁定时间配置界面。
  3. 设置锁定时间为五分钟。
  4. 进入用户解锁界面，将sectest用户解锁。
  5. 退出系统。
  6. 使用sectest用户登录系统。
  7. 退出登录。
  8. 使用sectest的用户和错误的密码，登录系统四次，账号认证失败（锁定账号的次数为三次）。将sectest账号锁定。
  9. 五分钟后使用sectest用户登录系统。

输入口令时不能明文回显（ 操作界面中的输入口令用*代替）。

测试步骤

  1. 使用sectest用户登录系统。
  2. 进入所有设置到口令校验的界面。
  3. 在口令输入框输入密码。
  4. 观察界面口令回显形式。

口令不允许在界面上明文显示。说明：除非特殊业务需要禁止从服务端返回密码到客户端。

测试步骤

  1. 使用sectest用户登录系统。
  2. 进入所有显示口令的界面（例如默认密码配置数据库连接配置等）。
  3. 查看口令显示方式。

口令输入框禁止支持复制功能。

测试步骤

  1. 使用sectest用户登录系统。
  2. 进入登录界面修改密码界面等需要输入口令的界面。
  3. 选中口令，在键盘上按ctrl加C。
  4. 打开记事本在键盘上ctrl加v。
  5. 观察记事本上的文本是否为输入的口令。

口令禁止在代码中写死，所有口令必须要可更改、可配置。

测试步骤

  1. 登录应用系统。
  2. 按照默认密码列表核查口令是否可更改。

用户修改自己口令时，必须在同一请求内提交新口令和旧口令，并在修改口令前先验证旧口令。

测试步骤

  1. 登录系统。
  2. 进入密码修改界面。
  3. 观察是否需要输入旧口令。
  4. 就口令输入框为空，直接输入新口令。
  5. 输入错误的旧口令。输入新口令。
  6. 使用代理工具观察修改口令的请求，是否只有一条请求，同时包含了旧口令和新口令，没有其他参数。

不允许修改除自身账号以外的账号口令（管理员除外）。

测试步骤

防止越权登录绕过等。

测试步骤

  1. 使用sectest登录系统。
  2. 进入密码修改界面。
  3. 观察是否存在修改其他用户密码的功能。
  4. 使用burpsuite拦截修改自己密码的请求。
  5. 篡改请求中的带有身份信息标识的参数(例如，user ID，user code等)为sectest2的身份信息标识。
  6. 退出登录。
  7. 使用sectest2用户做登陆操作。
  8. 观察密码是否被修改。

应提供通过email或手机验证码重置密码的功能，向用户发送一次性的重置验证码或URL ，验证码或URL有效期可配置。建议15分钟，不得超过24小时。

在邮箱短信验证码的功能设计时，应考虑防止功能滥用。如限制同一客户端或用户使用该功能的频率次数等。若无次数限制，会导致短信轰炸。长时间验证码会存在泄露风险。

测试步骤

  1. 使用管理员登录系统。
  2. 进入验证码或URL有效期配置页面。
  3. 配置有效期为15分钟。
  4. 重置自己的密码。
  5. 收到验证码或URL后，等待15分钟，再输入验证码或点击URL。
  6. 观察页面是否有失效提示。

口令的认证凭证在传输过程中使用https安全协议或使用高安全。等级的加密算法。安全协议保护其机密性。

防密码泄露机制。高安全等级的加密算法包括AES128，RSA2048，sha 256及以上强度的加密算法。

测试步骤

  1. 使用代理工具抓取登录请求，确认是否使用https协议。
  2. 使用wireshark配置，然后调用登录接口，在wireshark抓取到报文中，右键选择追踪TCP流。
  3. 访谈开发人员确认协议加密算法。

口令不能够明文写入数据库、日志文件、配置文件以及cookie中，必须使用高安全等级的加密算法进行加密保护。口令不能以任何形式写入日志，包括加密口令。

测试步骤

  1. 进入数据库，查看口令在相关表中的存储方式。
  2. 搜索日志文件，查看口令在日志中的存储方式。
  3. 查看配置文件，查看口令在配置文件中的存储方式。
  4. 下载服务器的安装目录到本地，使用search and replace搜索关键字（包括但不限于系统内使用的各种口令的明文）分析结果中不存在发现的明文口令。

包括口令的文件必须设置访问控制，普通用户不能读取和拷贝加密的内容，将系统上含有口令的文件访问权限设置为750或者更低权限。

主机层防密码泄露机制。

测试步骤

  1. 登录应用服务器。
  2. 进入口令文件所在的目录。
  3. 使用阿拉斯刚L查看口令文件。
  4. 口令文件的权限小于等于750。

用户登录后，在界面上显示上次登录信息，包括登录时间，IP，成功、失败。

使用户可察觉自己密码有无泄漏。

测试步骤

  1. 使用正确的用户名，错误的密码登录系统。
  2. 使用正确的用户名，正确的密码登录系统。
  3. 查看界面是否有登录信息提示。
  4. 退出登录。
  5. 重复步骤二。
  6. 查看界面是否有登录信息提示。

默认关闭“记住我”之类的。在客户端存储口令的功能说明。有明确客户需求的可以支撑开启“记住我”功能，开启后必须保证客户端存储的口令处于加密状态。

测试步骤

  1. 打开登录界面等口令校验界面。
  2. 查看页面是否存在“记住我”功能。
  3. 若有“记住我”功能以问卷访谈形式询问开发者人员密文存储位置以及存储方式。

关闭登录窗体表单中的自动填充功能。 防止浏览器记录用户名和口令。

防止密码泄露。

测试步骤

  1. 打开登录界面等口令校验界面。
  2. 打开浏览器的开发者工具。
  3. 选中用户名和口令元素。
  4. 查看autocomplete是否为Off。

产品配套资料需提供清晰的默认账号口令清单。

测试步骤

  1. 包含账号口令清单。
  2. 包含操作系统，数据库，应用内安装好系统后的账号及口令。
  3. 包含每个用户的口令修改指南。

认证类

对用户的最终认证处理过程必须放到应用服务器服务端进行。

不允许仅仅通过脚本或其他形式在客户端进行验证。必须在应用服务器进行最终认证处理。如果采用其中认证如SSO，则对用户的最终认证应放在集中认证服务器进行。

常见的漏洞：认证结果从前端获取，burpsuite拦截后就可以绕过认证，从而越权访问资源。不仅仅是登录界面，所有访问资源的需要先身份认证的地方都有可能产生漏洞。

测试步骤

  1. 打开涉及到口令校验的界面。
  2. 输入正确的用户名密码。
  3. 使用burpsuite的拦截器登录请求，篡改口令字段为错误的密码发送登录请求。
  4. 观察是否可以登录成功。
  5. 若存在集中认证系统，在认证系统进行登录，跳转到子系统时，观察是否需要重新进行登录认证。

登录认证表单必须加入验证码，防止口令暴力破解攻击。为避免用户体验问题，建议在前三次登录程序中不使用验证码，三次登录失败后必须使用验证码登录。失败次数必须在后台维护。

测试步骤

  1. 打开登录认证界面。
  2. 查看认证界面是否存在验证码。
  3. 输入三次错误登录口令。
  4. 观察认证界面是否存在验证码。

用户名、 密码和验证码必须在同一请求中提交给服务器。必须先判断验证码是否正确。 只有当验证码校验通过后才进行用户名和密码的校验。 否则直接提示验证码错误。

测试步骤

  1. 打开登录认证界面。
  2. 输入正确的用户名，正确的密码和错误的验证码。
  3. 使用brupsuite拦截登录请求。
  4. 观察用户名密码验证码是否在同一请求中提交。
  5. 提交请求。
  6. 观察是否登录成功。

验证码，必须满足如下要求。

验证码复杂度可以防止机器识别绕过人机验证后爆破攻击。

  1. 验证码必须是单一图片，且只能采用jpeg、png或gif格式。
  2. 验证码内容不能与客户端提交的任何信息相关联。
  3. 验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现。
  4. 验证码字符串要求是随机生成，生成的随机数必须是安全的。
  5. 验证码要求有背景去有背景干扰，背景干扰元素的颜色、位置、数量要求随机变化。
  6. 验证码在一次使用后，要求立即失效。新的请求需要重新生成验证码。

测试步骤

  1. 打开登录认证页面。
  2. 打开开发者工具，进入network页面。
  3. 刷新验证码。
  4. 查看network页面验证码的type。
  5. 查看生成验证码和提交的参数是否有关系。 例如URL请求为get code.jsp?code=1234，验证码是1234则存在漏洞。
  6. 在开发者工具的sources中搜索验证码。
  7. 多次刷新验证码，观察每次生成的验证码大小数字是否有规律可循，例如递增递减等。
  8. 查看验证码，判断背景是否加上无规律的干扰点线或背景弄花等。

所有登录页面的认证处理模块必须统一。

防止浏览器绕过。

测试步骤

  1. 访谈开发人员，确认登录页面的认证处理模块。

所有针对第三方开放接口的认证处理模块必须统一。

防止登陆绕过。

测试步骤

  1. 访谈开发人员，确认第三方接口的认证处理模块。

认证处理模块在认证前必须对提交的参数进行合法性检查。

对于用户的输入均要做特殊字符转义等，防止注入类攻击。

测试步骤

  1. 打开认证登录界面。
  2. 输入正确的用户名，正确的密码和正确的验证码。
  3. 输入burpsuite拦截登录请求，分别修改验证码用户名口令为非法格式（非法格式包括：用户名或口令超长大于32位，用户名或密码超短小于四位，用户名或口令为空，用户名或验证码，包括特殊字符验证码，长度不正确，口令包括空格）。
  4. 提交请求。
  5. 观察响应。

认证失败后不能提示给用户详细以及明确的错误原因，只能给出一般的提示。建议统一提示：“用户名或口令错误，请重新登录！”。

防止用户名枚举漏洞。用户名枚举可增加爆破风险或信息泄漏。

测试步骤

  1. 打开登录认证界面，配置好代理工具。
  2. 输入正确的用户名，错误的密码，正确的验证码。提交登录请求。观察代理工具的响应。
  3. 输入错误的用户名，正确的密码，正确的验证码。提交登录请求。观察代理工具的响应。
  4. 输入错误的用户名，错误的密码，正确的验证码。提交登录请求。观察代理工具的响应。

禁止在系统中预留任何的后门账号或特殊的访问机制。

有泄露后造成越权等风险。

测试步骤

  1. 与开发人员访谈，确认测试代码、测验参数、测试账号、测试接口均没有包含在发布包中。
  2. 抽测接口。
  3. 配置好代理调用某一服务接口，在代理工具中确认接口名称。
  4. 使用search and replace搜索接口名称的关键字以定位代码中的接口。
  5. 对比代码中接收的参数和界面上的参数是否一致？
  6. 如果不一致，那么在代理工具中调用请求，并使用代码中接收的额外参数， 确认是否可以进行界面定义之外的操作。
  7. 使用search and replace搜索代码，选中扫描正则表达式。 搜索手机号正则表达式和邮箱正则表达式，并对代码进行结果分析。

对于重要的管理事务或重要的交易事务要进行二次确认，以防止会话劫持或跨站请求伪造给用户带来损失。

测试步骤

  1. 输入正确的用户名密码登录系统。
  2. 打开修改密码、支付、转账、服务增删改等重要的需要二次认证的页面。
  3. 查看是否需要再次进行身份认证。

高安全等级要求，如向公网开放的系统必须使用安全访问策略。

安全预防措施，减少攻击面。

  1. 对系统后台管理员登录页面，应限制访问的IP地址范围。
  2. 对特殊权限管理员（如号码管理员），应限制登录的终端IP地址范围或者Mac。

测试步骤

  1. 使用超级管理员账号密码登录系统。
  2. 配置管理员登录页面访问的IP为固定IP。
  3. 退出登录。
  4. 使用普通管理员账号或密码登录，观察是否可以访问管理界面。
  5. 退出登录。
  6. 使用超级管理员账号登录。
  7. 去掉管理员界面的IP限制。配置普通管理员的IP限制。
  8. 退出登录。
  9. 使用普通管理员账号登录系统观察是否有限制。

会话管理类

使用会话cookie rich会话。

防止未授权访问和越权。

测试步骤

  1. 登录应用。
  2. 使用burpsuite拦截抓取任意请求，观察请求中cookie中是否有expires/max-age属性。

登陆后，用户身份角色权限等数据在服务端维护，比如放入session对象中。

防止越权，未授权访问。

测试步骤

  1. 登录应用。
  2. 逐个访问各功能菜单，查看URL或页面源文件(以hidden关键词在源代码中查找隐藏域),是否包含用户标识。 商品价格等不允许客户端修改的信息。
  3. 尝试通过burpsuite拦截并修改步骤二发现的不允许客户端修改的信息(比如把用户标识改为其他用户，或者把商品价格改为低价格)，然后提交给服务器。
  4. 查看后台数据库相关表的数据变化。

当web应用跟踪到非法会话，必须记录日志，清除会话并返回到认证页面。

对于某些需要保持长连接的场景，可以不清楚会话，但必须提供告警信息。

安全防护措施，增加攻击难度，减少恶意尝试。

测试步骤

  1. 使用管理员用户登录应用。 进入用户管理界面，拷贝对应URL，然后点击注销退出按钮或菜单。
  2. 以普通操作员（未分配用户管理权限）登录系统。 在浏览器URL地址栏中粘贴步骤一获得的URL并按回车。
  3. 查看系统的响应。

禁止使用客户端提交的未经校验的信息来给会话信息赋值。

会话信息包括cookie中的数据和服务端会话对象中的数据。

参数化查询不可取，容易造成越权。此漏洞经常在我司产品中出现。

测试步骤

  1. 配置好代理工具登录应用。
  2. 访问被测接口，检查用户提交的用户。

用户名和密码验证通过后，必须更换会话标识，以防止会话固定session fixaction漏洞。

防止会话固定漏洞，泄露后有很大的风险。

测试步骤

  1. 打开web登录界面，输入用户名密码。
  2. 使用burpsuite拦截登录请求记录其中的jsessionid信息。
  3. 登录成功后再访问任意功能菜单。使用burpsuite拦截请求查看并记录其中的jsessionid信息。
  4. 比较步骤二和步骤三中记录的jsessionid是否一致。

当用户退出时，服务端必须清除该用户的会话信息。

防止cookie、token泄露。

测试步骤

  1. 登录web应用。
  2. 访问任意菜单使用burpsuite拦截post请求并放到Repeater窗口。
  3. 点击注销按钮。
  4. 在burpsuite的Repeater界面重新发送请求。
  5. 观察响应中是否有set-cookie。

必须设置会话超时机制,超时后,必须在服务端清除该会话信息，建议十分钟。

防止cookie、token泄露。

测试步骤

  1. 登录web应用
  2. 闲置浏览器11分钟
  3. 点击任意操作菜单,观察是否强制重新登录

在服务端对业务流程进行必要的流程安全控制，保证流程衔接正确，防止关键鉴别步骤被绕过、重复、乱序。

业务安全要求，防止逻辑漏洞。

测试步骤

  1. 登录web应用。
  2. 按照步骤顺序操作业务。
  3. 使用burpsuite按照顺序拦截请求，并依次放到repeater窗口。
  4. 打乱请求顺序发包列如从N步直接跳到N+2步。
  5. 查看响应是否正常。受理了步骤N+2步的请求，从而绕过了步骤N+1。

所有登陆后才能访问的页面都必须有明确的“注销（或退出）”的按钮或菜单。如果该按钮或菜单被点击，则必须使对应的会话立即失效。

基本安全功能退出后会话标识失效，否则存在身份被盗用风险。

测试步骤

  1. 登录到web应用。
  2. 观察页面上是否存在明显的注销/退出按钮。

会话标识必须足够随机，防止攻击者猜测标识或依据当前标识推测后续的标识。

防止cookie、token被暴力猜解。

测试步骤

  1. 登录web应用。
  2. 使用burpsuite拦截任意请求。
  3. 查看cookie、jsessionid等会话标识。
  4. 点击注销按钮。
  5. 观察jsessionid是否大于等于32位。

在cookie中设置secure HTTPonly等安全属性，以增强对cookie的保护。

会话安全属性，防止cookie、token被窃取。

测试步骤

  1. 进入登录界面。
  2. 输入用户名。
  3. 使用burpsuite拦截，登录请求和响应。
  4. 观察响应中set-cookie时是否有secure,httpOnly,domain和path属性。

权限管理类

应设置不同角色，不同的角色拥有不同的权限。不同的角色可以赋予于同一账号。

权限控制，便于权限粒度控制。

测试步骤

  1. 使用超级管理员登录到web应用。
  2. 进入角色管理界面。
  3. 查看不同的角色对应的操作权限是否相同(例如可访问的菜页面,可进行的操作)。
  4. 进入用户管理界面。
  5. 对用户进行角色赋权。
  6. 查看讨厌用户是否可以赋予不同的权限。

设置角色时，应根据系统特点尽可能细化各种权限。如管理员修改数据表，可以设计成特定的权限，修改特定的数据表。

权限控制，便于权限粒度控制。

测试步骤

  1. 以上需求通过即可。

赋予角色相应的生命周期。

权限控制，减少账号泄露危害。

测试步骤

  1. 以上需求通过即可。

授予和用户角色数据必须存放在服务器端，不能存放在客户端。鉴权处理也必须在服务端完成。

防止越权。

一个账号只能拥有必需的角色或必需的权限。一个组只能拥有必需的角色和必需的权限，一个角色只能拥有必需的权限。

权限控制，便于权限粒度控制。

对于运行应用程序的操作系统账号不能使用root，Administrator，Supervisor等特权账号或高级别权限的账号应该尽可能的使用低级别权限的操作系统账号。

防止获取后台权限后，直接获得服务器主机权限。

测试步骤

  1. 进入后台输入命令ps -ef grep应用。

对于应用程序连接数据库服务器的数据库账号，在满足业务需求的前提下，必须使用最低级别权限的数据库账号。

防止获取数据库权限后，直接获得服务器主机权限。

测试步骤

  1. 登录后台分别减少应用数据库账号的某一权限(减少任何一个权限业务应用均会出现问题)。

数据安全类

通用数据安全。

  1. 禁止在代码中存储敏感数据。
  2. 禁止密钥/口令以明文形式存储在数据库或者文件中。
  3. 禁止在cookie中以明文形式存储敏感数据。
  4. 禁止带有敏感数据的web页面缓存。
  5. 带有敏感数据的表单必须使用HTTP post的方式提交。
  6. 在客户端和服务器间传递明文的敏感数据时，必须使用带服务器端证书的TLS协议进行传输。
  7. 禁止在URL中携带会话标识，如jsessionid等。
  8. 禁止在HTTP请求和响应中暴露后台文件绝对路径。
  9. 仅允许将业务需要的敏感数据传送到客户端。

日志审计类

应用服务器服务端必须对安全时间及操作时间进行日志记录。

安全事件包括：用户登录、用户注销、添加用户、删除用户、修改用户权限、修改用户口令等。

操作事件包括：对业务系统配置参数的修改、对重要业务数据的创建、删除、修改等。

对于上述事件的结果，不管是成功还是失败，都需要记录日志。

应用程序出现异常时，应该在服务端捕获异常，并在日志中记录详细的错误信息。

测试步骤

  1. 登录系统。
  2. 进入用户管理界面。
  3. 进行添加、删除、修改用户、给用户授权、取消用户权限、修改用户口令等操作。
  4. 进入系统参数管理界面。新建、修改、查询、删除业务系统配置参数。
  5. 注销登录。
  6. 查看系统日志。

安全日志必须包括但不限于如下内容，事件发生的时间、事件类型、客户端IP、用户ID、访问对象（数据、资源）、操作结果。

建议同时记录启动该事件的进程线程标识以及对该事件的详细描述。

测试步骤

  1. 登录系统。
  2. 进入用户管理界面。
  3. 进行添加、删除、修改用户、给用户授权、取消用户权限、修改用户口令等操作。
  4. 进入系统参数管理界面。新建、修改、查询、删除业务系统配置参数。
  5. 注销登录。
  6. 查看系统日志。

严格限制对安全日志的访问。

只有web应用程序的管理员才能查询数据库表形式或文件形式的安全日志。

出数据库超级管理员外，只有应用程序连接数据库的账号可以查询（select）或插入（insert）安全日志表。

除操作系统超级管理员外，只有应用程序的运行账号才能读写文件形式的安全日志，但不允许删除。

测试步骤

  1. 使用普通用户登录到应用服务器。
  2. 进入log目录。
  3. 查看是否可以访问log文件。
  4. 使用普通用户登录到应用数据库。
  5. 尝试查询log表，观察是否具有查询权限。

对日志模块占用的硬盘资源必须有相应的限制机制。

测试步骤

  1. 使用管理员用户登录应用管理服务器。
  2. 进入日志文件目录，使用ID查看对应的group。
  3. 进入操作系统存储目录，使用ID查看对应的group。
  4. 对比福州二和步骤三中的group对应的ID是否相同。
  5. 打开日志级别。
  6. 进行功能测试自动化回归测试。
  7. 观察日志文件是否有转储、滚动、轮询机制。

禁止日志文件和操作系统存储在同一分区中，同时，应使用转储、滚动、轮询机制来防止存储日志的分区或磁盘写满。

测试步骤

  1. 在后台输入df，然后查看系统分区，确认日志的分区不是和如下目录同一不分区。
    • /bin：存放着常用的程序和命令。
    • /boot：存放启动Linux时使用的一些核心文件，包括Linux内核文件。
    • /dev：存放设备文件，例如硬盘、终端等。
    • /etc：存放系统配置文件。
    • /home：存放普通用户的主目录。
    • /lib：存放系统最基本的动态连接共享库。
    • /media：用于挂载可移动媒体设备，如USB驱动器、CD-ROMs等。
    • /mnt：另一个用于挂载设备的临时挂载点。
    • /opt：用于存放第三方软件。
    • /proc：一个虚拟文件系统，提供内核和进程信息。
    • /root：root用户的家目录。
    • /sbin：存放系统管理员使用的系统管理程序。
    • /srv：存放服务数据。
    • /tmp：存放临时文件。
    • /usr：用于存放共享的只读数据。
    • /var：用于存放经常变化的文件，如日志文件等。
  2. 访谈开发人员确认是否存在日志轮询机制。

输出日志的各服务器时间应保持一致。

测试步骤

  1. 检查部分日志，以确认日志的时间是否与当前时区时间一致。

安全日志应该有备份及清理机制，防止磁盘或存储过满。

生成安全日志时，将安全日志保存到集中日志服务器上。

服务接口类

对服务接口的调用，必须进行认证。

测试步骤

  1. 使用soapui录入URL和报文信息。
  2. 查看报文中是否存在用户认证凭证。

如果调用者的权限各不相同，那么必须配置框架提供的鉴权模块，以确认用户对服务接口的调用进行鉴权。

防止未授权访问、越权访问等。

测试步骤

  1. 使用soapui录入a用户有权限访问的接口URL和报文。
  2. 将A身份认证的信息修改为B用户的身份认证信息。
  3. 发送请求。
  4. 查看响应信息。

通过服务接口传递敏感数据时，必须加密后传输，或者采用tls等安全协议保障其机密性。

测试步骤

  1. 在soapui中录入接口的URL和报文信息。
  2. 使用burpsuite拦截接口的请求。
  3. 查看抓到的包体中口令是否采用安全期协议传输。如https sftp ssh等，或者使用高安全级别等级的加密算法(加密算法以问卷形式访谈测试)进行加密。

通过服务接口传递数据时，必须采用TLS等安全协议，并对数据进行数字签名，保障其安全性和不可抵赖性。

测试是否有https或HTTP混杂防止敏感数据泄露。

测试步骤

  1. 访谈开发人员确认接口的使用是否有签名机制。
  2. 确认接口是否有完整性校验机制。

如果服务接口只对特定的IP开放，那么必须对调用的服务接口的客户端IP进行鉴权，具有在IP地址白名单中的客户端才允许调用。IP地址白名单可配置。

网络划分，减少攻击面。

测试步骤

  1. 配置IP白名单。
  2. 在本期的soapui中录入接口的URL和报文信息。
  3. 尝试发送请求，观察是否可以正常发送。
  4. 使用burpsuite拦截对应的请求。 右键选择BURPfackIP功能插入伪造IP一般为X-FORWARD-FOR字段。
  5. 尝试发送请求，观察是否可以正常发送。

对服务接口的调用进行日志记录。

仅限于对用户提供的接口和对第三方系统提供的接口。需要记录日志内部调用，不强制要求记录日志查询，不强制记录日志。

便于审计和发现入侵。

测试步骤

  1. 在soapui中路由接口的URL和报文信息。
  2. 尝试发送请求。
  3. 登录后台服务器。
  4. 查看日志记录。

设置交易数据的服务接口必须在服务端对交易数据进行验证，比如平衡校验程序等，以确保其有效性。

防止中间人攻击。

测试步骤

  1. 使用soapui录入URL和报文信息。
  2. 使用burpsuite拦截请求信息， 篡改交易数据，比如将客服金额改为0，发送请求。
  3. 观察响应。

HTTP安全头部类

禁用不安全的HTTP方法，如PUT，DELETE，TRACE，TRACK等。

如果产品基于Spring框架开发的标准restful接口，已对HTTP方法进行了重新定义，并对使用场景进行了限制，不会执行原生HTTP方法，所以不需要禁用。

不安全的HTTP方法一般包括：TRACE，PUT，DELETE，COPY等。其中最常见的为TRACE方法可以回显服务器收到的请求，主要用于测试或诊断。恶意攻击者可以利用该方法进行跨站跟踪（即XST攻击），从而进行网站钓鱼、盗取管理员cookie等。

测试步骤

  1. 在burpsuite的repeater窗口构造请求如下： PUT /rsp/ HTTP/1.1 Host: ip:8282 Accept: /
  2. 讲步骤一中的PUT方法以此改为DELETE、TRACE。
  3. 查看响应。

在HTTP响应消息的header中设置X-Frame-Option X-XSS-Protection，Content-Security-Policy、Strict-Transport-Security等安全头字段，以增强web应用的安全防护能力。。

HTTP安全属性可以减少中间人攻击，CSRF，XSS等多种漏洞，增加安全性。

测试步骤

  1. 打开登录界面。
  2. 输入用户名密码登录系统。
  3. 点击任意页面。
  4. 使用burpsuite拦截请求和响应。
  5. 观察响应。

禁止在https页面中混杂HTTP内容。

防止敏感数据泄露。

测试步骤

  1. 打开登录界面。
  2. 使用开发者工具查看网页源代码。
  3. 搜索iframe、meta关键字。
  4. 观察是否有HTTP关键字。

注入类

XSS

  1. 必须对所有用户产生的收入在服务端进行校验。
  2. 必须对所有网元交互产生的输入进行校验。一旦发现数据不合法，必须记录告警日志。

  3. 禁止将HTTP标题头中的任何未加密信息作为安全决策依据。

    在同源策略、跨域访问等场景下，HTTP标题头中的数据可能被作为安全决策依据使用，此时这些数据需要实施机密性保护。

  4. 对于在客户端已经做了输入校验，在服务器端再次以相同的规则进行校验时，一旦发现数据不合法，必须使会话失效并记录告警日志。

    对于某些需要保持长连接的场景，可以不清除会话。 但必须提供告警信息。输入校验可以采用如下方式进行。

    1. 如果输入为数字参数，则必须进行数字类型合法性及判断。
    2. 如果输入只允许包含某些特定的字符或字符的组合，则使用白名单进行输入校验。
    3. 如果输入为字符串参数，则必须进行字符串型合法性判断。
    4. 校验输入数据的长度。
    5. 校验输入数据的范围。
    6. 使用黑名单进行输入校验。
  5. 对于不可信的数据，输出到客户端前必须进行HTML或URL编码。inner HTML取得内容后，用正则表达式去除HTML标签。
  6. 请只使用eval()函数来处理用户提交的字符串。

SQL注入

  1. 禁止通过字符串拼接的方式直接使用用户输入数据，构造可执行的SQL语句。
  2. 对于Java/jsp语言使用预编译语句PreparedStatement代替直接的语句执行statement。
  3. 如果服务器端调用操作系统命令，那么禁止将客户端输入的数据作为命令或命令的一部分执行。
  4. 对于使用MML进行数据交互的业务，包括服务接口，必须对输入参数进行校验，防止MML注入。
  5. 在导出格式为CSV Excel HTML时对用户进行控制的字符进行限制。禁用字符<>+-=@，防止CSV注入HTML注入。
  6. 验证应用程序是否针对LDAP注入漏洞提供保护，或者是否已实施防止L DAP注入的特定安全控制。

XXE

  1. 对于使用XML进行数据交互的业务（包括服务接口）。必须采用合适的方式来防止XXE攻击。

    可以通过禁止XML外部实体解析或者对XML数据进行校验的方式来防止XXE攻击。

  2. 文件上传下载接口涉及XML格式文档（如docx/xlsx/pptx等）解析时，需要防止XXE攻击，如果使用第三方组件进行解析，必须保持最新版本。

其他安全漏洞

文件上传下载

文件上传测试。

  1. 登录应用。 请打开文件上传页面。
  2. 点击浏览按钮并选择本地的一个jsp文件，比如hacker.jsp并确认上传。
  3. 如果客户端脚本限制了上传文件的类型，比如允许gif文件，则把。 hacker.jsp更名为hacker.gif。 使用burpsuite进行HTTP请求拦截，重新点击“浏览”按钮并选择后hacker.gif确认上传。
  4. 在burpsuite拦截的HTTP请求数据中，将hacker.gif修改为hacker.jsp，再发送请求数据。
  5. 登录后台服务器，用命令find ./ -name hacker.jsp，查看hacker.jsp文件存放的路径。如果可以直接以web方式访问，则构造访问的URL，并通过浏览器访问hacker.jsp，如果可以正常访问，则已经取得WebShell测试结束。如果hacker.jsp无法通过web方式访问，例如hacker.jsp存放在/home/tmp/目录下，而/home/tomcat/webapps目录对应的http://www.example.com/ ，进行下一步。
  6. 重复1-3，在burpsuite拦截的HTTP请求数据中，将hacker.gif修改为../tomcat/webapps/hacker.jsp,在发送请求数据。
  7. 在浏览器地址栏输入http://www.example.com/hacker.jsp。 访问该后门程序取得WebShell。
  8. 重复步骤一选择一个>10M的文件进行上传。

文件下载测试。

  1. 更改参数的值为其他路径和文件

  2. 在浏览器地址栏中尝试以下URL

    http://www.exmaple.com/viewfile.do?filename=../etc/passwd

    http://www.exmaple.com/viewfile.do?filename=../../etc/passwd

    http://www.exmaple.com/viewfile.do?filename=../../../etc/passwd

    http://www.exmaple.com/viewfile.do?filename=../../../../etc/passwd

    http://www.exmaple.com/viewfile.do?filename=../../../../../etc/passwd

    ……

对于UNIX/Linux服务器可以尝试下载/etc/passwd；对于Windows服务器可以尝试下载c:\boot.ini文件 观察页面返回信息，如果可以获取到passwd或boot.ini文件，则说明存在漏洞。

  1. 必须在服务器端采用白名单方式对上传的文件类型、大小进行严格的限制。
  2. 对下载文件的权限进行严格控制，在下载文件前必须进行合法性校验，防止攻击者利用目录跨越、越权下载到本不该下载的文件（比如其他用户的私有、敏感文件）。
  3. 禁止以用户提交的数据（如文件名）作为上传/下载文件的路径或文件名，以防止目录跨越和不安全直接对象引用攻击。
  4. 禁止将敏感文件（如日志文件、配置文件、数据库文件等）存放在Web内容目录下。
  5. 文件上传下载接口必须对./以及../等进行屏蔽，防止用户恶意猜解后台服务器目录结构。

越权访问

  1. 对于每一个需要授权访问的页面、servlet、service的请求都必须核实用户的会话标识是否合法、用户是否被授权执行这个操作。
    1. 对于每一个页面请求，应当先检查用户会话确认用户是否已经登录，如果用户未登录，则返回登录页面；
    2. 用户身份应当从服务端session对象中获取，而不应依赖于用户请求中的userid等信息；
    3. 用户对于资源是否有权限进行访问和操作，应该从服务端维护的用户-角色-权限-资源关系中获取。”
  2. 使用第三方组件和开源组件时，如果不需要使用第三方组件和开源组件提供的接口则必须关闭，如需要使用则必须配置认证模式，防止未授权访问。

基于用户身份ID的越权

基于用户身份ID的越权

篡改cookie进行越权

防止第三方接口未授权访问

敏感信息泄露

  1. 应用程序出现异常时，禁止向客户端暴露不必要的信息（如在响应中打印堆栈信息等），只能向客户端返回一般性的错误提示消息。
  2. 应当配置统一的HTTP出错页面，防止HTTP请求报错时泄露服务器版本信息。 在客户的测试中，经常出现tomcat报错页面泄露tomcat版本等；
  3. 在注释信息中禁止包含物理路径信息、数据库连接信息、SQL语句信息、源代码信息。
  4. 对于动态页面不使用普通注释，只使用隐藏注释。
  5. 版本归档时，必须删除开发过程（包括现场定制）中的临时文件、备份文件、无用目录、测试用户和数据等。
  6. 归档的页面程序文件的扩展名必须使用小写字母，禁止保留调试用的代码。
  7. 禁止在日志中打印认证凭据信息如密码hash、会话ID、数据库连接信息等。
  8. 禁止在响应消息中返回用户密码。
  9. 禁止在响应消息中返回以及在前台界面上展示后台数据库表名、字段名，业务必须返回的应对返回的表、字段名加以限制仅返回业务必须字段。

目录