CN108667617A - app接口防重放方法及服务器 - Google Patents

app接口防重放方法及服务器 Download PDF

Info

Publication number
CN108667617A
CN108667617A CN201810422092.0A CN201810422092A CN108667617A CN 108667617 A CN108667617 A CN 108667617A CN 201810422092 A CN201810422092 A CN 201810422092A CN 108667617 A CN108667617 A CN 108667617A
Authority
CN
China
Prior art keywords
transmitting terminal
interface requests
time stamp
verification
information
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN201810422092.0A
Other languages
English (en)
Inventor
郑乐银
王辉耀
方杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Water World Co Ltd
Original Assignee
Shenzhen Water World Co Ltd
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 Shenzhen Water World Co Ltd filed Critical Shenzhen Water World Co Ltd
Priority to CN201810422092.0A priority Critical patent/CN108667617A/zh
Publication of CN108667617A publication Critical patent/CN108667617A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明涉及一种app接口防重放方法及服务器，所述方法包括：接收发送端发送的接口请求；获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求；若是，则执行所述接口请求的处理事务并返回响应信息，否则不予处理并返回错误信息。本发明实施例通过获取接口请求中的发送端验证信息，并验证该发送端验证信息是否合理，当发送端验证信息合理时，说明该接口请求合理并执行该接口请求的处理事务，然后返回响应信息至发送端，通知发送端操作成功，若发送端验证信息不合理时，则认为接口请求错误，不进行处理并发送错误信息至发送端，避免服务器多次接收到相同的接口请求出现数据库数据错乱，甚至导致服务器宕机的情况。

Description

