Real-time protection method for Web application session data of power monitoring system

Abstract

The invention provides a real-time protection method for Web application session data of an electric power monitoring system. Firstly, JML static constraint is utilized to add constraint conditions for an interface of the power monitoring system, and then an interface technology is simulated through randomized control flow and whether the interface technology meets the constraint conditions or not is verified. And secondly, through a runtime synchronization and state management technology, the consistency of session data in a concurrent environment is ensured by using a synchronous lock, and through a filter interface configuration technology, a Filter interface filtering rule conforming to service logic is configured for the power monitoring system. And finally, realizing real-time protection of session data through a protocol state machine realization technology and state transition logic management, and recording key information for feedback and analysis. The whole process of the method not only improves the safety and reliability of the power monitoring system, but also has good universality and adaptability, and can be suitable for power monitoring systems of different scale architectures.

Description

Technical Field

[0001] This invention relates to the field of power monitoring system security, and in particular to a method for real-time protection of web application session data in power monitoring systems. Background Technology

[0002] With the growth of global energy demand and the rapid development of smart grid technology, power monitoring systems are increasingly widely used in the power industry. These systems integrate sensors, actuators, and communication networks to achieve real-time monitoring and control of power facilities. However, as power monitoring systems become increasingly integrated with enterprise information networks and the Internet, their increased openness exposes them to a growing number of cybersecurity threats, such as malware attacks, data breaches, and session hijacking. Therefore, ensuring the security of power monitoring systems is crucial for guaranteeing the stable operation of the power grid and the reliability of power supply.

[0003] Currently, the security of power monitoring systems primarily relies on traditional network security measures such as firewalls, intrusion detection systems, and security protocols. While these measures improve system security to some extent, they often struggle to address complex session data dependency vulnerabilities. Existing security methods tend to focus on network-level defenses, neglecting in-depth analysis and protection of session data within the power monitoring system. Furthermore, existing protection methods are insufficient in terms of real-time performance, accuracy, and adaptability, making them ineffective against rapidly changing network environments and evolving attack methods. Therefore, developing a method capable of real-time monitoring and protection against session data dependency vulnerabilities in power monitoring systems is of great significance for improving system security and resisting complex attacks.

[0004] For example, a power distribution terminal security testing system based on automated pipeline operation is disclosed on the China Patent Network, with application number CN201910980291.8. The system is characterized by a fully automated testing pipeline design, integrating rich security testing functions, including encryption authentication, risk assessment, and intrusion detection; it has a comprehensive management and control system, achieving seamless connection of the testing process and timely feedback of results; and it employs multiple security isolation mechanisms to ensure network security during the testing process. It also specifically incorporates the function of detecting domestic cryptographic applications, meeting the needs of a specific field. However, this method has drawbacks: it is highly targeted: this solution is primarily aimed at power distribution terminal equipment and is difficult to directly apply to other types of critical systems; it has high deployment complexity: it requires the construction of dedicated pipeline hardware facilities and multiple subsystems such as a security testing platform, making deployment and maintenance relatively more complex; it has high implementation costs: due to the need for significant investment in hardware equipment and system integration, the overall implementation and operating costs may be high; and it has low flexibility: compared to software-level interface security protection, this hardware and system-level solution requires significant modifications and upgrades to address emerging security threats. Summary of the Invention

[0005] The purpose of this invention is to improve the security and reliability of power monitoring systems, primarily implemented at the software level, offering high flexibility, low implementation cost, and low deployment complexity. This method can monitor and respond to potential vulnerabilities in session data in real time, effectively preventing data leakage and malicious attacks. Through this invention, not only can the defense capabilities of power monitoring systems be enhanced, but also in-depth analysis and protection of session data can be achieved without affecting the normal operation of the system.

[0006] To achieve the above objectives, the present invention is implemented according to the following technical solution: S1: Transform the business logic of the power monitoring system into constraints and add constraints to the interfaces of the power monitoring system; S2: Simulate the operations performed on session data by the interfaces described in step S1, verify whether the constraints are met, and mark the interfaces that meet the constraints; S3: Ensure the consistency of session data of the marked interfaces in a concurrent environment; S4: Write configuration files and confirm whether the Filter and filtering rules correspond; S5: Build a management mechanism for state transition logic and verify whether user requests conform to the predetermined state transition rules.

