7

We had a major SharePoint outage a few months back because a user wedged their keyboard in such a way as to cause the Enter button to be pressed indefinitely. The user was on a customized people search page and hundreds of POSTs by the same user were submitted asynchronously, which overloaded the server.

Because I work in a large organization, I am looking for a more global way to prevent this from happening.

Is there a way to prevent multiple web form submissions by a common user within a short period of time within IIS?

I am aware we can write javascript to disable the button after it is clicked, but we are hoping to prevent this issue from occurring on other pages where a similar possibility may exist.

Update: It appears looking at the source code, the javascript is performing a document.location = url, whenever keycode 13 (Enter) is pressed. Again, we can write JS to prevent this in this location, but we also want to be able to guard against this kind of issue more generally... preferably at the IIS level.

Joel Coel
  • 12,910
  • 13
  • 61
  • 99
user1209640
  • 171
  • 1
  • 3
  • 2
    Add the JavaScript to every page? – Michael Hampton Oct 29 '12 at 16:32
  • Thanks for the comment, but unfortunately our SharePoint farm is very large where there are many developers all writing their own custom code. We are hoping for a lower level solution in IIS. – user1209640 Oct 29 '12 at 16:54
  • 1
    Improved user training, then? – Michael Hampton Oct 29 '12 at 16:57
  • If you have common javascript used throughout, then you could look at binding a general event handler to the submit on every form and trap it there. I don't believe there is anything built into IIS that would let you trap that situation at that level. The other option might be to write an HTTP handler in ASP.NET and you could probably detect it there. – dmarietta Oct 29 '12 at 19:49
  • 1
    I'm surprised there would not be anything achievable within a web server like IIS, especially since there are many community providers out there serving up ASP.Net to the public internet, and how easy it could be for a developer to write faulty javascript that could inadvertently take down a server. I think the issue I am describing could be akin to an accidental DDOS attack. – user1209640 Oct 31 '12 at 17:26
  • 1
    You would have to find a way to block more than 'x' connections from one IP address. Where x is greater than the amount of simultaneous connections typically used for a standard request with some additional buffer (or likely you'd just triple the number for safety). Likely you would need to use some sort of firewall device between end users and the SharePoint servers... flood protection is what some firewalls call it. – Ashley Nov 01 '12 at 20:52

3 Answers3

2

One option for this would be rate-limiting using something like http://www.iis.net/downloads/microsoft/dynamic-ip-restrictions which can be set to block the offending IP for a set amount of time.

You'd want to baseline the typical requests/second/IP before putting something like this into production, of course, but this should prevent a single user from being able to do something like that again.

Nathan V
  • 711
  • 5
  • 16
2

If the issue is simply avoiding impact due to the number of concurrent requests, there is an add-on for IIS 7, Dynamic IP Restrictions. (This capability is now built-in to IIS8). It's possible to configure this for log-only mode to determine what if any impact there would be before enabling the capability.

http://www.iis.net/downloads/microsoft/dynamic-ip-restrictions

  • Seamless integration into IIS 7.0 Manager.
  • Dynamically blocking of requests from IP address based on either of the following criteria:
    • The number of concurrent requests.
    • The number of requests over a period of time.
  • Support for list of IPs that are allowed to bypass Dynamic IP Restriction filtering.
  • Blocking of requests can be configurable at the Web Site or Web Server level.
  • Configurable deny actions allows IT Administrators to specify what response would be returned to the client. The module supports return status codes 403, 404 or closing the connection.
  • Support for IPv6 addresses.
  • Support for web servers behind a proxy or firewall that may modify the client IP address.

Dynamic IP Restrictions in action

Multiple form submits should be addressed at the application level. It's trivially easy to implement with master pages. The following jquery in the master page does the trick for all child content pages: 

$("form").submit(function () {
    $(":submit", this).attr("disabled", "disabled");
});

Another good practice that may be worth adopting: Post/Redirect/Get

http://en.wikipedia.org/wiki/Post/Redirect/Get

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
0

You can write a global level IIS module and check if same request coming from same user in a specific short time. then you can decide if allow request continue or not.

class CGlobalTestFilterModule:public CGlobalModule
{
public:
    GLOBAL_NOTIFICATION_STATUS 
        OnGlobalPreBeginRequest(IN IPreBeginRequestProvider * pProvider)
    {
    ...
   }
...
}

here is a good guide to implementing IIS modules : http://www.iis.net/learn/develop/runtime-extensibility/develop-a-native-cc-module-for-iis you can choose managed modules if you are more familiar with .NET

hassan.monfared
  • 71
  • 1
  • 4