LDAP injection primary defenses
The two primary defenses against LDAP injection are: (1) Escape all variables using the right LDAP encoding function, and (2) Use a framework that automatically protects from LDAP injection.
OWASP Cheat Sheets · all subjects
abuse_cases/implementation
98 notes in this subject, read out of this brain and free to use. This is page 2 of 2.
.NET LINQ to LDAP framework
The LINQ to LDAP NuGet package (for .NET Framework 4.5 or lower) provides automatic LDAP encoding when building LDAP queries, eliminating manual escaping requirements.
.NET Encoder LDAP DN encoding with optional parameters
Encoder.LdapDistinguishedNameEncode(string, bool, bool) allows turning off initial or final character escaping rules, useful when concatenating escaped DN fragments into a complete distinguished name.
.NET Encoder LDAP Distinguished Name encoding
In .NET, use Encoder.LdapDistinguishedNameEncode(string) to encode DN input according to RFC2253. Unsafe characters are converted to #XX where XX is the hexadecimal representation. Comma, plus, quote, slash, less than, and greater than signs are escaped with backslash notation. Leading space or hash (#) and trailing space are also escaped with backslash.
.NET Encoder LDAP filter encoding
In .NET, use Encoder.LdapFilterEncode(string) to encode LDAP search filter input according to RFC4515. Unsafe values are converted to \XX where XX is the hexadecimal representation of the unsafe character.
OWASP Java Encoder LDAP functions
The OWASP Java Encoder Project provides encodeForLDAP(String) and encodeForDN(String) methods for safe LDAP encoding. These should be used to escape variables before adding them to LDAP queries.
Java vulnerable LDAP query concatenation
Do not concatenate user input directly into LDAP filters. Vulnerable example: String filter = "(&(uid=" + userInput + ")(objectClass=person))"; This allows LDAP injection attacks.
Java parameterized LDAP query syntax
In Java, use parameterized filters with placeholders to prevent LDAP injection. Syntax: String filter = "(&(uid={0})(objectClass=person))"; NamingEnumeration<SearchResult> results = ctx.search("ou=users,dc=example,dc=com", filter, new Object[]{ userInput }, controls);
Avoid direct updates to running containers; use rolling updates instead
Direct updates to running containers can break the image-container relationship. Use Kubernetes' rolling updates feature instead, which gradually updates a running application by upgrading its images to the latest version.
Use distroless images or empty scratch images to minimize attack surface
Distroless images sharply reduce attack surface because they do not include shells and contain fewer packages than other images. Empty/scratch images are ideal for statically compiled languages like Go, providing truly minimal attack surface with only the code. Avoid including OS package managers or shells in container images as they may have unknown vulnerabilities.
Pod security context parameters and enforcement
Security context controls security parameters for pods, containers, and volumes in deployment yaml. Key parameters include: runAsNonRoot indicates containers should run as non-root user; Capabilities controls Linux capabilities assigned to container; readOnlyRootFilesystem controls whether container can write to root filesystem. PodSecurityContext runAsNonRoot prevents running container with root user as part of pod. Properly implementing security context everywhere eliminates entire classes of attacks relying on privileged access.
Resource quota configuration to prevent DoS and resource exhaustion
Kubernetes clusters create resources with unbounded CPU limits and memory requests/limits by default, risking Denial of Service or noisy neighbor scenarios. Resource quotas on namespaces limit resource capacity and restrict namespaces by defining CPU capacity, memory, or persistent disk space. Quotas can limit pod, service, or volume counts per namespace and restrict maximum or minimum resource sizes. Example yaml for ResourceQuota: specify hard limits for pods count, requests.cpu, requests.memory, limits.cpu, and limits.memory. Apply with: kubectl create -f compute-resources.yaml --namespace=myspace
Kubernetes Secrets must not be exposed as environment variables; use read-only volumes
Secrets in Kubernetes contain sensitive data like passwords and tokens. Best practice is to mount secrets into read-only volumes rather than expose them as environment variables. Secrets must be kept separate from images or pods; anyone with access to the image would have access to the secret. Complex applications with public access are especially vulnerable.
Encrypt Kubernetes Secrets at rest using encryption feature
Kubernetes supports encryption at rest (introduced in 1.7, v1 beta since 1.13) which encrypts Secret resources in etcd and prevents parties with etcd access from viewing secret content. Always encrypt backups using reviewed solutions and consider full disk encryption, as the etcd database contains information accessible via Kubernetes API. Access to etcd could give attackers significant visibility into cluster state.
Use external secrets manager as alternative to Kubernetes Secrets
External secrets managers can store and manage secrets rather than storing them in Kubernetes Secrets, providing benefits including handling secrets across multiple clusters or clouds and controlling and rotating secrets centrally.
Rotate infrastructure credentials frequently with short lifetimes
The shorter the lifetime of a secret or credential, the harder for attackers to exploit it. Set short lifetimes on certificates and automate rotation. Use authentication providers that control token lifetime and issue short-lived tokens where possible. Rotate service account tokens used in external integrations frequently. Revoke or remove authorization for bootstrap tokens after node setup is complete.
Mass Assignment exploitability conditions
Mass Assignment becomes exploitable when: (1) an attacker can guess common sensitive fields, (2) an attacker has access to source code and can review the models for sensitive fields, AND (3) the object with sensitive fields has an empty constructor.
Least privilege principle for command execution
The problem of command injection is exacerbated if the compromised process does not follow the principle of least privileges. Attacker-controlled commands running with special system privileges increase the amount of damage possible.
Additional defense: least privilege execution
Applications should run using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task.
Avoid dangerous functions: eval() and child_process.exec()
Never use `eval()` which executes strings as JavaScript code, leading to remote code execution (RCE) if combined with user input. Avoid `child_process.exec()` which sends arguments to /bin/sh, allowing arbitrary command execution through input injection. Also be cautious with `fs` module (filesystem operations) and `vm` module (code execution in V8 contexts) when used with unsanitized user input.
Avoid vulnerable regular expressions to prevent ReDoS attacks
Regular Expression Denial of Service (ReDoS) exploits regex implementations that reach extreme performance conditions (exponential backtracking). Evil regexes use grouping with repetition and alternation with overlapping, like `^(([a-z])+.)+[A-Z]([a-z])+$`, which can hang on crafted input like long strings of 'a' characters. Use `vuln-regex-detector` tool to identify vulnerable patterns.
Shopify store custom domain associations are reclaimable
Shopify custom domain associations can be claimed by any Shopify store. Vulnerable resource indicator: CNAME target `shops.myshopify.com`.
Netlify site names are reclaimable after deletion
Netlify site names are reclaimable after deletion. Any new Netlify account can claim a previously used site name. Vulnerable resource indicators: CNAME targets `*.netlify.app` or `*.netlify.com`.
GitHub Pages custom domain associations are reclaimable after deletion
When a repository using a custom domain is deleted or made private, the custom domain association is removed and an attacker can configure the same custom domain on their own GitHub Pages repository. Vulnerable resource indicators: CNAME targets `*.github.io`. Claiming the default `username.github.io` subdomain requires registering that GitHub username, which is not possible while the original account exists.
AWS S3 bucket names are globally unique and reclaimable
AWS S3 bucket names are globally unique across all AWS accounts. If a bucket is deleted, any AWS account can recreate it with the same name and serve content on the CNAME. Vulnerable resource indicators: CNAME targets `*.s3.amazonaws.com` or `*.s3-website-*.amazonaws.com`.
AWS Elastic Beanstalk environment names are globally unique and reclaimable
AWS Elastic Beanstalk environment CNAMEs are globally unique and released on environment termination. An attacker can create a new environment with the same CNAME prefix and claim the subdomain. Vulnerable resource indicator: CNAME target `*.elasticbeanstalk.com`.
Azure App Service app names are globally unique and reclaimable
Azure App Service app names are globally unique. After deletion, any Azure tenant can create a new app with the same name. Vulnerable resource indicator: CNAME target `*.azurewebsites.net`. Azure offers a domain verification mechanism via TXT records to mitigate this.
Azure Traffic Manager profile names are globally unique and reclaimable
Azure Traffic Manager profile names are globally unique and reclaimable after deletion. Any Azure tenant can create a new profile with the same name and claim the subdomain. Vulnerable resource indicator: CNAME target `*.trafficmanager.net`.
Azure CDN endpoint names are globally unique and reclaimable
Azure CDN endpoint names are globally unique. A deleted endpoint name can be registered by another tenant and claimed. Vulnerable resource indicator: CNAME target `*.azureedge.net`.
Heroku app names are globally unique and reclaimable
Heroku app names are globally unique and released on app deletion. Any Heroku account can claim the name. Vulnerable resource indicator: CNAME target `*.herokuapp.com`.
Fastly CDN service names are claimable by attacker accounts
An attacker with a Fastly account can add the victim's domain to their own Fastly service configuration. Vulnerable resource indicators: CNAME targets `*.fastly.net` or `*.global.ssl.fastly.net`.
Zendesk support portal subdomain names are reclaimable
Zendesk support portal subdomain names can be reclaimed by new Zendesk accounts. Vulnerable resource indicator: CNAME target `*.zendesk.com`.
Cargo Collective portfolio names are reclaimable
Cargo Collective portfolio names are reclaimable after deletion. Any new account can claim a previously used portfolio name. Vulnerable resource indicator: CNAME target `*.cargocollective.com`.
Tumblr custom domain associations are released when blog is deleted
Tumblr custom domain associations are released when a blog is deleted, and can be claimed by other Tumblr users. Vulnerable resource indicator: CNAME target `*.tumblr.com`.
AWS CloudFront distribution deleted while CNAME remains is vulnerable
When a CloudFront distribution is deleted but the CNAME record still points to the `*.cloudfront.net` hostname, an attacker can create a new CloudFront distribution and add the victim's domain as an alternate domain name (CNAME). CloudFront does not always verify domain ownership when adding alternate domain names, making this exploitable.
AWS Route 53 NS delegation to deleted hosted zone is vulnerable
If a subdomain's NS records delegate to a Route 53 hosted zone that has been deleted, an attacker can create a new hosted zone for the same subdomain and may receive the same NS server assignments, effectively taking control of all DNS records for that subdomain.
Google Cloud Storage bucket names are globally unique and reclaimable
GCS bucket names are globally unique and can be reclaimed after deletion. Google imposes rate limits on bucket creation and may temporarily reserve recently deleted names, but this is not a documented security guarantee and should not be relied upon. Remove DNS records when decommissioning GCS buckets.
Cloudflare for SaaS misconfiguration enables subdomain takeover
Cloudflare for SaaS (custom hostnames) configurations that do not use the custom hostname verification feature are vulnerable to hostname claim conflicts and subdomain takeover.