Category: Identity Lifecycle

Rebinding

Also known as: DNS Rebinding

Simply put

In an IAM and network security context, rebinding most commonly refers to DNS rebinding, an attack that manipulates the Domain Name System so a web browser is tricked into treating an attacker-controlled external domain as if it were part of a user's internal or private network. This can let malicious code loaded in the browser reach devices and services that would normally be shielded from the public internet. The term 'rebind' more generally means to bind something anew, but in security discussions it typically denotes this DNS-based attack.

Formal definition

DNS rebinding is an attack technique that abuses the DNS resolution and browser same-origin trust boundaries by changing the IP address associated with an attacker-controlled domain after an initial page load. According to the cited sources, the attacker first serves malicious JavaScript from a domain that resolves to their own server, then rebinds that domain to an internal or private-network IP address, causing the browser to treat requests to the internal target as same-origin with the attacker's domain. This can expose internal devices and services to browser-originated requests despite network segmentation. Note that the evidence provided describes DNS rebinding at a conceptual level only and does not detail specific mitigations, standards, or protocol-level countermeasures; those are out of scope for this entry. The non-security dictionary sense of 'rebinding' (renewing a physical binding, such as on a book) is unrelated to the IAM and network security usage.

Why it matters

DNS rebinding matters because it can defeat one of the most common assumptions in network security: that services placed behind a firewall or on a private network segment are unreachable from the public internet. As the cited sources describe, the attack tricks a user's browser into treating an attacker-controlled external domain as if it belonged to the internal network, allowing malicious JavaScript to reach internal devices and services. This means a user simply visiting a malicious or compromised web page can become an unwitting conduit into an otherwise segmented environment.

For identity and access teams, the significance is that DNS rebinding sidesteps controls that rely on network location as an implicit trust signal. Internal administrative interfaces, management consoles, and other services that are exposed without strong authentication because they are assumed to be network-isolated become viable targets when a browser can be coerced into originating requests to them. The attack is a concrete illustration of why network position alone is a weak basis for authorization decisions.

The evidence provided describes DNS rebinding only at a conceptual level and does not detail specific mitigations, standards, or protocol-level countermeasures, so this entry does not make claims about defenses. Teams evaluating their exposure should treat those countermeasures as out of scope here and consult dedicated mitigation guidance.

Who it's relevant to

Security architects

DNS rebinding demonstrates why network location should not be treated as an implicit trust or authorization signal. Architects designing segmentation and zero-trust access models should account for the possibility that a user's browser can be coerced into reaching internal targets, and should not assume that firewall placement alone protects a service.

System administrators

Administrators who expose internal management consoles, device interfaces, or services on private networks with weak or absent authentication are the practical targets of this technique. The cited sources describe how such internal devices and services can be reached by malicious JavaScript running in a user's browser despite network segmentation.

IAM engineers

The attack underscores the value of requiring strong authentication and authorization on every service rather than relying on network isolation. Engineers should consider how services validate the origin and identity of incoming requests, since a browser tricked by DNS rebinding may present requests that appear to come from inside the network.

Compliance and governance leads

For teams assessing risk, DNS rebinding is an example of how network-based assumptions can be circumvented. Note that the evidence used for this entry covers the attack conceptually and does not enumerate specific mitigations or standards; those should be sourced separately when documenting controls or audit expectations.

Inside Rebinding

LDAP Rebind Operation

In the context of directory services, rebinding refers to issuing a new bind operation on an existing LDAP connection to authenticate as a different principal or to re-authenticate the current one. This changes the authorization context associated with subsequent operations on that connection without necessarily tearing down the underlying transport.

Connection Reuse vs. Re-authentication

Rebinding typically allows a client or connection pool to reuse an established connection while switching the bound identity, avoiding the overhead of opening a new socket. The identification and authentication steps are repeated for the new principal even though the network connection persists.

Referral Chasing and Rebind Callbacks

Many LDAP client libraries invoke a rebind mechanism when following referrals to another directory server, where credentials must be presented again to the referred-to server. Depending on configuration, this may reuse the original credentials or require a separate credential set supplied by a rebind handler.

Anonymous vs. Authenticated Rebind

A rebind can move a connection from an authenticated state to an anonymous state, or from anonymous to authenticated, or between two distinct authenticated identities. Each transition changes what the connection is authorized to read or modify, subject to the directory's access controls.

DNS Rebinding (distinct concept)

