Mozilla Security Blog
Categories: General

Attack Aware Applications

mozilla

7 responses

We are working hard to advance the security of Mozilla web applications.  This includes efforts such as threat modelling, security training, security throughout development, code review, testing, the bounty program, and more. In addition to secure development, we are also working to make our applications “attack aware”.

The idea behind an “attack aware” application is that the application is able to identify abnormal user actions that are not due to user errors, such as typos, and are instead the result of deliberate attacks against the application.  The goal is to detect a malicious user probing for application weaknesses and disable their ability to cause damage to the system.

An “attack aware” application uses a blacklist style detection of a potential attack. It is important to realize that this is not intended to be a substitute for secure design principles. Instead, it is an additional detection capability layered on top of a securely designed application. Think of a bank that has been built securely and then installs an alarm system to detect attempted attacks.

The value of “attack aware” applications is in the correct selection of detection points that minimize false positives and effectively detects malicious activity. For example, detecting a single tick (‘) within a text field (which could be used for SQL injection testing) is a bad detection point since there will be many false positives with legitimate uses of that character (e.g. the name O’malley, or just typos).

An example of a good attack detection point is detecting malicious values within password reset token URLs (e.g. site.com/resetToken?k=abc ‘ OR 1=1;–). There is no reason a user would accidentally modify the URL to include a potential SQL injection attack. Therefore false positive rates are low and the likelihood of the user purposively attacking the application is high. This is only one example of the detection points we are using. The OWASP AppSensor research project provides numerous detection points and covers this topic in much more detail.

The next question is what should be done after an attack is detected? Currently we are monitoring attack reports from our attack aware applications. This data is all fed into a security integration manager that allows us to monitor trends and investigate individual attack reports.  We are moving towards building a system that will enable us to selectively block the offending user from the application to prevent further attacks.

What about the bounty program? These additional defenses are slowly being rolled into our systems and we don’t expect any impact on the bounty program in the near future. However, when the time arrives one possible solution is to provide a mirror environment of bug bounty sites for security testing and enable the primary application with the attack aware capabilities and response options.

Michael Coates
Web Security Nomad

7 comments on “Attack Aware Applications”

  1. Ping from Tweets that mention Attack Aware Applications at Web Application Security -- Topsy.com on

    […] This post was mentioned on Twitter by George, mozwebsec. mozwebsec said: Attack Aware Applications: We are working hard to advance the security of Mozilla web applications.  This includ… http://bit.ly/gbo1k7 […]

  2. oxdef wrote on

    What about WAF?

    1. mcoates wrote on

      A WAF is able to detect generic attacks that could apply to any application. Our goal is to take the detection a step further and detect attacks that are specific to our applications. For example, if a user generates an access control exception within the application we will be able to capture this via a detection point. A WAF would be totally blind to this event. In other words, this “in-the-app” approach allows us to leverage application specific detection and also allows us to easily tie the actions to a specific authenticated user.

  3. Neal Poole wrote on

    You talk about blocking users based on these signals. But what’s to prevent an attacker from creating a page that causes a visitor to submit malicious looking requests? If you automate these kind of blocks, don’t you run the risk of opening up a denial of service attack against users of your website?

    1. mcoates wrote on

      Excellent point. Any sort of automatic blocking, which would first require extensive testing and tuning, would need to be limited to pages that can prevent against cross domain pollution. By that I am basically saying we could only auto block for detection points that are within pages that utilize CSRF controls to prevent against the type of scenario you described.

      However, it is still worthwhile to monitor and review other instances of attacks even if they could be influenced by a third party. Depending on the attacks and impact on our system, we may still need to block those attacks and follow up with the end user.

  4. albino wrote on

    I like the idea of providing mirror sites for bounty hunters. At least it would relieve the researcher’s burden of trying to be discrete among hordes of legitimate users. That said, if the attack-aware capabilities are entirely disabled there won’t be any way for the bug hunters to test them. Detecting attacks but substituting an ‘attack detected’ message for the response might be more appropriate. Then again, a potential attacker could use the mirror-server to practise attacks without being monitored, then hit the production server with a perfect payload straight away.

  5. Neal Poole wrote on

    mcoates: Totally agree. Thank you for the well thought out response. 🙂

    albino: “Then again, a potential attacker could use the mirror-server to practise attacks without being monitored, then hit the production server with a perfect payload straight away.”
    1. That assumes a “perfect payload” can circumvent these protections. In an ideal situation (from Mozilla’s perspective), the protections would be sufficient to prevent all attacks.
    2. Even if the protections don’t work perfectly, Mozilla is no worse off than they are now. After all, the code for many Mozilla sites is publicly available: an attacker can download it and set up their own test server. Setting up a mirror service would, at worst, not change anything about that behavior. On the other hand, it very well could incentivize attackers to target the mirror server, giving Mozilla request data which it can then use to better protect its servers.