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

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

Info

Publication number
WO2016029795A1
WO2016029795A1 PCT/CN2015/086618 CN2015086618W WO2016029795A1 WO 2016029795 A1 WO2016029795 A1 WO 2016029795A1 CN 2015086618 W CN2015086618 W CN 2015086618W WO 2016029795 A1 WO2016029795 A1 WO 2016029795A1
Authority
WO
WIPO (PCT)
Prior art keywords
attribute information
payment
client
security
information
Prior art date
Application number
PCT/CN2015/086618
Other languages
English (en)
French (fr)
Inventor
沈星宇
黄冕
李潇霄
Original Assignee
阿里巴巴集团控股有限公司
沈星宇
黄冕
李潇霄
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司, 沈星宇, 黄冕, 李潇霄 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2016029795A1 publication Critical patent/WO2016029795A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing

Definitions

  • the present application relates to the field of electronic commerce technologies, and in particular, to a method and an apparatus for detecting payment security.
  • the phishing website automatically creates a payment order for the merchant website on the server side, and then jumps to the payment service provider page link or form to trigger submission or jump on the user page, because fishing
  • the website simulates the page of the order the user wants to pay, so the user will continue to pay, causing him to be deceived and suffer money loss.
  • the characteristics of such phishing websites are that the IP of the payment order for creating the merchant website (Internet Protocol, the protocol interconnected between the networks) and the IP paid by the user on the payment platform are not the same IP, but the normal user operation should be the same IP.
  • the user in order to prevent the phishing website from simulating the order page that the user wants to pay, the user may be deceived, and the IP of the created order may be obtained through the merchant website, and then the IP is submitted to the payment service provider through the form. For the payment platform to determine whether there is a risk of fishing.
  • IP address of the merchant website may not be unified due to the existence of devices such as load balancing and reverse proxy in the technology or server architecture developed by the merchant. For example, if the IP address of the intranet is taken, a large number of payment failures may occur, for example, If the header header is taken (the server uses the HTTP (Hypertext Transfer Protocol) protocol to pass HTML (HyperText Markup language) data to the string sent by the browser), the IP will be phishing. Website malicious Making IP in the header, bypassing the prevention and control, therefore, it is difficult for the merchant to obtain an accurate IP;
  • HTTP Hypertext Transfer Protocol
  • IP services may be used by the network during transmission.
  • the tampering of the business led to regional payment failures.
  • the user IP provided by the payment service provider's merchant website may be inaccurate, which may affect the detection of payment security, which may result in inaccurate detection results.
  • the purpose of the present application is to solve at least one of the above technical problems to some extent.
  • an object of the present application is to propose a method of detecting payment security.
  • the method makes the IP obtained by the payment service provider more accurate, so that the payment service provider can perform security detection on the payment operation according to a more accurate IP, thereby improving the accuracy.
  • Another object of the present application is to provide a detection device for payment security.
  • a method for detecting payment security includes: receiving a payment request sent by a client, and recording first attribute information related to the payment request; and sending the security to the client.
  • Code and collecting second attribute information by the security code; receiving a business order submission request of the client, and recording third attribute information related to the commercial order submission request; and according to the first attribute information, At least two of the second attribute information and the third attribute information perform payment security detection.
  • the method for detecting payment security in the embodiment of the present application may first receive a payment request sent by the client, and record the first attribute information related to the payment request, and then send the security code to the client, and collect the second through the security code. Attribute information, then receive the client's commercial order submission request, and Recording third attribute information related to the business order submission request, and performing payment security detection according to at least two of the first attribute information, the second attribute information, and the third attribute information, and through the payment service during the entire payment detection process
  • the quotient to obtain the user IP has at least the following advantages: (1) it is not affected by devices such as load balancing and reverse proxy in the technology or server architecture developed by the merchant, and the user IP can be accurately obtained through the payment interface; (2) Obtaining the network layer IP directly through the payment interface, avoiding the risk that the IP will be tampered with by the network service provider during the transmission process, thereby making the IP obtained by the payment service provider more accurate, so that the payment service provider according to the more accurate IP Security checks can be performed on payment
  • a payment security detecting apparatus includes: a first receiving module, configured to receive a payment request sent by a client, and record first attribute information related to the payment request.
  • a sending module configured to send a security code to the client
  • an acquiring module configured to collect second attribute information by using the security code
  • a second receiving module configured to receive a business order submission request of the client, and record a third attribute information related to the business order submission request;
  • a detecting module configured to perform payment security detection according to at least two of the first attribute information, the second attribute information, and the third attribute information.
  • the payment security detecting apparatus of the embodiment of the present application may receive the payment request sent by the client through the first receiving module, and record the first attribute information related to the payment request, and the sending module sends the security code to the client, and the collecting module passes The security code collects the second attribute information, the second receiving module receives the business order submission request of the client, and records the third attribute information related to the commercial order submission request, and the detecting module is configured according to the first attribute information, the second attribute information, and the third attribute. At least two of the information are used for payment security detection. In the whole payment detection process, the payment service provider obtains the user IP, and at least has the following advantages: (1) is not subject to load balancing in the technology or server architecture developed by the merchant.
  • the user IP can be obtained directly through the payment interface; (2) The network layer IP is directly obtained through the payment interface, which avoids the risk that the IP will be tampered with by the network service provider during the transmission process, so that the IP obtained by the payment service provider is more accurate, so that the payment service provider can pay according to a more accurate IP. Operation for safety testing improves accuracy.
  • FIG. 1 is a flow chart of a method for detecting payment security according to an embodiment of the present application
  • FIG. 2 is a flow chart of collecting second attribute information by a security code according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of a method for detecting payment security according to an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram of a payment security detecting apparatus according to an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of a device for detecting payment security according to another embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a device for detecting payment security according to still another embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a device for detecting payment security according to still another embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of a payment security detecting apparatus according to still another embodiment of the present application.
  • the method for detecting payment security may include:
  • S101 Receive a payment request sent by the client, and record first attribute information related to the payment request.
  • the client can be understood as a merchant website.
  • the client may initiate a JS (JavaScript, Literal Translation Language) payment request to the payment platform on the order page, and the payment platform server may acquire and record the first related to the payment request after receiving the payment request sent by the client.
  • An attribute information such as the IP of the network layer, where the IP can be understood as the IP when the client places a single page.
  • the method for detecting payment security may further include: extracting the Refer information in the payment request, wherein the security is safe when the Refer information is empty. The code is sent to the client.
  • the source of the payment request initiated by the order page should be the client's page under normal circumstances. Therefore, at this time, it is necessary to determine whether the source of the payment request is the order page of the client. Specifically, the Refer information in the payment request may be extracted, and the value corresponding to the Refer information is recorded. When the value corresponding to the Refer information is empty, it may be determined that the payment request may be a payment request created by the phishing website. At this time, the security code is sent to the client to enable the client to prevent and control the phishing risk.
  • the The method of detecting payment security may further include: obfuscating the security code by an obfuscation algorithm to generate an obfuscated string to send the obfuscated security code and the obfuscated string to the client.
  • the security code can be understood as an attack and defense JS code.
  • the attack and defense JS code can be confused by the irreversible confusion algorithm to generate an obfuscated string, and then the offensive and defensive JS code and the obfuscated string are sent to the client.
  • the confusing string can activate the anti-collection function.
  • the obfuscation algorithm needs to be updated periodically, or the security code is confusing in real time, and a confusing string is added in the variable of the security code when periodically updating or real-time confusing, thereby being safe.
  • the code is protective.
  • collecting the second attribute information by using the security code may specifically include: the client running the security code to enable the security code to collect the second attribute information (S201). Thereafter, the client signs the second attribute information and the obfuscated character string to generate signature information (S202). Then, the second attribute information and the signature information sent by the client are received, and the second attribute information is verified according to the signature information (S203).
  • the obfuscated string here is the obfuscated string received by the above client.
  • the second attribute information takes “location.host” and "parent.location.host” as an example.
  • the client receives the security code and runs the security code, it can pass security.
  • the code collects information about "location.host” and "parent.location.host”.
  • the client can perform MD5 (Message Digest Algorithm, fifth edition) signature on "location.host", "parent.location.host” and the obfuscated string to generate signature information, such as: MD5 (location. Host+ confuses the string +parent.location.host) to prevent tampering.
  • MD5 Message Digest Algorithm, fifth edition
  • signature information such as: MD5 (location. Host+ confuses the string +parent.location.host) to prevent tampering.
  • the second attribute information and the signature information sent by the client may be received, and then the signature information may be decrypted, and the second attribute information is verified according to the decrypted signature information to verify whether the received second attribute information is decrypted.
  • the second attribute information in the subsequent signature information is consistent. Thereby ensuring the source of the second attribute information Is the client.
  • the third attribute information may be a network layer IP address when the commercial order is paid by the payment platform cashier.
  • S104 Perform payment security detection according to at least two of the first attribute information, the second attribute information, and the third attribute information.
  • the first attribute information may be a first IP address when the client sends a payment request
  • the second attribute information may be a second IP address of the client collected by the security code
  • the third attribute The information can be the third IP address when the client sends a commercial order submission request.
  • the first attribute information is a network layer first IP address when the client sends a payment request
  • the second attribute information is a network layer second IP address when the client information is returned after collecting the second attribute information by using the security code
  • the third attribute information is a network layer third IP address when the client sends a commercial order submission request, and compares the first IP address, the second IP address, and the third IP address, when the first IP address, the second IP address, and the first
  • the payment process may be judged as a high-risk payment, and the user may be reminded of the risk of fishing.
  • the first attribute information may be the first domain name information acquired by the payment request
  • the second attribute information may be the second domain name information collected by the security code.
  • the first attribute information may be a domain name location.host (ie, the first domain name information) of the Refer information obtained through the payment request
  • the second attribute information is a domain name of the security code collection client.
  • the “location.host” ie, the second domain name information
  • the “location.host” may compare the first domain name information with the second domain name information.
  • the payment process may be determined to be a high-risk payment, and Remind users of the risk of fishing.
  • the method for detecting payment security may further include: recording a first timestamp when the payment request is received, and recording a second timestamp when the second attribute information is received; If the time between the first timestamp and the second timestamp is less than the first preset threshold, or the time between the first timestamp and the second timestamp is greater than the second preset threshold, it is determined to be a high-risk payment Wherein the second preset threshold is greater than the first preset threshold. It can be understood that the first preset threshold and the second preset threshold can be set according to actual conditions. Therefore, in order to ensure the security of payment, it is necessary to ensure that the time taken by this process is within a normal and reasonable range from the start of the received payment request until the receipt of the second attribute information.
  • the method for detecting payment security in the embodiment of the present application may first receive a payment request sent by the client, and record the first attribute information related to the payment request, and then send the security code to the client, and collect the second through the security code. Attribute information, then receiving a business order submission request of the client, and recording third attribute information related to the commercial order submission request, and performing payment security according to at least two of the first attribute information, the second attribute information, and the third attribute information Sex detection, in the entire payment detection process, through the payment service provider to obtain the user IP, at least has the following advantages: (1) will not be affected by the technology developed by the merchant or the load balancing, reverse proxy and other devices in the server architecture, The user interface can be obtained directly through the payment interface; (2) directly obtaining the network layer IP through the payment interface, thereby avoiding the risk that the IP will be tampered with by the network service provider during the transmission process, thereby making the IP obtained by the payment service provider More accurate, so payment service providers can secure payment operations based on more accurate IP Measure, improves accuracy
  • the merchant website can initiate a JS request (ie, a payment request) through the business page.
  • the payment platform can receive the JS request (S1), and obtain the network layer IP1 of the merchant website when the order page is placed, and record the IP1 into the session session (S11), and then record the Refer1 to the session in the JS request.
  • the payment platform returns JS+cookie (S2) to the merchant website, obtains location.host(S21) through the attack and defense JS code, obtains the parent (S22), and obtains the confusion string (S23) provided by the attack and defense JS code, and then the location.
  • the three strings of host, parent, and obfuscated string are MD5-signed to obtain signature information (S24), and then submit location.host, parent, and signature information to the payment platform (S25) through get.
  • the payment platform receives the verification string returned by the merchant website (S3), acquires the network layer IP2 at this time (S31), and obtains the current timestamp 2 (ie, the second timestamp), and records it to the session (S32).
  • the payment platform receives the commercial order submission request (S4), the payment platform acquires the network layer IP3 at this time (S41), and then takes out the IP1, Refer1, timestamp 1, timestamp 2, IP2, location.host1 in the session. , parent.location.host2 and IP3 (S42), and then based on the data to comprehensively determine whether the user is safe when paying (S43).
  • the present application also proposes a payment security detecting apparatus.
  • FIG. 4 is a schematic structural diagram of a payment security detecting apparatus according to an embodiment of the present application.
  • the payment security detecting apparatus may include: a first receiving module 10, a sending module 20, an acquiring module 30, a second receiving module 40, and a detecting module 50.
  • the first receiving module 10 is configured to receive a payment request sent by the client, and record first attribute information related to the payment request.
  • the client can be understood as a merchant website.
  • the client may initiate a JS (JavaScript, Literal Translation Language) payment request to the payment platform on the order page, and the first receiving module 10 may acquire and record the payment request after receiving the payment request sent by the client.
  • the related first attribute information such as the IP of the network layer, can be understood as the IP when the client places a single page.
  • the sending module 20 can be used to send a security code to the client.
  • the acquisition module 30 can be configured to collect the second attribute information through the security code.
  • the payment security detecting apparatus may further include an extracting module 60.
  • the extraction module 60 is configured to extract the Refer information in the payment request, where the sending module 20 is specifically configured to send the security code to the client when the Refer information is empty.
  • the extraction module 60 may extract the Refer information in the payment request and record the value corresponding to the Refer information. When the value corresponding to the Refer information is empty, it may be determined that the payment request may be a payment request created by the phishing website. At this time, the sending module 20 sends the security code to the client to enable the client to prevent and control the phishing risk. .
  • the payment security detecting apparatus may further include a generating module 70.
  • the generation module 70 can be used to confuse the security code with an obfuscation algorithm to generate a confusing string.
  • the sending module 20 is also used for Send the obfuscated security code and obfuscated string to the client.
  • the security code can be understood as an attack and defense JS code.
  • the generating module 70 can confuse the attack and defense JS code by an irreversible obfuscation algorithm to generate an obfuscated string.
  • the sending module 20 can send the confusing attack and defense JS code and the confusing string to the client.
  • the confusing string can activate the anti-collection function.
  • the obfuscation algorithm needs to be updated periodically, or the security code is confusing in real time, and a confusing string is added in the variable of the security code when periodically updating or real-time confusing, thereby being safe.
  • the code is protective.
  • the second receiving module 40 can be configured to receive a commercial order submission request of the client and record third attribute information related to the commercial order submission request.
  • the third attribute information may be a network layer IP address when the commercial order is paid by the payment platform cashier.
  • the detecting module 50 is configured to perform payment security detection according to at least two of the first attribute information, the second attribute information, and the third attribute information.
  • the first attribute information is a first IP address when the client sends a payment request
  • the second attribute information is a second IP address of the client that is collected by the security code
  • the third attribute information is The third IP address when the client sends the commercial order submission request
  • the detecting module 50 is specifically configured to determine that the high-risk payment is made when any two of the first IP address, the second IP address, and the third IP address are different.
  • the first attribute information is a network layer first IP address when the client sends a payment request
  • the second attribute information is a network layer second IP address when the client information is returned after collecting the second attribute information by using the security code
  • the third attribute information is a network layer third IP address when the client sends a commercial order submission request
  • the detecting module 50 compares the first IP address, the second IP address, and the third IP address, when the first IP address, the second IP address When any two of the IP address and the third IP address are different, The payment process is judged to be a high-risk payment, and the user may be reminded of the risk of fishing.
  • the first attribute information is the first domain name information acquired by the payment request
  • the second attribute information is the second domain name information collected by the security code
  • the detecting module 50 may be specifically used in the first When the domain name information is different from the second domain name information, it is judged to be a high-risk payment.
  • the first attribute information may be the domain name location.host (ie, the first domain name information) of the Refer information obtained by the payment request
  • the second attribute information is the domain name “location.host” of the security code collection client (ie, the second domain name information)
  • the detecting module 50 may compare the first domain name information with the second domain name information. When the first domain name information and the second domain name information are different, the payment process may be determined to be a high-risk payment, and the user may be reminded of the risk of fishing.
  • the acquisition module 30 may include a receiving unit 31 and a verification unit 32.
  • the receiving unit 31 is configured to receive second attribute information and signature information sent by the client, where the client runs the security code to enable the security code to collect the second attribute information, and the client signs the second attribute information and the obfuscated string to generate Signature information.
  • the verification unit 32 is configured to verify the second attribute information according to the signature information. It should be understood that the obfuscated string here is the obfuscated string received by the above client.
  • the second attribute information takes “location.host” and "parent.location.host” as an example.
  • the client receives the security code and runs the security code, it can pass security.
  • the code collects information about "location.host” and "parent.location.host”.
  • the client can sign MD5 (Message Digest Algorithm, Message Digest Algorithm, Fifth Edition) for "location.host", “parent.location.host”, and obfuscated string to generate signature information, such as: MD5 (location.host+ Confuse the string +parent.location.host) to prevent tampering.
  • MD5 Message Digest Algorithm, Message Digest Algorithm, Fifth Edition
  • the receiving unit 31 can receive the second attribute information and the signature information sent by the client, and the verification unit 32 can decrypt the signature information, and verify the second attribute information according to the decrypted signature information to verify the receipt. Whether the second attribute information is consistent with the second attribute information in the decrypted signature information. Thus, the source of the second attribute information is guaranteed to be the client.
  • the payment security detecting apparatus may further include a recording module 80.
  • the recording module 80 can be configured to record the first timestamp when the payment request is received, and record the second timestamp when the second attribute information is received.
  • the detecting module 50 is further configured to: the time between the first timestamp and the second timestamp is less than the first preset threshold, or the first timestamp and the second time When the time between the stamps is greater than the second preset threshold, it is determined to be a high-risk payment, wherein the second preset threshold is greater than the first preset threshold.
  • the first preset threshold and the second preset threshold can be set according to actual conditions. Therefore, in order to ensure the security of payment, it is necessary to ensure that the time taken by this process is within a normal and reasonable range from the start of the received payment request until the receipt of the second attribute information.
  • the payment security detecting apparatus of the embodiment of the present application may receive the payment request sent by the client through the first receiving module, and record the first attribute information related to the payment request, and the sending module sends the security code to the client, and the collecting module passes The security code collects the second attribute information, the second receiving module receives the business order submission request of the client, and records the third attribute information related to the commercial order submission request, and the detecting module is configured according to the first attribute information, the second attribute information, and the third attribute. At least two of the information are used for payment security detection. In the whole payment detection process, the payment service provider obtains the user IP, and at least has the following advantages: (1) is not subject to load balancing in the technology or server architecture developed by the merchant.
  • the impact of devices such as reverse proxy can directly obtain the user IP through the payment interface; (2) directly obtain the network layer IP through the payment interface, thereby avoiding the risk that the IP will be tampered with by the network service provider during the transmission process. Thereby making the IP obtained by the payment service provider more accurate, so that the payment service provider according to Accurate IP can be used to check the security of payment operations and improve accuracy.
  • first and second are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated.
  • features defining “first” or “second” may include at least one of the features, either explicitly or implicitly.
  • the meaning of "a plurality” is at least two, such as two, three, etc., unless specifically defined otherwise.
  • a "computer-readable medium” can be any program that can contain, store, communicate, propagate, or transmit a A device that is used by an execution system, apparatus, or device, or in conjunction with such instructions to execute a system, apparatus, or device.
  • computer readable media include the following: electrical connections (electronic devices) having one or more wires, portable computer disk cartridges (magnetic devices), random access memory (RAM), Read only memory (ROM), erasable editable read only memory (EPROM or flash memory), fiber optic devices, and portable compact disk read only memory (CDROM).
  • the computer readable medium may even be a paper or other suitable medium on which the program can be printed, as it may be optically scanned, for example by paper or other medium, followed by editing, interpretation or, if appropriate, other suitable The method is processed to obtain the program electronically and then stored in computer memory.
  • portions of the application can be implemented in hardware, software, firmware, or a combination thereof.
  • multiple steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system.
  • a suitable instruction execution system For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques well known in the art: having logic gates for implementing logic functions on data signals. Discrete logic circuits, application specific integrated circuits with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.
  • each functional unit in each embodiment of the present application may be integrated into one processing module, or each unit may exist physically separately, or two or more units may be integrated into one module.
  • the above integrated modules can be implemented in the form of hardware or software functional modules. Formal realization.
  • the integrated modules, if implemented in the form of software functional modules and sold or used as stand-alone products, may also be stored in a computer readable storage medium.
  • the above mentioned storage medium may be a read only memory, a magnetic disk or an optical disk or the like. While the embodiments of the present application have been shown and described above, it is understood that the above-described embodiments are illustrative and are not to be construed as limiting the scope of the present application. The embodiments are subject to variations, modifications, substitutions and variations.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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