app接口防重放方法及服务器
技术领域
本发明涉及网络接口请求技术领域，特别涉及一种app接口防重放方法及服务器。
背景技术
目前app应用市场越来越广泛，小到新闻、广播或者聊天，大到支付、理财以及购买等均通过使用app事项，方便快捷满足了广大用户的日常需求，使得app应用开发成为不可阻挡的趋势。
同样作为开发设计app的研发人员不仅要考虑到应用的功能实现和用户体验，也要考虑到app的服务器稳定数据传输安全等问题，防止服务器异常造成用户使用出现问题，降低产品的用户体验。
目前app应用和服务器的通讯一般都是以接口形式进行数据传输，但是，如果有不法用户通过工具截取用户app和服务器之间的接口数据进行重复发送，即把用户的请求原封不动的在发送一次、两次...n次，或者由于用户在很短的时间内多次操作而发送多次请求，就会导致数据库数据错乱，甚至服务器异常宕机等情况。
发明内容
本发明要解决的技术问题在于针对上述现有技术中的不足之处，提供一种app接口防重放方法及服务器。
本发明解决技术问题采用的技术手段是提供一种app接口防重放方法，包括：
接收发送端发送的接口请求；
获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求；
若是，则执行所述接口请求的处理事务并返回响应信息，否则不予处理并返回错误信息。
进一步地，所述获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求的步骤，包括：
获取所述接口请求中的发送端签名信息；
判断所述发送端签名信息是否符合预设签名验证要求；
若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
进一步地，所述判断所述发送端签名信息是否符合预设签名验证要求的步骤，包括：
获取接收到所述接口请求时的本地时间戳；
获取所述发送端签名信息中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配；
若是，则所述发送端签名信息符合预设签名验证要求，否则所述发送端签名信息不符合预设签名验证要求。
进一步地，所述根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配的步骤，包括：
获取所述接口请求中的随机值信息；
根据所述发送时间戳和所述随机值信息拼接成秘钥信息；
判断所述秘钥信息是否与预设缓存中的数据匹配；
若是，则所述本地时间戳与所述发送时间戳不匹配，否则所述本地时间戳与所述发送时间戳匹配，并将所述秘钥信息存入所述预设缓存中。
进一步地，所述获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求的步骤，包括：
获取接收到所述接口请求时的本地时间戳；
获取所述接口请求中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配；
若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
另一方面，本发明还提供一种服务器，包括：
接收单元，用于接收发送端发送的接口请求；
验证单元，用于获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求；
处理单元，用于当所述验证单元判断为是时执行所述接口请求的处理事务并返回响应信息，否则不予处理并返回错误信息。
进一步地，所述验证单元包括：
签名获取子单元，用于获取所述接口请求中的发送端签名信息；
判断子单元，用于判断所述发送端签名信息是否符合预设签名验证要求，若是，则所述发送端验证信息符合预设签名验证要求，否则所述发送端验证信息不符合预设签名验证要求。
进一步地，所述判断子单元包括：
本地时间戳获取模块，用于获取接收到所述接口请求时的本地时间戳；
发送时间戳获取模块，用于获取所述发送端签名信息中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
时间戳判断模块，用于根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配，若是，则所述发送端签名信息符合预设签名验证要求，否则所述发送端签名信息不符合预设签名验证要求。
进一步地，所述时间戳判断模块包括：
随机值获取子模块，用于获取所述接口请求中的随机值信息；
合并子模块，用于根据所述发送时间戳和所述随机值信息拼接成秘钥信息；
秘钥判断子模块，用于判断所述秘钥信息是否与预设缓存中的数据匹配，若是，则本地时间戳与所述发送时间戳不匹配，否则所述本地时间戳与所述发送时间戳匹配，并将所述秘钥信息存入所述预设缓存中。
进一步地，所述验证单元包括：
本地签名获取子单元，用于获取接收到所述接口请求时的本地时间戳；
发送签名获取子单元，用于获取所述接口请求中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
签名判断子单元，用于根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配，若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
采用上述技术方案，本发明至少具有以下有益效果：本发明实施例通过获取接口请求中的发送端验证信息，并验证该发送端验证信息是否符合预设验证要求，当发送端验证信息与预设验证要求符合匹配时，说明该接口请求合理，服务器执行该接口请求的处理事务，然后返回响应信息至发送端，通知发送端操作成功，若该发送端验证信息不符合预设验证要求时，则认为该接口请求不合理，服务器不进行处理并发送错误信息至发送端，避免服务器多次接收到相同的接口请求出现数据库数据错乱，甚至导致服务器宕机的情况，提高用户体验。
附图说明
图1是本发明app接口防重放方法一个实施例的流程示意图。
图2是本发明app接口防重放方法一个实施例步骤S2的具体流程示意图。
图3是本发明app接口防重放方法一个实施例步骤S22的具体流程示意图。
图4是本发明app接口防重放方法一个实施例步骤S223的具体流程示意图。
图5是本发明app接口防重放方法另一个实施例步骤S2的具体流程示意图。
图6是本发明服务器一个实施例的结构方框示意图。
图7是本发明服务器另一个实施例的结构方框示意图。
图8是本发明服务器一个实施例判断子单元的结构方框示意图。
图9是本发明服务器一个实施例时间戳判断模块的结构方框示意图。
图10是本发明服务器另一个实施例的结构方框示意图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
请参阅图1至图5，本发明提供一种技术方案：一种app接口防重放方法，包括：
步骤S1，接收发送端发送的接口请求；
步骤S2，获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求；
步骤S3，若是，则执行所述接口请求的处理事务并返回响应信息，否则不予处理并返回错误信息。
在实施时，服务器接收发送端发送的接口请求，该接口请求由发送端的app进行封装生成，所述接口请求至少包括发送端的app封装的请求数据报文、发送端验证信息等，当服务器接收到接口请求时，服务器对所述发送端验证信息进行验证，判断该发送端验证信息是否符合预设验证要求，只有当所述发送端验证信息与预设验证要求对应匹配时，则认为该接口请求是合法请求，服务器会进行与接口请求对应的业务处理并返回响应数据至发送端，通知发送端操作成功；若服务器判断所述发送端验证信息不符合预设验证要求时，则认为该接口请求不是合法请求，服务器不进行处理并返回错误信息至发送端，通知发送端操作失败，避免服务器多次接收到相同的接口请求，并根据接口请求进行多次相同的操作而出现数据库数据错乱，甚至导致服务器宕机的情况，提高用户体验。当然，所述发送端验证信息可以与时间关联，以3秒时间为例，当服务器接收到发送端发送的接口请求时，获取发送端发送该接口请求时的时间节点并存储，并在3秒时间内多次接收到相同的接口请求时，判定接口请求为无效请求，服务器不予处理并返回错位信息。
在一个可选实施例中，如图2所示，所述获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求的步骤，包括：
步骤S21，获取所述接口请求中的发送端签名信息；
步骤S22，判断所述发送端签名信息是否符合预设签名验证要求；
步骤S23，若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
在实施时，所述接口请求至少包括发送端的app封装的请求数据报文、发送端签名信息等，目前app应用和服务器的通讯接口形式主要为Get和Post两种方式，这里以Get请求http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝cc为例，上述接口请求设计好签名sign的生成方式后，只有当接口请求中的发送端签名信息符合预设签名验证要求时，服务器才会认为该接口请求中的发送端验证信息符合预设验证要求，进而认为该接口请求是合法请求，服务器才会进行与接口请求对应的业务处理并返回响应数据至发送端，通知发送端操作成功；若不知道签名sign的生成方式，发送的接口请求中的发送端签名信息不符合预设签名验证要求，则发送接口请求是不会成功的，服务器会认为该发送端信息不符合预设验证要求，即认为该接口请求不是合法请求，服务器不进行处理并返回错误信息至发送端。
在一个可选实施例中，如图3所示，所述判断所述发送端签名信息是否符合预设签名验证要求的步骤，包括：
步骤S221，获取接收到所述接口请求时的本地时间戳；
步骤S222，获取所述发送端签名信息中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
步骤S223，根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配；
步骤S224，若是，则所述发送端签名信息符合预设签名验证要求，否则所述发送端签名信息不符合预设签名验证要求。
在一个实施例中，以所述接口请求为http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝cc为例，通过修改签名sign的生成方式，所述签名sign为所述发送端签名信息，例如之前的签名sign的生成方式为sign＝Md5(name＝aa&type＝＝bb),修改后的签名sign＝Md5(name＝aa&type＝＝bb&tm＝1522119884)，其中tm的值为当前时间戳，所述当前时间戳为发送端发送所述接口请求时的发送时间戳，修改后的发送端的app发送接口请求即http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝newcc，其中newcc为上述修改后的sign，服务器接收到发送端发送的接口请求后，服务器会根据参数name＝aa&type＝＝bb加上服务器当前时间的时间戳生成新的服务器签名newsign＝(name＝aa&type＝＝bb&tm＝1522119885)1522119885为服务器收到所述接口请求时的时间戳，即1522119885为服务器接收到所述接口请求时的本地时间戳，服务器将所述newsign和sign的值根据第一预设规则进行比较，如果newsign和sign的值相匹配，则认为该接口请求是合法请求，服务器会进行与接口请求对应的业务处理并返回响应数据至发送端，通知发送端操作成功。
具体地，所述第一预设规则的具体步骤包括，以预设时间差为3秒为例，若服务器接收到所述接口请求时的本地时间戳和发送端发送该接口请求时的发送时间戳的时间差小于预设时间差，即发送端发送该接口请求到服务器接收该接口请求的时间差小于3秒时，则认为newsign和sign的值匹配，服务器认为该接口请求是合法请求，若服务器接收到所述接口请求时的本地时间戳和发送端发送该接口请求时的发送时间戳之间的时间差大于预设时间差，即发送端发送该接口请求到服务器接收到该接口请求之间的时间差大于3秒，则认为newsign和sign的值不匹配，服务器重新获取newsign并与旧的sign进行对比，若经过预设次数对比后newsign和sign的值均不匹配，以所述预设次数为3次为例，当newsign与sign对比3次后均不匹配，则认为该接口请求不是合法请求，服务器不进行处理。当然，在具体实施时，所述预设时间差和预设次数的数值不做具体限定，本实施例中，时间戳没有直接体现在发送端的接口请求中，提高获取sign的生成方式的难度，能有效避免被恶意多次发送该接口请求时服务器的冗余操作。
在一个可选实施例中，如图4所示，所述根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配的步骤，包括：
步骤S2231，获取所述接口请求中的随机值信息；
步骤S2232，根据所述发送时间戳和所述随机值信息拼接成秘钥信息；
步骤S2233，判断所述秘钥信息是否与预设缓存中的数据匹配；
步骤S2234，若是，则所述本地时间戳与所述发送时间戳不匹配，否则所述本地时间戳与所述发送时间戳匹配，并将所述秘钥信息存入所述预设缓存中。
在实施时，发送端的app封装接口请求还包括随机值信息，具体地，以app封装接口请求http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝cc为例，其中，sign为发送端签名信息，通过添加额外的时间戳tm和随机值信息rad＝rand(0,1000)得到：http://x.x.x.x/add.do？name＝aa&type＝＝bb&tm＝1522119885&rad＝100，然后生成的签名sign的值newcc拼接成app的接口请求为：http://x.x.x.x/add.do？name＝aa&type＝＝bb&tm＝1522119885&rad＝100&sign＝newcc，服务器接收到发送端的发送的接口请求后，服务器会先验证签名sign是否合理，即所述签名sign是否符合预设签名验证要求，若不合理则认为该接口请求不合理，服务器不予处理并直接返回请求错误信息；若签名sign合理，服务器接下来会解析接口请求议获取时间戳tm的值，并与服务器当前的本地时间戳进行对比，若时间戳tm的值与本地时间戳之间相差大于3秒，则认为接口请求为无效请求，并重新接收发送端发送的接口请求，若3次接收到的接口请求均为无效请求，返回通知错误信息至发送端；若在3次内有匹配成功，及时间戳tm的值与本地时间戳之间相差小于3秒，则进行以下步骤。
服务器拼接时间戳tm和随机值信息rad的值作为秘钥信息key(1522119885100)，服务器在redis缓存中查找是否已经存在这个值了，即判断所述秘钥信息key是否与预设缓存中的数据匹配，如果已经存在，则认为接口请求为重复请求，服务器不予处理并通知发送端错误信息；如果在redis缓存中不存在这个值，则认为该接口请求是第一次请求，并且是有效请求，服务器会把秘钥信息key存入redis缓存中，然后执行与该接口请求对应的处理事务，然后通知发送端操作成功。本实施例通过将时间戳tm和随机值信息rad拼接成秘钥信息key，即使相同的接口请求在很短的时间内多次发送，依然能够有效的进行防范，能有效减少服务器对无效请求的操作。
在一个可选实施例中，如图5所示，所述获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求的步骤，包括：
步骤S24，获取接收到所述接口请求时的本地时间戳；
步骤S25，获取所述接口请求中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
步骤S26，根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配；
步骤S27，若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
在实施时，所述第二预设规则的具体步骤包括：以发送端的app封装接口请求http://x.x.x.x/add.do？name＝aa&type＝＝bb&tm＝1522119884&sign＝cc为例，服务器接收该接口请求并解析该接口请求获取时间戳tm，所述时间戳tm为发送端发送所述接口请求时的发送时间戳，然后获取服务器接收到所述接口请求时的本地时间戳，服务器根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配，具体地，以预设时间差为3秒以及预设次数为3次为例，服务器判断所述本地时间戳和发送时间戳之间是否超过预设时间差，即所述本地时间戳和发送时间戳之间的时间差是否超过3秒，若是，则认为所述接口请求不合理，重复上述操作3次，若3次获取的本地时间戳与发送时间戳之间均超过3秒，则服务器返回请求错误信息至发送端；若在规定的预设次数内有匹配成功，即在3次内有任意一次本地时间戳与发送时间戳之间的时间差小于3秒，则认为接口请求合理，服务器会进行接下来的与接口请求对应的业务处理后返回响应数据至发送端。本实施通过将时间戳tm直接体现在接口请求中，方便服务器直接获取并进行时间比较，减少服务器的数据处理量，方便快捷。
另一方面，如图6至图10所示，本发明还提供一种服务器，包括：
接收单元1，用于接收发送端发送的接口请求；
验证单元2，用于获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求；
处理单元3，用于当所述验证单元判断为是时执行所述接口请求的处理事务并返回响应信息，否则不予处理并返回错误信息。
在实施时，服务器通过接收单元1接收发送端发送的接口请求，该接口请求由发送端的app进行封装生成，所述接口请求至少包括发送端的app封装的请求数据报文、发送端验证信息等，当服务器接收到接口请求时，验证单元2对所述发送端验证信息进行验证，判断该发送端验证信息是否符合预设验证要求，只有当所述发送端验证信息与预设验证要求对应匹配时，则认为该接口请求是合法请求，服务器中的处理器单元3会进行与接口请求对应的业务处理并返回响应数据至发送端，通知发送端操作成功；若服务器判断所述发送端验证信息不符合预设验证要求时，则认为该接口请求不是合法请求，处理器单元3不进行处理并返回错误信息至发送端，通知发送端操作失败，避免服务器多次接收到相同的接口请求，并根据接口请求进行多次相同的操作而出现数据库数据错乱，甚至导致服务器宕机的情况，提高用户体验。
在一个可选实施例中，如图7所示，所述验证单元2包括：
签名获取子单元21，用于获取所述接口请求中的发送端签名信息；
判断子单元22，用于判断所述发送端签名信息是否符合预设签名验证要求，若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
在实施时，所述接口请求至少包括发送端的app封装的请求数据报文、发送端签名信息等，目前app应用和服务器的通讯接口形式主要为Get和Post两种方式，这里以Get请求http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝cc为例，上述接口请求设计好签名sign的生成方式后，通过签名获取子单元21获取发送端签名信息，然后通过判断子单元22判断所述发送端签名信息是否符合预设签名验证要求，只有当接口请求中的发送端签名信息符合预设签名验证要求时，服务器才会认为该接口请求中的发送端验证信息符合预设验证要求，进而认为该接口请求是合法请求，服务器才会进行与接口请求对应的业务处理并返回响应数据至发送端，通知发送端操作成功；若不知道签名sign的生成方式，发送的接口请求中的发送端签名信息不符合预设签名验证要求，则发送接口请求是不会成功的，服务器会认为该发送端签名信息不合理，即认为该接口请求不是合法请求，服务器不进行处理并返回错误信息至发送端。能有效防止不知道签名sign的生成方式的其他人的恶意攻击。
在一个可选实施例中，如图8所示，所述判断子单元22包括：
本地时间戳获取模块221，用于获取接收到所述接口请求时的本地时间戳；
发送时间戳获取模块222，用于获取所述发送端签名信息中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
时间戳判断模块223，用于根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配，若是，则所述发送端签名信息符合预设签名验证要求，否则所述发送端签名信息不符合预设签名验证要求。
在一个实施例中，以所述接口请求http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝cc为例，通过修改签名sign的生成方式，所述签名sign为所述发送端签名信息，例如之前的签名sign的生成方式为sign＝Md5(name＝aa&type＝＝bb),修改后的签名sign＝Md5(name＝aa&type＝＝bb&tm＝1522119884)，其中tm的值为当前时间戳，服务器通过发送时间戳获取模块222获取所述发送时间戳；所述当前时间戳为发送端发送所述接口请求时的发送时间戳，修改后的发送端的app发送接口请求即http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝newcc，其中newcc为上述修改后的sign，服务器接收到发送端发送的接口请求后，服务器会根据参数name＝aa&type＝＝bb加上服务器当前时间的时间戳生成新的服务器签名newsign＝(name＝aa&type＝＝bb&tm＝1522119885)1522119885为服务器收到所述接口请求时的时间戳，即1522119885为服务器接收到所述接口请求时的本地时间戳，服务器通过本地时间戳获取模块221获取所述本地时间戳，然后通过时间戳判断模块223将所述newsign和sign的值根据预设规则进行比较，如果newsign和sign的值相匹配，则认为发送端签名信息合理，即该接口请求是合法请求，服务器会进行与接口请求对应的业务处理并返回响应数据至发送端，通知发送端操作成功。
具体地，服务器将所述newsign和sign的值根据预设规则进行比较的步骤包括，以预设时间差为3秒为例，若服务器接收到所述接口请求时的时间戳和发送端发送该接口请求时的时间戳的时间差小于预设时间差，即发送端发送该接口请求到服务器接收该接口请求的时间差小于3秒时，则认为所述发送端签名信息合理，即该接口请求是合法请求；若服务器接收到所述接口请求时的时间戳和发送端发送该接口请求时的时间戳的时间差大于预设时间差，即发送端发送该接口请求到服务器接收到给接口请求之间的时间差大于3秒，则认为newsign和sign的值不匹配，服务器重新获取newsign并与旧的sign进行对比，若经过预设次数对比后newsign和sign的值均不匹配，以所述预设次数为3次为例，当3次获取newsign且与sign对比后均不匹配，则认为所述发送端签名信息不合理，即该接口请求不是合法请求，服务器不进行处理。当然，所述预设时间差和预设次数的数值不做具体限定，时间戳没有体现在发送端的接口请求中，提高获取sign的生成方式的难度，避免被恶意多次发生该接口请求。
在一个可选实施例中，如图9所示，所述时间戳判断模块223包括：
随机值获取子模块2231，用于获取所述接口请求中的随机值信息；
合并子模块2232，用于根据所述发送时间戳和所述随机值信息拼接成秘钥信息；
秘钥判断子模块2233，用于判断所述秘钥信息是否与预设缓存中的数据匹配，若是，则本地时间戳与所述发送时间戳不匹配，否则所述本地时间戳与所述发送时间戳匹配，并将所述秘钥信息存入所述预设缓存中。
在实施时，发送端的app封装接口请求还包括随机值信息，具体地，以app封装接口请求http://x.x.x.x/add.do？name＝aa&type＝＝bb&sign＝cc为例，其中，sign为发送端签名信息，通过添加额外的时间戳tm和随机值信息rad＝rand(0,1000)得到：http://x.x.x.x/add.do？name＝aa&type＝＝bb&tm＝1522119885&rad＝100，生成的签名sign的值newcc拼接成app的接口请求为：http://x.x.x.x/add.do？name＝aa&type＝＝bb&tm＝1522119885&rad＝100&sign＝newcc，服务器接收到发送端的app封装生成的接口请求，服务器先验证签名sign是否合理，即所述签名sign是否符合预设签名验证要求，若不合理则认为该接口请求不合理，不予处理并直接返回请求错误信息；若签名sign合理，服务器接下来解析接口请求获取时间戳tm的值，并与服务器当前的本地时间戳进行对比，若相差时间大于3秒，则认为接口请求为无效请求，并重新接收发送端发送的接口请求，若3次接收到的接口请求均为无效请求，返回通知错误信息至发送端；若在3次内有匹配成功则进行以下步骤。
服务器通过随机值获取子模块2231获取随机值信息rad，然后通过合并子模块2232拼接时间戳tm和随机值信息rad的值作为秘钥信息key(1522119885100)，再通过秘钥判断子模块2233在redis缓存中查找是否已经存在这个值了，即判断所述秘钥信息key是否与预设缓存中中的数据匹配，如果已经存在这个值了，则认为接口请求为重复请求，服务器不予处理并通知发送端错误信息；如果在redis缓存中不存在这个值，则认为该接口请求是第一次请求，并且是有效请求，服务器会把秘钥信息key存入redis缓存中，然后执行与接口请求对应的处理事务，然后通知发送端的app操作成功。即使相同的接口请求在很短的时间内多次发送，依然能够有效的进行防范，能有效减少服务器对无效请求的操作，所述redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
在一个可选实施例中，如图10所示，所述验证单元2包括：
本地签名获取子单元23，用于获取接收到所述接口请求时的本地时间戳；
发送签名获取子单元24，获取所述接口请求中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
签名判断子单元25，用于根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配，若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
在实施时，发送端的app封装接口请求http://x.x.x.x/add.do？name＝aa&type＝＝bb&tm＝1522119884&sign＝cc为例，服务器通过发送签名获取子单元24接收该接口请求并解析该接口请求获取时间戳tm，所述时间戳tm为发送端发送所述接口请求时的发送时间戳，然后通过本地签名获取子单元23获取服务器接收到所述接口请求时的本地时间戳，再通过签名判断子单元25根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配，具体地，以预设时间差为3秒以及预设次数为3次为例，服务器判断所述本地时间戳和发送时间戳之间是否超过预设时间差，即所述本地时间戳和发送时间戳之间的时间差是否超过3秒，若是，则认为所述接口请求不合理，再次重复上述操作3次，若3次获取的本地时间戳与发送时间戳之间均超过3秒，则服务器返回请求错误信息；若在规定的预设次数内有匹配成功，即在3次内有任意一次本地时间戳与发送时间戳之间的时间差小于3秒，则认为接口请求合理，服务器会进行接下来的与接口请求对应的业务处理后返回响应数据至发送端。时间戳直接体现在接口请求中，方便服务器直接进行时间比较，方便快捷。
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种app接口防重放方法，其特征在于，包括：
接收发送端发送的接口请求；
获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求；
若是，则执行所述接口请求的处理事务并返回响应信息，否则不予处理并返回错误信息。
2.根据权利要求1所述的app接口防重放方法，其特征在于，所述获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求的步骤，包括：
获取所述接口请求中的发送端签名信息；
判断所述发送端签名信息是否符合预设签名验证要求；
若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
3.根据权利要求2所述的app接口防重放方法，其特征在于，所述判断所述发送端签名信息是否符合预设签名验证要求的步骤，包括：
获取接收到所述接口请求时的本地时间戳；
获取所述发送端签名信息中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配；
若是，则所述发送端签名信息符合预设签名验证要求，否则所述发送端签名信息不符合预设签名验证要求。
4.根据权利要求3所述的app接口防重放方法，其特征在于，所述根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配的步骤，包括：
获取所述接口请求中的随机值信息；
根据所述发送时间戳和所述随机值信息拼接成秘钥信息；
判断所述秘钥信息是否与预设缓存中的数据匹配；
若是，则所述本地时间戳与所述发送时间戳不匹配，否则所述本地时间戳与所述发送时间戳匹配，并将所述秘钥信息存入所述预设缓存中。
5.根据权利要求1所述的app接口防重放方法，其特征在于，所述获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求的步骤，包括：
获取接收到所述接口请求时的本地时间戳；
获取所述接口请求中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配；
若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
6.一种服务器，其特征在于，包括：
接收单元，用于接收发送端发送的接口请求；
验证单元，用于获取所述接口请求中的发送端验证信息，并验证所述发送端验证信息是否符合预设验证要求；
处理单元，用于当所述验证单元判断为是时执行所述接口请求的处理事务并返回响应信息，否则不予处理并返回错误信息。
7.根据权利要求6所述的服务器，其特征在于，所述验证单元包括：
签名获取子单元，用于获取所述接口请求中的发送端签名信息；
判断子单元，用于判断所述发送端签名信息是否符合预设签名验证要求，若是，则所述发送端验证信息符合预设签名验证要求，否则所述发送端验证信息不符合预设签名验证要求。
8.根据权利要求7所述的服务器，其特征在于，所述判断子单元包括：
本地时间戳获取模块，用于获取接收到所述接口请求时的本地时间戳；
发送时间戳获取模块，用于获取所述发送端签名信息中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
时间戳判断模块，用于根据第一预设规则判断所述本地时间戳与所述发送时间戳是否匹配，若是，则所述发送端签名信息符合预设签名验证要求，否则所述发送端签名信息不符合预设签名验证要求。
9.根据权利要求8所述的服务器，其特征在于，所述时间戳判断模块包括：
随机值获取子模块，用于获取所述接口请求中的随机值信息；
合并子模块，用于根据所述发送时间戳和所述随机值信息拼接成秘钥信息；
秘钥判断子模块，用于判断所述秘钥信息是否与预设缓存中的数据匹配，若是，则本地时间戳与所述发送时间戳不匹配，否则所述本地时间戳与所述发送时间戳匹配，并将所述秘钥信息存入所述预设缓存中。
10.根据权利要求6所述的服务器，其特征在于，所述验证单元包括：
本地签名获取子单元，用于获取接收到所述接口请求时的本地时间戳；
发送签名获取子单元，用于获取所述接口请求中的发送时间戳，所述发送时间戳为发送端发送所述接口请求时的时间戳；
签名判断子单元，用于根据第二预设规则判断所述本地时间戳与所述发送时间戳是否匹配，若是，则所述发送端验证信息符合预设验证要求，否则所述发送端验证信息不符合预设验证要求。
CN201810422092.0A 2018-05-04 2018-05-04 app接口防重放方法及服务器 Pending CN108667617A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810422092.0A CN108667617A (zh) 2018-05-04 2018-05-04 app接口防重放方法及服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810422092.0A CN108667617A (zh) 2018-05-04 2018-05-04 app接口防重放方法及服务器

