Categories
- General (22)
- Talking (10)
- Thinking (58)
- Apple (2)
- Browsers (4)
- Business (16)
- Databases (6)
- MySQL (3)
- SQL Server (1)
- Design (3)
- E-commerce (3)
- Marketing (2)
- Mobile (1)
- Networking (2)
- Programming (30)
- ColdFusion (24)
- Java (1)
- Javascript (6)
- PHP (6)
- Ruby (1)
- Web 2.0 (3)
- Web Servers (3)
- IIS (3)
- Windows (11)
- Walking (1)
Archives
- July 2010 (1)
- June 2010 (1)
- March 2010 (1)
- February 2010 (1)
- January 2010 (13)
- December 2009 (3)
- July 2009 (2)
- June 2009 (1)
- May 2009 (1)
- April 2009 (8)
- March 2009 (6)
- February 2009 (15)
- January 2009 (4)
- December 2008 (3)
- November 2008 (2)
- September 2008 (2)
- August 2008 (2)
- November 2007 (2)
- September 2007 (1)
- April 2007 (5)
Preventing SQL Injection attacks in ColdFusion
This is an article I came across on Ben Forta’s blog. This gives some very good tips on preventing SQL injection attacks and provides some excellent best practices.
When I took up my current position we had to do a vulnerability scan to become PCI compliant and well we originally failed horribly. After much work we got it compliant and fixed all of the security holes identified. The article above gives some ColdFusion specific items but also defines some techniques that can be applied to other languages. A few things that are of note are:
These three points are usually overlooked by the average developer and should really be implemented.
Database User Access:
Only give the user the minimum rights required to perform the task. So if your user only needs to perform select and update operations they should not have delete, create or other rights.
Stored Procedures:
Stored procedures provide a very good way to abstract and hide database logic from your code. This is a problem with many of the frameworks that use Active Record patterns like Rails and CakePHP or ORM systems like Reactor in ColdFusion but stored procedures can provide significant performance improvements as well as having security benefits.
Dynamic Table Names:
By prefixing your database tables with a custom string, you can build queries that use a dynamic string for accessing the table information instead of hardcoding the table name. This is another good idea since many systems use generic table names like users, categories, groups etc which can be easily guessed.
It is very important to analyse every section of code and perform a security audit ensuring that all forms are protected since this is the first place that attackers target.
Related Posts