CN105447700A - 支付安全性的检测方法和装置 - Google Patents

Abstract

本申请公开了一种支付安全性的检测方法，包括：接收客户端发送的支付请求，并记录于支付请求相关的第一属性信息；向客户端发送安全代码，并通过安全代码采集第二属性信息；接收客户端的商业订单提交请求，并记录与商业订单提交请求相关的第三属性信息；以及根据第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测。本申请实施例的方法，使得支付服务商获取到的IP更加准确，从而支付服务商根据更加准确的IP即可对支付操作进行安全性检测，提高了准确率。本申请还公开了一种支付安全性的检测装置。

Description

支付安全性的检测方法和装置

技术领域

本申请涉及电子商务技术领域，尤其涉及一种支付安全性的检测方法和装置。

背景技术

目前互联网上存在一种钓鱼欺诈方式，即钓鱼网站自动在服务端创建商家网站的支付订单，之后将跳转到支付服务提供商页面的链接或表单在用户页面上触发提交或跳转，因为钓鱼网站会模拟用户想要支付的订单的页面，所以用户就会继续支付，导致上当受骗，遭到金钱损失。这类钓鱼网站的特征是创建商家网站的支付订单的IP(InternetProtocol，网络之间互连的协议)和用户在支付平台付款的IP不是同一个IP，但是正常用户操作应该是同一个IP。

相关技术中，为了避免钓鱼网站模拟用户想要支付的订单页面而导致用户上当受骗的问题，可通过商家网站先获取创建订单的IP，再通过表单将该IP提交给支付服务提供商的页面，以供支付平台判断是否有钓鱼风险。

但是，通过商家网站获取创建订单的IP再将其传给支付平台的方法存在以下缺陷：

1)商家网站取IP的逻辑会由于商家开发的技术或服务器架构中的负载均衡、反向代理等设备的存在导致无法统一，例如，有取到内网IP而导致大批支付失败，又如，如果取了标头header(服务器以HTTP(Hypertexttransferprotocol，超文本传输协议)协议传HTML(HyperTextMarkuplanguage，超级文本标记语言)资料到浏览器前所送出的字串)中的IP会被钓鱼网站恶意伪造header中的IP，绕过防控，因此，商家很难获取到准确的IP；

2)由于有些网络服务商的设备会因为某些业务需要配置了修改URL(UniformResourceLocator：统一资源定位器)中的IP值，如内容服务器，因此，IP在传输过程中可能会被网络服务商篡改，从而导致区域性的支付失败。

由于存在上述缺陷，所以会导致支付服务提供商接收到的商家网站提供的用户IP不准确，从而影响支付安全性的检测，可能会导致检测结果不准确。

发明内容

本申请的目的旨在至少在一定程度上解决上述的技术问题之一。

为此，本申请的一个目的在于提出一种支付安全性的检测方法。该方法使得支付服务商获取到的IP更加准确，从而支付服务商根据更加准确的IP即可对支付操作进行安全性检测，提高了准确率。

本申请的另一个目的在于提出一种支付安全性的检测装置。

为了实现上述目的，本申请一方面实施例的支付安全性的检测方法，包括：接收客户端发送的支付请求，并记录与所述支付请求相关的第一属性信息；向所述客户端发送安全代码，并通过所述安全代码采集第二属性信息；接收所述客户端的商业订单提交请求，并记录与所述商业订单提交请求相关的第三属性信息；以及根据所述第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测。

本申请实施例的支付安全性的检测方法，可先接收客户端发送的支付请求，并记录与支付请求相关的第一属性信息，之后可向客户端发送安全代码，并通过安全代码采集第二属性信息，然后接收客户端的商业订单提交请求，并记录与商业订单提交请求相关的第三属性信息，以及根据第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测，在整个支付检测过程中，通过支付服务商来获取用户IP，至少具有以下优点：(1)不会受到商家开发的技术或服务器架构中的负载均衡、反向代理等设备的影响，通过支付接口直接即可准确地获取到用户IP；(2)通过支付接口直接获取网络层IP，避免了IP在传输过程中会被网络服务商篡改的风险，从而使得支付服务商获取到的IP更加准确，从而支付服务商根据更加准确的IP即可对支付操作进行安全性检测，提高了准确率。

为了实现上述目的，本申请另一方面实施例的支付安全性的检测装置，包括：第一接收模块，用于接收客户端发送的支付请求，并记录与所述支付请求相关的第一属性信息；发送模块，用于向所述客户端发送安全代码；采集模块，用于通过所述安全代码采集第二属性信息；第二接收模块，用于接收所述客户端的商业订单提交请求，并记录与所述商业订单提交请求相关的第三属性信息；以及检测模块，用于根据所述第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测。

