Security: Restrict direct attachment access and upload file types

[anonymoususer72041]

Summary

This pull request strengthens the security of attachment handling in two ways.

First, it hardens the attachments/ directory by denying all direct HTTP access via .htaccess, ensuring that attachments can only be served through the application layer (AttachmentsUI) where authentication and authorization checks already exist.

Second, it introduces a server-side whitelist of allowed file extensions in AttachmentCreator::createFromUpload(), so only a predefined set of document and image formats can be uploaded.

Among other things this removes html from the allowed types, reducing the risk of serving active content while still supporting common recruitment-related file formats.

Motivation

Securing access to stored attachments

Before this change, files stored under attachments/ were effectively accessible by direct URL for specific extensions, which meant that knowledge of the path alone was sufficient to download them without going through OpenCATS authentication.

While the paths are not trivial to guess, this does not align with the principle of defense in depth. By denying all direct HTTP access to attachments/ and relying exclusively on AttachmentsUI::getAttachment() for downloads, we ensure that attachment access always goes through the existing authentication and authorization checks, and we decouple security from any URL obfuscation details.

Restricting allowed upload types

Previously there was no server-side restriction on which file types could be uploaded. Any extension that passed the basic size and upload error checks was accepted. This increased the risk of storing and potentially serving file types that are unnecessary for typical recruiting workflows and could introduce security issues, especially when rendered inline by the browser. Introducing a server-side whitelist based on common document and image formats narrows the attack surface and prevents the upload of unexpected or potentially dangerous file types.

Removing html from the allowed types explicitly addresses the risk of stored cross-site scripting (XSS), where uploaded HTML could be served inline and executed under the same origin as OpenCATS, allowing untrusted scripts to run in the user's session.

[anonymoususer72041]

I reverted commit 215e59c since it’s out of scope for this PR and is much more closely tied to the work tracked in issue #682.