0

To prevent DOS attacks in my ASP.NET C# application, i have implemented throttling with help of Jarrod's answer in this post. Best way to implement request throttling in ASP.NET MVC?

But this uses Ip address, which makes it vulnerable to advanced attackers who can change it easily. Another option to identify anonymous users is to use their session ID.

I think that it can't be changed until the user restarts the browser, so it can be a good alternative. But i am not sure from the security point of view. Kindly tell me if it is safe or not to use it? If not, then is there any other method to achieve this purpose? Thanks


Edit:
There are some methods that need a longer throttle. That's why i need a programmatic throttle of about 5 secs to 2 mins. I have configured Dynamic Ip Restrictions for IIS, but i can't specify such large time for it.

Community
  • 1
  • 1
It's a trap
  • 1,333
  • 17
  • 39
  • 1
    You can refer also https://technet.microsoft.com/en-us/library/cc750213.aspx – Mukul Varshney Sep 26 '16 at 05:45
  • Acoording to this: http://stackoverflow.com/questions/9726576/system-web-httpcontext-current-request-userhostaddress an ip received from `HttpContext.Request.UserHostAddress` might be a router address. So there could be multiple hosts behind that. – DerpyNerd Sep 26 '16 at 05:47
  • 2
    I don't believe that the attacker will use his browser any way – Haitham Shaddad Sep 26 '16 at 05:47
  • If you believe changing IP of request is easier than making scripted request for new cookie... you may be in for a lot of new interesting ideas... I'd recommend checking posts tagged with "web-scraping" to learn some of the ways to script sites. – Alexei Levenkov Sep 26 '16 at 05:48
  • @AlexeiLevenkov does that mean session Id is not safe for my use case? – It's a trap Sep 26 '16 at 05:49
  • @HaithamShaddad then how can i secure the site from them? there are some expensive tasks that need to be throttled for longer time, so just implementing Dynamic Ip restrictions in IIS may not be enough – It's a trap Sep 26 '16 at 05:54
  • 1
    I belive (I may be wrong) that in this case you should use something ready made, maybe on IIS level or a hardware level – Haitham Shaddad Sep 26 '16 at 05:57
  • It is completely your call - requiring session ID (or some other cookie) on most pages may help you somewhat... – Alexei Levenkov Sep 26 '16 at 05:58
  • @AlexeiLevenkov IIS level security will be fine for most of the methods except 1or 2 as they need a longer throttling. For what i have implemented till now, they must have a session ID to process. So can i rest assured? – It's a trap Sep 26 '16 at 06:03
  • Only you / your team/ someone explicitly testing your site can answer whether it is enough for your particular case or not. SO answers can explain things, but can't make decisions for you. – Alexei Levenkov Sep 26 '16 at 06:07
  • 1
    IP address can be spoofed, session ID can be spoofed too. I mean, if they're not interested in receiving a response they can send literally anything at you. The significance IP address and session ID have is dependent on the assumption that the client is expecting a response. I took some networking classes and I vaguely recall that the best DDOS protection isn't done in software, it's done by your DNS server somehow. – Chris Rollins Sep 26 '16 at 06:14
  • @AlexeiLevenkov to make that decision, i need to get my facts right. If i am taking my decision believing something that's not true, then it may be trouble. – It's a trap Sep 26 '16 at 06:16

1 Answers1

1

I think your terminology might be mixed up. DoS is Denial of Service. Someone changing multiple records or requesting functionality is not a DoS attack and normally, most DoS attacks are Distributed, hence DDoS.

What you are requesting based on the link you provided is called throttling... but as others have suggested, the sessionid is simply a value passed up in a cookie and can be easily modified to bypass a check just as you can simply put a proxy in front of the request to mask the source IP between requests.

Therefore, if you only wish to throttle then you need to implement authentication in front of the functionality you want to protect, use the throttling code you posted and maybe throw a CSRF token in as well for good measure.

BUT... if you want to stop DDoS, it ain't going to happen at Layer 7 since the data is already at the server.

timkly
  • 793
  • 6
  • 14
  • How would you get the value of CSRF token in the action method. Another thing is if cookie value can be tampered to change session id, how can CSRF token be used? It is also stored in the cookie. – It's a trap Sep 26 '16 at 08:48
  • You can pass CSRF tokens to the server using the POST method (ideal) and then validate that against a known CSRF token on the server (usually stored in the session). This means in order to perform a request and they have changed/removed the session id from the cookie then they first need to make a request to the server to get the CSRF token and then pass that back up in the POST request. – timkly Sep 27 '16 at 00:08
  • Hi. I am still not able to get what help can CSRF token do that sessionId can't. both are stored in session, both can be generated by a new cookie request. And as Alexie pointed out in comments, requesting a new cookie may be easier than changing the ip of the request. – It's a trap Sep 27 '16 at 05:12
  • The CSRF value is stored in the session, not the cookie and then when a form is submitted, the CSRF token is posted up as a value and then compared against the session value (and the CSRF token is included in the form from the server). So this means that even if the user regenerates a new session id. without the CSRF token from the server, they can make requests to change data. – timkly Sep 30 '16 at 00:46