The SQL Injection Attacking Prevention Applying the Design Techniques

The SQL Injection Attacking Prevention Applying the Design Techniques of IPTABLES Faculty of Informatics, Mahasarakham University, Thailand, preecha.n@msu.ac.th Abstract This study presents the SQL Injection Prevention using the design techniques of IPTABLES. It applied the IPTABLES s special feature that is able to investigate the application layers to detect and drop the packets that contains SQL patterns ( e.g. ' or '1'=' ). Besides, the study suggests the methods for designing the IPTABLES rule without a confliction or that has least possibility of confliction between the rules. The researcher presents how to adjust IPTABLES to filter the SQL Injection packets more rapidly by applying the concept of relation and Cartesian product into designing the rule and using the rule repositioning method. The researcher has also collected various patterns that used to be attacked with SQL Injection, from different reliable sources, to find out the common signatures. Then these patterns were concluded to be about 10 patterns only so that they would function with least overhead. In addition, the researcher has run the performance testing and found that the response time has been slightly increased, while the possibility of false positive appeared at an acceptable rate. Keywords: Web Security, Database Security, Sql Injection, Hack, Firewall, IPTABLES 1. Introduction Attacking with SQL Injection is popularly used amongst the hackers and even the university students who are knowledgeable in either computer software or information technology since SQL Injection is an approach launched to attack web server and database without any tools required. It can be launched immediately on a browser and give a sudden result. In this regard, an organization "Open Web Application Security Project" (OWASP) [1] has ranked a top 10 web server attacking and named SQL Injection as a first attacking approach that has fluently found and mostly harmful. (based on the information provided in "OWASP Top 10 for 2010"). The samples of the most harmful incidents caused by the SQL Injection are as follows. - July 2012: 450,000 accounts of Yahoo mail has been hacked for their usernames and passwords. - June 2012: the passwords and credit card database of a million customers of SONY have been hacked. - March 2011: a webpage of mysql.com, the MySQL database maker, has been hacked and changed by a hacker. Apparently, the above mentioned websites has been attacked with the SQL Injection [2], so people should be more aware of the SQL Injection attacking. The best solution is educating the web programmers with more information about how to write a web code with strong security and encouraging them to focus more on testing the web security i.e. penetration testing, Black-Box testing, and White-Box testing, as well as web application hardening. However, the prevention by web application hardening requires a high cost and takes very much time. Thus, purchasing the tools as Web Application Firewall (WAF) that can prevent the SQL Injection could be another way out. The examples of these WAF are Cisco IPS [3], Barracuda [4], etc. Still, these tools are expensive and difficult for being updated to handle the new attacking approaches. For these reasons, the researcher tries to seek out a proper solution with low cost but still contains a strong security and able to effectively prevent any kinds of attacking. Journal of Convergence Information Technology(JCIT) Volume 7, Number 22, Dec 2012 doi : 10.4156/jcit.vol7.issue22.9 66