[0007] Preferably, in step S1, the step of adding constraints to the interface includes: writing contract elements and translating the contract elements into JML and performing static analysis.

[0008] Preferably, the specific steps for adding constraints to the interface are as follows: S11: Read the interface of the power monitoring system and convert the business logic into constraints; S12: For each interface, define the necessary contract elements, which are used to represent the constraints of the interface; S13: Using keywords provided by JML, map the preconditions and postconditions involved in the contract elements and the modified member variables to require, ensure, and modify clauses, respectively; use the also keyword to declare the inherited interfaces; S14: Add the constraints as JML comments below the corresponding interface declaration; S15: Perform static analysis on a single interface to check whether the interface meets the constraints; S16: If the check result in step S15 meets the constraints, no operation is required; otherwise, repeat step S15 until the check result fully meets the constraints; S17: Repeat steps S15 to S16 until all the interfaces are verified, and the interface of the power monitoring system containing constraints is obtained.

[0009] Preferably, step S2 includes randomizing the control flow, running the simulation method, and verifying the constraints.

[0010] Preferably, step S2 includes the following steps: S21: Add the interface containing constraints to the simulation method of control flow determined by random values ​​to simulate different operation paths and conditional branches; S22: Add random noise to the interface input of the simulation method to test the behavior of the interface under different inputs; S23: Run the simulation method and record the execution status and system response of each interface in detail; S24: Verify whether the execution result of the simulation method satisfies the constraints of all control flows, and mark the interface according to the verification result.

[0011] Preferably, in step S3, the synchronized code block and the access logic of the synchronized code block ensure the consistency of session data of the marked interface in a concurrent environment.

[0012] Preferably, step S3 includes the following steps: S31: The marked interface records the code block involving the processing of user session data objects; S32: The synchronized keyword is used before the code block involving the processing of user session data objects, and it is passed to the session data object to form a synchronization lock to ensure synchronization; S33: The access logic for shared session data is placed in the synchronized block; S34: Excluding cases where no other synchronized methods are called in the synchronized block, eliminating the risk of deadlock, and obtaining a power monitoring system with added synchronization lock.

[0013] Preferably, in step S4, the specific steps are as follows: S41: Add the JAR package containing the Filter interface to the WEB-INF / lib directory of the power monitoring system with synchronization lock; S42: Configure the Filter interface for the power monitoring system by loading the corresponding JAR package to filter abnormal access behavior; S43: If the power monitoring system supports the @WebFilter annotation in Java, jump to S44; otherwise, jump to S46; S44: Use the urlPatterns attribute of the @WebFilter annotation to explicitly specify the URL patterns that the Filter interface needs to intercept; S45: Use the filterName attribute of the @WebFilter annotation to name the Filter interface and set its order in the request processing chain to obtain the power monitoring system with the Filter interface configured; S46: Write a configuration file to implement the configuration of the Filter interface to obtain the power monitoring system with the Filter interface configured.

[0014] Preferably, in step S5, state transition conditions need to be defined before implementing the state transition system.

[0015] Preferably, the steps for implementing the state transition system are as follows: S51: Read the power monitoring system with the completed Filter interface configuration, identify and list all business points involving state transition; S52: Define the corresponding state transition conditions for each state based on the business logic of the business points involving state transition; S53: Implement the ProtocolStateMachine class to manage state transition logic, including the current state, transition rules, and transition methods; S54: Add the currentState property to the session data object to track and store the current state; S55: Create a Filter interface instance to intercept requests according to the filtering rules configured in S4, and interact with the ProtocolStateMachine; S56: Check the state before the request and the expected state after the request in the Filter. If the state before the request or the expected state after the request does not meet the state transition conditions corresponding to the business, then block the request; otherwise, allow the request, update the state information, and execute normal business logic to obtain the power monitoring system running the protocol state machine; S57: Allow the request according to the request timestamp, request path, and parameters, and append the status information records after processing the request to the log system for feedback.

[0016] This invention addresses session data dependency vulnerabilities in power monitoring systems, implementing a comprehensive protection process from static constraint definition, simulation verification, runtime synchronization and state management, filtering interface configuration to protocol state machine implementation. From the overall technical solution perspective, this invention establishes a complete real-time protection method and process for the first time in the field of power monitoring system security. This invention is not limited by the scale or architecture of the power monitoring system; whether it is a small local monitoring system or a large wide-area monitoring network, the designed protection method can effectively address various session data dependency vulnerabilities. Furthermore, the method of this invention is not dependent on a specific programming language or platform, exhibiting excellent versatility and adaptability. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0018] Figure 2 This is a schematic diagram of the JML static constraint process in this invention.

