CAXSS: A Cookie Authentication Scheme Against XSS Attacks for HTTPS

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper proposes CAXSS, a novel cookie authentication framework designed to defend HTTPS-based web applications against cross-site scripting (XSS) and related session hijacking threats.  The scheme introduces an Elliptic Curve Digital Signature Algorithm (ECDSA)–based cookie authentication mechanism that enforces mutual verification between clients and servers.  The authors further conduct formal security validation using GNY logic and Scyther model checking to demonstrate correctness, confidentiality, and resistance to replay or forgery attacks. The study is technically solid and demonstrates a strong understanding of web protocol security.  Its combination of asymmetric cookie signatures and TLS coupling is elegant and practical.  However, the manuscript could be strengthened by clarifying the implementation feasibility, comparing computational efficiency with modern standards, and emphasizing how it complements or differs from existing TLS extensions and CSP-based mitigations. Here are the following suggestions for revision:

1. It is advisable to have the manuscript undergo professional technical English editing to refine grammar, spelling, and sentence structure, ensuring clearer conveyance of research objectives and results.
2. While the proposed CAXSS scheme is well-motivated, its innovation lies primarily in integrating existing primitives—ECC-based signatures and HTTPS handshake extensions. The authors can emphasize how CAXSS extends beyond token signing approaches or secure cookie flags in existing standards. A short comparative table highlighting distinctions from prior schemes such as OTC, OTP-based protocols, or CSP policies would improve clarity on originality and relevance.
3. Although the authors claim that CAXSS achieves high efficiency through lightweight ECC operations, the manuscript lacks empirical benchmarking of computational and latency overheads. For web-scale adoption, detailed comparisons of signature generation time, key size trade-offs, and throughput under concurrent requests are essential. Furthermore, the paper should address backward compatibility and deployment challenges within standard HTTPS stacks (e.g., browser support, TLS library modification requirements).
4. The formal analyses using GNY logic and Scyther effectively establish correctness and resilience under theoretical assumptions. However, the threat model remains somewhat idealized—it does not consider practical client-side attack vectors such as browser extension hijacking, DOM-based XSS persistence, or key storage compromise. Extending the analysis with discussion of real-world attacker capabilities (e.g., compromised JavaScript contexts) or integration with secure enclave storage would enhance credibility.
5. The paper is well-organized and technically thorough, but its length and density make comprehension challenging for readers outside cryptography fields. Some sections (e.g., 3.3–3.7) contain excessive procedural detail that could be condensed or moved to an appendix. The formal verification results (Figure 5) could include a summary table of verified properties for better readability. Finally, the conclusion should be strengthened by summarizing limitations and outlining future research directions such as browser-integrated cryptographic APIs.
6. To enrich the research background, the relevant paper is worth referencing:
   [a]A Resilience Recovery Method for Complex Traffic Network Security Based on Trend Forecasting[J]. International Journal of Intelligent Systems,2025,2025(1):3715086.                [b] An interpretable deep learning framework for intrusion detection in industrial Internet of Things[J].  Internet of Things, 2025: 101681.

In summary, this study has its own contributions, but improvements are needed in terms of presentation and the issues mentioned above, Major Revision is required before acceptance.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

This paper proposes CAXSS, a scheme aiming to mitigate session hijacking via XSS by cryptographically signing HTTP cookies using ECDSA. While the objective is relevant and the integration with HTTPS is a practical approach, the protocol suffers from significant technical shortcomings, questionable design choices, and a lack of depth in its security and performance analysis. The following critique details these concerns.

1. Critical Flaws in Cryptographic Protocol Design

a) Misuse and Redundancy of Signatures:
The core mechanism involves a double-signature process: the server signs the cookie , and then the client re-signs a hash of the cookie . This design is convoluted and introduces unnecessary complexity.
-Server Signature  is Largely Redundant: The servers signature is verified by the client upon receipt. However, in the standard HTTPS/TLS model, the client has already authenticated the server during the TLS handshake and is receiving the cookie over this authenticated channel. The additional signature on the cookie content provides marginal security benefit against a network attacker, as the channel is already confidential and authenticated. Its primary stated purpose—allowing the client to verify the cookies origin—is already a property of the TLS channel.
-Client Signature  is the True Mechanism: The clients signature is the actual defense against cookie theft. An attacker who steals the cookie via XSS cannot forge this signature without the clients private key. However, the paper fails to justify why the entire double-signature structure is necessary instead of a simpler model where the server issues a cookie and the client immediately signs it with its own key.

