Secure your Web Site Now!

The University's Information Security Office (ISO) has been scanning web sites on campus with greater-than-normal frequency lately looking for security issues, and this has generated a lot of security tickets!

If the issues uncovered by a scan are not addressed quickly, the ISO will quarantine the affected web site --- remove it from the network --- until the security issues are addressed. The best strategy is to secure your web site now, before the ISO finds something wrong with it that warrants putting it in quarantine.

There are many types of security issues found with web sites and web applications across campus.  Typically, they fall into one of five categories, though.  In this article, we will introduce you to these five common categories of vulnerabilities, describing briefly the type of issue, how to detect it; and how to fix it.

One of the most common issues is simply not performing software updates on the web server.  Out-of-date operating system, web server, database, or other software can present real security issues.  Fortunately, this is relatively easy to identify and to fix.  Most operating systems provide an easy way to check and update the operating system software, which usually includes the web server software and its supporting add-ons.  Out-of-date software is generally one of the easiest issues to find and fix, yet also one of the more common!  If you need help updating the software on your web server, please contact the CNS Help Desk for assistance at

Another common problem is out-of-date, weak, self-signed, misconfigured, or just plain missing SSL certificates.  You can check your web site's SSL certificates by going to and  entering your web site in the "Hostname:" field.  This will give you a letter grade for your site, telling you what, if anything, is wrong with it, as well as some information on how to fix it.  If you need help updating the SSL certificate or SSL configuration on your web server,  please contact the CNS Help Desk for assistance at

The third category of issues are Injection issues.  An injection issue occurs when untrusted data is sent to an interpreter, such as an SQL interpreter, as part of a command or query. The attacker's hostile data can trick the interpreter into executing commands or accessing data without proper authorization. In severe cases, it can result in data loss or even the complete takeover of the web server host!  There are several ways to detect if your code is vulnerable to injection.  One is a code review.  Another is to use a scanner like the ISO's Self Scan Tool.  Fixing these types of issues requires code changes to restrict what can be passed in a text string to the interpreters for processing.  Contact the CNS Help Desk at or the ISO at if you want help reviewing your web site for injection vulnerabilities.

The fourth category of issues are cross-site scripting (XSS) issues.  XSS occurs whenever an application takes untrusted data and sends it back to a web browser without proper validation or escaping.  XSS allows the attacker to execute a script in the victim's web browser, which can be used to hijack web sessions, deface web sites, redirect users to malicious sites, or in some cases even download malware like a virus or trojan. Again, the ways to detect if your code is vulnerable to XSS attacks is via code review, and automated scanners like the ISO's Self Scan tool. Fixing them can be done via input validation, input sanitization, or output encoding.  Contact the CNS Help Desk at or the ISO at if you want help reviewing your web site for XSS vulnerabilities, or fixing them.

The final category of vulnerability can result in cross-site request forgery (CSRF).  This occurs when a user is already authenticated into a web application or system and browses to a site that sends unauthorized commands to that web application as the authenticated user.  These types of attacks do not typically release unauthorized data, but allow for data modification.  The best way to avoid these types of attacks is to embed and expect additional authentication metrics in requests to your application.  This allows the application to discriminate requests coming from itself vs unauthorized sources.  For example, giving a unique token for each request that is generated and embedded into forms as a hidden field makes it impossible for a 3rd party to successfully send commands, since they do not have the key embedded with their request.

While there are other possible vulnerabilities, the above five are the most common ones we see on campus.  If you ignore them, chances are that the ISO will eventually find the vulnerabilities in your site and schedule a quarantine.  Worse, you may be leaving yourself, or your customers, at risk.  The best thing to do is to be proactive, check your web sites now, and secure them before the ISO comes knocking.

Written by Eric Rostetter, Senior System Administrator
Questions or comments? The best and easiest way to contact us is via the CNS Help Desk form.