本申请实施例的支付安全性的检测装置，可通过第一接收模块接收客户端发送的支付请求，并记录与支付请求相关的第一属性信息，发送模块向客户端发送安全代码，采集模块通过安全代码采集第二属性信息，第二接收模块接收客户端的商业订单提交请求，并记录与商业订单提交请求相关的第三属性信息，检测模块根据第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测，在整个支付检测过程中，通过支付服务商来获取用户IP，至少具有以下优点：(1)不会受到商家开发的技术或服务器架构中的负载均衡、反向代理等设备的影响，通过支付接口直接即可准确地获取到用户IP；(2)通过支付接口直接获取网络层IP，避免了IP在传输过程中会被网络服务商篡改的风险，从而使得支付服务商获取到的IP更加准确，从而支付服务商根据更加准确的IP即可对支付操作进行安全性检测，提高了准确率。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是根据本申请一个实施例的支付安全性的检测方法的流程图；

图2是根据本申请一个实施例的通过安全代码采集第二属性信息的流程图；

图3是根据本申请一个实施例的支付安全性的检测方法的示意图；

图4是根据本申请一个实施例的支付安全性的检测装置的结构示意图；

图5是根据本申请另一个实施例的支付安全性的检测装置的结构示意图；

图6是根据本申请又一个实施例的支付安全性的检测装置的结构示意图；

图7是根据本申请再一个实施例的支付安全性的检测装置的结构示意图；

图8是根据本申请又另一个实施例的支付安全性的检测装置的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的支付安全性的检测方法和装置。

图1是根据本申请一个实施例的支付安全性的检测方法的流程图。如图1所示，该支付安全性的检测方法可以包括：

S101，接收客户端发送的支付请求，并记录与支付请求相关的第一属性信息。

其中，在本申请的实施例中，客户端可理解为商户网站。

具体地，客户端可在下单页面向支付平台发起JS(JavaScript，直译式脚本语言)支付请求，支付平台服务器在接收到客户端发送的支付请求之后，可获取并记录与该支付请求相关的第一属性信息，如网络层的IP，此处的IP可理解为在客户端下单页面时的IP。

S102，向客户端发送安全代码，并通过安全代码采集第二属性信息。

进一步的，在本申请的一个实施例中，在向客户端发送安全代码之前，该支付安全性的检测方法还可包括：提取支付请求中的Refer信息，其中，当Refer信息为空时将安全代码发送至客户端。

需要说明的是，在客户端下单页面时，下单页面发起的支付请求的来源，正常情况下应该是客户端的页面。因此，此时需判断该支付请求的来源是否为客户端的下单页面。具体地，可提取支付请求中的Refer信息，并记录该Refer信息所对应的值。其中，当Refer信息所对应的值为空时，可判断该支付请求可能是钓鱼网站创建的支付请求，此时，将安全代码发送至客户端以使客户端对钓鱼风险进行防控。

进一步的，在本申请的一个实施例中，在向客户端发送安全代码之前，该支付安全性的检测方法还可包括：通过混淆算法对安全代码进行混淆以生成混淆字符串以将混淆之后的安全代码和混淆字符串发送至客户端。其中，在本申请的实施例中，安全代码可理解为攻防JS代码。例如，可通过不可逆混淆算法对攻防JS代码进行混淆，生成混淆字符串，之后将混淆之后的攻防JS代码和混淆字符串发送至客户端。其中，可以理解，混淆字符串可起动防采集的作用。需要说明的是，在本申请的实施例中，混淆算法需要定期更新，或者安全代码进行实时混淆，且在定期更新或实时混淆时加入一个混淆字符串定义在安全代码的变量中，从而对安全代码起到保护作用。

在本申请的实施例中，如图2所示，通过安全代码采集第二属性信息具体可包括：客户端运行安全代码以使安全代码采集第二属性信息(S201)。之后，客户端对第二属性信息和混淆字符串进行签名以生成签名信息(S202)。然后，接收客户端发送的第二属性信息和签名信息，并根据签名信息对第二属性信息进行验证(S203)。应当理解，此处的混淆字符串为上述客户端接收的混淆字符串。

