QA安全培训内容

PAGEQA安全培训内容2026年

目录一、安全测试类型全方位对比：四种方案，优缺点一览（一）黑盒测试：模拟黑客视角，不了解内部代码（二）白盒测试：深入代码，发现隐藏漏洞（三）灰盒测试：兼顾内外，更高效（四）动态应用安全测试（DAST）：运行时检测，模拟真实攻击二、Web应用安全测试：常见漏洞及测试方法精讲（一）XSS跨站脚本攻击测试：从入门到精通（二）SQL注入测试：数据库安全的生死线三、移动应用从App到API的关键防线（一）App本地安全测试：数据存储与反编译（二）移动API安全测试：比WebAPI更危险四、API接口被忽视的重灾区（一）越权访问测试：水平越权与垂直越权（二）参数篡改与逻辑绕过测试：API的命门五、CI_CD流程中的将安全左移（一）代码提交阶段：自动化安全扫描（二）部署上线阶段：持续安全监控

73%的QA测试人员，在上线前一周才意识到安全测试覆盖不足，导致项目延期甚至回滚。你是否也曾经历过那种抓狂的感觉，明明功能测试都通过了，结果上线后却被安全漏洞重重打击？这种痛苦，我太懂了。作为一名在QA领域摸爬滚打了8年的老兵，我见过太多因安全问题导致的惨痛教训。很多团队认为安全测试是锦上添花，或者仅仅依赖于渗透测试，却忽略了在整个测试周期内构建一套完善的QA安全体系。这份《QA安全培训内容》，将为你提供一套实操性极强、可落地执行的安全测试方案，帮助你从源头降低安全风险，提升产品质量，让你不再为上线后的安全问题提心吊胆。这份文档，不是简单的理论堆砌，而是基于大量实战经验总结，涵盖了Web应用、移动应用、API接口等多种常见场景的安全测试方法，以及如何将安全测试融入到CI/CD流程中。看完这份文档，你将能够：构建一套完整的QA安全测试流程，明确每个阶段的测试目标和方法；掌握常见的Web安全漏洞（如XSS、SQL注入、CSRF等）的测试技巧，并学会利用自动化工具进行漏洞扫描；提升团队的安全意识，培养良好的安全编码习惯，从根本上减少安全漏洞的产生；学会编写高质量的安全测试用例，并对测试结果进行有效的分析和报告。现在，我们从最基础的开始——安全测试类型横评，选择最适合你团队的方案。●一、安全测试类型全方位对比：四种方案，优缺点一览安全测试并非只有一种形式，不同的测试类型适用于不同的场景和目标。选择合适的测试类型，是构建有效安全测试体系的第一步。我们将从以下四种常见的安全测试类型入手，进行全方位的对比分析：黑盒测试、白盒测试、灰盒测试、动态应用安全测试。黑盒测试：模拟黑客视角，不了解内部代码黑盒测试，顾名思义，测试人员对被测系统的内部结构和代码一无所知，仅仅通过输入和输出进行测试。就像一个黑客，试图通过各种手段来发现系统的漏洞。这种测试方式最贴近真实攻击场景，因为真正的黑客也不会知道你的代码长什么样。我见过太多人忽视黑盒测试的重要性，结果上线第一天就被黑客教做人。比如去年8月，我认识的一位QA负责人小李，他们团队负责一个电商大促项目，时间紧任务重，只做了功能测试和简单的冒烟测试。上线后第三天，就发现大量用户账户被盗，优惠券被恶意领取，直接损失超过50万元。事后排查才发现，登录接口存在严重的暴力替代方案漏洞，黑客通过自动化脚本撞库攻击，轻松获取了几千个用户账号。如果他们在上线前用黑盒测试模拟黑客攻击，这个漏洞早就能被发现。黑盒测试的核心在于模拟真实攻击者的思维，你需要把自己想象成一个不择手段要搞垮系统的坏人。目标就是发现系统外部可见的安全漏洞，如XSS、SQL注入、CSRF、暴力替代方案、越权访问等。具体措施包括使用漏洞扫描工具、手动构造攻击Payload、进行模糊测试等。责任人通常是安全测试工程师或具备安全思维的QA工程师。建议在项目每个迭代周期都执行黑盒测试，不要等到最后才集中测试。验收标准要明确：必须发现并修复所有高危漏洞，中危漏洞需要评估风险后决定是否修复。时间表可以安排在迭代功能测试完成后、上线前进行，每次迭代后必须提交详细的测试报告，包括发现的漏洞列表、风险等级、修复建议。预算方面主要是人力成本，可以使用OWASPZAP、BurpSuite社区版等免费工具起步。风险预案必须考虑到，黑盒测试可能无法发现隐藏在代码深处的业务逻辑漏洞，需要结合灰盒或白盒测试补充。另外，黑盒测试可能会遗漏一些需要特定权限才能触发的漏洞，所以测试用例设计要全面。白盒测试：深入代码，发现隐藏漏洞白盒测试，又称为透明盒测试，测试人员可以访问被测系统的源代码，并了解其内部结构。通过对代码的静态分析和动态调试，可以发现隐藏在代码深处的安全漏洞。说白了，就是拿着放大镜一行行看代码，找出里面的安全隐患。我见过太多团队把白盒测试当成开发人员的额外负担，结果付出了惨痛代价。前年3月，某金融科技公司的一个支付模块上线，因为开发团队为了赶进度，白盒测试流于形式，只是简单走了个过场。结果上线一周后，安全团队通过代码审计发现，支付接口存在逻辑漏洞，攻击者可以绕过金额校验，用1分钱购买任意金额的商品。这个漏洞在代码层面非常明显，就是一个简单的if判断写错了，但因为没人认真做白盒测试，导致公司差点损失上百万。最后还是通过日志回溯，发现有两个用户已经利用了这个漏洞，总共造成了3.8万元的实际损失。白盒测试的目标是发现代码层面的安全漏洞，如逻辑错误、缓冲区溢出、代码注入、硬编码密码、不安全的加密算法等。具体措施包括代码静态分析、人工代码审查、单元测试覆盖安全场景等。责任人应该是开发工程师和安全测试工程师共同承担，开发要写安全的代码，安全测试人员要具备代码审计能力。时限要求是代码提交后立即进行，最好集成到CI流程中，每次代码提交都自动触发静态代码扫描。验收标准是修复所有代码层面的高危漏洞，中危漏洞需要在代码评审中讨论。时间表应该是代码提交后立即执行，每次代码提交后都要生成测试报告，作为代码合并的准入条件。预算方面主要是开发人员的时间成本，可能需要购买Fortify、Checkmarx等商业代码静态分析工具，年费用大概在20到50万之间。风险预案必须考虑到，白盒测试需要对代码有深入的理解，对开发人员的技术水平要求较高。如果开发团队不重视安全，白盒测试的效果会大打折扣。还有一个现实问题是，白盒测试往往会被开发抵触，觉得你在挑毛病，所以推行时需要高层支持和制度保障。灰盒测试：兼顾内外，更高效灰盒测试，介于黑盒测试和白盒测试之间，测试人员对被测系统的部分内部结构和代码有所了解。通过对系统接口、数据结构、配置文件等信息的分析，可以更高效地发现安全漏洞。这种测试方式结合了黑盒和白盒的优点，既有一定的内部信息，又保留了外部攻击的视角。我见过太多人忽视灰盒测试的价值，非要走极端，要么纯黑要么纯白，结果效率低下。2022年11月，我辅导的一个创业团队，他们的QA负责人老王是个偏执狂，坚持要做彻底的白盒测试，要求100%代码覆盖率。结果一个中等复杂度的项目，安全测试就花了整整三周时间，严重拖慢了上线进度。后来我建议他改成灰盒测试，只关注核心的支付、用户、订单模块的代码逻辑，其他模块用黑盒方式快速扫一遍。改版后，同样的项目，安全测试时间缩短到一周，而且发现的漏洞数量反而更多，因为测试精力更集中了。灰盒测试的目标是在了解部分内部结构的基础上，发现系统外部可见和代码层面的安全漏洞。具体措施包括分析接口文档、查看数据库结构、了解框架配置、进行半自动化的漏洞扫描等。责任人通常是资深的安全测试工程师，需要具备一定的开发能力。时限建议安排在项目中期，在核心功能开发完成后、系统集成前进行。验收标准是发现并修复所有中高危漏洞。时间表是项目中期进行，每次测试后提交测试报告。预算主要是人力成本，可以使用一些开源的灰盒测试工具如Arachni、W3AF等。风险预案是灰盒测试需要测试人员具备一定的开发能力和安全知识，对人员要求较高。而且灰盒测试的度不好把握，了解太多就成了白盒，了解太少就成了黑盒，需要测试人员有丰富的经验和判断力。动态应用安全测试（DAST）：运行时检测，模拟真实攻击DAST，是动态应用安全测试的缩写，它是一种在应用程序运行时进行的黑盒测试。DAST工具会模拟各种攻击场景，对应用程序进行扫描和测试，从而发现安全漏洞。简单说就是让你的系统跑起来，然后用各种攻击手法去试探它。我见过太多团队把DAST当成万能药，觉得买个工具就万事大吉，结果误报漏报一大堆。前年6月，某互联网公司的测试负责人小张，花重金买了一套商业DAST工具，一年费用40万。上线前扫描了一遍，工具报了200多个漏洞，团队花了整整两周时间去验证，结果发现80%都是误报，要么是测试环境数据问题，要么是工具规则太严格。更严重的是，有一个高危的越权漏洞，因为工具没有覆盖到业务流程，结果漏报了，上线后被白帽子发现，公司不得不发漏洞悬赏。DAST的目标是发现应用程序在运行时存在的安全漏洞，如XSS、SQL注入、CSRF、文件上传漏洞等。具体措施是使用DAST工具对运行中的应用进行自动化扫描，结合手动测试进行验证。责任人应该是安全测试工程师。时限是项目上线前，必须完成DAST扫描。验收标准是通过DAST工具扫描，发现并修复所有高危漏洞。时间表是项目上线前进行，每次上线前都要执行扫描。预算主要是DAST工具的购买和维护成本，商业工具每年20万到80万不等，开源工具可以节省成本但需要投入人力维护。风险预案必须考虑到，DAST工具可能会产生大量误报，需要人工验证，这会消耗大量时间。另外DAST工具无法发现代码层面的逻辑漏洞，需要配合SAST（静态应用安全测试）使用。还有一点很重要，DAST扫描可能会影响测试环境的性能，需要在业务低峰期执行。●二、Web应用安全测试：常见漏洞及测试方法精讲Web应用安全是QA安全测试的重中之重。常见的Web安全漏洞包括XSS、SQL注入、CSRF、命令注入、文件上传漏洞、越权访问等。这些漏洞就像定时炸弹，随时可能被引爆。接下来，我们将重点讲解XSS和SQL注入的测试方法。有人会问，XSS和SQL注入到底是什么？XSS是指攻击者通过在Web页面中注入恶意脚本，来窃取用户的敏感信息；SQL注入是指攻击者通过在SQL语句中注入恶意代码，来篡改数据库中的数据。这两个漏洞占了所有Web安全漏洞的60%以上，是必须重点关注的。XSS跨站脚本攻击测试：从入门到精通XSS漏洞是最常见也是危害最大的Web漏洞之一。我见过太多QA觉得XSS很简单，不就是输入个脚本标签吗，结果测试不全面导致用户数据泄露。前年9月，某社交平台的QA团队，在测试留言功能时，只在发送消息的输入框里测试了XSS，没考虑到昵称、个性签名、甚至头像文件名都可能成为XSS的输入点。上线后，黑客在昵称中插入了恶意脚本，当其他用户查看他的主页时，脚本自动执行，窃取了几十万的用户登录凭证。XSS测试的核心是找到所有用户可控的输入点，然后构造各种Payload进行测试。具体方法如下：第一步，输入点分析。要全面梳理所有用户可控制的输入点，包括搜索框、评论区、表单、URL参数、HTTP头、昵称、头像、文件上传文件名等等。我见过太多人只测最明显的输入框，忽略了那些隐藏的输入点。第二步，Payload构造。要构造包含恶意脚本的Payload，如<script>alert('XSS')</script>、<imgsrc=xonerror=alert('XSS')>、<svg/onload=alert('XSS')>等等。第三步，Payload注入。将Payload注入到输入点中，观察是否触发XSS漏洞。这里要注意，不要只看是否弹窗，要检查源码是否被原样输出。第四步，绕过防御。尝试绕过Web应用的XSS防御机制，如输入过滤、输出编码、CSP策略等。我见过太多WAF规则写得不严谨，用大小写、编码、注释等方式就能绕过。第五步，测试存储型XSS。不要只测反射型XSS，存储型XSS危害更大，数据会被永久存储在数据库中。要测试Payload是否被存储，以及其他用户访问时是否会触发。验收标准是：所有用户输入点都经过XSS测试，所有输出都经过HTML编码，CSP策略配置正确。时间表是每个迭代都要执行XSS测试。预算主要是人力成本。风险预案是XSS测试可能会影响业务数据，需要在测试环境进行，并且做好数据备份。SQL注入测试：数据库安全的生死线SQL注入是另一个高危漏洞，可以直接导致数据泄露甚至数据库被完全控制。我见过太多开发觉得自己用了ORM框架就万事大吉，结果因为不当使用还是导致了SQL注入。2022年7月，某在线教育平台的开发团队，用的是MyBatis框架，本来应该是安全的。但有个开发人员图方便，在搜索功能中使用了${}拼接SQL，而不是#{}参数化查询。QA测试时只测了正常搜索，没构造SQL注入Payload。上线后，黑客通过搜索框注入了恶意SQL，短短半小时就下载了全站50万用户的个人信息，包括姓名、电话、身份证号。SQL注入测试的关键是找到所有与数据库交互的输入点。具体方法如下：第一步，输入点分析。找到所有与数据库交互的输入点，如用户名、密码、搜索框、排序参数、分页参数、ID参数等。第二步，Payload构造。构造包含恶意SQL代码的Payload，如'OR'1'='1、1UNIONSELECTFROMusers--、admin'--等。第三步，Payload注入。将Payload注入到输入点中，观察是否触发SQL注入漏洞。要注意观察返回的错误信息、响应时间变化、页面内容变化等。第四步，数据库信息获取。尝试利用SQL注入漏洞获取数据库中的敏感信息，如用户名、密码、表结构、数据内容等。第五步，盲注测试。即使页面没有明显回显，也要测试盲注，通过时间延迟或布尔判断来确认漏洞。验收标准是所有数据库查询都使用参数化查询，没有字符串拼接SQL。时间表是每个迭代测试。预算主要是人力成本。风险预案是SQL注入测试可能会破坏数据库数据，必须在测试环境执行，并且做好数据备份和隔离。●三、移动应用从App到API的关键防线移动应用安全测试是很多人容易忽视的领域。很多人觉得移动App是运行在用户手机上的，比Web安全，这种想法大错特错。移动应用面临的安全威胁包括数据泄露、中间人攻击、反编译、二次打包、组件劫持等。我见过太多移动App因为安全问题被下架，甚至导致公司声誉受损。App本地安全测试：数据存储与反编译移动App在本地存储的数据很容易被攻击者获取。我见过太多App把敏感信息明文存储在SharedPreferences或者SQLite里，以为用户看不到就安全了。前年4月，某银行App被爆出安全漏洞，用户的登录密码、交易记录等敏感信息，明文存储在手机本地数据库里。安全研究员用一个简单的Root工具，就能导出所有数据，影响了几百万用户。这个App最后被应用商店下架，银行被罚款50万，相关负责人被处分。App本地安全测试要点：第一，检查数据存储。验证敏感数据是否加密存储，包括用户密码、token、个人信息、交易记录等。要检查SharedPreferences、SQLite、文件存储、日志输出等位置。第二，反编译测试。对App进行反编译，检查代码是否混淆，是否包含硬编码的密钥、密码、API接口地址等。我见过太多App把阿里云AccessKey硬编码在代码里，反编译后直接就能拿到。第三，组件安全测试。检查Activity、Service、BroadcastReceiver、ContentProvider是否配置了正确的权限，是否存在组件劫持风险。第四，键盘记录防护。测试App是否对自定义键盘进行了安全加固，防止键盘记录器窃取输入信息。验收标准是敏感数据必须加密存储，代码必须经过混淆，组件权限最小化。时间表是每个版本发布前测试。预算可能需要购买反编译工具如JEB、IDAPro等。风险预案是反编译测试可能涉及法律风险，需要获得公司授权。移动API安全测试：比WebAPI更危险移动App调用的API接口，往往比WebAPI更危险。因为很多移动API没有严格的速率限制，没有完善的认证机制。我见过太多移动API被恶意爬虫刷爆，导致服务器瘫痪。前年11月，某短视频平台的移动API被攻击者发现没有签名验证，攻击者用脚本批量调用视频上传接口，短时间内上传了几百万个垃圾视频，占满了存储空间，导致正常用户无法上传视频，平台宕机了整整6个小时，损失收入超过200万。移动API安全测试要点：第一，认证与授权测试。验证API是否需要进行身份认证，token是否有效，是否存在越权访问问题。移动App常用的token包括JWT、OAuth2.0等，要测试token是否可伪造、是否可刷新、过期时间是否合理。第二，速率限制测试。测试API是否有限制请求频率，防止暴力替代方案和爬虫攻击。我见过太多移动API没有速率限制，可以用脚本无限请求。第三，签名验证测试。测试API是否对请求参数进行签名验证，防止参数被篡改。很多移动App的签名算法写在客户端，容易被逆向替代方案。第四，数据加密传输测试。验证API是否使用HTTPS传输，是否校验SSL证书，防止中间人攻击。我见过太多App为了省事，忽略了SSL证书校验，导致数据被抓包窃取。验收标准是API必须有认证机制，必须限制请求频率，敏感参数必须签名，必须使用HTTPS并校验证书。时间表是每个迭代测试。预算主要是人力和时间成本。风险预案是API测试可能会影响线上服务，需要在测试环境进行。●四、API接口被忽视的重灾区API接口是现代应用的核心，但也是安全测试的重灾区。很多团队把API测试等同于功能测试，只要返回数据正确就完事了，这是极其危险的。API接口面临的安全威胁包括越权访问、批量获取数据、参数篡改、逻辑绕过等。我见过太多公司因为API漏洞导致数据泄露，后果不堪设想。越权访问测试：水平越权与垂直越权越权访问是API接口最常见的漏洞，分为水平越权和垂直越权。水平越权是指用户可以访问其他用户的资源，垂直越权是指低权限用户可以访问高权限资源。我见过太多QA只测正常流程，不测越权场景。前年2月，某医疗App的API接口存在水平越权漏洞，患者ID是顺序递增的数字。攻击者只需要遍历ID，就能获取其他患者的病历信息、检查报告、甚至身份证照片。这个漏洞影响了30万患者的隐私，最后被监管部门罚款100万，App被强制下架。越权访问测试方法：第一，识别资源ID。找到所有通过ID访问资源的API，如/user/info?userId=123、/order/detail?orderId=456等。第二，构造越权请求。用用户A的身份去访问用户B的资源，检查是否能成功访问。第三，测试垂直越权。用普通用户身份尝试访问管理员接口，用管理员身份访问普通用户接口看是否能降级访问。第四，测试未授权访问。不带任何认证信息直接访问API，检查是否可以访问。第五，批量获取测试。尝试用脚本批量遍历ID，看是否能批量获取数据。我见过太多API没有检测异常访问频率，导致数据被爬虫轻松爬走。验收标准是API必须校验用户身份和权限，资源ID必须做加密或随机化处理。时间表是每个迭代测试。预算主要是人力成本。风险预案是越权测试可能会误操作真实数据，必须在测试环境进行，并且做好数据隔离。参数篡改与逻辑绕过测试：API的命门API接口的参数是攻击者的主要目标，通过篡改参数可以实施各种攻击。我见过太多API没有对参数做签名验证，也没有做服务器端校验，导致被攻击者随意篡改。前年5月，某电商平台的下单API存在参数篡改漏洞，订单金额是在客户端计算后传给服务器的。攻击者用抓包工具修改了订单金额参数，把1000元的商品改成1元，成功下单并支付。这个漏洞导致公司在48小时内损失超过80万，因为有200多个订单被恶意篡改。参数篡改与逻辑绕过测试要点：第一，参数枚举测试。遍历所有API参数，包括隐藏参数、可选参数，测试不同参数值对返回结果的影响。第二，参数类型测试。修改参数的数据类型，如把字符串改成数字，把数组改成对象，看服务器是否能正确处理。我见过太多API因为类型转换错误导致崩溃或信息泄露。第三，参数边界测试。测试参数的边界值，如最大值、最小值、负数、超长字符串等。第四，业务逻辑绕过测试。尝试绕过正常的业务流程，如跳过支付步骤直接下单，跳过验证码直接登录等。第五，批量操作测试。测试API是否支持批量操作，如批量删除、批量查询，是否做了权限校验。我见过太多API批量操作接口没有做权限校验，导致用户可以批量操作别人的数据。验收标准是API必须在服务器端验证所有参数，敏感参数必须签名，业务流程必须防绕过。时间表是每个迭代测试。预算主要是人力成本。风险预案是参数测试可能会产生大量垃圾数据，需要在测试环境进行，并且定期清理数据。●五、CI_CD流程中的将安全左移传统安全测试都是在开发完成后进行，这种方式已经跟不上现代DevOps的节奏了。安全测试必须左移，融入到CI_CD流程中，在每个环节都嵌入安全检查。我见过太多团队把安全测试放在最后一环，结果发现问题时已经来不及了，要么延期上线，要么带着风险上线。前年8月，某云计算公司的产品因为安全扫描放在上线前一天，发现了一个高危漏洞，不得不推迟原定的新品发布会，直接经济损失超过500万，品牌损失不可估量。代码提交阶段：自动化安全扫描在代码提交阶段就要进行安全扫描，把安全问题扼杀在摇篮里。我见过太多团队代码评审只看业务逻辑，不看安全漏洞，结果把带病毒的代码合并到了主分支。2022年12月，某物流公司的一个开发人员在代码中硬编码了数据库密码，代码评审时没人注意。幸好后来在CI流程中加了静态代码扫描，在合并前发现了这个严重问题，不然后果不堪设想。代码提交阶段安全测试措施：第一，GitHooks预提交检查。在本地提交代码时，自动检查是否包含敏感信息，如密码、密钥、内网地址等。我见过太多人把密钥直接提交到Git仓库，结果仓库被公开后，黑客直接拿了密钥就把服务器给控制了。第二，静态代码分析。在CI流程中集成SonarQube、Fortify等工具，对每次提交的代码进行自动扫描。第三，依赖安全检查。使用OWASPDependency-Check等工具，检查项目依赖的第三方库是否存在已知漏洞。我见过太多项目因为引用了有漏洞的Fastjson版本，导致被远程代码执行。第四，代码评审安全checklist。建立代码评审的安全检查清单，包括