Files
EventSnap/e2e/specs/07-adversarial/ddos.spec.ts
fabi 32dfe6874a test(e2e): make nine red specs assert the contracts the code actually implements
The e2e suite had never been run during this audit. It failed 9 of 256; seven of those
predated the audit's changes, established by building a stack from a clean HEAD worktree
and running the same specs against it rather than guessing.

Most were stale assertions rather than product defects:

- quota.spec solved for a target limit using the observed uploader count, but the divisor is
  max(active, estimated_guest_count, 1) and that config seeds at 100 — so every limit it
  aimed for came out 100x small and every "within quota" upload 413'd.
- rate-limit-shared-nat destructured `ticket` from a 429 body and fetched with
  `ticket=undefined`, turning the 429 under test into an unrelated 401. It also faked a
  release with no archive on disk, so the mint's pre-check 404'd and the per-day limiter was
  never reached; it now does a real release and asserts 200 rather than "not 429".
- ddos allowed only [200,429] from ten concurrent streams, so it failed on the very defence
  it exercises: four tickets per session survive and the rest correctly 401. Now asserts
  exactly four, which a tightened cap or an inverted eviction order would catch.
- auth-tampering asserted a throttled IP is refused EVEN with the correct password. That
  contract was deliberately removed — it let any phone on the venue NAT lock the operator
  out of their own admin panel, with a circular escape hatch. Inverted, plus a new check
  that a success does not refill an attacker's bucket.
- moderation-ui assumed a ban leaves a comment "stuck on screen"; `list_for_upload` filters
  banned authors, so it is hidden from everyone including the host. Now pins the pair that
  matters — the ban hides it, and the host's permanent removal survives an unban — and the
  UI leg it used to own is restored as a separate test on a reachable comment.

The export specs mint with `?kind=` now that a download ticket is bound to one archive, and
four of them assert the mint's 404 rather than the download's: with the kind always known,
the pre-check refuses up front instead of after charging a daily download for an archive
that cannot be served.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 22:44:48 +02:00

144 lines
7.1 KiB
TypeScript

