Tag Archives: Information Security

Measuring the Occurrence of Security-Related Bugs through Software Evolution

Posted on by
Reply

You can actually measure the number of the security-related bugs of a project by using the corresponding static analysis tools (depending on the programming language that you used) but you cannot check how they evolve over time.

To involve the aspect of time we can take advantage of the characteristics of version control systems (VCS). As we all know, to manage large software projects, developers employ such systems like Subversion and Github. Such systems can provide project contributors with major advantages like: automatic backups, sharing on multiple computers, maintaining different versions and others. For every new contribution, which is known as a commit, a VCS system goes to a new state, which is called a revision. Every revision stored in a repository represents the state of every single file at a specific point of time.

To measure the occurrence of security-related bugs through time, together with two colleagues, we combined FindBugs, an effective static analysis tool that runs over bytecode and has already been used in research, and Alitheia Core, an extensible platform designed for performing large-scale software quality evaluation studies. I will not spoil your time by describing the integration of the two (you can check it in the proceedings of this conference). I will go one step further and describe how the framework works: First, Alitheia Core checks out a project from its SVN repository. Then, for every revision of this project, the framework creates a build. Then it invokes FindBugs to examine this build and create an analysis report. A user can select whether to examine the project alone or the project together with its dependencies. Finally, from this report, it retrieves the security-related bugs.

We have examined four open source projects that are based on the Maven build system namely: xlite, sxc, javancss, and grepo. We particularly chose Maven-based projects to exploit the advantages of the system such as: resolving and downloading dependencies on the fly and automatically build every revision. In addition, all projects deal with untrusted input, thus they could become targets for exploits. Our experiment included two measurements. First, for every revision, we applied FindBugs only to the bytecode of a specified project. Then for our second one, we also included the dependencies of this project. The figure below depicts the results for the javancss project. The results are representative for all four projects. The red line represents the first measurement and the green line the second one.

Bug frequency for javancss project

The most interesting observation that we can make is that the security bugs are increasing as projects evolve. This is quite important and shows that bugs should be fixed in time to decrease the effort and cost of the security audits after the end of the development process. Another observation is the existence of the domino effect. The usage of external libraries introduces new bugs. Thus, we can observe how third-party software can affect the evolution of a project while its developers are unaware of that. Another interesting issue regards the bugs themselves. As we observed, even after hundreds of revisions, in the release versions there are bugs that could be severe for the application. For instance, the last revision of javancss includes a code fragment that creates an SQL statement from a non-constant string. If this string is not checked properly, an SQL injection attack is prominent.

At first glance you could say that as a project evolves, the lines of code increase and as a result, the security-related bugs should increase too. But you cannot support this with confidence since there are techniques like refactoring that could decrease the project’s code as time passes. Hence, it could be interesting to check if there is a correlation between the lines of code and the security bugs of a project.

The main limitation of our approach is that it has to build automatically numerous revisions and run FindBugs on the created jars. This is not convenient since most Maven-based projects exist on GitHub. To validate the statistical significance of our results we should run our framework on more projects. This can be done by managing data from GitHub and we are currently working towards this direction.

The code of our framework can be found here.

To share or not to share: The Security Risks of Social Networking

Posted on by
Reply

If you are not using Facebook, Twitter, YouTube, Linked In, or any of the social networks that are currently monopolizing the interest of web users, please stop reading. Well, given the fact that many of them are included in the Top 20 list of the most visited websites I presume that you are still here.

There are numerous reasons for people to join such a network including: keeping up with old friends, sharing music, photos and videos, finding job opportunities, starting up a small business, promoting it, connecting to causes and many others. To deliver such services, social networks contain and distribute huge amounts of sensitive information. This fact raises many security threats that involve scam artists, stalkers, identity thieves and companies that gather information to gain marketing advantages. Even if it is impossible to escape all the social network-related risks that exist, there are a few steps that you can take to reduce them.

First of all you have to be skeptical about the information you share. Some people share too much while their information can be shared more widely than they wished if they don’t set the network’s privacy controls. Before you share something, you have to be discreet and wary. Specifically, never type anything that would expose you to unwanted persons and remember that people on the Internet are not always who they seem to be. Also, you have to keep in mind that there are social networks that do not guarantee the security of the information shared through a profile, a group etc. For instance, as of May 7, 2010, Facebook’s privacy policy mentioned that it could not guarantee that only authorized persons will view a user’s information. The social network-related security flaws that come to light very often exhibit the above fact.

Most social networks employ some sort of application system where a developer is able to write code and develop third-party applications, which are executed within the social network and have access to content that is only available to the network’s provider (for example the public information of a user). Such applications include quizzes, games to play with other users, polls and others. Apart from the public information of a user, a third-party application may access some private information even if the user is not aware that this is happening. Actually, such an application may also gain access to the personal information of a user’s contacts even if those contacts have not granted any explicit permission to the application. Also, this kind of applications may contain malware designed to attack your computer or maliciously use your data. In addition, scammers can also utilize such applications in order to waste your time and resources. So when you are about to use a new application that was suggested to you remember to always think twice.

A malicious user does not have to develop an application to harm you. A simple personal message could be enough to form a phishing-like attack. Hence, you don’t have to click on everything that is sent to you. Especially on all these shortened URL’s that are popping up everywhere and are commonly accepted as links to relevant and valuable information despite their “disguise”.

Advertisers can be very interested in using the data that social networks collect (i.e. exploring the “favorite movies” section of millions of user profiles could be vital for a film studio). Such data can be used as a basis for behavioral targeting. But currently there are no limits on the ways advertisers can gather and use this kind of data. As a result, there are several concerns regarding this kind of advertising since user privacy attracts little consideration. For example, there are third-party applications that transmit specific information to companies without notifying users.

Social network security has attracted the interest of researchers and practitioners many times. If you want to learn more about this field you can check this white paper by Brad Dinerman called “Social networking and security risks”. Furthermore, you can have a look on how a person’s mishandlings in the social network context, can pose a security threat to her university and college network in “Who’s really in your top 8: network security in the age of social networking” by Robert Gibson. Finally, if you want to learn more about the security and privacy in social networks and how they can be ensured, you can refer to “Security and privacy in online social networks: A survey”, which is a very good survey by Novak et al.

How secure is your software?

Posted on by
Reply

When you are implementing an application, your first goal is to achieve a specific functionality. For instance, if you want to implement a specific algorithm that was given to you as an exercise from your informatics course professor, or you just want to create your personal website, the first thing that comes to mind is how to “make it work”. Then of course, you will follow some code conventions during implementation while simultaneously check your code quality. But how about security? How secure is your code? Is there a way for a malicious user to harm you or your application by taking advantage of potential bugs that exist in your code?

Unfortunately, most programmers have been trained in terms of writing code that implements the required functionality without considering its many security aspects. Most software vulnerabilities derive from a relatively small number of common programming errors that lead to security holes. For example, according to SANS (Security Leadership Essentials For Managers) two programming flaws alone were responsible for more than 1.5 million security breaches during 2008.

In 2001 when software security was first introduced as a field, information security was mainly associated with network security, operating systems security and viral software. Until then, there were hundreds of millions of applications implemented but not with security in mind. As a result, the vulnerabilities “hidden” in these (now legacy) applications can still be used as backdoors that lead to security breaches.

Although, nowadays computer security is standard fare in academic curricula around the globe, few courses emphasize on secure coding practices. For instance, during a standard introductory C course, students may not learn that using the gets function could make their code vulnerable to an exploit. Even if someone includes it in a program, while compiling he or she will get the following obscure warning: “the ‘gets’ function is dangerous and should not be used.”. Well, gets is dangerous because it is possible for the user to crash the program by typing too much into the command prompt. In addition, it cannot detect the end of available memory, so if you allocate an amount of memory too small for the purpose, it can cause a segmentation fault and crash.

The situation is similar in web programming. Programmers are not aware of security loopholes inherent to the code they write; in fact, knowing that they program using higher level languages than those prone to security exploits, they may assume that these render their application immune from exploits stemming from coding errors. Common traps into which programmers fall concerns user input validation, the sanitization of data that is sent to other systems, the lack of definition of security requirements, the encoding of data that comes from an untrusted source and others which we will have the opportunity to discuss later on this blog.

Today there are numerous books, papers and security bulletin providers that you can refer to about software security. Building Secure Software by Viega et al., Writing Secure Code by Howard et al. and Secure Coding: Principles & Practices by Graff et al. are three standard textbooks that you can refer to. Furthermore, there are some interesting lists that quote secure coding practices like OWASP’s (The Open Web Application Security Project), CERT’s (Carnegie Mellon’s Computer Emergency Response Team) and Microsoft’s. Also it is interesting to check from time to time the various lists that contain top software defects like CWE’s (Common Weakness Enumeretion) Top 25 and OWASP’s Top 10. But do not panic, you are not obliged to become an expert in secure coding. There are numerous tools that can help you either build secure applications or protect existing ones.