amuleweb hardening: address #869 #870 #871 #872 #873 #874 - #875

…le-project#873)

The OnReceive() loop reads up to `m_dwBufSize` bytes into `m_pBuf` and
unconditionally writes a NUL at `m_pBuf[m_dwRecv]` to terminate the
buffer for the request-parsing strstr() calls below. The grow loop is
gated on three conditions:

    while (m_dwRecv == m_dwBufSize && read != 0 && !LastError())

If a Read() exactly fills the buffer AND LastError() is set
immediately afterwards (e.g. peer sent 4096 bytes then reset the
connection), the loop exits without growing -- but m_dwRecv ==
m_dwBufSize, so the terminator write at line 85 lands one byte past
the allocation. Heap corruption, narrow trigger window, reachable
from network input.

Fix is the smallest possible thing: allocate `m_dwBufSize + 1` in
both the constructor's initial allocation and in the grow path's
`new char[newsize + 1]`. The usable-span tracking via m_dwBufSize is
unchanged (still the value passed to Read()), so the loop's
`m_dwBufSize - m_dwRecv` arithmetic stays correct and the terminator
slot at index m_dwBufSize is always within the allocation.

Closes amule-project#873

…roject#869)

amuleweb-main-search.php:184 echoed the user-supplied `sort` query
parameter directly into an `<a href=...?search_sort=$X>` attribute
with no escaping. An attacker who can get a user to click a crafted
URL or load a malicious form action gets reflected XSS in the
authenticated amuleweb session -- which, given that amuleweb is the
remote-control surface for amuled, means session theft + remote
daemon control as the logged-in admin.

This template is the only direct-echo XSS site in the webserver
templates (`grep -r 'echo(\$HTTP_GET_VARS' src/webserver/`); the
rest of the user-supplied surface either lives in C++ where it
goes through `_SpecialChars()` first, or is consumed only by
amuleweb's PHP-side handlers rather than reflected to the browser.

Whitelist `sort` against the three column keys `my_cmp()` actually
understands (line 234-236 of this same file: "size", "name",
"sources"). Anything else falls through to empty -- which produces
the "use the session's last sort" branch that the rest of the
template already handles for missing-param case. Belt-and-braces:
`htmlspecialchars()` the surviving value with `ENT_QUOTES` in case
the whitelist later grows a key that needs HTML escaping.

No PHP linter available locally; verified by reviewing the diff
against `my_cmp()`'s switch arms and confirming the three valid
values exactly match.

Closes amule-project#869

)

CScriptWebServer::CheckLoggedin was generating session IDs with C
`rand()` into an `int`, looping on collision. `rand()` is not a CSPRNG,
isn't seeded with anything an attacker can't observe, and yields at
most RAND_MAX (~2^31) candidate values -- making session IDs guessable
in modest time without ever stealing the cookie. The pattern is the
classic "fake session-cookie until you hit a live one and inherit
that user's authenticated context" attack on an admin surface.

Replace with `CryptoPP::AutoSeededRandomPool::GenerateBlock` into a
`uint64_t`:

- 64 bits of entropy is enough that brute-force is no longer a
  realistic attack at amuleweb scale (web request rate, server CPU
  cost per attempt). Going wider (128-bit opaque hex) would also
  work but pulls in cookie-format and storage-type changes for
  marginal improvement.
- AutoSeededRandomPool is the same primitive the EC stack already
  uses for DH key agreement (see EncryptedStreamSocket.cpp), so this
  doesn't drag in a new crypto dependency.
- Reuse the pool across calls via a function-local static so the
  OS-RNG seeding cost is paid once per process, not once per login.

Type ripple (int -> uint64_t):

- `ThreadData::SessionID` (WebServer.h)
- `std::map<int, CSession> m_sessions` -> `std::map<uint64_t, CSession>`
- `CWebSocket::SendHttpHeaders` signature + Set-Cookie format
  (`%d` -> `%llu` with explicit unsigned-long-long cast for the
  windows builds where uint64_t != unsigned long long)
- `int sessid = 0; ... sessid = atoi(...)` -> `uint64_t sessid = 0;
  ... sessid = strtoull(..., 10)` in WebSocket cookie-parse

Closes amule-project#870

…-project#871)

CWebSocket::SendHttpHeaders emitted the session cookie with no
security attributes whatsoever:

    Set-Cookie: amuleweb_session_id=<NN>

Two consequences with practical attack value:

- Any cross-origin script that gets loaded into a page the user is
  visiting can read `document.cookie` and exfiltrate the session
  token. Combined with the reflected XSS in amule-project#869 (or any future
  one), this is "click a malicious link -> attacker has your
  amuleweb session". `HttpOnly` removes that read path entirely --
  the cookie still rides on requests the browser sends to amuleweb,
  it just stops being visible to JavaScript running in the page.

