Web page interaction technology applied to self-service terminal

Abstract

The embodiment of the invention provides a web page interaction technology applied to a self-service terminal, which is characterized by comprising the following steps: a) customizing a browser based on a Chromium kernel, including a host process and a rendering process; b) in a host process of the customized browser, integrating a hardware resource access capability, and implementing a homologous strategy and a Content Security Policy enhanced security measure; c) in the rendering process of the customized browser, loading a third-party Web page, and pre-loading a JavaScript API (Application Program Interface); d) when a Web page initiates a request through a JavaScript API, encrypting request data by using an SM4 encryption algorithm, generating a digital signature and a construction message by using an SM2 algorithm, and sending the digital signature and the construction message to a local application; e) after receiving the message, the local application verifies the digital signature and decrypts the request data to obtain the request content; and f) according to the request content, calling hardware resources by the local application, and packaging a result into a response message. Through the scheme of the embodiment of the invention, the problem of how to realize efficient Web page interaction experience compatible with various devices can be solved.

Description

Technical Field

[0001] The present invention relates to the technical field of information technology, and in particular to a web page interaction technology applied to a self-service terminal. Background Art

[0002] As for the web page interaction technology applied to self-service terminals, we can understand it as a technology that aims to improve the user experience of self-service terminals. It optimizes the design and functions of web pages to achieve a smoother and more intuitive user interaction process. This technology usually involves the application of front-end development technologies, such as HTML5, CSS3, and JavaScript, to ensure that web pages can provide a consistent and efficient user experience on different types of self-service terminals.

[0003] In practical applications, one of the main challenges facing this technology is how to achieve an efficient and multi-device compatible web page interactive experience. Since there are many types of self-service terminal devices with different screen sizes, operating systems and hardware configurations, the key issues that need to be addressed include but are not limited to: how to ensure that web pages load fast enough on various devices; how to design an interface layout that can adapt to different screen sizes; and how to write code that can run across platforms to support different operating systems and technical standards. Solving these problems is crucial to improving the overall user experience of self-service terminals. Summary of the invention

[0004] In view of the above problems existing in the existing web page interaction technology applied to self-service terminals, the present invention is proposed.

[0005] Therefore, the problem to be solved by the present invention is how to ensure that the loading speed of a Web page on various devices is fast enough; how to design an interface layout that can adapt to different screen sizes; and how to write code that can run across platforms to support different operating systems and technical standards.

[0006] In order to solve the above technical problems, the present invention provides the following technical solutions: A web page interaction technology applied to a self-service terminal, characterized in that: it includes:

[0007] a) Customize the browser based on the Chromium kernel, including the main process and rendering process;

[0008] b) Integrate hardware resource access capabilities into the main process of the customized browser, and implement the same-origin policy and ContentSecurity Policy to strengthen security measures;

[0009] c) Load the third-party web page and preload the JavaScript API in the rendering process of the custom browser;

[0010] d) When a web page initiates a request through the JavaScript API, the request data is encrypted using the SM4 encryption algorithm, and a digital signature is generated using the SM2 algorithm, a message is constructed, and sent to the local application;

[0011] e) After receiving the message, the local application verifies the digital signature and decrypts the request data to obtain the request content;

[0012] f) Based on the request content, the local application calls the hardware resources and encapsulates the result into a response message;

[0013] g) The response message is encrypted and signed and sent back to the web page;

[0014] h) The Web page receives the response message, verifies the digital signature and decrypts the data to obtain the result of the hardware resource.

[0015] As a preferred solution of the web page interaction technology applied to the self-service terminal of the present invention, the customized browser based on the Chromium kernel includes:

[0016] Download the source code of the Chromium kernel;

[0017] Modify the configuration files in the source code according to customization requirements;

[0018] Compile the source code to generate a binary file of the customized browser;

[0019] Install the binary file on the target device;

[0020] The customized browser includes a main process and a rendering process.

[0021] As a preferred solution of the web page interaction technology applied to the self-service terminal of the present invention, wherein: in the main process of the customized browser, the integrated hardware resource access capability includes:

[0022] Register hardware resource access API;

[0023] Determine whether the current system supports the API;

[0024] If supported, enable the API and set permission control;

[0025] If not supported, an error log is recorded and the related functions are disabled;

[0026] Define a hardware resource access interface, the interface including read, write and query functions;

[0027] Set the security check function of the interface to verify the permission of the web page to access specific hardware resources;

[0028] Setting a hardware resource access whitelist, wherein the whitelist stores URLs and domain names of web pages for accessing hardware resources;

[0029] When a web page attempts to access a hardware resource, a match is performed according to the whitelist. If the match is successful, access is allowed; otherwise, access is denied.

[0030] As a preferred solution of the web page interaction technology applied to the self-service terminal of the present invention, wherein: the implementation of the same-origin policy and the Content Security Policy includes:

[0031] Determine the source of the web page, the source including the protocol, domain name and port number;

[0032] For each web page, record its source information;

[0033] When a web page tries to access another resource, it compares the source information of the resource with the source information of the current web page;

[0034] If the source information is exactly the same, access is allowed, otherwise access is denied;

[0035] Configure the CSP header to define the type of resources loaded and their sources;

