Browser "Safe Site" Plugins

Jason Lam's recent ISC diary post about WOT reminded me that we haven't reviewed browser security plugins for site recommendations recently. There are at least twoo browser plugins that can be useful for less savvy users when browsing the Internet, including:

• WOT
• McAfee's Site Advisor

BlueCoat's K9 is a bit different and provides features including activity reporting, safe search enforcement, time restrictions, and many other features more appropriate to a parental controls environment.

What browser plugins do you recommend to your non-technical users?

Wireshark 1.2 Released, Portable Wireshark Reminder

Wireshark 1.2 is out, and if you're a Wireshark user, two of the features make this a worthwhile upgrade. First, a big bonus for casual and occasion users - display filters now autocomplete, meaning that searching for the proper syntax won't be quite as painful. Second, support for IP packet comparison was added, making one of the things I do often easier - comparison of packets to determine where a break point is.

As a reminder, you can also run Wireshark as a portable app on a PortableApps enabled device. That makes Wireshark an easy tool to provide to your system administrators and security staff. Note that if WinPCap isn't installed, this portable version will install it as needed, then uninstall it when complete - this isn't an entirely zero footprint portable app.

Facebook Privacy: The App Gap

Joseph Bonneau's article "How Privacy Fails: The Facebook Privacy Debacle" points to deeper application data sharing concerns with Facebook's enforcement. His digging showed session parameters being passed to 3rd parties, in violation of Facebook's rules. More details on this issue can be found here.

These issues will make a great addition to awareness materials I'm preparing - while AllFacebook's 10 Privacy Settings are becoming more widely known, the risks of providing data to the whole host of quizzes, tests, and throwaway apps that populate Facebook are still largely unexplored by most users.

Changing Gmail For The Better - A Campaign for S/MIME

Many of us use Gmail for daily personal use. Some use it in their enterprise. What's missing? S/MIME support.

Fortunately, Google allows you to suggest desired functionality. Please join me in suggesting S/MIME support be added to Gmail.

Security bloggers and others, I invite you do make the same call to your audience. S/MIME support would offer a host of benefits, from greater functionality for Google's enterprise and higher education Gmail platforms to better trust models amongst Gmail users.

The Rise and Fall of E-Gold

Wired has a great article about the rise and fall of E-Gold, including details on how carders and others used the service to transfer funds. Well worth a read.

Homework Submissions: Beating Corrupted Files

Bruce Schneier recently wrote a blurb on the discussion of corrupted files for homework submission that has been making the rounds. Fortunately for professors and instructors, there are a number of ways to deal with corrupt files:

1. For these specific files, MD5 checksums have already been created.
2. For most Office documents, some data can be viewed by simply opening a file using Notepad or VI. This will help determine if the file has any actual relevant content - and will point to a fake file quite quickly.
3. Simply checking files soon after they are submitted will result in students not getting much of a delay. This is also a good time to check the creator and other metadata on files.

While turning in a corrupted file may sound clever, it shouldn't work more than once for technically aware faculty members. Students will have to return to trying to get their email to be timestamped earlier than the submission date, or any of the other tricks that are often attempted when submitting electronically.

Sprinkling XSS In Your Cookies

Creative Commons attribution licensed image courtesy scuba67

A recent web application vulnerability scan came back with an interesting result - automated cross site scripting tests were showing positive results in cookies.

"Wait! That can't be!" you say, knowing that cookies typically don't contain user visible content that their browser would interpret.

That was my reaction as well, so I went digging. Our environment uses ColdFusion for some application development, so most cookie handling is done via ColdFusion's built in cookie management tools. How was a cookie's content being rolled into the page?

Further digging showed that the error only showed on error pages, and consultation with the developer said that those pages were automatically generated by ColdFusion, and were not custom to his application. This is where having sharp developers comes in handy - the developer paused, looked more closely at the page and noted that he had requested a scan in our development environment - and that the ColdFusion error messages were disabled in our pre-prod and production environments.

Users would never see the XSS in any public facing environment - and, better, would only see the XSS in an error page, not in any valid user page. A false positive due to compensating controls and a very low risk profile even without them.

So, yes, you can have XSS in cookies, but it isn't as tasty as it might sound.

And the sharp developer? He and a co-worker went back through their ColdFusion framework and wrote back to me that the discovery had inspired them to armor their standard framework against similar issues in the future - they proactively updated it and will add that update to all of their standard framework applications.