webhook: signature verification silently no-ops without encrypt_key; no timestamp-freshness or replay checks
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
The issue identifies _verify_sign as the no-op path and points to _verify_webhook_request plus its tests in dsh-feishu-bridge as a reference. Read those entry points first; completion requires an agreed SDK scope and tests covering the selected handling for missing keys, timestamp freshness, and replay deduplication.
Written by the indexing model from the issue text.
Description
Context
We run lark-channel-sdk==1.2.0 inside two FastAPI-based webhook bridges. While security-reviewing the webhook path we found that delegating request verification entirely to the SDK leaves several gaps. Reporting them here so other integrators are aware and so they can be considered for hardening — happy to provide more detail or test cases.
Observed on 1.2.0
- Signature verification silently no-ops when no encrypt key is configured.
_verify_signreturns without checking anything ifencrypt_keyis unset. That may be by design (Feishu only signs when encryption is enabled), but the caller gets no signal that inbound requests are effectively unauthenticated — an integrator who reads "the SDK verifies signatures" can ship an open webhook without realizing it. - No timestamp-freshness check. Even with
encrypt_keyconfigured and the signature verified,X-Lark-Request-Timestampis never checked against a window, so an arbitrarily old (captured) request still verifies. - No replay deduplication. There is no
(timestamp, nonce)dedup, so a captured legitimate request can be replayed indefinitely and will pass verification every time.
Combined effect: a captured request is replayable forever, and in the no-encrypt-key configuration any forged request is accepted.
Suggestions
- Fail loudly (or require an explicit opt-out) when webhook mode runs without an encrypt key, instead of silently skipping verification.
- Reject timestamps outside a configurable window (we use ±300s, rejecting the exact boundary so replay-cache TTLs stay strictly positive).
- Document that replay dedup is the integrator's responsibility, or provide a small
(timestamp, nonce)cache with TTL tied to the timestamp's remaining validity.
What we did meanwhile
We now verify signature + timestamp window + replay dedup at our own boundary before the SDK sees the request, e.g. https://github.com/wz-heng/dsh-feishu-bridge (see _verify_webhook_request and its tests). Not a criticism of the SDK's scope — just flagging that today's behavior is easy to over-trust.
- Dominant language
- Python
- Stars
- 17
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from larksuite/channel-sdk-python
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
-
merge_streaming_text drops characters for pure-delta streaming producersPossibly taken @Xuxchloris claimed this 57 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 58/100
-
Long threaded reply leaks out of a topic/thread chat: reply_to dropped on chunks after the firstPossibly taken @Ydz0616 claimed this 95 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
All issues in larksuite/channel-sdk-python
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
NousResearch/hermes-agent#136483 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
[BUG] LazyStackedTensorDictStore zeroes the last byte of a new key set on the last elementPossibly taken @peterdsharpe claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
pytorch/tensordict#2307 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
GrokModel.generate/a_generate pass an OpenAI-style list-of-dicts to xai_sdk.chat.user(), so every call crashes with a protobuf TypeError before any network I/OPossibly taken @Christian-Sidak claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
confident-ai/deepeval#3436 · 1 comment ·
Maintainers usually reply within 1 day