Intro to Cybersecurity · How hackers think and act · Day 2 of 4

Admin Bypass and Simple Web Challenges

Why weak logins and lazy access checks are so dangerous, and why the only check that counts is the one on the server. Then you take on beginner web challenges on AquilaCyber.

Yesterday you noticed a site that trusted a number in a link. Today you meet the family of bugs that number belongs to. It is the single most common serious weakness on the web, and once you can see it, you see it everywhere.

Its proper name is broken access control: the system lets people do things they should not be allowed to do. We will keep everything on AquilaCyber, where the systems exist to be broken for practice.

1. Client Side and Server Side

Definition

A web app runs in two places at once, and you must always know which one you are looking at.

• The client side is your browser. You can see all of it and change all of it. It is the shop window.
• The server side is the company’s computer. You never see it and cannot change it. It is the stockroom and the till.

Here is the rule the whole day rests on: anything your browser can do, you can change. The menus, the hidden fields, the disabled buttons, the "you are not an admin" message. All of it is a copy sitting in your browser, and a copy can be edited.

Real-Life Scenario

A cinema prints "STAFF ONLY" on a door but never locks it. The sign is a client-side check: it depends on you choosing to obey. A locked door is a server-side check: it does not care what you choose. Security that depends on you choosing to behave is not security.

2. A Hidden Button Is Not a Locked Door

Imagine a page that shows an admin button only to admins, like this.

A button the page hides from normal users

1
2

<!-- the page quietly carries this for everyone -->
<button hidden data-role="delete-user">Delete user</button>

The button was sent to every visitor. "hidden" only stops it being drawn, not from existing.

The button is not absent for a normal user. It was downloaded to everyone and simply not shown. If the server deletes a user the moment it receives the delete request, without checking "is the person sending this actually an admin?", then whether the button was visible never mattered. The system guarded the view instead of guarding the action.

3. What "Admin Bypass" Means

Definition

An admin bypass is reaching an admin-only area or action without being an admin. It almost never means guessing the admin’s password. It usually means the system asked "who are you?" and then forgot to ask "are you allowed to do this?"

How It Happens

Picture a site that decides you are an admin based on something your own browser tells it, such as a stored value that simply says your role.

A trust decision made from data the user controls

1
2
3

role = user        <-  what the browser sends
if role == "admin":  open the admin page
else:                show "access denied"

The server believes a value the visitor can change. That misplaced trust is the whole bug.

The lesson is not a recipe. It is a principle: never decide what someone is allowed to do based on something they are able to change. The role, the price, the student number, the "is this an admin" flag: if it reaches the server from the browser, the server must treat it as a claim to be checked, not a fact to be trusted.

4. How the Builder Should Have Done It

Because this is a course about thinking clearly, here is the safe version. The server decides, using what the server knows, after checking the real session.

The same feature, checked where it counts

1
2
3
4
5

# on the server, where the user cannot reach
user = load_user_from_session()      # not from the browser's claim
if not user.is_admin:                 # the check that actually matters
    return "access denied"
delete_user(target)                   # only an admin ever gets here

The decision uses the trusted session, and it happens before the action, every time.

Notice there is no clever trick in the fix. Good security is usually boring: ask the right question, in the right place, every single time.

Practise

1. Which side?. For each, say client side or server side: the price shown on a product page; the price the server charges your card; a greyed-out "Delete" button; the database row that actually gets deleted.
2. Name the bug. A site hides the "Edit everyone’s profile" link from normal users but still edits any profile it is asked to. What is this weakness called?
3. Fix it in words. Rewrite this rule so it is safe: "if the role the browser sends is admin, allow the delete."
4. Climb. Solve Day 2: Admin Area and at least two more web challenges on AquilaCyber, and note your leaderboard rank before and after.

Checkpoint

Next: Day 3. We leave the web app and turn to people. OSINT is finding out who really sent a message using nothing but public information, and it starts with "who sent this?"