举例而言，在本申请的实施例中，第二属性信息以“location.host”、“parent.location.host”为例，在客户端接收到安全代码，并运行安全代码之后，可通过安全代码采集“location.host”、“parent.location.host”信息。之后，客户端可对“location.host”、“parent.location.host”和混淆字符串进行MD5(MessageDigestAlgorithm，消息摘要算法第五版)签名，以生成签名信息，如：MD5(location.host+混淆字符串+parent.location.host)，防止篡改。然后，可接收客户端发送的第二属性信息和签名信息，之后可对签名信息进行解密，根据解密后的签名信息对第二属性信息进行验证，以验证接收到的第二属性信息是否与解密后的签名信息中的第二属性信息一致。由此，保证第二属性信息的来源是客户端。

S103，接收客户端的商业订单提交请求，并记录与商业订单提交请求相关的第三属性信息。

其中，在本申请的实施例中，第三属性信息可为商业订单在支付平台收银台支付时的网络层IP地址。

S104，根据第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测。

其中，在本申请的一个实施例中，第一属性信息可为客户端发送支付请求时的第一IP地址，第二属性信息可为通过安全代码采集的客户端的第二IP地址，第三属性信息可为客户端发送商业订单提交请求时的第三IP地址。其中，在本申请的实施例中，如果第一IP地址、第二IP地址和第三IP地址中的任意两个不同，则判断为高危支付。

例如，第一属性信息为客户端发送支付请求时的网络层第一IP地址，第二属性信息为在通过安全代码采集第二属性信息之后返回客户端信息时的网络层第二IP地址，第三属性信息为客户端发送商业订单提交请求时的网络层第三IP地址，将第一IP地址、第二IP地址和第三IP地址进行对比，当第一IP地址、第二IP地址和第三IP地址中的任意两个不同时，可判断支付过程为高危支付，并可提醒用户有钓鱼风险。

在本申请的另一个实施例中，第一属性信息可为通过支付请求获取的第一域名信息，第二属性信息可为安全代码采集的第二域名信息。其中，在本申请的实施例中，如果第一域名信息与第二域名信息不同，则判断为高危支付。

例如，第一属性信息可为通过支付请求获取的Refer信息的域名location.host(即第一域名信息)，第二属性信息为安全代码采集客户端的域名“location.host”(即第二域名信息)，可将第一域名信息和第二域名信息进行对比，当第一域名信息和第二域名信息不同时，可判断支付过程为高危支付，并可提醒用户有钓鱼风险。

进一步的，在本申请的一个实施例中，该支付安全性的检测方法还可包括：记录接收到支付请求时的第一时间戳，并记录接收到第二属性信息时的第二时间戳；如果第一时间戳和第二时间戳之间的时间小于第一预设阀值，或者，第一时间戳和第二时间戳之间的时间大于第二预设阀值，则判断为高危支付，其中，第二预设阀值大于第一预设阀值。可以理解，第一预设阀值和第二预设阀值可根据实际情况设定。由此，为保证支付的安全性，需保证从接收到的支付请求开始直到接收到第二属性信息时为止，这个过程所花费的时间控制在正常合理的范围内。

本申请实施例的支付安全性的检测方法，可先接收客户端发送的支付请求，并记录与支付请求相关的第一属性信息，之后可向客户端发送安全代码，并通过安全代码采集第二属性信息，然后接收客户端的商业订单提交请求，并记录与商业订单提交请求相关的第三属性信息，以及根据第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测，在整个支付检测过程中，通过支付服务商来获取用户IP，至少具有以下优点：(1)不会受到商家开发的技术或服务器架构中的负载均衡、反向代理等设备的影响，通过支付接口直接即可准确地获取到用户IP；(2)通过支付接口直接获取网络层IP，避免了IP在传输过程中会被网络服务商篡改的风险，从而使得支付服务商获取到的IP更加准确，从而支付服务商根据更加准确的IP即可对支付操作进行安全性检测，提高了准确率。

为了使得本领域的技术人员更加地了解本申请，下面可举例说明。

