Staying Secure on the Go with Seven Must-Have Firefox Add-Ons

When you're out and about with your laptop, you probably like to frequent spots where you know you can score easy access to the Internet via a hotspot. When you're outside your own home network, though, which you've probably secured with a password against strangers, you're often at your most vulnerable. You never know who you're sharing a network with.

Fifteen years ago the floppy disk was the most common vector used by malware writers to spread viruses, and in more recent years email has been the primary vector. But the trend now seems towards spreading malware and exploiting vulnerabilities using malicious code on websites to exploit browser vulnerabilities.

According to IBM Internet Security Systems X-Force team's 2008 Trend & Risk Report "the number of vulnerabilities affecting Web applications has grown at a staggering rate. In 2008, vulnerabilities affecting Web server applications accounted for 54 percent of all vulnerability disclosures and were one of the primary factors in the overall growth of vulnerability disclosures during the year."

To minimize the risk of succumbing to a Web-borne attack then, it's essential that you use the Web as safely as possible, and the first thing to decide upon is a browser. The two most popular choices are Microsoft's Internet Explorer and Mozilla Firefox, and there's some debate about which one is more secure.

It's certainly true that Explorer is used by far more people than Firefox (due to it's being part of the Windows operating system) so one could argue that, all things being equal, choosing the minority browser is the sensible choice because it offers a smaller (and thus less tempting) pool of potential victims to malware writers.

Ensuring that the browser is up to date can help minimize security risks, but perhaps the most interesting feature of Firefox from a security perspective is the possibility of enhancing the browser's security with the addition of browser extensions or add-ons. Of course any add-ons risks adding new vulnerabilities, but if they protect against known problems at the expense of possibly adding as-yet unknown ones, then the trade-off may well be worth it.

With that proviso, here are some important add-ons to consider for anyone browsing the Web outside a trusted network and to protect against Web-based exploits as well as more general security risks. All are available from http://addons.mozilla.org.

1. NoScript

This Firefox extension allows the user to enable or disable Java, JavaScript, Flash, Silverlight, and other plug-ins (which could be malicious) for all sites unless the sites are specifically marked as trusted, which can be configured directly from the status bar. These settings can also be temporarily allowed on any given site without adding it to a whitelist.

NoScript also protects against Cross Site Scripting attacks, and ClickJacking (also known as UI Redressing) attacks that cause users to click on buttons that are obscured by other page elements.

2. CS Lite

This simple add-on allows users to selectively or globally block cookies from websites, and view edit and delete them directly from the status bar. It does for cookies what NoScript does for scripts and plug-ins.

3. ShowIP

ShowIP helps against phishing attacks by displaying the IP address of the current website in the status bar at the bottom of the browser. While this is of limited use in itself (unless the user happens to know the IP address of the Web site they want to visit,) right clicking on the IP address shown in the status bar brings up a number of options, including running a whois lookup to confirm the registered owner of the IP address concerned.

4. WOT (Web of Trust)

The WOT add-on gives a trustworthiness rating for sites that users visit based on feedback from other WOT users. The rating is accessible from a WOT button in the address toolbar.

The button itself changes color depending on the trustworthiness of the site, giving an instant warning when a user visits a site that may be a source of malware. For some sites, such as those rated dangerous, WOT brings up a warning screen with the options to proceed to the site, add it to a whitelist, or to find out more information about the nature of the dangers that other users have reported.

5. Foxmarks

There's always a danger with laptop computing that bookmarks for sites on your desktop computer won't be available on your laptop. If you then type in the address of the site manually there's the possibility that you could misspell it, and end up on a malicious Web site inadvertently.

Foxmarks (now called Xmarks) helps prevent this by syncing your laptop and desktop bookmarks, so you can access frequently visited sites via bookmarks that are known to work. Foxmarks can also sync Web site passwords (protected by a PIN) so that passwords stored on a desktop machine by Firefox's password manager are also available without having to write them down for use on the road.

This also makes it more practical to change passwords frequently and store them within Firefox without having to worry about keeping the password stores on different computers synchronized.

