dpgaspar commented on issue #35921:
URL: https://github.com/apache/superset/issues/35921#issuecomment-3485182264
End-to-end HTTPS will already prevent most of these attacks, since it
encrypts all communication between the client and server, ensuring that an
attacker cannot intercept or modify API requests in transit. This means that a
third party on the network cannot capture a valid request and replay it later —
the encrypted transport channel prevents that.
However, HTTPS alone does not fully eliminate the possibility of replay
attacks. While it secures the data in transit, it does not ensure that each
request is unique or time-bound. If the same valid request is sent multiple
times over a legitimate HTTPS session, the server will typically accept it
again, since HTTPS does not include any mechanism for detecting duplicate or
repeated requests.
Yet, this attack is not possible by a network eavesdropper:
TLS adds:
Message authentication codes (MACs) or AEAD tags, which prove the
authenticity of each record.
Sequence numbers that prevent reordering or reuse of packets.
If an attacker tries to replay an old TLS packet (even from the same
session):
The recipient detects the sequence number mismatch.
The MAC check fails.
The connection is immediately dropped.
So even within the same TLS session, packet-level replay is prevented.
So this is only possible by a client-side breach or a Proxy or API gateway
breach.
To mitigate this, it’s best practice to add application-level replay
protection on top of HTTPS. This can be achieved by:
Including a timestamp and HMAC signature in every API request, which the
server or API gateway validates.
Enforcing a short validity window (for example, ±5–10 seconds) for the
timestamp.
Optionally caching used signatures or nonces for a few seconds to reject
duplicates.
This approach, used by platforms like AWS and Stripe, ensures that even if
an identical HTTPS request is sent again, it will be rejected as invalid.
Implementing this at the API gateway level (e.g., using Kong or NGINX with Lua)
provides robust replay protection without modifying Apache Superset itself.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
