» Six Common Web Programming Mistakes and How to Avoid Them
Posted by | 0 Comments
Posted on: May 14th, 2012


The ubiquity of technology in our daily lives has made programming an indispensable DIY skill for the digital age. The ‘learn to code‘ movement, kick started by the easy availability of free interactive coding lessons on platforms such as Codecademy, combined with the inevitable shift of talent towards entrepreneurship in a depressed job market, has introduced thousands of people to programming.

Programming is difficult. Even the simplest of coding languages have steep learning curves. Add to that the imperative task of fixing security loopholes, and you have the perfect recipe for a concoction that can intimidate all but the most resolute of new converts to this field.

Most new programmers (and many old hands as well) are guilty of a committing a bevy of programming mistakes, some of which can be virtual suicide for a promising app or software program. The six most common programming mistakes are:

1. Not Validating Input

A numeric input field should get a numeric, not alphabetical input. A field that checks the price of a new car shouldn’t accept a dollar sign and other special characters. Validating the input is one of the fundamental rules of programming; breaking it can often lead to patchy performance and a host of easily exploitable vulnerabilities. Not only can hackers gain control over an app by carefully modifying the input, but incorrectly validated input also disrupts the data flow of a program.

How to avoid it:

Begin by using an input validation framework such as OWASP ESAPI Validation API (available for many languages). Maintain a strict policy of assuming all input as potentially malicious until further verification. Carefully examine all potential sources of vulnerabilities – filenames, databases, cookies, etc. – fixing each along the way. You can never really be too obsessed with security; using an input validation framework, and careful cross-checking of the code are only a few precautions to prevent a security mishap.

2. Cross-Site Scripting (or, Failure to Neutralize User Input)

Another common programming mistake is a failure to neutralize user-input before using it to generate output on a dynamically generated web page. Suppose a web-page requires input from a user (such as a comment field) before redirecting him to a dynamically created web page that incorporates that data. If the programmer fails to neutralize the user’s input, a hacker can insert malicious code into the input field, which can subsequently lead to inclusion of malicious, browser executable content (JavaScript, Flash, etc.) in the page.

How to avoid it:

Cross-site scripting usually occurs when users are allowed to submit unregulated content to be consumed by other users of a website. It is most common in sites that allow user-generated content such as comments for forum posts. This exploit has been prevalent since the beginning of the internet when ‘guestbooks’ were a common feature on most sites.

To prevent this from occurring, consider using a vetted framework that makes it easier to generate neutralized output, such as the Microsoft Anti-XSS library or the OWASP ESAPI Encoding Module. Further, carefully examine your code and understand the relationship between various components, neutralizing and escaping any user-generated content before outputting it to a web page. This cross-site scripting prevention cheat-sheet is a good resource as any to learn more about this exploit.

3. SQL Injection (or, A Major Failure to Neutralize User Input)

The previous mistake only affects other visitors to your site; but failure to neutralize user input before using it for database interaction is the even nastier version of this problem – it can take your entire site down and wipe out precious data. This should actually be the number one problem, because it causes more serious problems and dangerous security breaches than probably any other mistake. Mess up on this one, and your entire server could be taken over by a hacker.

How to avoid it:

To learn more about the technical details of SQL injection attacks, read this article on SQL Injection. The solution is actually rather simple: always, always escape all user input before using it in a database query. Most programming languages have built-in functions to clean user input before use in database queries. (For example, mysql_real_escape_string in PHP.)

4. Poor Formatting and Improper Comments

By its very nature, programming is a collaborative effort. This means that code generated by one programmer may be accessed and modified by other programmers days, months, and even years down the line. A failure to format the code and provide effective comments detailing each function makes code unmanageable and difficult to maintain.

How to avoid it:

Each programming language has its own entrenched ‘grammar’ and style guidelines. When in doubt, refer to them to gather insight on how to effectively comment and format code. Regardless, develop a habit of inserting appropriate white-space and starting each new function with a comment detailing its use and scope. Practice brevity; comments need to be concise and to the point, not overly wordy. A couple of well-written comments can go a long way in making code easier to read and interpret. Also, be careful to break up code by the specific task it performs; avoid run-on code, just like run-on sentences.

5. Improper User Authorization

Controlling what logged-in users can and cannot do is crucial to ensuring application security and stability. Inadvertently allowing users access to forbidden areas is a mistake new and old programmers alike are sometimes guilty of. Most recently, the ICANN allowed applicants to its new gTLD program to view other applicants’ private information in a major security gaffe, proving not only the pervasiveness of this programming error, but also its injurious consequences.

How to avoid it:

Each application should be divided into limited (normal), privileged, and administrative areas, and given rights and control accordingly. Most logged-in users must be granted limited additional rights, and only a few trusted parties must be given administrative control. Use of role-based access control (RBAC) is also highly recommended.

It is also recommended that you use a vetted library (such as the JAAS Authorization Framework for Java) to make this weakness easier to avoid.

6. Using Hard-Coded Passwords

This is one of the most prevalent programming mistakes, simply because of its convenience. Using a secret hard-coded password for authentication across all the components of a software program makes modifying the code very easy, but also makes the software vulnerable to security breaches. If an enterprising hacker gains access to this password, not only will the security breach be nearly impossible to detect, but also difficult to fix, putting your entire product at risk.

How to avoid it:

Every software program utilizes either of the two authentication methods: outbound (i.e. connecting to an external database or file to verify authentication), and inbound (the authentication mechanism is built into the software itself). For outbound authentication, it is best to save all relevant login data in a strongly encrypted database or protected file. No outside user should be granted access to this information.

For inbound authentication, the security vulnerabilities of a hard-coded password can be circumvented by requiring all users to enter a unique, strong password upon first registration. These user-specific passwords should be “salted” (the process of adding a special secret string to the actual password), then hashed using a one-way hashing algorithm before storage. Passwords should never be stored in plaintext.

In conjunction with access control checks, the elimination of hard-coded passwords can significantly improve the security of your program.

You may also like…

Good Old Static HTML Sites Aren’t Dead Yet. Should They Be? →
Should You Keep Your Website Open Source? →
Should Designers know how to code? What do you think? →
Is a Design House-Style Really Necessary? →
Repeat Work and the Search For The Holy Grail →
Thoughts and Considerations for Freelancing on a Part-Time Basis →
Is Working Freelance Really Worth It? Pros and Cons →



View 's Profile | Subscribe via RSS
No comments currently exist for this post.
Leave your response:

Name (Required)

Email (Required)

Website (Optional)