Web Application Security

Automating Test Cases

October 26th, 2011 by yboily

Earlier this year I wrote about some of the challenges of scaling security efforts in an organization, and I mentioned that we are working to adopt better tooling to assist us in this.  We have been working towards improving security in the development lifecycle by making security tests a part of the quality assurance process. In order to accomplish this we worked with the QA team at Mozilla to create a simple tool called Garmr to integrate automated security test cases as part of our continuous integration (CI) processes.

When we started the discussion about which tools to use, our requirements were pretty straightforward; it needed to be fast, simple, and accurate.  When we looked at Selenium and Mozmill the feedback we got from other teams is that although powerful, these frameworks were complex to configure properly, and had significant overhead to maintain as a project progresses.  Since the focus was on testing web applications in a repeatable fashion, we identified a set of required functionality and David Burns from the very awesome Mozilla QA team put together the Garmr prototype and initial test cases.

Garmr has been public since its initial version, but the tool has now reached the point where we will start to leverage it in our testing and CI processes.  The tool works by running a series of tests against target URLs and reporting back the results.  The results are currently formatted as a JUnit style XML report that can be consumed by other tools such as Jenkins.

Garmr Test Cases

Garmr currently supports two types of test cases that can be authored, an Active Test and a Passive Test.  ActiveTests are expected to make at least one HTTP request, and return the most relevant HTTP response after the check is completed.

Here is an example of an ActiveTest that makes a simple HTTP GET request:

class WebTouch(ActiveTest):
    run_passives = True
    description = "Make a GET request to the specified URL, and check for a 200 response after resolving redirects."
    def do_test(self, url):
        response = requests.get(url)
        if response.status_code == 200:
            result = self.result("Pass", "The request returned an HTTP 200 response.", None)
        else:
            result = self.result("Fail", "The response code was %s" % response.status_code, None)
        return (result, response)

The test case makes an HTTP Get request, and passes or fails dependent on the response code.  This very basic check does serve a purpose; it grabs an HTTP response to run passive tests against.  For an example of a more complex check, look at the StsUpgradeCheck implemented in the corechecks module.

PassiveTest instances receive a copy of an HTTP response and analyze it to determine if the test passes or fails.  In most circumstances, Garmr will run all of the configured PassiveTests against the result of each ActiveTest.  The goal of a passive test is to inspect each the response of a query for properties that are expected from a secure web application.

This is an example of a passive test that checks an HTTP response for the presence of X-Frame-Options headers:

class XFrameOptionsPresent(PassiveTest):
    description = "Check if X-Frame-Options header is present."
    def analyze(self, response):
        xfoheader = "X-Frame-Options"
        xfo = xfoheader in response.headers
        if xfo == False:
            result = self.result("Fail", "X-Frame-Options header not found.", None)
        else:
            result = self.result("Pass", "X-Frame-Options header present.", response.headers[xfoheader])
        return result

The goal is to allow developers to create test cases that are specific to their applications and gain the benefit of running pedantic checks for security related attributes such as cookies and headers each step of the way.  Note that there is no practical limitation on what a passive check does, as long as the result object is returned properly.

Using Garmr

The current version of Garmr can be downloaded from the Github repository at https://github.com/ygjb/Garmr.

Getting, installing, and using Garmr is very easy:

git clone https://github.com/ygjb/Garmr.git
cd Garmr
sudo python setup.py install
garmr -u http://my.target.app

Limitations

Garmr is an alpha tool.  The only part of it that we expect to remain stable at this point is the Xml Report format that it produces, since this is specified by the Jenkins tool chain that we are integrating with.

This tool is not intended to replace a typical dynamic or static analysis tool any more than the existence of Unit Tests replaces end to end functional testing, but it does provide a simple facility for QA, development, and security teams to collaborate on web application testing.

Currently the tool can be used to run a number of simple tests, and supports the ability to load modules; two examples of how a module would be written are included in djangochecks.py and webchecks.py

There is a list of features still to come:

• less noisy CLI
• proxy support (already supported in requests)
• sessions (controlled; sequence for active tests, with a cookie jar that is propagated through the session)
• detailed reporting, including the ability to record all HTTP requests and responses generated
• the ability to filter which passive checks are run by check name or by check type (i.e. cookies, headers, content-type, etc)
• support for additional protocols (websockets, spdy)
• Implement instances of each test case for each target scanned to allow them to retain state as a set of tests progresses.

I am very excited to see how the tool will develop over the next few months as we have an intern who will be working to implement these and other features, so please test it out, give us feedback (patches and feature requests are welcome too!).

Posted in Automated Testing, General    2 Comments

Mozilla Bug Bounty Update

October 4th, 2011 by mcoates

We’re nearly three quarters the way through 2011 and we wanted to provide an update on the progress of the Mozilla bug bounty programs.  The goal of the Mozilla bounty programs is to encourage security research in Mozilla software, reward the individuals that are participating in this research, and continue pursuing the safest browsing and web experience for all users.

The Firefox bug bounty was created in 2004 and has demonstrated its success over the past 7+ years. At the end of 2010, the bounty program was expanded and select high value Mozilla web sites were also included into a Mozilla web bounty program. Statistics on the success of the web bounty program were recently presented at the OWASP AppSecUSA conference and the slides, along with statistics, are available here.

Between the two bounty programs Mozilla has paid over $200,000 in bounties during 2011 for previously unknown security bugs in Firefox or our critical Mozilla web applications.  These programs have established a productive dialog between the Mozilla community and numerous security researchers. In addition, each bounty bug report has enabled Mozilla to further refine the security controls in our products and web applications to deliver a more secure browsing and web experience to hundreds of millions of users around the world.

If you are interested in getting involved in the Mozilla bug bounty program then please check out the following links:

• Mozilla bug bounty program overview
• Details and FAQ for Firefox bounty program
• Details and FAQ for Mozilla websites bounty program

- Michael Coates

Posted in General    Closed

Mozilla’s Secure Coding Guidelines for Web Applications

September 30th, 2011 by mcoates

We’re committed to security at Mozilla and take every opportunity throughout the development lifecycle to integrate security controls, guidance and verification. One of the items that we’ve found successful thus far is the secure coding guidelines document for web applications.  The goal of this document is to provide concise security guidance and security requirements that can be used in any web application.  While specific security controls may differ between applications, this baseline at least puts all applications and in a solid position in terms of security.

Take a look and feel free to use or adopt this information within your organization. Your recommended controls and risk tolerance may vary, but ultimately, providing clear security expectations to developers will lead to a more secure application in the end.

-Michael Coates

Posted in Uncategorized    3 Comments

Mozilla at OWASP AppSecUSA

September 19th, 2011 by mcoates

Mozilla will be sending several security folks to this year’s OWASP AppSecUSA conference held in Minneapolis, MN on Thursday and Friday (Sept 22, 23).  Stop by and find one of us to get one of our “Securing Mozilla” stickers.

We’ll be hosting the following events:

• Security Evolution – Bug Bounty Programs for Web Applications
• Open Source Demo Space – Visualizing Tracking on the Web
• OWASP Cheat Sheets
• AppSensor Summit

- Michael

Posted in General    2 Comments

Mozilla Hosting Open Source Security MeetUp

August 24th, 2011 by mcoates

On Thursday, Aug 25, Mozilla will be hosting the OWASP Bay Area chapter meeting. This free event will bring together nearly 100 security experts in the bay area to discuss current security topics and defenses.

Although the registration is now closed, we quickly hit the maximum number of attendees, anyone is welcome to watch the event online at air.mozilla.org . The video stream will begin at 6:30 PM Pacific Standard Time.

Schedule:

• 6:00 PM – 6:30 PM — Check-in, registration, networking
• 6:30 PM – 6:35 PM — Welcome Remarks/Agenda – Mandeep Khera
• 6:35 PM – 7:45 PM — Enabling Browser Security in Web Applications – Michael Coates, Mozilla
• 7:45 PM – 8:30 PM — Blackhat spam SEO – Julien Sobrier, Zscaler

Posted in Uncategorized    5 Comments

Mozilla Discusses New Browser & Web Security Features at European Security Conference

July 13th, 2011 by mcoates

Michael Coates from Mozilla’s Infrastructure Security team presented on top web security threats and how new security controls in Firefox can be leveraged to increase the security of a website and further protect users against malicious attacks.

Attackers are continuing to exploit issues that are challenging for web application owners to address throughout their applications.  Some of these issues include:
- cross site scripting vulnerabilities
- intercepting sensitive communications due to incorrect usage of SSL/TLS
- user confusion attacks such as click-jacking

New security controls in Firefox such as Content Security Policy, Strict Transport Security, and X-Frame-Options provide effective defense mechanisms that can be utilized by a web application to increase security.

This presentation was delivered to the annual ENISA & Forth Security Summer School held in Greece that attracts security and technology experts throughout Europe and also to a group of application security experts at the OWASP Greece chapter.

The full presentation can be viewed at the following link:

http://people.mozilla.org/~mcoates/WebSecurityControls.html

-Michael Coates

Posted in General    3 Comments

sha-512 follow-up and thank you

June 1st, 2011 by Chris Lyon

I made a statement in my previous post, SHA-512 w/ per Users Salts about a “significant hit rate” when it comes to dictionary attacking hashes. This significant hit rate is what we are scared of because we feel that not many people really know the ease of dictionary attacking the hashes, even if you have a large salt. It should be known that hashes alone are not meant to secure passwords. Additional steps are required such as increased iterations and salts are necessary to increase the cost of both offline brute force attacks and pre-computed tables. (rainbow tables) As I pointed out in my last post, most applications store the salt with the hash.

So, on my quest to prove a point and to prove how easy it is to dictionary hashes, I designed a system where we could perform dictionary attacks but under the strictest security possible. I didn’t want to use a public cloud nor did I want to know the passwords. My first goal with this project was to get two metrics, how fast could I dictionary 1 million hashes and what would be the hit rate.

The System

My first mission was to get a few systems for testing and since there was plenty of old desktops and Mac Book Pros around the office, I grabbed a few of these and started building my own. The first task was to build a client/server app that got the hash from the master database and then past the hash to the worker. Once that was done, the local server had to have a database for metrics and to keep timing and hit rates. The API that I wrote between the client and server was pretty simple, auth the request, request a hash, and ack the client “got the hash.” The client also needs to be multi-threaded, which is pretty simple at this point. When the worker was completed with a hash, send a true/false for the ability to dictionary the password and how long did it take.

Once this was built, and I am over simplifying the how in this post, I started testing against sample hashes to get an idea of scale. I started off with just three worker machines, all over 1 1/2 years old. I found that I could get an answer on any given hash under 4 seconds. The dictionary that I am using is my own dictionary, something I won’t release out to the public (yet) but I will say, it has 400,000 entries. I do have a more complete dictionary that is over 10 million entries, but it takes some significant time to process this dictionary but has a much higher hit rate.

Results

When I got the system tested and working, I was able to unleash it on 1 millions hashes. The results were pretty surprising in that I was able to completely process 1 million hashes in under 18 hours using just three older machines and get a 20% password hit. I did want to stress that we didn’t record the password, just if we got a match.

Imagine if I had more machines or even used ec2, I could cut that time down significantly. This is the biggest reason we are moving away from sha-512 and moving towards hmac with bcrypt.

Thank You

On a personal note, I did want to give one last “Thank you” to all the people in the community who I have had a chance to work with over the past 2 years. As many of you know, Friday June 3rd will be my last day at Mozilla as I am moving on to new challenges. The infrastructure security group wasn’t here when I started and I’m proud to say that it is now starting to put its feet down and establish itself as a “security enabler” for Mozilla and the community. The team that I am leaving behind is nothing short of top notch and will continue to be security enablers.

Once again, it has been a great ride and thank you all for your support.

Chris Lyon
Director of Infrastructure Security (Until June 3rd)
twitter: @cslyon

Posted in General, Passwords    3 Comments

SHA-512 w/ per User Salts is Not Enough

May 10th, 2011 by Chris Lyon

Back in January, I was having a causal conversation about passwords at a local gathering about security and was asked what we use for storing the passwords. I stated that we are using sha-512 w/ per user salts but we are looking at moving away from this standard to something much stronger. The response that I received from this person was pretty much in line with other comments I have received and seen on some of our forums. The two most common responses are: “Oh good, you are using per user salts” and “yeah, using sha-512 is much better than md5.” Granted, these comments are true, using sha-512 is better than using md5 and better than not using per user salts but there is still a weakness that I feel is overlooked.