Description

支付安全性的检测方法和装置 技术领域
本申请涉及电子商务技术领域，尤其涉及一种支付安全性的检测方法和装置。
背景技术
目前互联网上存在一种钓鱼欺诈方式，即钓鱼网站自动在服务端创建商家网站的支付订单，之后将跳转到支付服务提供商页面的链接或表单在用户页面上触发提交或跳转，因为钓鱼网站会模拟用户想要支付的订单的页面，所以用户就会继续支付，导致上当受骗，遭到金钱损失。这类钓鱼网站的特征是创建商家网站的支付订单的IP(Internet Protocol，网络之间互连的协议)和用户在支付平台付款的IP不是同一个IP，但是正常用户操作应该是同一个IP。
相关技术中，为了避免钓鱼网站模拟用户想要支付的订单页面而导致用户上当受骗的问题，可通过商家网站先获取创建订单的IP，再通过表单将该IP提交给支付服务提供商的页面，以供支付平台判断是否有钓鱼风险。
但是，通过商家网站获取创建订单的IP再将其传给支付平台的方法存在以下缺陷：
1)商家网站取IP的逻辑会由于商家开发的技术或服务器架构中的负载均衡、反向代理等设备的存在导致无法统一，例如，有取到内网IP而导致大批支付失败，又如，如果取了标头header(服务器以HTTP(Hypertext transfer protocol，超文本传输协议)协议传HTML(HyperText Markup language，超级文本标记语言)资料到浏览器前所送出的字串)中的IP会被钓鱼网站恶意伪 造header中的IP，绕过防控，因此，商家很难获取到准确的IP；
2)由于有些网络服务商的设备会因为某些业务需要配置了修改URL(Uniform Resource Locator：统一资源定位器)中的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(Message Digest Algorithm，消息摘要算法第五版)签名，以生成签名信息，如：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(MessageDigest Algorithm，消息摘要算法第五版)签名，以生成签名信息，如：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任一项所述的支付安全性的检测装置，其特征在于，还包括：
    记录模块，用于记录接收到所述支付请求时的第一时间戳，并记录接收到所述第二属性信息时的第二时间戳；其中，
    所述检测模块还具有用于：
    在所述第一时间戳和第二时间戳之间的时间小于第一预设阈值，或者，所述第一时间戳和第二时间戳之间的时间大于第二预设阈值时，判断为高危支付，其中，所述第二预设阈值大于所述第一预设阈值。
