11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection

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

11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection

Key Takeaways Explain This Topic AI

All injection flaws share one root cause: untrusted input is interpreted as part of a command, query or code rather than treated as data.

LDAP injection manipulates directory filter syntax such as )(uid= ) to bypass authentication or enumerate the directory.

XPath injection abuses XML query syntax with payloads like ' or '1'='1 to bypass logic or extract nodes, and is not mitigated by database controls.

Code and expression-language injection (eval, SpEL, OGNL, template engines) leads directly to remote code execution.

The universal defence is parameterisation or context-aware escaping specific to the target interpreter, plus strict input validation.

Last updated: September 2026

11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection

Section 12.2 and 12.3 cover SQL injection in depth. But syllabus item H10 lists the wider injection family — SQL injection, LDAP injection, code injection and XML injection — and asks for the potential implications of each and how these techniques benefit an attacker. SQL is only the most famous member of a class.

The unifying idea is worth stating once and remembering: an injection flaw exists whenever untrusted input crosses a boundary and is interpreted as part of a command, query or program rather than treated as inert data. Change the interpreter — a SQL engine, an LDAP directory, an XML query processor, a shell, a template engine — and you change the syntax of the attack, but not its nature or its defence.

1. LDAP Injection

LDAP (Lightweight Directory Access Protocol) queries directories such as Active Directory using a distinctive filter syntax built from parentheses and logical operators: (&(objectClass=user)(uid=jsmith)(userPassword=secret))

When an application builds that filter by concatenating user input, an attacker manipulates the filter logic :

Authentication bypass. A login that checks (&(uid=<user>)(userPassword=<pass>)) can be broken by submitting the username *)(uid=*))(|(uid=* or the classic *)(|(uid=*)) , turning the filter into one that always matches. Supplying admin)(&) with any password can authenticate as admin where the password clause is neutralised.

Blind enumeration. By injecting wildcard and boolean conditions and observing whether results are returned, an attacker enumerates attributes character by character — the LDAP analogue of blind SQLi. *)(uid=a*) versus *)(uid=b*) reveals which usernames exist.

The special characters that must be neutralised are ( ) * \ / NUL and the filter operators & | . The implication for the attacker is directory-wide: authentication bypass, disclosure of user attributes (including group memberships and sometimes password-related fields), and a map of the organisation's identity store.

2. XPath / XQuery Injection

XPath queries XML documents, and applications that store users or configuration in XML often authenticate against it: /users/user[username/text()='jsmith' and password/text()='secret']

Because XPath has no equivalent of database privilege separation, XPath injection is in some ways more dangerous than SQLi: there is no notion of a low-privileged database account to contain it. Payloads mirror SQLi:

Authentication bypass: username ' or '1'='1 (or admin' or '1'='1' or 'a'='a ) makes the predicate always true.

Blind extraction: using substring() , string-length() and boolean conditions to read the document node by node, exactly as boolean-blind SQLi reads a table.

Whole-document disclosure: injecting //* style expressions to return every node.

The implication is disclosure of the entire XML data store and authentication bypass against any XML-backed login.

3. XML Injection (and its relation to XXE)

XML injection means inserting XML metacharacters ( < > & ' " ) or whole elements into an XML document the application builds, altering its structure. Two distinct outcomes:

Structural/logic injection: adding an extra element to a message so that, say, a <role>user</role> becomes <role>user</role><role>admin</role> and a naive parser honours the last one — privilege escalation via message tampering. This is the SOAP-injection idea from 10.5.

XXE (XML External Entity): covered in detail in 11.4 — injecting a DTD with an external entity to read local files, reach internal services (SSRF) or cause denial of service via entity expansion. XXE is the highest-impact member of the XML-injection family and the reason external-entity processing must be disabled.

4. Code and Expression-Language Injection

Code injection is the most severe class: untrusted input is passed to a function that executes it as program code , giving remote code execution directly.

Interpreter eval : PHP eval() , assert() , preg_replace with the legacy /e modifier; Python eval() / exec() ; JavaScript eval() and Function() . Input reaching any of these runs as code.

Expression Language / template injection (SSTI): modern frameworks evaluate expressions in templates — Java SpEL and OGNL (the engine behind several catastrophic Apache Struts RCEs), Thymeleaf , Python Jinja2 ( {{7*7}} returning 49 is the canonical detection probe), Ruby ERB , and Node Pug/Handlebars . Server-Side Template Injection escalates from expression evaluation to full RCE ( {{config.__class__...}} chains in Jinja2, #{...} in Thymeleaf).

Deserialization: untrusted serialized objects (Java, .NET, PHP, Python pickle) that instantiate attacker-chosen types on load — a distinct but related path to code execution.

Distinguish code injection (attacker input becomes code in the application's own language, run in-process) from OS command injection (11.4: input becomes arguments to a shell command). Both yield execution; code injection runs inside the interpreter, command injection spawns a shell.

The detection method for SSTI is the arithmetic probe: submit ${7*7} , {{7*7}} , #{7*7} and <%= 7*7 %> in turn and watch for 49 in the response, which tells you both that evaluation occurs and which engine is present.

• 5. The Shared Root Cause and the Shared Defence Trusted structure + Untrusted input = Interpreter runs it
• -----------------------------------------------------------------------------
• SQL query ' OR '1'='1 database command
• LDAP filter *)(uid=* directory query
• XPath expression ' or '1'='1 XML node selection
• Shell command line ; rm -rf / OS command
• Template / eval() {{7*7}} / system('id') arbitrary code

Because the cause is identical, the defence is identical in principle and only differs in mechanism per interpreter:

Parameterisation / separation of code and data wherever the interpreter supports it — parameterised SQL queries, LDAP APIs that bind values rather than concatenate filters, XPath variable binding, sandboxed template contexts that never evaluate user input as an expression, and never passing user input to eval .

Context-aware escaping as a secondary control — escape exactly the metacharacters of the target interpreter (LDAP ()*\ , XML <>&'" , shell metacharacters), not a generic set.

Strict input validation — allow-list the expected format (a numeric ID is digits only), which shrinks the payload space for every class at once.

Least privilege — the LDAP bind account, database account and application process should hold only the rights they need, so a successful injection is contained.

For the exam, the key takeaways are that injection is one class with many dialects, that each dialect has a recognisable payload signature, that code/template injection means RCE while LDAP/XPath typically mean authentication bypass and data disclosure, and that parameterisation — not blacklisting — is the real fix in every case.