Chapter 3 — Operating systems and identities
Lesson map
Lesson 03 published. Map, example, EX009.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Accounts on the server"]
N2["3.2 File permissions"]
N3["3.3 Staff identities"]
N4["3.4 Customer identities"]
N5["3.5 Checking permissions"]
N6["3.6 Records"]
N7["Removing old accounts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX009"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Accounts on the server"]
N2["3.2 File permissions"]
N3["3.3 Staff identities"]
N4["3.4 Customer identities"]
N5["3.5 Checking permissions"]
N6["3.6 Records"]
N7["Removing old accounts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX009"]
[Learning outcomes]
|
v
[3.1 Accounts on the server]
|
v
[3.2 File permissions]
|
v
[3.3 Staff identities]
|
v
[3.4 Customer identities]
|
v
[3.5 Checking permissions]
|
v
[3.6 Records]
|
v
[Removing old accounts]
|
v
[Worked example] --> [Exercise EX009]
Learning outcomes
You will (1) describe user accounts and file permissions on a web server; (2) apply least privilege to sites and staff; (3) manage support access safely; (4) recognise risky permission settings.
3.1 Accounts on the server
Each customer site runs under its own operating system user, so one site cannot read another's files. The web server process can read site files and write only to upload and cache folders. Separate users mean the Ferncroft problem stayed inside Ferncroft's site rather than spreading to other customers on the same server. The web server's write access is limited to uploads and cache, so normal visitors cannot change code. When that limit is broken, as it was at Ferncroft, the protection weakens.
3.2 File permissions
Plugin and application code should not be writable by the web server process. If it is, a flaw in any plugin could let changed code be written into the site, which is one way unexpected redirects appear. At Ferncroft, the plugin folder was writable by the web server, a leftover from the mirror installation. That setting did not cause the redirect by itself, since the mirror copy already carried it. It did mean that any plugin flaw could have let further changes be written to the site.
3.3 Staff identities
Support technicians sign in with personal accounts and multi-factor authentication. They have temporary access to a customer site only while a ticket is open, granted by the ticket system and removed when it closes. Tying access to an open ticket means Tomás could work on Ferncroft's site only while the redirect ticket was open. When the ticket closed, the access ended without anyone having to remember to remove it. The session log then shows exactly who worked on the site and when.
3.4 Customer identities
Customers manage their own shop administrators. Pinecrest advises unique accounts for each staff member and removing accounts when staff leave. OWASP Top 10:2021 A07 covers authentication failures. Shared administrator accounts make it impossible to tell who did what. At Ferncroft, Tomás found two administrator accounts belonging to former shop staff, which were removed with the customer's agreement. Pinecrest cannot know who has left a customer's business, so the yearly reminder asks customers to check their own lists. OWASP A07 lists weak and shared credentials among authentication failures, which matches what Pinecrest asks customers to avoid.
3.5 Checking permissions
A support script lists files writable by the web server outside the permitted folders. The script reads permissions and prints a list; it changes nothing. On Ferncroft's site it found the plugin folder writable by the web server. Running it weekly through the nightly job later turns a one-off discovery into a routine check that catches the same mistake on other sites before it causes harm. The permitted folders, uploads and cache, are listed in the script itself so reviewers can check them.
3.6 Records
Every support session is logged with the technician, ticket and time. Each log entry names the technician, the ticket and the time, so any change on a customer site can be traced to a person and a reason. For Ferncroft, the logs would show which technician installed the resize plugin and when, which mattered when the cause of the redirects was being reconstructed. Grace samples these logs during her monthly reviews to confirm that each session matched an open ticket.
Removing old accounts
Tomás also lists shop administrator accounts on Ferncroft's site and finds two belonging to former shop staff. With the customer's agreement, they are removed. Grace adds a yearly reminder to customers to review their own administrator lists, since Pinecrest cannot know who has left a customer's business.
Worked example
Running the permission check on Ferncroft's site shows the plugin folder writable by the web server, a leftover from the mirror installation. Tomás reports it; the security team restores correct permissions after taking a copy for investigation.
Synthetic case. Accounts and findings are synthetic.
Errors and limits
Correct permissions limit damage but do not fix a flawed plugin.
Exercises
- EX009 — Site isolation. How are customer sites kept apart? Rubric: 3 = own OS user each; 2 = partial; 1 = vague; 0 = none.
- EX010 — Writable code. Why should code not be writable by the web server? Rubric: 3 = a flaw could write changed code; 2 = partial; 1 = vague; 0 = none.
- EX011 — Support access. How is support access limited? Rubric: 3 = temporary, per open ticket; 2 = partial; 1 = vague; 0 = none.
- EX012 — Ferncroft permission. What permission problem was found? Rubric: 3 = plugin folder writable by web server; 2 = partial; 1 = vague; 0 = none.
Synthesis
Least privilege for sites and staff limits harm.
Continue studying — chapter 03 of 18
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →