[Webappsec] HTTP only support in XMLHTTPRequest

[Arian J. Evans]

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
>
>



-- 
-- 
Arian J. Evans.

I spend most of my money on motorcycles, mistresses, and martinis. The
rest of it I squander.