CN116132157A - Request tamper-proof method and device based on webpage element visibility verification - Google Patents
Request tamper-proof method and device based on webpage element visibility verification Download PDFInfo
- Publication number
- CN116132157A CN116132157A CN202310066945.2A CN202310066945A CN116132157A CN 116132157 A CN116132157 A CN 116132157A CN 202310066945 A CN202310066945 A CN 202310066945A CN 116132157 A CN116132157 A CN 116132157A
- Authority
- CN
- China
- Prior art keywords
- request
- client
- data table
- page
- visibility data
- 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
Links
Images
Classifications
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
The invention provides a request tamper-proof method and device based on webpage element visibility verification, wherein the method comprises the following steps: receiving a request sent by a client; judging whether session information of the client is stored or not; if the session information of the client is stored, judging whether the request is matched with the element visibility data table corresponding to the client; the element visibility data table comprises all elements of the current page of the client which are bound with the request; if the request matches the element visibility data table, the request is determined to be a legal request. The embodiment of the invention can determine whether the request received by the server is a legal request by analyzing whether the request can be initiated by the element binding the request in the current page of the client, namely whether the request can be initiated by the current page of the client or not, and if the request can be initiated, determining that the request is not tampered.
Description
Technical Field
The invention relates to the technical field of information security, in particular to a request tamper-proof method and device based on webpage element visibility verification.
Background
HTTP (Hyper Text Transfer Protocol )/TCP (Transmission Control Protocol, transmission control protocol) protocol is widely used for interaction between a web client and a server, however HTTP has the following hidden trouble in terms of security: 1. the communication with the server uses plaintext, and the content may be intercepted (the HTTP protocol itself does not have encryption function, so the content of the request and the response cannot be encrypted); 2. both the server and the client using the HTTP protocol will not verify the identity of the communicating party, and may suffer from masquerading; 3. the integrity of the message cannot be verified by the server and the client using the HTTP protocol, so that the message may be tampered in the communication process.
Based on such security problems, various encryption technologies are derived, and for the HTTP protocol, there are generally two ways of encryption: encryption of the communication content and encryption of the communication channel. The former is to encrypt the content contained in the HTTP message. Thus, firstly, the client encrypts the message and then sends the message to the server. When the server receives the request, the message needs to be decrypted and then processed. This approach, because it is not end-to-end, still has the risk of tampering with the content. The latter performs end-to-end encryption of the entire HTTP communication procedure by HTTP in combination with SSL (Security Socket Layer, secure socket layer) encryption protocol, HTTPs (Hypertext Transfer Protocol Secure, secure hypertext transfer protocol) protocol. But HTTPS encrypted content may also be decrypted if a hacker uses special means to let the requesting device communicate using a fake certificate.
Disclosure of Invention
In order to solve the above problems, an embodiment of the present invention provides a request tamper-proof method based on a visibility check of a web page element, where the method includes: receiving a request sent by a client; judging whether session information of the client is stored or not; if the session information of the client is stored, judging whether the request is matched with an element visibility data table corresponding to the client; the element visibility data table comprises all elements of the current page of the client which are bound with the request; and if the request is matched with the element visibility data table, determining that the request is a legal request.
Optionally, the method further comprises: if a request corresponding to a routing element sent by a client is received and the request corresponding to the routing element is a legal request, updating the element visibility data table according to a page after the jump corresponding to the routing element; the routing element is an element which is clicked in a page of the client and jumps to a new page, or an element which is clicked in the page and changes the element contained in the page; the element visibility data table comprises request links, element names and associated routing elements of elements in the page after the jump.
Optionally, the element visibility data table further includes a permission to access the user for each element in the page after the jump.
Optionally, the determining whether the request matches with the element visibility data table corresponding to the client includes: comparing whether the element name carried by the request or the request link belongs to the element name and the request link included in the element visibility data table corresponding to the client; if yes, determining that the request is matched with the element visibility data table corresponding to the client.
Optionally, the determining whether the request matches with the element visibility data table corresponding to the client includes: comparing whether the user name carried by the request belongs to the user name included in the element visibility data table corresponding to the client; if the element name belongs to the user name included in the element visibility data table, comparing whether the element name carried by the request or the request link belongs to the element name and the request link included in the element visibility data table corresponding to the client; and if the request belongs to the element name or the request link included in the element visibility data table, determining that the request is matched with the element visibility data table corresponding to the client.
Optionally, the method further comprises: if the session information of the client is not stored, a login redirection response is returned to the client; if receiving the user login information resent by the client, carrying out login verification; if the login verification is passed, initializing session information corresponding to the client; the session information comprises an initialized session number and an initialized last time received route request; if a default page request sent by the client is received, verifying whether session information of the client is stored or not; and if the session information of the client is stored, returning default page data to the client and updating an element visibility data table corresponding to the client according to the default page data.
Optionally, the element visibility data table further includes a self-added primary key of each element in the page after the jump.
The embodiment of the invention provides a request tamper-proof device based on webpage element visibility verification, which comprises: the request receiving module is used for receiving a request sent by the client; the session detection module is used for judging whether the session information of the client is stored or not; the matching module is used for judging whether the request is matched with the element visibility data table corresponding to the client if the session information of the client is stored; the element visibility data table comprises all elements of the current page of the client which are bound with the request; and the tampering judging module is used for determining that the request is a legal request if the request is matched with the element visibility data table.
Optionally, the apparatus further comprises an update module for: if a request corresponding to a routing element sent by a client is received and the request corresponding to the routing element is a legal request, updating the element visibility data table according to a page after the jump corresponding to the routing element; the routing element is an element which is clicked in a page of the client and jumps to a new page, or an element which is clicked in the page and changes the element contained in the page; the element visibility data table comprises request links, element names and associated routing elements of elements in the page after the jump.
Optionally, the device further comprises a login module for: if the session information of the client is not stored, a login redirection response is returned to the client; if receiving the user login information resent by the client, carrying out login verification; if the login verification is passed, initializing session information corresponding to the client; the session information comprises an initialized session number and an initialized last time received route request; if a default page request sent by the client is received, verifying whether session information of the client is stored or not; and if the session information of the client is stored, returning default page data to the client and updating an element visibility data table corresponding to the client according to the default page data.
The embodiment of the invention can determine whether the request received by the server is a legal request by analyzing whether the request can be initiated by the element binding the request in the current page of the client, namely whether the request can be initiated by the current page of the client or not, and if the request can be initiated, determining that the request is not tampered.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present invention, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic flow chart of a request tamper-proof method based on a webpage element visibility check according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of a web page according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of a page status according to an embodiment of the present invention;
FIG. 4 is a flowchart of another request tamper-proofing method based on webpage element visibility verification according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a request tamper-proof device based on a webpage element visibility check according to an embodiment of the present invention.
Detailed Description
In order that the above objects, features and advantages of the invention will be readily understood, a more particular description of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
The embodiment of the invention discloses a request tamper-proof system based on webpage element visibility verification, which comprises a honeypot management service, a honeypot probe service and a honeypot service.
The embodiment of the invention provides a request tamper-proof method based on webpage element visibility verification, which can judge whether a request received by a server is tampered or not by analyzing whether the request can be sent out by a current page of a client.
Fig. 1 shows a flow chart of a request tamper-proofing method based on webpage element visibility verification, which is provided by an embodiment of the invention, and the method can be applied to a server and comprises the following steps:
s102, receiving a request sent by a client.
The client or browser can call the back-end interface to initiate a request, and the server receives the request and then performs session information check.
S104, judging whether session information of the client is stored. If yes, executing S106, if not, triggering a login response.
A general server maintains a Session table named Session in a memory, wherein the Session table records the information of a client which is recently communicated with the server, and after receiving a request of the client, the server firstly checks whether the request contains a valid Session ID; if not, performing login response; if yes, jumping to the next step;
s106, judging whether the request is matched with the element visibility data table corresponding to the client. The element visibility data table includes all elements of the client's current page that bind the request. If the element visibility data table is matched with the element visibility data table, S108 is executed; if there is no match with the element visibility data table, S110 is performed.
The server pre-builds and maintains an element visibility data table in which any web page contains which elements that bind the request call.
For classifying page elements, referring to the schematic diagram of the web page shown in fig. 2, elements in the marking areas 1, 2 and 3 will jump to a new page or change the content of elements contained in the current page after being clicked, while elements in the marking areas 4 and 5 will stay in the current page after being clicked, the former is called a routing element, and the latter is called a common element. The two elements differ in that a routing element triggers a change in the visibility of a page element, whereas a normal element does not. Still taking fig. 2 as an example, when the elements in regions 4 and 5 are clicked on the current page, the original elements can still be seen and allowed to be clicked on, but when the elements in regions 1, 2 and 3 are clicked on, the elements allowed to be clicked on are quite different due to page skip.
Referring to the schematic diagram of the page state shown in fig. 3, when the user clicks the routing element m, the client jumps to the corresponding page, where the element included in the page and capable of initiating the interface request is composed of two parts, namely other routing elements and a common element, and this set may be referred to as the page state m, where the current page of the client is the page state m. When the client is in the page state m, if the server receives an element request that does not belong to the page state m, it may be determined that it is an illegal tampering request.
When a user clicks a common element, the page state cannot be changed, and only the routing element in the page is clicked, the user can migrate from one page state to another page state. Illustratively, an element visibility data table as shown in Table 1 may be constructed and maintained in the server.
TABLE 1
Wherein the meaning of each field is as follows:
sequence number: a self-added entry primary key; request linking: the current table entry represents a request link for element binding; element name: the current table entry represents the display name of the element; associated routing elements: the current table entry represents that the element is visible under the page corresponding to the routing element; character visibility: what roles have access to the current element.
Optionally, the element visibility data table further includes a self-added primary key of each element in the page after the jump.
S108, determining that the request is a legal request.
Specifically, whether the element name carried by the request or the request link belongs to the element name and the request link included in the element visibility data table corresponding to the client side can be compared; if the element name carried by the request belongs to the element name included in the element visibility data table corresponding to the client, or the request link carried by the request belongs to the request link included in the element visibility data table corresponding to the client, determining that the request is matched with the element visibility data table corresponding to the client.
Taking table 1 as an example, if the element name of the request or the request is linked to table 1, the request is determined to be a legal request.
Considering that the users of the clients are different, the corresponding access rights are also different, and the request sent by the user with the rights is legal. Based on this, the element visibility data table further includes the allowed access users for each element in the page after the jump. Taking table 1 as an example, the role visibility is a user name with authority, and the element visibility data table is an administrator.
Specifically, whether the user name carried by the request belongs to the user name included in the element visibility data table corresponding to the client side can be compared; if the element name belongs to the user name included in the element visibility data table, comparing the element name carried by the request or the request link, and judging whether the element name belongs to the element name and the request link included in the element visibility data table corresponding to the client; if the request belongs to the element name or the request link included in the element visibility data table, the request is determined to be matched with the element visibility data table corresponding to the client.
S110, determining that the request is an illegal request.
The request tamper-proof method based on the webpage element visibility verification provided by the embodiment of the invention can be initiated by analyzing whether the request received by the server is an element binding the request in the current page of the client, namely whether the request can be initiated through the current page of the client, and if so, determining that the request is not tampered and is a legal request.
And in the process of processing the request sent by the client by the server, updating the element visibility data table in real time. Based on this, the above method may further comprise the steps of:
and if a request corresponding to the routing element sent by the client is received and the request corresponding to the routing element is a legal request, updating the element visibility data table according to the page after the jump corresponding to the routing element.
The routing element is an element which is clicked in a page of the client and jumps to a new page, or an element which is clicked in the page and changes the element contained in the page.
In the case that the current page of the client jumps to a new page, the element visibility data table in the server is correspondingly updated, and the updated element visibility data table includes all elements binding the request in the new page. Specifically, the element visibility data table includes request links, element names, and associated routing elements for each element in the page after the jump.
And if the session information of the client is not stored in the server, triggering a login response. Based on this, the above method may further comprise the steps of:
and if the session information of the client is not stored, returning a login redirection response to the client. After receiving the redirection response, the client redirects to the login page, and the user inputs login information to click for login.
If receiving user login information resent by the client, performing login verification;
if the login verification is passed, initializing session information corresponding to the client; the session information includes an initialization session number and an initialization last time a route request was received.
If a default page request sent by a client is received, verifying whether session information of the client is stored or not;
and if the session information of the client is stored, returning default page data to the client and updating an element visibility data table corresponding to the client according to the default page data. Firstly, verifying whether the session information carried by the request is effective, after passing, verifying that the last received route request in the session table of the discovery server is an initial value, updating the field to a request URL (uniform resource locator, uniform resource location system) pointing to a default page, returning the first page data to the client,
fig. 4 is a flow chart of another request tamper-proofing method based on webpage element visibility verification according to an embodiment of the present invention, including the following steps:
s401, the server builds and maintains an element visibility data table. In which any web page is stored that contains which elements that bind the request call.
S402, the client browser (hereinafter referred to as client) invokes the backend interface to initiate a request.
S203, after receiving the request, the server checks whether the server has session information of the client. If not, directly performing S404; if so, the process proceeds to S405.
A general server maintains a Session table named Session in a memory, wherein the Session table records the information of a client which is communicated with the server recently, and after receiving a client request, the server firstly checks whether a Cookie in the request contains a valid Session ID; if not, directly carrying out the next step; if so, the process proceeds to S405.
S404, the server returns a login redirection response to the client, and after the client finishes login, the server establishes a session for the client in a session table.
The basis for judging whether the request is tampered in this embodiment is as follows: "when the client is in state m, if the server receives an element request belonging to another state". If the state of the client is to be known, i.e. which route element corresponds to the page is displayed, the server can store the route request sent by the last received client into the corresponding session table.
The method comprises the following specific steps:
(1) The server returns a login redirection response to the client;
(2) After receiving the redirection response, the client redirects to a login page, and the user inputs login information to click for login;
(3) And after receiving the user login information, the server checks, and if the check fails, the server refuses the user login, and the process is terminated. And if the verification is successful, initializing Session information for the client, wherein the Session at least comprises an initialized Session ID (Session number) and LastRoute (last time of receiving a route request). The server then sends a redirect response to the client that points to the default home page.
(4) And after receiving the response returned by the server, the client redirects the default home page, namely, initiates a new page request.
(5) After receiving the page request sent by the client, the server firstly verifies whether the sessionID carried by the request is valid, and after the sessionID passes, the server verifies that LastRoute in the server session table is found as an initial value, updates the field to a request url pointing to a default home page, returns home page data to the client, and the process is finished.
S405, the server matches the received request with the element visibility data table, and if the matching is successful, the request is a legal request; if the matching fails, the illegal request after tampering is obtained.
The method comprises the following specific steps:
(1) The server obtains a corresponding role by inquiring data according to the user name in the Cookie carried by the request;
(2) The server queries an element visibility data table according to LastRoute in the role and Session, wherein the LastRoute corresponds to an associated routing element field in the table, the role visibility field in the table corresponds to the role, and data in the table are aggregated according to the two fields, namely all the sponsorable requests of pages corresponding to LastRoute in pages which can be viewed by the current user role are found out;
(3) If the request received by the server contains the query result in the last step, judging that the request is a legal request, otherwise, judging that the request is an illegal request after tampering.
The embodiment of the invention can judge whether the request received by the server is tampered or not by analyzing whether the request can be sent out by the current page of the client.
Fig. 5 is a schematic structural diagram of a request tamper-proof device based on a webpage element visibility check according to an embodiment of the present invention, where the device includes:
a request receiving module 501, configured to receive a request sent by a client;
a session detection module 502, configured to determine whether session information of the client is stored;
a matching module 503, configured to determine whether the request matches with an element visibility data table corresponding to the client if session information of the client is stored; the element visibility data table comprises all elements of the current page of the client which are bound with the request;
a tamper determination module 504, configured to determine that the request is a legal request if the request matches the element visibility data table.
The request tamper-proof device based on the webpage element visibility verification provided by the embodiment of the invention can be initiated by analyzing whether the request received by the server is an element binding the request in the current page of the client, namely whether the request can be initiated through the current page of the client, and if so, determining that the request is not tampered and is a legal request.
Optionally, the apparatus further comprises an update module for: if a request corresponding to a routing element sent by a client is received and the request corresponding to the routing element is a legal request, updating the element visibility data table according to a page after the jump corresponding to the routing element; the routing element is an element which is clicked in a page of the client and jumps to a new page, or an element which is clicked in the page and changes the element contained in the page; the element visibility data table comprises request links, element names and associated routing elements of elements in the page after the jump.
Optionally, the element visibility data table further includes a permission to access the user for each element in the page after the jump.
Optionally, the matching module is specifically configured to: comparing whether the element name carried by the request or the request link belongs to the element name and the request link included in the element visibility data table corresponding to the client; if yes, determining that the request is matched with the element visibility data table corresponding to the client.
Optionally, the matching module is specifically configured to: comparing whether the user name carried by the request belongs to the user name included in the element visibility data table corresponding to the client; if the element name belongs to the user name included in the element visibility data table, comparing whether the element name carried by the request or the request link belongs to the element name and the request link included in the element visibility data table corresponding to the client; and if the request belongs to the element name or the request link included in the element visibility data table, determining that the request is matched with the element visibility data table corresponding to the client.
Optionally, the device further comprises a login module for: if the session information of the client is not stored, a login redirection response is returned to the client; if receiving the user login information resent by the client, carrying out login verification; if the login verification is passed, initializing session information corresponding to the client; the session information comprises an initialized session number and an initialized last time received route request; if a default page request sent by the client is received, verifying whether session information of the client is stored or not; and if the session information of the client is stored, returning default page data to the client and updating an element visibility data table corresponding to the client according to the default page data.
Optionally, the element visibility data table further includes a self-added primary key of each element in the page after the jump.
The embodiment of the invention also provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor, implements the processes of the above embodiments, and can achieve the same technical effects, and in order to avoid repetition, the description is omitted here. Wherein the computer readable storage medium is selected from Read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or optical disk.
Of course, it will be appreciated by those skilled in the art that implementing all or part of the above embodiments may be implemented by a computer level to instruct the control device, where the program may be stored in a computer readable storage medium, where the program may be executed, where the program may include the above embodiments of the method, where the storage medium may be a memory, a magnetic disk, an optical disk, or the like.
Finally, it is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
In the present specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, and identical and similar parts between the embodiments are all enough to refer to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A request tamper-proofing method based on webpage element visibility verification, the method comprising:
receiving a request sent by a client;
judging whether session information of the client is stored or not;
if the session information of the client is stored, judging whether the request is matched with an element visibility data table corresponding to the client; the element visibility data table comprises all elements of the current page of the client which are bound with the request;
and if the request is matched with the element visibility data table, determining that the request is a legal request.
2. The method according to claim 1, wherein the method further comprises:
if a request corresponding to a routing element sent by a client is received and the request corresponding to the routing element is a legal request, updating the element visibility data table according to a page after the jump corresponding to the routing element;
the routing element is an element which is clicked in a page of the client and jumps to a new page, or an element which is clicked in the page and changes the element contained in the page; the element visibility data table comprises request links, element names and associated routing elements of elements in the page after the jump.
3. The method of claim 2, wherein the element visibility data table further comprises allowed access users for each element in the jumped page.
4. The method according to claim 1 or 2, wherein said determining whether the request matches an element visibility data table corresponding to the client comprises:
comparing whether the element name carried by the request or the request link belongs to the element name and the request link included in the element visibility data table corresponding to the client;
if yes, determining that the request is matched with the element visibility data table corresponding to the client.
5. The method of claim 3, wherein the determining whether the request matches the element visibility data table corresponding to the client comprises:
comparing whether the user name carried by the request belongs to the user name included in the element visibility data table corresponding to the client;
if the element name belongs to the user name included in the element visibility data table, comparing whether the element name carried by the request or the request link belongs to the element name and the request link included in the element visibility data table corresponding to the client;
and if the request belongs to the element name or the request link included in the element visibility data table, determining that the request is matched with the element visibility data table corresponding to the client.
6. The method according to claim 1, wherein the method further comprises:
if the session information of the client is not stored, a login redirection response is returned to the client;
if receiving the user login information resent by the client, carrying out login verification;
if the login verification is passed, initializing session information corresponding to the client; the session information comprises an initialized session number and an initialized last time received route request;
if a default page request sent by the client is received, verifying whether session information of the client is stored or not;
and if the session information of the client is stored, returning default page data to the client and updating an element visibility data table corresponding to the client according to the default page data.
7. The method of claim 3, wherein the element visibility data table further comprises a self-increasing primary key for each element in the jumped page.
8. A request tamper-resistant apparatus based on a web page element visibility check, the apparatus comprising:
the request receiving module is used for receiving a request sent by the client;
the session detection module is used for judging whether the session information of the client is stored or not;
the matching module is used for judging whether the request is matched with the element visibility data table corresponding to the client if the session information of the client is stored; the element visibility data table comprises all elements of the current page of the client which are bound with the request;
and the tampering judging module is used for determining that the request is a legal request if the request is matched with the element visibility data table.
9. The apparatus of claim 8, further comprising an update module to:
if a request corresponding to a routing element sent by a client is received and the request corresponding to the routing element is a legal request, updating the element visibility data table according to a page after the jump corresponding to the routing element;
the routing element is an element which is clicked in a page of the client and jumps to a new page, or an element which is clicked in the page and changes the element contained in the page; the element visibility data table comprises request links, element names and associated routing elements of elements in the page after the jump.
10. The apparatus of claim 8, further comprising a login module for:
if the session information of the client is not stored, a login redirection response is returned to the client;
if receiving the user login information resent by the client, carrying out login verification;
if the login verification is passed, initializing session information corresponding to the client; the session information comprises an initialized session number and an initialized last time received route request;
if a default page request sent by the client is received, verifying whether session information of the client is stored or not;
and if the session information of the client is stored, returning default page data to the client and updating an element visibility data table corresponding to the client according to the default page data.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310066945.2A CN116132157A (en) | 2023-01-16 | 2023-01-16 | Request tamper-proof method and device based on webpage element visibility verification |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310066945.2A CN116132157A (en) | 2023-01-16 | 2023-01-16 | Request tamper-proof method and device based on webpage element visibility verification |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116132157A true CN116132157A (en) | 2023-05-16 |
Family
ID=86307780
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310066945.2A Pending CN116132157A (en) | 2023-01-16 | 2023-01-16 | Request tamper-proof method and device based on webpage element visibility verification |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116132157A (en) |
-
2023
- 2023-01-16 CN CN202310066945.2A patent/CN116132157A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1368722B1 (en) | Method and system for web-based cross-domain single-sign-on authentication | |
| US8683565B2 (en) | Authentication | |
| KR100800339B1 (en) | Method and system for user-determined authentication and single-sign-on in a federated environment | |
| US5908469A (en) | Generic user authentication for network computers | |
| KR100781725B1 (en) | Method and system for peer-to-peer authorization | |
| US8819253B2 (en) | Network message generation for automated authentication | |
| US7725562B2 (en) | Method and system for user enrollment of user attribute storage in a federated environment | |
| US7587491B2 (en) | Method and system for enroll-thru operations and reprioritization operations in a federated environment | |
| EP2643955B1 (en) | Methods for authorizing access to protected content | |
| US9143502B2 (en) | Method and system for secure binding register name identifier profile | |
| EP1379045B1 (en) | Arrangement and method for protecting end user data | |
| EP0940960A1 (en) | Authentication between servers | |
| US20060136724A1 (en) | Relay method of encryption communication, gateway server, and program and program memory medium of encryption communication | |
| US8555365B2 (en) | Directory authentication method for policy driven web filtering | |
| US20090165124A1 (en) | Reducing cross-site scripting attacks by segregating http resources by subdomain | |
| CN107016074B (en) | Webpage loading method and device | |
| CN111786996B (en) | Cross-domain synchronous login state method and device and cross-domain synchronous login system | |
| CN111770072B (en) | Method and device for accessing function page through single sign-on | |
| EP1209577A1 (en) | Web page browsing limiting method and server system | |
| WO2007068717A1 (en) | Method and system for externalizing http security message handling with macro support | |
| CN107343028B (en) | Communication method and system based on HTTP (hyper text transport protocol) | |
| US20060161971A1 (en) | Method and apparatus for providing secure connectivity between computer applications | |
| CN113411324B (en) | Method and system for realizing login authentication based on CAS and third-party server | |
| CN116132157A (en) | Request tamper-proof method and device based on webpage element visibility verification | |
| CN114244616B (en) | Login verification method, login verification system, electronic device and storage medium |
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 |