fix: resolve all six CodeQL security alerts

[houko]

Fixes all six CodeQL alerts. They are all in pre-existing code — CodeQL had never run on this repository until #43, so this is the first time anyone has seen them.

Alert	Severity	Location
TrustManager that accepts all certificates	high	core/.../HttpUtil.java
Unsafe hostname verification	medium	core/.../HttpUtil.java
Failure to use secure cookies	medium	core/.../HttpUtil.java
Uncontrolled data used in path expression	high	core/.../FileUtil.java
Insecure randomness ×2	high	website/.../UserModel.java, AdminModel.java

TLS validation was switched off entirely

MyX509TrustManager had an empty checkServerTrusted and returned null from getAcceptedIssuers. TrustAnyHostnameVerifier.verify returned true unconditionally. Together they disable certificate-chain and hostname validation on every HTTPS request this utility makes — any machine on the path can decrypt and rewrite the traffic.

Both classes are removed, and initHttps no longer overrides SSLSocketFactory or HostnameVerifier. The JDK default validates properly.

This is a behaviour change. Any server this code talks to that presents a self-signed or expired certificate will now fail to connect. That is the bug becoming visible rather than a new bug: the fix is to add the certificate to the trust store, not to turn validation off.

Cookies lacked the secure flag

setCookie set httpOnly but not secure, so the cookie was sent over plaintext HTTP. Added setSecure(true) and SameSite=Lax. Worth knowing when testing locally: browsers will not return a secure cookie over plain HTTP.

Path injection in FileUtil

getNewFileName builds a filename from the email local-part and the file extension, both user-supplied. Taking "everything after the last dot" as the extension means an upload named a.b/../../evil contributes b/../../evil to the path. The result was concatenated straight into a FileOutputStream path.

Both components are now filtered to [A-Za-z0-9_-], and the write resolves through normalize() then startsWith(root) against a dedicated upload directory — the same canonical guard used in the fileupload module, which CodeQL recognises.

While in there: savePath was initialised to "" and never assigned a directory, so uploads landed in the process working directory. Now they go to upload/.

Insecure randomness

The two alerts point at @Data on UserModel and AdminModel, which is CodeQL following the taint into Lombok-generated setters. The actual source is RandomUtil: getTonken, randomPwd and createSalt all called RandomStringUtils.random(), which is backed by java.util.Random — a 48-bit seed and a published algorithm, so observing a handful of outputs is enough to predict the rest. These values are used as password salts and cache tokens, where predictability defeats the purpose.

Switched to RandomStringUtils.secure(), which is SecureRandom-backed (available since commons-lang3 3.16; this project is on 3.20).

RandomUtil.random(min, max), randomElement and isGenerate are left on ThreadLocalRandom. They pick demo data, not secrets, and CodeQL does not flag them.

Verification

New SecurityHardeningTest covers the parts that can be asserted directly — traversal fragments stripped from both filename components, secure and httpOnly both set on the cookie, salts of the right length with no collisions across 500 draws, and tokens that are all digits.

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 -- info.xiaomo.core.utils.SecurityHardeningTest
[INFO] BUILD SUCCESS

Full build passes across all 21 modules with the existing 24 tests still green.