Websites Here, Websites There, Websites Everywhere…, but are they secure?
Contributed by: Elisa Cockburn, Sr. Internal Auditor, Institute Audit, Compliance, & Advisement
Written with the help of Paul Lepkowski, Lead Engineer, Information Security Office, and Ben Woelk, Communications and Training Specialist, Information Security Office
We know that websites are a wonderful communication tool; they not only let us spread information to coworkers and students in seconds, but also to the whole World Wide Web. However, just as much as they let us send information out to the world, they also open a window from the world into our network. There are risks associated with this free flow of information.
If you have been watching the news in the past few years, you have probably heard about many successful attacks on organizations via their websites. Cybercriminals are no longer the average teenager without anything else to do; they have evolved into organized criminals looking for information that they can quickly sell on the black market, such as credit card or social security numbers. There is financial gain now associated with hacking into organizations’ websites.
This has resulted in cybercrime becoming more sophisticated than before. We now live in a time of “zero day” attacks, which means that hackers are coming up with exploits to applications so fast that there is a significant number of applications that have vulnerabilities of which developers are not yet aware, but that hackers are already exploiting.
For known vulnerabilities, application developers are now being more proactive in issuing patches to their applications as soon as they know about the vulnerabilities. However, this also results in having information regarding the vulnerabilities of most applications readily available on-line. Nowadays leaving systems unpatched is leaving an open door for an attack, since it would be a lot easier for hackers to exploit known vulnerabilities than to try to discover new vulnerabilities on their own. In his keynote address to attendees of the 2008 Hackerfest conference, Paul Henry, founder and CEO of Forensics & Recovery LLC and SANS Certified Instructor, stated that 90% of attacks exploit known vulnerabilities for which a patch already exists.
Although there are many areas to discuss when it comes to protecting our network and our information from cybercrime, this article will concentrate on websites. Here at RIT, the most common incident category for which the Information Security Office has to attend deals with website attacks. In addition, the SANS Institute ranked web application security exploits number eight in their 2008 list of “Top Ten Cyber Security Menaces.” Web security vendor ScanSafe states in their 2008 Annual Global Threat Report:
“In 2008, the Web was indisputably established as the preferred platform for malware distribution, with the majority of distribution occurring through mass compromise of legitimate websites. The sheer number of impacted websites is immeasurable, but certainly it is conservative to say that the number exceeds hundreds of thousands and is more likely in the millions.”
ScanSafe as well as OWASP, the Open Web Application Security Project, agree on naming vulnerable code as the main source of website vulnerabilities, with SQL injection and Cross-Site Scripting (XSS) as the most popular attack techniques.
These attacks allow the perpetrators to run their own code in the compromised computer, which could lead to the following problems:
Private and confidential information disclosure
Installation of malware on legitimate websites
Defacement of the website whereby it may be used for advertising of prescription drugs or various illegal activities
Turning the compromised computer into a “bot,” which means that it is now under the complete control of the individual who attacked it, who would have the same rights in the network as the compromised computer, and who can use it to conduct other attacks, including installing malware in other computers in the local network
Address Resolution Protocol (ARP) spoofing that could result in a denial of service attack, which renders the compromised systems unavailable
Alteration of data in databases, compromising data integrity
Stealing the compromised computer’s cookies for session hijacking, allowing the perpetrator to pose as the compromised machine on a user web application session
Websites that are susceptible to these types of attacks are those that have forms to be filled in by site visitors and those that have a database application in the background.
So, what can you do to defend your website from these attacks? Start by considering the use of RIT web resources for your website. These resources include RIT’s Online Learning’s Confluence wiki and people.rit.edu. These resources are supported by professional web and system administrators, who are familiar and experienced with systems security.
If you are unable to use RIT resources and need to develop a web application on your own, your application’s source code would be the first line of defense against intruders. Some steps you could take to secure your code are the following:
Familiarize yourself with the web development application (e.g., ASP.NET, PHP, Perl) that you use. It is extremely important that you are comfortable and familiar with your web development application in order to know how to avoid common coding pitfalls. Some ways to familiarize yourself with your web application are obtaining the necessary training, reading on-line resources, and sharing information with your peers.
Conduct code reviews. The sophistication and abundance of attacks are such that many times a vulnerability cannot be detected by a scanner or by conducting penetration testing. The best defense is looking at the code. Establish a quality control process for your web applications that involves using your peers to review your code. OWASP offers a free “Code Review Guide” on their website that can be used as a starting point for a code review process. According to this guide “…Despite the many claims that code review is too expensive or time consuming, there is no question that it is the fastest and most accurate way to find and diagnose many security problems. There are also dozens of serious security problems that simply can’t be found any other way.”
Validate and sanitize user input before executing it. In addition, avoid displaying user input, and, if this cannot be avoided, validate and sanitize it before displaying it.
Customize your error messages. Avoid giving away information such as whether a username is correct, what web application is being used, and the version number of the web application in use.
If your website is a blog, wiki, forum, or other similar application, review the content of postings by others. Postings could have malicious content that you will need to stop before they cause any damage. Also, require user authentication for any postings.
Connect to databases with the minimum required privileges. Never connect users as superusers or database owners.
Eliminate typical test user name and password combinations (test/test, admin/admin, guest/guest) before a website is put into production.
Do not store credit card numbers in your web server. The payment card industry has strict technical standards for systems that process credit card data. Vendors that take credit card numbers, even if only temporarily, need to comply with this standard. To address this issue, RIT utilizes a third party vendor for credit card processing through the use of an e-commerce web application. For further information regarding this e-commerce application, contact the Student Financial Services office.
Do not post RIT private and/or confidential information on websites that can be accessed by the general public.
Test your web application in a secure environment. Isolate the server from the outside world when the web application is under development and only allow minimal access when an outside world connection is needed for testing. Remember not to use actual/real data for testing; create your own test data.
Stay current with your web development application patches as well as with the OS patches of your web server.
Utilize RIT’s Information Security Office (ISO) quarterly web server vulnerability scan reports. Contact your system administrator to request the results of the scan for your web server.
Comply with the RIT Information Security Standards. RIT web servers are required to comply with the relevant Standards issued by the ISO. To determine the Standards with which your server needs to comply, please go to the Server Security Standard page.
Harden the security of your web server. If your web application grants it, do not just implement the level of security that is required by ISO Standards, go beyond. ISO Standards are produced for the whole Institute and, as such, have to remain at a level that is reasonable for all RIT systems. However, if your web application requires increased security, or if you are passing RIT credentials within your application, go the extra mile and make your server even more secure. The Payment Card Industry Data Security Standard (PCI DSS) – the standard mentioned above that is required by the payment card industry from vendors who process credit card data – is one of the most comprehensive and detailed technical standards currently available and can be used as a guide to what constitutes strong security for a web server. In addition, the ISO performs security reviews upon request. Their security report will provide you with suggestions and advice to improve security in your environment. Contact Infosec@rit.edu to request a security review.
Subscribe to the ITSTech mailing list to stay informed regarding the latest security issues affecting your web server and applications, RIT policies and procedures regarding web development and IT services, and many other areas of interest for web developers.
Report any incidents with your website to the ISO.