The idea is that they get the session cookie and used it as it is, to send it to the server and server connects the cookie with the victim session. Actually there is no data on session cookie, just an encrypted number of the session id.
Now there is a case that sensitive data stored on cookie and that is the Roles of the currenct user. To avoid a possible decrypt and change on web.config on <roleManager cacheRolesInCookie="false"
Also on the authentication cookie and on role manager always use the requireSSL="true", so its impossible to steal the cookie of authentication, but you must use secure pages for this make work.
How some can stole a critical session. This can be done if the programmer depends the critical data that show to the user, on the session id. For example, if you store the phone number and the name on a session variable and show that to the user, then some one can stole the full web page and read it (if not ssl). If you have connect the backoffice and the access to hidden administrate page with the session id, then if some steal the session cookie and open the pages, then he can gets on that administrators back office pages.
So its up to you not to store critical information's on session data, and always use ssl pages to administrate and to get send cookie critical data.
Now if a hacker steal the session cookie and you there just store what users see in previous pages, a history of products like amazon, then is not big deal because still can not connect this history with the user, but also can anyone sniff the urls that a user see.
Of course its up to you also to not store critical data on any unencrypted cookie !
So you split your data to critical ones, and not critical ones, and always use SSL for page and cookie for the critical ones, and never trust the data that comes from unsecure pages.
You can also read :
Can some hacker steal the cookie from a user and login with that name on a web site?
Hope this helps you.