Before getting started into creating the most secure MOSS or WSSv3 site that we can, it is prudent to firstly understand how SharePoint processes the relevant requests that it is handling and serving to external clients with an internet facing, as well as an internal site.
When an initial request is made to SharePoint, it is possible that the request actual never makes it to have been parsed by the ASP.NET handler that will push out the relevant SharePoint page. The first layer of permissions processing that SharePoint will handle are those that are given by the Windows kernel, gaining support from that substance of the HTTP driver that will ultimately serve the request through the relevant pipe. This HTTP driver is known as http.sys which is the primary handler for the SharePoint request, and has some mechanisms that deal with information handling and serving that help to protect the overall server environment.
The first of these is minimizing the request throughput in regards to URL length that can exist within a SharePoint URL. Although it is relatively common within a SharePoint URL for the URL name to become lengthy, the overall URL and its associated request assets size may never exceed 16k, the path segments can never be above 255 segments, and the length of a specific segment should not exceed the length of 260 characters, although this is a rather generous size in any respect, particularly if you have taken the time to carefully name your SharePoint sub sites correctly. The actual body of the request is not handled at this point, rather it is handled by ASP.NET. In any respect, hitting this type of restrictions is atypical within a common SharePoint environment, however keeping them in mind will ensure that your uses have the most fluid and consistent user experience and your application architecture doesn’t subjugate itself to undo service downtime. This comes primarily into play when developing custom applications and WebParts that leverage the SharePoint framework that may implement query string values. When developing the specific WebPart, is important to keep in mind that the amount of characters that exist in the WebPart query string do not exceed 260 characters otherwise the kernel mode restrictions will come into play.
There is a good purpose behind this restriction type. Several types of attacks that may happen against a SharePoint environment take on the role of appending various characters against the overall URL structure, by which it would allow arbitrary commands or code to be executed on the server. As well, if a malicious user where attempt to try various types of these attacks against the SharePoint server, it would result in possible service disruption as SharePoint struggles to serve the malformed user request. In order to track these malicious requests as they happen against a SharePoint environment, it is best to maintain active study of the HTTP logs so that pertinent addresses can be blocked if necessary (i.e. booted attempts). This log exists with all the rest of the IIS logs in the system 32 log directory, and will give you all the GET requests that may have been malicious towards your SharePoint environment.
Once the kernel level checks are done on the request from the client, it is time for ASP.NET 2.0 to begin handling the request, since this is the underlying basis that SharePoint is built on. This is handled by aspnet_filter.dll, which is also known as the ASP.NET worker process routine. This is kicked in following the whatever other ISAPI filters are placed on the IIS virtual server outside of the ASP.NET runtime ISAPI extension, which, in the current version of SharePoint as opposed to previous versions is fortunately none. The important concept to grasp however is that the kernel mode HTTP driver is the first level that is subjected to the request.
aspnet_filter.dll is the following section that is implemented after the request has passed through the kernel mode driver. This happens before managed code is executed. The aspnet_filter is responsible for two main actions, protecting those directories that are under ASP.NET supervision, and translating cookie less tickets into HTTP headers. The last of these is very important, since cookies less tickets are imperative for session state functionality. The other is protecting the directories that are managed under ASP.NET, which is related to the cookie less tickets since it happens after the ISAPI filter processes those tickets. The URL that a user request will be processed, and if it stats a certain directory that ASP.NET deems as protected, such as: /bin, /app_code, /app_data, /app_globalresources, /app_localresources, /app_webreferences, or/app_browsers, IIS will take over and return an error to the user.