6. Master Password Timeout

Firefox has the ability to remember and enter passwords for sites you may visit, and these passwords can be protected with a master password. If the master password is long and not guessable but stored in your head (i.e. not written down) then having Firefox remember passwords can be a very secure solution.

The problem is that once the master password is entered Firefox gives you access to passwords without prompting for the master password until it detects five minutes of inactivity. This is a potential security risk if you leave the laptop unattended for a minute or two in a public place.

To prevent this, Master Password Timeout allows you to specify your own, shorter timeout period. The master password can also be "logged off" manually from the Tools menu once Master Password Timeout is installed.

7. FireGPG

The use of encryption and digital signatures are important ways of maintaining the security of communications that are sent over insecure channels such as the Internet when a VPN is not available. FireGPG allows users to encrypt, decrypt, sign and verify the signature of text from within Firefox from a FireGPG item in the Tools menu. It also adds buttons to the Gmail Web page carrying out the same functions. Note: FireGPG requires that GnuPrivacyGuard (GPG) is installed on the laptop computer.

Exploring Office 2007: Working with Sequentially Numbered Tickets in Word 2007

Creating tickets and other sequentially numbered elements in Microsoft Word 2007 documents isn't an intuitive process. However, there is a built-in tool in Word that you can use to simplify the process. Using this, you can create documents with sequentially numbered elements such as a design that gives you tickets and ticket stubs with matching numbers.

» Create the Document

To see how this might be done, create a new Word 2007 document and choose Insert > Table and create a two-column, five-row table. Size the table cells so that the entire table fits the sheet of paper. To do this, drag the bottom border of the table downwards so it sits just above the bottom margin of the page. Click inside the table and choose Table Tools > Layout and from the Cell Size group select Distribute Rows.

Configure the starting number for the tickets — here we have used 1000

Drag the middle table divider to the left so that you have a small section on the left and a larger area on the right. Select the first column by clicking in the table and from the Table Tools > Layout tab choose Select > Select Column. Again, from the Table Tools > Layout tab on the ribbon, locate the Alignment options and click the Text Direction button to select a rotated option.

Format the tickets as desired — for example, you may want to remove the table border lines and type your text into the ticket areas on the right. Ultimately, you will print the pages and cut each sheet to create the 5 tickets and stubs.

» Number the Tickets

To add the ticket numbers, click in the top left cell, which is the stub for the first ticket. Choose Insert > Quick Parts > Field to display the Field dialog. From the Categories list choose Numbering, and from the Field Names list choose SEQ.

In the Advanced Field Properties area, click after the word SEQ and type ticketno. This is the name we are using to identify the auto numbering sequence — we must use this each time we refer to this sequence.

Click the Options button, select the Field Specific Switches tab, and select the \r switch. Click the Add to Field button and after the \r in the field codes area, type the number that you will use for the first ticket — 1000, for example. Click OK twice to end. If you see field codes instead of numbers, click inside the field code and press Shift + F9 to display the results rather than the field code itself.

The cell to the right gets the same number as the ticket stub value

This starts the numbering sequence by seeding the first number at 1,000. Click in the second cell in the first row, which is where the ticket number will appear again. Repeat the process and choose Insert tab > Quick Parts > Field and reselect the SEQ field.

Again, after the word SEQ, type ticketno and click Options > Field Specific Switches tab. This time choose the \c switch and click Add to field and then OK twice. The \c switch tells Word to insert the copy of the nearest number in this position so the same number will be repeated.

» Copying the Data

The field code from the second column of the table can be copied down to the cells below. Don't worry at this stage if the numbering isn't correct — it won't be. You will, however, need to add a different field code into the second cell in the leftmost column — this field code will be the next number in the sequence.

To do this, click in the cell and choose Insert tab > Quick Parts > Field and again select the SEQ field. Type the word ticketno in the field codes area and again choose Options > Field Specific Switches tab and this time choose the \n switch, which adds the next number in the sequence. Copy the contents of the second cell in the left column down to the other cells in the left column of the table.