[0036] When a web page attempts to load an external resource, it checks whether the resource complies with the CSP header.

[0037] If it complies with the regulations, loading is allowed, otherwise loading is blocked;

[0038] If a web page attempts to execute a script, check whether the script comes from an allowed source. If so, allow execution; otherwise, block execution.

[0039] As a preferred solution of the web page interaction technology applied to the self-service terminal of the present invention, wherein: in the rendering process of the customized browser, loading the third-party web page and preloading the JavaScript API includes:

[0040] Check whether the page URL complies with the security policy before loading the web page;

[0041] If it matches, then load the web page;

[0042] If it does not match, the loading is blocked and a warning message is displayed;

[0043] Perform sandbox isolation on loaded web pages;

[0044] Preload JavaScript API, provide a set of safe interfaces, define interface functions and their parameter types;

[0045] Add input validation logic to the interface function;

[0046] If the input validation passes, the subsequent logic will continue to execute;

[0047] If input validation fails, an error message is returned.

[0048] As a preferred solution of the web page interaction technology applied to the self-service terminal described in the present invention, when the web page initiates a request through the JavaScript API, the request data is encrypted using the SM4 encryption algorithm, and a digital signature is generated using the SM2 algorithm, a message is constructed, and sent to the local application, including:

[0049] Create a message object and initialize it;

[0050] Set the message type to request type;

[0051] Verify the request data and set the default value if the request data is empty;

[0052] If the request data is not empty, the provided data is used directly;

[0053] The request data is encrypted using the SM4 encryption algorithm, and a digital signature is generated using the SM2 algorithm. A message containing the request type, unique identifier, request data, and digital signature is constructed and sent to the local application.

[0054] As a preferred solution of the web page interaction technology applied to the self-service terminal of the present invention, the security enhancement also includes:

[0055] Monitor all network requests of web pages;

[0056] For each request, check whether its destination address is in the preset safe list;

[0057] If the destination address is not in the safe list, the request is blocked;

[0058] If the target address is in the security list, the requested data is further checked to see if it complies with the predefined data format. If so, it is allowed to be sent, otherwise it is blocked.

[0059] As a preferred solution of the web page interaction technology applied to the self-service terminal of the present invention, the security enhancement also includes:

[0060] Check each HTTP response of the web page;

[0061] Check if the response status code is 200 or 302;

[0062] If the status code is 200, check whether the response body contains sensitive information. If so, block the display.

[0063] If the status code is 302, check whether the redirection target address is in the preset safe list. If so, allow the redirection; otherwise, block the redirection.

[0064] The beneficial effects of the present invention are as follows: the present invention can enable the local application to call the corresponding hardware resources to perform the required operations according to the request content, and encapsulate the results into a response message, which is also encrypted and signed to ensure the security of data transmission, and then sent back to the Web page. Finally, after the Web page receives the response message, it first verifies the digital signature to ensure the integrity and source of the message, and then decrypts the data to obtain the results of the hardware resources. This series of processes realizes the secure interaction between the Web page and the local application, and also ensures the access control of the hardware resources and the secure transmission of data. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0066] Figure 1 The figure is a flowchart of the web page interaction technology applied to the self-service terminal.

[0067] Figure 2 Provides a flow chart for customizing the browser.

[0068] Figure 3 Flowchart for integrating hardware resource access capabilities into the main process of a custom browser.

[0069] Figure 4 A flowchart for supporting the loading of third-party web pages in a rendering process of a customized browser.

[0070] Figure 5 A flow chart that provides a set of safe interfaces for JavaScript APIs.

[0071] Figure 6 Flowchart for building the messages when a web page makes a request through the JavaScript API.

[0072] Figure 7Flowchart for integrating hardware resource access capabilities into the main process of a custom browser.

[0073] Figure 8 Flowchart for implementing a strict same-origin policy.

[0074] Fig. 9 Flowchart for implementing Content Security Policy (CSP).

[0075] Fig.10 A flowchart is also provided for enhanced safety.

[0076] Fig.11 A flowchart is also provided for enhanced safety. DETAILED DESCRIPTION

[0077] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings.

[0078] In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention may also be implemented in other ways different from those described herein, and those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0079] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The term "in one embodiment" that appears in different places in this specification does not necessarily refer to the same embodiment, nor is it a separate or selective embodiment that is mutually exclusive with other embodiments.

[0080] Example 1

[0081] Reference Figure 1-Figure 11 , which is the first embodiment of the present invention, provides a method for secure communication between a third-party Web page and a local application, comprising the following steps:

[0082] a) Provide a customized browser based on the Chromium kernel, including but not limited to the main process and rendering process;

[0083] b) Integrate hardware resource access capabilities into the main process of the custom browser and implement strict same-origin policy and Content Security Policy (CSP) to enhance security;

[0084] c) In the rendering process of the customized browser, support loading of third-party web pages and preload JavaScript APIs for encapsulating interactions with local applications. The JavaScript API provides a set of secure interfaces that allow authorized web pages to call specific hardware resources.

[0085] d) When a web page initiates a request through the JavaScript API, it constructs a message containing the request type, unique identifier, request data, and digital signature, encrypts the request data using the SM4 encryption algorithm, generates a digital signature using the SM2 algorithm, encapsulates the encrypted data and digital signature into the message, and sends it to the local application;

[0086] e) After receiving the message, the local application verifies the digital signature to ensure the integrity and trustworthiness of the message, and decrypts the data to obtain the requested content;

[0087] f) Based on the request content, the local application calls the corresponding hardware resources and encapsulates the result into a response message;

[0088] h) The response message is also encrypted and signed, and then sent back to the web page;

[0089] g) The web page receives the response message, verifies the digital signature and decrypts the data to obtain the result of the hardware resource;

[0090] It also includes a message authentication code (MAC), which is calculated using the HMAC-SHA256 algorithm and is used to verify the integrity of the message;

[0091] The communication between the custom browser and the local application is protected by TLS 3 protocol;

[0092] The method also includes processing the time-consuming hardware operation in an asynchronous manner to prevent the Web page from being blocked;

[0093] The method also includes managing high-frequency used hardware resources using resource pool technology to reduce frequent allocation and release of resources;

[0094] The method also includes using a cache mechanism to reduce direct calls to hardware resources that are frequently accessed and whose data does not change much;

[0095] In a specific embodiment,

[0096] Download the source code of the Chromium kernel;

[0097] Modify the configuration files in the source code according to customization requirements;

[0098] Compile the source code to generate a custom browser binary;

[0099] Install the binary file on the target device.

[0100] In a specific embodiment,

[0101] Register hardware resource access API;

[0102] Determine whether the current system supports the API;

[0103] If supported, enable the API and set permission control;

[0104] If not supported, an error is logged and the related functionality is disabled.

[0105] In a specific embodiment,

[0106] Check whether the page URL complies with the security policy before loading the web page;

[0107] If it matches, then load the web page;

[0108] If it does not match, the loading is blocked and a warning message is displayed;

[0109] Perform sandbox isolation on loaded web pages.

[0110] In a specific embodiment,

[0111] Define interface functions and their parameter types;

[0112] Add input validation logic to the interface function;

[0113] If the input validation passes, the subsequent logic will continue to execute;

[0114] If input validation fails, an error message is returned.

[0115] In a specific embodiment,

[0116] Create a message object and initialize it;

[0117] Set the message type to request type;

[0118] If the request data is empty, set the default value;

[0119] If the request data is not empty, the provided data is used directly;

[0120] Integrating hardware resource access capabilities into the main process of a custom browser includes:

[0121] Define the hardware resource access interface, which at least includes read, write and query functions;

[0122] Implement the security check function of the interface, which is used to verify whether the web page has the permission to access specific hardware resources;

[0123] Set up a hardware resource access whitelist, which stores the URLs or domain names of web pages that can access hardware resources;

[0124] When a web page attempts to access hardware resources, it is matched against the whitelist. If the match succeeds, access is allowed; otherwise, access is denied.

[0125] Implementing a strict same-origin policy includes:

[0126] Determine the source of the web page, including the protocol, domain name, and port number;

[0127] For each web page, record its source information;

[0128] When a web page tries to access another resource, it compares the source information of the resource with the source information of the current web page;

[0129] If the source information is exactly the same, access is allowed, otherwise access is denied;

[0130] Implementing Content Security Policy (CSP) includes:

[0131] Configure the CSP header, which defines the types of resources allowed to be loaded and their sources;

[0132] When a web page attempts to load an external resource, it checks whether the resource complies with the CSP header.

[0133] If it complies with the regulations, loading is allowed, otherwise loading is blocked;

[0134] If a web page attempts to execute a script, check whether the script comes from an allowed source. If so, allow execution; otherwise, block execution.

[0135] Security enhancements also include:

[0136] Monitor all network requests of web pages;

[0137] For each request, check whether its destination address is in the preset safe list;

[0138] If the destination address is not in the safe list, the request is blocked;

[0139] If the target address is in the security list, further check whether the requested data conforms to the predefined data format. If so, it is allowed to be sent, otherwise it is blocked;

[0140] Security enhancements also include:

[0141] Check each HTTP response of the web page;

[0142] Check if the response status code is 200 or 302;

[0143] If the status code is 200, check whether the response body contains sensitive information. If so, block the display.

[0144] If the status code is 302, check whether the redirection target address is in the preset safe list. If so, allow the redirection; otherwise, block the redirection.

[0145] refer to Figure 1 Describe this web page interaction technology applied to self-service terminals:

[0146] S101: Provide a customized browser to achieve an efficient and multi-device compatible web page interactive experience. This customized browser is developed based on the Chromium kernel, which means it inherits all the advantages of Chromium, such as high performance, open source, and extensive web standard support. The customized browser includes not only the main process but also the rendering process. This design ensures that the browser maintains stability and responsiveness when processing complex web pages. For example, when a user opens a complex banking service web page on a self-service terminal, the customized browser can quickly load the page and present the content smoothly, while ensuring the efficient operation of the background process.

[0147] S102: Security is further enhanced by integrating hardware resource access capabilities and implementing strict same-origin policy and Content Security Policy CSP in the main process of the custom browser. Integrated hardware resource access capabilities mean that the browser can interact directly with the hardware of the self-service terminal, such as reading data from a barcode scanner or controlling a printer. The same-origin policy restricts how documents or scripts on one domain can interact with resources on another source, while CSP prevents security threats such as cross-site scripting attacks. For example, if a malicious website attempts to access the camera of the self-service terminal through a script, the strict same-origin policy and CSP will block this attempt, thereby protecting the user's privacy and data security.

