[WEB SECURITY] ICal bookmarking .ICS file

GROSS, Bill wrg at nei.org
Wed Sep 17 15:00:07 EDT 2008


Agreed.

We are working on a calendar web application that allows users to click "export to calendar".  That button basically does what you are talking about - creates a .ICS file that Outlook then imports.

What we are finding is:
1) Outlook will allow HTML into the body of the event: DESCRIPTION field.
2) Thus, it may be possible to insert SCRIPT tags, IFRAMES, etc.  We have not tested.

If you are writing the application that exports the data, be sure that the sources of event data are trusted.

IE, if USER A can create the data, and USER B can create the ICS file, be sure that A is trusted, or that A's data is sufficiently sanitized prior to export.

You can:
1) Ensure that A cannot use anything but TEXT in creating the event (no HTML allowed)
2) When creating the output for the ICS file, run the content for the DESCRIPTION field through an HTML/Script scrubber.

Lastly, I have not read (not for a long time) of any patches to email clients for vulnerabilities in the calendar import module.  That doesn't mean there aren't though.

William Gross
Manager, Web Services

Nuclear Energy Institute
1776 I Street NW, Suite 400 
Washington, DC 20006
www.nei.org

P: 202-739-8123
F: 202-533-0119
M: 202-437-2428
E: wrg at nei.org


nuclear. clean air energy.


-----Original Message-----
From: Simone Onofri [mailto:simone.onofri at gmail.com] 
Sent: Wednesday, September 17, 2008 1:39 PM
To: KT
Cc: websecurity at webappsec.org
Subject: Re: [WEB SECURITY] ICal bookmarking .ICS file

Dear KT,

ICS it's a file, processed by a program or a script, probably some
code can be injected, but depending on how this file is processed.
Think an importer (in php or other web language) to MySql...

Cheers,

Simone

On Wed, Sep 17, 2008 at 6:07 PM, KT <ktriv3di at msn.com> wrote:
> Are there any security issues with .ICS file? I have an application that
> writes ICS files which could then be imported using ical to create calendar
> entries and then synced up with iPhone
> I am looking for any kind of threats
>
> Thanks
>
> --------------------------------------------------
> From: "Guy Aharonovsky" <guy at jajah.com>
> Sent: Wednesday, September 17, 2008 3:00 AM
> To: <websecurity at webappsec.org>
> Subject: RE: [WEB SECURITY] Bug in Internet Explorer security model
> whenembedding Flash
>
>> Hi Stefano,
>>
>> I took one kind of attack and tried it in on a real website with a real
>> flaw. In my blog I explain how successful it was.
>>
>> http://blog.guya.net/2008/09/14/encapsulating-csrf-attacks-inside-massively-distributed-flash-movies-real-world-example/
>>
>> I knew about all these kind of Flash related attacks and didn't think I've
>> invented something there.
>> I've foolishly thought I have something new with IE, I should have checked
>> it better. Thanx for enlightening me.
>>
>> Best
>>
>> Call me free at: http://jajah.com/guy
>> Visit me at: http://guya.net & http://jajahdevblog.com/guy
>>
>>
>> -----Original Message-----
>> From: Stefano Di Paola [mailto:stefano.dipaola at wisec.it]
>> Sent: Tuesday, September 16, 2008 10:58 AM
>> To: Guy Aharonovsky
>> Cc: websecurity at webappsec.org
>> Subject: Re: [WEB SECURITY] Bug in Internet Explorer security model when
>> embedding Flash
>>
>> Hi Guya,
>>
>> Maybe I missed something about your blog entry, but the IE stuff and the
>> other flash issues/features has been already covered here:
>>
>> http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt
>>
>> and here
>>
>>
>> http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt
>>
>> and SWFIntruder (https://www.owasp.org/index.php/Category:SWFIntruder)
>> also uses the try{}catch(){} block in order to bypass the security check
>> deployed on IE.
>>
>>
>> Regards,
>> Stefano
>>
>> Il giorno lun, 15/09/2008 alle 12.04 +0300, Guy Aharonovsky ha scritto:
>>>
>>> Taken from my blog:
>>>
>>>
>>> http://blog.guya.net/2008/09/10/bug-in-internet-explorer-security-model-when-embedding-flash/
>>>
>>> Update: I've posted a real world example of this bug being exploited.
>>>
>>> This one has the same behavior on IE6, IE7 and IE8 betas.
>>>
>>> I have only tested this with Flash swf files, but it's likely that
>>> this security is applied and broken the same way, when navigating to
>>> different types of files.
>>>
>>> When loading Flash file (swf) directly inside the browser without an
>>> html page container, for ex: http://example.com/game.swf , most
>>> browsers create an html page automatically and embed the swf inside
>>> it. FireFox and Google Chrome, for that matter, automatically create
>>> an embed tag with some default values, and IE uses this mshtml script
>>> (res://mshtml.dll/objectembed_neutral.js) to load the object.
>>>
>>> The fact that this automatically created embed tag doesn't mention the
>>> allowscriptaccess property it's defaulted to samedomain. This way the
>>> swf file can script the automatically generated html page it resides
>>> in, using ExternalInterface, leading to a major security flaw. I will
>>> post about a real world example of this security flaw, shortly.
>>>
>>> Internet Explorer, rightfully, consider this generated page as less
>>> secure and as such restrict access to the JavaScript document object.
>>> It's preventing from the embedded swf to script the DOM of the page.
>>>
>>> Just test it, go to any swf file on the web using Internet explorer,
>>> then run this script in the address bar javascript:alert(document);
>>> you'll see the error "Access is denied". Touching the document is
>>> prohibited!
>>>
>>> Error_Access_Denied
>>>
>>> But, all that is needed to compromise this security feature in IE is
>>> to reload the page. That's it, just reload the page once by pressing
>>> F5. Run the script again javascript:alert(document); you'll see the
>>> precious document and no error will be thrown.
>>>
>>> Since most of the other javascript objects are still available and
>>> among these is the window native object. A swf file, for example, can
>>> reload the page on its own using window.location.reload() and then
>>> will be able to bypass the restriction and freely manipulate the page.
>>>
>>> This script can run from inside the swf using
>>> ExternaInterface.call("eval", "script"); If the "try" clause fail it's
>>> probably an IE browser and the page will reload immediately without
>>> the user noticing. The 2nd time the page loads the "try" clause won't
>>> fail.
>>>
>>> JavaScript:
>>>
>>>     1. try{
>>>     2. $d = document;
>>>     3. //Mess with the DOM
>>>     4. }catch(ex){
>>>     5. window.location.reload();
>>>     6. }
>>>
>>> I was impressed that Microsoft implemented such a security feature as
>>> opposed to FireFox, Chrome and others who don't have a similar
>>> restriction. but, it needs to be done right otherwise it misses the
>>> point.
>>>
>>> As I said, I'll post a real world example of this being exploited,
>>> soon.
>>
>>
>>
>>
>>
>>
>>
>>
>> ******************************************************************************
>>
>> This footnote confirms that this email message has been scanned by Jajah
>> Inc. Mail system for the presence of malicious code, vandals & computer
>> viruses.
>>
>>
>> ******************************************************************************
>>
>>
>>
>>
>>
>>
>> ******************************************************************************
>> This footnote confirms that this email message has been scanned by Jajah
>> Inc. Mail system for the presence of malicious code, vandals & computer
>> viruses.
>>
>> ******************************************************************************
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>> Join us on IRC: irc.freenode.net #webappsec
>>
>> Have a question? Search The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>>
>> Subscribe via RSS:
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>> Join WASC on LinkedIn
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>



-- 
Simone Onofri
http://www.siatec.net/

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA




More information about the websecurity mailing list