Coders Conquer Security: Share & Learn Series - LDAP Injections
The vast majority of computer systems use Lightweight Directory Access Protocol (LDAP). It's used to maintain distributed directory information services over any Internet Protocol (IP) network. So basically, it functions as a way to keep track of users.
LDAP is often used as an authentication source by apps to see if a user has permission to perform various actions, especially as it pertains to their defined role within an organization. For example, only those in accounting might be able to use company accounting software. Applications will often be programmed to check an LDAP table to ensure that users are acting within their established permissions.
Problems can occur when malicious users can manipulate an LDAP query. Doing this can trick the receiving server into executing invalid queries that would normally not be allowed, or even granting high level or administrator access to invalid or low-security users without a password.
LDAP injections can be tricky, but in this episode, we will learn:
- How they work
- Why they are so dangerous
- How you can put defenses in place to stop them.
How do Attackers Use LDAP Injection?
One of the reasons that LDAP-based attacks have remained popular for years is the fact that almost every computer system uses it. LDAP is open-source and works extremely well, so not a lot of alternatives have been created.
At its core, LDAP is a database that tracks valid users within an IP-based computer system or network. It can allow users to share information about systems, networks, servers, applications and even other users on the same network.
Information is stored by LDAP in the equivalent of a database line or record that is called a distinguished name, which is often abbreviated as DN. Each DN is unique. As an example, this is what a DN might look like for a user who works in the Chicago accounting office of a large corporation.
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
To ensure that each DN is unique, various codes can be added to the record, such as "+", "/", "=" and a few others. Spaces before or after a record can also be inserted to ensure that even if there are two James Smiths working in Corporate Accounts in the Chicago Parkview Office, they will each have individual DNs.
Applications generally use LDAP to allow users to send queries about specific DNs, such as, for example, when trying to locate the correct contact in the payroll department to talk about a mistake on their check. LDAP injections can happen when there is no validation of the user-provided parameters in search queries. In that case, hackers can manipulate benign searches to bypass authentication mechanisms or execute additional arbitrary queries. This can trick the server into displaying results that should not be allowed, such as user passwords, or even cause an application to grant access to high-security areas within the network, with or without a valid password.
Why are LDAP Injections so Dangerous?
The biggest danger with LDAP injections is likely the proliferation of the protocol throughout the majority of IP computer networks worldwide. It makes for an easy stepping stone for hackers looking to steal information, or to elevate their privileges on a network. No trained hacker will fail to check if LDAP injections are possible, so security teams must ensure that those holes are always closed.
Specifically, quite a few applications are programmed to help valid users find limited information about users and groups within an organization, or any other information contained in the DNs. For example, an app might allow someone to use LDAP to search for the contact information of corporate accountants working in Chicago, which would return our friend James Smith from the above example. Depending on permissions, this is likely a perfectly valid use of an LDAP query.
The danger comes when a malicious user can add parameters unfiltered the query, changing the nature of the search and tricking the server into providing information that should not normally be given. For example, by adding a user=* string, attackers could get information about every single user at an entire organization, something that should probably never be allowed.
For applications that use LDAP for authentication, the problem can be even worse. Attackers can use, for example, the (&) string at the end of an LDAP query to trick the server into thinking the argument is true. If an app uses LDAP to validate a password, forcing a True argument through an LDAP injection might allow an unauthorized user to log into the network as an administrator, even without a password.
Making LDAP Injection an L-DON'T in your Network
One of the best ways to prevent LDAP injections is to implement something like LINQtoAD or other frameworks designed specifically to resist it. This may not be possible if a network already has applications that are leveraging LDAP queries. However, even in that case, it's still a good idea for every new application to use injection-resistant frameworks moving forward.
Existing applications that use LDAP can also be hardened against injections through the use of whitelist validation and input sanitization. Where possible, restrict user input to a limited set of trusted values. Otherwise, user input that is part of an LDAP query should be sanitized first, and don't forget to include GET and POST parameters, cookies and HTTP headers as they can also act as attack vectors. Do not write your own functions to perform input sanitization; use a trusted third-party security focussed library or built-in framework APIs instead.
Beyond targeted fixes, good computing practices like assigning LDAP querying applications the least privilege needed on a network can also help. That way, if the worst should happen and an LDAP injection gets through, the damage would be mitigated.
More Information about LDAP Injections
For further reading, you can take a look at the OWASP writeup on LDAP Injections, or the injection prevention cheat sheet. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Problems can occur when malicious users can manipulate an LDAP query. Doing this can trick the receiving server into executing invalid queries that would normally not be allowed, or even granting high level or administrator access to invalid or low-security users without a password.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
The vast majority of computer systems use Lightweight Directory Access Protocol (LDAP). It's used to maintain distributed directory information services over any Internet Protocol (IP) network. So basically, it functions as a way to keep track of users.
LDAP is often used as an authentication source by apps to see if a user has permission to perform various actions, especially as it pertains to their defined role within an organization. For example, only those in accounting might be able to use company accounting software. Applications will often be programmed to check an LDAP table to ensure that users are acting within their established permissions.
Problems can occur when malicious users can manipulate an LDAP query. Doing this can trick the receiving server into executing invalid queries that would normally not be allowed, or even granting high level or administrator access to invalid or low-security users without a password.
LDAP injections can be tricky, but in this episode, we will learn:
- How they work
- Why they are so dangerous
- How you can put defenses in place to stop them.
How do Attackers Use LDAP Injection?
One of the reasons that LDAP-based attacks have remained popular for years is the fact that almost every computer system uses it. LDAP is open-source and works extremely well, so not a lot of alternatives have been created.
At its core, LDAP is a database that tracks valid users within an IP-based computer system or network. It can allow users to share information about systems, networks, servers, applications and even other users on the same network.
Information is stored by LDAP in the equivalent of a database line or record that is called a distinguished name, which is often abbreviated as DN. Each DN is unique. As an example, this is what a DN might look like for a user who works in the Chicago accounting office of a large corporation.
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
To ensure that each DN is unique, various codes can be added to the record, such as "+", "/", "=" and a few others. Spaces before or after a record can also be inserted to ensure that even if there are two James Smiths working in Corporate Accounts in the Chicago Parkview Office, they will each have individual DNs.
Applications generally use LDAP to allow users to send queries about specific DNs, such as, for example, when trying to locate the correct contact in the payroll department to talk about a mistake on their check. LDAP injections can happen when there is no validation of the user-provided parameters in search queries. In that case, hackers can manipulate benign searches to bypass authentication mechanisms or execute additional arbitrary queries. This can trick the server into displaying results that should not be allowed, such as user passwords, or even cause an application to grant access to high-security areas within the network, with or without a valid password.
Why are LDAP Injections so Dangerous?
The biggest danger with LDAP injections is likely the proliferation of the protocol throughout the majority of IP computer networks worldwide. It makes for an easy stepping stone for hackers looking to steal information, or to elevate their privileges on a network. No trained hacker will fail to check if LDAP injections are possible, so security teams must ensure that those holes are always closed.
Specifically, quite a few applications are programmed to help valid users find limited information about users and groups within an organization, or any other information contained in the DNs. For example, an app might allow someone to use LDAP to search for the contact information of corporate accountants working in Chicago, which would return our friend James Smith from the above example. Depending on permissions, this is likely a perfectly valid use of an LDAP query.
The danger comes when a malicious user can add parameters unfiltered the query, changing the nature of the search and tricking the server into providing information that should not normally be given. For example, by adding a user=* string, attackers could get information about every single user at an entire organization, something that should probably never be allowed.
For applications that use LDAP for authentication, the problem can be even worse. Attackers can use, for example, the (&) string at the end of an LDAP query to trick the server into thinking the argument is true. If an app uses LDAP to validate a password, forcing a True argument through an LDAP injection might allow an unauthorized user to log into the network as an administrator, even without a password.
Making LDAP Injection an L-DON'T in your Network
One of the best ways to prevent LDAP injections is to implement something like LINQtoAD or other frameworks designed specifically to resist it. This may not be possible if a network already has applications that are leveraging LDAP queries. However, even in that case, it's still a good idea for every new application to use injection-resistant frameworks moving forward.
Existing applications that use LDAP can also be hardened against injections through the use of whitelist validation and input sanitization. Where possible, restrict user input to a limited set of trusted values. Otherwise, user input that is part of an LDAP query should be sanitized first, and don't forget to include GET and POST parameters, cookies and HTTP headers as they can also act as attack vectors. Do not write your own functions to perform input sanitization; use a trusted third-party security focussed library or built-in framework APIs instead.
Beyond targeted fixes, good computing practices like assigning LDAP querying applications the least privilege needed on a network can also help. That way, if the worst should happen and an LDAP injection gets through, the damage would be mitigated.
More Information about LDAP Injections
For further reading, you can take a look at the OWASP writeup on LDAP Injections, or the injection prevention cheat sheet. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
The vast majority of computer systems use Lightweight Directory Access Protocol (LDAP). It's used to maintain distributed directory information services over any Internet Protocol (IP) network. So basically, it functions as a way to keep track of users.
LDAP is often used as an authentication source by apps to see if a user has permission to perform various actions, especially as it pertains to their defined role within an organization. For example, only those in accounting might be able to use company accounting software. Applications will often be programmed to check an LDAP table to ensure that users are acting within their established permissions.
Problems can occur when malicious users can manipulate an LDAP query. Doing this can trick the receiving server into executing invalid queries that would normally not be allowed, or even granting high level or administrator access to invalid or low-security users without a password.
LDAP injections can be tricky, but in this episode, we will learn:
- How they work
- Why they are so dangerous
- How you can put defenses in place to stop them.
How do Attackers Use LDAP Injection?
One of the reasons that LDAP-based attacks have remained popular for years is the fact that almost every computer system uses it. LDAP is open-source and works extremely well, so not a lot of alternatives have been created.
At its core, LDAP is a database that tracks valid users within an IP-based computer system or network. It can allow users to share information about systems, networks, servers, applications and even other users on the same network.
Information is stored by LDAP in the equivalent of a database line or record that is called a distinguished name, which is often abbreviated as DN. Each DN is unique. As an example, this is what a DN might look like for a user who works in the Chicago accounting office of a large corporation.
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
To ensure that each DN is unique, various codes can be added to the record, such as "+", "/", "=" and a few others. Spaces before or after a record can also be inserted to ensure that even if there are two James Smiths working in Corporate Accounts in the Chicago Parkview Office, they will each have individual DNs.
Applications generally use LDAP to allow users to send queries about specific DNs, such as, for example, when trying to locate the correct contact in the payroll department to talk about a mistake on their check. LDAP injections can happen when there is no validation of the user-provided parameters in search queries. In that case, hackers can manipulate benign searches to bypass authentication mechanisms or execute additional arbitrary queries. This can trick the server into displaying results that should not be allowed, such as user passwords, or even cause an application to grant access to high-security areas within the network, with or without a valid password.
Why are LDAP Injections so Dangerous?
The biggest danger with LDAP injections is likely the proliferation of the protocol throughout the majority of IP computer networks worldwide. It makes for an easy stepping stone for hackers looking to steal information, or to elevate their privileges on a network. No trained hacker will fail to check if LDAP injections are possible, so security teams must ensure that those holes are always closed.
Specifically, quite a few applications are programmed to help valid users find limited information about users and groups within an organization, or any other information contained in the DNs. For example, an app might allow someone to use LDAP to search for the contact information of corporate accountants working in Chicago, which would return our friend James Smith from the above example. Depending on permissions, this is likely a perfectly valid use of an LDAP query.
The danger comes when a malicious user can add parameters unfiltered the query, changing the nature of the search and tricking the server into providing information that should not normally be given. For example, by adding a user=* string, attackers could get information about every single user at an entire organization, something that should probably never be allowed.
For applications that use LDAP for authentication, the problem can be even worse. Attackers can use, for example, the (&) string at the end of an LDAP query to trick the server into thinking the argument is true. If an app uses LDAP to validate a password, forcing a True argument through an LDAP injection might allow an unauthorized user to log into the network as an administrator, even without a password.
Making LDAP Injection an L-DON'T in your Network
One of the best ways to prevent LDAP injections is to implement something like LINQtoAD or other frameworks designed specifically to resist it. This may not be possible if a network already has applications that are leveraging LDAP queries. However, even in that case, it's still a good idea for every new application to use injection-resistant frameworks moving forward.
Existing applications that use LDAP can also be hardened against injections through the use of whitelist validation and input sanitization. Where possible, restrict user input to a limited set of trusted values. Otherwise, user input that is part of an LDAP query should be sanitized first, and don't forget to include GET and POST parameters, cookies and HTTP headers as they can also act as attack vectors. Do not write your own functions to perform input sanitization; use a trusted third-party security focussed library or built-in framework APIs instead.
Beyond targeted fixes, good computing practices like assigning LDAP querying applications the least privilege needed on a network can also help. That way, if the worst should happen and an LDAP injection gets through, the damage would be mitigated.
More Information about LDAP Injections
For further reading, you can take a look at the OWASP writeup on LDAP Injections, or the injection prevention cheat sheet. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
The vast majority of computer systems use Lightweight Directory Access Protocol (LDAP). It's used to maintain distributed directory information services over any Internet Protocol (IP) network. So basically, it functions as a way to keep track of users.
LDAP is often used as an authentication source by apps to see if a user has permission to perform various actions, especially as it pertains to their defined role within an organization. For example, only those in accounting might be able to use company accounting software. Applications will often be programmed to check an LDAP table to ensure that users are acting within their established permissions.
Problems can occur when malicious users can manipulate an LDAP query. Doing this can trick the receiving server into executing invalid queries that would normally not be allowed, or even granting high level or administrator access to invalid or low-security users without a password.
LDAP injections can be tricky, but in this episode, we will learn:
- How they work
- Why they are so dangerous
- How you can put defenses in place to stop them.
How do Attackers Use LDAP Injection?
One of the reasons that LDAP-based attacks have remained popular for years is the fact that almost every computer system uses it. LDAP is open-source and works extremely well, so not a lot of alternatives have been created.
At its core, LDAP is a database that tracks valid users within an IP-based computer system or network. It can allow users to share information about systems, networks, servers, applications and even other users on the same network.
Information is stored by LDAP in the equivalent of a database line or record that is called a distinguished name, which is often abbreviated as DN. Each DN is unique. As an example, this is what a DN might look like for a user who works in the Chicago accounting office of a large corporation.
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
To ensure that each DN is unique, various codes can be added to the record, such as "+", "/", "=" and a few others. Spaces before or after a record can also be inserted to ensure that even if there are two James Smiths working in Corporate Accounts in the Chicago Parkview Office, they will each have individual DNs.
Applications generally use LDAP to allow users to send queries about specific DNs, such as, for example, when trying to locate the correct contact in the payroll department to talk about a mistake on their check. LDAP injections can happen when there is no validation of the user-provided parameters in search queries. In that case, hackers can manipulate benign searches to bypass authentication mechanisms or execute additional arbitrary queries. This can trick the server into displaying results that should not be allowed, such as user passwords, or even cause an application to grant access to high-security areas within the network, with or without a valid password.
Why are LDAP Injections so Dangerous?
The biggest danger with LDAP injections is likely the proliferation of the protocol throughout the majority of IP computer networks worldwide. It makes for an easy stepping stone for hackers looking to steal information, or to elevate their privileges on a network. No trained hacker will fail to check if LDAP injections are possible, so security teams must ensure that those holes are always closed.
Specifically, quite a few applications are programmed to help valid users find limited information about users and groups within an organization, or any other information contained in the DNs. For example, an app might allow someone to use LDAP to search for the contact information of corporate accountants working in Chicago, which would return our friend James Smith from the above example. Depending on permissions, this is likely a perfectly valid use of an LDAP query.
The danger comes when a malicious user can add parameters unfiltered the query, changing the nature of the search and tricking the server into providing information that should not normally be given. For example, by adding a user=* string, attackers could get information about every single user at an entire organization, something that should probably never be allowed.
For applications that use LDAP for authentication, the problem can be even worse. Attackers can use, for example, the (&) string at the end of an LDAP query to trick the server into thinking the argument is true. If an app uses LDAP to validate a password, forcing a True argument through an LDAP injection might allow an unauthorized user to log into the network as an administrator, even without a password.
Making LDAP Injection an L-DON'T in your Network
One of the best ways to prevent LDAP injections is to implement something like LINQtoAD or other frameworks designed specifically to resist it. This may not be possible if a network already has applications that are leveraging LDAP queries. However, even in that case, it's still a good idea for every new application to use injection-resistant frameworks moving forward.
Existing applications that use LDAP can also be hardened against injections through the use of whitelist validation and input sanitization. Where possible, restrict user input to a limited set of trusted values. Otherwise, user input that is part of an LDAP query should be sanitized first, and don't forget to include GET and POST parameters, cookies and HTTP headers as they can also act as attack vectors. Do not write your own functions to perform input sanitization; use a trusted third-party security focussed library or built-in framework APIs instead.
Beyond targeted fixes, good computing practices like assigning LDAP querying applications the least privilege needed on a network can also help. That way, if the worst should happen and an LDAP injection gets through, the damage would be mitigated.
More Information about LDAP Injections
For further reading, you can take a look at the OWASP writeup on LDAP Injections, or the injection prevention cheat sheet. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Table of contents
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
