I recall a project I worked on a few years ago where I was tasked with overseeing the security of a website we were building. When I sat down with the chief programmer I wanted to discuss three types of vulnerabilities with him: cross-site scripting, SQL injection and information leakage. His response was simply, “I don’t know anything about this stuff and I don’t care. That’s your job.”

While other web developers I have worked with aren’t generally so curt in their response, I have noticed that not many of them are aware of the different vulnerabilities that exist when it comes to web site development.

When it comes to websites, WhiteHat Security found some interesting data that should be considered required reading for all web developers. Not to make your job more complicated, but to give you a better understanding of what threats your sites face.

Most websites were exposed to at least one serious* vulnerability every day of 2010, or nearly so (9–12 months of the year). Only 16% of websites were vulnerable less than 30 days of the year overall. 71% of Education, 58% of Social Networking, and 51% of Retail websites were exposed to a serious* vulnerability every day of 2010. During 2010, the average website had 230 serious* vulnerabilities. SQL Injection vulnerabilities, despite large numbers of them being found and fixed during 2010, still occurred in 14% of websites.

So what does this mean for the average web developer? That we have to take a good look at the security of our websites because there is a pretty good chance we left an opening somewhere in our site.

Knowing the Threats

Understanding what threats we face when writing code can help establish a foundation that can be used to help protect web sites against attackers. According to WhiteHat, the most prevalent vulnerabilities found in web site code are as follows:

Information leakage Cross-site scripting Content spoofing Cross-site request forgeries Brute force attacks Insufficient authorization Predicable resource location SQL injection Session fixation Abuse of functionality

Least Secure Language

Knowing what coding languages are the least secure can also help you write more secure code. According to a report that ranked programming languages common to web development and ranked them by the average number of serious vulnerabilities found per site developed in them. The results are:

Perl – 44.8 Cold Fusion – 34.3 PHP – 26.6 JSP – 25.8 Microsoft ASP – 25 Struts DO – 19.9 Microsoft ASPX – 18.7

Best Practices for Secure Development

Finally, we turn to OWASP for the best practices they recommend for web developer to as guidance on implementing security mechanisms and avoiding vulnerabilities.

Validate user input Use secure authentication services Make sure only authorized users can perform actions allowed within their privilege level Practice good session management Protect your code against attacks from common interpreters Protect confidentiality and integrity with cryptography Use best practices when it comes to error handling Protect the file system Make sure your code runs securely out of the box, don’t assume it is the responsibility of the operator to secure it Be aware that Web 2.0 technologies also pose security risks

Again, having knowledge of the different types of vulnerabilities that can threaten your code will not make you a security expert. However, having a understanding of what threats you face can help you write more secure code and in the long run, this can certainly make you a valuable asset to any development team.

...

JavaScript went on to become cult right after its launch due to its extensive list of features. It also gave programmers the chance to give their webpages a more eye-popping look and website visitors were happier than ever.

Despite the large number of developers that sing the praises of JavaScript, there are those Internet users who see its dark side.

Webpages using multiple JavaScript codes are slow to load and overuse of JavaScript contributes to making webpages look cluttered and ugly. In no time the smart use of JavaScript became a hot topic amongst programmers.

Without further ado, let us dive into our list of JavaScript best practices that will save you from this unwanted criticism.

Keep it short, stupid!

You have read this a zillion times already. As a programmer/webmaster you might have applied this tip multiple times too but never forget this in case of JavaScript.

Use comments and white spaces while in development mode to keep your code readable. Remove white spaces and comments before publishing your scripts in live environment. Also, try to shorten your variable and function names. Consider using third party tools to compress your JavaScript code before publishing the same.

Think before you touch object prototypes

Appending new properties to object prototypes is one of the most common reasons for script failures.

yourObject.prototype.anotherFunction = ‘Hello’; yourObject.prototype.anotherMethod = function () { … };

In above case all variables will be affected as they are inherited from “yourObject”. Such usage might cause unexpected behaviour. Henceforth, it is suggested to delete such modifications right after its usage:

yourObject.prototype.anotherFunction = ‘Hello’; yourObject.prototype.anotherMethod = function () { … }; test.anotherMethod(); delete yourObject.prototype.anotherFunction = ‘Hello’; delete yourObject.prototype.anotherMethod = function () { … };

Debug JavaScript Code

Even the best programmers make mistakes. To limit them, run your JavaScript code through a JavaScript debugger to make sure that you haven’t made any silly blunders that can easily be prevented.

Avoid Eval

Your JavaScript can work well without the use of “eval” function. For those not aware, “eval” gives access to JavaScript compiler. If a string is passed as parameter of “eval” then its result can be executed.

This will degrade your code’s performance though it acts as a boon during development phase. Avoid “eval” in live environment.

Minimize DOM access

DOM is one of the most complex APIs that slows down the code execution process. At times the webpage might not load or it might load incompletely. Better to avoid DOM.

Learn JavaScript before using JavaScript libraries

