Tip #2 Web development tips and tricks

Tip #2 in this series touches on the topic of security.  With the latest heartbleed vulnerability within OpenSSL hitting the headlines security it currently at the forefront.  I think it is fair to say that security is not a priority for most web developers: for some it is not even on the radar.  The problem is, that it is way, way too easy, to roll-out a site for a new project, get paid and move on. But, what happens to the site a week, month or a year down the line?  Worse case scenario is the site gets hacked.  Why? Because, it is not being kept up-to-date with the latest security patches and your web developer has moved on.

The simple solution is to keep you platform up-to-date.  Whether it Magento, Symfony, WordPress or Joomla.  It needs to be kept current.  If you were offered a way to improve the security of your house would you take it?  Of course you would.  The same should apply to your website.  Security vulnerabilities are discovered all the time. We should give the framework vendors credit here.  They issue security patches with a high level of speed and efficiency.  The problem you face is getting that security patch installed on your website.  I’d suggest striking a deal with your web designer/agency so they are responsible.  Of course they would expected some recompense for this, but, it shouldn’t be a lot.  Any web designer/agency who will not agree to this are obviously not a good choice to begin with.  Security first!


Security Scoring your Bank

Most of us use some form of online banking. Whether it be simply viewing a monthly statement, or, paying a bill online. We entrust the banks with financial transactions and personal data. But, how do we know secure is secure? Continue reading “Security Scoring your Bank”

Security: the Good, the Bad and the Ugly

In the physical world everyone applies basic security principles such as closing and locking doors when leaving their home.  We are, in the most, security conscious and the majority of us wouldn’t knock on the door of a con man and start a conversation.  It’s also true we have a good understanding of what  makes our world safe, such as fitting a car alarm, or, carrying a personal safety alarm.  In the digital world we seem to loose these basic instincts and brazenly click link after link, trusting that we’ll end up in a safe place.  Unfortunately, many innocent looking websites are acting for the forces of evil and it is not always obvious this is the case. Continue reading “Security: the Good, the Bad and the Ugly”

Should you fear QR Codes?

QR Code
Would you scan it?

Quick Response (QR) Codes allow you to scan a square image which resembles a bar-code to open web pages on a compatible device.  This means retailers can direct you to their websites without you having to type a long URL.  The trend to include QR codes on advertisements within magazines is pretty standard. Read more

Tips for securing SSH

SSH is the preferred method for providing remote shell services such as command execution.   Designed as a replacement for the old-school insecure Telnet protocol SSH provides an encrypted secure connection between client and server.  Although, far more secure than its for-farther, there are some extra steps you can take to increase out-of-the-box setting to increase the level of security.

The following assumes a fresh installation of CentOS 6.  By default the SSH service is not enabled.  To enabled the service you need to start the service.  To do this run the following command as the root user within a terminal:

service sshd start

To configure the system to start the SSH service at start-up you can run the following:

chkconfig sshd on

The service will now accept connections from clients. The configuration of the service is controlled by the contents of a configuration file called ‘sshd_config’ located within the folder ‘/etc/sshd/’. Open this file using the editor of your choice. Read more

Software Security: Education’s missing module

Security the missing module in education

I’m shortly due to reach my fifteenth year as a programmer within the software industry. During this time I have witnessed a significant increase in the number of viruses, malicious software and security holes found within any given piece of software. To protect us, software vendors issue security patches issued within software updates on a regular basis and hope we all apply these to avoid the pitfalls. This ship first, fix later approach has always seemed odd to me. It’s akin to locking the door of your house after the burglar has already visited, in the hope all of your neighbours will follow suite and remember to lock their houses too!

The computer security industry can be split into three sections: the White hats, Grey hats and Black hats. The White hats are our guardian angles, who spend their time finding and fixing security problems. The opposite of this is the ‘evil’ Black hats who attempt to expose and maliciously exploit security vulnerabilities in the goal taking our data or controlling our computers without our consent. And, in-between these two are the Grey hats, who like to prove they can hack; but without any real malicious intent. The individuals within each camp range from IT professional to passionate teenagers seeking a thrill. Although quite different they share a common tool-set. All of these tools are easy to access and complemented by a huge collection of tutorials. These include standalone utilities such as the port scanner ‘nmap’ to entire operating systems built for the sole purpose of security scanning/hacking, such as ‘Back Track 5’. Another similarity shared by these individuals is they share a common target. Your Software!