The numbering may not look correct yet — to fix this, update the field codes by pressing Ctrl + A and then F9 — this selects the document and updates all field codes.

Security for the Rest of Us: An Industry Perspective on the Secure-Software Challenge

Developing secure software is easy! Just don't have any bugs. Oh, and use security APIs correctly, and make sure your software doesn't have any undocumented functionality or side effects, doesn't have race conditions, and doesn't use unsafe environment variables or any other input, for that matter. It also needs to mediate completely any access to any protected resource. The mediation must be tamper-proof, nonbypassable, and small enough to verify its correctness. Your software's security should support the users' needs. It should also be easy for users to figure out, set up, and inspect, even if they do it only once a year and don't bother to read documentation or stay up-to-date on the latest attacks and defense techniques. All this stuff must not affect your budget, development schedule, or, of course, the functionality of the software you're building (what the customers are really paying for!). Easy, huh?

Joking aside, while security was once a specialty of interest to only a few programmers, it's now a critical topic for almost all software engineers, project managers, and decision makers. This is not only because pervasive software insecurity has been in the news for the last several years but also because all software developers now feel the pressure (or at least expectations) from end users to deliver secure software.

Yet no company can afford to throw away all its existing software and redevelop it from scratch or retrain all software developers to be security experts. This is why we need methods, processes, and tools for improving the security of software created by a wide range of developers with a wide range of resource constraints, development methods, time-to-market schedules, contexts, and organizational and national cultures.

Historically, many publications specializing in security have focused on the development of software for security-critical domains (for example, military, safety critical, and government), where the production cost and time-to-market are, although nonnegligible, of secondary concern. Unlike those publications, this special issue focuses on creating and maintaining secure software by the wide range of developers who constitute the software industry—many who work in domains where cost (both production and maintenance) and time-to-market are the main driving factors.

What's special about software security?

Back to Top

When most people think about software security, they think about authentication, encryption, and access control. All these security features are important, but security features alone don't make a system secure. A system's design and the techniques used to construct it have as much, if not more, impact on the system's eventual security. Why would an attacker break encryption if he or she can just exploit a buffer overflow? Why crack passwords if the attacker can bypass the authentication system entirely by typing a special URL into his or her browser?

When the Internet was younger, organizations tried to cordon off vulnerable software by putting up firewalls. A firewall would protect a vulnerable internal network from the ravages of the unruly Internet. The problem is that customers are increasingly demanding software that communicates and interoperates with other systems. Such programs must be designed and built so that they can handle attacks and intentional misuse.

Software vendors can't solve the digital security problem alone. They have to rely on secure networks and system administrators who think about security when deploying new services. Developers also have to rely on users to make reasonable choices about security. But developers can't just throw up their hands and treat security as someone else's job. Also, techniques for building high-reliability systems won't necessarily help developers build adequately secure systems. For example, redundancy is good for combating independent random events, but an attacker who can force a system to fail can often just as easily cause a redundant system to fail.

In this issue

Back to Top

Getting security right is hard because an attacker—having virtually unlimited time—needs to find only one vulnerability in a system to succeed, whereas the defender—constrained in time—must ensure that the system has no weak points. Software systems are specifically difficult because of their inherent high complexity (Windows Vista, for example, is rumored to comprise 60 million lines of source code), connectivity, and extensibility. On top of that, software systems aren't linear or continuous, which makes their analysis and testing (either functional or security specific) even harder.

Security bugs themselves are harder to catch. They show up not only as a lack of required functionality (for example, missing authentication) but also as incorrect implementations (for example, easy-to-spoof authentication) or, even worse, as unintended, undocumented, or unknown "features" (for example, buffer overflow in authentication). Charlie Lai discusses several such unintended side effects of Java constructs in this special issue. His article, "Java Insecurity: Accounting for Subtleties That Can Compromise Code," examines three fundamental (and language-agnostic) coding guidelines that Java developers commonly follow to ensure their programs are safe: minimizing accessibility, creating copies of mutable inputs, and preventing the unauthorized construction of sensitive classes. But rather than focusing on the guidelines themselves, he explores the subtleties involved in applying them in Java and suggests approaches Java developers can use to account for them in their work.

