Right now the CDP sends a redirect event but it is not very complete. I'm thinking it should be something like:

{
  "source": "string", // The original url that initiated the request
  "hops": ["string"] // All the hops we've done so far 
}

We could also add the hops property to the fetch::end and targetfetch::end events and not trigger another event. What do you think @alrra ?

• Check if the header Strict-Transport-Security is sent for resources served over HTTPS.
• Check if the max-age value is small (less than 10886400 seconds should be an error, no configuration possible).

Also inform users about https://hstspreload.org/? However, make it clear that:

• the preload list cannot easily be undone (domains can be removed, but it takes months for a change to reach users, basically until those users upgrade to a new version of the browser)
• they should only do this if they are sure that they can support HTTPS for their entire site and all its subdomains in the long run.

See also:

• https://tools.ietf.org/html/rfc6797
• https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

• Check if the if the meta tag is not included completely within the first 1024 bytes of the document - done by the markdown validator (see: #28)

• Check if meta tag is not specified as early as possible (before any content that could be controlled by an attacker, such as a <title> element) so to avoid a potential encoding-related security issue in Internet Explorer (Note: this was only an issue with IE6?).

• Check if non-utf-8 encodings are used

• Check if things like utf8 are used (even though this is valid nowadays as the specifications and browsers alias utf8 to utf-8, that wasn't the case in the past).

• Check if the short version is used (i.e.: <meta http-equiv="Content-Type" content="text/html;charset=UTF-8"> => <meta charset="utf-8"> ).

• Other?

gzip

1. Check is something is served compressed using gzip:

   Make a request with the Accept-Encoding: "gzip" header, then verify if the response is served with the Content-Encoding: "gzip" header and the body of the response starts with 1f 8b.

2. What should be compressed with gzip:

   File type	Commonly used file extension(s)	Commonly used media types(s)
   Atom	.atom	application/atom+xml
   App Cache Manifest	.appcache	text/cache-manifest
   BMP	.bmp	image/bmp
   CSS	.css	text/css
   Cursors Images	.cur	image/x-icon image/vnd.microsoft.icon
   Embedded OpenType font	.eot	application/vnd.ms-fontobject
   Favicon	.ico	image/x-icon image/vnd.microsoft.icon
   HTML	.html .htm ...	text/html application/xhtml+xml
   HTML Components	.htc	text/x-component
   JavaScript	.js	application/javascript text/javascript
   JSON	.json ...	application/json application/<something>+json
   OpenType font	.otf	font/opentype
   RDF	.rdf	application/rdf+xml
   RSS	.rss	application/rss+xml
   Source Maps	.map	application/json
   SVG	.svg	image/svg+xml
   TrueType font	.ttc .ttf	application/x-font-ttf
   TXT	.txt	text/plain
   vCard	.vcard vcf	text/vcard
   VTT	.vtt	text/vtt
   XML	.xml ...	application/xml text/xml application/<something>+xml
   Web App Manifest	.webmanifest .json	application/manifest+json

   Notes:

   • Under 1K things should not necessarily be compressed.
   • WOFF fonts should not be compressed (see: h5bp/server-configs-apache#42).
   • SVGZ should be served with the Accept-Encoding: "gzip" header as they are compressed by default.

Zopfli

1. Check is something is served compressed using Zopfli:

   Same as with gzip, just that we need to detect Zopfli.

2. What should be compressed with Zopfli:

   Same as with gzip.

   Note(s):

   • We will need to a check if WOFF fonts use Zopfli compression internally.

Brotli

1. Check is something is served compressed using Brotli.

   Make a request with the Accept-Encoding: "br" header, then verify if the response is served with the Content-Encoding: "br" header (no magic numbers?).

   Note: Brotli compressed responses should be served only over HTTPS.

2. What should be compressed with Brotli:

   Same as with gzip.

Note: This is just a starting point, we will probably split this into more specific issues / rules.

TODO: Look into how the Nu HTML Checker can be integrated.

• Check if HTML documents use any NPAPI-based plugins.

See also:

• https://blogs.windows.com/msedgedev/2016/12/14/edge-flash-click-run/
• https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/
• https://blog.google/products/chrome/flash-and-chrome/
• https://webkit.org/blog/6589/next-steps-for-legacy-plug-ins/
• https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support-has-been-dropped-other-than-flash/
• https://developer.mozilla.org/en-US/Add-ons/Plugins
• https://developer.chrome.com/extensions/npapi

• Check for if the tag is included, and has width=device-width.

  Note: For iOS 9+ initial-scale=1 is no longer needed (1, 2)

• Check for values that create bad user experience such as user-scalable=no.

• Check for values that are ignored such as user-scalable, min-scale, and max-scale.

  From https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/:

  "Now, we ignore the user-scalable, min-scale and max-scale settings. If you have content that disabled zoom, please test it on iOS 10, and understand that many users will be zooming now."

See also:

• https://www.youtube.com/watch?v=8J6EdpXdzqc&t=23m31s

• Check if the Set-Cookie header is sent with the Secure and HttpOnly values if the page is served over HTTPS.

See also:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies

We use rule-runner to test our rules. Right now, the biggest problem is that we need to create a bit of infrastructure around it to test the rules (some mocks, rely on jsdom, etc.).
We should refactor rule-runner in such a way that:

• It tests all the available collectors (although this should be configurable because of the limitations with travis)
• It's even easier to write rules

We should probably have a special web server we can control via the configuration in the rules. Port should be random so we can spin up several at the same time (tests are run in parallel).
It should accept text as HTML to return as well as a folder for static resources plus a way to configure some of the response headers.

Or test if just with the following config it works:

'/path': {
  statusCode: 301,
  content: '/'
}

We should do several things:

• Split into multiple related files.
• Rename it to interfaces.ts. All are interfaces IIRC.
• Keep interfaces.ts as a way to aggregate all and export them if it makes sense.
• Remove as many any as possible, probably by adding more interfaces. Tracked via #76

Not all rules (especially ones that do network related checks) make sense with local files, so currently those types of rules will need to have extra checks to work properly.

Wouldn't it be better if rules would specify (e.g.: have a property in meta) if they work or not with local files?

Right now it is undefined or null (emitAsync('fetch::end', null, networkData);). I think the reason is we want to put in there the element that triggered the requests but I don't think that's the way to go.
We are analyzing that resource and we need a way to identify exactly so we can group errors related to it. Also, some events will not have a source tag.
The initiator should come in the networkData object and be optional.

Try running #84 with npm run site -- http://edge.ms and you will see issues are not well grouped and makes more sense to have the url directly there instead of looking for it under request or response.

Sinon has released a new major version since we started the tests on this project. We need to update as soon as possible so we don't get left behind now that we don't use it that much.

• Check if the header is sent for non-HTML resources (e.g.: on images, fonts, etc.) - done in c55bdfb.
• Check for older deprecated version of the header are sent (i.e.:X-WebKit-CSP, X-Content-Security-Policy).

• TODO: Look into what other checks we can add for that this (e.g.: validate the content of the header, upgrade-insecure-requests)

See also:

• https://content-security-policy.com/

We should avoid using any on TypeScript as much as possible.

This is part of #75 but at a larger scale.

• Check if the <link> tag (e.g. <link rel="apple-touch-icon" href="apple-touch-icon.png">) is specified

  Note: In the past, people usually just had the apple-touch-icon in the root of the site, but that is no longer consider a good practice and can create a lot of issues (see: h5bp/html5-boilerplate#1622).

• Check if a 180×180px image is not used

• Check if multiple multiple images of different sizes are used

  Note: Usually iOS devices get upgraded pretty quickly, most people being on the latest 2 version of the iOS, so specifying multiple sizes of the apple-touch-icon just adds to the weight of the page, without no real benefit. One 180×180px apple-touch-icon is nowadays enough for all cases, as Safari will scale it down automatically if needed (see also: h5bp/html5-boilerplate#1367).

• Check if the image has transparent background

• Other?

Although the project started as plain JavaScript, we are going to migrate to TypeScript to help with the documentation and development process (intellisense, type checking, etc.).
This issue covers (if needed):

• refactoring
• documenting API
• set up TypeDoc in build process
• bug fixing

Epic to track all the places where we need to add tests (everywhere). Goal should be to have +90% code coverage.

There are different test runners in JavaScript. We should look which one is better suited form this project (mocha, ava, tape)

• <script> or <link> elements don't have the integrity attribute
• the content of the <script> or <link> elements doesn’t match the associated integrity value
• other checks (TODO: read the spec)

See also:

• https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
• Spec: https://w3c.github.io/webappsec-subresource-integrity/

We are not currently testing that fetch::error is properly emitted (and CDP doesn't emit it).
Need to fix this.

By default, the collectors will not request certain resources (e.g.: manifest file, all font files, etc.).

Since quite a few rules will need to analyze those requests/resources, it wouldn't make sense to have every rule add custom code to request them, so we should add a helper to do that and notify the subscribed rules.

What we might want to request (incomplete list):

• manifest file (<link rel="manifest" href="site.webmanifest">)
• rss and atom files (<link rel="alternate" ... href="...">)
• font files (specified in @font-face rules)
• images specified in css files, manifest file, etc.
• video, audio, and subtitle files
• source map files (e.g.: //# sourceMappingURL=example.js.map)

Discussion moved from #87 (comment):

Continuing the discussion about the encoding there are a couple things we can do. HTML5 defaults to utf8 but previous versions were ISO-8859-1 which are not supported by node directly. jsdom uses iconv-lite to do text transformations. I don't know how popular that encoding (or any other) are in non-western cultures.
We could:

1. Accept the PR as it is with a known issues section in the documentation linking to an issue to fix it.
2. Use iconv-lite to add support for the same encodings and maybe look into contributing back for the most popular missing ones. We will need to see what happens with jsdom collector because we are using request to get the initial HTML and by default uses utf8 and only supports the same that node does.

I'm not sure what percentage of the web is in non utf8 but we should check it and add support if it is significant if we want sonar to be successful.

TODO: determine exactly what should be checked and how.

• Check if the manifest is specified and exists (done in #54)
• Check if the manifest file is valid (partially done in: #56)
• Check if the file is not sent with the application/manifest+json media type (will be solved by #141)
• Check if the file extension is webmanifest (done in #39)

See: https://www.w3.org/TR/appmanifest/

• Check if the header is sent for non-HTML resources (e.g.: on images, fonts, etc.) - done in c55bdfb.
• Check if the header value is 1; mode=block. (?)

See also:

• https://blog.innerht.ml/the-misunderstood-x-xss-protection/

Add a new collector that supports the Chrome Debugging Protocol.

• Check if the header is sent for non-HTML resources (e.g.: on images, fonts, etc.) - done in c55bdfb.
• Check if the header is sent with the value "DENY" on pages that allow a user to make a state changing operation (e.g: login pages, pages that contain one-click purchase links, checkout or bank-transfer confirmation pages, pages that make permanent configuration changes, etc.)
• Other?

See also:

• https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

@molant:

Yes, we want to group them and I think it should be via the meta object. We can use the meta.docs.category or any another property we want. I don’t think extends is a good idea because that should be to extend a configuration set. We could add an option in .sonarrc to enable all rules within a category (that also works with the command line).

It could be something like:

“categories”: [“webapp”, “security”]

That can be mixed with the rules (rules will have higher priority so if we enable a category but disable a rule, all the rules for that category but that one will be enabled).

Problems for this approach:

• How to set up the severity error (could be an object instead of just an array of strings)
• How to set up the extended configuration (maybe it just enables the default values and then user needs to configure further via rules)

Since the Zopfli output (for the gzip option) is valid gzip content, there doesn't seem to be a straightforward and foolproof way to identify files compressed with Zopfli.

From an email discussion with @lvandeve:

There is no way to tell for sure. Adding information to the output to indicate zopfli, would actually add bits to the output so such thing is not done :) Any compressor can set the FLG, MTIME, and so on to anything it wants, and users of zopfli can also change the MTIME bytes that zopfli had output to an actual time.

One heuristic to tell that it was compressed with zopfli or another dense deflate compressor is to compress it with regular gzip -9 (which is fast), and compare that the size of the file to test is for example more than 3% smaller.

Other notes:

gzip

A gzip member header has the following structure

  +---+---+---+---+---+---+---+---+---+---+
  |ID1|ID2|CM |FLG|     MTIME     |XFL|OS | (more-->)
  +---+---+---+---+---+---+---+---+---+---+

where:

• ID1 = 1f and ID2 = 8b - these are the magic numbers that uniquely identify the content as being gzip.

• CM = 8 - this is a value customarily used by gzip

• FLG and MTIME are usually non-zero values.

• XFL will be either 0, 2, or 4:

  • 0 - default, compressor used intermediate levels of compression (when any of the -2 ... -8 options are used).
  • 2 - the compressor used maximum compression, slowest algorithm (when the -9 or --best option is used).
  • 4 - the compressor used fastest algorithm (when the -1 or --fast option is used).

Zopfli

On thing that Zopfli does is that it sets FLG and MTIME to zero, XFL to 2, and OS to 3, so basically files compressed with Zopfli will most likely start with 1f8b 0800 0000 0000 0203, unless things are changed by the user (which in general doesn't seem very likely to happen).

Now, regular gzip output might also start with that, even thought the chance of doing so is smaller:

• Most web servers (e.g.: Apache, NGINX), by default, will not opt users into the best compression level, therefore, the output shouldn't have XFL set to 2.
• Most utilities that output regular gzip will have non-zero values for MTIME and FLG.

So, if a file doesn't start with 1f8b 0800 0000 0000 0203, it's a good (not perfect) indication that Zopfli wasn't used, but it's a fast check compared to compressing files and comparing file sizes. However, if a file does start with that, it can be either Zopfli or gzip, and we cannot really make assumptions here.

Servers, frameworks, and server-side languages (e.g.: ASP.NET, PHP), often set, by default, HTTP headers with values that contains information about them: their name, version number, etc.

Sending those types of HTTP headers does not provide any value to users, contributes to header bloat, and just gives more information to any potential attackers about the technology stack being used.

List of headers:

• Server
• X-AspNet-Version
• X-AspNetMvc-version
• X-Powered-By
• X-Runtime
• X-Version

Right now we are doing:

• exports const name = ...: types.ts
• module.exports = { ... } : jsdom.ts

We should pick up a syntax and stick to it through the project.

• Check if different content is served if the request is made with different UA strings.
• Check if for code that does UA sniffing.

Ref: https://www.npmjs.com/package/markdownlint

The documentation will contain a lot of links, so we should have an automatic process to detect broken ones.

• Check if the header is sent and its value is nosniff.

See also:

• http://www.slideshare.net/hasegawayosuke/owasp-hasegawa
• http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx
• https://msdn.microsoft.com/en-us/library/ie/gg622941.aspx

See also:

• Seren Davies: Death to icon fonts - EpicFEL 2015 (slides)
• https://css-tricks.com/icon-fonts-vs-svg/
• <span> vs. <i> (https://www.youtube.com/watch?v=DGQSw6gc95k&t=13m + http://fontawesome.io/examples/)

We need to:

• find a way to calculate the offset automatically (if needed)
  • update the tests so we no longer have <!doctype html><html><head> in the same line
• make sure we get the same results for all collectors

Make collectors:

• trigger the same events
• fetch the same resources

Look into how SSL Server Test can be integrated.