web安全测试实践方法

167 阅读17分钟

在当今数字化时代,软件安全已成为企业和个人用户的核心关切。面对网络攻击手段的不断演变和升级,软件中存在的安全漏洞极有可能对企业造成重大的经济和声誉损失。通过持续开展安全测试,企业不仅能够有效地防御潜在的安全威胁,保护其宝贵资产和用户敏感数据,有助于企业在用户心中建立起可靠和专业的品牌形象,进而在商业竞争中占据有利地位。

01

安全测试简介

安全测试是一种系统性的评估和验证过程,旨在发现软件、网络或系统中存在的潜在安全漏洞和风险。通过模拟真实世界的攻击场景和利用安全漏洞的方法,评估系统的安全性,并提供建议和解决方案来修复发现的漏洞,从而保护系统免受恶意攻击和未经授权的访问。安全测试涵盖的范围非常广泛:包括业务功能、应用、网络等方面,本文将重点探讨WEB应用安全测试相关内容。 

下面我们先了解一些 Java Web应用常见的安全漏洞: 

1、WEB应用安全测试常见漏洞介绍

Java Web应用常见的漏洞主要包括信息泄露、猜解漏洞、业务逻辑缺陷以及未过滤的输入输出等问题。基于这些漏洞类型,我们归纳出一些典型的安全测试场景。 

Notes:这些场景是WEB安全测试的典型场景,全面的WEB安全测试覆盖的范围要广泛的多。 

1.1 信息泄露 

信息泄露是指敏感或保密的信息未经授权地被披露或获取。通常是由于设计缺陷、编程错误、配置不当或滥用权限等原因导致。常见的信息泄露场景包括:传输过程泄露、敏感文件泄露、报错页泄露敏感信息、接口泄露敏感信息等。 

1.1.1 传输过程泄露漏洞 

指的是在数据传输过程中,敏感信息以明文的形式(即未加密的原始文本)在网络上进行传送的情况。攻击者可以通过窃听网络通信来获取传输的敏感信息,这种情况下,密码、个人身份信息、财务信息等可以被轻易截取和窃取。 
测试方法: 

  1. 使用代理工具(如Burp Suite)拦截和修改数据包,验证系统是否能够正确地加密敏感信息; 
  2. 使用网络嗅探工具(如Wireshark)来监视网络流量,检查是否有敏感信息以明文形式传输。 
    防御方法: 
  3. 对敏感信息进行分类,采取适当的措施保护对应信息; 
  4. 网络通信中使用安全的加密协议; 
  5. 敏感信息采用安全的加密算法和密钥长度; 
  6. 避免明文存储敏感信息; 
  7. 定期进行安全审查。 

1.1.2 敏感文件泄露漏洞 

敏感文件泄露漏洞是一种常见的安全漏洞:指在应用中,由于配置不当、管理疏忽或其他原因,导致包含敏感信息的文件(如数据库配置文件、源代码备份、日志文件等)被放置在公共可访问的目录下,从而允许未授权用户访问这些文件的情况。该漏洞可能会导致机密信息泄露、隐私问题以及合规性风险。 
测试方法:通过工具对系统中常见的敏感文件进行遍历,扫描系统开放的端口和服务。推荐几款扫描工具:Nessus/ZAP/御剑。 
防御方法: 

  1. 制定定期扫描计划; 
  2. 对敏感文件进行加密; 
  3. 定期审计文件访问记录,监控敏感文件的访问情况。 

1.2 猜解漏洞 

猜解漏洞是Web应用中存在的一类安全漏洞,它允许攻击者通过尝试不同的输入组合来猜测系统信息,如用户名、密码、文件路径等。这种漏洞通常发生在应用程序没有正确地限制对敏感资源的访问,或者没有适当的错误消息管理,导致攻击者可以通过分析应用的响应来获取额外的信息。 常见的猜解漏洞场景包含账号枚举、弱口令密码、敏感链接预测、暴力破解等。 

1.2.1 账号枚举漏洞 

攻击者通过系统返回的错误信息或其他方式,识别系统中存在的有效用户账号。 
测试方法:在需要验证账号/密码/验证码等功能模块中使用已知存在和不存在的账号进行操作,观察系统反馈是否有差异。 
防御方法: 

  1. 在相关业务中统一错误消息; 
  2. 限制每个IP地址或账号的登录尝试次数,添加账号安全锁定机制等; 
  3. 查看系统的登录日志和错误日志,分析是否存在账号枚举的痕迹。 