/**
* Phase 2 adversarial — small-scale DDoS / oversized-body tests. These are
* NOT real load tests. We just verify that obvious abuse is rate-limited
* or rejected gracefully without crashing the backend.
*/
import { test, expect } from '../../fixtures/test';
import { mintSseTicket } from '../../helpers/sse';
import { seedUpload } from '../../helpers/seed';
import { BASE } from '../../helpers/env';
test.describe('Adversarial — small-scale abuse', () => {
// Note: the truncate auto-fixture resets every rate-limit toggle back to false
// before each test, so we re-enable in beforeEach (not beforeAll).
test.beforeEach(async ({ api, adminToken }) => {
await api.patchConfig(adminToken, { rate_limits_enabled: 'true', join_rate_enabled: 'true' });
});
test('a /join flood from one IP is caught by the per-IP ceiling', async ({ api, adminToken }) => {
// This used to assert that 20 joins from one IP produced 429s under a 5/min per-IP
// bucket. That "protection" was the bug: at a venue every guest shares one public IP,
// so it turned real arriving guests away (see 01-auth/rate-limit-shared-nat). The
// anti-spam bucket is now per (ip, name); what remains per-IP is a loose ceiling whose
// job is only to bound raw volume. Squeeze the ceiling so a flood is reproducible here
// without firing 60+ requests.
await api.patchConfig(adminToken, { join_ip_rate_per_min: '5' });
const requests = Array.from({ length: 20 }, (_, i) =>
fetch(`${BASE}/api/v1/join`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ display_name: `Flood${i}_${Date.now()}` }),
})
);
const statuses = (await Promise.all(requests)).map((r) => r.status);
// Ceiling of 5 → the excess must be shed.
expect(statuses.filter((s) => s === 429).length).toBeGreaterThan(0);
// Server stays up — at least one succeeded.
expect(statuses.some((s) => s === 201 || s === 409)).toBe(true);
});
// The comment body cap lives in [backend/src/handlers/social.rs] `add_comment`:
// if text_chars == 0 || text_chars > 500 → 400
// It must be exercised against a REAL upload: the handler looks the upload up (and
// 404s) *before* it reaches the length check, so posting to a non-existent id proves
// nothing about the cap.
async function postComment(jwt: string, uploadId: string, body: string) {
return fetch(`${BASE}/api/v1/upload/${uploadId}/comments`, {
method: 'POST',
headers: { Authorization: `Bearer ${jwt}`, 'Content-Type': 'application/json' },
body: JSON.stringify({ body }),
});
}
test('comment body over the 500-char cap is rejected with 400', async ({ guest }) => {
const g = await guest('LongComment');
const uploadId = await seedUpload(g.jwt);
const res = await postComment(g.jwt, uploadId, 'A'.repeat(501));
expect(res.status, '501 chars must be rejected by the length cap').toBe(400);
const json: any = await res.json().catch(() => ({}));
expect((json.message ?? '').toLowerCase()).toMatch(/500 zeichen/);
});
test('comment body exactly at the 500-char cap is accepted', async ({ guest }) => {
const g = await guest('MaxComment');
const uploadId = await seedUpload(g.jwt);
// The boundary must be inclusive — otherwise the "cap" is really 499 and the
// rejection test above would also pass on an off-by-one implementation.
const res = await postComment(g.jwt, uploadId, 'A'.repeat(500));
expect(res.status, '500 chars is the documented maximum and must be accepted').toBe(201);
});
test('10 MB comment body never reaches the handler (body-size limit rejects it)', async ({
guest,
}) => {
const g = await guest('BigComment');
const uploadId = await seedUpload(g.jwt);
const huge = 'A'.repeat(10 * 1024 * 1024);
const res = await postComment(g.jwt, uploadId, huge);
// This asserts ONLY what it can prove: a 10 MB JSON body is refused somewhere on the
// path (Caddy's request-body limit → 502/413, or the backend's own body limit → 413,
// or the 500-char cap if it does get through → 400). The upload exists, so a 404 here
// would be a bug, and a 201 would mean we stored a 10 MB comment.
expect([400, 413, 502]).toContain(res.status);
});
test('SSE: 10 concurrent streams from one user do not crash the server', async ({ guest }) => {
const g = await guest('SseFlood');
// The stream endpoint authenticates via single-use tickets (POST /stream/ticket),
// not the raw JWT — a `?token=` open is rejected with 400. Mint one ticket per stream.
// (These streams must be held open concurrently, so we can't use the openStream
// helper which opens-and-aborts a single stream.)
const tickets = await Promise.all(Array.from({ length: 10 }, () => mintSseTicket(g.jwt)));
const controllers = tickets.map(() => new AbortController());
const requests = tickets.map((ticket, i) =>
fetch(`${BASE}/api/v1/stream?ticket=${encodeURIComponent(ticket)}`, {
signal: controllers[i].signal,
})
);
const responses = await Promise.all(requests);
// One session may hold only MAX_TICKETS_PER_SESSION (4) live tickets — enough for a guest with
// a couple of tabs open, deliberately not enough for a reconnect loop to accumulate. Minting a
// 5th evicts the oldest, so most of these ten tickets are already dead when their stream opens
// and the server answers 401. That IS the cap working; this used to allow only [200, 429] and
// so failed on the very defence it was written to exercise.
//
// What must hold is that the server sheds the flood deliberately rather than falling over: no
// 5xx, and the surviving tickets still get their stream.
const statuses = responses.map((r) => r.status);
for (const s of statuses) {
expect([200, 401, 429], `unexpected status from the stream flood: ${statuses}`).toContain(s);
}
// EXACTLY four, not merely "at least one". The cap is a known constant, so asserting a
// bound this loose would still pass if it were tightened to 1 (a guest with two tabs loses
// their live feed) or if eviction kept the OLDEST ticket instead of the newest (every
// reconnect throws away the ticket it just minted — a permanently dead feed for that guest).
expect(
statuses.filter((s) => s === 200).length,
`exactly MAX_TICKETS_PER_SESSION streams should survive, got: ${statuses}`
).toBe(4);
// Tear them all down so the next test doesn't see leaked connections.
controllers.forEach((c) => c.abort());
// Sanity: a new request still works.
const ping = await fetch(`${BASE}/api/v1/me/context`, {
headers: { Authorization: `Bearer ${g.jwt}` },
});
expect(ping.status).toBe(200);
});
test('malformed JSON in /join is rejected with 400, not 500', async () => {
const res = await fetch(`${BASE}/api/v1/join`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: '{"display_name":',
});
expect([400, 422]).toContain(res.status);
expect(res.status).not.toBe(500);
});
});