Verified cryptography for Firefox 57

Traditionally, software is produced in this way: write some code, maybe do some code review, run unit-tests, and then hope it is correct. Hard experience shows that it is very hard for programmers to write bug-free software. These bugs are sometimes caught in manual testing, but many bugs still are exposed to users, and then must be fixed in patches or subsequent versions. This works for most software, but it’s not a great way to write cryptographic software; users expect and deserve assurances that the code providing security and privacy is well written and bug free.

Even innocuous looking bugs in cryptographic primitives can break the security properties of the overall system and threaten user security. Unfortunately, such bugs aren’t uncommon. In just the last year, popular cryptographic libraries have issued dozens of CVEs for bugs in their core cryptographic primitives or for incorrect use of those primitives. These bugs include many memory safety errors, some side-channels leaks, and a few correctness errors, for example, in bignum arithmetic computations… So what can we do?

Fortunately, recent advances in formal verification allow us to significantly improve the situation by building high assurance implementations of cryptographic algorithms. These implementations are still written by hand, but they can be automatically analyzed at compile time to ensure that they are free of broad classes of bugs. The result is that we can have much higher confidence that our implementation is correct and that it respects secure programming rules that would usually be very difficult to enforce by hand.

This is a very exciting development and Mozilla has partnered with INRIA and Project Everest  (Microsoft Research, CMU, INRIA) to bring components from their formally verified HACL* cryptographic library into NSS, the security engine which powers Firefox. We believe that we are the first major Web browser to have formally verified cryptographic primitives.

The first result of this collaboration, an implementation of the Curve25519 key establishment algorithm (RFC7748), has just landed in Firefox Nightly. Curve25519 is widely used for key-exchange in TLS, and was recently standardized by the IETF.  As an additional bonus, besides being formally verified, the HACL* Curve25519 implementation is also almost 20% faster on 64 bit platforms than the existing NSS implementation (19500 scalar multiplications per second instead of 15100) which represents an improvement in both security and performance to our users. We expect to ship this new code as part as our November Firefox 57 release.

Over the next few months, we will be working to incorporate other HACL* algorithms into NSS, and will also have more to say about the details of how the HACL* verification works and how it gets integrated into NSS.

Benjamin Beurdouche, Franziskus Kiefer & Tim Taubert

Mozilla Releases Version 2.5 of Root Store Policy

Recently, Mozilla released version 2.5 of our Root Store Policy, which continues our efforts to improve standards and reinforce public trust in the security of the Web. We are grateful to all those in the security and Certificate Authority (CA) communities who contributed constructively to the discussions surrounding the new provisions.

The changes of greatest note in version 2.5 of our Root Store Policy are as follows:

  • CAs are required to follow industry best practice for securing their networks, for example by conforming to the CA/Browser Forum’s Network Security Guidelines or a successor document.
  • CAs are required to use only those methods of domain ownership validation which are specifically documented in the CA/Browser Forum’s Baseline Requirements version 1.4.1.
  • Additional requirements were added for intermediate certificates that are used to sign certificates for S/MIME. In particular, such intermediate certificates must be name constrained in order to be considered technically-constrained and exempt from being audited and disclosed on the Common CA Database.
  • Clarified that point-in-time audit statements do not replace the required period-of-time assessments. Mozilla continues to require full-surveillance period-of-time audits that must be conducted annually, and successive audit periods must be contiguous.
  • Clarified the information that must be provided in each audit statement, including the distinguished name and SHA-256 fingerprint for each root and intermediate certificate in scope of the audit.
  • CAs are required to follow and be aware of discussions in the mozilla.dev.security.policy forum, where Mozilla’s root program is coordinated, although they are not required to participate.
  • CAs are required at all times to operate in accordance with the applicable Certificate Policy (CP) and Certificate Practice Statement (CPS) documents, which must be reviewed and updated at least once every year.
  • Our policy on root certificates being transferred from one organization or location to another has been updated and included in the main policy. Trust is not transferable; Mozilla will not automatically trust the purchaser of a root certificate to the level it trusted the previous owner.

The differences between versions 2.5 and 2.4.1 may be viewed on Github. (Version 2.4.1 contained exactly the same normative requirements as version 2.4 but was completely reorganized.)

