I'm comparing the pros and cons between having an authenticated "stateless" ASP.NET MVC session versus a ASP.NET Forms application with viewstate.

Assuming that there is a webfarm of more than 1 web server behind a load balancer:

  1. What threats would a stateless application have that a traditional "state aware" application don't have?

  2. If there is a difference, what are the risks?

  3. What should I do to my stateless MVC application to maintain comparable security? (I'm thinking about the options in a NetScaler with regard to session affinity)

  • How do you delete a session when there is no session?
    – curiousguy
    Nov 9 '11 at 18:13
  • 1
    What do you mean by stateless? Lack of per-user session state stored on the server? By your definition is it true that a stateless application doesn't suffer from problems associated with interleaving of messages from the same client, but might suffer from cache poisoning? Nov 9 '11 at 18:16
  • A web app may require a load balancer to redirect a source IP to a target host by means of a cookie or source IP. This usually implies the server has information in memory that can't be transferred to another server. Should an attacker start a new session, they might be redirected to a new host. Nov 9 '11 at 18:43
  • @curiousguy My terms may be wrong, but I'm referring to a session as a logon session. When a SAML user authenticates, they get a FedAuth cookie. This cookie (and any other data embedded in this encrypted payload) might be used to create a temporary state on the server that lasts as long as the single HTTP request. Nov 9 '11 at 18:46

Certain DOS attacks become feasible with a smaller number of misbehaving clients when it is unpredictable which real machine will service a particular request.

  1. Send a series of messages which cause the receiving shards to fetch data into memory paging out most of anything else that is resident.
  2. Switch to send a series of messages which cause the receiving shards to fetch a different set of data into memory paging out whatever was fetched by 1.
  3. Repeat.

When allocation of messages to shards is random or mostly random, that randomness can be exploited to DOS a group of machines by a smaller number of attackers if an alternating set of messages can cause those shards to spend most of their time filling caches instead of handling requests.

With a stateful system that shards based on session ID, you need to be able to cheaply create sessions or have a large number of attackers that can each keep one expensive session.

Obviously, for certain applications it may be possible to define a stateless system that doesn't swap to disk.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.