Improving Web Application Security: Threats and - CGISecurity

54 Part I: Introduction to Threats and CountermeasuresIdentify Entry PointsThe entry points of your application also serve as entry points for attacks. Entrypoints might include the front-end Web application listening for HTTP requests. Thisentry point is intended to be exposed to clients. Other entry points, such as internalentry points exposed by subcomponents across the tiers of your application, mayonly exist to support internal communication with other components. However, youshould know where these are, and what types of input they receive in case anattacker manages to bypass the front door of the application and directly attack aninternal entry point.For each entry point, you should be able to determine the types of gatekeepers thatprovide authorization and the degree of validation.Logical application entry points include user interfaces provide by Web pages,service interfaces provided by Web services, serviced components, and .NETRemoting components and message queues that provide asynchronous entry points.Physical or platform entry points include ports and sockets.Identify Privileged CodePrivileged code accesses specific types of secure resources and performs otherprivileged operations. Secure resource types include DNS servers, directory services,environment variables, event logs, file systems, message queues, performancecounters, printers, the registry, sockets, and Web services. Secure operations includeunmanaged code calls, reflection, serialization, code access security permissions, andmanipulation of code access security policy, including evidence.Privileged code must be granted the appropriate code access security permissions bycode access security policy. Privileged code must ensure that the resources andoperations that it encapsulates are not exposed to untrusted and potentially maliciouscode. .NET Framework code access security verifies the permissions granted tocalling code by performing stack walks. However, it is sometimes necessary tooverride this behavior and short-circuit the full stack walk, for example, when youwant to restrict privileged code with a sandbox or otherwise isolate privileged code.Doing so opens your code up to luring attacks, where malicious code calls your codethrough trusted intermediary code.Whenever you override the default security behavior provided by code accesssecurity, do it diligently and with the appropriate safeguards. For more informationabout reviewing code for security flaws, see Chapter 21, “Code Review.” For moreinformation about code access security, see Chapter 8, “Code Access Security inPractice” and Chapter 9, “Using Code Access Security with ASP.NET.”