mozilla/http-observatory-website

Mozilla Observatory (Website)

Mozilla Observatory :: Website

The Mozilla Observatory is a set of tools to analyze your website and inform you if you are utilizing the many available methods to secure it.

It is split into three projects:

• http-observatory - scanner/grader
• http-observatory-cli - command line interface
• http-observatory-website - web interface

TLS evaluation relies on external scanners, such as Mozilla's TLS Observatory.

Installation

If you just want to use a local version of the website, you can simply clone the dist directory:

$ git clone -b gh-pages https://github.com/mozilla/http-observatory-website.git

However, it comes with a built-in web server that will automatically regenerate the SRI hashes:

$ npm install
$ npm run watch

Note that this will still use the global Mozilla Observatory API endpoints; you will need to change httpobs.js and httpobs-third-party.js if you wish to use your own local endpoints.

Authors

• April King

License

• Mozilla Public License Version 2.0

http-observatory-website's Issues

Add tick/cross marks in DOM

At the moment you are using:

.glyphicon-ok:before {
    content: "\e013"
}

I'm wondering if it would be better for the JavaScript to set that value in the DOM, rather than relying on the CSS and Icon Fonts to provide the content.

I know it's being a bit picky, but some users (e.g. using a screen reader with IE11) might have difficulty with this:

http://tink.uk/accessibility-support-for-css-generated-content/

https://speakerdeck.com/ninjanails/death-to-icon-fonts

$('#tests-cross-origin-resource-sharing-pass').text('✓');

Add favicons

Someone who's good with designing should make a logo we can use to generate the various favicons.

X-XSS Protection refers to cross-site-scripting as "CSS"

The tooltip next to the X-XSS-Protection result on the Test Results refers to cross-site scripting as CSS. This should probably be XSS since it is used that way in other places on the site.

X-XSS-Protection protects against reflected cross-site scripting (CSS) attacks in IE and Chrome, but has been superseded by Content Security Policy. It can still be used to protect users of older web browsers.

securityheaders.io third party scan fails without HTTP

When you ask to scan "https://example.com", it scan "example.com" with securityheaders.io, and securityheaders.io failed because there is no http. (But if you scan "https://example.com" with securityheaders.io it works)

obsovatory says "Content Security Policy (CSP) header not implemented", but it is provided

CSP is correctly accepted and parsed by browsers (e.g. Chrome), but the web-tool says that it is no implemented. Also the X-XSS protection is not accepted. Can it be that there is a problem with the request header parser in observatory? Here are the headers as seen from a browser.

Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 5945
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' cdn.ckeditor.com code.jquery.com ajax.googleapis.com; img-src 'self' cdn.ckeditor.com ipv6-test.com; style-src 'self' 'unsafe-inline' cdn.ckeditor.com;
Content-Type: text/html; charset=utf-8
Date: Mon, 05 Sep 2016 09:06:59 GMT
Expires: Mon, 05 Sep 2016 09:06:59 GMT
Pragma: no-cache
Server: NaviServer/4.99.12
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

The website is openacs.org (the CSP will be made much less liberal in the near future).

Error: AttributeError("'module' object has no attribute 'JSONDecodeError'",)

Was scanning my site and got this error message:
Error: AttributeError("'module' object has no attribute 'JSONDecodeError'",)

Avoid leaking information about hidden scans

The API should avoid leaking information about scans marked as hidden.

Currently simply iterating over certain objects reveals information that basically contain the originally requested domain. No proper access restriction (like including the domain for which that test object is valid) is present.

Configuration bug?

I got to the site via the URL: https://mozilla.github.io/http-observatory-website/

but when I try to submit a domain I end up with a github-served 404 (I was trying to get a scan for thimble.mozilla.org)

Redirect to production site

Add a banner to the top of:

https://mozilla.github.io/http-observatory-website/

That redirects people to the production site. This is just the beta site, after all.

Pass cross or tick

Up for debate, but if a website hasn't implemented SRI, HPKP, etc... while I don't think they should be penalised, I don't think they should get a tick either... maybe a dash?

Might also be nice to reinforce the tick or cross with a bit of colour (makes it easier for the eye to scan).

https://github.com/mozilla/http-observatory-website/blob/master/dist/js/httpobs-1.0.0.js#L136

NIST / PCI-DSS compliance integration

https://www.htbridge.com/ssl/ provides a public API and detailed compatibility with NIST Special Publication 800-52 Revision 1 - Section 3 and PCI DSS 3.2 - Requirements 2.3 and 4.1 (+ some best-practices as bonus).

I might be useful to integrate those metrics and perhaps subtly remind the users that, as of today, complying with NIST recommendations doesn't necessarily mean "being secure".

sort hall of fame/shame by alexa rank

The popularity of a website is an important criteria in the risk calculation. It would make the hall of fame/shame more meaningful if popular websites were listed at the top.

inconsistent handling of "can't check" tests

I have an HTTP only site with only a very simple static page at the root. (dtor [dot] com) Of course, this means a guaranteed 'F', which is fine, but the analysis phrases results of things which can not be tested differently.

The TLS checks are marked as "failed" (agreed), but the sub-resource integrity is marked as 'passed', simply because my root page doesn't have a script tag.

I'm not sure what the "best" solution is here - but the inconsistency did make me have to rescan the results several times to make sure I understood what was being communicated. Maybe a 3rd icon for "can't test" - negative score still allowed?

It detects my page as weak but there is no attack surface

the page is static (no dynamic content) so there is no XSS or any issue related to frames possible - even without the headers.
However this is hard to detect so you may close this issue if you like.

Erroneous (?) "Site down" message

I have a web site at: https://www.goldenhillsoftware.com/

When I enter "goldenhillsoftware.com" and click "Scan Me", I get "Error: Site down".

Take dnssec into account

If the domain is highjacked taken over the rest doesn't really matter does it ?

Unsupported ciphers?

I've got a very small set of ciphers that I allow:
https://www.ssllabs.com/ssltest/analyze.html?d=seegras.discordia.ch&s=2a05%3afc84%3ac%3a0%3a0%3a0%3a0%3a8&latest

Now the observatory thinks the site is not available via TLS. Either you don't support any of these ciphers, or there is an issue with IPv6 (since it uses an IPv6-Address on its own) or SNI (needs SNI for IPv4).

Add a "request rescan" button to the individual results page

STR:

1. Visit eg https://mozilla.github.io/http-observatory-website/analyze.html?host=treeherder.mozilla.org from a link in a bug/email
2. Make some changes to improve the score
3. Revisit that URL to see updated score

Expected:
Obvious way to request a rescan from that page.

