diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 42 |
1 files changed, 42 insertions, 0 deletions
@@ -92,6 +92,48 @@ The autoloader in `bootstrap.php` uses `spl_autoload_register` to automatically 4. `Router::dispatch()` matches the URL against registered patterns and calls the matching controller method 5. The controller fetches data via models and renders a view inside the layout +## Security concepts + +### CSRF (Cross-Site Request Forgery) + +Imagine you're logged into Camagru. A malicious website could contain a hidden form that submits a request to `camagru.local/delete-account` — and your browser would automatically send your session cookie along with it, so the server thinks *you* made that request. This is a CSRF attack: the attacker forges a request that rides on your existing session. + +**How tokens prevent it:** every form on Camagru includes a hidden field with a random token that was generated server-side and stored in the user's session. When the form is submitted, the server checks that the token in the request matches the one in the session. The attacker's malicious site can't know this token (it's unique per session and never exposed in a URL), so their forged request will be rejected. + +In the code, `App\Csrf` handles this: +- `Csrf::generate()` creates a random token (via `random_bytes()`) and stores it in `$_SESSION` +- `Csrf::field()` outputs a hidden `<input>` to embed in forms +- `Csrf::validate()` checks the submitted token against the session using `hash_equals()` — a constant-time comparison that prevents timing attacks (where an attacker measures response times to guess the token character by character) + +### Password hashing + +Passwords are never stored in plain text. PHP's `password_hash()` uses bcrypt by default, which: +1. Generates a random **salt** (so two users with the same password get different hashes) +2. Runs the password through a deliberately slow hashing algorithm (to make brute-force attacks impractical) +3. Produces a string that embeds the algorithm, cost factor, salt, and hash — so `password_verify()` can check a password without needing to know the salt separately + +### Prepared statements + +SQL injection happens when user input is concatenated directly into a query: `"SELECT * FROM users WHERE name = '$name'"` — if `$name` is `' OR 1=1 --`, the attacker gets all users. Prepared statements separate the query structure from the data: the database compiles the query first, then plugs in the values, so user input can never be interpreted as SQL. PDO's `prepare()` + `execute()` handle this. + +### XSS (Cross-Site Scripting) + +If user-generated content (usernames, comments) is rendered directly into HTML, an attacker could inject `<script>alert('hacked')</script>` and it would execute in other users' browsers. `htmlspecialchars()` escapes characters like `<`, `>`, `&`, `"` into their HTML entities (`<`, `>`, etc.) so the browser displays them as text instead of interpreting them as code. Every piece of user data rendered in a view must be escaped this way. + +### Sessions + +HTTP is stateless — the server doesn't inherently know that two requests come from the same person. PHP sessions solve this: `session_start()` generates a unique session ID, stores it in a cookie on the client, and creates a server-side data store (`$_SESSION`) keyed by that ID. On every request, the browser sends the cookie, PHP looks up the matching session data, and the server knows who you are. This is how login state, CSRF tokens, and flash messages persist across page loads. + +### Session fixation + +A session fixation attack works like this: the attacker visits the site and gets a session ID (say `abc123`). They then trick the victim into using that same session ID — for example by sending a link like `http://camagru.local/?PHPSESSID=abc123`. If the victim clicks the link, logs in, and the server keeps using `abc123`, the attacker now has a valid logged-in session because they already know the ID. + +`session_regenerate_id(true)` prevents this by generating a brand-new session ID the moment a user logs in. The old ID (`abc123`) is destroyed and becomes useless. Even if the attacker planted it, they can't use it after the victim authenticates — the real session now lives under a new, unknown ID. + +### User enumeration + +When a login fails, our error message says "Invalid username or password" rather than "Username not found" or "Wrong password". Similarly, the forgot-password form always says "If that email is registered, a reset link has been sent." This is deliberate: if the server told you *which* part was wrong, an attacker could probe the system to build a list of valid usernames or emails, then target those accounts specifically with brute-force or phishing attacks. + ## Image format choices - **Overlays** are PNG (alpha channel required for transparency) |