[0019] Figure 3 This is a schematic diagram of the filter interface configuration process in this invention. Detailed Implementation

[0020] To better illustrate the purpose, technical solutions, and advantages of the embodiments of the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0021] In some embodiments, this embodiment discloses the overall process of a real-time protection method for web application session data in a power monitoring system, such as... Figure 1 As shown in the flowchart of the present invention, the steps of the method include: JML static constraints, simulation verification, runtime synchronization and state management, filter interface configuration, and protocol state machine implementation.

[0022] S1: The JML static constraint step: Use contract elements to describe the business logic of the power monitoring system as constraints, and use the JAVA modeling language (JML) to add constraints to the interface of the power monitoring system. S2: The simulation verification step: randomize the control flow, simulate the operation of the power monitoring system interface with added constraints in step S1 on the session data, verify whether it meets the constraints, and mark the power monitoring system interface that meets the constraints. S3: The runtime synchronization and state management steps: ensure the consistency of session data of the marked power monitoring system interface in a concurrent environment through a runtime synchronization mechanism and state management based on synchronization locks; S4: The filter interface configuration steps are as follows: Write JML comments or XML configuration files to configure the Filter interface filtering rules that conform to the business logic in the power monitoring system with added synchronization locks; S5: The implementation steps of the protocol state machine are as follows: a management mechanism for state transition logic is constructed, user requests received by the system are intercepted and verified to conform to the predetermined state transition rules, session management is performed in strict accordance with the protocol state sequence, and the power monitoring system that has completed the Filter interface configuration follows the predetermined state transition protocol when processing requests.

[0023] In step S1, detailed constraints are added to the interfaces of the power monitoring system using Java Modeling Language (JML), expressing the business logic originally implicit in the code in a clear contractual form. JML is a powerful formal specification language that can very precisely describe preconditions, postconditions, and invariants in Java programs. By adding JML annotations to the interfaces, developers can clearly define the interface's input and output requirements, mutable states, and other constraints. This lays the foundation for subsequent automatic verification.

[0024] In step S2, researchers use random testing to simulate the execution of the power monitoring system interface under various input conditions and check whether it meets the aforementioned JML constraints. Through a large number of automated test cases, problems in the interface implementation can be quickly identified, and interfaces that pass verification can be marked.

[0025] In step S3, for each verified interface, the method adds a runtime synchronization mechanism based on a synchronization lock. Simultaneously, it maintains a state management mechanism to record the current state of the interface. In this way, it ensures the consistency of session data in a concurrent environment, avoiding issues such as race conditions. The state management mechanism can strictly control the state transitions of the interface.

[0026] In step S4, the method configures the system with Filter interface filtering rules that conform to the business logic by writing JML comments or XML configuration. These Filter interfaces are responsible for preprocessing and filtering user requests, ensuring that only requests that meet the constraints and state transition rules can enter the subsequent business logic processing.

[0027] In step S5, the method constructs a state transition logic management mechanism to intercept user requests received by the system and verify whether they conform to the predetermined state transition rules. Specifically, it designs a protocol state machine that strictly follows the predetermined state transition order for session management.

[0028] Through the above five steps, this method achieves comprehensive protection for the key interfaces of the power monitoring system, forming a multi-layered protection mechanism with interlocking links, from static constraints, dynamic verification, concurrent control, filtering configuration to state machine management.

[0029] In some embodiments, this embodiment discloses the overall process of JML static constraints, such as Figure 2 The diagram shown illustrates the JML static constraint process. The steps for this static constraint are as follows: S11: Transform the business logic of the interface into constraints by analyzing the business logic of the interface; S12: For each interface, define the necessary contract elements, including read, write, and possible write operations, to represent the constraints of the interface. S13: Using keywords provided by JML, map the preconditions involved in the contract element to the requires clause, the postconditions involved in the contract element to the ensures clause, the member variables involved in the contract element to the modifying clause, and use the also keyword to declare interfaces involving inheritance. S14. Add the constraints as JML comments below the corresponding interface declaration to provide a basis for the constraints in subsequent static analysis. S15: Use the ESC / Java2 tool to perform static analysis on a single interface and check whether the interface code conforms to the constraints defined in the JML comments; S16: If the results of the check in step S15 meet the constraints, no changes are needed; otherwise, modify the relevant code according to the warnings or error messages output by the ESC / JAVA2 tool, and then repeat step S15 until the results of the check fully meet the constraints. S17: Write an automated script to repeat steps S15 to S16 until all interfaces are verified and the interface of the power monitoring system with added constraints is obtained.

