Tuesday, July 1, 2008

Applications take a beating...and keep taking it

Let's consider the average web application. It may or may not be secure. It may have obvious vulnerabilities just waiting to be exploited or it could be relatively secure minus a more obscure vulnerability buried in the app. If an attacker were targeting this app, they would perform a series of steps to try and identify a vulnerability. Perhaps they would insert xss type string into various input fields? Maybe integers within the URL arguments would be incremented or replaced with SQL injection attempts. Another great target is the cookie values. Maybe these are modified or removed.

The problem I have is that the application just sits there and waits; waits to be compromised. This is akin to someone taking a stick and hitting you repeatedly while you do nothing. If the application is clearly being attacked, then I believe it should respond.

There are challenges in responding. First, it is tough to respond to an unauthenticated user. You don't know who they are and it would be nearly impossible to accurately track them from request to request. So lets consider only authenticated users. In fact, that is a good move because many of the more complex features are available to the authenticated users anyway. Second, we need to determine what is an attack versus what is user error.

Now, if we can detect a user that is performing basic malicious activity against our application, we can take action BEFORE they locate a vulnerability. Perhaps our action is to logout the user and lock the account? That would make it very difficult for our attacker to discover a vulnerability if their account was locked due to a security error and they had to contact a phone number to unlock it.

The response actions would have to be tuned to prevent taking action against innocent users. However, there are many cases where we can take responsive action with little fear of targeting the innocent. For instance, how many innocent users would modify a POST request and include a cross site scripting attack? Odds are this is bad.

If we identified a collection of detection points within our application and then collected any firings of these intrusion events we would be able to monitor the malicious activity of the users. Once defined thresholds had been reached, the application can perform a defensive response action such as warning the user or locking the account.

These issues are all being explored as part of the OWASP Summer of Code AppSensor project.

-Michael Coates

4 comments:

  1. Michael,

    I agree with your statement the web applications shouldnt just sit there and do nothing.
    However in the applications I develop I find that automatic reactions are too dangerous.
    Instead I try to detect as many forms of attacks as possible and raise security alerts. Its then up to a human to analyse these alerts and to decide whether they are false positives, relatively reasonable actions by the user or genuine attacks.
    So far this approach has proved to be very successful.

    SB

    ReplyDelete
  2. Thats a great approach when reliable and trained staff are available to quickly respond to the alerts. The fact of the matter is that most organizations do not employ a trained IDS team with adequate understanding of the application to make such timely decisions.

    Aside from the gray areas of possible attacks/user error, would you agree that an automated response is appropriate if you detect hundreds of SQL injection attacks from a single user? Thats more of my thinking. Lets step out of the gray area and nab those people who are clearly attacking us.

    By the way, kudos for having dedicated staff. Consider taking a look at the AppSensor project (when complete) for more possible detection points.

    -Michael Coates

    ReplyDelete
  3. Michael,

    where you can reliably detect specific types of attacks then I have no problem with having the option of automatically reacting, for example by disabling a users account.
    However I would want this to be a highly configurablable option.
    There is always the danger that the bad guys could use this type of mechanism as a form of denial of service attack.
    Web applications should be robust enough to handle things like SQL injection attacks (I know many are not!).
    If they are then why do you need to automatic disable users who (apparently) attempt such attacks?
    I would rather gather the evidence and then decide what to do about that user.
    However if you think you can reliably detect specifc attacks then yes, an automatic response could be appropriate.

    Your AppSensor project looks very interesting - do you have any idea when it will be made public?

    SB

    ReplyDelete
  4. "However I would want this to be a highly configurablable option."

    Exactly, the intended implementation of the AppSensor is to utilize a policy file which sets thresholds where reponsive action should be taken based upon the total number and types of user generated alerts.

    "Web applications should be robust enough to handle things like SQL injection attacks (I know many are not!). If they are then why do you need to automatic disable users who (apparently) attempt such attacks?"

    The idea here is that we identified a user that is malicious and intent on doing harm or something bad to the site. While they weren't (hopefully) able to find a SQL injection issue, that doesn't mean they won't find something else (accesss control failure, xss, etc). Since we know they are bad, lets cut them off now, before they do harm.

    "I would rather gather the evidence and then decide what to do about that user."

    You could configure your reponse policy to simply enable detailed user logging instead of locking out the account. Your call there.

    "Your AppSensor project looks very interesting - do you have any idea when it will be made public?"

    The beta release will be August 31.

    The mailing list just got started up and is here:
    https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project

    -Michael Coates

    ReplyDelete

Note: Only a member of this blog may post a comment.