Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

LDAP Injection Techniques


Published on

Artículo para el congreso ICCS 2010 sobre técnicas LDAP Injection en aplicaciones web.

Published in: Technology
  • Be the first to comment

LDAP Injection Techniques

  1. 1. TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 1 LDAP Injection Techniques Jose Mar´ıa Alonso, Rodolfo Bord´on, Marta Beltr´an and Antonio Guzm´an Abstract—The increase in the number of databases accessed only by some applications has made code injection attacks an important threat to almost any current system. If one of these applications accepts inputs from a client and executes these inputs without first validating them, the attackers are free to execute their own queries and therefore, to extract, modify or delete the content of the database associated to the application. Several works have analyzed SQL injection attacks and their consequences. However, there is very little work in other code injection techniques attacking other languages or protocols. In this paper a deep analysis of the LDAP injection techniques is presented. Furthermore, a clear distinction between classic and blind injection techniques is made. Finally, a real LDAP environment has been implemented to evaluate the security of applications based on LDAP and to exemplify the most common vulnerabilities and their possible consequences. Index Terms—Web applications security, code injection techniques, LDAP. I. INTRODUCTION The amount of data stored in organizational databases has increased very fast in last years due to the rapid advancement of information technologies. And a lot of these data is sensitive, private and critical to the organizations, their clients and partners. Therefore, the databases are usually installed behind internal firewalls, protected with intrusion detection mechanisms and accessed only by some application programs. To access a database, users have to connect to one of these applications and to submit queries trough them to the database. Then, the threat to databases arises when these application programs do not behave properly and send these queries without validating user inputs first. In fact, over a 50% web applications vulnerabilities are input validation vulnerabilities ([1]) which allow the exploitation of code injection techniques. These attacks have proliferated in recent years causing severe damages in several systems and applications. The SQL injection techniques are the most widely used and studied ([2], [3], [4], [5]) but there are other injection techniques associated to other languages or protocols such as XPath ([6], [7]) or LDAP ([8], [9]). The only hope in preventing the consequences of this kind of attacks lies in studying the different code injection possibilities and in making them public and well known for all the programmers and administrators ([10], [11], [12]). In this paper the LDAP injection techniques are analyzed in depth, because all the web applications based on LDAP trees can be vulnerable to this kind of attacks. The key to exploit injection techniques with LDAP is to concatenate attack filters to the filters used to search in the directory services. Using these techniques, an attacker may obtain direct access to the hierarchical database underlying an LDAP tree, and therefore to important information of the corporative network. And this can be even more critical because the security of many applications and services are based on LDAP directories in current single sign-on Jose Mar´ıa Alonso and Rodolfo Bord´on are with Informatica64, c/Juan Ramon Jimenez 8, 28933 M´ostoles, Madrid, Spain. Email:, Marta Beltr´an and Antonio Guzm´an are with the Computing Department, Universidad Rey Juan Carlos, Edificio Departamental II, Campus de M´ostoles, 28933 M´ostoles, Madrid, Spain. E-mail:, environments ([13], [14]). Although the vulnerabilities that lead to these consequences are easy to understand and to solve, they persist due to the lack of information about these attacks and their effects. The main contributions of this paper are a first study of the LDAP vulnerabilities and a deep analysis of the injection techniques which can be used to exploit these vulnerabilities. Furthermore, a real environment has been implemented to perform different experiments in typical LDAP scenarios and to evaluate the possible danger of this kind of attacks. It is important to note that the use of filters to limit the information that is showed to a client sending an LDAP search to the server does not increase the security of the applications, because these filters does not prevent the use of blind code injection techniques, capable of exploiting injection techniques without having detailed error messages from the server. Therefore, both, the classic and the blind code injection techniques will be studied in depth in this paper. This paper is organized as follows. Section 2 gives an LDAP protocol overview necessary to understand the concepts used in the rest of the paper. Section 3 presents the typical LDAP environment where the LDAP injection attacks reported in Section 4 usually take place. Section 5 summarizes the most important results obtained using these injection techniques to exploit the reported vulnerabilities in the typical environments. Based on these results, solutions for the LDAP injection vulnerabilities are proposed in Section 6. And, finally, Section 7 presents conclusions and future work. II. LDAP OVERVIEW Directories are hierarchical databases designed to store and to organize information sharing certain common attributes: • The information structure: a tree of directory entries. • Powerful browsing and search capabilities Therefore, a directory is a database specialized in searches instead in updates and in processing specific queries instead in results listing. Furthermore, a directory tolerates temporal inconsistencies between its copies. A directory service is a software application implemented to access the directories information. It usually allows data replication and distribution and acts as an abstraction layer between users and shared resources. The Lightweight Directory Access Protocol is a protocol for querying and modifying directory services running over TCP/IP ([15], [16]). It allows quick and efficient searches and updates of this kind of services. The most widely used implementation of this protocol are ADAM (Active Directory Application Mode, [17]) and OpenLDAP ([18]). LDAP is object-oriented, therefore, every entry in a LDAP tree is an instance of an object and must correspond to the rules fixed for the attributes of that object. LDAP is also based on the client/server model, therefore, clients send operation requests to the server and the server responses with the directory information. The most frequent operation request is to search for directory entries, and to response these requests the server has to test if an entry of the LDAP tree contains a given attribute value. This test is performed using the LDAP filters defined in the RFC 4515.
  2. 2. TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 2 The structure of these filters can be summarized with: Filter = ( filtercomp ) Filtercomp = and / or / not / item And = & filterlist Or = | filterlist Not = ! filter Filterlist = 1*filter Item= simple / present / substring Simple = attr filtertype assertionvalue Filtertype = ”=” /” =”/ ”¿=” / ”¡=” Present = attr = * Substring = attr ”=” [initial] * [final] Initial = assertionvalue Final = assertionvalue It can be seen that all the filters must be in brackets, and that only a reduced set of logical (AND, OR and NOT) and relational (≤, ≥, =, ) operators is available to construct them. In addition, one special character, the asterisk, can be used to replace one or more characters in the construction of the filters. III. TYPICAL LDAP ENVIRONMENT LDAP services are a key component for the daily operation of many companies and institutions. Directory Services such as Microsoft Active Directory, Novell E-Directory or RedHat Directory Services are based on the LDAP protocol ([19]). But there are other application and services taking advantage of the LDAP services. These applications and services required in the past different directories (with different user names and passwords) to work. For example, a directory was required for the domain, a separate directory for mailboxes and distribution lists, and more directories for remote access, databases or web applications. But new directories based on LDAP services are multi-purpose, working as centralized information repositories for users authentica- tion and enabling single sign-on environments. This new scenario increases the productivity by reducing the administration complexity and by improving security and fault toler- ance. In practically all the environments, the applications based on LDAP services use the directory with one of these purposes: • Access control (user/password pair verification, users certificates management). • Privileges management. • Resources management. Due to the importance of the LDAP services for the corporative networks, the LDAP servers are usually placed in the backend with the rest of database servers. IV. LDAP INJECTION The LDAP injection attacks are based on the same techniques that the SQL injection attacks. The underlying concept is to take advantage of the parameters introduced by the client to generate the LDAP query. A secure application should filter these inputs before constructing the query sent to the server. But in a vulnerable environment these parameters are not filtered and the attacker can inject his code to change the results obtained with the query. Taking into consideration the structure of the LDAP filters ex- plained in section II and the implementations of the most widely used LDAP implementations, ADAM and OpenLDAP, the following conclusions can be drawn about the code injection: • ((normal query)(code injection)): If the filter used to construct the query has this structure, the code injection has no results be- cause the server only processes the first complete filter structure, in this case, the normal query. • (|(normal query)(code injection)): In this case, the code in- jected at the right of the normal query is processed if the filter sintaxis is correct, due to the | operator at the beginning of the query. The OR logic operation is performed between the results of the normal query and the results obtained with the code injection if the application does not filter the parameters introduced by the user. • (&(normal query)(code injection)): In this last case, the code injected at the right is processed again if the filter sintaxis is correct, now due to the & operator at the beginning of the query. The AND logic operation is performed between the results of the normal query and the results obtained with the code injection if the application does not filter the parameters introduced by the user. Therefore, only when the parameters introduced by the user are not filtered and when the normal queries begin with a logical operator | or &, code injection attacks can be performed. In these cases, two kinds of injection can be generated depending on the LDAP environment: classic code injection or blind code injection. A. Classic Code Injection The typical test to know if an application is vulnerable to code injection consists of sending to the server a query that generates an invalid input. Therefore, if the server returns any error message, it is clear for the attacker that the server has executed his query and that he can exploit the code injection techniques to extract the information he wants. In the case of LDAP injection, two kinds of environments can be distinguished: • AND LDAP Injection: In this case the application constructs the normal query to search in the LDAP tree with the & operator and one or more parameters introduced by the user. For example: (& (parameter1=value1)(parameter2=value2)) Where value1 and value2 are the client’s inputs used to per- form the search in the hierarchical database. The attacker can inject code to the normal query using the client input value1, maintaining a correct filter construction but using the query to achieve his own objectives. For example, suppose that this query lists all the documents visible for the users with a low security level: (& (directory=documents)(security level=low)) Where documents is the value given for the first client input and low is the value given for the second. But if the attacker wants to list all the documents visible for the high security level, he can use a code injection technique: (& (directory=documents)(security level=high))(& (directory=documents)(security level=low)) Examining this query, the following structure has been injected in the original query using the first client input value: valu1= documents)(security level=high))(& (directory=documents LDAP only processes the first complete filter structure, then, only the following query is processed: (& (directory=documents)(security level=high))
  3. 3. TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 3 , while (& (directory=documents)(security level=low)) is ig- nored. But the attacker has injected all the code necessary to maintain the correct sintaxis in the LDAP query. As a result, a list with all the documents available for the users with high security level is displayed for the attacker although he has not privileges to see them. • OR LDAP Injection: In this case the application constructs the normal query to search in the LDAP tree with the | operator and one or more parameters introduced by the user. For example: (| (parameter1=value1)(parameter2=value2)) Where value1 and value2 are the client’s inputs used to perform the search in the hierarchical database. Again the attacker can inject his own query in the server using the first client input. For example, suppose that this query wants to find a user whose name is John Smith, but the client does not know if the user has been registered with his name or with his surname: (| (uid=John)(uid=Smith)) Following with the example, if the attacker wants to know the name of all the users in the tree, he could inject code in the first parameter to construct the following query: (| (uid=void)(uid=*))(|(uid=*)(uid=Smith)) Examining this query, void)(uid=*))(| (uid=* and Smith are the client’s inputs. The LDAP server only processes the first complete filter structure, then, only this query is processed: (| (uid=void)(uid=*)) , while (|(uid=*)(uid=Smith) is ignored. But the attacker has injected all the code necessary to maintain the correct sintaxis in the LDAP query. As a result, a list with all the users would be displayed, because the first part of the processed filter is always a logical ’0’ (the value of void) and the second uses the asterisk operator to replace all the uid characters. B. Blind Code Injection One extended solution to solve the code injection vulnerabilities is to avoid the server to show error messages when it executes invalid queries. But this kind of filtering only prevents the classic code injection techniques explained in the previous section. A secure application should reject any query with injected code because it should filter the client’s input parameters. But a fortified application does not perform this filtering, it only filters the error messages produced by the server when it executes invalid injected code. Therefore, suppressing the error messages is not enough to avoid all the injection techniques, only the classic injection. Suppose that an attacker can infer from the server response, although it does not show error messages, if the code injected in the query generates a valid response (true result) or an error (false result). Then, the attacker could use this behavior to ask the server true or false questions. This kind of injection is a more tedious method than the classic one but it can be easily automatized (it is based on a very simple binary logic) and allows to extract the same information. • AND Blind LDAP Injection: Suppose a query to list all the Epson printers available in a shop in a system where LDAP message errors are filtered: (& (objectClass=printer)(type=Epson*)) With this query, if there is some Epson printer available, a printer icon is shown to the client, else, no icon is shown. If the attacker wants to use a blind LDAP injection technique, he can inject code to construct the following query: (& (objectClass=*)(objectClass=*))(& (objectClass=void)(type=Epson*)) Examining this query, the *)(objectClass=*))(& (object- Class=void structure has been injected in the original query. LDAP only processes the first complete filter structure, then, only the query (& (objectClass=*)(objectClass=*)) is pro- cessed. As a result, the printer icon must be shown to the client, because this query always obtains results: the filter objectClass=* always returns some object (true result). From this point, it is easy to use blind injection techniques. The following injections can be constructed: (& (objectClass=*)(objectClass=users))(& (objectClass=foo)(type=Epson*)) (& (objectClass=*)(objectClass=logins))(& (objectClass=foo)(type=Epson*)) (& (objectClass=*)(objectClass=passwd))(& (objectClass=foo)(type=Epson*)) (& (objectClass=*)(objectClass=resources))(& (objectClass=foo)(type=Epson*)) This set of queries allows the attacker to infer the different objectClass values possible in the LDAP tree. When a query returns the printer icon, the objectClass exists (true results), and when the query does not obtain the icon as a result, the objectClass does not exist in the tree (false results). But there is a more efficient way to ask to the LDAP server using an alphabetic search: (& (objectClass=*)(objectClass=a*))(& (objectClass=foo)(type=Epson*)) (& (objectClass=*)(objectClass=b*))(& (objectClass=foo)(type=Epson*)) (& (objectClass=*)(objectClass=c*))(& (objectClass=foo)(type=Epson*)) ..... (& (objectClass=*)(objectClass=z*))(& (objectClass=foo)(type=Epson*)) With these queries, the first characters of the different object- Class values are found. Then, the attacker can continue with the second characters, with the third, etc to find the complete objectClass values names. For example: (& (objectClass=*)(objectClass=aa*))(& (objectClass=foo)(type=Epson*)) (& (objectClass=*)(objectClass=ab*))(& (objectClass=foo)(type=Epson*)) (& (objectClass=*)(objectClass=ac*))(& (objectClass=foo)(type=Epson*)) This mechanism is one kind of booleanization (based on true and false questions) and it is usually called character displaying. It is summarized in figure 1 and can be applied in many different ways. For example, once the attacker knows that users is a valid objectClass for the LDAP tree, he can infer all the users names: (& (objectClass=users)(objectClass=a*))(& (objectClass=foo)(type=Epson*)) (& (objectClass=users)(objectClass=b*))(& (objectClass=foo)(type=Epson*)) (& (objectClass=users)(objectClass=c*))(& (objectClass=foo)(type=Epson*)) And so on. Therefore, even when the error messages from the LDAP server are filtered, the attacker can extract information from the LDAP tres using blind injection techniques.
  4. 4. TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 4 Fig. 1. Blind LDAP injection booleanization mechanism: character displaying Fig. 2. Login page with a LDAP injection vulnerability • OR LDAP Injection: In this case, the logic used to infer the desired information is the opposite, due to the presence of the OR operator. Following with the Epson printers example, the injection in an OR environment should be: (| (objectClass=void)(objectClass=void))(& (objectClass=void)(type=Epson*)) This query obtains a false result from the LDAP server, there- fore, the printer icon is not shown to the client. And any result different from this would be the true result. The queries constructed to extract the LDAP tree information are the following: (| (objectClass=void)(objectClass=users))(& (objectClass=void)(type=Epson*)) (| (objectClass=void)(objectClass=passwd))(& (objectClass=void)(type=Epson*)) (| (objectClass=void)(objectClass=resources))(& (objectClass=void)(type=Epson*)) And the techniques explained in the AND environment using the character displaying mechanism (with the asterisk operator) can be used again to extract all the LDAP tree information. V. EXPLOITATION EXAMPLES In this section, a real LDAP environment has been implemented to exemplify the use of the injection techniques explained in the previ- ous section. And even more, the possible effects of the exploitation of these vulnerabilities are presented to show the important impact of these attacks in systems security. A. Classic Injection Techniques 1) Example 1 - Avoiding Access Control: A login page has two text box fields for entering user name and password (figure 2). Let Uname and Pwd represent the strings contained in text boxes, therefore, the two client inputs. To verify the existence of the user/password pair supplied by a client, a LDAP query is constructed and sent to the LDAP server: Fig. 3. Home page shown to the attacker after avoiding the access control (& (USER=Uname)(PASSWORD=Pwd)) This is an AND LDAP injection case, therefore, if an attacker enters a valid user name, for example, slisberger, and injects the appropriate sequence following this name, the password supplying can be avoided. Making Uname=slisberger)(&)) and introducing some string, no matter what, as the Pwd value, the following query is constructed and sent to the server: (& (USER=slisberger)(&))(PASSWORD=Pwd)) Only the first complete filter structure is processed by the LDAP server, then, only the query (& (USER=slisberger)(&)) is processed. And this query is always true, so the attacker gains the access to the system without having a valid password (3). 2) Example 2 - Avoiding Privileges Management: In this example, an attacker with low security level avoids the system privileges management gaining access to documents only available for users with high privileges. To perform this attack, the environment is again an AND LDAP injection case (figure 4), because the normal query used to obtain the documents available for a certain user is: (& (path=Documents)(level=LVL)) Where LV L denotes the privileges of the user. If the attacker has low level privileges, the query is: (& (path=Documents)(level=low)) But injecting the sequence Documents)(level=high)) as the value of the path field, a user with low level privileges will have access to the high level documents, because the following query is constructed: (& (path=Documents)(level=high))(level=low)) Only the first complete filter is processed by the LDAP server, therefore, the obtained result is the one shown in figure 5. 3) Example 3 - Avoiding Resources Management: Suppose that there is a Resource Explorer to allow users to know the resources available in the system (printers, scanners, storage systems, etc). This
  5. 5. TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 5 Fig. 4. Documents available for a user with low privileges Fig. 5. Documents available for the attacker after avoiding the privileges management Fig. 6. Resources available for the user from the Resource Explorer is a typical OR LDAP injection case, because the query used to show the available resources is: (| (objectclass=Rsc1)(objectclass=Rsc2)) Where Rsc1 and Rsc2 represent the different kinds of resources in the system. In figure 6, Rsc1=printer and Rsc2=scanner to show all the available printers and scanners in the system. If the attacker makes Rsc1=printer)(uid=*)), the following query is sent to the server: (| (objectclass=printer)(uid=*))(objectclass=scanner)) Only the first correct filter is processed in the server. And as a result, all the system users uid’s are shown to the attacker (figure 7). This information can be very dangerous, for example, to use it in attacks similar to the one performed in the Example 1 to avoid access control. Fig. 7. Information available for the attacker after the LDAP injection Fig. 8. Attributes defined for the objectclass printer Fig. 9. Normal behavior of the application B. Blind Injection Techniques 1) Example 1 - Extracting LDAP Tree Information: In this ex- ample the page printerstatus.php receives a parameter idprinter to construct this query: ( & (idprinter=Value1)(objectclass=printer)) If the attributes defined for the objectclass printer are shown in figure 8, the result of this query is shown in figure 9 for V alue1 = HPLaserJet2100. But Blind LDAP injection techniques can be used to obtain forbidden information from the LDAP tree. For example, an attributes discovering can be performed making these code injections: ( & (idprinter=HPLaserJet2100)(ipaddress=*)) (objectclass=printer)) ( & (idprinter=HPLaserJet2100)(distinguishedname=*)) (objectclass=printer)) ( & (idprinter=HPLaserJet2100)(department=*)) (objectclass=printer)) Obviously, the attacker can infer from the obtained results which attributes exist and which not. Only the first complete LDAP filter is processed in the server, therefore in the first case, the information about the printer is not given by the application because the attribute ipaddress does not exist (it is a false query). But in the second and third cases, the results of the query are normal, therefore, the attributes distinguishedname and department exist (they are true queries).
  6. 6. TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 6 Fig. 10. Asking if the character ’b’ is in the department name Fig. 11. Asking if the character ’n’ is in the department name Furthermore, with Blind LDAP injection techniques, the values of some of these attributes can be obtained. For example, suppose that the attacker wants to know the value of the department attribute. Then, he can use booleanization mechanisms such as character displaying or charset reduction to infer it. Using the character displaying techniques, the process would be the following, taking advantage of the possibility of asking false and true questions to the server : ( & (idprinter=HPLaserJet2100)(department=a*)) (objectclass=printer)) ..... ( & (idprinter=HPLaserJet2100)(department=f*)) (objectclass=printer)) ( & (idprinter=HPLaserJet2100)(department=fa*)) (objectclass=printer)) ...... ( & (idprinter=HPLaserJet2100)(department=fi*)) (objectclass=printer)) The first test with the first character does not obtain the printer information, therefore, the first character is not an ’a’. Testing with the rest of characters, the only one that obtains a normal behavior from the application is the ’f’ (true). Remember from figure 8 that the deparment value in this example is finantial. Following with the second character, the only one that obtains the normal operation is ’i’. And, using this process reiteratively, the complete name of the department value can be obtained. On the other hand, if the charset reduction technique is used, the following injections are constructed: ..... ( & (idprinter=HPLaserJet2100)(department=*b*)) (objectclass=printer)) .... ( & (idprinter=HPLaserJet2100)(department=*n*)) (objectclass=printer)) With this kind of technique, the set of characters composing the department name can be obtained, and, after that, only the correct characters order must be inferred. Figure 10 shows the results when the character ’b’ is tested: no results are sent from the server because the query has a false result. But in figure 11 a normal result is shown, meaning that the ’n’ character is in the department name. Again following with this process, the value for this attribute can be obtained by the attacker. VI. SECURING APPLICATIONS AGAINST LDAP INJECTION The attacks presented in the previous sections are performed on the application level, therefore, normal firewall and intrusion detection mechanisms at network layer have no effects on preventing all these injections. But the general security recommendations for LDAP trees can help to avoid these vulnerabilities or to minimize their impact: minimum exposition point and minimum privileges. The use of LDAP-s and IPSec protocols is recommended too. On the other hand, the mechanisms used to prevent the well known SQL injection techniques include defensive programming, sophisticated input validation, dynamic checks and static source code analysis. Therefore, the work on mitigating LDAP injections may involve similar techniques adapted to this protocol. It has been demonstrated in the previous sections that LDAP injection attacks are performed including special characters in the parameters sent from the client to the server. Then, it is clear that it is very important to filter the variables used to construct the LDAP queries before sending them to the server. As a conclusion the parenthesis, asterisks, logical (AND, OR and NOT) and relational (≤, ≥, , =) operators should be filtered on the client side to obtain a proper system operation. Furthermore, the values used to construct the LDAP queries should be offered to the client in a list of options to avoid malicious manipulations. If this is not possible because the set of possible values for some client input is too numerous or complex, a type check should be performed as a minimum verification. And, of course, the AND and OR constructions should be avoided in the normal queries to limit the injection possibilities, because all the injection attacks are based on these logical operators. VII. CONCLUSIONS AND FUTURE WORK LDAP services facilitate access to networks information organizing it in a hierarchical database that allows authorized users and applica- tions to find information related to people, resources and applications. This protocol is simple to install, maintain, replicate and use, and it can be highly distributed. And it allows an easy implementation of the widely used single sign-on environments. Therefore, given the increasing need for information in current systems, it is an essential service in almost all networks. LDAP injection techniques are an important threat for these environments, specially, for the control access and privileges and resources management. These attacks modify the correct LDAP queries, altering their behavior for the attacker benefit. And the consequences of these attacks can be very severe. Our work is unique in providing a rigorous analysis of LDAP injection techniques and in showing representative examples of the possible effects of these attacks. Even more, recommendations to secure applications against these techniques have been proposed. It has been showed that filtering the error messages produced by the server only fortifies the system but does not secure it against blind injection techniques. A more in depth
  7. 7. TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 7 protection is needed to avoid this kind of injection vulnerabilities too. It has been demonstrated with the presented examples, that it is essential to filter the client inputs used to construct the LDAP queries before sending them to the server. And that the AND and OR filter constructions should be avoided. Finally, a very interesting line for future research is working on analyzing injection techniques with other protocols used to access databases and directories. And to study the possible utilization of mechanisms booleanization techniques such as character displaying or charset reduction in other environments. REFERENCES [1] S. Barnum and G. McGraw, “Knowledge for software security,” IEEE Security and Privacy Magazine, vol. 3(2), pp. 74–78, 2005. [2] E. Bertino, A. Kamra, and J. Early, “Profiling database application to detect SQL injection attacks,” in Proceedings of the IEEE International Performance, Computing, and Communications Conference, 2007, pp. 449–458. [3] X. Fug, X. Lu, B. Peltsverger, S. Chen, K. Qian, and L. Tao, “A static analysis framework for detecting SQL injection vulnerabilities,” in Proceedings of the 31st Annual International Computer Software and Applications Conference, 2007, pp. 87–96. [4] E. Merlo, D. Letarte, and G. Antoniol, “SQL-injection security evolution analysis in PHP,” in Proceedings of the 9th IEEE International Workshop on Web Site Evolution, 2007, pp. 45–49. [5] S. Thomas and L. Williams, “Using automated fix generation to secure SQL statements,” in Proceedings of the 3rd International Workshop on Software Engineering for Secure Systems, 2007, pp. 9–19. [6] “XPath 1.0 specification,” 1999, [7] “XPath 2.0 specification,” 2007, [8] “RFC 1777: Lightweight Directory Access Protocol v2,” 1995, [9] “RFC 2251: Lightweight Directory Access Protocol v3,” 1997, [10] T. Holz, S. Marechal, and F. Raynal, “New threats and attacks on the world wide web,” IEEE Security and Privacy Magazine, vol. 4(2), 2006. [11] G. Hermosillo, R. Gomez, L. Seinturier, and L. Duchien, “AProSec: an aspect for programming secure web applications,” in Proceedings of the Second International Conference on Availability, Reliability and Security, 2007, pp. 1026–1033. [12] N. Jovanovic, C. Kruegel, and E. Kirda, “Pixy: a static analysis tool for detecting web application vulnerabilities,” in Proceedings of the IEEE Symposium on Security and Privacy, 2006, pp. 6–15. [13] E. Jamhour, “Distributed security management using LDAP directories,” in Proceedings of the XXI Internatinal Conference of the Chilean Computer Science Society, 2001, pp. 144–153. [14] R. Sari and S. Hidayat, “Integrating web server applications with LDAP authentication: Case study on human resources information system of ui,” in Proceedings of the International Symposium on Communications and Information Technologies, 2006, pp. 307–312. [15] M. Wahl, T. Howes, and S. Kille, “Lightweight Directory Access Protocol (v3),” 1997, [16] V. Koutsonikola and A. Vakali, “LDAP: framework, practices, and trends,” IEEE Internet Computing, vol. 8(5), pp. 66–72, 2004. [17] M. Russinovich and D. Solomon, Microsoft Windows Internals. Mi- crosoft Press, 2004. [18] “OpenLDAP main page,” [19] N. Klasen, “Directory services for Linux, in comparison with Novell NDS and Microsoft Active Directory,” 2001, master Thesis, Aachen University.