举例而言，如图3所示，以客户端为商户网站为例，首先，商户网站可通过商业页面发起JS请求(即支付请求)。支付平台可接收到该JS请求(S1)，并获取到该商户网站在下单页面时的网络层IP1，并可将IP1记录到会话session中(S11)，之后可记录JS请求中的Refer1到session，并通过Refer1的值来判断是否需要向商户网站发送攻防JS代码；当Refer1的值为空时，向商户网站发送攻防JS代码(S12)，同时获取接收到支付请求时的当前时间戳1(即第一时间戳)(S13)，并记录到session，之后可通过混淆算法将混淆之后的攻防JS代码返回到商户网站，即返回不可逆混淆的“js+cookie(sessionid)”(S14)。支付平台向商户网站返回JS+cookie(S2)，通过攻防JS代码可获取location.host(S21)，获取parent(S22)，获取攻防JS代码自带的混淆字符串(S23)，之后对location.host、parent和混淆字符串这三个字符串进行MD5签名以得到签名信息(S24)，之后通过get提交location.host、parent和签名信息到支付平台(S25)。支付平台接收到商户网站返回的验证字符串(S3)，同时获取此时的网络层IP2(S31)，并获取当前时间戳2(即第二时间戳)，并将其记录到session(S32)，之后解密被加密的字符串以取到location.host1和parent.location.host2(S33)。当支付平台接收到商业订单提交请求时(S4)，支付平台获取此时的网络层IP3(S41)，之后，取出session中的IP1、Refer1、时间戳1、时间戳2、IP2、location.host1、parent.location.host2和IP3(S42)，之后可根据这些数据来综合判断用户付款时是否安全(S43)。

为了实现上述实施例，本申请还提出了一种支付安全性的检测装置。

图4是根据本申请一个实施例的支付安全性的检测装置的结构示意图。如图4所示，该支付安全性的检测装置可以包括：第一接收模块10、发送模块20、采集模块30、第二接收模块40和检测模块50。

具体地，第一接收模块10可用于接收客户端发送的支付请求，并记录与支付请求相关的第一属性信息。其中，在本申请的实施例中，客户端可理解为商户网站。

更具体地，客户端可在下单页面向支付平台发起JS(JavaScript，直译式脚本语言)支付请求，第一接收模块10在接收到客户端发送的支付请求之后，可获取并记录与该支付请求相关的第一属性信息，如网络层的IP，此处的IP可理解为在客户端下单页面时的IP。

发送模块20可用于向客户端发送安全代码。采集模块30可用于通过安全代码采集第二属性信息。

进一步的，在本申请的一个实施例中，如图5所示，该支付安全性的检测装置还可包括提取模块60。提取模块60可用于提取支付请求中的Refer信息，其中，发送模块20具体用于在Refer信息为空时将安全代码发送至客户端。

需要说明的是，在客户端下单页面时，下单页面发起的支付请求的来源，正常情况下应该是客户端的页面。因此，此时需判断该支付请求的来源是否为客户端的下单页面。具体地，提取模块60可提取支付请求中的Refer信息，并记录该Refer信息所对应的值。其中，当Refer信息所对应的值为空时，可判断该支付请求可能是钓鱼网站创建的支付请求，此时，发送模块20将安全代码发送至客户端以使客户端对钓鱼风险进行防控。

进一步的，在本申请的一个实施例中，如图6所示，该支付安全性的检测装置还可包括生成模块70。生成模块70可用于通过混淆算法对安全代码进行混淆以生成混淆字符串。在本申请的实施例中，发送模块20还可用于将混淆之后的安全代码和混淆字符串发送至客户端。其中，在本申请的实施例中，安全代码可理解为攻防JS代码。

例如，生成模块70可通过不可逆混淆算法对攻防JS代码进行混淆，生成混淆字符串。发送模块20可将混淆之后的攻防JS代码和混淆字符串发送至客户端。其中，可以理解，混淆字符串可起动防采集的作用。需要说明的是，在本申请的实施例中，混淆算法需要定期更新，或者安全代码进行实时混淆，且在定期更新或实时混淆时加入一个混淆字符串定义在安全代码的变量中，从而对安全代码起到保护作用。

如图4所示，第二接收模块40可用于接收客户端的商业订单提交请求，并记录与商业订单提交请求相关的第三属性信息。其中，在本申请的实施例中，第三属性信息可为商业订单在支付平台收银台支付时的网络层IP地址。

如图4所示，检测模块50可用于根据第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测。

其中，在本申请的一个实施例中，第一属性信息为客户端发送支付请求时的第一IP地址，第二属性信息为通过安全代码采集的客户端的第二IP地址，第三属性信息为客户端发送商业订单提交请求时的第三IP地址，其中，检测模块50可具体用于在第一IP地址、第二IP地址和第三IP地址中的任意两个不同时，判断为高危支付。

例如，第一属性信息为客户端发送支付请求时的网络层第一IP地址，第二属性信息为在通过安全代码采集第二属性信息之后返回客户端信息时的网络层第二IP地址，第三属性信息为客户端发送商业订单提交请求时的网络层第三IP地址，检测模块50可将第一IP地址、第二IP地址和第三IP地址进行对比，当第一IP地址、第二IP地址和第三IP地址中的任意两个不同时，可判断支付过程为高危支付，并可提醒用户有钓鱼风险。