Actual:
No way to rescan from there, I have to return to the homepage (https://mozilla.github.io/http-observatory-website/), enter the domain name again and choose "Force a rescan".

Fails to Detect HTTPS Redirect

In testing my own website, joshvickerson.com, Observatory indicates that my site doesn't support https. However, the site is configured to require https. If you visit in a browser, you will be redirected to https://www.joshvickerson.com every time.

Edit: This occurs when I simply enter joshvickerson.com as the domain. If I enter www.joshvickerson.com as the domain, it does detect HTTPS support. Is this an issue with Observatory, my configuration, or both?

All ESLint support

Should help keep the codebase clean and consistent.

A % column in the overall results

on the main page.

Makes it very easy to read and have a "status" of the internet.

Letter grades should be clickable

On the home page, it would be nice if the user could click the letter grades (or the corresponding numbers) and see a list of sites with that grade.

Observatory wants 26 weeks for HSTS headers, preload list only needs 18

This is more a question on the ratings, rather than the site itself - the test for yell.com (https://observatory.mozilla.org/analyze.html?host=yell.com) got a -10 on its HSTS for "HTTP Strict Transport Security (HSTS) header set to less than six months (15768000)"

I've got it set to 18 weeks, not 26 as the HSTS preload submission site only needs the header set to 18 weeks in order to meet their requirements.

In general, longer is better, but I'd have thought 18 weeks is enough time for a header like that.

Can you explain why 26 weeks, not 18 weeks?

no direction for deploying the website

would love to see directions for deploying the website.. is there a plan to produce this?

Need margins on phone-size page

When you set the window width to be small enough for the CSS to flip into phone mode, the left and right margins go away, so the blue boxes go all the way to the edges. We should have some margin there.

HSTS preload for subdomains

Submitting a subdomain to the preload list is actually not possible and the HSTS header must contain includeSubDomains in order to be included in the preloading list. However, one might still use www.example.com instead of example.com for the website for cookie security. The thing is that the when one submits www.example.com to the Observatory it will forward the domain name as is to the HSTS app and report that it is not being preloaded although it might be if only the hostname with TLD would be forwarded.

Extracting the hostname with TLD from the given domain name is trivial with the public suffix list and should cover 99% of all cases and results in proper preloading reports.

Sites using Un-trusted certificates return "site down" error.

When you attempt to scan a site using an un-trusted SSL certificate, the scanner returns "Error: Site down".

I'm not sure if the intention is to fail if the certificate is un-trusted, if it is, I think a more accurate error message would be helpful.

Examples:

https://superfish.badssl.com/

https://spi.dod.mil/

Site needs a lot of work to look good on mobile devices

Much thanks to @XhmikosR for his work on #46, which greatly improved the front page.

The results page is a lot more complicated though, and needs a lot of work. If there's a designer out there that is great at this stuff, I'd really appreciate the help.

mobile home page layout is messed up

Just cross posting this from webcompat/web-bugs#3076 as I realized I can contribute directly to the project

URL: https://observatory.mozilla.org/
Browser / Version: Firefox Mobile 51.0

Steps to Reproduce

1. Navigate to: https://observatory.mozilla.org/
2. Pan around the page/ Observe the buttom button/footer

Actual Behavior:

From webcompat.com with ❤️

"Home" link goes to mozilla.github.io

Should go to https://mozilla.github.io/http-observatory-website

Enforce LF for the repo

On Windows I end up with different hashes due to line endings being different.

So using LF will make the behavior consistent.

redeploy observatory.mozilla.org using IPv6-enabled AWS ALBs

Although the scanners now work with IPv6:

mozilla/http-observatory#91

The Observatory website itself is not accessible via IPv6. Although less of an issue -- almost every user has an IPv4 gateway -- it still blocks IPv6 only users.

This is blocked on the fact that AWS's ELBs don't support IPv6. Once they add support for IPv6 to ALBs, we can hopefully cut the website over to IPv6.

Creating this issue now to track it, even though it can't currently be fixed.

Move Google Font to the HTML

Currently, due to the way Bootswatch themes ship, it's included via an @import which doesn't allow the browser to start fetching the Google font until it has fetched the CSS.

Or even better, get rid of it and use system fonts :)

Weak symmetric ciphers not reported as such

In light of Sweet32, some ciphers like DES, 3DES, RC4 and IDEA should be marked as weak. Essentially all ciphers with a block size smaller than 128 bit (16 Bytes). For RC2 and RC4 see RFC 7465.

test results mix test scope of aplicability

There are two scopes for the findings being presented: "host based" and "page based" (cookies, subresource, etc.). The host scope would hold for every page within the site, but the page scope does not. Yet the 2 scopes are commingled in the "Test Scores" section.

I'd suggest grouping the test results by scope (host first). And include some sort of disclaimer on the page scope section that it only applies to the default page at the root of the site. Other pages on the site could have a different grade.

HSTS preload call is case-sensitive

Consider https://hstspreload.appspot.com/?domain=example.com is part of the HSTS preload list.

Trying https://hstspreload.appspot.com/?domain=Example.com (uppercase "e") will return Initial redirect is to an insecure page.

Note: According to my tests, https://hstspreload.appspot.com seems to always convert addresses to lowercase.

Rename /HTTP Observatory/

This is not really in the present state an HTTP observatory, but more a useful tool to test HTTPS.

I would be in favor of renaming it

s/HTTP Observatory/HTTPS Observatory/

And probably with a subline giving the scope on security.

PageSpeed is a lot closer of what is an HTTP observatory
https://developers.google.com/speed/pagespeed/

Redbot.org is also good at giving advice on the sanity of HTTP headers.
https://redbot.org/

Scans that return "site down" should force rescans on the next scan

I always get an error "Site down" and see no access at all in the nginx logs.
Website is configured on 80/443 as http and https so it should reply to any request. But none is coming to the server it seems.
Is that a matter of using a newer TLD? If s/o please could try for https://vocab.guru/ ?

CSP header parsing error with multiline definition

Snippet from Apache config follows.

Header always set Content-Security-Policy
"
default-src 'self';
style-src 'self'
'unsafe-inline'
'sha256-e7cmLP/1kNNvlmAL6WpxAbxYm11otS+g2JqtWfJjyJ4='
'sha256-jE00AJAJfF4e5zCe/WZdF7CzTFqwV0hYFN1ICf2NT88='
'sha256-0+eUWXEzIzayXtwbs4qgGqcUroB222vieZ1QP7fQ6so='
'sha256-H+MZMHAjxtX51BD5NQvR2VBEYdZkra7aCuCgN0suCfk='
'sha256-S7jkx8JtJicm/79wzDgSPAz8c2i1ns8O8hI/DpuWN88=';
script-src 'self' 'unsafe-inline' https://cdn.ampproject.org/v0.js https://cdn.ampproject.org/v0/validator.js;
upgrade-insecure-requests;
base-uri 'none';
frame-ancestors 'none';
sandbox allow-same-origin allow-scripts;
"

For ECDSA certs, include RSA equivalent size

Instead of saying 384-bits, add something like (equiv. RSA 7000000), or whatever it is.

Error when domain exists but no site

If the domain is registered but no website exists the message is "Error: name.example is an invalid hostname". I tried this on one with just mx records. This is technically correct. I thought it said "invalid domain" yesterday which wasn't right.

I read the error as implying the name isn't correct - it is registered and in use, just not for web access.

This might be beyond the intended scope - reporting dns sanity checks would be useful. There's other tools that do that though. You could deep link the searched domain as a "check on xxx" or roll your own. See http://www.dnsstuff.com/tools#dnsReport%7Ctype=domain&&value=NAME.EXAMPLE or http://mxtoolbox.com/SuperTool.aspx?action=a%3aNAME.EXAMPLE&run=toolpage#

Cipher list should display numeric cipher IDs

To make validation of results comparable across the various namespaces of ciphers used, the table listing the ciphers should indicate the unique low-level cipher id (2/3 bytes) as that ID can be looked up and referred to the cipher meant by it.

Server are reported as down, but it is alive.

There test server are reported as down, but it is alive.
Other site's can scan it without any problems.
How does the detection algorithms work?

CSP as HTML-Meta-Tag not recognized

Having the CSP-Header in a HTML-Meta tag seems not to be recognized, although it is stated here as an implemenation example: https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy

See here: https://observatory.mozilla.org/analyze.html?host=dotbox.org

Access-Control-Allow-Origin: null ---> -50 ???

The string "null" is perfectly legal, and in fact advisable if you are a hosting domains and want to
enforce the protection above local overrides.

Ref. http://www.w3.org/TR/access-control/#access-control-allow-origin-response-header
In practice the origin-list-or-null production is more constrained. Rather than allowing a space-separated list of origins, it is either a single origin or the string "null".

Website tells me that CSP has 'unsafe-inline' inside style-src, but it doesn't

My CSP: Content-Security-Policy: default-src 'none'; script-src 'self' https://some-url; object-src 'none'; style-src 'self' data:; img-src 'self' data: https://some-url; media-src 'self'; frame-src 'none'; font-src 'self'; connect-src 'self'

The test reports Content Security Policy (CSP) implemented with 'unsafe-inline' inside style-src

Evaluate refreshing some cached third-party results after time passes

Consider https://tls.imirhil.fr/ (awesome job @aeris !)
A given domain can be tested only once every hour and the result (https://tls.imirhil.fr/https/example.com.json) is cached until the domain is checked again.

So even though a user hits "Initiate rescan", the tool doesn't call imirhil's refresh API to reset the scan (i.e. https://tls.imirhil.fr/https/example.com/refresh), thus returning potentially inconsistent results.

Suggestion:

• Case 1: No data cached -> Return the result + current timestamp
• Case 2: Data in cache && Tcurrent - Ttest < 1h: Return cached data + cache timestamp
• Case 3: Data in cache && Tcurrent - Ttest >= 1h: Reset data and goto case 1.

tl;dr: Always try to refresh the cache :)

Better document how the redirect test works

The observatory reports for some redirects:

[ -5] Initial redirection from http to https is to a different host, preventing HSTS

It has come up that describing how this should be properly done may best be made part of the FAQ.

-10 for not having a contribute.json?

From the website: The Mozilla Observatory is a project designed to help developers, system administrators, and security professionals configure their sites safely and securely.

The docs say contribute.json is a Mozilla standard used to describe all active Mozilla websites and projects. – Why do I need to have a contribute.json if I do not host a Mozilla website? 😉

"Cookies set without using the Secure flag, but transmission over HTTP prevented by HSTS"

https://observatory.mozilla.org/analyze.html?host=ulabox.com

Both "ULBXSESS" and "ulabox" cookies are are sent with the "secure" flag (as can be seen in the "Raw Server Headers" section) so I'm not really sure what might be going on here.

Thanks!