Per user salts do provide value, but the problem is that they are typically stored with the hash. So the entry in the database looks something like this:

sha512${salt}${hash}

Or perhaps the hash is stored in a separate column or table and is grabbed as needed during password verification. Either way, both the hash and salt are stored in the same database.

In the event the hash was disclosed or the database was compromised, the attacker will already have one of the two values (i.e. the salt), used to construct the hash. All the attacker needs to do now is figure out the password entered into the hash formula and the order in which it was used. Order being:

hash = hash_operation({password} + {salt}) or;
hash = hash_operation({salt} + {password})

The two issues with this are: 1) since our source code is public, the order in which we salt is also public and; 2) due to our scale and usability, we store the hash and salt in the same place.

What am I getting at? The real problem is that we shouldn’t be solely replying on hashing algorithms to secure this data. Once the salt is known, it would be pretty trivial to dictionary a bunch of hashes in little or no time and get a pretty significant hit rate. (More to follow on this subject to follow in another post)

What is the solution? Right now the solution is moving away from sha-512 w/ per user salts to something like bcrypt but with a twist. The twist is adding in a layer of defense plus adding some controls over who can unlock the password equation. In pseudo code, this is what I mean:

{hmac_result} = hmac_create_operation( user_password + system_shared_password )
{bcrypt_result} = bcrypt_create_operation(( hmac_result + salt ) bcrypt iterations)

The bcrypt result would be stored in the database like this:

bcrypt$bcrypt_result$shared_key_version

The system_shared_password (aka nonce) is not stored within the database. Instead this data is stored on the operating system within a protected file. Using this configuration a SQL injection vulnerability that provides access to the password hash data would not provide access to the system_shared_password. Only under the scenario of a full system compromise would both secrets (password hashes, system_shared_password) be compromised.

We feel this solution gives us better controls around who can unlock the hashes and provides a layer of defense around the hashes. We also have put some code together thanks to fwenzel:

Why use per user salts at all? Two reasons, first per user salts ensure that two users with the same password will not have the same hash. Second, the use of salts prevents an attacker from using a precomputed rainbow table against the hashes.

More to come on this subject, as our goal is to increase security and the time in which it would take in order to brute or dictionary the hash. Our goal is and always to provide better protection around authentication systems.

Chris Lyon
Director of Infrastructure Security
a.k.a the hash buster.

Posted in General, Passwords    14 Comments

Mozilla Brings Web Application Security To University Students

April 25th, 2011 by mcoates

Over the weekend Mozilla led an open source boot camp at Stanford University with a great lineup of courses including a hands-on web security lab where students performed actual exploits against a vulnerable web application.

The goal of the web security workshop was to educate students about top security threats facing today’s web applications. By allowing students to perform exploits themselves, the students were able to fully grasp both the impact of these weaknesses and also the ease at which an attacker could compromise a vulnerable application. The combination of the lab actives and secure coding principles provided the next generation of computer scientists with the skills to better understand web application threats and the importance of building security into their applications.

Unlike a traditional presentation where there is one speaker and many listeners, the web security workshop leveraged a vulnerable web application platform created by OWASP that enabled students to perform actual exploits against a running web application.

The workshop addressed four prominent web application security issues:

• cross site scripting
• access control
• SQL injection
• cross site request forgery

The event was structured to provide each student with an understanding of the vulnerability, knowledge of the impacts and risks the vulnerability poses to users, the ability to exploit the vulnerability within a running application, and the secure design patterns necessary to avoid these weaknesses in their own applications.

The web security workshop was a great success and received very strong feedback from the students.  Students particularly enjoyed the lab element that allowed them to put the new skills they’d just learned into use.

The full slide deck and notes on how to setup the web security testing software are online for anyone that would like to work through the material on their own.  Mozilla is hoping to conduct similar open source workshops at other universities around the world.

Full List of Mozilla courses at the boot camp:

• 7 Lessons from Mozilla – Pascal Finette & Todd Simpson, Mozilla Labs
• Hacking the Firefox UI, Shawn Wilsher & Frank Yan
• Managing Software at Internet Scale, Christian Legnitto
• Web Security, Hands on Learning, Michael Coates
• Frontend Development Foundations, Matthew Claypotch
• Scaling a Web Application, Jeff Balogh