2. Background and Related Works The SQL Injection attacking can be launched by entering the SQL command in a login browser or searching browser. (or entering the command directly in an address bar browser), for example entering ' or '1'=' or ' or ''='. After these strings have been sent to web server, they would be merged with the SQL command on a server s side and its logical outcome would be true e.g. SELECT * FROM users WHERE name = '' OR '1'='1'. Through this method, a hacker will be able to bypass the authentication system; the skillful hacker will adjust the SQL Injection s strings to allow himself to log into the system as the administrator, in which he can either edit or steal the important information from the website. A number of researches have been conducted on the SQL Injection attacking. For examples, G N V Prasad and V. Siva Parvathi [5] suggested how to prevent the SQL Injection by adjusting the web application code with the command "mysql_real_escape_string()", but this method only worked on some platforms since some platforms did not have that kind of command. Meanwhile, Theodoor Scholte et al. [6] had studied on detecting the XSS:Cross Site Scripting and SQL Injection but mentioned nothing about the useful preventions. Indrani & E. Ramaraj [7] proposed the frame work to prevent the SQL Injection by designing and equipping it with X-log Generator, X-log Authentication and Vulnerability Guard but still had a problem since the software needs to be installed on a dedicated computer and placed on the route between a client and a server. Khwairakpam Amitab et al. [8] presented how to detect the SQL Injection using Chi-square test but suggested nothing about the solutions. Perumalsamy Ramasamy et al [9] suggested the prevention technique by inserting a code on the web application and on all servers. Meanwhile, K. Ahmad [10] suggested the prevention technique by writing a special application to be installed on a dedicated computer and put between the web server and database server. Overall, this method functioned with high speed because the preventer was not put between the web server and internet. However, with this method, to detect the SQL Injection would be more difficult than those that were put in the front of the web server. 3. Designing Since the SQL Injection is an attacking on an application layer, i.e. Layer-7 of OSI Reference Model, with a special string e.g. ' or '1'='1. Typically, a route of the attacking packets will begin from the outside (from the internet) and go straight into Demilitarized Zone (DMZ) where the web servers located. Sometimes, the attacking packets may come from an internal network caused by either a local user or guest who intended to attack the internal web server. After all, the attacking packets will travel through the firewall so the preventer is purposively located at the same point as the firewalls. 3.1 Designing as the Application-Layer Filter The regular firewall will filter the packets at Layer-3 and Layer-4 of OSI Reference Model, whereas the SQL Injection attacking happens at Layer-7. The researcher is willed to study on and seeks out the proper solution and has found that IPTABLES is the suitable firewall to take this mission, since it is able to detect the packets at Layer-7 with a parameter "-m string" and "--string". Additionally, IPTABLES is an open source and free software that is cheap and easy to be implemented. Example: the rule used in preventing the SQL Injection. iptables -A FORWARD -s 0.0.0.0/0 -m string --string %27+or+%271%27%3d%271 -j DROP From the example, it can be seen that no matter source that they have been launched from (-s 0.0.0.0/0), the packets will be detected if there is "%27+or+%271%27%3d%271" contained in the strings content. If the mentioned exists, that packet will be dropped immediately. Note: "%27+or+%271%27%3d%271" is an URL encoding that can be decoded as ' or '1'=1, a sample of the SQL Injection attacking patterns. 67

3.2 Designing to Decrease the Rule Confliction and Increase the Detecting Speed. The sample patterns of the SQL Injection attacking are presented as below. ' -- ' or '1'='1 ' or ''=' These patterns are separately defined on each line of the IPTABLES rule; meanwhile the servers that located in Demilitarized Zone (DMZ) also include not only the web servers, but also other related servers e.g. mail servers or DNS servers. Thus, besides the IPTABLES rule, there are more rules required for preventing the different servers. These also include the rules to prevent the attacking launched on the internal user s IP Address. In particular, inside the IPTABLES requires the rule that allow only the internal user with some port number to connect to the internet. Based on a study on the firewall rule designing (including IPTABLES), the researcher notices that the firewall rule designing may cause some confliction between the rules; the kinds of confliction may vary. Particularly, the rule conflictions needed to be aware of include Shadowing Anomaly, Correlation Anomaly, and Redundancy Anomaly. Shadow Anomaly is a confliction that exists because there is the rule that hides and does not allow the packets to match with the next rules below. The example of this confliction is present as follows. Rule-1: iptables -A FORWARD -d 200.1.1.0/24 -dport 80 -j ACCEPT Rule-2: iptables -A FORWARD -d 200.1.1.5 -dport 80 -m string --string %27+or+%271%27%3d%271 -j DROP From the example, Rule-2 is hidden by Rule-1 in which no packets can match with Rule-2. Indeed, Rule-2 refers to the SQL Injection prevention that protects the server with IP address: 200.1.1.5; therefore, if Rule-2 is hidden by Rule-1, the prevention will not be processed. Correlation Anomaly is a confliction existing since the two rules take different actions and partly are overlapped. If the firewall administrators swap the positions of these two rules, the packet decision (to accept or to drop the packet) will be changed as follows. Rule-3: iptables -A FORWARD -s 10.10.10.99 -d 200.1.1.0/24 -dport 80 -j ACCEPT Rule-4: iptables -A FORWARD -s 10.10.10.0/24 -d 200.1.1.5 -dport 80 -m string -- string %27+or+%271%27%3d%271 -j DROP From the example, Rule-3 and Rule-4 have been swapped and the decision on the packet with Source IP = 10.10.10.99 and Destination IP = 200.1.1.5 will be mistakenly changed from "to be accepted" to "to be dropped" Redundancy Anomaly is the redundant rule. It means that the previous rules redundant with the latter rules as follows. Rule-5: iptables -A FORWARD -s 10.10.10.0/24 -d 200.1.1.5 -dport 80 -m string --string %27+or+%271%27%3d%271 -j DROP Rule-6: iptables -A FORWARD -s 0.0.0.0/0 -d 200.1.1.5 -dport 80 -m string --string %27+or+%271%27%3d%271 -j DROP As apparently seen, the packets that match Rule-5 also match Rule-6 (noticed from that 10.10.10.0/24 is a subset of 0.0.0.0/0). In fact, despite without Rule-5, the firewall still works on with the same policy. Therefore, Rule-5 becomes an unnecessary redundancy and as it is redundant with Rule-6; consequently, Rule-5 should be deleted. To decrease the possibility of the mentioned confliction, the researcher has designed the rule using Destination IP at the 1st priority and Destination Port at the 2nd priority. The Source IP will be the 3rd priority as presented in Table 1. 68