[0148] S103: By supporting the loading of third-party web pages in the rendering process of the customized browser and preloading the JavaScript API for encapsulating the interaction with the local application, the web page can interact securely with the local application. Preloading the JavaScript API means that the browser has prepared a set of APIs when it starts, and these APIs can be used by the web page to request access to specific hardware resources. For example, a web page may need to read the magnetic card reader information of a self-service terminal. Through the preloaded JavaScript API, the web page can safely initiate the request without worrying about security vulnerabilities.

[0149] S104: Through the security interface provided by the JavaScript API, the authorized web page can call specific hardware resources. These interfaces are carefully designed to only allow authenticated web pages to access necessary hardware resources, thereby avoiding potential security risks. For example, an authenticated web page can request access to the printer of the self-service terminal through these interfaces to print out a transaction receipt.

[0150] S105: When a web page initiates a request through the JavaScript API, it constructs a message containing the request type, unique identifier, request data, and digital signature. This message is the core of the request, and the digital signature ensures the integrity of the message and the credibility of the source. For example, when a web page wants to read the barcode scanner data of a self-service terminal, it constructs such a message and attaches a digital signature to prove the validity of the request.

[0151] S106: The request data is encrypted using the SM4 encryption algorithm and the digital signature is generated using the SM2 algorithm to ensure the security of data transmission. SM4 is a symmetric encryption algorithm, while SM2 is an asymmetric encryption algorithm. The combination of these two algorithms can effectively prevent data from being tampered with or eavesdropped during transmission. For example, the message constructed in the above steps will be encrypted to prevent it from being intercepted by a third party during transmission.

[0152] S107: Encapsulate the encrypted data and digital signature into a message and send it to the local application. This step ensures the secure transmission of the message. Even if the message is intercepted during transmission on the network, the attacker cannot decipher or tamper with the content of the message because the data has been encrypted and protected by a digital signature.

[0153] S108: After receiving the message, the local application first verifies the digital signature to ensure the integrity and credibility of the message, and then decrypts the data to obtain the request content. This process ensures that only legitimate local applications can process requests from web pages. For example, when the local application receives an encrypted message, it first verifies the digital signature, and then decrypts the data after confirming that it is correct, to obtain the specific request content.

[0154] S109: According to the request content, the local application calls the corresponding hardware resources and encapsulates the result into a response message. For example, if the Web page requests to read data from a barcode scanner, the local application will call the barcode scanner and encapsulate the scanned data into a response message.

[0155] S1010: The response message is also encrypted and signed, and then sent back to the web page. This step ensures that the data returned from the local application is also safe, preventing the data from being tampered with or stolen during the return process.

[0156] S1011: The web page receives the response message, verifies the digital signature and decrypts the data to obtain the result of the hardware resource. For example, after receiving the encrypted response message, the web page verifies the digital signature, decrypts the data after confirming that it is correct, and obtains the specific data of the barcode scanner.

[0157] Through the above steps, the problem of how to achieve an efficient and multi-device compatible web page interactive experience can be solved. The entire process not only ensures efficient communication between web pages and local applications, but also ensures data security through encryption and signature mechanisms, allowing self-service terminals to operate safely and reliably in various environments.

[0158] Next, refer to Figure 2 Describe the specific steps of customizing the browser in a web page interaction technology applied to self-service terminals:

[0159] S201: By downloading the source code of the Chromium kernel. First, in order to build a browser optimized specifically for self-service terminals, it is necessary to download the latest Chromium project source code from the official repository or a trusted source. This step ensures that all necessary development tools and dependencies are available for subsequent customized development of the browser. For example, the Chromium source code repository can be cloned by executing the command `;git clone https: / / chromium.googlesource.com / chromium / src.git`;.

[0160] S202: By modifying the configuration file in the source code according to the customization requirements. After obtaining the Chromium source code, the configuration file needs to be adjusted according to the specific requirements of the self-service terminal. These configuration files may include compilation options, function switches, and hardware platform-specific settings. For example, if the self-service terminal does not need to support certain advanced graphics features, these features can be disabled in the GngNinja configuration file to reduce the browser's resource consumption and improve performance.

[0161] S203: Generate a custom browser binary file by compiling the source code. After completing the modification of the configuration file, you need to use an appropriate build system such as GN and Ninja to compile the entire Chromium project. This process will generate the final browser binary file based on the customized configuration made previously. For example, in a Linux environment, you can run the `gngen out / Default` and `ninja-C out / Default` commands to generate executable files.

[0162] S204: Install the binary file on the target device. Finally, deploy the compiled custom browser binary file to the self-service terminal device and perform necessary tests to ensure that it works properly. For example, the binary file can be transferred to the file system of the self-service terminal through SCPSecure Copy Protocol, and the browser process can be automatically started through a script to achieve the self-service function.

[0163] Next, refer to Figure 3 Describes the specific steps of integrating hardware resource access capabilities into the main process of a custom browser in a web page interaction technology applied to a self-service terminal:

