Home / Knowledge hub / Server-side includes injection
Knowledge hub
Server-side includes injection
Input that gets processed as a server-side include directive.
What it means
Server-side includes, or SSI, are directives placed in a web page that the web server itself runs before sending the page. They can insert another file, show a variable or, on some setups, run a command. SSI injection is when user input ends up inside a page the server processes this way.
If your input is written into such a page and the server treats it as a directive, the visitor is no longer supplying text. They are giving the server instructions. It belongs to the same family as other injection flaws: data that is read as code.
Why it matters
Depending on configuration, an injected directive can print environment details, read files the web server can reach or run commands. The last of these amounts to remote code execution, which is among the most serious outcomes a web flaw can have.
It is easy to overlook because SSI feels old. It still turns up on legacy sites, embedded devices and servers where the feature was left on by default. An old marketing page that nobody owns can be the weak point.
How it shows up
You meet it on Apache or nginx setups where SSI is enabled and pages with the .shtml extension or similar are processed. Typical entry points are feedback forms, guest books, error pages that echo input, and search results written into a file that the server later parses.
The simplest defence is to turn SSI off if you do not use it. If you do, disable the command-running directive, and never write user input into a file the server will process. Apply output encoding to anything shown back. A scan of configuration and a test with directive-shaped input will show whether it is live.
Questions people ask
Server-side includes injection, answered
Is SSI injection still a real risk?
Yes, where the feature is enabled. It is rare on modern frameworks but common on older sites and appliances, where nobody has reviewed the web server configuration in years.
How is it different from cross-site scripting?
Cross-site scripting runs script in the visitor's browser. SSI injection runs directives on the server itself, so the impact reaches your files and system rather than one visitor.
Both come from input being treated as instructions.
Can it run commands on my server?
It can, if the exec directive is allowed. Many servers allow include and variable directives but block exec, which limits the damage. Check your configuration instead of assuming.
How do we know whether SSI is switched on?
Look at the web server settings for the include feature, and at which file types it processes. You can also test by submitting a harmless directive that prints a date and seeing whether it comes back evaluated.
How do we prevent it?
Turn the feature off where it is not needed, block the command directive where it is, and do not place user input in files the server parses. Encode output so directive syntax is shown as text.
Keep input validation strict on top.
Related
Terms that sit next to this one
Injection
Input that ends up running as a command instead of being read as text.
Remote code execution
Getting a server to run commands of an attacker's choosing.
Output encoding
Escaping data for its destination so it is shown as text, not run as code.
Server-side template injection
User input evaluated by your template engine, often leading to code execution.
Command injection
Input that ends up run as an operating system command on your server.
Is old server config still live?
Old features are tested like any other. We try directive-shaped input against the running app and report only what the server actually evaluated, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.