As always, we re-iterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve.

Mozilla Security Team

Removing Disabled WoSign and StartCom Certificates from Firefox 58

In October 2016, Mozilla announced that, as of Firefox 51, we would stop validating new certificates chaining to the root certificates listed below that are owned by the companies WoSign and StartCom.

The announcement also indicated our intent to eventually completely remove these root certificates from Mozilla’s Root Store, so that we would no longer validate any certificates issued by those roots. That time has now arrived. We plan to release the relevant changes to Network Security Services (NSS) in November, and then the changes will be picked up in Firefox 58, due for release in January 2018. Websites using certificates chaining up to any of the following root certificates need to migrate to another root certificate.

This announcement applies to the root certificates with the following names:

  • CA 沃通根证书
  • Certification Authority of WoSign
  • Certification Authority of WoSign G2
  • CA WoSign ECC Root
  • StartCom Certification Authority
  • StartCom Certification Authority G2

Mozilla Security Team

A Security Audit of Firefox Accounts

FXA-01-reportTo provide transparency into our ongoing efforts to protect your privacy and security on the Internet, we are releasing a security audit of Firefox Accounts (FxA) that Cure53 conducted last fall. At Mozilla, we sponsor security audits of core open source software underpinning the Web and Internet, recently relaunched our web bug bounty program, find and fix vulnerabilities ourselves, and open source our code for anyone to review. Despite being available to more reviewers, open source software is not necessarily reviewed more thoroughly or frequently than closed source software, and the extra attention from third party reviewers can find outstanding issues and vulnerabilities. To augment our other initiatives and improve the overall security of our web services, we engage third party organizations to audit the security and review the code of specific services.

As Firefox’s central authentication service FxA is a natural first target. Its security is critical to millions of users who rely on it to authenticate with our most sensitive services, such as addons.mozilla.org and Sync. Cure53 ran a comprehensive security audit that encompassed the web services powering FxA and the cryptographic protocol used to protect user accounts and data. They identified 15 issues, none of which were exploited or put user data at risk.

We thank Cure53 for reviewing FxA and increasing our trust in the backbone of Firefox’s identity system. The audit is a step toward providing higher quality and more secure services to our users, which we will continue to improve through our various security initiatives. In the rest of this blog post, we discuss the technical details of the four highest severity issues. The report is available here and you can sign up or log into Firefox Accounts on your desktop or mobile device at: https://accounts.firefox.com/signup

 

FXA-01-001 HTML injection via unsanitized FxA relier Name

The one issue Cure53 ranked as critical, FXA-01-001 HTML injection via unsanitized FxA relier Name, resulted from displaying the name of a relier without HTML escaping on the relier registration page. This issue was not exploitable from outside Mozilla, because the endpoint for registering new reliers is not open to the public. A strict Content Security Policy (CSP) blocked most Cross-Site-Scripting (XSS) on the page, but an attacker could still exfiltrate sensitive authentication data via scriptless attacks and deface or repurpose the page for phishing. To fix the vulnerability soon after Cure53 reported it to us, we updated the template language to escape all variables and use an explicit naming convention for unescaped variables. Third party relier names are now sanitized and escaped.

FXA-01-004 XSS via unsanitized Output on JSON Endpoints

The first of three issues ranked high, FXA-01-004 XSS via unsanitized Output on JSON Endpoints, affected legacy browsers handling JSON endpoints with user controlled fields in the beginning of the response. For responses like the following:

    {
        "id": "81730c8682f1efa5",
        "name": "<img src=x onerror=alert(1)>",
        "trusted": false,
        "image_uri": "",
        "redirect_uri": "javascript:alert(1)"
    }

an attacker could set the name or redirect_uri such that legacy browsers sniff the initial bytes of a response, incorrectly guess the MIME type as HTML instead of JSON, and execute user defined scripts.  We added the HTTP header X-Content-Type-Options: nosniff (XCTO) to disable MIME type sniffing, and wrote middleware and patches for the web frameworks to unicode escape <, >, and & characters in JSON responses.

FXA-01-014 Weak client-side Key Stretching

The second issue with a high severity ranking, FXA-01-014 Weak client-side Key Stretching, is “a tradeoff between security and efficiency”. The onepw protocol threat model includes an adversary capable of breaking or bypassing TLS. Consequently, we run 1,000 iterations of PBKDF2 on user devices to avoid sending passwords directly to the server, which runs a further 216 scrypt iterations on the PBKDF2-stretched password before storing it. Cure53 recommended storing PBKDF2 passwords with a higher work factor of roughly 256,000 iterations, but concluded “an exact recommendation on the number of iterations cannot be supplied in this instance”. To keep performance acceptable on less powerful devices, we have not increased the work factor yet.

FXA-01-010 Possible RCE if Application is run in a malicious Path

The final high severity issue, FXA-01-010 Possible RCE if Application is run in a malicious Path, affected people running FxA web servers from insecure paths in development mode. The servers exposed an endpoint that executes shell commands to determine the release version and git commit they’re running in development mode. For example, the command below returns the current git commit:

var gitDir = path.resolve(__dirname, '..', '..', '.git')
var cmd = util.format('git --git-dir=%s rev-parse HEAD', gitDir)
exec(cmd, …)

Cure53 noted malicious commands like rm -rf * in the directory path __dirname global would be executed and recommended filtering and quoting parameters. We modified the script to use the cwd option and avoid filtering the parameter entirely:

var cmd = 'git rev-parse HEAD'
exec(cmd, { env: { GIT_CONFIG: gitDir } } ...)

Mozilla does not run servers from insecure paths, but some users host their own FxA services and it is always good to consider malicious input from all sources.

 

We reviewed the higher ranked issues from the report, circumstances limiting their impact, and how we fixed and addressed them. We invite you to contribute to developing Firefox Accounts and report security issues through our bug bounty program as we continue to improve the security of Firefox Accounts and other core services.

Analysis of the Alexa Top 1M sites

Prior to the release of the Mozilla Observatory a year ago, I ran a scan of the Alexa Top 1M websites. Despite being available for years, the usage rates of modern defensive security technologies was frustratingly low. A lack of tooling combined with poor and scattered documentation had led to there being little awareness around countermeasures such as Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), and Subresource Integrity (SRI).

A few months after the Observatory’s release — and 1.5M Observatory scans later — I reassessed the Top 1M websites. The situation appeared as if it was beginning to improve, with the use of HSTS and CSP up by approximately 50%. But were those improvements simply low-hanging fruit, or has the situation continued to improve over the following months?

Technology April 2016 October 2016 June 2017 % Change
Content Security Policy (CSP) .005%1
.012%2
.008%1
.021%2
.018%1
.043%2
+125%
Cookies (Secure/HttpOnly)3 3.76% 4.88% 6.50% +33%
Cross-origin Resource Sharing (CORS)4 93.78% 96.21% 96.55% +.4%
HTTPS 29.64% 33.57% 45.80% +36%
HTTP → HTTPS Redirection 5.06%5
8.91%6
7.94%5
13.29%6
14.38%5
22.88%6
+57%
Public Key Pinning (HPKP) 0.43% 0.50% 0.71% +42%
 — HPKP Preloaded7 0.41% 0.47% 0.43% -9%
Strict Transport Security (HSTS)8 1.75% 2.59% 4.37% +69%
 — HSTS Preloaded7 .158% .231% .337% +46%
Subresource Integrity (SRI) 0.015%9 0.052%10 0.113%10 +117%
X-Content-Type-Options (XCTO) 6.19% 7.22% 9.41% +30%
X-Frame-Options (XFO)11 6.83% 8.78% 10.98% +25%
X-XSS-Protection (XXSSP)12 5.03% 6.33% 8.12% +28%

The pace of improvement across the web appears to be continuing at an astounding rate. Although a 36% increase in the number of sites that support HTTPS might seem small, the absolute numbers are quite large — it represents over 119,000 websites.

Not only that, but 93,000 of those websites have chosen to be HTTPS by default, with 18,000 of them forbidding any HTTP access at all through the use of HTTP Strict Transport Security.

The sharp jump in the rate of Content Security Policy (CSP) usage is similarly surprising. It can be difficult to implement for a new website, and often requires extensive rearchitecting to retrofit to an existing site, as most of the Alexa Top 1M sites are. Between increasingly improving documentation, advances in CSP3 such as ‘strict-dynamic’, and CSP policy generators such as the Mozilla Laboratory, it appears that we might be turning a corner on CSP usage around the web.

Observatory Grading

Despite this progress, the vast majority of large websites around the web continue to not use Content Security Policy and Subresource Integrity. As these technologies — when properly used — can nearly eliminate huge classes of attacks against sites and their users, they are given a significant amount of weight in Observatory scans.

As a result of their low usage rates amongst established websites, they typically receive failing grades from the Observatory. Nevertheless, I continue to see improvements across the board:

Grade April 2016 October 2016 June 2017 % Change
 A+ .003% .008% .013% +62%
A .006% .012% .029% +142%
B .202% .347% .622% +79%
C .321% .727% 1.38% +90%
D 1.87% 2.82% 4.51% +60%
F 97.60% 96.09% 93.45% -2.8%

As 969,924 scans were successfully completed in the last survey, a decrease in failing grades by 2.8% implies that over 27,000 of the largest sites in the world have improved from a failing grade in the last eight months alone.

In fact, my research indicates that over 50,000 websites around the web have directly used the Mozilla Observatory to improve their grades, indicated by scanning their website, making an improvement, and then scanning their website again. Of these 50,000 websites, over 2,500 have improved all the way from a failing grade to an A or A+ grade.

When I first built the Observatory a year ago at Mozilla, I had never imagined that it would see such widespread use. 3.8M scans across 1.55M unique domains later, it seems to have made a significant difference across the internet. I feel incredibly lucky to work at a company like Mozilla that has provided me with a unique opportunity to work on a tool designed solely to make internet a better place.

Please share the Mozilla Observatory and the Web Security Guidelines so that the web can continue to see improvements over the years to come!

 

Footnotes:

  1. Allows 'unsafe-inline' in neither script-src nor style-src
  2. Allows 'unsafe-inline' in style-src only
  3. Amongst sites that set cookies
  4. Disallows foreign origins from reading the domain’s contents within user’s context
  5. Redirects from HTTP to HTTPS on the same domain, which allows HSTS to be set
  6. Redirects from HTTP to HTTPS, regardless of the final domain
  7. As listed in the Chromium preload list
  8. max-age set to at least six months
  9. Percentage is of sites that load scripts from a foreign origin
  10. Percentage is of sites that load scripts
  11. CSP frame-ancestors directive is allowed in lieu of an XFO header
  12. Strong CSP policy forbidding 'unsafe-inline' is allowed in lieu of an XXSSP header

Relaunching Mozilla’s Web Security Bounty Program

Today we are announcing the relaunch of our web security bug bounty program, creating greater transparency into how we handle web security bug bounty payouts.

History

Bug bounty programs started a number of years ago with Netscape leading the way. In August of 2004, Mozilla joined in by launching our first bug bounty program. Funded by Linspire, Inc. and Mark Shuttleworth, it paid out $500 for critical security vulnerabilities found in Firefox and other Mozilla software. Although this may seem quaint in comparison to modern day bug bounties that can reach well into the six figures, at the time it was considered a revolutionary advance in how technology companies deal with the discovery of security flaws.

Six years later, in December of 2010, Mozilla was one of the first companies to add bugs found in their web properties to their bounty programs. Ranging from $500 up to $3000, it was another leap forward, this time focused on improving the state of web security.

From our first awarded web bounty bug (a cross-site scripting vulnerability in addons.mozilla.org) to now, we have paid out hundreds of thousands of dollars to researchers around the world who have lent their expertise to help us protect our users.

Challenges and Solutions

Bug bounty programs are always challenging to administer, especially for a company like Mozilla. We have staff and contributors that have lived and breathed the web for almost 20 years and our portfolio of websites has grown exponentially. From www.mozilla.org, to www.bugzilla.org to arewefastyet.com some of these sites create significantly more risk to Mozilla’s operations than others.

Problems have arisen with communicating this risk spectrum to bounty hunters. A hypothetical SQL injection on Bugzilla presents a different level of risk to Mozilla than a cross-site scripting attack on the Observatory or an open redirect on a community blog. To a bounty hunter, the level of risk is often irrelevant — they simply want to know if a class of bug on a specific site will pay out a bounty and how much it will pay out.

Overall, we think we have done a reasonable job listing the Mozilla websites that pay out bounties, but the actual payout amounts have varied. In addition, payouts have become more complicated for bugs discovered on sites that are not explicitly part of the program.

If a payout comes in at a level that meets or exceeds what the researcher was expecting, then everything is great. But if it comes in lower than expectations, a bounty hunter may be disappointed. Furthermore, making a payout exception for a given site creates an expectation that additional exceptions will be made.

Today

We are excited to relaunch our web based bounty program in a way that will address many of these historical issues while also expanding the number of websites and bug classes that are covered. In addition, we are explicitly listing how much each bug class will pay out and for what websites, based on their risk profile.


[see the whole table here]

Having a clear and straightforward table of payouts allows bounty hunters to devote their time and effort to discovering bugs that they know will receive a payout. The hunters will also know the exact amount of the payouts.  We’re also expanding the classes of bugs that qualify for our bug bounty Hall of Fame. Although these bugs don’t come with a monetary payout, it’s our way of publicly acknowledging the work of bounty hunters in making the web a safer place.

From our logos to our products, Mozilla is a company that prides itself on its openness. Although being open about payouts is generally unexplored territory, we hope that it helps contribute to greater openness in bug bounty programs around the web.

If you are an existing contributor to our web bug bounty program, we hope this structure helps focus your efforts. If you are just starting out, we look forward to working with you to help make the internet more secure!

Mozilla Releases Version 2.4 of CA Certificate Policy

Mozilla has released version 2.4.1 of Mozilla’s CA Certificate Policy and sent a CA Communication to inform Certification Authorities (CAs) who have root certificates included in Mozilla’s program about new program requirements. Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies and open-source projects in a variety of applications.

The changes of note in Mozilla’s CA Certificate Policy are as follows:

  • In addition to audit statements, the CP and CPS documents need to be submitted to Mozilla each year.
  • As of June 1, 2017, the audit, CP, and CPS documents must be provided in English, translated if necessary.
  • All submitted documentation must be openly licensed (see the policy for the exact options and terms).
  • Version 2.4 of Mozilla’s CA Certificate Policy incorporates by reference the Common CCADB Policy and the Mozilla CCADB Policy.
  • The new Common CA Database (CCADB) Policy makes official a number of existing expectations regarding the CCADB.
  • The applicable versions of some audit criteria have been updated.
  • There are additional requirements on OCSP responses.
  • 64 bits of entropy is required in certificate serial numbers.

The differences in Mozilla’s CA Certificate Policy between versions 2.4 and 2.3 (published December 2016), and between versions 2.4 and 2.2 (published July 2013) may be viewed on Github. Version 2.4.1 contains exactly the same normative requirements as version 2.4 but has been completely reorganized.

The CA Communication has been emailed to the Primary Point of Contact (POC) for each CA in Mozilla’s program, and they have been asked to respond to 14 action items. The full set of action items can be read here. Responses to the survey will be automatically and immediately published via the Common CA Database.

In addition to responding to the action items, we are informing CAs that we are instituting a program requirement that they follow discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla’s CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum’s Baseline Requirements or other program requirements. CAs are not required to contribute to those discussions, only to be aware of them. However, we hope CAs will participate and help shape the future of Mozilla’s CA Certificate Program.

With this CA Communication, we re-iterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve.

Mozilla Security Team

The end of SHA-1 on the Public Web

Our deprecation plan for the SHA-1 algorithm in the public Web, first announced in 2015, is drawing to a close. Today a team of researchers from CWI Amsterdam and Google revealed the first practical collision for SHA-1, affirming the insecurity of the algorithm and reinforcing our judgment that it must be retired from security use on the Web.

As announced last fall, we’ve been disabling SHA-1 for increasing numbers of Firefox users since the release of Firefox 51 using a gradual phase-in technique. Tomorrow, this deprecation policy will reach all Firefox users. It is enabled by default in Firefox 52.

Phasing out SHA-1 in Firefox will affect people accessing websites that have not yet migrated to SHA-2 certificates, well under 0.1% of Web traffic. In parallel to phasing out insecure cryptography from Firefox, we will continue our outreach efforts to help website operators use modern and secure HTTPS.

Users should always make sure to update to the latest version of Firefox for the most-recent security updates and features by going to https://www.mozilla.org/firefox.

Questions about Mozilla policies related to SHA-1 based certificates should be directed to the mozilla.dev.security.policy forum.

Mozilla Security Bytes, ep. 1: Content Security Policy

Sharing the work we do around web and information security is an important role of Mozilla Security. We often get questions on specific security technologies, both from our engineers who work on Mozilla products and services, and from the community interested in using these technologies in their own environments.

Today, we introduce a new podcast, called Mozilla Security Bytes, mozilla_security_byteswhere we discuss these security technologies in details.

In this first episode, we talk about Content Security Policy, or CSP, with Christoph Kerschbaumer, Frederik Braun and Dylan Hardison. We cover both the history and future of CSP, and various issues we have learned while implementing it on our own sites and services.

We hope you find the discussion interesting, and feel free to share your feedback with us at security-bytes@mozilla.com.

Download link, Podcast subscription URL

 Links mentioned in the episode

Setting a Baseline for Web Security Controls

Securing modern web applications effectively is a complex process. However there are many straightforward security controls such as HTTP security headers which are very effective at blocking web common attacks.

At Mozilla we provide Security Guidelines as well as a Checklist of security controls for the developers of Firefox Services. Last year, we introduced the Mozilla Observatory, a hosted scanner to evaluate the security of websites and services. In this blog post, we present the ZAP Baseline scan designed to test the security controls of web applications in Continuous Integration and Continuous Deployment (CI/CD).

Verifying that the correct controls are in place across all of our applications can be challenging, especially in a CI/CD environment. We run full vulnerability scans against our services on a regular basis, but these can take a long time to run and are not really adapted to fast release cycles.

This is why we have introduced a ‘baseline’ scan which runs very quickly and on every release of a service, but still gives us crucial feedback about the key security controls that we are concerned about. The baseline scans are included in the CI/CD pipelines of Firefox services to inform developers of potential issues before they reach production environments. We also run it against all of those services every day to generate a dashboard of the overall security status of our services.

This blog post presents the techniques we use to implement baseline scans in our infrastructure.

The ZAP Baseline Scan

Mozilla invests heavily in the development and support of security tools. The author of this blog post leads the OWASP Zed Attack Proxy (ZAP) project,  which we use to run baseline and vulnerability scans.

The ZAP baseline scan is a quick, easy and highly configurable way to test the security controls you care about. The tests are non intrusive so they are safe to run against production applications.
You don’t need to have ZAP installed – the zap-baseline.py script uses Docker and is included in the 2 ZAP Docker images:

For our baseline scans we use the weekly docker image which has more options available – you can run the script with the -h flag to see all of them.

The script zap-baseline.py uses the ZAP spider to explore the application, by default for just one minute. Spidering the application is important to verify that all pages, and not only the top one, implement the required security controls. This is particularly useful when web frameworks will handle some of the pages automatically without setting the headers.
The script will then report all of the potential issues found.

The baseline scan can be run against an application by just specifying its URL using the -t flag:

docker run owasp/zap2docker-weekly zap-baseline.py -t https://www.example.com

This will produce output like: 

Total of 3 URLs
PASS: Cookie No HttpOnly Flag [10010]
PASS: Cookie Without Secure Flag [10011]
PASS: Password Autocomplete in Browser [10012]
PASS: Cross-Domain JavaScript Source File Inclusion [10017]
PASS: Content-Type Header Missing [10019]
PASS: Information Disclosure - Debug Error Messages [10023]
PASS: Information Disclosure - Sensitive Informations in URL [10024]
PASS: Information Disclosure - Sensitive Information in HTTP Referrer Header [10025]
PASS: HTTP Parameter Override [10026]
PASS: Information Disclosure - Suspicious Comments [10027]
PASS: Viewstate Scanner [10032]
PASS: Secure Pages Include Mixed Content [10040]
PASS: Weak Authentication Method [10105]
PASS: Absence of Anti-CSRF Tokens [10202]
PASS: Private IP Disclosure [2]
PASS: Session ID in URL Rewrite [3]
PASS: Script Passive Scan Rules [50001]
PASS: Insecure JSF ViewState [90001]
PASS: Charset Mismatch [90011]
PASS: Application Error Disclosure [90022]
PASS: WSDL File Passive Scanner [90030]
PASS: Loosely Scoped Cookie [90033]
WARN: Incomplete or No Cache-control and Pragma HTTP Header Set [10015] x 1
    https://www.example.com