[0030] The first step is the JML static constraint step (S11-S14). First, the business logic of the interface is analyzed and transformed into a series of specific constraints. For example, for the `updatePowerConsumption(int userId, int powerUsage)` interface, the following constraints are determined: the input parameter `userId` must be greater than 0, `powerUsage` must be greater than or equal to 0, and the method return value must be greater than or equal to 0.

[0031] Next, the necessary contract elements are defined for each interface, including read operations, write operations, and possible write operations. Using keywords provided by JML, these contract elements are mapped to preconditions (requires), postconditions (ensures), and modification clauses in JML comments, thus making the interface constraints more explicit and formalized. Finally, these JML comments are added directly below the corresponding interface declarations to provide a basis for subsequent static analysis.

[0032] In the simulation verification steps (S15-S16), the ESC / Java2 tool is used to perform static analysis on a single interface to check whether its implementation conforms to the constraints defined in the aforementioned JML comments. If any non-compliance is found, the code is modified according to the information output by the tool until the constraints are met. This ensures that the interface implementation fully conforms to its constraint definitions.

[0033] Once the verified interfaces are available, in the runtime synchronization and state management step (S3), a runtime synchronization mechanism based on synchronization locks is added to each interface, and a state management mechanism is maintained to record the current state of the interface. This ensures that the session data of the interface remains consistent in a concurrent environment, avoiding problems such as race conditions.

[0034] In the filter interface configuration step (S4), JML comments or XML configurations are written to configure the filter interface filtering rules that conform to the business logic for the system. These filter interfaces are responsible for preprocessing and filtering user requests, ensuring that only requests that meet the constraints and state transition rules can enter the subsequent business logic processing.

[0035] Finally, there is the protocol state machine implementation step (S5). In this step, a management mechanism for state transition logic is established to intercept user requests received by the system and verify whether they conform to the predetermined state transition rules. This ensures that the power monitoring system always follows the established protocol state transition order when processing requests, further guaranteeing the consistency and security of session data.

[0036] By following the steps described above, critical interfaces of the power monitoring system can be comprehensively protected. This method not only clearly defines the constraints of the interfaces but also ensures that they meet the requirements through automated verification, and maintains the consistency and security of session data during runtime.

[0037] In some embodiments, this embodiment discloses a simulation verification process, the steps of which are as follows: S21: Add the constrained interface of the power monitoring system obtained in step S17 to a simulation method that includes if-else, while, and switch-case control flows determined by random values, to simulate different operation paths and conditional branches. S22: Add random noise to the interface input of the simulation method to test the behavior of the interface under different inputs; S23: Run the simulation method and record the execution status and system response of each interface in detail; S24: Use the ESC / JAVA2 tool to verify whether the execution results of the simulation method meet all control flow constraints, and mark the interfaces of the verified power monitoring system.

[0038] Based on the aforementioned interface protection method for power monitoring systems based on constraint verification and state management, the specific implementation steps are further explained in detail. This includes simulation verification of the interface with added constraints, injection of random noise, execution of simulation tests, and final verification using ESC / JAVA2 tools.

[0039] The first step, S21, integrates the power monitoring system interface with added constraints obtained in step S17 into a simulation method that incorporates various control flow structures. This simulation method simulates the complex operation paths and conditional branches that the power monitoring system may encounter in actual operation. Specifically, the simulation method uses control flow statements such as if-else, while, and switch-case to make the interface's execution flow more diverse and unpredictable. This complex simulation environment allows for better testing of the interface's behavior under various scenarios.

[0040] The next step, S22, involves adding random noise to the interface input of the simulation method. This simulates the impact of various uncertainties in the real-world environment on the interface input, such as the uncertainty of user behavior and the instability of network transmission. By injecting random noise, it's possible to check whether the interface can maintain its expected behavior when subjected to various disturbances, thereby improving the system's robustness.

