The Center for Education and Research in Information Assurance and Security (CERIAS)

The Center for Education and Research in
Information Assurance and Security (CERIAS)

CERIAS Blog

Page Content

PHPSecInfo Released; Celebrity Status Imminent

Share:

So we finally went public with PHPSecInfo as an official project of the PHP Security Consortium.

phpsecinfo_ss

I just was interviewed by Cal Evans for the Zend Developer Zone, which was pretty cool—it was nice to talk to him again.  He said the story should be posted sometime this weekend or Monday.

Who do you trust?

Share:

In my earlier posts on passwords, I noted that I approach on-line password “vaults” with caution.  I have no reason to doubt that the many password services, secure email services, and other encrypted network services are legitimate.  However, I am unable to adequately verify that such is the case for anything I would truly want to protect.  It is also possible that some employee has compromised the software, or a rootkit has been installed, so even if the service was designed to be legitimate, it is nonetheless compromised without the rightful owners knowledge.

For a similar reason, I don’t use the same password at multiple sites—I use a different password for each, so if one site is “dishonest” (or compromised) I don’t lose security at all my sites.

For items that I don’t value very much, the convenience of an online vault service might outweigh my paranoia—but that hasn’t happened yet.

Today I ran across this:
MyBlackBook [ver 1.85 live] - Internet’s First Secure & Confidential Online Sex Log!

My first thought is “Wow!  What a way to datamine information on potential hot dates!” grin 

That quickly led to the realization that this is an *incredible* tool for collecting blackmail information.  Even if the people operating it are legit (and I have no reason to doubt that they are anything but honest), this site will be a prime target for criminals.

It may also be a prime target for lawyers seeking information on personal damages, divorce actions, and more.

My bottom line: don’t store things remotely online, even in “secure” storage, unless you wouldn’t mind that they get published in a blog somewhere—or worse.  Of course, storing online locally with poor security is not really that much better…..

A great example of how NOT to save passwords

Share:

See this account of how someone modified some roadside signs that were password protected.  Oops!  Not the way to protect a password.  Even the aliens know that.

ZUG: Comedy Articles: Electronic Road Signs and Me:

The New Security Seminar Podcast

Share:

We’ve made some significant changes to how people can view our Security Seminar Series:

  • We’re now offering h.264/mp4 versions of the seminar videos, both as downloadable files and in a spanking-new video podcast.  Look us up in iTunes or the Democracy channel guide, and you’ll find us.  The 320x240 videos are not only higher-quality than what we’ve previously offered, but are also playable on portable players than support h.264 (we’ve tested it on 5G iPods)
  •      
  • We will also look at encoding all of our previous recorded seminars to h.264/mp4 in the next few months.  Those that we have on DVD will be easy, but the ones more than a couple years old we only have on VHS, so they will likely take a lot longer.
  • In the near future — at latest by summer 2007 — we will stop encoding our videos in RealMedia format.  The popularity of Real has faded a lot over the years, and most folks (including us) aren’t interested in installing it.  This would leave us without a streaming video format, but we’re not sure there’s a lot of demand for one now.  If there is, we will likely go with an embedded Flash video player rather than something like Windows Media.

If there is strong interest in providing other video formats, please let us know.  We may consider moving to 640x480 resolution for our videos now that iPods support the larger size, but we don’t want to push the file size to high and make for lengthy downloads.

If you have problems or feedback, please let us know in the comments section.

So you think AJAX and Web 2.0 are all that and a bag of chips

Share:

You know, I would feel a lot better about this technology if someone had fixed basic problems with the way browsers handle JavaScript, about JavaScript policy specifications and compliance testing, and if there were good, usable and mature static analysis tools that could detect cross-site scripting vulnerabilities (Pixy by Jovanovic et al. comes to mind as a promising open source tool), and if people used them.  These problems have been known for a long time.

  1. Same origin policy and shared servers.  So, my home page is http://homes.cerias.purdue.edu/~pmeunier/;  if I put a nasty javascript there, it can access or change the contents of other CERIAS home pages if you follow a link from my page, or if my page opens another home page for you.  I made a demo which for Safari users displays Adam Hammer’s home page url but with contents of my choosing (with apologies to Adam).  Firefox is a bit smarter and the url displayed is instead that of my page, which could clue attentive users to the fact that the content really comes from elsewhere.  Adam doesn’t actually have a home page there.
  2. Modern browsers still can’t survive a visit to this site (WARNING!  Your browser will likely crash or become unusable when you click buttons on that site):  Nasty Javascript Bombs (I didn’t try all browsers, like Opera, but Safari died horrible deaths)
  3. Modern browsers can still be captured:  Firefox users visit (WARNING!  you won’t be able to return) the jail, do not collect $200.
  4. Searching for JavaScript-related vulnerabilities in 2006 in the National Vulnerability Database gives 124 matches (and the year is not even over).  3 of those are accidental hits (because “javascript” was part of a file name or such).  About 50% are cross-site scripting vulnerabilities, that could include the above Javascript (and likely worse code than changing your choice of hero). About 40% are coding errors in the JavaScript implementation.  About 10% are still issues with the enforcement of JavaScript default security policies, or things that should explicitly be stated as part of default policies (e.g, CVE-2006-2900 and CVE-2006-2894, abusing Javascript keystroke events to trick users into typing where they didn’t mean to).  Cross-site scripting vulnerabilities are hard to avoid because scripts can be embedded almost anywhere inside HTML.  The separation between code (JavaScript) and data (HTML) is flimsy and complex.  I predict that XSS vulnerabilities will be to AJAX applications what buffer overflows and format string vulnerabilities are to C:  a real pain.  There is no sign that browsers have matured enough yet to be trusted in handling JavaScript safely, and this will likely continue for many years.
  5. Perfectly compliant JavaScript and browsers can be used to scan internal networks and even perform limited exploits.
  6. JavaScript seems to be used most of the time to perform tasks that are user-unfriendly (hide user interface elements and generally remove control from the user, create pop-unders, show ads, track you by history, etc…).  So, I should expose myself to these, and the above and future vulnerabilities, so you can program something that’s a little slicker, or poorly duplicates the functionality of executables on my system?  Huh.

So, tell me again;  do you really want to build castles on that foundation?  It sounds like a bad idea to me.  We can always hope that eventually, AJAX horror stories (to come) will drive security improvements, but I’d rather not be in the crowd of early sufferers.  At least, please do me a favor and honor the principle of graceful degradation, so that if I visit your web site with JavaScript turned off, I can still make some use of it.