在本申请的另一个实施例中，第一属性信息为通过支付请求获取的第一域名信息，第二属性信息为安全代码采集的第二域名信息，其中，检测模块50可具体用于在第一域名信息与第二域名信息不同时，判断为高危支付。

例如，第一属性信息可为通过支付请求获取的Refer信息的域名location.host(即第一域名信息)，第二属性信息为安全代码采集客户端的域名“location.host”(即第二域名信息)，检测模块50可将第一域名信息和第二域名信息进行对比，当第一域名信息和第二域名信息不同时，可判断支付过程为高危支付，并可提醒用户有钓鱼风险。

进一步的，在本申请的一个实施例中，如图7所示，采集模块30可包括接收单元31和验证单元32。接收单元31可用于接收客户端发送的第二属性信息和签名信息，其中，客户端运行安全代码以使安全代码采集第二属性信息，客户端对第二属性信息和混淆字符串进行签名以生成签名信息。验证单元32可用于根据签名信息对第二属性信息进行验证。应当理解，此处的混淆字符串为上述客户端接收的混淆字符串。

举例而言，在本申请的实施例中，第二属性信息以“location.host”、“parent.location.host”为例，在客户端接收到安全代码，并运行安全代码之后，可通过安全代码采集“location.host”、“parent.location.host”信息。之后，客户端可对“location.host”、“parent.location.host”和混淆字符串进行MD5(MessageDigestAlgorithm，消息摘要算法第五版)签名，以生成签名信息，如：MD5(location.host+混淆字符串+parent.location.host)，防止篡改。然后，接收单元31可接收客户端发送的第二属性信息和签名信息，验证单元32可对签名信息进行解密，根据解密后的签名信息对第二属性信息进行验证，以验证接收到的第二属性信息是否与解密后的签名信息中的第二属性信息一致。由此，保证第二属性信息的来源是客户端。

进一步的，在本申请的一个实施例中，如图8所示，该支付安全性的检测装置还可包括记录模块80。记录模块80可用于记录接收到支付请求时的第一时间戳，并记录接收到第二属性信息时的第二时间戳。其中，在本申请的实施例中，检测模块50还可具体用于在第一时间戳和第二时间戳之间的时间小于第一预设阀值，或者，第一时间戳和第二时间戳之间的时间大于第二预设阀值时，判断为高危支付，其中，第二预设阀值大于第一预设阀值。可以理解，第一预设阀值和第二预设阀值可根据实际情况设定。由此，为保证支付的安全性，需保证从接收到的支付请求开始直到接收到第二属性信息时为止，这个过程所花费的时间控制在正常合理的范围内。

本申请实施例的支付安全性的检测装置，可通过第一接收模块接收客户端发送的支付请求，并记录与支付请求相关的第一属性信息，发送模块向客户端发送安全代码，采集模块通过安全代码采集第二属性信息，第二接收模块接收客户端的商业订单提交请求，并记录与商业订单提交请求相关的第三属性信息，检测模块根据第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测，在整个支付检测过程中，通过支付服务商来获取用户IP，至少具有以下优点：(1)不会受到商家开发的技术或服务器架构中的负载均衡、反向代理等设备的影响，通过支付接口直接即可准确地获取到用户IP；(2)通过支付接口直接获取网络层IP，避免了IP在传输过程中会被网络服务商篡改的风险，从而使得支付服务商获取到的IP更加准确，从而支付服务商根据更加准确的IP即可对支付操作进行安全性检测，提高了准确率。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (14)

1.一种支付安全性的检测方法，其特征在于，包括以下步骤：

接收客户端发送的支付请求，并记录与所述支付请求相关的第一属性信息；

向所述客户端发送安全代码，并通过所述安全代码采集第二属性信息；

接收所述客户端的商业订单提交请求，并记录与所述商业订单提交请求相关的第三属性信息；以及

根据所述第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测。

2.如权利要求1所述的支付安全性的检测方法，其特征在于，其中，所述第一属性信息为所述客户端发送所述支付请求时的第一IP地址，所述第二属性信息为通过所述安全代码采集的所述客户端的第二IP地址，所述第三属性信息为所述客户端发送所述商业订单提交请求时的第三IP地址，其中，

如果所述第一IP地址、所述第二IP地址和所述第三IP地址中的任意两个不同，则判断为高危支付。

