10.6 Web APIs, Server Extensions & Client-Side Sub-Components

10.6 Web APIs, Server Extensions & Client-Side Sub-Components

Two syllabus items complete the web-technologies picture. G8 (Web APIs) covers the application interfaces that extend a web server: CGI, ISAPI filters and Apache modules. G9 (Web Sub-Components) covers the pieces of an application that run on the client: thin/thick web clients, servlets and applets, ActiveX, Flash application testing, .NET thick clients, Java applets, and de-compilation of client-side code. Together they describe how a web application is actually built on both sides of the connection, and where each construction technique introduces risk.

---

1. Server Extension Interfaces (G8)

A bare web server only serves files. To run application logic it must be extended, and there are two architectural models with very different security properties.

CGI — External Process per Request

CGI (Common Gateway Interface) is the original mechanism. For each request the web server spawns a separate external program (a Perl, Python, C or shell script in a cgi-bin directory), passes the request data through environment variables and standard input, and returns the program's standard output.

• Isolation: because each request is a separate process, a crash affects only that request.
• Cost: spawning a process per request is slow, which is why CGI gave way to in-process models and FastCGI.
• Risk: CGI programs are a classic injection surface. User input arrives in environment variables and is often passed to a shell — the exact path Shellshock (CVE-2014-6271) exploited, because a CGI invocation of Bash exposed the environment-variable parsing flaw to the internet. Command injection (11.4) and path traversal in CGI scripts are staple findings.

ISAPI and Apache Modules — In-Process Extensions

The performance answer is to run the extension inside the web server process:

• ISAPI (Internet Server API) on Microsoft IIS: ISAPI extensions implement application functionality (classic ASP and ASP.NET are hosted this way) and ISAPI filters intercept and modify every request/response passing through IIS (used for URL rewriting, authentication, logging).
• Apache modules (mod_php, mod_perl, mod_security, mod_rewrite) are shared objects loaded into the Apache process at start-up, hooking into the request-processing pipeline.

The crucial security consequence: an in-process extension runs with the web server's privileges and shares its address space. A memory-corruption flaw in an ISAPI filter or an Apache module is a flaw in the web server itself — historically the source of some of the most serious IIS and Apache vulnerabilities (the IIS ISAPI .printer and .ida/Code Red overflows being the archetype). A filter that sees every request is also a single point through which all traffic — including credentials — passes, so its correctness is security-critical.

For an assessor, identifying the extension model narrows the attack surface: file extensions and headers reveal whether you are facing CGI scripts, an ISAPI-hosted .NET app, or Apache with specific modules, and each has its own vulnerability history to check against the observed version.

---

2. Thin vs Thick Web Clients (G9)

The syllabus draws the thin/thick distinction because it changes what the assessor can and must inspect.

The golden rule from section 10.2 applies with full force: anything on the client is attacker-controlled. For a thick client that means the code, the traffic, and any embedded secret are all recoverable.

---

3. Client-Side Component Technologies

• Servlets and JSP — Java server-side components; strictly they run on the server, but they are paired with client-side applets in legacy Java web apps.
• Java Applets — Java bytecode downloaded and run in the browser's JVM. Deprecated and removed from modern browsers, but still present on legacy enterprise and appliance management interfaces.
• ActiveX Controls — Windows COM components downloaded and run by (legacy) Internet Explorer with substantial local privileges; a notorious historical attack surface because a signed control could do almost anything on the host.
• Adobe Flash — end-of-life since 2020 but still found internally; Flash .swf files contain ActionScript logic and were a major vulnerability source, and the syllabus explicitly names Flash Application Testing.
• .NET Thick Clients — desktop applications (WinForms/WPF, ClickOnce) that call web services or databases directly. Their assemblies are distributed to the client.
• Silverlight / applets / browser plug-ins generally — the same class of downloadable executable client code.

---

4. Decompilation of Client-Side Code

The syllabus lists "De-compilation of client-side code" as an explicit skill, because compiled client components are only superficially opaque.

• Java (.class, .jar, applets) compiles to bytecode, which decompiles almost perfectly back to source with JD-GUI, Procyon, CFR or Fernflower. Method names, string constants and logic all return.
• .NET (C#/VB assemblies, .exe/.dll) compiles to CIL/MSIL, which dnSpy, ILSpy or dotPeek decompile back to near-original C#. dnSpy can even edit and re-run the assembly.
• Flash .swf files decompile to ActionScript with JPEXS Free Flash Decompiler.
• JavaScript, though not compiled, is frequently minified or obfuscated; beautifiers and source maps recover readable logic, and bundled SPAs often ship source maps by accident.
• ActiveX/native controls require disassembly (Ghidra, IDA), which is harder but still tractable.

What Decompilation Recovers — and Why It Matters

 Compiled/obfuscated client component
        |  decompile / beautify
        v
 - Hardcoded credentials, API keys, connection strings
 - Internal and undocumented API endpoint URLs
 - Encryption keys and the algorithm used ("security by obscurity")
 - Business logic and validation rules (which the client can then ignore)
 - Comments and debug strings revealing internal detail

This is the concrete demonstration of the golden rule. Developers repeatedly embed an API key, a database connection string, or a "licence check" in a thick client believing the compiled form hides it. It does not: a few minutes with dnSpy or JD-GUI returns the source, the secret, and the endpoint it authenticates to. Any secret shipped to the client is compromised, and any security check performed only on the client can be bypassed simply by calling the server directly (see 10.5) or by patching the decompiled client.

---

5. Assessment Approach

1. Identify the server extension model from extensions, headers and error pages (CGI scripts, ISAPI/.NET, Apache modules) and check the identified components against their vulnerability history.
2. Classify the client as thin or thick. For a thin client, concentrate on server-side testing; for a thick client, treat the client as in-scope code.
3. Retrieve and decompile every client component — applets, ActiveX, Flash, .NET assemblies, JS bundles — and read them for secrets, endpoints and logic.
4. Extract endpoints and secrets found in client code and test them directly, because server-side controls are frequently weaker than the client implies.
5. Bypass client-side controls by calling the discovered endpoints without the client, proving that validation must be re-implemented server-side.
6. Report the specific artefact: the file decompiled, the secret or endpoint recovered, and the server-side action it enabled — that evidence is what makes "client-side controls are insufficient" actionable.