WARN: Web Browser XSS Protection Not Enabled [10016] x 3
    https://www.example.com
    https://www.example.com/robots.txt
    https://www.example.com/sitemap.xml
WARN: X-Frame-Options Header Not Set [10020] x 1
    https://www.example.com
WARN: X-Content-Type-Options Header Missing [10021] x 1
    https://www.example.com
FAIL-NEW: 0    FAIL-INPROG: 0    WARN-NEW: 4    WARN-INPROG: 0    INFO: 0    IGNORE: 0    PASS: 22

By default the output lists all of the passive scan rules applied and whether they passed or failed.

You can change how the baseline handles different errors by specifying a rule configuration file via either the -c flag (for a local file) or the -u flag for a remote URL.
You can also generate a default file using the ‘g’ option: https://github.com/zaproxy/community-scripts/blob/master/api/mass-baseline/mass-baseline-default.conf
As specified in the generated file header you can change any of the “WARN”s to “IGNORE” or “FAIL”.

The script will exit with a 0 if there are no issues, 1 if there are any failures or 2 if there are just warnings. The return value can therefore be used in CI tools like Jenkins, CircleCI, TravisCI, etc. to fail a build step.

For example, the configuration below shows how the baseline scan can run in CircleCI with every pull request:

test:
  override:
    # build and run an application container
    - docker build -t myrepo/myapp
    - docker run myrepo/myapp &
    # retrieve the ZAP container
    - docker pull owasp/zap2docker-weekly
    # run the baseline scan against the application
    - |
      docker run -t owasp/zap2docker-weekly zap-baseline.py \
      -t http://172.17.0.2:8080/ -m 3 -i

Scanning Multiple Sites

The baseline scan is a great way to check that a single site meets your base security requirements.

In order to run the ZAP Baseline scan against a large number of websites, we have written a set of wrapper scripts specific to Mozilla. You can find  generic versions of these scripts in the ZAP community-scripts repository.

You will need to customize these scripts as detailed in the README:

  • Change the sites listed in mass-baseline.sh
  • Change the relevant user and repo details in mass-baseline.sh
  • Build a docker image
  • Run the docker image, setting the credentials for your user

These scripts will then generate a summary dashboard in your repo wiki:

Baseline-summary
The ‘Status’ badge is a link to a page containing the latest baseline results for the relevant application and the ‘History’ date links to a page which show all of the previous scans.
Example pages are included on the community scripts wiki: https://github.com/zaproxy/community-scripts/wiki/Baseline-Summary

Tuning

The baseline scan is highly configurable and allows you to fine tune the scanning to handle your applications more effectively.
You can do things like:

  • Increase the time spent spidering your application
  • Use the Ajax Spider in addition to the standard ZAP spider to handle applications that make heavy use of JavaScript
  • Include alpha passive scan rules as well as the beta and release quality ones used by default
  • Ignore specific URLs or even ignore specific issues on those pages
  • Link known issues to a bugtracker URL
  • Specify any of the options supported on the ZAP command line

For more details see the ZAP wiki: https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan

Conclusion

The baseline scan gives us immediate feedback about the security controls in place across all of our web applications. The scans run on every commit so that we are immediately aware if there has been any regression. The dashboard allows us to track the state of our applications and the CI integration provides the ability to block a deployment if the baseline is not met.

Integrating baseline scanning in CI/CD helps us work more closely with developers and operators. We don’t force our security tools onto DevOps processes, we integrate security into DevOps. The net effect is better collaboration between teams, and faster turnaround on fixing security issues.