Flaws in software more often than not reveal security vulnerabilities. These vulnerabilities can lead to leaked data, or, even the bad guys having control of your computer.   This leads me onto the main point and a question: do software programmers/developers consider security when applying their craft? In my experience the answer in, ‘No!’. The fault of which does not solely lie with the programmer.  I see no evidence from the Schools, Collages and Universities that the subject is covered sufficiently by the relevant courses.  Take for example, a web development course; are the students being taught about SQL injection, or, the importance of software updates. More often than not I see web developers creating beautiful sites in Joomla or WordPress, or, any other CMS, and at the end the site simply gets hosted and left for the client to manage. I ask the question: whose’s going to update the core CMS, or, the plugins used after a security vulnerability has been found. Not the web developer, as they have been paid and moved on! This is a typical example of how the industry is disjointed. And, I’m not picking out web developers: further examples could easily be given involving Java/C/Ruby developers, or, companies that deliver bespoke systems.

The problem is both an educational one in the academic sense and a re-education of users and clients so they appreciate and demand security guarantees. Imagine if you are faced with these two quotes, the first, “I can provide you with a website for $400”. The other said, “I can provide you with a website for $400, plus $50 per year to monitor and maintain security patches”. What option would you pick? I fear at the minute most would choose the first option; thus, the need for re-education, re-education, re-education.

So how would one go about fixing this? I’d love to see security knowledge being taught  alongside every web development and software development course. I’d also like to see a web development/programming governing body, ensuring our work is up to scratch. This governing body would be akin to the building trade’s regulators; ensuring and enforcing we deliver consistent and quality products to our customers. Alongside this we should expect our work to be appreciated as a craft and educate future clients that our products need maintenance which will incur maintenance costs.

Security Now – Security, education and coffee

Security_now_podcastSecurity now is a weekly pod-cast fronted by the duo Steve Gibson and Leo Laporte. The pod-cast’s primary topic is security within the IT sector. Each show normally focus’ on a given topic which is chosen by Steve Gibson – the Commander and Chief of all things security. The main subject fits around several regular slots which includes discussions about the latest security events. The pod-cast lasts around 60-90 minutes and is pitched at listeners with a medium to high knowledge within the security area. However, anyone who wants to learn about security will truly benefit from the show as Steve and Leo explain complex subjects in a manner that is very easy to digest.  Although the show is driven by Steve Gibson’s labyrinthian brain, Leo Laporte’s broader knowledge of everything IT brings a fresh edge to Steve’s in-depth crypo-speak.  The two compliment each other and occasionally digress into other areas of interest to the super geek; like books, coffee, nutrition and sci-fi.

The history of the show goes back to 2005 and they have recorded over three-hundred and fifty shows, each of these shows are available at GRC (Gibson Research Company) website.  The latest shows are also published on Leporte’s Twit network  The archive is well worth reviewing, some of the best pod-casts I’d recommend are Episode #325, 323 and 317 which delves into the bowels of how the TCP protocol – the backbone of the Internet.

For more information please visit Twit’s site!  You can even tune into the show as it is broadcast live.

How to keep your system up-to-date and secure

Keeping your PC secure

We’ve all got software installed on our computers that accesses the Internet.  It is relatively normal to be connected to the Internet every second of the day. This combination means our machines need to be super secure.


In order to appreciate why security is important, let me explain.  Software is written by software developers. These software developers (like me) are only human and from time-to-time they make mistakes.  It is normal for new features to be added to software at an alarming pace. The browsers war is a prime example of how several companies are trying their best to convince us to use their browser; be it Chrome, IE, Firefox, Opera or Safari. As software grows they add more and more features.  The more features they add the more complex the software becomes. This complexity makes it very difficult to make sure software cannot be abuse. By abuse I mean, can a bad guy make the software behave as it was not intended. For example, imagine if you were to browse to a random site. We put a lot of faith in our browsers to do as we ask; however, if a bad guy has discovered a method to make your browser behave as it was not intended they may be able to access all the files on your computer: your emails, family photos, letters etc. This is not an exaggeration! This type of thing happens and have been given the technical labelled ‘software security vulnerabilities’. What tends to happen is that these are fixed as quickly as they are discovered and the software company ships a new version of their software: known as a security patch.  The problem is how do we know that our software needs an update?  The truth is the majority of use do not update unless the software we are using forces us to.  Ask yourself, when was the last time you updated Adode Reader?

