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

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

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

Key Takeaways Explain This Topic AI

CGI runs an external program per request; ISAPI filters/extensions (IIS) and Apache modules run inside the web server process for performance.

A server extension running in-process shares the web server's privileges, so a flaw in it compromises the whole server.

Thin clients render server-generated content; thick clients execute significant logic locally and must be treated as attacker-controlled.

Java applets, ActiveX controls, Flash and .NET thick clients can be downloaded and decompiled to recover logic, endpoints and hardcoded secrets.

Any security control or secret placed in client-side code is recoverable and therefore not a control at all.

Last updated: September 2026

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.

Thin client Thick (rich) client

Where logic runs Almost entirely on the server; the browser renders HTML Significant logic executes on the client (rich JS SPA, Java applet, .NET WinForms/WPF talking to an API, ActiveX control)

What the client holds Presentation only Business logic, endpoint URLs, sometimes secrets

Assessment implication Focus on server-side flaws The client itself is attacker-controlled and must be reverse-engineered

Trust boundary At the browser The client is outside the trust boundary entirely

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

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.

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.

Retrieve and decompile every client component — applets, ActiveX, Flash, .NET assemblies, JS bundles — and read them for secrets, endpoints and logic.

Extract endpoints and secrets found in client code and test them directly, because server-side controls are frequently weaker than the client implies.

Bypass client-side controls by calling the discovered endpoints without the client, proving that validation must be re-implemented server-side.

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.