Separately from directory operations, 'rebinding' also names DNS rebinding, a network attack technique where an attacker manipulates DNS resolution to bypass same-origin protections. This is a different concept and is generally out of scope when the term is used in a directory or authentication context.

Common questions

Answers to the questions practitioners most commonly ask about Rebinding.

Is LDAP rebinding a way to authorize what a user can access?

No. Rebinding is part of authentication and identification against a directory, not authorization. In a typical bind-search-rebind flow, the initial bind and subsequent rebind verify credentials or re-establish an authenticated session as a particular principal; determining what that principal may then do is a separate authorization step handled by directory access controls or an external policy decision point. Keeping these distinct matters because a successful rebind confirms identity only, not entitlements.

Does rebinding create a brand-new connection to the directory each time?

Not necessarily. Rebinding refers to changing the authentication identity associated with an existing LDAP connection rather than always tearing down and reopening a network connection. In many deployments a connection is opened, an initial bind is performed (often as a service account to search for the user's DN), and then a rebind authenticates as the located user on the same connection. Whether the underlying connection is reused depends on the client library and configuration.

When is rebinding typically used in an LDAP authentication flow?

Rebinding is commonly used in the bind-search-rebind pattern. A client first binds with a service or proxy account, searches the directory to resolve the user's distinguished name from a supplied identifier, and then rebinds as that DN using the user-supplied credential to verify authentication. This is typical when the login identifier is not the DN itself and must be looked up before the user's credentials can be validated.

How does rebinding interact with LDAP referrals?

When a directory returns a referral pointing to another server, the client may need to bind again at the referred server to continue the operation. Depending on the client configuration, referral chasing can trigger an automatic rebind, and how credentials are supplied for that rebind varies by library. Behavior differs across implementations, so whether referrals are followed automatically and with which identity is a configuration and deployment concern rather than a fixed guarantee.

What are the security considerations when rebinding as an end user?

Because a rebind transmits the user's credential to authenticate as that DN, the connection should typically use TLS (for example LDAPS or StartTLS, depending on configuration) so credentials are not exposed in transit. Note that transport encryption protects the credential on the wire but is separate from how credentials are stored or verified server-side. Handling of failed rebinds should also avoid leaking whether a DN exists versus whether the password was wrong, depending on your account-enumeration posture.

How does rebinding affect connection pooling in high-volume deployments?

Connection pooling and per-user rebinding can conflict, because a pooled connection carries the authentication state of the last bind. In many deployments the search phase uses a shared service-account connection from the pool, while user authentication rebinds are performed on dedicated or carefully reset connections so a pooled connection is not left authenticated as an end user. The exact handling depends on the client library's pooling and rebind semantics.

Common misconceptions

Rebinding re-establishes the network connection each time.

In most LDAP deployments rebinding re-runs the bind (authentication) step on the same underlying connection, which is precisely why it is used to avoid the cost of opening new connections. The transport typically persists while the bound identity changes.

Rebinding is only about authentication and has no bearing on what the connection can do.

Because a bind establishes the principal, rebinding to a different identity changes the authorization context for subsequent operations. Authentication and authorization remain distinct steps, but the authenticated identity determined by the rebind is what the directory's access controls are evaluated against.

LDAP rebinding and DNS rebinding are the same thing.

They share a name but are unrelated. LDAP rebinding is a directory authentication operation; DNS rebinding is a network attack against origin-based security. Which meaning applies depends entirely on context and should be stated explicitly.

Best practices

Use connection pooling with controlled rebinding to reuse transport connections while switching principals, but ensure each pooled connection's bound identity is tracked so operations are not executed under the wrong authorization context.

When rebinding to follow referrals, decide deliberately whether to reuse the original credentials or supply a dedicated rebind handler, since credential reuse across servers may expose credentials beyond their intended trust boundary.

Avoid leaving connections in an unexpected anonymous state after a rebind; verify the resulting bound identity before performing sensitive reads or writes, because the authorization outcome depends on that identity.

Protect credentials presented during rebind by requiring transport encryption (such as LDAPS or StartTLS depending on your deployment), noting that authentication over an unencrypted channel can expose bind credentials.

Clearly disambiguate the term in documentation and design discussions to indicate whether directory rebinding or DNS rebinding is meant, since the mitigations and concerns differ entirely.

Test rebind behavior against your specific directory vendor and client library, as referral chasing, credential handling, and state transitions can vary by implementation and configuration.