Internet is chock full of JavaScript libraries that perform various functions. Programmers end up using JavaScript libraries without understanding the side effects of the same. It is strongly advisable to learn the basics of JavaScript before using third party JavaScript libraries; otherwise, be prepared for disastrous results.

Never use “SetTimeOut” and “SetInterval” as alternatives to “Eval”

setTimeOut( “document.getID(‘value’)”, 3000);

In above code document.getID(‘value’) is used as a string that is processed within the “setTimeOut” function. This is similar to “eval” function which executes a string during every execution of code thus degrading performance. Henceforth, it is suggested to pass a function within such functions:

setTimeOut(yourFunction, 3000);

[] is better than “new Array();”

“A common error in JavaScript programs is to use an object when an array is required or an array when an object is required. The rule is simple: when the property names are small sequential integers, you should use an array. Otherwise, use an object.” – Douglas Crockford, writer of JavaScript: Good Parts.

Suggested:

var a = [‘1A’,’2B’];

Avoid:

var a = new Array(); a[0] = “1A”; a[1] = “2B”;

Never use “var” multiple times

While initializing every variable programmers tend to use “var” keyword. Instead, it is suggested that you use commas to avoid redundancy of keywords and reduce code size:

var variableOne = ‘string 1’, variableTwo = ‘string 2’, variableThree = ‘string 3’;

Never Miss Semicolons

This is one of the programming bugs that can consume hours of debugging. Personally, I have spent hours looking for problems in my code when the reason was the missing semicolon.

I am pretty sure that you must have read most of the above points but at times we tend to ignore the basics. Did you ever miss a semicolon? Has “eval” keyword messed up your code’s performance?

...

There are times when we are so anxious to jump into creating something new that we forget to cover the basics. For web developers it is important, actually vital, to have the ability to test your projects locally before they go live.

While much of the web relies on a Linux, Apache, MySQL, PHP stack, or LAMP, to power applications and dynamic websites, not everyone codes in a Linux environment.

Those who prefer Windows can still replicate how their code will work by using WAMP to replicate a live web environment right on their own computer with the only difference being substituting the Linux operating system in the stack for Windows.

Obtain a copy of WAMP

Before you do anything you need to download WAMP from http://www.wampserver.com/en/download.php. You will have the  option to choose wither a 32 or 64-bit environment depending upon your computer’s configuration. In addition to Apache, PHP and MySQL this download includes phpMyAdmin and SQLBuddy to better help you manage your databases through web based GUI rather than having to use a terminal interface.

Install the software

Once you have downloaded and uncompressed your WAMP executable you will need to go ahead and launch it to start the installation process.

When you click next you will be asked to accept the license agreement. Since it is a GPL license you are free to do just about anything with it so you can go ahead and accept.

The next step requires you to select the folder where you would like to install your WAMP server. The default will be c:\wamp however you can change this to install the server into any directory or partition you choose.

Chose where to install the software

After you choose your directory you will have the option to setup icons. Once you decide on this click Next and then confirm the installation settings again by clicking Install.

Once the installation runs its course you will be asked to choose your default browser. Internet Explorer is the default choice but you can navigate your way to any other browser of your choosing.

NB – if your Windows firewall pops up at this point make sure to grant Apache access.

The next decision you will have to make is to set the PHP mail parameters. Many people leave this set to the defaults when setting up a testing server on their local computer. If you wish to configure it to connect to your SMTP server you may do so here but unless you plan on testing email capabilities the default entries can be left and all you need to do is click Next.

Setting the SMTP server (optional)

Congratulations, WAMP is now installed on your local computer.

Testing the installation

Now that everything has been installed let’s test everything out.

Using one of the icons you created, or Start –> All Programs –> WampServer –> start WampServer, you can launch the management console. Once opened, it will appear in the lower right hand corner of your screen.

The WAMP management console

If WAMP is not started go ahead and click Start All Services. If you are not sure whether or not WAMP is running, look for the small green W icon in your toolbar. If it is red, WAMP services are stopped, green means everything is running while orange means some services are running.

Now we want to test to see if everything was installed correctly. In the WAMP management console, click on Localhost. If you see the following screen pop up in your browser then everything is working!

WAMP services are running

Configuring phpMyAdmin

The last step is to set a password for phpMyAdmin. Many people forgo this step because the server is not going to be live so they don’t see the need to protect the database if it is only sample data. You can decide what practice to follow.

In order to change the password you will need to navigate to your phpMyAdmin file, located at C:/wamp/apps/phpmyadmin3.x.x and open the config.inc.php file for editing.

Once opened, navigate to the lines that read,

$cfg['Servers'][$i]['user'] = 'root'; $cfg['Servers'][$i]['password'] = 'xxxxx'; $cfg['Servers'][$i]['AllowNoPassword'] = true;

Where the example reads xxxxx insert your password. Under AllowNoPassword, change the value to false.

What do I do next?

Now that everything is installed and working you can upload test websites to your root or even install third-party web applications like WordPress, Moodle, Drupal, etc. to this location. You now have a sandbox in which to work on your development projects! Have fun with it.

...