[0041] With the simulation environment and random noise in place, run the simulation method in step S23 and record the execution status and system response of each interface in detail. These records will provide a basis for subsequent verification work.

[0042] Finally, in step S24, the execution results of the simulation method are verified using the ESC / JAVA2 tool. Specifically, it checks whether the actual execution of each interface fully conforms to the constraints defined in the aforementioned JML comments. For interfaces that pass verification, they are marked as "trustworthy"; for interfaces that fail verification, code corrections are needed based on the output of the ESC / JAVA2 tool until the constraints are met.

[0043] Through steps S21 to S24, a more in-depth and comprehensive test and verification of the key interfaces of the power monitoring system were conducted. First, various possible operation paths and input conditions were simulated in a complex simulation environment to examine the interface's behavior under these complex scenarios. Then, the robustness of the interface was further examined by injecting random noise. Finally, using ESC / JAVA2 tools, the simulation results were rigorously verified under constraints to ensure that the actual execution of the interface fully meets expectations.

[0044] These steps not only identify problems in the interface implementation but also ensure that verified interfaces meet all constraints of the business logic during actual operation. This further enhances the reliability and stability of the power monitoring system.

[0045] The aforementioned constraint-based verification and state management methods are further refined and implemented, encompassing a comprehensive range of testing techniques, from simulation verification and random noise injection to final ESC / JAVA2 verification. This multi-layered and comprehensive testing mechanism provides complete protection for the critical interfaces of the power monitoring system.

[0046] In some embodiments, this embodiment discloses a synchronization and state management process, the steps of which are as follows: S31: Analyze the marked interface of the power monitoring system obtained in step S24 and record the code blocks involved in processing user session data objects; S32: Use the synchronized keyword before the code block that handles the user session data object and pass it to the session data object to form a synchronization lock to ensure synchronization. S33: Put the access logic for shared session data into a synchronized block; S34: Excluding cases where no other synchronization methods are called in the synchronization block, eliminating the risk of deadlock, and obtaining a power monitoring system with added synchronization locks.

[0047] Based on the aforementioned interface protection method for power monitoring systems based on constraint verification and state management, the runtime synchronization and state management of key interfaces of the power monitoring system will be further completed. This includes steps such as analyzing verified interfaces, adding synchronization lock mechanisms to key code blocks, and implementing synchronization control for access to shared session data.

[0048] The first step is S31, which analyzes the power monitoring system interface marked as "trusted" in step S24, focusing on code blocks that handle user session data objects. These code blocks are key to potential concurrent access issues and require special attention. Through careful analysis, the specific locations and processing logic of these critical code blocks were determined.

[0049] The next step, S32, involves adding synchronization logic using the `synchronized` keyword before the critical code blocks that handle user session data objects. Specifically, the session data object is used as a monitor for the synchronization lock, ensuring that only one thread can access the session data at a time. This effectively avoids concurrency issues such as race conditions.

[0050] In step S33, all access logic for shared session data is further enclosed in a synchronized block. This ensures that all read and write operations on session data are subject to strict synchronization control, preventing data inconsistencies.

[0051] Finally, in step S34, the implementation of the synchronization block was carefully examined to ensure that no other synchronization methods that might cause deadlock were called. This results in a power monitoring system with an added synchronization lock mechanism, effectively protecting critical session data and maintaining stable system operation.

[0052] Through steps S31 to S34, building upon the aforementioned JML static constraints and simulation verification, the runtime synchronization and state management of the power monitoring system interface were further improved. First, key code blocks involving session data processing were identified, and then a synchronization lock mechanism based on session data objects was added to them. This ensures that access to critical session data is effectively synchronized in a concurrent environment, avoiding data inconsistency issues.

[0053] Furthermore, the implementation of the synchronization blocks was carefully reviewed to ensure there were no potential deadlock risks. This not only enhanced the system's concurrent processing capabilities but also improved its overall robustness and reliability.

[0054] This multi-layered protection mechanism, including static constraint verification, simulation testing, and runtime synchronization management, provides comprehensive security for the critical interfaces of the power monitoring system. This not only identifies problems in the interface implementation but also ensures the consistency of critical session data at runtime.

