Main Defenses

• To properly secure web applications, administrators must secure against any malicious user input. To do so, they must adequatly understand that user input cannot be trusted.

Defense mechanisms used within web applications can be separated into four categories:

1. Prevent unauthorized access

• Handling user access is done through three security mechanisms:
  • Authentication: Establishing whether a user is who he/she claims to be. This is most of the time done through conventional means, like a username and password. Security-critical applications supplement this with additional factors of authentication or even a multistage login process. Some website functionalities are huge concerns in this category: self-registration, account recovery, and a password change process.
  • Session Management: Once authenticated, the application uses session management to identify whch users the requests originate from. Commonly, this is done by issuing each user a token to identify a particular session. Subsequent HTTP requests include the token string. Some other means of performing session management include hidden form fields or URL query strings
  • Access Control: Making and enforcing user access is fundamental to assuring unauthorized access of information does not occur. Once the application knows who a request is coming from using the previous two mechanisms, privileges can be assigned and utilized to limit information access.

2. Prevent undesirable behavior resulting from malformed input

• Varieties of Input

Approaches to Input Handling

• "Reject Known Bad"
  • The usefulness of blacklist-based filters depends extremely upon the set of known bad inputs. Unfortunately, permutations or slight alterations of these inputs can often bypass even the most expansive of filters.
  • Some examples include: SELECT --> SeLeCt, or 1=1-- --> or 2=2--, alert('xss') --> prompt('xss'). Other alterations may include encoding characters or using nonstandard characters between expressions.
  • Many applications are also vulnerable to NULL byte attacks, which are executed by prepending a NULL byte like so: %00<script>alert(1)</script>. The NULL byte may stop an expression from being processed before any of the input has actually been validated

• "Accept Known Good"

  • Create a white-list defining a set of "literal strings, patterns, or criteria, that is known to match only benign input"
  • This is the most affect solution if it is possible to use it.
  • Issues arise in cases like accepting names with an apostrophe or hyphen within them.

• Sanitization

  • Sometimes need to accept data that cannot be guaranteed as safe, so you need to sanitize it. This can be done by removing malicious characters or by encoding or escaping characters before later processing occurs.
  • e.g. In defending against cross-site scripting, you can HTML-encode dangerous characters before embedding them in pages.

• Safe Data Handling

  • Quite simply, process data in a safe manner, such as using parameterized queries or avoiding passing user input to the command interpreter.

• Semantic Checks

  • Check that how data is being sent is also safe, such as making sure an account number is not altered before transmission to a server. Sometimes its not just about the syntactic validation, but also how and what information is being sent at certain times during server-client communication.

• Boundary Validation

  • At each 'boundary', or rather each point that data is being received, data must be validated. For instance, client-side there should be some general checks in place on the data. Then, the application server should make sure that SQL queries are safe and that requests such as SOAP messages are encoded (in this case encoding XML metacharacters).

• Multistep Validation and Canonicalization

  • Sometimes special characters or strings are removed. This may, inevitably, allow an encapsulated and malicious command to be processed intentionally. For instance, <scr<script>ipt> would become <script> if the inner part was removed.
  • Canonicalized: a process for converting data that has more than one possible representation into a "standard", "normal", or canonical form.
  • Sometimes data is also encoded and subsequently canonicalized. For instance, %2527 may become %27after being canonicalized.
  • Issues like these are extremely difficult to circumvent, and there is no single solution to them all.
    • One approach: perform sanitization recursively until no further modifications need to occur.
      • May be an infinite loop.
    • Another approach: case-by-case basis, based on certain types of validation performed.

3. Ensure appropriate behavior occurs even when web application is directly targeted.

• e.g. defensive and offensive measures taken to frustrate attacker

• Handling Errors (p.30)

  • It is fundamental for applications to handle unexpected errors gracefully

    • They can either recover from them or present a good error message to the user. Additionally, serve these error messages back to some logs.

    • In a production environment, error messages should never return system-generated messages or debug information. Too much information can be a security risk.

• Maintaining Audit Logs

  • Certain events should always be logged. These may include:

    • Authentication events, including successful logins, failed logins, and password changes. Transactions, blocked access attempts, and blacklisted/malicious input should also all be logged.

• Alerting Administrators

  • Anomalies in the usage of an application and business related functions should be reported to administrators. Whenever attack strings or hidden data modifications are noticed, they should also be alerted to an administrator.

  • Often times, signature and anomaly-based rules are used to identify malicious use of an application, and if levels are used in the rules set, then alerting can be based off of the rule level designations.

• Reacting to Attacks

  • In the event that an attacker systematically probes an application for vulnerabilities, the application can be setup in such a way as to react to these attacks. For instance, slowing, limiting, or completely stopping subsequent requests can be one security measure.

4. Managing web application by providing a means to monitor and configure it.

• While this is important, security experts shouldn't forget that administration mechanisms are yet another part of an application's attack surface. Any weaknesses in authentication, access control, or session management to this management interface may provide an attacker full access to admin privileges.