- The browser attaches this cookie to any cross-site request hitting
  amuleweb. An attacker page that fires a fetch / form-submit to
  `http://localhost:4711/login.php?...` rides on the victim's
  authenticated session. `SameSite=Strict` tells the browser to
  refuse the cookie attachment for cross-site requests, closing
  the CSRF lane.

`Secure` is NOT set. amuleweb has no native TLS and doesn't know
whether it's behind a TLS-terminating proxy; setting it
unconditionally would lock out every direct-HTTP user (the browser
refuses to send the cookie, login becomes impossible). Wiring it to
a preference (e.g. `[WebServer] CookieSecure=1`) is a clean
follow-up but out of scope for this hardening pass.

Layered on top of amule-project#870's `uint64_t` session ID so the cookie format
string is the only thing that changes here.

Closes amule-project#871

…t#872)

amuleweb's login handler reads the password via
`Data.parsedURL.Param("pass")`. The wrinkle is the POST-body merge in
CWebSocket::OnRequestReceived: for `POST` requests the body is
concatenated onto the URL string and then handed to CParsedUrl, which
makes the parsed-URL map agnostic about which params came from the
URL query vs which came from the body (the comment at WebSocket.cpp:
197-208 calls out the deliberate behaviour, and links back to amule-project#724
where the fix was originally introduced).

The side-effect: a `pass` query parameter in the original URL gets
into the parsed-URL map and is accepted as the login password. Two
concrete attacks that uses:

- GET-with-pass click: attacker sends the victim
  `https://amule-host/login.php?pass=XYZ`. Browser sends a GET, the
  URL query is the only source, `pass=XYZ` reaches the login handler.

- POST-with-pass-in-URL form: attacker hosts a page with
  `<form action="https://amule-host/login.php?pass=XYZ" method="POST">`.
  Victim clicks, browser POSTs, the POST body might be empty but
  the URL still carries `?pass=XYZ` -> same outcome.

Passwords in URLs also leak into proxy logs, browser history, and
`Referer` headers, so this isn't only an attacker-controlled-link
problem.

Fix is the Option B from the design discussion: capture the
*pre-merge* URL on the wire and stash it alongside the merged one in
`ThreadData::getOnlyParsedURL`. In the login handler, before reading
`Data.parsedURL.Param("pass")`, check whether `pass` is reachable
from the pre-merge URL -- if it is, refuse to consume it. The merged
map stays the source of truth for every non-credential parameter, so
the amule-project#724 POST-on-query-URL fix isn't disturbed.

Side-effects across the rest of the code:

- `ThreadData` gains a `CParsedUrl getOnlyParsedURL` field; the one
  brace-init call site in WebSocket.cpp:231 grows from 4 fields to
  5. No allocation cost on the hot path: CParsedUrl is just two
  wxStrings + a map<wxString,wxString>, identical to the existing
  parsedURL field.
- For GET requests `getOnlyParsedURL` parses the same string as
  `parsedURL`, so the only `pass` check fires identically in either
  case. For POST requests with `pass` only in the body, the pre-merge
  URL has no `pass` entry and the password is read normally -- the
  intended login flow keeps working.

Closes amule-project#872

Caught while executing PR amule-project#875's test plan on the Ubuntu VM. My
original amule-project#869 fix at 5030691 used three constructs the bundled
amuleweb PHP interpreter doesn't actually support:

- `[...]` short array syntax (the interpreter only accepts
  `array(...)`).
- `in_array(...)` -- not a registered native function. Grep of
  `src/webserver/src/php_core_lib.cpp` shows the entire builtin set
  is `var_dump / strlen / count / isset / usort / split` plus the
  gettext family. Calling an unregistered function path-crashes
  `php_execute` at php_syntree.cpp:1819 on the first request that
  reaches the search template.
- `htmlspecialchars(...)` -- same: not registered, same crash.

Reproduction: log in, render any template -- amuleweb segfaults
inside php_execute. Backtrace points at the search template's
PHP block. Captured in the test session under PR amule-project#875.

Rewrite the whitelist as a plain `==` chain. The three valid sort
keys (`size`, `name`, `sources`) are static alphanumeric column
names; no escaping is needed because non-whitelist values simply
don't get echoed at all -- the only escape-sensitive scenario would
have been a whitelisted value containing HTML-special characters,
which is impossible by construction. Net effect on the XSS surface
is identical: attacker-supplied `sort` payloads never reach the
rendered HTML.

Re-verified after this change: the crash is gone, sort=size /
sort=name / sort=sources all set the correct anchor href, payload
sort values fall through to empty.

Refs amule-project#869 amule-project#875