b) The "Dual-Mode Authentication" is a Logic Flaw:
The protocol introduces a "preliminary verification" (using the clients signature ) and a "secondary verification" (comparing a hash h). After the first successful signature verification, the server sets a client_verified flag and subsequently only checks that the received hash h matches a stored value h.
-This completely undermines the security claim. The entire security premise is that a signature is required for each request. Once the server switches to the hash-check mode, it is no longer validating the clients proof-of-possession of the private key. If an attacker steals the cookie after the client_verified flag is set, they can replay the (cookie, h) tuple indefinitely until the cookie expires. The scheme effectively degrades from a strong cryptographic authentication to a simple shared secret (the hash h) that is transmitted in cleartext within the encrypted channel, thus negating the primary claimed benefit.

c) Incomplete and Problematic Key Management:
The paper glosses over the most challenging aspect of any asymmetric client authentication scheme: key management.
-Client Key Generation and Storage: Where and how is the clients private key (SK_c) generated and stored? If its stored in the same browser context (in localStorage or an unsecured JavaScript variable) as the cookies, it is equally vulnerable to theft via the same XSS vulnerability. The paper provides no details on secure, non-exportable storage (using Web Crypto API or hardware security modules).
-Server-side Public Key Registration: The protocol assumes the server possesses the clients public key (PK_c). How is this key initially registered and bound to a user account? This process is non-trivial and introduces a significant deployment and usability hurdle that the paper entirely ignores. Without a secure bootstrap, the entire system is vulnerable to man-in-the-middle attacks during account setup.

2.  Questionable Security Analysis

a) Formal Verification is Misleading:
The paper uses GNY logic and the Scyther tool for formal verification. However, the models used are abstract and do not reflect the protocols critical weaknesses.
-The GNY logic analysis primarily verifies the initial server-to-client message, proving the client can trust the cookies origin. It does not formally model the flawed "dual-mode" authentication, which is the protocols most significant vulnerability.
-The Scyther model (Figure 4) is simplistic. It shows the client signing H(cookie) but does not model the servers subsequent decision to skip signature verification after the first time. A faithful model would include this stateful behaviour, which would likely cause the verification of authentication claims to fail. The statement that "all security claims are satisfied" is therefore valid only for an idealised version of the protocol that does not include its most critical stateful logic.

b) Security Claims Overstated Against Stated Threats:
-Resistance to MITM Attacks: The claim of MITM resistance is primarily inherited from TLS. The signature σ_s adds no meaningful protection against a MITM that can already break or proxy the TLS connection.
-Resistance to Replay Attacks: The reliance on a short-term timestamp (ΔT_max = 5 minutes) is a weak defence. It requires strict clock synchronisation and is susceptible to replay within this window. A proper nonce or sequence number, agreed upon during the initial handshake, would be a more robust solution.
-Session Fixation: The claim is valid only if a new cookie (with a new Cid_c) is issued upon login, which is standard practice and not an innovation of CAXSS.

3. Inadequate Performance Evaluation and Comparison

a) Unrealistic Benchmark:
The paper compares CAXSS only against the scheme by Lee et al. [18], which is based on ElGamal over multiplicative groups. This is a straw-man comparison. ECC is universally known to be more efficient than classic RSA/ElGamal for equivalent security. A more relevant and critical comparison would be against:
1.  Standard HTTPS sessions with short-lived cookies.
2.  Existing token-binding or same-site cookie proposals.
3.  Schemes using symmetric-key cryptography (HMAC) on the client side, which would be far more efficient if a secure key storage mechanism existed.