PCT/CN2015/086618 2014-08-27 2015-08-11 支付安全性的检测方法和装置 WO2016029795A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410431210.6A CN105447700A (zh) 2014-08-27 2014-08-27 支付安全性的检测方法和装置
CN201410431210.6 2014-08-27

Publications (1)

Publication Number Publication Date
WO2016029795A1 true WO2016029795A1 (zh) 2016-03-03

Family

ID=55398740

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/086618 WO2016029795A1 (zh) 2014-08-27 2015-08-11 支付安全性的检测方法和装置

Country Status (3)

Country Link
CN (1) CN105447700A (zh)
HK (1) HK1221805A1 (zh)
WO (1) WO2016029795A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113379406A (zh) * 2021-05-20 2021-09-10 大河(深圳)信息有限公司 商户端与第三方支付平台之间的交易方法

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106952409B (zh) * 2017-04-27 2022-10-11 济南大学 一种按流量计费的售水系统及方法
CN107784554B (zh) * 2017-09-28 2020-11-27 深圳乐信软件技术有限公司 订单处理的方法、装置、存储介质、服务器及终端设备
CN109600272B (zh) * 2017-09-30 2022-03-18 北京国双科技有限公司 爬虫检测的方法及装置
CN110233839B (zh) * 2019-06-10 2021-10-15 北京奇艺世纪科技有限公司 一种数据处理系统及方法
CN110555303A (zh) * 2019-08-01 2019-12-10 苏宁云计算有限公司 防止机器脚本恶意访问的方法及装置
CN111967929A (zh) * 2020-07-09 2020-11-20 口碑(上海)信息技术有限公司 订单巡检方法及装置、电子设备、存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102073953A (zh) * 2009-11-24 2011-05-25 阿里巴巴集团控股有限公司 一种网上支付方法及系统
CN102096872A (zh) * 2011-02-12 2011-06-15 中国工商银行股份有限公司 一种网上银行支付信息安全检测方法及装置
CN102214334A (zh) * 2010-04-01 2011-10-12 阿里巴巴集团控股有限公司 一种网上支付方法、装置及系统
CN103745352A (zh) * 2013-12-30 2014-04-23 北京中科金财电子商务有限公司 Wap商户移动平台调用支付插件进行下单的方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103166917B (zh) * 2011-12-12 2016-02-10 阿里巴巴集团控股有限公司 网络设备身份识别方法及系统
CN103888490B (zh) * 2012-12-20 2018-03-13 上海天泰网络技术有限公司 一种全自动的web客户端人机识别的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102073953A (zh) * 2009-11-24 2011-05-25 阿里巴巴集团控股有限公司 一种网上支付方法及系统
CN102214334A (zh) * 2010-04-01 2011-10-12 阿里巴巴集团控股有限公司 一种网上支付方法、装置及系统
CN102096872A (zh) * 2011-02-12 2011-06-15 中国工商银行股份有限公司 一种网上银行支付信息安全检测方法及装置
CN103745352A (zh) * 2013-12-30 2014-04-23 北京中科金财电子商务有限公司 Wap商户移动平台调用支付插件进行下单的方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113379406A (zh) * 2021-05-20 2021-09-10 大河(深圳)信息有限公司 商户端与第三方支付平台之间的交易方法