[0055] In some embodiments, this embodiment discloses a filtering interface configuration process, such as Figure 3 The diagram shown illustrates the filter interface configuration process of this invention. The steps of this process are as follows: S41. Add the JAR package containing the Filter interface to the WEB-INF / lib directory of the power monitoring system with synchronization lock; S42. Configure the Filter interface for the power monitoring system by loading the corresponding JAR package to filter abnormal access behavior; S43. If the power monitoring system supports the @WebFilter annotation in Java, proceed to S44; otherwise, proceed to S46. S44. Use the urlPatterns attribute of the @WebFilter annotation to explicitly specify the URL patterns that the Filter interface should intercept; S45. Use the filterName attribute of the @WebFilter annotation to name the Filter interface and set its order in the request processing chain to obtain the power monitoring system with the Filter interface configured. S46. Write an XML configuration file to configure the Filter interface, and obtain a power monitoring system with the Filter interface configured.

[0056] The previous sections introduced interface protection methods for power monitoring systems based on constraint verification and state management, including key steps such as JML static constraints, simulation verification, runtime synchronization, and state management. Building on this foundation, this section will further explain how to enhance the security of power monitoring systems through interface filtering configuration.

[0057] The first step, S41, involves adding the pre-prepared JAR package containing the Filter interface to the WEB-INF / lib directory of the power monitoring system. These Filter interfaces are responsible for preprocessing and filtering user requests, ensuring that only requests that meet the constraints and state transition rules can proceed to subsequent business logic processing.

[0058] The next step, S42, involves loading the corresponding JAR packages to configure these Filter interfaces for the power monitoring system. These Filter interfaces will intercept and verify user requests when they enter the system, ensuring their legitimacy and security.

[0059] In step S43, first check whether the power monitoring system supports the @WebFilter annotation in Java. If it does, proceed directly to step S44; otherwise, jump to step S46.

[0060] For systems that support the `@WebFilter` annotation, the `urlPatterns` attribute of this annotation is used in step S44 to explicitly specify the URL patterns that the Filter interface should intercept. This allows for targeted preprocessing and filtering of specific URLs, improving system security.

[0061] Next, in step S45, the `filterName` attribute of the `@WebFilter` annotation is used to name the Filter interface and set its order in the request processing chain. This ensures that the execution order of the Filter interfaces is consistent with the expected business logic, preventing unexpected processing results. This completes the configuration of the Filter interfaces for the power monitoring system that supports the `@WebFilter` annotation.

[0062] For systems that do not support the `@WebFilter` annotation, an XML configuration file is written in step S46 to configure the Filter interface. This XML configuration can also specify the URL patterns that the Filter interface should intercept, and their order in the processing chain. In this way, the Filter interface configuration for power monitoring systems that do not support annotations is also completed.

[0063] Through steps S41 to S46 above, building upon the aforementioned JML static constraints, simulation verification, runtime synchronization, and state management, a filtering interface configuration function is further added to the power monitoring system. These filter interfaces can preprocess and filter user requests when they enter the system, ensuring that only requests that meet the constraints and state transition rules can proceed to subsequent business logic processing.

[0064] Whether using the `@WebFilter` annotation or XML configuration, the URL patterns that the Filter interface needs to intercept and their execution order in the processing chain can be flexibly defined. This provides a more granular and controllable means for system security protection, effectively blocking various abnormal access behaviors.

[0065] This multi-layered protection mechanism, including static constraint verification, simulation testing, runtime synchronization management, and filtered interface configuration, constructs a comprehensive security protection system for the critical interfaces of the power monitoring system. This not only identifies problems in the interface implementation but also ensures the consistency of critical session data at runtime, effectively blocks abnormal access, and ensures system stability.

[0066] In some embodiments, this embodiment discloses a filtering interface configuration process, the steps of which are as follows: S51: Read the power monitoring system after completing the Filter interface configuration, identify and list all service points involving state transition; S52: Based on the business logic of the business points involving state transitions, define the corresponding state transition conditions for each state. S53: Implement the ProtocolStateMachine class to manage state transition logic, including the current state, transition rules, and transition methods; S54: Add the currentState property to the session data object to track and store the current state; S55: Create a Filter interface instance to intercept requests based on the filtering rules configured in S4, and interact with ProtocolStateMachine; S56: In the Filter, check the state before the request and the expected state after the request. If the state before the request or the expected state after the request does not meet the conditions for the state transition corresponding to the business, then block the request. Otherwise, let the request through, update the state information and execute the normal business logic to obtain the power monitoring system running the protocol state machine. S57: Record the request timestamp, request path and parameters, whether the request is allowed, and the status information after the request is processed in an append-only manner and write it to the log file for feedback.

