CN116865980A - Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface - Google Patents

Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface Download PDF

Info

Publication number
CN116865980A
CN116865980A CN202311134517.5A CN202311134517A CN116865980A CN 116865980 A CN116865980 A CN 116865980A CN 202311134517 A CN202311134517 A CN 202311134517A CN 116865980 A CN116865980 A CN 116865980A
Authority
CN
China
Prior art keywords
signature
request
sha
data
hash value
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
CN202311134517.5A
Other languages
Chinese (zh)
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.)
Hangzhou Bizhi Technology Co ltd
Original Assignee
Hangzhou Bizhi Technology 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 Hangzhou Bizhi Technology Co ltd filed Critical Hangzhou Bizhi Technology Co ltd
Priority to CN202311134517.5A priority Critical patent/CN116865980A/en
Publication of CN116865980A publication Critical patent/CN116865980A/en
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/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
    • 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
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp

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)
  • Storage Device Security (AREA)

Abstract

The invention discloses a method and a system for realizing tamper resistance based on a SHA-256 hash algorithm interface added with a signature, wherein the method comprises the following steps: s1, a sender receives a request and starts signature verification; s2, proxy XMLHttpRequest object and fetch object; s3, acquiring a request body; s4, calculating a signature, modifying two objects of XMLHttpRequest and fetch, adding a SHA-256 hash value as the signature, and sending the signature and request data to a receiver; s5, the receiving party receives the request data and the signature, carries out the same SHA-256 hash operation on the received request data, and generates a new hash value; s6, comparing the new hash value with the received signature, if the hash value is consistent, forwarding the request, and if the hash value is inconsistent, alarming. The signature mechanism ensures the integrity and the authenticity of the data in the transmission and interaction processes, prevents the occurrence of simulated tampering behaviors, and improves the trust degree of the user on the security of the interface.

