Preventing Denial-of-Service Attacks ASP.NET

Web services are the most attractive target for hackers because even an unsophisticated hacker can bring down a server by repeatedly calling a web service.Ajax web portals are a good target for such DoS attacks because if you just visit the home page repeatedly without preserving a cookie, every hit is producing a new user, a new page setup, and new widgets.

You can try this yourself with a simple code like this:


To your great surprise, you will notice that after a couple of calls, you will simply get no response.It’s not that you brought down the server, but that your requests are being rejected.You no longer get any service,thus you achieve denial of service (for yourself), and the site is happy to deny you of service (DYoS).

A simple trick to remember how many requests are coming from a particular IP is to record a caller’s IP in the ASP.NET cache and count the requests per IP.When the count exceeds a predefined limit,reject further requests for a specific duration, say 10 minutes. After 10 minutes,allow requests from that IP again.

The ActionValidator class maintains a count of specific actions such as first visit,revisit, asynchronous postbacks,adding a new widget, adding a new page, etc.It checks whether the count for a specific IP exceeds the threshold value or not.The following code shows the enumeration that contains the type of actions to check for and their threshold value for a specific duration, which is 10 minutes:

public static class ActionValidator


A static method named IsValid does the check. It returns true if the request limit is not passed and false if the request needs to be denied. Once you return false, you can call Request.End( )and prevent ASP.NET from proceeding further.You can alsoswitch to a page that shows something like “Congratulations! You have succeeded in a denial-of-service attack (for you).”

public static bool IsValid( ActionTypeEnum actionType )


The cache key is built with a combination of action types and client IP addresses.It first checks if there’s any entry in the cache for the action and the client IP. If not, start the count and remember it for the IP cache for the specific duration. The absolute expiration on a cache item ensures that after the duration, the cache item will be cleared and the count will restart When there’s already an entry in the cache, it will get the last hit count and check if the limit has been exceeded. If not, then the counter will be increased.There is no need to store the updated value in the cache again by calling Cache[url]=hit; because the hit object is determined by reference, it is changed in the cache every time as well. In fact, if you put it in the cache again, the cache expiration counter will restart and fail the logic of restarting count after specific duration.

The usage is very simple:

protected override void OnInit(EventArgs e)


Of course you can put in a Cisco fire wall and you get a guarantee from your hosting provider that its entire network is immune to DoS and distributed DoS (DDoS) attacks. But what they guarantee is protection against a network-level attack, such as TCP SYN attacks or malformed packet floods. There is no way your hosting provider can analyze the packet to find out if a particular IP is trying to load the site to many times without supporting cookies or adding too many wid gets.These are application-level DoS attacks that cannot be prevented with hard ware, operating systems, or fire walls, and must be implemented in your own code.

There are very few web sites that take such precautions against application-level DoS attacks.There fore,it’s quite easy to make servers go mad by writing a simple loop and hitting expensive pages or web services continuously from your home broadband connection.


Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

ASP.NET Topics