1.2.2 弱口令密码漏洞 

用户在使用密码时选择了过于简单、容易被猜测或破解的密码,存在安全隐患,容易被暴力破解。 
测试方法: 

  1. 检查系统是否实施了强密码策略,如密码长度、复杂性要求等;检查系统中存储的密码是否以明文形式存储; 
  2. 使用暴力破解工具(如Burp Suite)多次请求登录接口,查看是否有安全登录限制。 
    防御方法: 
  3. 制定强密码策略,要求用户设置符合安全策略的密码; 
  4. 限制每个IP地址或账号的登录尝试次数,添加账号安全锁定机制等。 

1.3 业务逻辑漏洞 

业务逻辑漏洞是指在软件应用程序的业务逻辑中存在的安全弱点,这些弱点可以被攻击者利用来绕过正常的应用流程,实现非预期的功能或访问未授权的数据。常见业务逻辑漏洞包含:越权访问、业务流程跳跃、异常链接跳转、文件上传、登录安全性验证、前端校验绕过等。 

1.3.1 越权访问 

攻击者通过利用系统中存在的漏洞或不当配置,获取到未经授权的权限,从而访问或执行本应该被限制的操作;越权是开发容易忽略的点,问题发生概率很高。常见的越权包括:垂直越权/水平越权。 
垂直越权:攻击者利用漏洞绕过系统的权限验证机制,获取到比其权限范围更高的权限。水平越权:攻击者可以访问或执行本应受限制的操作,如查看、修改或删除其他用户数据。 
测试方法: 

  1. 使用低权限账户访问高权限资源,通过API接口访问需要高权限的操作; 
  2. 修改API/URL参数访问其他用户数据; 
  3. 审查业务流程,查看是否存在越权访问漏洞; 
  4. 验证数据库的权限设置,确保只有授权用户可以访问特定数据表或执行特定操作。 
    防御方法: 
  5. 确保系统实施了严格的权限控制机制,经过授权的用户才能访问特定资源或执行特定操作:包括对用户、角色和权限的管理,以及对访问控制列表(ACL)的有效管理; 
  6. 最小权限原则:用户应该只被授予完成其工作所需的最低权限; 
  7. 确保系统在访问敏感信息或执行敏感操作时进行适当的身份验证; 
  8. 敏感数据加密,避免被越权后泄露敏感信息; 
  9. 定期审计和监控系统的访问记录,及时发现异常访问行为。 

1.3.2 业务流程跳跃 

该漏洞指攻击者通过绕过应用程序的正常流程,利用未经授权的方式执行系统中的某些关键操作或访问敏感信息的漏洞。 
测试方法: 

  1. 对系统中的关键业务流程进行审查,识别可能存在的跳跃点和漏洞。检查系统是否严格遵循预定的业务流程,是否存在绕过流程的可能性。 
  2. 测试系统的API接口,验证是否存在未经授权的API调用会导致业务流程跳跃漏洞。检查API的输入验证、授权验证和数据返回的完整性。 
    防御方法: 
  3. 在系统中的关键步骤都进行授权验证,避免关键业务逻辑仅前端校验; 
  4. 测试设计时,考虑到业务逻辑跳过漏洞,设计相关测试用例。

1.3.3 文件上传 

文件上传功能可能会成为安全漏洞的源头,通常发生在允许用户上传文件的应用程序中。如果上传功能没有得到正确的验证和处理,攻击者可能会上传恶意文件,导致多种严重安全风险,如执行任意代码、窃取敏感信息、安装恶意软件: 
测试方法: 

  1. 修改HTTP请求包中的Content-Type字段,尝试用不同的MIME类型上传文件; 
  2. 路径字符串以特定的字符(如0x00,即NULL字符)结束,系统可能会错误地认为路径已经结束,而忽略后面的部分,可以尝试使用路径截断技术(如0x00,%00)来绕过服务端的路径检测。 
  3. 禁用或修改前端JavaScript代码,尝试上传通常被禁止的文件类型,尝试上传具有文件特征的脚本文件; 
  4. 使用大小写变换、畸形扩展名、特殊文件名等方式尝试绕过扩展名检测。 
    防御方法: 
  5. 使用白名单机制,只允许特定的文件类型,并限制文件大小; 
  6. 检查文件的MIME类型和实际内容,确保它们匹配且不包含潜在的恶意代码; 
  7. 确保上传目录不允许执行脚本,防止Web Shell攻击; 
  8. 上传后,更改文件名和路径,防止直接访问导致的安全问题; 
  9. 做好前后端文件校验工作:前端初步校验,后端严格校验,避免被绕过。 

