Moving session IDs to cookies will also open you up to CSRF attacks. :-)
On 2016-03-24, 10:21 AM, "webobjects-dev-bounces+chill=gevityinc....@lists.apple.com on behalf of OC" <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com on behalf of o...@ocs.cz> wrote: >Hello there, > >one of my applications drained its memory quickly; it looks like the primary >cause was creation of thousands sessions, which itself was caused by lots of >Google requests containing spurious (probably stored years ago) session IDs. >It seems each such request creates a new session, and hilarity quickly ensues. > >Of course, moving session IDs to cookies would help (and kicking out those >bloody Google bots from the server would help tremendously), but I wonder... > >... first, sometimes session IDs in URLs are needed, e.g., to allow concurrent >work in different sessions from more browser tabs/windows. Besides, an attack >can be created maliciously with spurious session IDs in cookies just as well. > >Is there a known and tested way to reliably prevent this kind of >session-induced death? Some trick to create new sessions only for valid >requests? Perhaps handleSessionRestorationErrorInContext redirecting to a >static address without a session ID, or something like that? > >Thanks, >OC > > > _______________________________________________ >Do not post admin requests to the list. They will be ignored. >Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >Help/Unsubscribe/Update your Subscription: >https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com > >This email sent to ch...@gevityinc.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