[0164] S301: Start the process by registering the hardware resource access API. This step involves defining a set of application programming interfaces (APIs) that allow web pages to request access to specific hardware resources on the self-service terminal, such as printers, scanners, or cameras. The registration process ensures that these APIs can be correctly identified and called by web pages.

[0165] S302: Next, the system needs to determine whether the current operating environment supports these APIs. This is usually done by querying the function list of the operating system or browser kernel. If it is detected that the current environment supports the required API, the next step can be continued; otherwise, the error handling process will be executed.

[0166] S303: If the current system supports the registered APIs, enable these APIs and set corresponding permission controls to ensure security and compliance. Permission controls may include but are not limited to user authorization, access frequency restrictions, and data encryption to prevent unauthorized access or abuse of hardware resources.

[0167] S304: On the contrary, if the current system does not support the registered API, a detailed error log is recorded and all functions related to these APIs are disabled. This can avoid abnormal behavior or crashes caused by trying to access unavailable hardware resources and help maintain system stability and user experience.

[0168] Next, refer to Figure 4 Describes the specific steps of supporting third-party web page loading in the rendering process of a custom browser in a web page interaction technology applied to a self-service terminal:

[0169] S401: By customizing the rendering process of the browser, before loading any third-party web page, the URL of the web page to be loaded is first checked for security policy. This process ensures that only web content that meets the predefined security standards can be loaded on the self-service terminal. For example, a whitelist or blacklist can be maintained to determine whether the URL is allowed to be loaded, or a more complex mechanism such as a rule-based security engine can be used to evaluate the risk level of the URL.

[0170] S402: If the URL of the web page is determined to be safe after the security policy check, the web page is allowed to load. This step usually involves parsing resources such as HTML, CSS, and JavaScript, and presenting them to the user. In order to ensure security, a variety of technical means can be used, such as limiting access rights to certain JavaScript APIs to prevent potential malicious code execution.

[0171] S403: If the URL of the web page does not comply with the security policy, the page is blocked from loading and a warning message is displayed to the user. This warning message can clearly inform the user that the page has potential risks and is not recommended to continue accessing. In addition, some additional information can be provided, such as why the page is considered unsafe and how to report an error or request a review of a specific URL.

[0172] S404: For all loaded web pages, regardless of whether their URLs pass the security policy check, sandbox isolation should be performed in the rendering process of the customized browser. This means that even if malicious code manages to bypass the security check, it cannot directly access the operating system or other sensitive data of the self-service terminal. Sandbox isolation can be implemented in a variety of ways, such as limiting the interaction of web pages with the local file system, disabling the use of certain high-risk APIs, or running web content entirely in a restricted environment.

[0173] Next, refer to Figure 5 Describe the specific steps of a web page interaction technology applied to self-service terminals:

[0174] S501: Define interface functions and their parameter types: In order to ensure the safe and reliable interaction between the web page and the self-service terminal, a set of JavaScript API interface functions need to be defined, and the parameter types of these functions need to be clearly specified. For example, an interface function named "processPayment" can be defined to process payment operations. This function may need to receive parameters such as order ID string type and payment amount numeric type. The purpose of this is to ensure that the caller must pass parameters in the correct format, thereby reducing security vulnerabilities caused by mismatched parameter types.

[0175] S502: Add input validation logic to the interface function: After defining the interface function, you need to implement input validation logic inside each function. This usually involves checking the validity of the incoming parameters. For example, inside the `processPayment` function, you can use regular expressions to verify whether the order ID conforms to the expected format, or check whether the payment amount is a positive number. If the input validation passes, the subsequent business logic is allowed to execute; if the validation fails, the execution is stopped immediately and the corresponding error message is returned to the caller to prompt the user or developer where the problem is.

[0176] S503: Execute subsequent logic or return error information based on input verification results: Once input verification is completed, different actions are taken based on the verification results. If all inputs pass the verification, the predetermined business logic can continue to be executed, such as calling the payment system of the self-service terminal to process the payment request. On the contrary, if the input verification fails, further operations should be terminated immediately, and a message containing the specific error cause should be returned to the caller so that the caller can correct the error in time and try again. This mechanism helps to improve the robustness of the system and user experience.

[0177] Next, refer to Figure 6 Describe the specific steps of a web page interaction technology applied to self-service terminals:

[0178] S601: Constructing a message when initiating a request through the JavaScript API: When a web page needs to interact with a self-service terminal, a request is initiated by calling a predefined JavaScript API. In this process, a message object is first created and initialized to ensure that the message object is in a known and usable state.

[0179] S602: Set the message type to the request type: In order to clarify the purpose of the message, the message type field in the created message object is set to "request type", which helps the receiving end to correctly parse the message and adopt corresponding processing logic.

[0180] S603: Set message content according to request data: Next, check whether the request data is empty. If the request data is empty, set a default value as the message content; if the request data is not empty, directly use the provided data to fill the message content, so as to ensure that the message can be processed correctly even if no specific data is provided.

[0181] Through the above steps, the message for interaction between the Web page and the self-service terminal can be effectively constructed, ensuring the accuracy and reliability of communication.

[0182] Next, refer to Figure 7 Describes the specific steps of integrating hardware resource access capabilities into the main process of a custom browser in a web page interaction technology applied to a self-service terminal:

