RE: [flexcoders] XSRF Vulnerability?

[Jeff Vroom]

It is quite possible to implement a flex/flash app which is susceptible to XSRF since the player uses the browser’s cookies for HTTP requests, and many server applications store session state based on these cookies.     You do have a couple of tools which you can use to get around this vulnerability though: 1)       You can use RTMP connections – the session is dropped when the player is unloaded and cookies are not used.  This requires a server which understands RTMP (right now either FMS or FDS) 2)       You can store an additional session id in the player’s memory and validate the session with this additional session id.   This id would potentially be sent by the server on the first request the player makes to the server and then returned by each HTTP request the player makes.   As soon as the player instance is closed, this session id would go away so the next site would have no ability to use it to authenticate the fake HTTP request.   If the server receives an HTTP request which does not have this extra session id, you would invalidate the HttpSession and return a new extra session id.  By invalidating the session, you’d remove any credentials associated with that session making the XSRF exploit impossible while still allowing the user to create a new player instance from the same browser.  Of course that player instance would have to reauthenticate.   Jeff   From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Christian Edward Gruber Sent: Tuesday, August 29, 2006 1:47 PM To: Flexcoders Discussion Group Subject: [flexcoders] XSRF Vulnerability?   Hi folks,      I've been digging into XSRF to make sure that my clients' portal implementations are protected against such, but was wondering:  With the varying access approaches Flex 2.0 apps have at their disposal, are typical default communications potentially vulnerable to XSRF attacks.  Are requests even consistent enough for this type of attack?  Are there standard Data Services places where HTTP calls are made that could be spoofed, and which are only authenticated by participation in a valid session?       If people have encountered such, are there practices people have adopted to avoid them?  Does Flex 2.0 already pass secure tokens to authenticate the valid source of a request already perhaps (I dare not hope)? regards, Christian. -- christian gruber + process coach and architect Israfil Consulting Services Corporation email [EMAIL PROTECTED]net + bus 905.640.1119 + mob 416.998.6023 __._,_.___ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Software development tool Software development Software development services Home design software Software development company YAHOO! GROUPS LINKS  Visit your group "flexcoders" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___