-----BEGIN PGP SIGNED MESSAGE----- On Fri, 4 Feb 2000, Tim Hollebeek wrote: > Misconception #2: This problem is "new" > > Security experts and hackers have been aware of the ability to exploit these > problems for a long time, but creators of web sites and web-enabled software > have for the most part not paid adequate attention to these problems. > CERT's motivation appears to be to raise awareness of these significant > dangers in the hopes that future and existing systems will be > (re-)engineered with these problems in mind. > > Misconception #3: This problem has never been exploited by hackers. > > Many of the problems with Microsoft's hotmail have been due to attacks which > fall within the range of this security advisor, as does the eBayla attack > on eBay. Erm... you are still missing the entire point of the advisory and the entire new aspect of it. The know issues you describe are where user B posts content that user A can see. This issue is about something that user A requests and only user A sees. The first issue is old, and is what your examples are. The second has never been widely recognized, and where it has been recognized the implications have not been understood. The fact that the first scenario is old news and largely dealt with (although certainly not completely; there are still javascript holes in hotmail, etc.) is expliciltly pointed out in the CERT advisory, and it makes it clear that the real meat of the issue being discussed is the second class of sites. Sure, they all end up boiling down to the same basic thing, but the methods of attack are different and the sites impacted by the second class of attacks are orders of magnitude larger. A huge number of sites (eg. you can steal accounts on at least half of the top 10 web sites, including several commerce sites) are impacted by this to varying degrees. Many or most of them don't realize it. The message to them: GET WITH IT! I'm sure that as nasty people start realizing this, you will see a lot of exploits being posted. They aren't hard to find. It is critical to realize this. I have talked to people at a couple of top ecommerce sites that were completely vulnerable to this attack. They had no idea of their exposure. Had they seen the CERT advisory? Well, of course. But they didn't think it mattered to them. This also brings to the forefront a lot of other issues that have been lingering, such as the dangerous of persistent signons and single signon systems (which can sometimes be exploited without this cross site scripting problem by getting someone to follow the right link) and the fact that it is _extremely_ difficult to properly encode or filter things, especially if you want to allow "safe" HTML through. This is a major issue. Things users should do: 1. Disable scripting if possible. See the CERT advisory and MS docs for info on this. Note that this is not a complete solution, because the problem is not a scripting problem. Scripting languages just make it easier to exploit because they have fairly complete control over what the user sees and does. Disabling scripting languages, however, obviously isn't possible all the time. 2. Do not use a mail reader that forces you to display HTML messages. Using something like Outlook Express is very dangerous, since it means that you can be exploited if an email message arrives in your inbox and is displayed. If you do use something like Outlook Express, be sure to configure it to disable scripting and make it as restrictive as possible. Unfortunately, in the case of Outlook Express, this doesn't appear to be enough since I can't find any setting that will stop things like IFRAMEs from automatically loading, which are enough to make you vulnerable in many situations. Hopefully I'm missing something. 3. Do _NOT_ enable the option of keeping yourself persistently logged in at any site that matters at all. Persistent logins make it far easier to steal cookies that allow others to steal your account. Be especially wary of sites with a single login system for a lot of sites, such as msn.com (which includes hotmail, etc. through MS Passport) and yahoo.com (which includes yahoo mail), since any single site in that domain that is vulnerable will compromise your cookies (and account) for the entire site. Some sites don't provide obvious ways to logout, such as Amazon. On those sites, often a "Not user foo? Click here" link will log you out. Use it. And make sure the site knows that you want the option of not being persistently logged in. 4. Don't randomly follow links that you are sent. Unfortunately, for many users, when combined with (2) this is impossible. 5. Even if you think you are safe because a site asks for a password before letting you do anything having any real consequence, be wary. I have found a number of top sites where this is improperly implemented: ie. if you know where the particular page the form submits to is (and this is normally the same for all users, possibly with some session identifier appended), you can access it directly without having to supply any password. Things web developers should do: 1. Read all the recommendations in the CERT advisory, the Apache info, and the Microsoft info. I think the MS info contains the most detailed information in a lot of areas here. Do what this info says. Namely, properly filter or encode all output. Unfortunately, figuring out what "properly" means and how to do it is not as trivial as some documents would make it seem. 2. Pay particular attention to any software you run. At last count, at least IIS5, Apache, WebSite Pro, Roxen, Netscape Enterprise, Zeus and thttpd had vulnerabilities in their default configurations, to the best of my knowledge. Some are fixable with config changes (eg. override default error page), some may not be. Of these, Apache's vulnerabilities are probably the smallest, as they are almost entirely based on not specifying an explicit charset. See point 3 below. Get in touch with your vendor; if your vendor says they aren't vulnerable, be dubious; they may not understand the problem. Note that while software like webservers is a small part of the problem, and the easiest part to fix, if it isn't fixed then fixing all your code does no good. 3. Pay particular attention to the charset issue. If you don't specify an explicit charset on your documents, it is possible the client could interpret "+ADwK-" as "<" if it is using UTF-7. IE even gives users an "auto-select" option that will make this trivial. For those lucky enough (or english-centric enough) not to have to deal with multiple charactersets, the Apache patches released allow you to force every resource on your server to be sent with a charset that you specify regardless of what module, etc. it is sent from. 4. Remember that if you are using domain based cookies (eg. .znep.com) instead of host based cookies (eg. foo.znep.com) then _any_ vulnerable server in your domain will make you vulnerable, even if that server doesn't do anything that matters. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOJxjTlQv/g4Arev1AQFtCwQApHgIYBI7gc2jULUdw/IqhTI+6wH9gkya vZhnk66u1A5OeRO78jqZqQSvJT1Rnx/bG+dqy93fH+UZyb06y8co80ZtlMUDOzyE 7YrRIW9p+cprUzMP/pJ6NkvaeroCzwsYPvJG5HCyjYGeX3mb9JheR3XfGrAX1v7+ +xFhP69ilcY= =QuzO -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:33:43 PDT