But before developers can even have a chance to deal with design or implementation vulnerabilities, they need to properly collect and analyze security requirements. The right set of security requirements will lead to security features and an implementation focus that's appropriate for the job at hand, whereas the wrong requirements can lead to a never-ending cycle of security failures and associated finger-pointing. This nontrivial exercise gets even harder if developers who aren't security experts will manage the process. "Security Requirements for the Rest of Us: A Survey," by Inger Anne T�ndel, Martin Gilje Jaatun, and Per H�kon Meland, examines how people elicit and record security requirements for software projects. The authors present their own requirements methodology and argue for bringing security awareness to all participants in a software development project.

Another important security-specific activity that must be properly done during requirements and design phases is threat analysis—the analysis of what can go wrong. Even in theory, building a 100-percent secure yet usable system is impossible, without regard to budget and time-to-market constraints. So, developers must identify and prioritize threats to the system. Only then can they design countermeasures against the most critical threats and build them into the system. Jeffrey Ingalsbe, Louis Kunimatsu, Tim Baeten, and Nancy Mead reflect on their team's threat-modeling experiences at Ford Motor Company. In "Threat Modeling: Diving into the Deep End," they discuss how they applied the Microsoft Threat Analysis and Modeling process to a dozen projects, what benefits they realized, and what lessons they learned.

Despite all the advances in security technologies, development of secure software remains costly. For example, Microsoft has spent over US$200 million since 2003 on its Security Development Lifecycle, according to Steve Lipner, Microsoft's Senior Director of Security Engineering Strategy in Trustworthy Computing. The amount of investment in security is a risk management decision: what's the likelihood of an attack, and what are an attack's likely consequences? Estimating the answers to those questions is tricky. Shari Lawrence Pfleeger and Rachel Rue begin their article, "Cybersecurity Economic Issues: Clearing the Path to Good Practice," with a simple observation: time, money, and good people are always in short supply. So how much time, money, or effort should you devote to security? The authors explore how organizations search for answers and what obstacles they often encounter. They discuss how to gather the right data and make good trade-offs between cost and level of protection. They present a framework for comparing economic security models so that stakeholders can make the right investments in security.

Conclusion

Back to Top

This special issue reports on the state of the practice and recent advances in engineering secure software for the wide range of industrial application domains. The articles explore practical and pragmatic ways of meeting this challenge; we hope you find them helpful in your work.

Konstantin (Kosta) Beznosov is an assistant professor in the University of British Columbia's Department of Electrical and Computer Engineering. He founded and leads the university's Laboratory for Education and Research in Secure Systems Engineering. He previously was a security architect with Hitachi Computer Products (America), where he designed and developed products for security integration of enterprise applications. He has also been a consultant for large telecommunication and banking companies on the architecture of security solutions for distributed enterprise applications. He's a coauthor of Enterprise Security with EJB and CORBA (John Wiley & Sons, 2001) and Mastering Web Services Security (John Wiley & Sons, 2003). He received his PhD in computer science from Florida International University. Contact him at the Dept. of Electrical and Computer Eng., Univ. of British Columbia, 4047-2332 Main Mall, Vancouver, BC V6T 1Z4, Canada; beznosov@ece.ubc.ca.

Brian Chess is a founder of and chief scientist at Fortify Software, where he focuses on practical methods for creating secure systems. Secure Programming with Static Analysis (Addison-Wesley, 2007), which he cowrote with Jacob West, shows how static source code analysis is indispensable for getting security right. He received his PhD in computer engineering from the University of California at Santa Cruz. Contact him at 2215 Bridgepointe Pkwy., Ste. 400, San Mateo, CA 94404; brian@fortify.com.

RSS Content Generator Enterprise 3.9.64

RSS Content Generator is a comprehensive website generator from free RSS feeds (news, press releases and articles) to boost up your search engine rankings or make money with Google AdSense or another advertising program. RSS Content Generator can automatically download new RSS feeds, update your site with your structure and design and upload it to your server - all without your intervention.