[0067] Based on the aforementioned interface protection method for power monitoring systems based on constraint verification and state management, a protocol state machine was further designed and integrated to ensure that the system always follows the predetermined state transition sequence when processing requests, thereby further guaranteeing the consistency and security of session data.

[0068] First, in step S51, the power monitoring system with the completed Filter interface configuration was carefully read, and all key business points involving state transitions were identified. These business points are the key to potential state inconsistencies in the system and require special attention. Through analysis, the specific processing logic and state transition characteristics of these business points were understood.

[0069] In step S52, based on the logic of these business points involving state transitions, corresponding business conditions and state transition rules are defined for each possible state. For example, for the updatePowerConsumption interface, the following states and their corresponding transition conditions can be defined: Not logged in (userId<0) -> Invalid request parameters, transfer not allowed; Logged in (userId>0) -> Can be moved to the updating state; Update in progress -> Can be moved to update complete status; Update complete -> You can switch back to logged-in status.

[0070] In step S53, the ProtocolStateMachine class was designed and implemented to manage these state transition logics. This class contains core elements such as the current state, transition rules, and state transition methods, providing support for subsequent state verification and maintenance.

[0071] To work with ProtocolStateMachine, a currentState property was added to the session data object in step S54 to track and store the current state information. This allows ProtocolStateMachine to query and update the state of the session data at any time.

[0072] In step S55, Filter interface instances are created to intercept requests based on the filtering rules configured in S4. These Filter interfaces interact with the ProtocolStateMachine to check whether the current request conforms to the established state transition rules.

[0073] Finally, in step S56, the Filter interface first checks the current state before the request and the expected next state after the request to see if they meet the state transition conditions defined in the business logic. If they do not meet the conditions, the request will be blocked; if they do meet the conditions, the request will be allowed, the session data state information will be updated, and normal business logic processing will continue.

[0074] To facilitate subsequent analysis and feedback, detailed information for each request is recorded in step S57, including the request timestamp, request path and parameters, whether the request was allowed, and the latest status information after the request was processed.

[0075] Through steps S51 to S57, building upon the aforementioned JML static constraints, simulation verification, runtime synchronization management, and filter interface configuration, the design and integration of the protocol state machine were further realized. This ensures that the power monitoring system always follows the predetermined state transition sequence when processing requests, effectively maintaining the consistency and security of session data.

[0076] Specifically, all key business points involving state transitions were first identified, and corresponding business conditions and transition rules were defined for each state. Based on this, the ProtocolStateMachine class was designed and implemented to manage these state transition logics. Simultaneously, a currentState property was added to the session data object to track the current state.

[0077] Building upon this, a Filter interface instance was created to intercept requests and interact with the ProtocolStateMachine. This way, when a request enters the system, the Filter can check if the current state meets business requirements; if not, it will directly block the request, preventing state inconsistency issues.

[0078] Finally, detailed information for each request was recorded, providing data for the analysis and improvement of system operation. This data can be used for subsequent system analysis and improvement.

[0079] By designing and integrating this protocol state machine, the security protection mechanism of the power monitoring system is improved, ensuring that the system always follows the predetermined state transition sequence when processing requests, and maintaining the consistency and security of session data.

[0080] This invention has illustrated its purpose, technical solutions, and beneficial effects through specific embodiments. However, these embodiments are merely examples to demonstrate the application of the invention and do not constitute a limitation on the scope of protection of this invention. We explicitly state that any reasonable modifications, equivalent substitutions, or technical improvements guided by the spirit and principles of this invention should be included within the scope of protection of this invention. This means that as long as these changes do not deviate from the core idea and basic function of the invention, they should be protected by patent rights. The scope of protection of this invention should be broad, including all directly obvious variations as well as non-obvious innovations that a technical expert can reasonably deduce from the disclosure of this invention. This broad protection aims to promote further research and development based on this invention, while ensuring that its innovativeness and practicality are fully protected by law.

Claims

