Free Hosting, Weak Passwords and a Payment Link
A school has uploaded its new site to a free shared-hosting account using FTP. The site is at http://school.example.org, and the contact form posts to a PHP script that emails the principal's Gmail address. The hosting control panel shows directory listing is enabled, the account password is 'school2019', and the public_html folder permissions are 777 because the previous student could not upload otherwise. The admin page admin.php is protected by a JavaScript prompt that compares the entered password with 'admin123' in the page source. A parent reports that the site shows a browser warning, and a teacher notices that the site is sometimes replaced by an advertisement page. The school also wants to add an online fee payment link. The annual function is next week, and the hosting provider offers a free Let's Encrypt certificate and SFTP, but no support for custom PHP versions.
1. Rank the security problems by risk and explain the likely causes of the browser warning and the advertisement replacement.
Read the worked answer
Rank by likelihood and impact: first, the hosting account is probably already compromised, because the advertisement replacement suggests modified files, a malicious .htaccess, or a vulnerable PHP script; second, 777 permissions and directory listing make defacement and discovery of backups or config files easy; third, the FTP password is weak and FTP is unencrypted, so credentials can be sniffed; fourth, the admin password is in the page source, so anyone can read it; fifth, plain HTTP explains the browser warning, not malware. The browser warning appears because the site is served over HTTP and the form collects data; it is not proof of a hack. The advertisement replacement is the stronger signal: check file modification times, index.php, .htaccess, scheduled tasks and access logs, then restore from a known-clean backup, change all passwords and enable SFTP. Do not just delete the advertisement; find the entry point.
2. What concrete changes should be made before adding an online payment link?
Read the worked answer
Before adding payments, move to HTTPS with the free Let's Encrypt certificate, redirect HTTP to HTTPS with a 301, and fix mixed content. Use a reputable hosted payment gateway, such as Razorpay or PayU, so card data never touches the school server; the server should create the order, verify the gateway signature, and mark payment success only after server-side verification. Never put secret keys or trusted amounts in client-side JavaScript. Add CSRF protection, validate the amount and student ID server-side, use secure, HttpOnly, SameSite cookies, and log transactions. Use a proper domain and a host that supports a current PHP version and security updates; a free shared host may not meet payment-provider requirements. Keep backups and monitor. If the school cannot meet these controls, use a payment link from the gateway rather than building a custom form.
3. Explain how file permissions and directory listing relate to the defacement, and give the correct settings.
Read the worked answer
777 means world-writable: any user or compromised process on the shared server can modify or replace the site files, which is a direct route to defacement. Correct settings are normally directories 755 and files 644, with ownership by the hosting account; upload directories should not be executable. Disable directory listing with Options -Indexes in .htaccess or the panel setting, because listing exposes admin.php, old backups and configuration files to anyone who guesses a folder. Move credentials and backups outside public_html, deny access to .git, .env and *.sql files, and remove unused scripts. Use SFTP instead of FTP, change the weak password, and check permissions after every upload because some FTP clients reset them. Explain that permissions are not a substitute for fixing the compromised account; they reduce the blast radius.