Thinking server-side

The bugs in this path look varied, reading files, fetching URLs, running commands, parsing XML, but they share one instinct, and holding that instinct is what lets you spot them. The instinct is: notice every place the server does something with your input other than store or display it.

The question that finds server-side bugs#

In the access path you asked "am I allowed this?" In injection you asked "does my input stay data?" Here the question is: "what does the server do with this value?"

Whenever an application takes something you supply and, on the server, uses it to act, open a file, request a URL, run a program, expand a piece of data, there is a chance you can steer that action somewhere it was not meant to go. The feature looks innocent because the action is a normal part of the app: a report generator opens a file, an avatar importer fetches a URL, a document converter runs a tool, an import parses XML. The bug is getting that same machinery to act on your target instead of the intended one.

The four verbs, and their bugs#

Sort every server-side finding by what the server is doing:

• Reads a file. A parameter names a file to open, include, or serve. Steer it to a file outside the intended folder and you read source code, config, secrets. That is path traversal and file inclusion (lesson 2).
• Runs a program. A value reaches a shell command, or a file you uploaded is executed, or your input is evaluated by a template engine. You run code on the server. That is command injection, upload-to-RCE, and template injection (lessons 3, 4, 7).
• Fetches a URL. A value tells the server what to request, a webhook, a link preview, an import-from-URL. Point it inward and the server reaches internal services and cloud metadata for you. That is SSRF (lesson 5).
• Parses your data. The server deserialises an object or parses XML you supplied, and the parser can be told to read files or build hostile objects. That is XXE and insecure deserialization (lessons 6, 8).

Learn the four verbs and you have a checklist for any feature: does this read, run, fetch, or parse something based on what I send?

Why the impact is so high#

Client-side bugs (XSS) run in a user's browser. Server-side bugs run on the server, the machine that holds every user's data, the source code, the credentials, and the keys to the rest of the infrastructure. So the outcomes are the biggest in web testing:

• Remote code execution (RCE): you run commands on the server. Effectively total control of that machine.
• Local file read: you read source code, configuration, /etc/passwd, private keys, .env files full of secrets.
• Internal network access: via SSRF you reach services that were never exposed to the internet, and cloud credential endpoints.

Because the stakes are this high, these are also the findings that pay the most on bounty programs and carry the most weight on an exam.

Finding the surface#

Server-side sinks hide in the "boring" features, so hunt them deliberately, using your recon:

• File parameters: anything named file, path, template, page, doc, download, include, lang.
• URL parameters: url, uri, webhook, callback, dest, feed, image, import, proxy, and any "fetch from URL" feature.
• Upload features: avatars, attachments, imports, document processors.
• Anything that runs a tool: a "ping this host" utility, a PDF/thumbnail/format converter, a backup or export function.
• Anything that parses structured data: XML/SOAP endpoints, file imports (.xml, .docx, .svg, .gpx), serialized cookies and tokens.

For each, ask which of the four verbs it performs, then test with the technique for that verb.

The honesty gate, and why it is strictest here#

These bugs can break the target: a command injection can delete data, an upload can leave a live web shell, an SSRF can hammer internal systems. So the rules are firm and non-negotiable on real targets:

• Authorised targets only. Command execution against something you were not asked to test is a serious offence, full stop.
• Prove with the gentlest payload. Run id or whoami, read one harmless file, make one benign internal request, enough to demonstrate the flaw, never a destructive command.
• Clean up. If you upload a proof web shell, remove it. Do not leave a foothold behind.

On this Academy's labs the environments are disposable and isolated, so you can go all the way to code execution safely, which is exactly why they exist.

Where this goes next#

Start with the simplest verb, reads a file. The next lesson is path traversal and file inclusion: using ../ to walk out of the folder the developer intended and read whatever the server's user can read.