In the early days of networked applications, application security was as simple as running programs on a "hardened box" behind a firewall. As general developer security IQ improved, we learned to write safer code, code that checked identities and principals, code that filtered user input.

Most hacker activity was targeted at getting network access anyway, so security was thought of more as the network and database administrator's domain and not really the developer's responsibility. However, things have changed.

The FBI estimates that 70% to 80% of attacks aren't going after the operating system or network software layers; they're after the applications that run on them.

Most intrusion detection and incident response implementations address network layer attacks, not application level attacks, and for the most part assume human interaction.

Besides all this, most "infrastructure"-centric defense strategies require unlimited administrative access to the server(s) on which your applications are deployed, which generally prevents you from using any of those technologies in a shared hosting environment.

So what happens when the bad guys attack our applications using intentionally implemented features that the application requires? Wouldn't the optimum application-level defense strategy be for applications to adjust themselves when attacked?

The .NET platform offers developers a wide variety of design opportunities to create such application features that would have been very difficult in pre-.NET applications.

As an introductory case study on "Self-Defensive Application Design Patterns," let's consider a login attack. Whether it's a brute force, dictionary, cross-site scripting, or an SQL injection attack - the authentication process is the most common attack target in a Web application.

The occasionally failed login is normal. People forget which password they used for a Web application or they mistype it, but a marked increase in failed logins may signal a hacker or automated hacking tool trying to gain access to your application.

Automated attacks often work this way:

• They use lexical builders to try all possible permutations of a user ID or password to find a valid login
• They use large dictionaries of common user names, passwords, and username/password combinations to find a valid login
• They use clever combinations of both

This repetition in and of itself may constitute a denial-of-service attack. The good news is that these repeated attempts are detectable and applications can respond.

We could, for example, define a "Failed Login Counter" class and create an application-scoped static instance to count the failed login attempts during a given time period.

One strategy we might use is to add an automatic lockout feature to the application. If an attack attempts a certain number of unsuccessful logins in a fixed period of time, then the account is locked and an e-mail with a confirmation code is sent to the user's pre-registered e-mail address requiring the user to either click on a generated link to reactivate his account or to return to the site and enter his username and password, along with the e-mailed confirmation code.

This technique alone won't mitigate denial-of-service attacks, but it will prevent an unauthorized access attack from succeeding because after a specified number of unsuccessful tries additional automated attempts will fail, even if the password is correct.

In another self-defending scenario, consider what to do if the Web application provides access to a knowledge base, and the data in the knowledge base is a unique company asset. The general public uses the application so the business requirements for the application demand that users not have to authenticate to use the search mechanism.

Intended users parametrically search the knowledge base index and narrow the result set scope until they select a specific article (or knowledge base record) and retrieve it.

An unscrupulous user might write an automation to try to gather all, or a significant part of, the knowledge base and steal a precious asset.

Our challenge is how to detect and prevent those automated retrievers without restricting valid customers. In this case there is no aberrant event state to catch our attention. Here all queries are "potentially" valid.

Well, we might create a class for instantiation as a session object and collect search and time data for frequency evaluation to determine when defensive action should be taken, such as marking the requesting IP address as "blocked" and denying all future requests from that address; of course, there are liabilities to that approach.

• It's possible that a valid user might be inadvertently blocked.
• "Unblocking" a restricted user might involve an expensive manual admin process that can't be automated because of the discretionary nature of the operation.
• A crafty attack might search until an IP address is blocked and then fetch a new IP address. When doing this serially an attack could effectively sidestep the countermeasure and retrieve all the data it wants.
• The countermeasure can't mitigate an automated attack that spoofs randomly selected IP addresses, or uses a multi-machine (distributed) attack vector.
• Blocking IP addresses in the application logic might inadvertently produce a self-inflicted denial-of-service attack.

By understanding this we might use the ASP.NET session object to introduce an intentional latency factor to search requests in our system. The pseudo-code might look something like this:

SearchRequest()
{
If ((TimeOfThisSearch - TimeOfLastSearch)  < 3 Minutes) 
     SearchFrequencyCount++
Else
SearchFrequencyCount--

TimeOfLastSearch = TimeOfThisSearch

Wait(SearchFrequencyCount * 30 Seconds)

ExecuteSearch()
}

This way each search action requested within three minutes of the last request adds 30 seconds of wait time before the user's request will execute. Each time the user waits three minutes between requests the delay is decreased by 30 seconds.

Manual use of the application's search mechanism and a subsequent review of the results should take an actual human user about three minutes, so human visitors won't experience the programmed delay, but automated searches will get slower and slower. This defense mechanism plays on the fact that brute force techniques fall apart when the period between attempts increases.

This is a good application-specific start to defending an application, but we should consider building applications with "defense in-depth." So let's look at some other techniques we might use to diversify an application's defenses.

We might begin by inspecting the user agent and ignoring requests that originate from unknown browser types and versions. It might disable some automated hacking tools, though not ones that simply script a known browser such as Internet Explorer.

If we can determine peak usage statistics, we might add application scope logic similar to what we implemented at the sessions level so that the application can evaluate aggregated request frequency and slow the response to search requests universally across sessions when it appears to be under attack.

So we have defended our knowledge base by incrementally slowing the responsiveness of search requests. At some point the wait will exceed the timeout threshold and those search requests will simply fail.

This approach protects the data, but comes at a cost. The attack is allowed to continue, and while the application eventually stops returning data to the attacker, the attack-er can degrade the application's performance and effectively pull off a denial-of-service attack.

Alternately, we could off-load some defenses from our application to IIS directly via the IIS ADSI Provider.

In ASP.NET we have access to the requesting client's IP address by way of the Http.Request.UserHostAddress property and the client machine's host name via HttpRequest.UserHostName. While they can be spoofed, they are often spoofed to mask identity, not to look like random requests from different users. To mask their uniqueness from us, the attack would have to randomize both the IP address and the host name - a technique that makes our job harder, but prevents other kinds of successful attacks.

By adding UserHostAddress and UserHostName to our search frequency logic, we could, at some threshold, ask IIS to simply deny access to the calling offender.

This is done by adding the offending caller to IIS's access filter list by calling the IIS ASDI provider methods IIsIPSecurity.IPDeny and, if appropriate, IIsIPSecurity.DomainDeny. The advantage here is that the application isn't slowed down by subsequent calls by the filtered attacker because the application never even gets the requests. IIS filters them and denies access, all the while never interacting with our search application.

As you can see, the challenge of in-depth application defense isn't so much in solving individual problems as it is in designing and understanding the impact of the combined complexities that a comprehensive strategy demands.

In our security travels we find that we're in a virtual arms race. Writing secure code is no longer about following a bundle of rules and best practices. We have to get out in front of the tide and build applications that defend themselves. We hope that these techniques serve as merely a first step on the road to developing truly secure applications.