Publications (1)

Publication Number Publication Date
CN108667617A true CN108667617A (zh) 2018-10-16

Family

ID=63781887

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810422092.0A Pending CN108667617A (zh) 2018-05-04 2018-05-04 app接口防重放方法及服务器

Country Status (1)

Country Link
CN (1) CN108667617A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109857575A (zh) * 2019-01-18 2019-06-07 深圳壹账通智能科技有限公司 接口调用方法、装置、电子设备及存储介质
CN109862076A (zh) * 2018-12-30 2019-06-07 贝壳技术有限公司 一种业务数据交互方法、装置和***
CN113225348A (zh) * 2021-05-19 2021-08-06 中国建设银行股份有限公司 请求防重放校验方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160337130A1 (en) * 2014-03-20 2016-11-17 Blackberry Limited Method for validating messages
CN107135073A (zh) * 2016-02-26 2017-09-05 北京京东尚科信息技术有限公司 接口调用方法和装置
CN107483459A (zh) * 2017-08-29 2017-12-15 四川长虹电器股份有限公司 防重放攻击的接口保护方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160337130A1 (en) * 2014-03-20 2016-11-17 Blackberry Limited Method for validating messages
CN107135073A (zh) * 2016-02-26 2017-09-05 北京京东尚科信息技术有限公司 接口调用方法和装置
CN107483459A (zh) * 2017-08-29 2017-12-15 四川长虹电器股份有限公司 防重放攻击的接口保护方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109862076A (zh) * 2018-12-30 2019-06-07 贝壳技术有限公司 一种业务数据交互方法、装置和***
CN109862076B (zh) * 2018-12-30 2022-05-03 贝壳技术有限公司 一种业务数据交互方法、装置和***
CN109857575A (zh) * 2019-01-18 2019-06-07 深圳壹账通智能科技有限公司 接口调用方法、装置、电子设备及存储介质
CN113225348A (zh) * 2021-05-19 2021-08-06 中国建设银行股份有限公司 请求防重放校验方法和装置
CN113225348B (zh) * 2021-05-19 2023-04-07 中国建设银行股份有限公司 请求防重放校验方法和装置