Michael Coates
Web Security Nomad
http://people.mozilla.org/~mcoates/

Posted in General    1 Comment

Enabling Browser Security in Web Applications

March 31st, 2011 by mcoates

HTTPOnly, Secure Flag, Strict Transport Security, X-Frame-Options, Content Security Policy

The vast majority of application security occurs within the application’s code. However, there are a few key security controls that are enabled by the web application dictating security properties to the web browser. These security properties enable the browser to impose additional security controls on items such as cookie handling, framing, and even the processing of JavaScript.  These controls provide an additional layer of defenses which will either eliminate certain attack vectors or, at a minimum, minimize the impact of particular client-side attack types.

Some of these defensive controls have been around for awhile and others are newly supported in Firefox 4 and other modern browsers.  Mozilla has been rolling out these controls across all of our websites with a high degree of success.  It should be noted that these controls are not a substitute for secure development practices. Instead, they are another layer of defense that can be used to protect users and data in the event of an unknown gap elsewhere in your application.

HTTPOnly

Benefit: Minimizes impact of cross site scripting vulnerability by preventing JavaScript access to the session cookie.

Limitations: Does not prevent against any other malicious actions from XSS (phishing, malicious redirects, etc)

Example within HTTP Response:
Cookie: sessiondID=kljahsdf123; HTTPOnly;

Additional Reading:
http://www.owasp.org/index.php/HttpOnly

Secure Flag

Benefit: Instructs the browser to never send the cookie over a HTTP request. The cookie can only be sent over HTTPS. This works even if the user manually types in a request for HTTP. The HTTP request will be sent, but the browser will not send any cookies marked as “SECURE”

Limitations: The HTTP Request is still sent and this could be manipulated by a man in the middle to perform convincing phishing attacks (See Strict Transport Security for solution).

Example within HTTP Response:
Cookie: sessiondID=kljahsdf123; SECURE;

Additional Reading:
http://code.google.com/p/browsersec/wiki/Part2
https://developer.mozilla.org/en/DOM/document.cookie

Note: When setting both HTTPOnly and SECURE flags you will simply have both values for the cookie:
Cookie: sessiondID=kljahsdf123; HTTPOnly; SECURE;

Strict Transport Security

Benefit: Instructs the browser to never send requests to the domain over HTTP. Requests can only be sent over HTTPS.  Think of this as the Secure flag for the entire request. This will protect the user even if they manually type in HTTP into the URL. The browser will upgrade this to HTTPS, assuming the site has previously enabled HSTS, and only the HTTPS request will be sent over the network.

Limitations: Only supported in most recent browser versions; however, support is quickly growing.

Example within HTTP Response:
Strict-Transport-Security: max-age=60000

Additional Reading:
https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security

X-Frame-Options
Benefit: Instructs the browser to disallow framing of a domain or limit framing to only sites of the same domain.  This prevents clickjacking attacks and other malicious framing actions.

Limitations: Not supported in very old browser versions.

Example within HTTP Response:
X-Frame-Options: DENY
or
X-Frame-Options: SAMEORIGIN

Additional Reading:

https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header

Content Security Policy (CSP)
Benefit:  CSP provides some amazing benefits. After a website is setup appropriately (no use of inline JavaScript) and a policy has been established, CSP will effectively prevent XSS where attacker controlled data is embedded in the HTML document.  This works since the policy has established what JavaScript code is allowed and any other JavaScript that may make its way into the webpage via user input is flagged by the browser and blocked.

Limitations: Supported in Firefox 4 and plans for support in Chrome.  It is still possible to introduce XSS vulnerabilities by not properly validating and sanitizing JSON content, or by including attacker controlled data in dynamically generated Javascript code.  Also, even if CSP is only supported by a portion of users it can act as an alerting system via the the report-uri to detect and report CSP violations that could be an attack.

Example within HTTP Response:
X-Content-Security-Policy: allow ‘self’ *.mydomain.com

Additional Reading:
https://developer.mozilla.org/en/Introducing_Content_Security_Policy
https://developer.mozilla.org/en/Security/CSP/Using_Content_Security_Policy

Michael Coates
Web Security Nomad
http://people.mozilla.org/~mcoates/

Posted in General    Closed

« Previous Page — Next Page »