Applying software updates

You could manually update each piece of software by checking the relevant vendors’ website for updates, downloading the updates and apply each, one-by-one.  This solution would be very time consuming and is prone to error e.g. you missed an update.  The automated solution I use is a piece of software called Secunia Personal Software Inspector (PSI).  This great piece of software regularly scans the software I have installed and then checks Secunia’s central database for updates. Secunia monitors the vendors; thus, the know the latest version of almost every piece of mainstream software.  If PSI detects a newer version than you have installed it will then either apply the update automatically, or, alert me of the issue.  Simple!


The following shows the Dashboard screen PSI displays when opened:

This shows me that I need to update nine pieces of software.  I can then drill into the scan results to view which software updates I need:

As you can see, I need to run window’s update.  I also need to download and update the software for Adobe Air and my HP printer.  To see the details of each I can drill into each by double-clicking the item in the list e.g.

The window above informs me the exact problem with the software and conveniently includes an “Install solution” button.  The ‘Online References’ section also directs me to the vendor’s site to read the related security advisory.  Following the advice from PSI, I can apply the  recommended updates.  PSI will eventually give me a 100% rating.

100% Secure

Of course, this process is iterative. I would recommend you re-check PSI on a weekly basis.
To obtain a free, yes FREE copy of PSI go here: http://secunia.com/vulnerability_scanning/personal/download_psi/.  Happy patching.

A simple SQL Injection vulnerability walk-through – Part 2

In part one of this post we installed and configured MySQL and installed the required package for our web-server (http).  In this post I intend on explaining how to configure the web server (httpd), ensuring the default httpd website is accessible to the public.  Once httpd is configured we’ll replace the default page with a simple HTML login form and we’ll also code a simple PHP login processor which will be vulnerable to SQL injection.  I’ll then demonstrate how to carry out the SQL injection attack and finally discuss how to prevent it!.

Installing a basic web-server with PHP support

In step one we installed the core web-sever packages: httpd, php and php-mysql.  By default the web-server (httpd) is configured to not start at boot e.g.

chkconfig --list httpd
httpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off

We’d like our web-site to be available after a reboot,so let’s modify this – again the chkconfig utility can be used:

chkconfig httpd on

In addition to the web-server starting automatically we also want the public to be able to access our web-site.  By default the firewall on Linux (iptables) will not permit external access to the httpd daemon.  Thus, we need to open up port 80.  This is achieved by modifying the file /etc/sysconfig/iptables as follows:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

In the example above I simply added the highlighted line which instructs the firewall to accept traffic on port 80.  To activate this restart iptables e.g.

service iptables restart
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules:                         [  OK  ]

We are now ready to start the web-server for this first time:

service httpd start
Starting httpd:                                            [  OK  ]

Once started it is wise to ensure the default web-site is available. This can be achieve by browsing to your IP address. You should see the following:


Continue reading “A simple SQL Injection vulnerability walk-through – Part 2”

A simple SQL Injection vulnerability walk-through – Part 1

Have you ever wondered what all the fuss about SQL injection is?  Does it really affect you?  Should I worry about it?  How do you know your site is safe from the perils of SQL injection!  Should I sleep at night, or, should I monitor my web-server logs for the nasty malicious hackers. In this post I’ll step you through setting up a simple website with a HTML log in page that submits a username and password to a PHP page that is susceptible to SQL injection.

Setting up the web-server

Before we start, let me state that all the steps shown in this post are tailored for the CentOS 6 operating system.  The command to achieve the same actions on other Linux flavours may differ and you may have to find a suitable substitute.

Installing a basic web-server with PHP support

In order to set-up a basic web-server we first need to install the following packages:

  • httpd
  • php
  • php-mysql
  • mysql-server

These packages can be installed using the YUM update manager as follows:

yum install httpd php php-mysql mysql-server

