A briefing paper on the osconcert online ticketing system security issues, vulnerabilities and privacy concerns. OSCONCERT SECURITY AND PRIVACY.

Transcription

1 osconcert Security and Privacy. A briefing paper on the osconcert online ticketing system security issues, vulnerabilities and privacy concerns. Contents. OSCONCERT SECURITY AND PRIVACY. 1 CONTENTS. 1 WHAT IS OSCONCERT? 2 OSCOMMERCE SECURITY - HISTORY 2 WHAT FORM DO THE ATTACKS/HACKS TAKE? 3 OSCONCERT HOW DO I MAKE MY SITE AS SECURE AS POSSIBLE? 3 Shared servers. 3 Dedicated servers. 4 File permissions. 4 Database Backups 4 File Backups 4 SSL 5 PRIVACY 5 INTERNAL SECURITY. 5 Administration of your administration. 5 Payment handling 6 CONCLUSION 6

2 What is osconcert? osconcert is web based ticketing software written in PHP/MySql and is derived from an offshoot of oscommerce. The code for oscommerce is Open Source and, as such, freely available for examination by potential hackers. Coupled with the fact that the original oscommerce release was back in 2003 then there has been ample opportunity for hackers to attempt attacks on oscommerce sites. oscommerce Security - history In the past couple of years hacking attacks on web facing software have grown more prevalent with the hackers usually aiming to inject their own code into an existing site - oscommerce was not exempt from such attacks and received a lot of attention from the hackers and subsequent bad press. The most recent version of oscommerce (2.3.1) has finally addressed many vulnerabilities within its code and, coupled with hosting improvements, this has seen a considerable drop in attacks/hacks. Eighteen months to two years ago I was doing a lot of work cleaning up infected oscommerce, WordPress and Joomla sites this work has now dried to a trickle as software and hosting security has seen a rapid improvement not to say that the hackers have gone away, they are just finding it harder to find a way into a site. osconcert/openfreeway was based on oscommerce 2.2 but the openfreeway design team had the advantage of knowing about the oscommerce vulnerabilities before they started adapting the code so they could integrate extra security to their scripts for example: Cross site scripting (XSS) osconcert carries an new PHP class (includes/classes/filter_input.php) which allows for the improved sanitising of user input strings to prevent XSS in particular checking for base_64 input strings and checking POST and GET data against a blacklist. This stops bots/hackers from trying to send instructions to your server using something as innocuous as a search box or contact form. Built in error checking in the checkout system three strikes and you re out e.g. more than three wrong attempts to submit a credit card number will log out the customer this helps stops people from trying to run a list of credit card numbers through your store in an attempt to find one that works. The file admin/filemanager.php was removed. Administrator username/password security enhanced

3 Parent/child file checking using the define( '_FEXEC', 1 ) code at the head of each parent file thus stopping the inclusion of rogue files. Upgrading of PHP code to exclude the use of global variables. What form do the attacks/hacks take? The most common form of attacks are Cross Site Scripting attacks and the Wikipedia overview gives a useful description here is their summary: Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications, such as web browsers through breaches of browser security, that enables attackers to inject client-side script into Web pages viewed by other users.. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner. Many shared hosting servers are lacking in their internal security setups and many shared sites were effectively hacked from within the server itself. weak ftp passwords/security settings will allow third parties to place files on your website through the hosting server PHP and MySQL are both being constantly tweaked/updated and hackers are keen to attack each new version as it is released security patches and updates are released at intervals and should be applied. In addition lack of care with installation/file permissions can allow improper access to the scripts. Direct attempts to hack/subvert the store checkout system osconcert how do I make my site as secure as possible? Shared servers. Most of us host sites on a shared server and with these, you most often get what you pay for we are reliant on the hosting company to monitor security patches from the PHP/MySQL/Apache world and apply them to their server usually the better known hosting companies carry the most up to date versions of PHP/MySQL. Have a look at where you will find a list of web hosting companies that are members of the stopbadware voluntary code of practice. Whilst this is by no means a guarantee of good health it is at least a start.

