Webmonkey » Databases

XSS Vulnerabilities, Raw SQL Top List of Common Programming Errors

Scott Gilbertson — Wed, 24 Mar 2010 18:24:21 +0000

No programmer is perfect, but some mistakes are more dangerous than others. While some mistakes might just slow down your site, others can open up vulnerabilities that expose your code, your database and even your users to all manner of attack.

To help you identify the more serious errors common in programs of all types, a group of top software security experts in the US and Europe have released their Top 25 Most Dangerous Programming Errors.

Unsurprisingly, cross-site scripting vulnerabilities and improperly handled SQL top the list of common and dangerous mistakes. Remember kids, sanitize your database inputs; you just never know when someone is going to name their child: “Robert’) DROP TABLE Students;”

While not all the errors in the list are common in web programming, some of the more serious things are concerns for web developers — cross-site request forgeries, missing encryption of sensitive data and unrestricted file uploads are all common web programming issues.

Also interesting is the weaknesses by language section, which breaks down common mistakes in PHP, Java, Perl and C/C++. No doubt web developers would like to have seen Python and Ruby in that list, but it should at least be useful for PHP and Perl programmers.

See Also:

Data Binding

Webmonkey Staff — Mon, 15 Feb 2010 20:45:47 +0000

As a computer science term, data binding is the substitution of a real value in a program after it has been compiled.

For example, during compilation a compiler can assign symbolic addresses to certain variables or instructions. When the program is bound, or linked, the binder replaces the symbolic addresses with real machine addresses. The moment at which binding occurs is called “bind time” or “link time.” In dHTML, data binding allows the client to look into a database and retrieve the content. This data can be automatically displayed in your table using the HTML data binding extensions, or you can manipulate the data with a script.

SQL Basics: Four Reasons Never to Select All

Adam Duvander — Mon, 28 Jul 2008 06:05:27 +0000

Have you ever written a database call that went something like… select * from posts where id=3;? We probably all have, but it’s bad for several reasons. Four of them, according to a programmer that goes by pizza_milkshake.

To database administrators and advanced programmers, this may not come as news. Even many seasoned coders could use a reminder not to be lazy.

pizza_milkshake’s Four Reasons Not to Select All

If you include the field names, your code is self-documenting
When a field name changes, you want to know with a query error, not later
Asking for more than you need is just wasting resources
Without naming the fields, you can’t be certain of the order you’ll receive them

I hope these reasons are good enough to encourage your next query to not start select *.

See also: