[Webappsec] HTTP only support in XMLHTTPRequest

Thu May 8 11:41:43 EDT 2008

This is great info, thanks very kindly Arian. :)
- Jim
> To follow up on your Flash/Actionscript question Jim:
>
> In general, Flash/Actionscript is limited to what you
> can do with Javascript, and is more rigorously limited
> to same-domain policies. I don't see a way to bypass
> HTTPOnly flags here, but I am *not* a Flash guru
> by any stretch of the imagination.
>
> I double-checked with Adobe last night to verify, and:
> Flash cannot currently access cookie headers. In fact,
> in general Flash/Actionscript ability to even set or read
> HTTP Headers has been limited (we ran into a recent
> problem on our Sentinel platform trying to pass Basic/Digest
> via a SWF -- this functionality has been removed from
> current versions of Flash).
>
> There are probably some caveats if allowScriptAccess
> is true, and domain restrictions are not properly enforced
> (DNS mis-mappings, wildcards, etc.). Unfortunately, we
> do sometimes see this in the wild on important production
> sites using Flash/Flex driven apps.
>
> Did that answer? Cheers,
>
> -ae
>
>
> On Wed, May 7, 2008 at 6:18 AM, Jim Manico <jim at manico.net> wrote:
>   
>>  Matt,
>>
>>  Hey, thanks for chiming in.  By the way, thanks for being the first to
>> clearly demonstrate ways around HttpOnly last year - it was an eye opener.
>>
>>
>>  > If the XMLHttpRequest did not send the session id,
>>
>>  I have no problem with the XMLHttpRequest *TRANSMITTING* a HttpOnly cookie,
>> I just have a problem with an AJAX application *READING/ACCESSING* a
>> HttpOnly cookie via JavaScript calls. There is a BIG difference - make
>> sense?
>>
>>  Why the heck would anyone ever need to READ a session cookie in JavaScript?
>> I can not think of any use case. However, as you clearly stated, there are
>> many reasons why an AJAX applications needs to TRANSMIT a HttpOnly cookie.
>>
>>  Cool?
>>
>>
>>
>>
>>
>>
>> Jim,
>>
>> I have to disagree with your conjecture. For applications that are simply
>> making requests to publicly available content you are correct, there is not
>> impact, but accessing protected content is another story. For instance, I
>> support an application that is very AJAX intensive (I know there is more to
>> 2.x than just AJAX but go with me here for the sake of argument). The user
>> is required to login to the application before accessing any information and
>> thus receives a JSESSIONID. The interface is loaded dynamically through
>> several AJAX requests that, as of now, sends the JSESSIONID and would
>> continue to do so even if it was marked as HttpOnly. If the XMLHttpRequest
>> did not send the session id, the application would break because all the
>> functionality being referenced behind the scenes requires some bit data out
>> of the session object, namely determining if the user is logged in and what
>> groups/roles the user is a member.
>>
>>
>>
>> The only way I see to combat this issue is to make the data available to
>> non-logged-in users, but then it is just protect by "security through
>> obscurity". Any thoughts?
>>
>>
>>
>> Thanks,
>>
>> Matt
>>
>>
>>
>>
>>
>> From: webappsec-bounces at lists.owasp.org
>> [mailto:webappsec-bounces at lists.owasp.org] On Behalf Of Jim Manico
>>  Sent: Tuesday, May 06, 2008 7:34 PM
>>  To: Arian J. Evans
>>  Cc: robert at sectheory.com; webappsec @OWASP
>>  Subject: Re: [Webappsec] HTTP only support in XMLHTTPRequest
>>
>>
>>
>> Conjecture: Restricting  XMLHTTPRequest from reading HttpOnly cookies is not
>> going to stop w 2.x innovation in any way.
>>
>>  I propose that we set up a petition over this issue (I'll lead the charge
>> in getting this set up) and submit the results to the w3c over this specific
>> issue.
>>
>>  Cool, Arian?
>>  - Jim
>>
>>  This is nice, but as you said, if we don't involve the W3C this will
>>  assuredly slide down that slippery slope of open access. Our
>>  community hasn't done an effective job with this so far (IMHO).
>>
>>  I believe the social-networking software community folks want
>>  XMLHTTPRequest to have access to anything they want it to,
>>  *especially* including values they deem as useful (personalization
>>  and tracking cookies).
>>
>>  Having OWASP support this would make sense, and add
>>  weight. Several user-agent implementation projects follow
>>  OWASP today....
>>
>>  Also, so would having "Oracle" encouraging this.
>>
>>  I don't think most of us as individuals will have much say or
>>  sway, especially if there starts to be conflicting interests
>>  with the functions of XMLHTTPRequest going forward
>>  (and I think there will be).
>>
>>
>>
>>
>>
>>
>>
>>
>>  --
>>  Jim Manico, Senior Application Security Engineer
>>  jim.manico at aspectsecurity.com | jim at manico.net
>>  (301) 604-4882 (work)
>>  (808) 652-3805 (cell)
>>
>>  Aspect Security™
>>  Securing your applications at the source
>>  http://www.aspectsecurity.com
>>
>>
>>  --
>> Jim Manico, Senior Application Security Engineer
>> jim.manico at aspectsecurity.com | jim at manico.net
>> (301) 604-4882 (work)
>> (808) 652-3805 (cell)
>>
>> Aspect Security™
>> Securing your applications at the source
>> http://www.aspectsecurity.com
>>
>> _______________________________________________
>>  Webappsec mailing list
>>  Webappsec at lists.owasp.org
>>  https://lists.owasp.org/mailman/listinfo/webappsec
>>
>>
>>     
>
>
>
>   


-- 
Jim Manico, Senior Application Security Engineer
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/webappsec/attachments/20080508/90395e09/attachment-0001.html