4 Dedicated servers. If you have your own dedicated server then it will be your responsibility to secure it against attacks be aware of vulnerabilities in not only PHP and MySQL but even the actual server handling software itself (e.g. cpanel and WHM) hackers will look to these as a way of getting access to your server. If your hosting company runs a dedicated server on your behalf then see if they have loaded the latest patches/updates for the software. File permissions. Your folders and files on the server should have the highest possible security settings that still allow the store to run these can usually be set to: All files, except for the two configure.php files have permissions no higher than 644 this is most important as the configure.php files hold your database login details The two configure.php files should, ideally, be at a higher level 400 is best but 444 or even 644 if 400 prevents the code from running. Permissions on folders should be no higher than 755 (this may vary from host to host and, in particular, the images folder may need to be 755 or 777). Remove the installation folder after you have your site up and running. Database Backups Complacency about database backups can kill your store dead in the water should there be some sort of problem with the hosting server never assume that your hosting company runs a daily backup of the database ask and, if even if they do, setup your own using cpanel or other control software (and once you have a backup make sure it works by a practice reload.) A daily backup means that you will lose fewer orders and customers should the worst ever happen. File Backups A standard osconcert installation contains over four thousand files. A successful cross server attack may place illegal code in perhaps just one of these files. Finding this code in a compromised site is therefore time consuming and, at times, well nigh impossible it is much easier to just wipe the entire server installation and reload the entire site. To that end a zipped copy of your site is a godsend have one somewhere safe and don t forget to update it should you edit any files on your live site.

5 SSL Currently there is some debate regarding just how secure SSL/HTTPS actually is but, nevertheless, you should always try to use SSL within your site and, if you are using any sort of on site payment data handling this is an absolute must. If osconcert is setup using SSL then all data sent/received during the customer account creation and checkout stage will be handled by HTTPS this includes all payment details if no SSL is setup then these steps will be unencrypted and any data transmitted may be vulnerable to interception. SSL also has a place in the discussion about privacy: Privacy The number one consideration with privacy has to be card holder data if you are accepting credit card details on your website then you should, at the very least, be handling this data using SSL and be aware of the further PCI Compliance Requirements: You should never store the CVV number provided by a card holder in your records if you want to store the credit card number itself then I would suggest only keeping the last four digits xxxx-xxxx-xxxx-1234 Customers will provide their personal details to you in the expectation that they are held securely and will not be used for any other purpose to this end you will have to rely on the server security steps outlines above to prevent unauthorised access to the database. Consideration could be given to running a site vulnerability scan using commercial software (e.g. mcafee Site Secure) which will attempt to hack your site via user input forms. Internal security. Administration of your administration. This may sound like an oxymoron but you need to know and control who has access to your store administration pages to prevent fraud and/or information leaks. To this end osconcert has the ability for the store owner to setup different administrator accounts with varying levels of authority you should make use of this to limit access where appropriate and review the authorised users at a set interval for example a disgruntled ex member of staff could cause all sorts of problems if they can still log in to your store.

6 The bigger your organisation the more important staff access becomes. Routinely change passwords and choose a strong password try not to repeat passwords across websites as a piece of malware may be sitting on a computer that you use one day to access something as minor as your Facebook account. Your favourite /password combination gets added to a hacker s list and then is tried against thousands of websites using remote login bots. Payment handling Up till now we ve mainly been looking at securing your site and data to finish up with let s have a quick look at your payment handling system. Whatever system you are using maximise your security at the merchant account end each bank/card issuer has different setups some features that you may be offered for example are: CVV checking AVS (address verification) Banned countries Customer IP number not from country of card holder Given that most osconcert stores are set to allow download of tickets as soon as a payment goes through then it is your own interests to setup as many anti-fraud measures as possible I have seen many merchant account setups where even the basic CVV function has not been initialised so take time to look through your bank setup and see that the security options are set. Conclusion osconcert is no more or less vulnerable to hacking that any other web facing application hackers and others are out there constantly sniffing at websites and servers looking for access so: Assume the worst may happen and backup your database daily if possible. Keep a copy of the site files on your local machine so that you can reload the site. Make sure store admin passwords and access levels are reviewed at intervals. Be paranoid assume they are out to get you.