前言
支付系统，这个名词相信生活在当下社会的大家应该都不在陌生了吧，他时时刻刻充斥在我们的日常生活中，哪里有交易发生，哪里就有它的身影。
其实直白的来说，支付系统是扮演着连接消费者、商家、银行和其他金融机构之间的桥梁角色。
对于支付系统的质量保障活动自然也成为了金融行业中产品与项目阶段的重中之重，当然除了基础的功能测试之外，安全测试也是保障支付系统的另外一个重要的保障维度。
那么做为一个从事测试工作十多余年的测试管理者来说，在我眼中的境外支付系统安全测试是什么样的呢？今天就由我来为大家详细的介绍一下吧。
概念
其实境外的支付系统与我国的支付系统本质上没有特别的大的区别，但因为其本身的系统特性与产品业务定义，凡是涉及到资金交易的，系统本身就需要具备高度的安全性保障，比如说系统中用户的关键信息、支付信息、交易信息等等。
另外除了系统本身的安全性规范之外，还需要严格遵守对应行业监管机构的合规性要求，其中最有代表性的应该就是AML（反洗钱）和CFT（反恐怖融资）的规定了。
在开始我们的安全测试之旅之前，我们还需要搞清支付系统中的三个重要角色，消费者、商家、银行。
我们来简单的设想一下，比如消费者去某网站进行网上购物，那么他就必须拥有自己的账号并将支付方式、收货地址等信息进行自身的条件进行设定，当他挑选完对应商品后就会进行交易与支付行为，之后商家收到订单之后会进行后续的一系列操作，此时的付款资金还未到达商家的对应账户中，必须在交易双方都确认之后才会进行打款。
那么其中的银行看似好像全程没有出现的场景，但其实无论是你的资金支付还是对方的资金收款的背后都是银行在默默的进行着操作。
就像前面所说的那样，支付系统对于三者来说就是直接的连结桥梁。
-
对于消费者来说，它提供了多种支付方式，如信用卡支付、借记卡支付、电子钱包等，方便他们进行在线购物等操作；
-
对于商家来说，它为其提供了安全可靠的支付接口和结算服务，帮助其处理订单支付、减少商业风险；
-
对于银行来说，它更是其某些业务的重要组成部分，其中的资金流动、结算和清算也是其最最关键的关注环节。
说了那么多，其实就是像告诉大家，无论在做任何种类的测试活动之前，我们必须对其的业务流程与测试需求场景有一个形象且全面的理解。
基本思路
光说不练假把式，那么接下来我就来为大家介绍一下，在日常的工作中我们应该如何对境外的支付系统进行安全测试。
这里必须先说明，因为境外支付系统与国内的支付系统还是存在着明显的不同点，比如：
-
境外支付系统涉及到跨境支付，需要进行实时的不同币种的汇率换算；
-
国外与国内交易费率与手续费会有明显的不同；
-
监管部门的行业规范与要求会有所不同等等。
在测试活动中，测试团队一定是基于测试需求来开展对应的测试类型任务，那么在安全测试中亦是如此，下面我们就举一个简单的例子，来为大家演示一下安全测试开展的基础流程。
例如有以下一个需求与业务场景需要安全测试进行介入：
需求场景描述：基础用户在XXX跨境电商网站购买商品时，通过支付系统完成支付。
基于以上简易的业务场景描述，在集成测试已经完成的前提下，我们可以将上述场景根据现有功能的分类进行步骤的分割。
-
用户应能够注册账户并提供个人信息；
-
用户应能够登录账户并管理其支付方式；
-
用户应能够选择商品或服务进行支付，并提供相应的金额；
-
系统应安全地处理支付请求，并确保用户的敏感信息不被泄露；
-
支付过程中应使用指定的身份验证和授权机制，确保只有合法用户能够完成支付操作；
-
系统应记录支付交易的详细信息，包括支付金额、支付方式、时间戳、交易双方基础信息；
-
系统应及时通过指定方式向用户发送支付确认和交易完成的通知。
分割完成后我们就已经有了基本的功能点设计思路了，那么在安全测试中我们其实还需要了解另外一个概念，那就是该支付系统安全要求与预期行为。
何为安全要求呢？在安全测试中对应的需求方或架构师会对整体的支付系统进行安全评估与安全需求提出，当然这些要求也是严格按照行业与监管会的要求来进行指定的，硬要做个形容的话就类似与性能测试中需求方或产品给出的性能指标。
预期行为则是我们通常说的在安全测试执行的过程中系统应该如何正确的处理一些正常或异常的情况，当特定的测试场景中系统的响应和处理是否能够符合我们的预期，而简言之就类似我们测试用例中的预期结果。
根据以上分割后的测试功能项的基本思路，加之需求方给出的安全要求，结合两者，我们就可以列举出以上需要实行测试的业务场景的安全要求与预期行为：
用户鉴权与授权
-
被测对象需要支持多种类的身份验证方式（密码、短信验证码、生物特征等）；
-
基础用户登录鉴权失败后，系统是否有实施登录锁定机制，以防止爆破。
交易数据保护
-
敏感数据应该使用对应加密算法进行存储和传输（银行卡号、信用卡CVV码、电子签名等）；
-
被测对象需要实施对应的数据层级保护，确保只有指定的授权人员能够访问业务敏感数据。
防止支付欺诈和非法活动
-
被测对象是否具备反欺诈机制，能够识别异常和可疑交易模式，并采取相应措施（拒绝交易、触发RA等）；
-
被测对象是否具有实时交易和异常状况下的检测动作，以预防非法活动和欺诈行为的发生。
安全审计和监控
-
被测对象需要记录和保存所有支付交易的详细日志，包括交易相关的信息（交易时间、交易双方基础信息、交易方式、交易金额等）；
-
被测对象应该确保具有实时监控和警报机制，以检测异常活动、安全事件和攻击事件。
安全更新和漏洞管理
-
被测对象应该定期执行更新和维护相关应用软件和涉及到的组件，以修复已知的应用安全漏洞；
-
被测对象需要具备有漏洞管理流程，包括漏洞评估、修复和验证等执行阶段。
灾难恢复和业务连续性
-
被测对象应具备灾备计划，包括备份和恢复策略，以确保支付系统的高可用性和业务连续性；
-
被测对象必须经过容灾测试和恢复测试的检验，以验证恢复计划的有效性。
合规性和法规要求
-
被测对象应符合所在国家与所在地的相关的支付行业法规和标准（比如在美国，我们需要遵守PCI DSS）；
-
被测对象有义务提供合规性报告和证明，以验证符合当地法规和标准的要求。
一般来说，在我们根据业务场景与安全要求来分析与设计相关的预期行为时，都会有公司或行业内的安全领域专家的意见参与，通常他们给出的修改建议都是极其重要的，我们一定要在遵循对方的意志基础上对相应的内容进行修改与优化。
测试用例
在有了业务场景、安全要求、预取行为已经分割完的测试功能项之后，我们就可以开始着手设计相应的测试用例了，在安全测试中我们需要额外编写一些不同维度的测试用例，当然其中有一部分可以直接从之前的黑盒测试用例中复用。
安全测试的用例主要还是从我们熟知的认证、授权、验证、过滤、加密、异常处理、安全漏洞几个方面来设计验证内容。
之前整理出的预期行为就是我们最好的测试用例编写大纲，此处则根据每个团队的风格与测试规范来进行对应的用例设计了，就没有什么特别好介绍的了。
测试执行
当我们的被测对象具备了安全测试的条件之后，我们就可以根据各自的测试用例来对其进行各个维度的测试验证，这里我为大家简单的介绍几种相关的安全测试维度。
用户鉴权与授权
安全测试中，我们一般都会从最基础的要素开始测试验证，用户最为所有业务的发起者，自然首当其冲。
在支付系统中，用户的功能与安全性自然依托与其严格分层的用户权限，所有的界面功能都是根据角色或权限来进行控制的。
所以用户鉴权与授权必然是用户层面安全测试的重头戏。那么在这个维度，我们就需要确认用户鉴权的过程是由哪些因素组成的。
比如有些系统它需要你进行复合认证，不单单是用户名+密码的组合，它需要你通过用户名+密码+手机验证码或者生物特征码的多重组合。反例自不用多提，大家顺着这个思路继续场景的交叉组合即可。
另外关于系统的登录限制功能也是我们需要重点关注的点，比如限制登录次数、账号锁定等，被测系统一般都会有这样的机制，一是用来防止暴力破解与恶意登录操作，二是降低不必要的服务器资源开销。
安全测试中的鉴权验证方法会与黑盒有些不同，比如验证用户鉴权的时候，不单单要关注功能的正确性，更多的则是要观察数据的传输方式与加密安全，检查是否有明文传输与落数据等情况存在。当然除此之外，比如密码的找回与重置、策略等都是不可忽略的一些重要测试对象，碍于篇幅这里就不展开细说了。
其实授权也是同理，当我们的鉴权动作完成后，用户必定是登录到对应的业务页面了。那么此时我们就需要观察与验证系统是否能正确限制用户对敏感操作和数据的访问权限，根据各自真实业务的不同，自会将不同的用户分为不同的等级权限或角色。
比如账户信息、支付信息、各类附加功能信息是否可以根据权限进行正确隔离，比如通过直接修改URL，跳过授权业务步骤等操作，是否存在越权访问的漏洞，都是我们这一步的验证重点。
支付交易
安全测试下的支付交易，相比起黑盒测试下的相同测试对象，我们更应该关注其交易时的数据状态与安全、以及如何防止支付欺诈、篡改信息、支付凭证的校验等方面。
对于交易时的数据加密，我们在安全测试中也可以通过多种手段来进行必要的测试验证，你所负责的被测对象所用的是什么类型的传输加密算法与协议，这个在系统设计或实现的阶段就找研发团队的小伙伴来确认好并进行必要的加密体系业务学习。
这里有一个很重要的点，那就是所用的加密体系的安全标准与其目前在行业内的最佳实践，因为这些加密体系都可以在搜索引擎上找到对应的资料，更不要提对应的行业官网了。
对于测试来说，特别是金融行业的测试，你如果对于各种加密体系与方法一知半解的话，那么其必将成为你在金融测试职业道路上的一块巨大绊脚石。这里就比较推荐NIST上的各类加密方法的一些具体解释，相信大家可以从中受益匪浅。
当然也不用看的太深，毕竟测试需要的是广度而非深度，业务你可以深耕，但技术就不一定了，比如之前有测试人员问我是否需要在安全测试中加入评估加密算法的安全性，我个人给出的答案是不一定，如果开发团队对于加密算法的本身适用性有一定的疑问，需要测试来验证说明的话，你可以去尝试着探索测试一下，但如果自身对于算法的特性原理、密钥长度、抗攻击能力、安全性证明没有一定的认知与实操经验的话，我是不推荐这么做的，这样不仅会把大把的时间和精力都浪费在自己不擅长的领域，更会忽略了其他支付业务功能点的保障工作，不失为得不偿失。
除了数据加密之外，我们在支付交易的安全测试中还需要就是被测对象的加密与协议的性能表现，当然这里的性能表现不是指一定要做对应的性能测试，而是在安全测试的时候关注一下每次交易时服务器的资源消耗与加解密的平均耗时。
这样做的好处在于既确保了交易过程中的数据传输稳定性，同时也为后期的性能测试的测试数据提供了重要的参考值。
还有一种行业中用的比较多的测试方法就是异常模拟，也被我们称为异常交易模拟，其实就是由测试人员去模拟各类异常的交易条件来进行各类交易并确认其异常处理正确性的一种测试手段。
站在被测对象的角度来说，一个支付系统如果遇到了错误的金额、超高的交易频率、异常的支付方式、交易断点信息篡改、风险交易方式等情况，在这样的前提下系统是否可以正确的处理以上的种种，正式我们做异常模拟的核心意义。
既然有了系统本身的异常模拟，那么来自于外部的恶意攻击自然是不能逃脱其外的。这一部分也是根据各自团队与产品的特性来有针对性的进行测试内容选择。
比较常见的测试手段有：恶意软件与病毒注入、DDoS攻击、密码爆破、数据注入与篡改、漏洞提权、劫持键盘记录、钓鱼网站邮件等方式。
这里需要提一下的是，在对支付系统做外部攻击模拟的时候，需要将测试环境进行必要的隔离，确保硬件与网络环境的相对隔离，如果有配置对应的硬件防火墙或安全网关当然是最好，就算没有也最好能独立在某个不互通的局域网内。
还有就是确保在测试的过程中将测试数据的用户权限限制在必要的最小值，这个有利于检测被攻击后的系统表现，确保数据的相对准确性。
安全漏洞
说到安全测试就一定离不开安全漏洞，这个也是安全测试领域中最最常见的测试内容之一。
我们在日常的工作中可以使用一些特定的工具来对被测对象、OS、甚至网络层来继续安全漏洞的检查。当然基于一些手工的安全漏洞检查也是很有必要的，单一的靠工具，那测试的效果也会具有片面性，最好是可以结合多款工具+手工检测的方式来多维度的对被测对象进行安全漏洞检测。
像我们团队，对于web架构的支付系统最常用的就是Nessus+OWASP ZAP的组合，不过其中的Nessus是有收费版本的，当然如果你的团队不希望在此方面投入太多的成本，可以考虑使用Nessus的Essentials版本。
一般我们在使用工具检测到对应的漏洞之后会先利用CVSS来对漏洞进行评级，在CVSS中会从三个维度（基础评分、Temporal评分、环境评分）来对漏洞进行打分，0为无风险，10为最高风险。
当对找到的漏洞有一个初步的评估之后，测试有开发人员就会将该漏洞进行利用，观察通过该漏洞可以进行哪些风险操作，而这些操作后产品的影响部分与风险内容将成为测试结果的一部分进行记录与留档。
而开发与安全专家则需要通过这些记录与测试结果来进一步分析漏洞可能被利用的潜在风险。考虑攻击者的动机和能力，以及漏洞可能导致的损失。
通过以上这些测试步骤之后，开发人员就可以根据提出的漏洞评级和风险分析的结果，提供相应的修复建议。
这里面涵盖了修复补丁、配置修改、安全设置调整等措施，而正是通过这些措施才得以让支付系统内的漏洞得以消除或减轻其所产生的影响。
测试人员来拿到对应的解决方案之后，则会像确认Bug修复一样，对OS或被测对象进行安全补丁的实施并观察实施后的被测对象表现。
这里需要提一下的是，安全补丁的建立分为字眼和三方两种，比如OS类的补丁就是三方，应用层面的补丁就是自研，试想一下windows的安全补丁也不可能是自家公司研发的对不对？
但是无论对于自研还是三方的补丁，产研团队最好是可以对应的补丁管理库或管理策略，用来有序的管理各类漏洞所产生的风险信息与对应解决补丁的方案、产品上线后的漏洞报告和补丁修复跟踪情况，这样的管理流程对于被测系统的长久安全与稳定性有着举足轻重的作用和意义，对于测试团队的线上问题跟踪与持续监控也是益处多多。
监控和安全日志
这里介绍的监控也称为监控测试，在安全测试领域中，一般来说监控测试的测试目的就是要确保我们的被测对象中的检测手段可以正确发挥效果，比如在出现各类攻击行为、异常活动和安全事件出现的情况下，我们的监控手段可以及时的发现与告警。
那测试人员在面对支付系统此类被测对象的监控测试时，我们就需要关注监控手段的正确配置和部署，监控规则、以及监控数据与日志。
这里呢，我就拿监控规则来举一个简单的例子。比如在一个境外支付系统中，我们需要对交易的金额进行监控，那么在监控系统中我们就可以添加对应的监控规则，通过设置阈值来规定某些特定的交易类型的交易金额上限，一旦超出阈值就会被判定为异常交易行为；有了阈值与特定交易类型，在此基础之上添加监控频率与监控范围，比如设置为以每天的间隔来进行监控并且指定特定国家与地区才适用这条规则。
综上所述，这条规则其实包含了多个条件，而条件的判定是逻辑或的关系，任何相关符合条件的异常交易（大额汇款、虚假交易、异常高频交易）都会被此规则辨认出来并进行实时告警。作为测试人员，在监控测试中我们需要保证的正是以上诸如此类的各种监控手段可以正确有效的发挥其应有的作用。
安全日志则是另一个可以有效确保支付系统在日常业务运行无误的重要因素之一。与之对应而应运而生的就是安全日志测试，针对这一特有的被测对象，该测试活动的主要目的就是确保在整体系统运行的过程中各类业务模块产生的安全日志是否被正确记录。
其中验证记录是否被正确记录的判断依据有三个主要因素：完整性、准确性和可审计性。
其中完整性和准确性自不必多介绍，就是字面的意思。
可审核性如果以简单粗暴的理解来解读的话，其实就是安全日志的整体日志格式与包含内容元素是否具有可以被安全团队或行业协会去审核的条件。
其中比较主要就是可被审核的格式，是否可以快速的被导入到指定的审查系统中去；另外就是日志内是否包含有维度明确的各类信息，较为主流的境外支付系统中的日志大致包括了用户、交易、安全事件、异常、各类评估信息等。
总结
碍于篇幅长度，今天我们只能介绍金融领域内安全测试的冰山一角，以上的这些内容是关于境外支付系统安全测试中的相关基础测试关注点与内容。在之后的文章中，我将会大家带来更多安全测试下的境外支付系统的实践经验与个人看法。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取