1.3.4 登录安全性验证 

判断当前用户登录环境是否安全,通过登陆限制、多因素认证等方式保障用户登陆安全。 
测试方法:修改登录环境查看是否触发异常登录流程:例如使用新手机登录,使用不常用的ip地址登录等; 
防御方法: 

  1. 添加登录限制机制,对有风险的账户通过暂时封禁,通过邮件/短信等方式通知用户账户风险; 
  2. 增加登录安全设计逻辑。如验证用户当前登录机型、IP等。发现异常登录则触发安全登录流程。 

1.4输入输出未过滤 

输入输出未过滤漏洞指的是Web应用程序在处理用户输入数据时未能进行适当的验证、过滤或转义,导致潜在的安全隐患。这种漏洞可能允许攻击者执行恶意代码、获取敏感信息或进行其他恶意行为。常见的输入输出未过滤漏洞包括:SQL注入、XSS、命令注入、XPATH注入等。 

1.4.1 SQL注入 

SQL注入是常见的网络攻击手段,它利用程序的安全漏洞,允许攻击者在数据库查询中插入恶意SQL代码,从而进行各种操作,这种攻击可能会导致非常严重的后果,SQL注入的思路有很多种,例如联合查询、错误盲注、时间盲注等。 
测试方法: 

  1. 通过Burp suite工具收集请求信息,使用sqlmap等工具扫描; 
  2. 手工注入测试:容易出现注入漏洞的场景:可直接输入的表单、分页和排序、搜索、URL传参、HTTP请求提交的数据; 
    防御方法: 
  3. 使用参数化查询,确保输入的内容被视为参数值,而不是SQL代码的一部分; 
  4. 限制用户输入,只接受预期的数据类型和格式; 
  5. 为数据库账户分配执行必要操作的最小权限; 
  6. 避免在错误消息中泄露敏感信息,如数据库结构或系统配置; 
  7. 使用自动化工具定期扫描发现SQL注入漏洞。 

1.4.2 跨站脚本 

XSS是一种常见的网络安全漏洞,现在大部分XSS漏洞都会被阻止了,但一些经验较浅的开发人员还是会忽略相关问题: 
测试方法: 

  1. 在Web应用程序的输入点,如表单、URL参数、HTTP头等位置,尝试注入恶意脚本代码,检查页面是否允许这些输入;对服务器返回的响应内容进行审查,查看是否将注入的恶意代码原样输出,从而判断是否存在XSS漏洞; 

  2. 使用自动化扫描工具:如OWASP ZAP、Burp Suite等进行XSS漏洞扫描。 
    防御方法: 

  3. 对所有插入到HTML、JavaScript、CSS或URL的输出进行适当的编码或转义,以防止恶意脚本的执行; 

  4. 对用户输入进行严格的验证和过滤,确保不包含恶意脚本。使用白名单方法,只允许已知安全的输入; 

  5. 对URL跳转参数进行验证和过滤,避免攻击者利用跳转机制执行XSS攻击。 

2、WEB-JAVA应用安全测试实践方法

在讨论安全测试实践时,我们经常会遇到一些挑战: 

  • 安全测试需要掌握理论知识,有不低的学习成本,普通测试人员没接触过,不知该如何入手。 
  • 不能很好的将安全测试工作与日常测试工作结合,需要额外投入人力去做专项测试。 

为了解决这些问题,我们将安全测试工作分层,难度较大的部分指派给有经验的同事来做,并由他们设计对应测试用例,交于测试人员协作执行:这样大家就可以实际操作,通过实践来引导知识学习,在发现/解决问题的过程中提升安全测试能力。降低了测试门槛,避免了枯燥的知识学习,无法在项目中运用的尴尬。 

2.1 存量业务安全测试具体落地方式 

项目阶段:项目立项,确保团队协作和资源的合理分配。 

