Easy way for user to tie up server resources in an ASP.NET application

[steventhrasher42]

I very likely may be missing something here, but what stops a user from
holding down the F5 key in their browser and generating hundreds of
requests to IIS and thus tying up server resources?

If session state is enabled (enableSessionS tate=true), all of these
requests get queued and processed one after another.

And if the user finds a particular page with poor enough performance,
say one that takes a few seconds to render, by holding down the F5 key
for a minute, he can queue up hundreds of requests and tie up the
server spiking it's cpu for an hour or even hours.

I've tested this and used the Performance Monitor to confirm this is
what goes on.

Shouldn't there be a feature of IIS or ASP.NET that allows you to limit
the number of requests per ASP.NET session so this is avoided?

[Juan T. Llibre]

You're right in raising this issue, Steven.

I have forwarded your (correct) concern
to the ASP.NET Dev Team.

Thanks!

Juan T. Llibre
ASP.NET MVP
===========
<st************ **@hotmail.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

I very likely may be missing something here, but what stops a user from
holding down the F5 key in their browser and generating hundreds of
requests to IIS and thus tying up server resources?

If session state is enabled (enableSessionS tate=true), all of these
requests get queued and processed one after another.

And if the user finds a particular page with poor enough performance,
say one that takes a few seconds to render, by holding down the F5 key
for a minute, he can queue up hundreds of requests and tie up the
server spiking it's cpu for an hour or even hours.

I've tested this and used the Performance Monitor to confirm this is
what goes on.

Shouldn't there be a feature of IIS or ASP.NET that allows you to limit
the number of requests per ASP.NET session so this is avoided?

[bruce barker]

this called a denial of service attack. generally your firewall would
prevent this. tying to session means little, as an attacker would know not
to send a session cookie, forcing a new session. the inproc session manager
is vey prone to this attack, as just create new session until asp.net
recycles, losing all session data.

-- bruce (sqlwork.com)

<st************ **@hotmail.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .
| I very likely may be missing something here, but what stops a user from
| holding down the F5 key in their browser and generating hundreds of
| requests to IIS and thus tying up server resources?
|
| If session state is enabled (enableSessionS tate=true), all of these
| requests get queued and processed one after another.
|
| And if the user finds a particular page with poor enough performance,
| say one that takes a few seconds to render, by holding down the F5 key
| for a minute, he can queue up hundreds of requests and tie up the
| server spiking it's cpu for an hour or even hours.
|
| I've tested this and used the Performance Monitor to confirm this is
| what goes on.
|
| Shouldn't there be a feature of IIS or ASP.NET that allows you to limit
| the number of requests per ASP.NET session so this is avoided?
|