Also Published As

Publication number Publication date
HK1221805A1 (zh) 2017-06-09
CN105447700A (zh) 2016-03-30

Similar Documents

Publication Publication Date Title
WO2016029795A1 (zh) 支付安全性的检测方法和装置
Burnett et al. Encore: Lightweight measurement of web censorship with cross-origin requests
WO2020233022A1 (zh) 漏洞检测方法、装置、计算机设备和存储介质
KR101001132B1 (ko) 웹 어플리케이션의 취약성 판단 방법 및 시스템
US11290468B2 (en) Content delivery network (CDN) bot detection using primitive and compound feature sets
CN104881603B (zh) 网页重定向漏洞检测方法及装置
CN101388768B (zh) 检测恶意http请求的方法及装置
CN102546576A (zh) 一种网页挂马检测和防护方法、系统及相应代码提取方法
US20200106790A1 (en) Intelligent system for mitigating cybersecurity risk by analyzing domain name system traffic
CN105635064B (zh) Csrf攻击检测方法及装置
CN102571846A (zh) 一种转发http请求的方法及装置
JP6030272B2 (ja) ウェブサイト情報抽出装置、システム、ウェブサイト情報抽出方法、および、ウェブサイト情報抽出プログラム
WO2015188604A1 (zh) 钓鱼网页的检测方法和装置
CN103117897A (zh) 一种检测包含Cookie信息的消息的方法及相关装置
CN103647652B (zh) 一种实现数据传输的方法、装置和服务器
CN114616795A (zh) 用于防止重试或重放攻击的安全机制
CN107864677A (zh) 内容访问验证系统和方法
Mirheidari et al. Web cache deception escalates!
CN111291353B (zh) 一种账号关联方法、装置以及计算机存储介质
JP5656266B2 (ja) ブラックリスト抽出装置、抽出方法および抽出プログラム
JP2007179522A (ja) リンク情報検証方法、システム、装置、およびプログラム
CN109818906A (zh) 一种设备指纹信息处理方法、装置及服务器
JP6291441B2 (ja) ウェブシステム、ウェブクライアント装置および改ざん検査装置
JP2004038272A (ja) ウェブ監視装置及び方法、コンピュータプログラム
WO2014059159A2 (en) Systems and methods for testing and managing defensive network devices

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15836680

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15836680

Country of ref document: EP

Kind code of ref document: A1