[0183] S701: Define hardware resource access interfaces: First, a set of hardware resource access interfaces need to be defined. These interfaces should at least include read, write, and query functions. The design of these interfaces should ensure that they can be called by Web pages to access specific hardware resources, while also ensuring that sensitive information will not be leaked or security vulnerabilities will be caused. For example, an API application programming interface can be designed to control access to a printer, including functions such as printing documents and obtaining printer status.

[0184] S702: Implementing a security check function of the interface: In order to ensure that only authorized web pages can access hardware resources, a security check function needs to be implemented. This function will be executed before a web page attempts to access hardware resources to verify whether the web page has the corresponding permissions. For example, you can write a function that checks whether the web page currently requesting access to hardware resources exists in a preset whitelist and whether the page has sufficient permissions to perform the requested operation.

[0185] S703: Setting a hardware resource access whitelist: Create and maintain a hardware resource access whitelist, which records the URLs or domain names of web pages that are allowed to access specific hardware resources. This step is implemented through a configuration file or a table in a database to ensure that only authenticated web pages can access hardware resources. For example, the domain name of a bank's official website can be added to the whitelist, so that only this website can access certain hardware resources on a self-service terminal, such as a cash register.

[0186] S704: Perform whitelist matching: When a web page attempts to access a hardware resource, the system automatically checks whether the URL or domain name of the web page matches an entry in the whitelist. If the match is successful, the web page is allowed to access the hardware resource; if it does not match, the access request is denied. For example, when a web page attempts to print a document, the system checks whether the source of the page is in the whitelist. If not, the printing operation is not allowed to proceed.

[0187] Next, refer to Figure 8 Describe the specific steps of implementing a strict same-origin policy in a web page interaction technology applied to self-service terminals:

[0188] S801: Determine the source of the web page by detecting its URL, where the source includes but is not limited to the network protocol used, such as HTTP or HTTPS, the domain name, such as example.com, and the port number, such as 80 or 443. This process can be completed by parsing the URL information in the web page request, ensuring that the complete source information of the web page can be accurately obtained.

[0189] S802: For each web page loaded on the self-service terminal, the system will record its source information. This information can be stored in memory or persistent storage device for subsequent comparison. The purpose of recording the source information is to be able to perform effective security checks when the web page attempts to access other resources.

[0190] S803: When a web page attempts to access other resources such as images, script files or API interfaces, the system automatically compares the source information of the resource with the source information of the current web page. This comparison process is usually automatically performed by the browser's security mechanism without user intervention.

[0191] S804: If the source information of the resource is exactly the same as the source information of the current web page, the web page is allowed to access the resource; otherwise, if the source information is different, the access request is denied. This strict same-origin policy helps prevent cross-site scripting attacks (XSS) and other source-based attacks.

[0192] For example, suppose there is a web page located at

[0193] `;https: / / www.example.com:443`;, it tries to load an image file. If the image file also comes from `;https: / / www.example.com:443`;, the loading operation will be allowed; but if the image file comes from `;http: / / www.anotherdomain.com:80`;, the loading operation will be blocked because the two sources are inconsistent. In this way, the self-service terminal can effectively protect the user's privacy and data security.

[0194] Next, refer to Fig. 9 Describe the specific steps of implementing ContentSecurity Policy CSP in a web page interaction technology applied to self-service terminals:

[0195] S901: Define the types of resources that are allowed to be loaded and their sources by configuring the CSP header. On the web server or application server of the self-service terminal, the developer needs to set the Content-Security-Policy field in the HTTP response header to clearly specify which types of resources such as images, scripts, style sheets, etc. can be loaded from which sources. For example, you can set `;default-src 'self'`; to limit all resources to be loaded only from the current site, or more specifically set `;script ...

[0196] example.com`; to allow scripts to be loaded only from the current site and example.com.

[0197] S902: Check whether the external resource that the web page attempts to load complies with the provisions of the CSP header. When the web page requests to load any external resource, the browser checks whether the resource is allowed to load according to the CSP policy. If the source of the resource matches the source defined in the CSP header, the loading is allowed; if it does not match, the browser will block the loading of the resource and may record a security log.

[0198] S903: By checking whether the script that the web page attempts to execute comes from an allowed source. When a web page attempts to execute an inline script or an external script, the browser will also check whether these scripts comply with the CSP policy. For example, if `script-src 'self'` is set in the CSP header, only scripts from the current site will be allowed to execute, and scripts from other sources will be blocked from executing.

[0199] Through the above steps, the security of self-service terminals can be effectively enhanced to prevent malicious script injection and other web-based security threats.

[0200] Next, refer to Fig.10 Describe the specific steps of strengthening security measures in web page interaction technology applied to self-service terminals:

[0201] S1001: All network requests of the web page are continuously monitored by deploying a network request monitoring module. This monitoring mechanism can ensure that all requests issued are captured by the system and subjected to subsequent security checks. For example, a listener can be set at the network request interface of the web browser engine to intercept and record each HTTP or HTTPS request to be issued.