1. A method for real-time protection of web application session data in a power monitoring system, characterized in that, Includes the following steps: S1: Transform the business logic of the power monitoring system into constraints, and add constraints to the interface of the power monitoring system. S2: Simulate the operations performed on session data by the interface described in step S1, verify whether the constraints are met, and mark the interfaces that meet the constraints. S3: Ensure the consistency of session data for the marked interfaces in a concurrent environment; S4: Write the configuration file and confirm that the Filter and filtering rules correspond; S5: Build a management mechanism for state transition logic, and verify whether user requests conform to the predetermined state transition rules.

2. The real-time protection method for Web application session data of a power monitoring system according to claim 1, characterized in that, In step S1, the step of adding constraints to the interface includes: writing contract elements; the specific way of writing the contract is: reading the interface, converting the business logic into constraints, and defining the necessary contract elements to represent the constraints of the interface.

3. The real-time protection method for Web application session data in a power monitoring system according to claim 2, characterized in that, Step S1 further includes: using keywords provided by JML to map the preconditions, postconditions, and modified member variables involved in the contract elements to requires clauses, ensures clauses, and modifyes clauses, respectively; using the also keyword to declare the inherited interface, and adding the constraints as JML comments below the corresponding interface declaration; and performing static analysis on the interface to check whether it meets the constraints.

4. A real-time protection method for Web application session data of a power monitoring system according to any one of claims 1 to 3, characterized in that, Step S2 includes randomizing the control flow; specifically, the randomized control flow involves adding the interface containing constraints to a simulation method of a control flow determined by random values, simulating different operation paths and conditional branches. The simulation method is then run, and the constraints are verified.

5. The real-time protection method for Web application session data of a power monitoring system according to claim 4, further comprising, in step S2: Run the simulation method and verify the constraints; The specific methods for running the simulation and verifying the constraints are as follows: add random noise to the interface input of the simulation method to test the behavior of the interface under different inputs; run the simulation method and record the execution status and system response of each interface in detail; verify whether the execution result of the simulation method satisfies the constraints of all control flows, and mark the interface according to the verification result.

6. A real-time protection method for Web application session data of a power monitoring system according to any one of claims 1 to 3, characterized in that, In step S3, the synchronized code block and its access logic ensure the consistency of session data for the marked interface in a concurrent environment.

7. A real-time protection method for Web application session data in a power monitoring system according to claim 6, characterized in that, In step S3, the marked interface records the code block that handles user session data objects; the synchronized keyword is used before the code block that handles user session data objects, and it is passed to the session data object to form a synchronization lock to ensure synchronization; the access logic for shared session data is put into the synchronized block; if no other synchronized methods are called in the synchronized block, the risk of deadlock is eliminated, and a power monitoring system with added synchronization lock is obtained.

8. A real-time protection method for Web application session data of a power monitoring system according to any one of claims 1 to 3, characterized in that, In step S4, the JAR package containing the Filter interface is added to the WEB-INF / lib directory, and the Filter interface is configured by loading the JAR package to filter abnormal access behavior. If the system supports the @WebFilter annotation in Java, then the URL patterns to be intercepted should be explicitly specified; otherwise, a configuration file should be written to configure the Filter interface. The urlPatterns attribute of the @WebFilter annotation should be used to specify the URL patterns to be intercepted, and the filterName attribute should be used to name the Filter interface and set the request processing order, thereby completing the configuration of the Filter interface.

9. A real-time protection method for Web application session data of a power monitoring system according to any one of claims 1 to 3, characterized in that, In step S5, state transition conditions need to be defined before implementing the state transition system. The way to define the state transition conditions is as follows: after reading the configured power monitoring system, identify all service points involved in state transition, and define transition conditions for each state.

10. A real-time protection method for Web application session data of a power monitoring system according to any one of claims 9, characterized in that, The implementation of the state transition system is as follows: a module that implements the ProtocolStateMachine class to manage state transition logic; a mechanism that adds the currentState property to the session data object to track the current state; a function that creates Filter interface instances according to filtering rules to intercept requests and interact with ProtocolStateMachine; and a process in which the state before and after the request is checked in the Filter, and if the transition conditions are not met, the request is blocked, and if the conditions are met, the request is allowed and the state is updated to execute the business logic. It also includes the function of recording status information based on the request's timestamp, path, and parameters, and appending it to the log system for subsequent feedback.

Images