Table 1. The structure of firewall rule to decrease the rule confliction Destination IP Destination Port Source IP Action Server 1 Server 2 Server 2 Server N User DROP all packets The design in Table 1 has it benefit in which Shadowing Anomaly and Redundancy Anomaly do not exist (or in lower rate); meanwhile, the possibility of Correlation Anomaly is at a lower rate. In this regard, the condition DROP all packets must be the last in order. It s possible to prove that Shadow Anomaly did not really exist by using the following equation. The packet meant to match with any rules must be resulted from this Cartesian product. [Destination IP's range] X [Destination Port's range] X [Source IP's range] Note: an X symbolizes a Cartesian product operation. To make it more understandable, the researcher demonstrates the rule as follows. iptables -A --dst-range 200.1.1.3-200.1.1.4 --dport 21:22 --src-range 200.1.1.91-200.1.1.93 -j DROP This rule contains its matching packets including the following 12 packets. 1. DestinationIP=200.1.1.3, DestinationPort=21, SourceIP=200.1.1.91 2. DestinationIP=200.1.1.3, DestinationPort=21, SourceIP=200.1.1.92 3. DestinationIP=200.1.1.3, DestinationPort=21, SourceIP=200.1.1.93 4. DestinationIP=200.1.1.3, DestinationPort=22, SourceIP=200.1.1.91 5. DestinationIP=200.1.1.3, DestinationPort=22, SourceIP=200.1.1.92 6. DestinationIP=200.1.1.3, DestinationPort=22, SourceIP=200.1.1.93 7. DestinationIP=200.1.1.4, DestinationPort=21, SourceIP=200.1.1.91 8. DestinationIP=200.1.1.4, DestinationPort=21, SourceIP=200.1.1.92 9. DestinationIP=200.1.1.4, DestinationPort=21, SourceIP=200.1.1.93 10. DestinationIP=200.1.1.4, DestinationPort=22, SourceIP=200.1.1.91 11. DestinationIP=200.1.1.4, DestinationPort=22, SourceIP=200.1.1.92 12. DestinationIP=200.1.1.4, DestinationPort=22, SourceIP=200.1.1.93 Running the Cartesian product results as "Relation" (Relation is subset of Cartesian product of domain); therefore, every single rule on the rule list has its own matching packets. The packet matching with any rule will be a member within the relation resulted from the Cartesian product running on that rule. Indeed, the rule can be mapped to relation by calculating the numbers in each column (e.g. Destination IP, Destination Port, and Source IP, with Action excluded) and running a Cartesian 69

product. For example, Rule-1 can be mapped to R1, and Rule-n is mapped to Rn. Based on the analysis, the packets that have arrived at the firewall will firstly match with Rule-1 before Rule-2, so the packets reaching Rule-2 will be a member of R2 R1. Similarly, the packets reaching Rule-n become a member of R(n) - R(n-1)-...-R2-R1. From this model, the existence of Anomaly can be explained as follows. - Shadow Anomaly exists from R(n)-R(n-1)-...-R2-R1, which is an empty set. - Correlation Anomaly exists when R(i) intersecting with R(i+1), not an empty set, and rule-(i) and rule-(i+1) take different actions (The rule swapping will causes a change in the policy) - Redundancy Anomaly exists when R(i) is a subset of R(i+1) and rule-(i) and rule-(i+1) take the same action. The rule structure in Table 1 can be presented as the Rule List with the string's condition that needs to be filtered to prevent the SQL Injection. The result is illustrated in Table 2 but these are only rough formats, not the IPTABLES formats. Table 2. The firewall rules which ready to be implemented as the IPTABLES rule Role-No Destination IP Destination Port Source IP Filter Action 1 WebServer 0-21 Any DROP 2 WebServer 22 Admin ACCEPT 3 WebServer 22! Admin DROP 4 WebServer 23-79 Any DROP 5 WebServer 80 Any -- DROP 6 WebServer 80 Any or '1'='1 DROP 7 WebServer 80 Any or ''=' DROP 8 WebServer 80 Any ACCEPT 9 WebServer 81-65535 Any DROP 10 MailServer 0-21 Any DROP 11 MailServer 22 Admin ACCEPT 12 MailServer 22! Admin DROP 13 MailServer 23-24 Any DROP 14 MailServer 25 Any ACCEPT 15 MailServer 26-142 Any DROP 16 MailServer 143 Internal-IP ACCEPT 17 MailServer 143! Internal-IP DROP 18 MailServer 144-65535 Any DROP 19 Remote-User-IP 22 Any ACCEPT 20 Any 80,443 Internal-IP ACCEPT 21 Any Any Admin ACCEPT 22 Any Any Any DROP From Table 2, if the researcher maps Rule-1 to relation (by running the Cartesian product on Destination IP, Destination Port, and Source IP), it will result as 22 rows of members. Thus, it means that there are 22 packets that match with Rul-1. In contrast, if mapping Rule-2 to relation, it will be found that there is only one packet that matches with Rule-2. When comparing R1 with R2 (R refers to relation resulted from the rule mapping), it was found that R1 intersecting with R2 resulted as an empty set. As a consequence, it can be concluded as follows. - Rule-2 cannot be Shadowed Rule since R2 R1 is not an empty set. - Rule-1 and Rule-2 cannot cause Correlation Anomaly since R1 intersecting with R2 result as an empty set. - Rule-1 is not redundant to Rule-2 because R1 is not a subset of R2. Making each rule dependent (the rule intersection gives an empty set) or namely if R1, R2,, Rn do not overlap one another, the existence of the anomaly within the rule set will be impossible. 70

From Table 1, it can be seen that Server1, Server2, ServerN, and Users are the IP addresses or a group of IP address that do not overlap one another. Therefore, although these IP addresses take the Cartesian product with any values in the columns i.e. Destination Port and Source IP, they will not cause the overlapped relations. Theorem: If D1 (Domain1) intersecting with D2 (Domain2) results as an empty set, (D1 X E1 X F1) intersecting with D2 X E2 X F2) also results as an empty set. (Note: E1, E2, F1, and F2 are sample Domains) Similar to designing Server1, Server2, ServerN, and Users as the IP address or a group of IP address that do not overlap one another, the researcher applies the same method with the values in Destination Port and Source Port columns, as presented below (See Table 1 and Table 2). In a final stage, the researcher implemented the same rule in Table 2 as the IPTABLES rule. The result is revealed as shown in Figure 3. Figure 3. Sample of the IPTABLES rule that filter the SQL Injection with the least confliction Note: The presented IPTABLES rule does not include other initializing commands e.g. iptables -F, iptables -P INPUT DROP, and other required commands including NAT (Network Address Translation). Nevertheless, the researcher has designed the last rule to cover all the packets in order to create a 100% packet protection that does not allow the packets to mistakenly be dropped. 4. Rule Development Table 3. the attacking patterns of the SQL Injection SQL Injection Common signatures SQL Injection Common signatures patterns patterns (cont.) ' or 0=0 -- ' or 1 --'" ' or -- or "a"="a or "x"="x or " "=" ' -- ' or '1'='1'-- ' -- or ''=' or ' or 0=0 -- or 0=0 or 'x'='x '=' or 0=0 # -- or a"="a or a or "= or a=a-- ) or (a"="a ) or ( ;shutdown-- -- 71

) or ('a'='a admin'-- ) or ('x'='x hi' or 'a'='a ' or ' hi" or "a"="a " or 'hi' or 'x'='x'; '=' hi" -- hi") or ("a"="a ") or (" hi') or ('a'='a ') or (' or 0=0 -- or 0=0 # or 0=0 -- ' or select * ' or ''=' -- ' or or '1'=1' or ' The researcher has collected the packets used to be attacked by the SQL Injection from various security websites e.g. www.governmentsecurity.org, www.thisislegal.com, edeyehack.blogspot.com.au, www.n1tr0g3n.com, and www.neurofuzz.com, etc., and found that there are over 40 attacking patterns of the SQL Injection popularly used. After that, these collected patterns were grouped and examined for the matched sub-patterns (the matched sub-pattern is called the common signature) as presented in Table 3 Next, the researcher analyzed the common signatures to be put in the IPTABLES rule. These common signatures are shown in Table 4 (alphabetically ordered). Table 4. Common signature of the SQL Injection attacking Begin with space ( char(32) ) Not begin with space -- ) or ( ' or ') or (' ' or ' or ' " or ' or "=" or 0=0 ) or ( '=' or ' or " or 0=0 or a From an additional analysis, the researcher found that some common signatures are a subset of other common signatures as presented in Table 5. Subset ' or Table 5. The common signatures as a subset of another signature Superset ' or ' (begin with space) or 0=0 or 0=0 (begin with space) (begin with space) or ' or ' (begin with space) ) or ( ) or ( (begin with space) ') or (' Due to the data in Table 5, all 40 patterns can be reduced into only 10 main patterns. Besides, the data in Table 5 suggests that when needed to be practically implemented, the rule with the common signature as a subset of another signature must be in a prior order to the rule with the common signature as a superset, as the following examples. Rule-1: iptables -A FORWARD -m string --string ) or ( -j DROP Rule-2: iptables -A FORWARD -m string --string ') or ( -j DROP Otherwise, Shadow Anomaly will be exist. 72

Filtering the strings of the common signatures will result as an incorrect entry or false positive on the website uploaded with the source code in the computer language such as a packet with the source code inside e.g. if (a1=a2) or (b1=b2), then DoSomething() will be dropped by Rule-1; meanwhile, if (a1='string2') or (b1='string1'), then DoSomething() will be dropped by Rule-2. For the common data, number of false positives was very small. 5. Performance Testing and Analysis The researcher has run the test on the common signatures in Table 5 to find their performance. It was found that each common signature gave different outcomes in terms of the prevention and false positive, as follows. ) or ( gave false positive < 0.01% for common data and 3.42% for Source code in computer language ) or ( gave false positive < 0.01% for common data and 1.83% for Source code in computer language (this pattern begin with space or Char(32)) ') or ( gave false positive < 0.01% for common data and 0.41% for Source code in computer language However, it is possible to reduce the false positive by selecting an appropriate common signature e.g. do not use ) or ( while filtering the string of the IPTABLES rule. The test resulted as presented in Table 6. Common signature (SQL Injection pattern) ' or ' or ' (begin with space) or 0=0 or 0=0 (begin with space) (begin with space) or ' (begin with space) or ' ) or ( ) or ( (begin with space) ') or ( Table 6. Test Result False positive for common data False positive for Source code in computer languages 0.16 % 3.42 % 1.83 % 0.41 % Based on the analysis, it was found that the proposed model provides the benefits in three aspects including the functional speed, the security, and the ease of use and additional implementations. 5.1 Speed In designing each rule after mapped to relation that does not overlap one another, it is possible to move up the rule fluently matched by the packets to be on a prior order without causing the anomaly and changing the policy. Differently, the rule that rarely matched by the packets can be moved down to be on a latter order. From Figure 3, Rule-5, Rule-6, and Rule-7 are the SQL Injection prevention. When delicately considered (based on the strings needed to be filtered and taking the Cartesian product with the 3 mentioned columns), these three rules will be mapped to be an overlapped relations. Nevertheless, the repositioning amongst these rules will not cause the Correlation Anomaly because they take different actions. In trying out using the IPTABLES rule with filtering the common signature 73

(SQL Injection patterns), the researcher found that the response time between the client and server has been 3% increased. When testing on a regular computer with the CPU = Intel Core i5 2.4GHz, RAM=8GB, OS=CentOS5.3, to see the difference between a testing without any IPTABLES rue and that with the IPTABLES rule designed by the researcher, it was found that the response time has been increased because the computer that functions as the firewall needs to process the IPTABLES rule and detect the SQL Injection patterns. Still, if using the computer with a more rapid functional speed or with multi CPU, the response time might be decreased. 5.2 Security Practically, the researcher s designed model helps in reducing the possibility of Shadow Anomaly. If the firewall administrator creates a rule to prevent the SQL Injection attacking and put it in a suitable position, he can be sure that the rule entered into the IPTABLES will definitely be processed. In case that the firewall administrator has detected a new pattern of the SQL Injection attacking, he can insert the rule in a proper order e.g. inserting a newly created rule in a range before Rue-5 to those after Rule- 7, as seen appropriate, as shown in Figure 3. In this regard, it is necessary to be aware of the Shadow Anomaly possibly caused by the common signature of the previous rule. 5.3 Ease of Use The researcher s model provides the prevention for the SQL Injection attacking by creating the rule on the IPTABLES and suggesting how to create the rule without causing the anomaly (with a small number of the anomaly). If a user has studied well on anomaly and restrictively follows the researcher s guidance, he will notice that it is very easy to practically implement this SQL Injection prevention model. In addition to the three benefits previously mentioned, it is affirmed that the researcher s model practically helps reduce the cost in purchasing on the expensive additional prevention tools because it is the implementation on Linux. 6. Conclusion and Future works In this study, the researcher purposively presents the model and methods on the SQL Injection attacking prevention by applying the design techniques of the IPTABLES without the rule confliction or with a small number of conflictions. The researcher suggests the IPTABLES to be used in filtering the application-layer data in order to prevent the strings of the SQL Injection attacking. Besides, the researcher demonstrates how to put the rule in a suitable order to prevent Shadow, Correlation, and Redundancy Anomalies and to allow the rule on the SQL Injection attacking prevention line to be processed. Meanwhile, the IPTABLES rule processing will be done more rapidly since it is possible to move up the rules frequently matched with various packets to be on a prior order. Furthermore, a large number of the SQL Injection attacking patterns can be concluded into only 10 patterns so that it helps decreasing the burden on the firewall s CPU. The researcher has run the performance test and found that the response time between the client and server has been 3% increased when comparing between testing without the IPTABLES rule and that with the IPTABLES rule designed by the researcher. Technically, this increased response time could be decreased when the high-performance computer is used as the firewall. Also, the test has been run to find number of false positive and it indicates that the website uploaded with common data is faced with a small number of false positive; lower than 0.01%. In contrast, the website uploaded with the source code encounters a larger number of false positive depending on the SQL Injection attacking patterns. Fortunately, it is possible to reduce a number of false positive if a user applies the appropriate common signatures. 7. Reference [1] https://www.owasp.org/index.php/top_10_2010-a1-injection [2] http://en.wikipedia.org/wiki/sql_injection [3] Earl Carter, CCSP IPS Exam Certification Guide, Cisco Press, ISBN-10:1587201461, 2005. [4] Barracuda web application firewall-web application protection against hackers and vulnerabilities, 74

from http://www.barracudanetworks.com/ns/products/web-sitefirewall-overview.php, 2010. [5] G N V Prasad, V. Siva Parvathi, Signature Based Evaluation to Counter and Prevent Injection Attacks, Asian Journal Of Computer Science And Information Technology, Vol. 1, No. 3, pp.81 85, 2011. [6] Theodoor Scholte, Davide Balzarotti and Engin Kirda, Quo Vadis? A Study of the Evolution of Input Validation Vulnerabilities in Web Applications, In Proceedings of the International Conference on Financial Cryptography and Data Security, Saint Lucia, Vol. 7035, pp.284-298, 2012. [7] B. Indrani, E. Ramaraj, X-Log Authentication Technique to Prevent SQL Injection Attacks, International Journal of Information Technology and Knowledge Management, Vol. 4, No. 1, pp.323-328, 2011. [8] Khwairakpam Amitab, Padmavati, Comparison of SQL Injection Detection Techniques which uses Chi-Square Test, International Journal of Engineering Science & Technology, Vol. 3 No. 6, pp.4968-4972, 2011. [9] Perumalsamy Ramasamy, Sunitha Abburu, SQL Injection Attack Detection and Prevention, International Journal of Engineering Science and Technology (IJEST), Vol. 4, No. 4, pp.1396-1401, 2012. [10] K. Ahmad, J. Shekhar and K. P. Yadav, Coalesce Techniques to Secure Web Applications and Databases against SQL Injection Attacks, Electronic Journal of Computer Science and Information Technology (ejcsit), Vol. 3, No. 1, pp.26-39, 2011. 75