[0202] S1002: For each monitored network request, the system checks whether its target address is in a preset security list. This security list can be a whitelist, which contains URLs or domain names that are allowed to be accessed. For example, if the self-service terminal is only allowed to communicate with the bank's internal servers, the addresses of these servers can be added to the whitelist. If the target address is not in the security list, the system will automatically block the request to prevent potential malicious behavior.

[0203] S1003: If the target address is in the security list, the system will further check whether the requested data conforms to the predefined data format. This step can be achieved by parsing the request body content and comparing it with the preset data format template. For example, if the request is for submitting user login information, the predefined data format may include fields that must exist such as user name and password and the formats of these fields such as length restrictions, character types, etc. The system will only allow the request to be sent if the request data fully conforms to the predefined data format; otherwise, the system will block the request and may record the attempt as part of the security log.

[0204] Through the above steps, the self-service terminal can effectively enhance the security of its web page interaction process and reduce the security risks caused by malicious requests.

[0205] Next, refer to Fig.11 Describe the specific steps to enhance security in a web page interaction technology used in self-service terminals:

[0206] S1101: The process begins by checking each HTTP response received. This means that whenever a web server returns a response, the client software on the self-service terminal automatically analyzes the response. This step ensures that all received data is evaluated to determine its security.

[0207] S1102: Next, check whether the status code of the HTTP response is 200 or 302. Status code 200 indicates that the request has been successfully processed, while 302 indicates a temporary redirection. In the case of status code 200, further check whether the response body contains any sensitive information. If sensitive information is detected, the system will prevent the display of the content, thereby preventing potential information leakage risks.

[0208] S1103: When the status code is 302, that is, when there is a redirection, it is necessary to check whether the redirection target address is in the preset safe list. If the target address is safe, the redirection is allowed to continue; otherwise, if the target address is not in the safe list, the redirection is blocked to prevent the user from being directed to malicious websites or unsafe links.

[0209] Through the above steps, the self-service terminal can effectively enhance the security of its web page interaction and protect users from potential security threats.

[0210] In actual operation, when this device is used, the customized browser is first started as the core component of the entire interaction method. The customized browser is based on the Chromium kernel, which ensures that it can run Web pages efficiently and stably. The customized browser is divided into two main parts: the main process and the rendering process. The main process is responsible for integrating hardware resource access capabilities and implementing strict homology policies and Content Security Policy CSP, which not only enhances security but also ensures that only authorized Web pages can access specific hardware resources. The rendering process is responsible for loading third-party Web pages and pre-loads a set of JavaScript APIs for encapsulating interactions with local applications. When the user interacts with the Web page, if a specific hardware resource needs to be called, the Web page will initiate a request through the pre-loaded JavaScript API. At this time, the JavaScript API constructs a message containing the request type, unique identifier, request data, and digital signature. In order to ensure the security of the data, the request data is encrypted using the SM4 encryption algorithm, and the digital signature is generated using the SM2 algorithm to ensure the integrity and source of the message. Subsequently, this encrypted message is sent to the local application. After receiving the message, the local application first verifies the digital signature to confirm the authenticity and integrity of the message, and then decrypts the data to obtain the specific request content. According to the request content, the local application calls the corresponding hardware resources to perform the required operations and encapsulates the results into a response message. The response message is also encrypted and signed to ensure the security of data transmission, and then sent back to the web page. Finally, after receiving the response message, the web page first verifies the digital signature to ensure the integrity and source of the message, and then decrypts the data to obtain the results of the hardware resources. This series of processes realizes the secure interaction between the web page and the local application, and also ensures the access control of hardware resources and the secure transmission of data.

[0211] The disclosed embodiment provides a method for secure communication between a third-party Web page and a local application, comprising the following steps: a) providing a customized browser, which is based on the Chromium kernel, including but not limited to a main process and a rendering process; b) integrating hardware resource access capabilities in the main process of the customized browser, and implementing strict homology policy and Content Security Policy (CSP) to enhance security; c) supporting the loading of third-party Web pages in the rendering process of the customized browser, and preloading a JavaScript API for encapsulating interaction with local applications; d) the JavaScript API provides a set of secure interfaces that allow authorized Web pages to call specific hardware resources; e) when a Web page accesses a specific hardware resource through JavaScript, the JavaScript API provides a set of secure interfaces that allow authorized Web pages to call specific hardware resources; and When the API initiates a request, a message including a request type, a unique identifier, request data, and a digital signature is constructed; f) the request data is encrypted using the SM4 encryption algorithm, and a digital signature is generated using the SM2 algorithm; g) the encrypted data and digital signature are encapsulated into a message and sent to the local application; h) after the local application receives the message, the digital signature is verified to ensure the integrity and source of the message, and the data is decrypted to obtain the request content; i) according to the request content, the local application calls the corresponding hardware resources and encapsulates the result into a response message; j) the response message is also encrypted and signed, and then sent back to the web page; k) the web page receives the response message, verifies the digital signature, and decrypts the data to obtain the result of the hardware resource. According to the method of claim 1, the message also includes a message authentication code (MAC), the MAC is calculated using the HMAC-SHA256 algorithm, and is used to verify the integrity of the message, wherein the communication between the customized browser and the local application is protected using the TLS 3 protocol, and the method also includes processing time-consuming hardware operations in an asynchronous manner to prevent the web page from being blocked. According to the method of claim 1, the method further comprises using resource pool technology to manage frequently used hardware resources to reduce the frequent allocation and release of resources, and the method further comprises using a cache mechanism to reduce direct calls to hardware resources that are frequently accessed and whose data do not change much. Through the solution of the embodiment of the present disclosure, it is possible to solve how to achieve an efficient and multi-device compatible Web page interactive experience.

