Is Your Website Secure?
11-1-2015The Internet can be very powerful and allows us to do some amazing things with data. But as Uncle Ben once said, "With great power, comes great responsibility." Ensuring your data is secure and safe in the constantly fluctuating battlefield of cyberspace is very important to us. This article will explain a few ways in which malicious users may attempt to put your data at risk. While not a comprehensive guide, this will serve as an eye-opener to the many things web developers have to be concerned about when it comes to security.
Protect Your Sessions
Two important concepts for web applications to protect against are Session Hijacking and Session Fixation. Any time you interact with a website, that website creates a unique session for you and your browser. Protecting that session is paramount. If an attacker can manipulate the website using your session, the website will not be able to distinguish your valid actions from those of an unwanted user. A malicious user may hijack a session using various approaches from "sniffing" data being sent across non-secure means, to inserting persistent cross-site scripting code to run in other users’ sessions.
Data sniffing can be stopped by having a Secure Socket Layer, also known as an SSL, on your website. You can tell when a site is secure because the URL will start with https:// instead of http://. You will also see a padlock icon in most browsers that can be clicked for more information. SSL's are relatively inexpensive and should be used anywhere where personal, or sensitive data is being sent or received. Some websites are even choosing to secure the entire site, rather than only securing forms or login sections of the site.
Tip: Even if a website is secure, sending email is NEVER secure. You should never send unencrypted personal or sensitive information over email as this can easily be intercepted, or could be stored on a computer that has the potential for getting hacked. You should only send this information within forms that have an SSL.
Cross-Site Scripting (XSS) uses scripts to run a malicious action. This can be reflected, using a direct link to run the script; or stored (also known as persistent) where a script is injected into the database and triggers each time that data is accessed. Sites that have comment sections or forms that submit to a database can be especially vulnerable to XSS. Developers can add validation to these forms which rely on whitelisting (allows only certain characters) or blacklisting (allows everything except the specified bad items). Most commonly, these would prevent custom HTML, JavaScript, or DIV tags from being entered into form fields.
The history of the Internet is riddled with famous examples of large and well-known companies falling victim to such attacks. One famous example is the "samy" hack. Through the use of a cross-site script, over one million MySpace user profiles were updated to say, “but most of all, samy is my hero.” A hacker used JavaScript in DIV tags so that whenever someone viewed a profile with this code, they would automatically be added as his friend and the quote above would be added to their profile; from there the code would propagate even further. After five hours, "samy" had 1 million friends and MySpace closed the site for repairs shortly after.
Protect Your Database
The last example of cybersecurity concerns is that of Structured Query Language (SQL) injection. Data stored on a database is very often stored and accessed via a programming language known as SQL. SQL injection is an attack to insert and have the database run unwanted SQL code, which can compromise the data within. For example, if a site uses SQL and it allows any text in a form to be run by its queries, an attacker may type SQL code in a form field that in essence means, “give me all the users’ login information, too!”
Session security and protection from SQL injection are just a couple of the many security risks web developers must be mindful of today. Fortunately, there are many tools to utilize and we at AVIBE take these situations seriously. The first step in defending a site from these risks is to develop sites with security in mind and avoid the naïve assumption that an attack will never happen.