| . |
|
Bitland.Net Security Notes
Comments? email jwilkins-at-bitland*net
More information on the author at Jonathan Wilkins's home page RSS feed available at http://www.bitland.net/index.rss 
|
| Archives: 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000 |
| |
| |
| IEs4Linux | (2007/06/24 13:30) |
Check out IEs4Linux, a really easy to install set of Internet Explorer versions that will run on Linux under Wine. The build includes IE5, 5.5 and 6. |
| +digg | +del.icio.us | [Web ] | Permanent link |
| |
| IE not much better in 2005 or 2006 | (2007/01/10 16:45) |
Brian Krebs' Security Fix blog did some followup on the scanit.be report on 2004. Apparently IE fared slightly better in 2005 and 2006, but not remotely well enough. IE had 109 days where it was *not* vulnerable to a published exploit. For more than 2/3 of the year, you were simply screwed if you were running IE. Even worse, it was known to be vulnerable to actively exploited vulnerabilities for 38 days. 2006 was worse again, though not quite as bad as 2004. In 2006, a fully patched IE was only safe from published vulnerabilities on 81 days of the year. Overall, if you were running IE from 2004-2006, you would have been in danger 898/1095 days and only safe on 197 days. I didn't see similar statistics for Mozilla for the same period in Krebs' posts, so I hope he does a follow up post. |
| +digg | +del.icio.us | [Web ] | Permanent link |
| |
| Fully patched IE safe only 7 days in 2004 | (2006/12/08 18:27) |
I can't find a date on the article, but the folks at scanit published a paper on browser security in 2004. They went through public security resources and tracked the lifetime of various browser vulnerabilities. They found that even if you installed all available patches as soon as they came out, if you were running IE, you would still have been vulnerable to publicly disclosed code execution bugs on all but seven days. Given the amount of auditing that IE7 has recieved, I expect that it will fare much better, but this is the sort of thing that has prompted MSFT to invest as much as it has over the past few years. Other browser manufacturers fared better, but nowhere near what they should have done. If you were running Opera, you could have been owned via publicly disclosed bugs on 65 days. Mozilla had the best record of the major browsers, being vulnerable 59 days of the year. While that's a major improvement, if you were running Mozilla, you were vulnerable 2/12 months. To recap, vulnerable days by browser:
|
| +digg | +del.icio.us | [Web ] | Permanent link |
| |
| Multiple Instances of Portable Firefox | (2006/12/04 20:20) |
Firefox Portable is great when you want to test against prior versions of the browser, but by default it doesn't allow multiple instances. This means you can't run it alongside your current version of Firefox or under different profiles simultaneously. In order to fix this, just copy the file FirefoxPortable.ini from the Other subdirectory of your portable Firefox installation to the same directory as FirefoxPortable.exe and change the AllowMultipleInstances line to true. |
| +digg | +del.icio.us | [Web ] | Permanent link |
| |
| Only allow GET and HEAD requests under Apache | (2006/12/04 19:00) |
Disallowing TRACE under Apache is a standard requirement for most sites these days due to Cross Site Tracing (XST). Most pages that make this recommendation suggest using mod_rewrite (./configure --enable-rewrite) and an entry in httpd.conf like the following:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
This is fine, but lots of times the other verbs aren't needed anyway. Given that, why allow them? Here's a better ruleset:
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)
RewriteRule .* - [F]
You may need POST or other methods, but it's simple to add them. Also note that if you're using virtual hosts, you have to place this in each VirtualHost section as it's not inherited by default. |
| +digg | +del.icio.us | [Web ] | Permanent link |
| |
| GET considered harmful | (2006/12/03 01:15) |
Ok, it's not quite that bad, but I'm seeing a ton of web application developers making the same mistake in the use of the GET method. Essentially, GET is only supposed to be used in cases where no data is being changed on the server. This is spelled out in the HTTP RFC (see RFC 2616 section 9 for details), and is responsible for at least a few major bugs over the years. I even recently came across this error on Yahoo's Developer Security Best Practice page (see the Request Forgery section). The HTTP/1.1 RFC says that GET and HEAD in particular are supposed to be safe and idempotent. This means that they should not perform any action other than retrieval (safe) and that there should be no side effects of multiple calls (idempotent). The most famous error of this type was when Google released the Google Web Accelerator (GWA). This broke a ton of applications and particularly those that were based on Ruby on Rails since applications built with Rails were especially prone to use GETs to perform actions. In order to speed up the user's experience GWA would pre-fetch all of the links on a page. This was great for images and so forth, but Rails applications were doing things like deleting records and cancelling accounts through GETs. The authors of some web applications made things worse by relying on JavaScript confirmations. Of course, GWA (correctly) wasn't doing JavaScript. |
| +digg | +del.icio.us | [Web ] | Permanent link |
| |
| RSS feed available at http://www.bitland.net/index.rss |