These packages provide the target server with a web server (httpd) with support for the PHP server-side language (php).  The package which provides support for MySQL within PHP is also added (php-mysql).  And, finally a  prerequisite for the aforementioned is added: the MySQL database itself (mysql-server).  On executing the command above YUM  will evaluate the package dependencies and present you with a list of what will be installed:

Dependencies Resolved

Package Arch Version Repository Size
mysql-server i686 5.1.61-1.el6_2.1 updates 8.3 M
php i686 5.3.3-3.el6_2.6 updates 1.1 M
php-mysql i686 5.3.3-3.el6_2.6 updates 76 k
httpd i686 2.2.15-15.el6.centos.1 updates 819 k
Installing for dependencies:
mysql i686 5.1.61-1.el6_2.1 updates 891 k
perl-DBD-MySQL i686 4.013-3.el6 base 134 k
perl-DBI i686 1.609-4.el6 base 705 k
php-cli i686 5.3.3-3.el6_2.6 updates 2.2 M
php-common i686 5.3.3-3.el6_2.6 updates 523 k
php-pdo i686 5.3.3-3.el6_2.6 updates 72 k
Updating for dependencies:
httpd-tools i686 2.2.15-15.el6.centos.1 updates 70 k
mysql-libs i686 5.1.61-1.el6_2.1 updates 1.2 M

Transaction Summary
Install 9 Package(s)
Upgrade 3 Package(s)

Total download size: 16 M
Is this ok [y/N]:

Simply accept the propossed list to install the packages.  YUM may prompt you to import the GPG key of the software repository if it is the first time YUM has accessed the repository.  If so accept to complete the installation:

Is this ok [y/N]: y
Downloading Packages:
(1/12): httpd-2.2.15-15.el6.centos.1.i686.rpm                                          | 819 kB     00:01
(2/12): httpd-tools-2.2.15-15.el6.centos.1.i686.rpm                                    |  70 kB     00:00
(3/12): mysql-5.1.61-1.el6_2.1.i686.rpm                                                | 891 kB     00:01
(4/12): mysql-libs-5.1.61-1.el6_2.1.i686.rpm                                           | 1.2 MB     00:01
(5/12): mysql-server-5.1.61-1.el6_2.1.i686.rpm                                         | 8.3 MB     00:07
(6/12): perl-DBD-MySQL-4.013-3.el6.i686.rpm                                            | 134 kB     00:00
(7/12): perl-DBI-1.609-4.el6.i686.rpm                                                  | 705 kB     00:00
(8/12): php-5.3.3-3.el6_2.6.i686.rpm                                                   | 1.1 MB     00:01
(9/12): php-cli-5.3.3-3.el6_2.6.i686.rpm                                               | 2.2 MB     00:02
(10/12): php-common-5.3.3-3.el6_2.6.i686.rpm                                           | 523 kB     00:00
(11/12): php-mysql-5.3.3-3.el6_2.6.i686.rpm                                            |  76 kB     00:00
(12/12): php-pdo-5.3.3-3.el6_2.6.i686.rpm                                              |  72 kB     00:00
Total                                                                         503 kB/s |  16 MB     00:32
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
Importing GPG key 0xC105B9DE:
 Userid : CentOS-6 Key (CentOS 6 Official Signing Key)
 Package: centos-release-6-2.el6.centos.7.i686 (@base/$releasever)
 From   : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
Is this ok [y/N]:

Once complete YUM should confirm the packages were installed successfully:

mysql-server.i686 0:5.1.61-1.el6_2.1     php.i686 0:5.3.3-3.el6_2.6     php-mysql.i686 0:5.3.3-3.el6_2.6
Dependency Installed:
mysql.i686 0:5.1.61-1.el6_2.1 perl-DBD-MySQL.i686 0:4.013-3.el6 perl-DBI.i686 0:1.609-4.el6
php-cli.i686 0:5.3.3-3.el6_2.6 php-common.i686 0:5.3.3-3.el6_2.6 php-pdo.i686 0:5.3.3-3.el6_2.6

httpd.i686 0:2.2.15-15.el6.centos.1

Dependency Updated:
httpd-tools.i686 0:2.2.15-15.el6.centos.1 mysql-libs.i686 0:5.1.61-1.el6_2.1