Similar Documents

Publication Publication Date Title
CN112994892B (zh) 跨链交互方法、装置、***和电子设备
CN101753374B (zh) 服务器对服务器的完整性检查
CN108667617A (zh) app接口防重放方法及服务器
CN108462758A (zh) 银企直联通信方法、装置、设备及计算机可读存储介质
CN108390881A (zh) 一种分布式高并发实时消息推送方法及***
CN110266642A (zh) 身份认证方法及服务器、电子设备
CN107545031A (zh) 账户综合查询服务、***及计算机可读存储介质
CN102413126B (zh) 一种银行卡交易前置设备的密钥同步方法及***
CN108388802A (zh) 一种脚本注入攻击的告警方法及告警***
CN114239072B (zh) 区块链节点管理方法及区块链网络
CN105704133A (zh) 数据同步的方法、终端及服务器
CN102790757B (zh) 用于网络交易的使用者身份识别方法与***
CN114157693A (zh) 通信设备的上电认证方法、通信模块和服务器
CN106355496A (zh) 实现批量电子交易的方法、***和装置以及电子签名工具
CN112953720A (zh) 一种网络请求处理方法、装置、设备及存储介质
CN109214189B (zh) 识别程序漏洞的方法、装置、存储介质和电子设备
CN113922952B (zh) 访问请求响应方法、装置、计算机设备和存储介质
CN101425925B (zh) 提供数据通信认证的方法、***和设备
CN114449520A (zh) 一种银行流水的远程获得方法及装置
CN116910704A (zh) 一种数据平台的许可校验方法、装置、设备及介质
CN109376508A (zh) 业务单元的管理方法、计算机可读存储介质和终端设备
CN112445594B (zh) 安全文件传输工具的切换方法、装置、计算机设备和介质
CN117353975B (zh) 基于企业微信的多终端安全统一登录授权***及方法
CN115242478B (zh) 一种提升数据安全的方法、装置、电子设备及存储介质
CN202261385U (zh) 一种银行卡交易前置设备的密钥同步***

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20181016

RJ01 Rejection of invention patent application after publication