Recent Articles |
CLR Vs T-SQL And Stored Procedures In SQL Server 2005
CLR or TSQL? That is the question. More are more developers are struggling to find the right answer, but the answer really depends on the developer's individual needs. For classic SQL tasks, the good old TSQL is recommended. On the other hand, CLR works best for calculations, parsing, image processing and...
MySQL Gets Telecom-Specific
Due to demand, MySQL AB announced the expansion of its telecom-specific services and consulting for MySQL software. Specifically, the company is promoting its MySQL Cluster, a high-end version of the standard database designed for fault-tolerant...
Practice Makes Perfect For SQL
MySQL guru Sheeri Kritzer listed eight SQL best practices for database professionals who are hard at work on their projects. Kritzer's list began with a preface on why she tries to live by the eight SQL rules in her post about best practices:
Ingres Christens Project Icebreaker
The open source database company Ingres teamed with another open source player to deliver Icebreaker, a way to place database services on a server with no operating system required. Ingres CTO Dave Dargo blogged about Icebreaker, which launched recently during the LinuxWorld Conference and Expo. Dargo explained...
MySQL Turbo Manager And Dream Coder
The success and the longevity of any prominent business nowadays depend on powerful application infrastructures and effective, reliable management and development solutions. In present, a wide range of IT companies are striving to provide business owners...
|
|
 |
|
10.24.06
Malicious Code Injection: Not Just For SQL Anymore
 By Bryan Sullivan
More and more, developers are becoming aware of the threats posed by malicious code, and SQL injection in particular, and by leaving code vulnerable to such attacks.
However, while SQL is the most popular type of code injection attack, there are several others that can be just as dangerous to your applications and your data, including LDAP injection and XPath injection. While these may not be as well-known to developers, they are already in the hands of hackers, and they should be of concern.
In addition, much of the common wisdom concerning remediation of malicious code injection attacks is inadequate or inaccurate. Following these flawed recommendations will not improve the security of your application, but will only leave you with a false sense of security until the next time your application is compromised and your data is stolen, erased, or tampered with. It is important for developers to acquaint themselves with all code injection types that exist as well as the proper ways to fix any vulnerabilities to malicious code.
The Basic Premise of All Code Injection Types
Many people mistakenly think that they are safe from malicious code injection attacks because they have firewalls or SSL encryption. However, while a firewall can protect you from network level attacks, and while SSL encryption can protect you from an outside user intercepting data between two points, neither of these options offers any real protection from code injection attacks. All code injection attacks work on the same principle: a hacker piggybacks malicious code onto good code through an input field in the application. Therefore, the protection instead has to come from the code within the application itself.
There are many motives that hackers using malicious code injection attacks may have. They may wish to access a website or database that was intended only for a certain set of users. They may also wish to access a database in order to steal such sensitive information as social security numbers and credit cards. Other hackers may wish to tamper with a database - lowering prices, for example, so they can steal items from an e-commerce site with ease. And once an attacker has gained access to a database by using malicious code, he may even be able to delete it completely, causing chaos for the business that has been attacked.
The root of all code injection problems is that developers put too much trust into the users of applications. A developer should never trust the user to operate the application in a safe manner. There will always be someone who is looking to use malicious code in an exploitative manner.
Looking Beyond SQL Injections
Aside from SQL injections, there are several other types of malicious code injection attacks with which developers must become familiar. Three of these types of dangerous malicious code injections are XPath injection, LDAP injection, and command execution injection.
An XPath injection attack is similar to an SQL injection attack, but its target is an XML document rather than an SQL database. The attacker inputs a string of malicious code meant to trick the application into providing access to protected information. If your website uses an XML (Extensible Markup Language) document to store data and user input is included in an XPath query against that document, you may be vulnerable to an XPath injection.
Click here to resume this article
About the Author:
Bryan Sullivan is a development manager at SPI Dynamics, a Web application security products company. Bryan manages the DevInspect and QAInspect Web security products, which help programmers maintain application security throughout the development and testing process.
|