Description

Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface
Technical Field
The invention relates to the technical field of computer networks and data processing, in particular to a method and a system for realizing tamper resistance based on signature added to an SHA-256 hash algorithm interface.
Background
In the modern digital age, information security and data integrity become critical. As more and more traffic and services move to the internet and networked environments, it becomes important to protect the integrity of data and communications from tampering. Interface tamper resistance is a critical task that ensures the integrity and security of the interface during data transmission and interaction.
Conventional tamper-resistant methods often rely on encryption and security protocols, but these methods have limitations in protecting the integrity of the interface. An attacker can bypass these security measures by tampering with the data packet or masquerading the request, resulting in unauthorized access or malicious tampering.
The interface risks analog tampering due to the lack of signature mechanisms. During transmission and interaction, unauthorized entities can easily forge or tamper with the data packets, resulting in the integrity of the data being compromised. Such simulated tampering may cause the following problems:
data integrity corruption: an unauthorized entity may intercept, modify, or replace data packets on the transmission path, resulting in the integrity of the data being compromised. The receiver cannot determine whether the received data has been tampered with, and thus cannot trust the authenticity of its content.
Examples:
it is assumed that an interface of an e-commerce web site is provided for updating personal information of a user. An attacker modifies the user's email address by tampering with parameters in the request.
Pseudo code example:
original request #
The interface address is/api/update-profile for the/(POST request)
POST/api/update-profile
The// request header parameters: request type-json
Content-Type:application/json
Request parameters
{
"user_id":"12345",
"email":"user@example.com"
}
Request after # tampering
The interface address is/api/update-profile for the/(POST request)
POST/api/update-profile
The// request header parameters: request type-json
Content-Type:application/json
Request parameters
{
"user_id":"12345",
The user mailbox is defined by user@example.com,
modified to attacker@example.co
"email": "attacker@example.com" # modify user mailbox
}
Identity disguising: the lack of a signature mechanism enables an attacker to masquerade as an authorized entity to send requests. Such identity masquerading may result in unauthorized access so that an attacker may perform unauthorized operations or obtain sensitive information.
Examples:
it is assumed that an interface of a banking application is provided for transfer operations. An attacker tries to disguise as other users, send malicious transfer requests, and transfer funds to the attacker's own account.
Pseudo code example:
request of # legal user
The interface address is/api/transfer for the/(POST request)
POST/api/transfer
The// request header parameters: check field, user token
Authorization:Bearer<valid_token>
The// request header parameters: request type-json
Content-Type:application/json
The// request parameters:
{
"recipient_id":"98765",
"amount":100.0
}
request masquerade by # attacker
The interface address is/api/transfer for the/(POST request)
POST/api/transfer
The// request header parameters: check field, user token
/(attacker hijacking interface, obtaining user token, forging request)
Authorization:Bearer<valid_token>
The// request header parameters: request type-json
Content-Type:application/json
Request parameters for/(falsification)
{
"receiver_id": "12345", # attacker-specified beneficiary account
"amounto" 1000.0# attacker tries to transfer a larger amount
}
In the above example, the attacker uses a valid access token (token), but masquerades as the other user sends transfer requests. The attacker deliberately alters the beneficiary account and transfer amount in the request in an attempt to transfer funds to his own account.
Such identity masquerading may result in unauthorized funds transfer and theft. To prevent identity masquerading attacks, banking applications should take measures such as forcing double identity verification, enforcing transaction restrictions or risk assessment, etc., to ensure that only authorized users can perform transfer operations and to monitor abnormal activities as well as malicious transfer actions.
Data security threat: simulating tampering may result in data leakage or theft. An attacker may tamper with sensitive information in the data packet, for example, modify the transaction amount or modify command parameters, thereby causing damage to the system or theft of sensitive data.
Examples:
an interface of a payment system is provided for processing transaction requests and transferring funds to a designated collection account. The attacker transfers funds to his own account by tampering with the transaction amount in the request, rather than a legitimate collection account.
Pseudo code example:
request of # legal user
The interface address is/api/process-transaction for the/(POST request)
POST/api/process-transaction
The// request header parameters: check field, user token
Authorization:Bearer<valid_token>
The// request header parameters: request type-json
Content-Type:application/json
The// request parameters:
{
"transaction_id":"12345",
"amount":100.0,
"recipient_account":"valid_recipient_account"
}
request for tampering by # attacker
The interface address is/api/process-transaction for the/(POST request)
POST/api/process-transaction
The// request header parameters: check field, user token
Authorization:Bearer<valid_token>
The// request header parameters: request type-json
Content-Type:application/json
Request parameters for/(falsification)
{
"transaction_id":"12345",
"amounto" 100000.0, # attacker deliberately modifies the amount to a larger value
"receiver_account": an account specified by an "attacker_account" # attacker
}
In the above example, the attacker uses a valid access token (token), but tampers with the transaction amount and the collection account in the transaction request. The attacker deliberately modifies the amount to a larger value and designates his own account as the collection account in order to transfer funds to his own account.
Such data security threats may result in lost funds and inaccuracy of the transaction data. To prevent such attacks, the payment system should verify and validate the transaction data at the server and implement appropriate restrictions and risk assessment mechanisms. For example, comparing the rationality between the transaction amount and the user account balance ensures that the transaction amount is within an acceptable range and additional authentication and authorization checks are performed to ensure that only authorized users can perform the transaction operation.
Furthermore, for critical operations, such as funds transfer, additional security layers should be employed, such as using two-factor authentication, using secure encrypted communication protocols and storage schemes, to protect the security of sensitive data.
By introducing a signature mechanism, the scheme of the invention aims to solve the problems and provide strong interface tamper-proof protection. The signature mechanism ensures the integrity and the authenticity of the data in the transmission and interaction processes, prevents the occurrence of simulated tampering behaviors, and improves the trust degree of the user on the security of the interface.
Disclosure of Invention
Aiming at the problems existing in the prior art, the invention aims to provide a method for realizing tamper resistance based on the signature added to an SHA-256 hash algorithm interface, which solves the challenges of interface security and data integrity faced by the digital age. The traditional tamper-resistant method has limitations and cannot provide strong protection for data integrity and authenticity in the interface transmission and interaction process.
In order to achieve the above purpose, the invention provides a method for realizing tamper resistance based on adding a signature to an SHA-256 hash algorithm interface, which comprises the following steps:
s1, a sender receives a request and starts signature verification;
s2, acquiring a time stamp and a signature from the request head; proxy XMLHttpRequest object and fetch object;
s3, acquiring a request body;
s4, calculating a signature, modifying two objects of XMLHttpRequest and fetch, adding a SHA-256 hash value as the signature, and sending the signature and request data to a receiver;
s5, the receiving party receives the request data and the signature, carries out the same SHA-256 hash operation on the received request data, and generates a new hash value;
s6, comparing the new hash value with the received signature, if the hash value is consistent, forwarding the request, and if the hash value is inconsistent, alarming.
Further, in step S2, the following steps are included:
s2.1, agent xmlHttpRequest object;
s2.2. proxy fetch object.
Further, step s2.1. the proxy xmlHttpRequest object further comprises:
s2.1.1 determines whether a signature agent has been implemented;
s2.1.2, proxy ajax object, open obtains url and method;
s2.1.3, proxy ajax object, signature is added in send method;
s2.1.4, generating a time stamp;
s2.1.5, calling setrequest Header;
s2.1.6, adding a custom field X-Signature into a request header, and transmitting the generated hash Signature;
s2.1.7, adding a custom timestamp field into the request header;
s2.1.8. perform send operation.
Further, the s2.2. proxy fetch object includes:
s2.2.1 determines if a fetch agent already exists;
s2.2.2 generates a timestamp;
s2.2.3 JSON serialization is performed as signed content based on body content;
s2.2.4 request header adds custom field X-Signature, and transmits generated hash Signature;
s2.2.5 requests that the header add a custom timestamp field.
Further, for the sender, the sender first generates SHA-256 hash values using the interface request data; the generated hash value is used as a signature and transmitted to the receiving side together with the request data.
Further, for the receiver, the receiver receives the request data and the signature, and the receiver performs the same SHA-256 hash operation on the received request data to generate a new hash value, and the new hash value is compared with the received signature.
Further, the verification process is as follows:
if the newly generated hash value is matched with the received signature, the verification is passed, and the fact that the data is not tampered in the transmission process is indicated;
if the newly generated hash value does not match the received signature, then verification fails, indicating that the data may have been tampered with or corrupted.
Further, both the modified objects XMLHttpRequest and fetch are javascript apis for making network data requests for data transfer between clients and servers.
Further, XMLHttpRequest is a client network request object that sends asynchronous requests and can handle server responses by listening for events; fetch is a network request API supporting Promise for processing response data. In another aspect, the present invention provides a system for implementing tamper resistance based on SHA-256 hash algorithm interface adding a signature, the system being configured to implement the method according to the present invention.
The beneficial effects of the invention are as follows:
the techniques of the present invention provide a more advanced tamper-resistant protection of interfaces; the scheme combines digital signature technology and a data integrity verification mechanism to ensure the integrity and authenticity of the interface in the transmission and interaction processes. By adding signature and verification mechanisms to the data packets, tampering can be effectively prevented and it is ensured that only authorized entities can access and operate the interface.
Drawings
FIG. 1 is a flow chart of a method for implementing tamper resistance based on SHA-256 hash algorithm interface signature addition in accordance with the present invention;
fig. 2 shows a flow chart of a request from a client to a server with a signature carried by an interface according to an embodiment of the invention.
Detailed Description
The following description of the embodiments of the present invention will be made more apparent and fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
In the description of the present invention, it should be noted that the directions or positional relationships indicated by the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. are based on the directions or positional relationships shown in the drawings, are merely for convenience of describing the present invention and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a specific orientation, be configured and operated in a specific orientation, and thus should not be construed as limiting the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.
In the description of the present invention, it should be noted that, unless explicitly specified and limited otherwise, the terms "mounted," "connected," and "connected" are to be construed broadly, and may be either fixedly connected, detachably connected, or integrally connected, for example; can be mechanically or electrically connected; can be directly connected or indirectly connected through an intermediate medium, and can be communication between two elements. The specific meaning of the above terms in the present invention can be understood by those of ordinary skill in the art according to the specific circumstances.
The following describes embodiments of the present invention in detail with reference to fig. 1-2. It should be understood that the detailed description and specific examples, while indicating and illustrating the invention, are not intended to limit the invention.
The invention provides a method for realizing tamper resistance based on adding signature to SHA-256 hash algorithm interface, which adopts two objects of modified XMLHttpRequest and fetch and adds SHA-256 hash value as signature to realize tamper resistance technology of interface. By signature verification of the data request and the response, the integrity and the authenticity of the data in the transmission and interaction processes are ensured, so that unauthorized access and data tampering are effectively prevented.
As shown in fig. 1, the method for realizing tamper resistance based on the SHA-256 hash algorithm interface signature addition according to the invention comprises the following steps:
s1, a sender initiates a request and starts signature verification; the specific implementation is as follows:
（
XMLHttpRequest：
XMLHttpRequest is a traditional client network request object that is widely used in earlier Web development.
It needs to call the open () method to configure the request parameters and then call the send () method to trigger the actual request transmission when sending the request.
After the request is sent, the server's response and state changes may be handled by listening for events (e.g., onreadystatechange and onload events).
fetch：
fetch is a new generation of network request APIs recommended for use in modern Web development.
The method uses Promise and chained calling modes, and is simpler and more flexible.
When a request is sent, only a fetch function is required to be called, and the URL and configuration parameters of the request are input, for example:
fetch(url,options)
.then(response=>{
response data is/are processed
})
.catch(error=>{
Request error handling/handling
});
S2, acquiring a time stamp and a signature from the request head; proxy XMLHttpRequest object and fetch object;
in the present invention, the two objects modified are XMLHttpRequest and fetch, respectively. Both of these objects are JavaScript APIs for making network data requests for data transfer between the client and the server. Their function is to send requests to the server and receive response data.
XMLHttpRequest: is a traditional client network request object and is widely used in early Web development. It can send asynchronous requests without refreshing the entire page and can process the server's response by listening for events. And (3) fetch: is a new generation of network request API recommended for use in modern Web development. The fetch API provides a more compact and flexible usage, supports Promise, and is easier to process response data. In the invention, the improvement technology specifically proposed is to modify the two objects so as to realize the purpose of tamper resistance of the interface. The original XMLHttpRequest and fetch requests do not have signature verification when sending data and are therefore vulnerable to data tampering. The invention modifies the two objects and adds the SHA-256 hash value as the signature, thereby ensuring the integrity and the authenticity of the data in the transmission process.
S3, acquiring a request body; the method comprises the following steps:
the XMLHttpRequest object gets the requestor:
the XMLHttpRequest object is/is proxy to obtain the request parameters in the send method
const proxiedSend=XMLHttpRequest.prototype.send;
Method for copying/copying original send
XMLHttpRequest.prototype.send=function(...args:any[]){
let stringify='';
The// determination method, if it is a GET request, does not add a signature
if(method!=='GET'&&!(args[0]instanceof FormData)){
Obtaining request body by parameter arg [0] of send method
stringify=args[0] '';
}
};
};
fetch object acquisition request body:
constfetchProxy=function(fetch){
return async function(...args:any[]){
let stringify='';
try {
if there is no body, the error will be reported
Parameter args according to request function
The// args [0] is the request body
const r = await args[0]?.clone()?.json();
Based on body content, JSON serialization is performed as signed content
stringify = JSON.stringify(r);
} catch (e) {}
};
};
S4, calculating a signature, modifying two objects of XMLHttpRequest and fetch, adding a SHA-256 hash value as the signature, and sending the signature and request data to a receiver;
s5, the receiving party receives the request data and the signature, carries out the same SHA-256 hash operation on the received request data, and generates a new hash value;
s6, comparing the new hash value with the received signature, if the hash value is consistent, forwarding the request, and if the hash value is inconsistent, alarming.
Specifically, in step S2, the following steps are included:
s2.1, agent xmlHttpRequest object;
s2.2. proxy fetch object.
Wherein step s2.1 the proxy xmlHttpRequest object further comprises:
s2.1.1 determines whether a signature agent has been implemented;
s2.1.2, proxy ajax object, open obtains url and method;
s2.1.3, proxy ajax object, signature is added in send method;
s2.1.4, generating a time stamp;
s2.1.5, calling setrequest Header;
s2.1.6, adding a custom field X-Signature into a request header, and transmitting the generated hash Signature;
s2.1.7, adding a custom timestamp field into the request header;
s2.1.8. perform send operation.
The code script of the proxy xmlHttpRequest object is as follows:
const xmlHttpRequestProxy = function (XMLHttpRequest) {
a determination is made as to whether a signature proxy has been implemented, skipping if xmlHttpRequest proxy already exists
if (window.xmlHttpRequestProxy) {
return null;
}
window.xmlHttpRequestProxy = true;
The// proxy ajax object, open get url and method
const proxiedOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function (...args: any[]) {
Variable of// save this
const that = this;
The url of the/save request, which will be part of the serialized data
that['x-url'] = args[1];
Method of/(and preservation request (GET, POST)
The operations are different for different methods
that.method = args[0];
The method of the original open is returned, and the modified parameters and the this object are returned
return proxiedOpen.apply(this, Array.from(args));
};
The input method adds signature to the/proxy ajax object
const proxiedSend = XMLHttpRequest.prototype.send;
XMLHttpRequest.prototype.send = function (...args: any[]) {
const that = this;
Time stamp generation
const timeStamp = String(new Date().getTime());
Request url saved in the/(fetch open method)
const xUrl = that['x-url'];
Method/acquisition (POST, get.)
const { method } = that;
Creation of url copies
let url = xUrl;
If the url contains a protocol, the protocol + domain name field (http, https) is removed
if (xUrl.startsWith('http')) {
Obtaining origin field by// parsing url
const { origin } = new URL(xUrl);
Example/:
// xUrl = http://www.baidu.com/request/apiaaa=value1&bbb=value2
// origin = http://www.baidu.com
url = url.replace(origin, '').trim();
// url =/request/apiaaa=value1&bbb=value2
}
the input/output of the variable is used for storing the data carried by the request head
let stringify = '';
Obtaining the requestor through args [0] when the method of the request is not GET and the requestor is not FormData type data
Request of the// GET mode, parameters on url, parameters are automatically obtained from variable url
The data in the// FormData format is not modifiable and may not be encrypted
if (method !== 'GET' && !(args[0] instanceof FormData)) {
stringify = args[0] '';
}
Determining if the URL is serialized, if not, serializing URL
The function of the// serialization is to prevent the server from receiving Chinese messy codes
if (decodeURIComponent(url) === url) {
url = customEncodeUri(url);
}
The method refers to XMLHttpRequest Standard by// calling setrequest header
The// needs to be invoked between open and send methods, so proxy send method
After// invoking setrequest Header, send operation is performed
The// request header adds custom field X-Signature, passing the generated hash Signature
that.setRequestHeader('X-Signature', sha256(`${url}${timeStamp}${stringify}`));
Addition of custom timestamp field to the request header
that.setRequestHeader('X-Timestamp', timeStamp);
Execution of true send operation
return proxiedSend.apply(this, Array.from(args));
};
};
Further, the s2.2. proxy fetch object includes:
s2.2.1 determines if a fetch agent already exists;
s2.2.2 generates a timestamp;
s2.2.3 JSON serialization is performed as signed content based on body content;
s2.2.4 request header adds custom field X-Signature, and transmits generated hash Signature;
s2.2.5 requests that the header add a custom timestamp field.
The code script of the proxy fetch object is as follows:
const fetchProxy = function (fetch) {
return async function (...args: any[]) {
a// determination is made as to whether a fetch agent already exists, if so, no more agents are available
if (window?.fetchProxy) {
return fetch.apply(this, args);
}
Adding fetchProxy to global variable window to mark whether encrypted data has been carried
window.fetchProxy = true;
Time stamp generation
const timeStamps = new Date().getTime();
let stringify = '';
try {
If there is no body, the error will be reported
const r = await args[0]?.clone()?.json();
Based on body content, JSON serialization is performed as signed content
stringify = JSON.stringify(r);
} catch (e) {}
const { url } = args[0];
The// request header adds custom field X-Signature, passing the generated hash Signature
args[0].headers.append('X-Signature', sha256(`${uri}${timeStamps}${stringify}`));
Addition of custom timestamp field to the request header
args[0].headers.append('X-Timestamp', String(timeStamps));
return fetch.apply(this, args);
};
};
S4, calculating a signature, modifying two objects of XMLHttpRequest and fetch, and adding a SHA-256 hash value as the signature; comprising the following steps:
s4.1 adding a time stamp as part of the data
S4,2, realizing the same interface, wherein the generated signatures are different when the interfaces are called for multiple times;
s4.3, signature generation, namely acquiring url and body of the request, performing hash operation, and performing sha-256 to generate a hash character string according to the time stamp and the parameters;
the code is as follows:
time stamp is added as part of the data
And the same interface is realized, and the generated signature is different when the interface is called for multiple times, so that the counterfeit signature is prevented.
const timeStamp = new Date().getTime();
The generation of the/signature is mainly to acquire url and body of the request and perform a hash operation
Tamper-proof url and body information
const Signature = sha256(url+timeStamp+body);
In addition, ensuring security of access tokens (token) is also critical. The token should be properly encrypted and protected and updated periodically to prevent theft or misuse by an attacker.
User tamper resistant functionality based on SHA-256 example one:
the interface address is/api/transfer for the/(POST request)
POST /api/transfer
The// request header parameters: check field, user token
Authorization: Bearer <valid_token>
The// request header parameters: request type-json
Content-Type: application/json
The// request parameters:
{
"recipient_id": "98765",
"amount": 100.0
}
the// request header parameters: signature generated based on sha-256, request parameters and time stamps
X-Signature：04f65eb4579f5e460e76cc7fa241c08791f7adc89ff
6640b0ab79abf6b46c21b
The// request header parameters: timestamp at request initiation
X-Timestamp:1690184728297。
According to the X-Timestamp and the parameter, sha-256 is conducted to generate a hash character string, and the back-end interface takes the X-Timestamp and the parameter to generate the hash character string according to the same mode to see whether the two character strings are matched.
If an attacker takes a token to request forgery:
the interface address is/api/transfer for the/(POST request)
POST /api/transfer
The// request header parameters: check field, user token
Authorization: Bearer <valid_token>
The// request header parameters: request type-json
Content-Type: application/json
Request parameters for/(falsification)
{
"receiver_id": "12345", # attacker-specified beneficiary account
"amounto" 1000.0# attacker tries to transfer a larger amount
}
The// request header parameters: signature generated based on sha-256, request parameters and time stamps
X-Signature：04f65eb4579f5e460e76cc7fa241c08791f7adc89ff
6640b0ab79abf6b46c21b
The// request header parameters: timestamp at request initiation
X-Timestamp:1690184728297。
The backend performs a hash generation string (1 f7c3a12982cc988028a63b5ca34e57dc373c01cf6f5ccf4d1a67d539355a53 f) through the X-Timestamp and the parameters, and finds that the parameters do not match with the X-Signature, and proves that the request is illegal. The request is denied.
That is, an attacker cannot modify the request parameters even if he takes the user token. Preventing funds from being transferred to its own account.
Interface data security detection based on SHA-256 implementation example two:
the interface address is/api/process-transaction for the/(POST request)
POST /api/process-transaction
The// request header parameters: check field, user token
Authorization: Bearer <valid_token>
The// request header parameters: request type-json
Content-Type: application/json
The// request parameters:
{
"transaction_id": "12345",
"amount": 100.0,
"recipient_account": "valid_recipient_account"
}
the// request header parameters: signature generated based on sha-256, request parameters and time stamps
X-Signature：e7c30734818562da6121ca19d0710bb0889ab50
9aa40ddb6aca21f16a2e768d1
The// request header parameters: timestamp at request initiation
X-Timestamp:1690184728297。
According to the X-Timestamp and the parameter, sha-256 is conducted to generate a hash character string, and the back-end interface takes the X-Timestamp and the parameter to generate the hash character string according to the same mode to see whether the two character strings are matched.
The interface address is/api/process-transaction for the/(POST request)
POST /api/process-transaction
The// request header parameters: check field, user token
Authorization: Bearer <valid_token>
The// request header parameters: request type-json
Content-Type: application/json
Request parameters for/(falsification)
{
"transaction_id": "12345",
"amounto" 100000.0, # attacker deliberately modifies the amount to a larger value
"receiver_account": an account specified by an "attacker_account" # attacker
}
The// request header parameters: signature generated based on sha-256, request parameters and time stamps
X-Signature：e7c30734818562da6121ca19d0710bb0889ab50
9aa40ddb6aca21f16a2e768d1
The// request header parameters: timestamp at request initiation
X-Timestamp:1690184728297。
The back end performs a hash generation string (9 f19da775ee7f9441080877513dcc88eb6cd086fac3acaacf06f4a1a745e 2029) verification through the X-Timestamp and the parameters, and finds that the parameters do not match with the X-Signature parameters, and then proves that the request is illegal and refuses the request.
As shown in fig. 2, the flow of the request from the interface carrying signature client to the server is as follows:
1. the sender:
the sender first generates SHA-256 hash values using the interface request data.
The generated hash value is used as a signature and transmitted to the receiving side together with the request data.
2. The receiving side:
the receiving party receives the request data and the signature.
The receiver performs the same SHA-256 hash operation on the received request data to generate a new hash value.
The new hash value is compared to the received signature.
3. The verification process comprises the following steps:
if the newly generated hash value matches the received signature, then verification passes, indicating that the data has not been tampered with during transmission.
If the newly generated hash value does not match the received signature, then verification fails, indicating that the data may have been tampered with or corrupted.
The SHA-256 signature is tamper-resistant with the advantage that:
powerful tamper resistance: SHA-256 is a hash algorithm with high encryption strength, and can effectively prevent tampering attacks. Even minor changes to the input data can result in disparate hash values, thereby quickly detecting tampering with the data.
And (3) fast calculating speed: the SHA-256 has relatively high calculation speed and is suitable for high-efficiency real-time verification and tamper-proof requirements.
Security is widely accepted: SHA-256 is a well-known security algorithm and is widely used in many security protocols and applications with high security and reliability.
Compared with the MD5 encryption mode, the SHA-256 has the following advantages:
the safety is higher: SHA-256 is a more powerful hash algorithm that is more secure against MD 5. MD5 has proven to have some security holes and can generate the same hash value by collision attacks, thus reducing the integrity protection of the data. While SHA-256 has higher collision resistance and lower collision probability, greatly enhancing the data integrity verification capability.
The hash length is longer: SHA-256 generates a hash value of 256 bits in length, in contrast to MD5 which is only 128 bits in length. The long hash length makes SHA-256 more difficult to crack and violently crack, increasing the difficulty of an attacker to generate the same hash value.
The anti-collision capability is stronger: SHA-256 is designed to take into account more safety and collision resistance. The method adopts a more complex algorithm structure and more iteration times to increase the randomness of the hash value of the data and reduce the possibility of generating the same hash value.
Extensive support and application: SHA-256 is a well-known security algorithm and is widely supported and applied in a variety of security protocols and applications. Many security standards and encryption protocols employ SHA-256 as a standard algorithm for data integrity verification and tamper resistance.
The invention has the technical advantages that:
the core technology of the invention is to use SHA-256 (Secure Hash Algorithm 256-bit) as a signature mechanism. SHA-256 is a secure hash algorithm with a high strength hash function that can convert any length of data to a fixed length 256-bit hash value. The widespread use of this algorithm makes it very prominent in terms of guaranteeing data integrity and security.
The invention can not only prevent data from being tampered, but also prevent identity masquerading attack. Because the signature is generated based on the data content, an attacker cannot forge the correct signature and thus cannot successfully disguise the identity of the sender.
The invention improves on the basis of the existing network communication technology. The method is adapted and modified for commonly used network request objects such as XMLHttpRequest and fetch, so that the data security can be increased on the basis of not changing the original communication mode.
The verification process is simple and efficient, the integration and expansibility of the existing server system and application are good, and the existing network architecture does not need to be changed greatly. The method for increasing the data security on the basis of not changing the original communication mode has the advantages of being innovative and practical in technology.
In the description herein, reference to the term "embodiment," "example," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the different embodiments or examples described in this specification and the features therein may be combined or combined by those skilled in the art without creating contradictions.
While embodiments of the present invention have been shown and described, it will be understood that the embodiments are illustrative and not to be construed as limiting the invention, and that various changes, modifications, substitutions and alterations may be made by those skilled in the art without departing from the scope of the invention.

Claims (10)

1. A method for realizing tamper resistance based on signature added to SHA-256 hash algorithm interface, which is characterized by comprising the following steps:
s1, a sender receives a request and starts signature verification;
s2, acquiring a time stamp and a signature from the request head; proxy XMLHttpRequest object and fetch object;
s3, acquiring a request body;
s4, calculating a signature, modifying two objects of XMLHttpRequest and fetch, adding a SHA-256 hash value as the signature, and sending the signature and request data to a receiver;
s5, the receiving party receives the request data and the signature, carries out the same SHA-256 hash operation on the received request data, and generates a new hash value;
s6, comparing the new hash value with the received signature, if the hash value is consistent, forwarding the request, and if the hash value is inconsistent, alarming.
2. The method for realizing tamper resistance based on SHA-256 hash algorithm interface signature addition according to claim 1, wherein in step S2, the method comprises the following steps:
s2.1, agent xmlHttpRequest object;
s2.2. proxy fetch object.
3. The method for tamper resistance based on SHA-256 hash algorithm interface added signature as claimed in claim 2, wherein step s2.1 the proxy xmlHttpRequest object further comprises:
s2.1.1 determines whether a signature agent has been implemented;
s2.1.2, proxy ajax object, open obtains url and method;
s2.1.3, proxy ajax object, signature is added in send method;
s2.1.4, generating a time stamp;
s2.1.5, calling setrequest Header;
s2.1.6, adding a custom field X-Signature into a request header, and transmitting the generated hash Signature;
s2.1.7, adding a custom timestamp field into the request header;
s2.1.8. perform send operation.
4. The method for realizing tamper resistance based on SHA-256 hash algorithm interface signature addition according to claim 2, wherein the s2.2. proxy fetch object comprises:
s2.2.1 determines if a fetch agent already exists;
s2.2.2 generates a timestamp;
s2.2.3 JSON serialization is performed as signed content based on body content;
s2.2.4 request header adds custom field X-Signature, and transmits generated hash Signature;
s2.2.5 requests that the header add a custom timestamp field.
5. The method for realizing tamper resistance based on the SHA-256 hash algorithm interface added signature as claimed in claim 1, wherein for the sender, the sender first uses the interface request data to generate SHA-256 hash value; the generated hash value is used as a signature and transmitted to the receiving side together with the request data.
6. The method for tamper resistance based on SHA-256 hash algorithm interface add signature as claimed in claim 1, wherein for the receiver, the receiver receives the request data and the signature, the receiver performs the same SHA-256 hash operation on the received request data, generates a new hash value, and compares the new hash value with the received signature.
7. The method for realizing tamper resistance based on SHA-256 hash algorithm interface signature addition according to claim 1, wherein the verification process is as follows:
if the newly generated hash value is matched with the received signature, the verification is passed, and the fact that the data is not tampered in the transmission process is indicated;
if the newly generated hash value does not match the received signature, then verification fails, indicating that the data may have been tampered with or corrupted.
8. The SHA-256 hash algorithm interface based signature adding tamper resistant method of claim 1, wherein the two modified objects XMLHttpRequest and fetch are JavaScript APIs for making network data requests for data transfer between the client and the server.
9. The SHA-256 hash algorithm interface based signature-based tamper-resistant method of claim 8, wherein XMLHttpRequest is a client network request object for sending asynchronous requests and can handle server responses by listening for events; fetch is a network request API supporting Promise for processing response data.
10. A system for implementing tamper resistance based on SHA-256 hash algorithm interface addition signature, wherein the system is configured to implement a method for implementing tamper resistance based on SHA-256 hash algorithm interface addition signature according to any one of claims 1-9.
CN202311134517.5A 2023-09-05 2023-09-05 Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface Pending CN116865980A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311134517.5A CN116865980A (en) 2023-09-05 2023-09-05 Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311134517.5A CN116865980A (en) 2023-09-05 2023-09-05 Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface

Publications (1)

Publication Number Publication Date
CN116865980A true CN116865980A (en) 2023-10-10

Family

ID=88232697

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311134517.5A Pending CN116865980A (en) 2023-09-05 2023-09-05 Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface

Country Status (1)

Country Link
CN (1) CN116865980A (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170141926A1 (en) * 2015-11-13 2017-05-18 Minghua Xu Methods and systems for pki-based authentication
CN109005038A (en) * 2018-08-03 2018-12-14 北京达佳互联信息技术有限公司 Endorsement method, device, electronic equipment and storage medium
CN109408250A (en) * 2018-09-27 2019-03-01 天津字节跳动科技有限公司 Call application programming interface API approach, device, electronic equipment
CN109450649A (en) * 2018-12-28 2019-03-08 北京金山安全软件有限公司 Gateway verification method and device based on application program interface and electronic equipment
CN110955918A (en) * 2019-10-29 2020-04-03 浙江工业大学 Contract text protection method based on RSA encrypted sha-256 digital signature
CN115801275A (en) * 2022-11-22 2023-03-14 苏州市公安局苏州工业园区分局 API interface encryption signature method

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170141926A1 (en) * 2015-11-13 2017-05-18 Minghua Xu Methods and systems for pki-based authentication
CN109005038A (en) * 2018-08-03 2018-12-14 北京达佳互联信息技术有限公司 Endorsement method, device, electronic equipment and storage medium
CN109408250A (en) * 2018-09-27 2019-03-01 天津字节跳动科技有限公司 Call application programming interface API approach, device, electronic equipment
CN109450649A (en) * 2018-12-28 2019-03-08 北京金山安全软件有限公司 Gateway verification method and device based on application program interface and electronic equipment
CN110955918A (en) * 2019-10-29 2020-04-03 浙江工业大学 Contract text protection method based on RSA encrypted sha-256 digital signature
CN115801275A (en) * 2022-11-22 2023-03-14 苏州市公安局苏州工业园区分局 API interface encryption signature method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
周志鹏;: "基于Java安全API的数字签名", 计算机与现代化, no. 10 *

Similar Documents

Publication Publication Date Title
EP3913854B1 (en) Methods and systems for pki-based authentication
US8528076B2 (en) Method and apparatus for authenticating online transactions using a browser and a secure channel with an authentication server
US8302170B2 (en) Method for enhancing network application security
US20100217975A1 (en) Method and system for secure online transactions with message-level validation
US9338173B2 (en) Methods and apparatuses for avoiding damage in network attacks
Bojjagani et al. PhishPreventer: a secure authentication protocol for prevention of phishing attacks in mobile environment with formal verification
CN112711759A (en) Method and system for preventing replay attack vulnerability security protection
Badra et al. Phishing attacks and solutions
JP4698751B2 (en) Access control system, authentication server system, and access control program
GB2456742A (en) Determining trust levels for data sources
El‐Hajj The most recent SSL security attacks: origins, implementation, evaluation, and suggested countermeasures
JP5186648B2 (en) System and method for facilitating secure online transactions
CN113055357B (en) Method and device for verifying credibility of communication link by single packet, computing equipment and storage medium
Pampori et al. Securely eradicating cellular dependency for e-banking applications
CN116865980A (en) Method and system for realizing tamper resistance by adding signature based on SHA-256 Hash algorithm interface
US11463433B1 (en) Secure bearer-sensitive authentication and digital object transmission system and method for spoof prevention
Mei et al. Research and Defense of Cross-Site WebSocket Hijacking Vulnerability
US10079857B2 (en) Method of slowing down a communication in a network
Deeptha et al. Extending OpenID connect towards mission critical applications
Al-Refai et al. An enhanced user authentication framework in cloud computing
CN113938323B (en) JWT (Java virtual machine-based) based replay attack prevention method, device, equipment and storage medium
Ellison et al. Security and privacy concerns of internet single sign-on
WO2010070456A2 (en) Method and apparatus for authenticating online transactions using a browser
Schwarz et al. Security challenges, threats and countermeasures version 1.0
CN117318932A (en) API tamper-proof and replay-proof system and method based on Nginx plug-in

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