4

Let's assume you have a single sign on ticket and you logon to a website which authanticates you by the ticket (same thing with user/password). The webserver will create a session and the user stores the session ID in his browser. Now the user delets his session cookie and refreshes the site. The user will get another session. But the webserver holds two sessions now. The old session does not expire until the timeout is reached. Imagine the user will do this over and over again:

while(true) {
  open website
  delete cookie
}

As soon as the maximum of sessions on the server side is reached, nobody will be able to create another session anymore. The consequence is a denial of service.

  • What is this kind of attack called?
  • How can I prevent it?
  • How high is the risk in a real world scenario? (The attacker still needs a valid authentification.)
2
+50

As Anders says, the chance of an attacker occupying the entire session id namespace is not an issue. However there are other bottlenecks which could be exploited. The obvious ones are the capacity for session storage and impact of increasing numbers of session data sets on the cost of retrieval of a single dataset.

Although session data is small, since there is a big performance benefit to storing the session data in memory, the amount of space for allocated for session storage may be of the order of Mb/host rather than Gb/host one might expect for non-volatile storage. On clusters, there may be replication bandwidth bottlenecks. Older filesystems can slow down when dereferencing files in a directory with thousands of entries.

What is this kind of attack called?

No idea (its a type of Denisal of Service, targetting limited resources)

How can I prevent it?

Make sure you have more capacity for your session storage than you think you need. If your session management does not synchronously remove data on expiration, then ensure you've got aggressive garbage collection.

RTFM - PHP's default handler, for instance, has an option for distributing session data across multiple directories.

Monitor your systems.

How high is the risk in a real world scenario? (The attacker still needs a valid authentification.)

I'd say its possible but never heard of happening in practice. Whether a particular site is vulnerable? Do the math - e.g. say you use memcache for your session storage, have 500Mb assigned for storage, a session TTL of 1 hour and an average session size of 0.2 Mb - that means to fill the storage an attacker would need to create 2500 sessions in an hour - or a new session every 1.5 seconds - that's doable. OTOH, with a session size of 0.02Mb, 4Gb of storage, and a TTL of 10 minutes, they would need to create over 300 sessions per second - that's becoming difficult - particularly if you consider the bandwidth needed.

9

If you are using a good system for generating session IDs this would not be a problem. To prevent an attacker from guessing session IDs by brute forcing you need to have a very large space, so that there are in practice to many possible IDs to perform this attack.

An attacker who is able to fill up the whole space of available session IDs would be able to impersonate any logged in user by brute forcing their session ID, something much worse than DoS. So to protect against that much bigger risk sane systems already use session IDs with enough entropy to make this practically impossible.

For instance, even if the session ID has just 32 bits of entropy and a session last for a full day you would still need to initiate 100 billion new sessions per second to use them all up. That would be enough to DoS the server from just the traffic anyway, so the limited number of possible sessions IDs would not be the bottle neck.

Another example are PHP session IDs. By default they are generating by MD5 hashing a number of things, including the current time. So unless you hit a hash collision by accident (extremely unlikely) there will be no duplicates.

In addition to this, I would assume that most services has some kind of cap on the number of open sessions for one user or one IP.

Since this is not a practical attack I don't think it has a name, but it would be a form of denail of service. I think you christened it with a good name in your title.

  • Thanks for the answer, it was very revealing to me. I faced this problem in a SAP scenario. I don't realy know how the session_ids are generated in SAP (i guess by a common hash-alg.). Now, SAP has a parameter that defines the maximum number of http(s) session for all users together, but not for a single user. So i am searching for a practical way to prevent this kind of attack vector. Do you have any more ideas? – licklake Dec 15 '16 at 9:28
  • I know nothing about SAP. If the total number of allowed sessions are low, then there might be a risk for DoS. If you need specific guidance on SAP I would recommend you to ask a new question about it, describing your specific problem. – Anders Dec 15 '16 at 9:43
  • 1
    I do. But i am explicitly asking here to get a "general valid" answer. I like to see it from another view :) – licklake Dec 15 '16 at 12:15
1

The webserver will create a session and the user stores the session ID in his browser. Now the user delets his session cookie and refreshes the site. The user will get another session. But the webserver holds two sessions now.

If you're worried about this, the logical thing to do is to limit the number of simultaneous sessions a user can have. One website I visit with rather resource-intensive sessions does just that: you're allowed to log in from three browsers at once. Log in from a fourth, and the oldest session gets expired.

Set the number of sessions based on expected usage, eg. one session for their home desktop, one for their work desktop, one for their laptop or smartphone, and a few extras for unexpected situations.

  • Yes you're absolutly right. That would be the most logical and best solution for the problem. Sadly thats the one thing i can't do... Do to the fact that SAP has no parameter to limit the userspecific sessions. I am asking especially in this forum to get a more general view of the problem and maybe another solution – licklake Dec 23 '16 at 7:45
0

It's very easy to carry out this kind of attack, using curl or wget.

In one of the projects I worked on, we used a LRU (least recently used) cache of sessions per user, and set the LRU cache size to be 10. So assuming the attacker is using the same username/password, it won't occupy more than 10 slots. This worked quite effectively for us.

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.