b) Omission of Critical Overheads:
The performance evaluation focuses only on the cryptographic operations for signing and verification.
-It completely ignores the latency and complexity introduced by the stateful server-side session management (storing hashes h, managing the client_verified flags, and performing database lookups for every request). This overhead is likely to be more significant than the cost of a single ECDSA verify operation in a high-concurrency server.
-The communication overhead analysis is naive, focusing only on bit lengths and ignoring the practical overhead of adding hundreds of bytes of signature data to every HTTP request header. This can have a non-trivial impact on performance, especially for applications making many small requests.

4. Lack of Practical Deployment Considerations

-Client-Side Complexity: The scheme requires significant JavaScript execution on the client side for cryptographic operations (key generation, signing). This impacts page load times, consumes battery on mobile devices, and is incompatible with simple clients or browsers with JavaScript disabled.
-No Consideration of Real-World XSS Vectors: The threat model assumes XSS is used only to steal cookies. A sophisticated XSS attack could potentially hijack the entire browsing context and perform these cryptographic operations on behalf of the user without exfiltrating the key, thereby generating valid signatures for malicious requests. The scheme does not protect against this.

 

For these reasons, while the paper identifies a valid problem, the proposed solution is not technically sound for practical deployment. A more robust approach would be to use a single, consistently verified client signature per request, coupled with a rigorous and practical solution for secure client key storage—a challenge that remains largely unsolved in the standard web browser model.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

I really appreciate the author’s response—it has resolved some of my issues. Their reply was quite meticulous, but I still have a few remaining questions:

1. The current performance evaluation uses synthetic benchmarks and lacks testing under real-world conditions, weakening the conclusion of "acceptable overhead.". First, the communication overhead analysis assumes a fixed 100 Mbps network but does not test edge networks (e.g., 3G/4G with high latency). Extending tests to low-bandwidth scenarios would verify if the 0.5088 ms transmission delay remains acceptable. second, the manuscript does not evaluate cookie size impact on browser behavior—some browsers limit cookie header size (typically 4KB), and CAXSS’s 54-byte client cookie is well within limits, but the authors should confirm compatibility with legacy systems or proxy servers that may have stricter constraints. Additionally, testing on mobile devices (with limited CPU/memory) would demonstrate CAXSS’s applicability to mobile web scenarios. These improvements ensure the performance conclusions are robust across real-world deployment environments.
2. The manuscript’s key management design has critical ambiguities, especially for long-term sessions, which undermines deployability. First, it states SK_c is stored only in runtime memory and cleared on session termination, but it does not specify how to handle persistent sessions (e.g., "remember me" functionality). The authors need to explain whether SK_c can be securely persisted or if a new key pair is generated per session—both options have tradeoffs (convenience vs. security) that require technical justification. Second, the server must associate PK_c with user identities, but the manuscript does not detail how PK_c is registered and synchronized in distributed systems. A supplementary section on key registration and distributed key lookup is necessary. Finally, the scheme does not address key revocation (e.g., if SK_c is compromised)—adding a revocation mechanism (e.g., server-side blacklisting of PK_c) would enhance security completeness. These clarifications are essential for real-world deployment, as poor key management often renders cryptographic schemes ineffective.
3. The manuscript adopts ECC (secp160r1/secp256r1) for digital signatures but lacks detailed justification for parameter selection and analysis of cryptographic security under modern threats. First, it claims 160-bit ECC equals 1024-bit RSA security, but industry standards now seem recommend 256-bit ECC (equivalent to 3072-bit RSA) for long-term security. The authors should explain why 160-bit is sufficient for their use case, or supplement tests with 256-bit to show performance-security tradeoffs. Then, the hash function H() is not explicitly defined and validating its collision resistance in the context of cookie signature verification will strengthen cryptographic rigor.
4. To enrich the research background, the relevant paper is worth referencing:
   [a] A health assessment framework of lithium-ion batteries for cyber defense[J]. Applied Soft Computing, 2021, 101: 107067.

In short, though the manuscript has seen marked improvements following a revision round, significant additional revisions are still needed to resolve outstanding key issues and meet acceptance requirements.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

Most of my round 1 recommendations were addressed- recommend acceptance 

Author Response

We sincerely thank you for your professional review and favorable feedback on our revised submission.