[0212] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0213] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in conjunction with such instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in conjunction with such instruction execution systems, devices or apparatuses.

[0214] More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be a paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering or, if necessary, processing in another suitable manner, and then stored in a computer memory.

[0215] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0216] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention, which should all be included in the scope of the claims of the present invention.

Claims

1. A web page interaction technology applied to a self-service terminal, characterized in that: include, a) Customize the browser based on the Chromium kernel, including the main process and rendering process; b) Integrate hardware resource access capabilities into the main process of the customized browser, and implement the same-origin policy and ContentSecurity Policy to strengthen security measures; c) Load the third-party web page and preload the JavaScript API in the rendering process of the custom browser; d) When a web page initiates a request through the JavaScript API, the request data is encrypted using the SM4 encryption algorithm, and a digital signature is generated using the SM2 algorithm, a message is constructed, and sent to the local application; e) After receiving the message, the local application verifies the digital signature and decrypts the request data to obtain the request content; f) Based on the request content, the local application calls the hardware resources and encapsulates the result into a response message; g) The response message is encrypted and signed and sent back to the web page; h) The Web page receives the response message, verifies the digital signature and decrypts the data to obtain the result of the hardware resource.

2. The web page interaction technology applied to a self-service terminal according to claim 1, characterized in that: The customized browser based on the Chromium kernel includes: Download the source code of the Chromium kernel; Modify the configuration files in the source code according to customization requirements; Compile the source code to generate a binary file of the customized browser; Install the binary file on the target device; The customized browser includes a main process and a rendering process.

3. The web page interaction technology applied to the self-service terminal according to claim 2, characterized in that: In the main process of the customized browser, the integrated hardware resource access capability includes: Register hardware resource access API; Determine whether the current system supports the API; If supported, enable the API and set permission control; If not supported, an error log is recorded and the related functions are disabled; Define a hardware resource access interface, the interface including read, write and query functions; Set the security check function of the interface to verify the permission of the web page to access specific hardware resources; Setting a hardware resource access whitelist, wherein the whitelist stores URLs and domain names of web pages for accessing hardware resources; When a web page attempts to access a hardware resource, a match is performed according to the whitelist. If the match is successful, access is allowed; otherwise, access is denied.

4. The web page interaction technology applied to a self-service terminal according to claim 3, characterized in that: The implementation of the same-origin policy and Content Security Policy includes: Determine the source of the web page, the source including the protocol, domain name and port number; For each web page, record its source information; When a web page tries to access another resource, it compares the source information of the resource with the source information of the current web page; If the source information is exactly the same, access is allowed, otherwise access is denied; Configure the CSP header to define the type of resources loaded and their sources; When a web page attempts to load an external resource, it checks whether the resource complies with the CSP header. If it complies with the regulations, loading is allowed, otherwise loading is blocked; If a web page attempts to execute a script, check whether the script comes from an allowed source. If so, allow execution; otherwise, block execution.

5. The web page interaction technology applied to a self-service terminal according to claim 4, characterized in that: The method of loading a third-party web page and preloading a JavaScript API in the rendering process of the customized browser includes: Check whether the page URL complies with the security policy before loading the web page; If it matches, then load the web page; If it does not match, the loading is blocked and a warning message is displayed; Perform sandbox isolation on loaded web pages; Preload JavaScript API, provide a set of safe interfaces, define interface functions and their parameter types; Add input validation logic to the interface function; If the input validation passes, the subsequent logic will continue to execute; If input validation fails, an error message is returned.

6. The web page interaction technology applied to a self-service terminal according to claim 5, characterized in that: When a web page initiates a request through a JavaScript API, the request data is encrypted using the SM4 encryption algorithm, a digital signature is generated using the SM2 algorithm, a message is constructed, and sent to the local application, including: Create a message object and initialize it; Set the message type to request type; Verify the request data and set the default value if the request data is empty; If the request data is not empty, the provided data is used directly; The request data is encrypted using the SM4 encryption algorithm, and a digital signature is generated using the SM2 algorithm. A message containing the request type, unique identifier, request data, and digital signature is constructed and sent to the local application.

7. The web page interaction technology applied to a self-service terminal according to claim 6, characterized in that: Security enhancements also include: Monitor all network requests of web pages; For each request, check whether its destination address is in the preset safe list; If the destination address is not in the safe list, the request is blocked; If the target address is in the security list, the requested data is further checked to see if it complies with the predefined data format. If so, it is allowed to be sent, otherwise it is blocked.

8. The web page interaction technology applied to a self-service terminal according to claim 7, characterized in that: Security enhancements also include: Check each HTTP response of the web page; Check if the response status code is 200 or 302; If the status code is 200, check whether the response body contains sensitive information. If so, block the display. If the status code is 302, check whether the redirection target address is in the preset safe list. If so, allow the redirection; otherwise, block the redirection.

Images