工作计划:为了更好的执行测试工作,将测试工作分为渗透测试、自动化工具扫描和常规安全测试三个层次 

  • 专项人员负责设计安全测试测试用例,安全测试知识培训讲解等工作,测试执行过程中则专注于渗透测试和安全测试工具扫描等; 
  • 其他测试成员负责协助常规功能相关安全测试用例执行; 

测试筹备:业务安全测试与功能测试最主要的区别在于测试思路:例如输入框测试,功能测试主要考虑等价类、边界值等场景,安全测试则会考虑特殊语句符号是否存在数据拼接,异常展示等;业务的安全测试属于功能测试内容的拓展。存量业务安全测试具体筹备步骤如下: 

  • 由专项人员给大家讲解常见的安全问题,介绍问题类型和基本测试方法 
  • 编写安全测试指引文件:根据前文介绍过的信息泄露、猜解漏洞等内容制定对应的检测项目,覆盖场景,检测方法等 
  • 准备安全测试基线用例:可参考前文的漏洞知识,编辑安全基线测试用例 
  • 组织用例评审,确保成员能准确理解用例内容,并能够执行相关测试用例 
  • 梳理当前的业务功能,输出存量业务功能列表 

测试计划: 

  • 对指定业务功能指派需要执行的安全测试用例:例如 
    a. 所有输入框都需要进行XSS和SQL注入测试; 
    b. 登录相关功能需要测试账号密码安全性等内容; 
    c. 用户数据相关业务都需要考虑越权等场景; 
  • 制定测试时间计划,及时评估项目风险 

测试执行:参考工作分层模块,将执行任务分为两个部分,并通过沟通和抽样检查,确保测试质量和完整性 

  • 专项人员专注于关键节点的渗透测试和自动扫描工具应用; 
  • 其他测试成员按照功能划分,执行筛选出的测试用例; 
  • 安全问题进行记录,并推动问题修复和回归测试; 

问题分析总结: 

  • 对问题归类分析,对出现BUG较多的场景重点关注,并安排后续测试任; 
  • 总结过程执行过程中遇到的问题,并改进测试方法和测试用例; 

知识分享: 

  • 搭建局域网靶机,通过一系列的“Top 10安全漏洞”实战课程,帮助团队成员深入理解并掌握常见的安全漏洞原理、利用方法及其防御技术,提高团队综合安全测试能力; 

成果检验: 

  • 为了检验我们测试过程有效性,和进一步提高系统安全性,我们找了第三方服务商对我们参与了安全测试和未参与安全测试的功能模块进行了整体渗透测试。执行过安全测试的模块质量显著好于未执行测试的模块。 

2.2 过程中的问题及处理方法 

1)部分用例不知道怎么操作: 

  • 文件上传漏洞,不知道该怎么操作上传异常文件,也不知道如何生成一个异常文件; 
  • Sql注入的具体操作方式和对应执行测试点不清楚:例如是在输入框拼接参数,还是URL拼接参数; 
  • 对XSS的各种payload类型不知如何测试; 

解决方案:通过搭建靶机演示操作,向大家展示相关测试操作步骤,加深用例理解;例如XSS不同payload的测试效果及防范方式的绕过方法; 

2)部分用例概念不清晰: 

  • 哪些文件属于敏感文件,敏感信息 
  • 哪些口令算弱口令 
  • 什么是SSRF 

解决方案:组织会议明确组织会议明确组织会议明确相关概念,规范测试标准:例如规定敏感信息范围。 

3)部分用例测试范围不好界定: 

  • 业务数据泄露:具体什么数据属于泄露 
  • 邮件转发:什么样的场景需要考虑转发 
  • 未验证URL跳转:哪些情况需要测试URL跳转 
  • SSRF:哪些情况需要测试SSRF 
  • 安全测试要求和需求冲突:例如token失效时间判断 

解决方案:添加用例范围界定指引,优化相关测试用例:例如列出SSRF可能出现的场景。 

02

结语

通过这种结构化和分层次的方法,可以确保安全测试工作的系统性和高效性,同时促进团队成员的技能提升。另外,安全测试不是一次性的,而是一个与软件开发生命周期各阶段紧密相连的、持续演进的过程。需要在技术、流程和文化上进行全面的投入和不断的改进,以适应不断变化的网络威胁和新业务需求。 

那么【持续交付中的安全测试】要怎么做?让我们带着疑问去探索,期待下次与大家分享。