-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the light of our discussion on cross site scripting I am cross-posting (with Steve's permission) a message from the online-news list which describes some ways the problem could be used in exploits. - -- Start forwarded message Subject: Re: Javascript "virus" in new CERT warning From: Steve Bonisteel <stevebat_private> Date: Fri, 04 Feb 2000 21:54:39 -0500 X-Message-Number: 9 At 03:11 PM 04/02/00 +0000, Adam Gaffin wrote: >The CERT warning also has some ramifications for sites that run user > forums. If you let your users use HTML in their postings, you >should figure out how to disable certain tags (script, embed, >applet and object). [Assuming we're talking about cross-site scripting here...] True, but if sites with user forums weren't already aware of this, they should not be running Web-based bulletin board and chat rooms :-) I did some quick tests after the advisory and had no trouble at all finding sites where some form of a cross-site scripting attack could be introduced. Web sites that have implemented their own site-search routines are particularly vulnerable. Once a hole is found, then the browser-cookie thing is often wide open (on sites using cookies, obviously), because it's common for site programmers to trust their own cookies. I reviewed by *own* code for various CGI applications and realized that, in all cases, my code assumes only *I* could have set the cookie. If everyone checks their code, I'd bet they'd find the same thing in many cases. The bottom line is that it's not a *script* problem: it's an oversight on the part of Web developers (like me!). How serious the problem is depends on a huge variety of factors on each site. For example: If your site puts a registered user's name in a cookie and then reads that name field later for a personalized page that says "Welcome back. Steve!" ... then it's *possible* that if, say, your site-search application is open to CSS, people could find their personalized page greeting them with "Welcome back, Pinhead!" But what if an e-commerce site does the same thing, and prints what it thinks is the user name on an order-entry form? In that case, an application that doesn't parse the cookie for script code could introduce a credit-card-stealing routine to the page. That's just one example. There are all kinds a site-specific variations that may or not use cookies. A direct, cross-site link to a CGI shopping application "Checkout," as an example, would be a high-probability way to introduce a malicious script into a form that still appears to be working from the user's perspective. One form of protection from a truly *cross-site* attack that I didn't see mentioned in the CERT advisory is the trusty "HTTP_REFERER" check. But then, with so many sites using affiliate programs to get their search boxes and book-buying links distributed across the Web, there may be few major e-commerce sites that block requests based on the referral source. In my tests, many of the *successful* search-engine attacks actually "broke" the search. By that, I mean that the site returned a page that complained in some way that the search was not successful - sometime reporting a syntax error. But, in many of those cases, a script was still successfully launched - a script that *could* have altered a cookie, which might do its real work later. Again, if we're talking about cross-site scripting, I haven't heard of a "denial of service" kind of attack, as mentioned by Mr. Meyer. Regards, SRB - -- Steve Bonisteel TypeCast - --- end forwarded message -- Bill Thompson Cambridge UK -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> iQA/AwUBOJ05OVNT/DkNet0bEQIf8wCghGCHG0RtMzVkffKx1Myx4yjBEmIAnR9G g3YLwoAQsc97ue84EqplO5M2 =7KyT -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:33:45 PDT