Before we start our newly installed web-server we first need to configure and start the MySQL service.  Once started we’ll connect to the service and create a new database which will hold our table of users and passwords for the login page.

Starting and securing the database

Once installed, the default for the MySQL database daemon is to start a boot.   To check this we can use the chkconfig utility:

chkconfig --list mysqld
mysqld          0:off   1:off   2:off   3:off   4:off   5:off   6:off

It is pretty normal to configure a database to automatically start a boot time, so let’s correct this – again the chkconfig utility can be used:

chkconfig mysqld on

We can now start the MySQL database.  This will initialise the database and create the system tables.  To start the database we use the service command e.g.

service mysqld start
Initializing MySQL database:  Installing MySQL system tables...
Filling help tables...

To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

To do so, start the server, then issue the following commands:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h localhost.localdomain password 'new-password'

Alternatively you can run:

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

See the manual for more instructions.

You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &

You can test the MySQL daemon with mysql-test-run.pl
cd /usr/mysql-test ; perl mysql-test-run.pl

Please report any problems with the /usr/bin/mysqlbug script!

Starting mysqld:                                           [  OK  ]

It’s important to take note of the advice given here.  The processes of starting the database for the first time has triggered MySQL to advise us on certain security actions we should be take.  As we are responsible and want to ensure our database is super secure, let’s do it.  We’ll start be setting the password for the database root user:

 /usr/bin/mysqladmin -u root password 'LetMeiIn!'

Next, to be super safe and secure we’ll run the script too:



In order to log into MySQL to secure it, we'll need the current
password for the root user.  If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

You already have a root password set, so you can safely answer 'n'.

Change the root password? [Y/n] n
 ... skipping.

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y
 ... Success!

By default, MySQL comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] Y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

As stated on the output above the script disallowed root access from anywhere but the localhost, it removed the test database that ships with MySQL and reloaded the privilege table.  That leaves us with a secure instance of MySQL without any database.  Thus the next logical step is to create the database that will hold our table of users.  In order to do this we first must log on to the MySQL command interface as the root user:

[root@localhost ~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 19
Server version: 5.1.61 Source distribution

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.


Once logged on simply issue the following command to create a database:

mysql> create database inject;
Query OK, 1 row affected (0.00 sec)

Assuming you received a positive response (as above), the next step is to create a user who can access the database. It is worth pointing out that you should never use the root user to access the database. This is because the root user has root privileges! And, if your website was to fall foul to SQL injection attack we’d all prefer the attacker to only see and subset of tables; rather than the entire database as root can see!

To create a user from the MySQL console run the following:

mysql> grant all on inject.* to 'loginaccount' identified by 'password';
Query OK, 0 rows affected (0.00 sec)

The command above creates the user and at the same time grants the user access to all objects on the inject database. Please DO NOT set the password of this user to ‘password’. Make it something far more secure to avoid nasty hackers from brute-forcing your database.

The final step to complete the configuration is to create the table of users.  Again, using the MySQL command prompt enter the following:

mysql> CREATE  TABLE `inject`.`users`
  `idusers` INT NOT NULL ,
  `name` VARCHAR(45) NOT NULL ,
  `email` VARCHAR(45) NOT NULL ,
  `password` VARCHAR(45) NOT NULL ,
  PRIMARY KEY (`idusers`)
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO `inject`.`users`
     (`idusers`, `name`, `email`, `password`)
     (0, 'paul', 'paul@cia.com', 'Secret123');
Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO `inject`.`users`
     (`idusers`, `name`, `email`, `password`)
     VALUES (1, 'ian', 'ian@fbi.com', '12345');
Query OK, 1 row affected (0.00 sec)

That completes the database configuration and part 1 of this post.  To conclude we now have a database called ‘inject’ which contains a schema called ‘inject’,  This schema holds a table of users called ‘users’.  We can now progress and configure the web server (httpd), ensuring the default httpd website is accessible to the public.  Once httpd is configured we’ll replace the default page with a simple HTML log in form and we’ll also code a simple PHP log in processor which will be vulnerable to SQL injection.  I’ll then demonstrate how to carry out the SQL injection attack and finally discuss how to prevent it!

Part two.