3.如权利要求1所述的支付安全性的检测方法，其特征在于，所述第一属性信息为通过所述支付请求获取的第一域名信息，所述第二属性信息为所述安全代码采集的第二域名信息，其中，

如果所述第一域名信息与所述第二域名信息不同，则判断为高危支付。

4.如权利要求1-3任一项所述的支付安全性的检测方法，其特征在于，在所述向所述客户端发送安全代码之前，还包括：

提取所述支付请求中的Refer信息，其中，当所述Refer信息为空时将所述安全代码发送至所述客户端。

5.如权利要求4所述的支付安全性的检测方法，其特征在于，在所述向所述客户端发送安全代码之前，还包括：

通过混淆算法对所述安全代码进行混淆以生成混淆字符串以将混淆之后的安全代码和所述混淆字符串发送至所述客户端。

6.如权利要求5所述的支付安全性的检测方法，其特征在于，所述通过所述安全代码采集第二属性信息具体包括：

所述客户端运行所述安全代码以使所述安全代码采集所述第二属性信息；

所述客户端对所述第二属性信息和所述混淆字符串进行签名以生成签名信息；

接收所述客户端发送的所述第二属性信息和所述签名信息，并根据所述签名信息对所述第二属性信息进行验证。

7.如权利要求1-3任一项所述的支付安全性的检测方法，其特征在于，还包括：

记录接收到所述支付请求时的第一时间戳，并记录接收到所述第二属性信息时的第二时间戳；

如果所述第一时间戳和第二时间戳之间的时间小于第一预设阈值，或者，所述第一时间戳和第二时间戳之间的时间大于第二预设阈值，则判断为高危支付，其中，所述第二预设阈值大于所述第一预设阈值。

8.一种支付安全性的检测装置，其特征在于，包括：

第一接收模块，用于接收客户端发送的支付请求，并记录与所述支付请求相关的第一属性信息；

发送模块，用于向所述客户端发送安全代码；

采集模块，用于通过所述安全代码采集第二属性信息；

第二接收模块，用于接收所述客户端的商业订单提交请求，并记录与所述商业订单提交请求相关的第三属性信息；以及

检测模块，用于根据所述第一属性信息、第二属性信息和第三属性信息中的至少两个进行支付安全性检测。

9.如权利要求8所述的支付安全性的检测装置，其特征在于，其中，所述第一属性信息为所述客户端发送所述支付请求时的第一IP地址，所述第二属性信息为通过所述安全代码采集的所述客户端的第二IP地址，所述第三属性信息为所述客户端发送所述商业订单提交请求时的第三IP地址，其中，所述检测模块具体用于：

在所述第一IP地址、所述第二IP地址和所述第三IP地址中的任意两个不同时，判断为高危支付。

10.如权利要求8所述的支付安全性的检测装置，其特征在于，所述第一属性信息为通过所述支付请求获取的第一域名信息，所述第二属性信息为所述安全代码采集的第二域名信息，其中，所述检测模块具体用于：

在所述第一域名信息与所述第二域名信息不同时，判断为高危支付。

11.如权利要求8-10任一项所述的支付安全性的检测装置，其特征在于，还包括：

提取模块，用于提取所述支付请求中的Refer信息，其中，所述发送模块具体用于在所述Refer信息为空时将所述安全代码发送至所述客户端。

12.如权利要求11所述的支付安全性的检测装置，其特征在于，还包括：

生成模块，用于通过混淆算法对所述安全代码进行混淆以生成混淆字符串；

所述发送模块还用于将混淆之后的安全代码和所述混淆字符串发送至所述客户端。

13.如权利要求12所述的支付安全性的检测装置，其特征在于，所述采集模块包括：

接收单元，用于接收所述客户端发送的所述第二属性信息和所述签名信息，其中，所述客户端运行所述安全代码以使所述安全代码采集所述第二属性信息，所述客户端对所述第二属性信息和所述混淆字符串进行签名以生成签名信息；

验证单元，用于根据所述签名信息对所述第二属性信息进行验证。

14.如权利要求8-10任一项所述的支付安全性的检测装置，其特征在于，还包括：

记录模块，用于记录接收到所述支付请求时的第一时间戳，并记录接收到所述第二属性信息时的第二时间戳；其中，

所述检测模块还具有用于：

在所述第一时间戳和第二时间戳之间的时间小于第一预设阈值，或者，所述第一时间戳和第二时间戳之间的时间大于第二预设阈值时，判断为高危支付，其中，所述第二预设阈值大于所述第一预设阈值。