I recently launched WebSecurity.is to help developers and operations people secure web apps. It’s designed to test web apps in 4 categories of security - HTTP, HTML5, connection (SSL/TLS) and Google’s Safe Browsing. Previously known as “HTTP Security Report”, the tool was renamed since the focus wasn’t just on HTTP anymore.
The scanner performs 27 checks and tests and presents the results as a score from 0 to 100. Most of these items checked for are considered best practises, especially from a defense-in-depth standpoint. WebSecurity.is tries to rank the findings and highlight the most important things to fix.
Let’s look at an example scan of Microsoft.com.
Microsoft.com scores highly on TLS but very low on HTTP and HTML5. The results reveal that Microsoft doesn’t use content security policy (CSP) and isn’t on the HTTP strict transport security (HSTS) preload list. It’s missing a few other defensive items and also exposes a lot of identifying information about the web server and framework. All in all, there is definite room for improvement.
Now let’s move on to more detailed discussion of the four main parts of the scanner.
HTTP headers can be used to harden web app security. HSTS, CSP, cookie hardening, control over what sites may place the site in question in an iframe, and more. There are a lot of ways for the web application to control browser via HTTP headers. If you’re not using them you may not be enjoying the level of security which they can offer.
Headers could also be leaking information about web app internals. Information about the webserver including version numbers, web framework, runtime version, etc. All of these make life easier for the hacker targeting your website, and may move the attacks from spray-and-pray attacks to targeted attacks against the particular webserver or web framework you are using. At the very worst, this information may reveal a vulnerable version of software being used in your stack, leading to quick pwnage of your site.
Security measures introduced in HTML5 can facilitate secure use of content delivery networks (CDNs) and social plugins. Adding social plugins or iframes to out sites or loading resources from external CDNs has traditionally required us to place some level of trust in web sites or code outside our control. However, with HTML5 we can assert control over all of these with sandboxed iframes, subresource integrity for CDN assets, and so on.
There are a lot of things to consider when deploying TLS. WebSecurity.is does basic health checks related to those, including HSTS usage, TLS version, HTTP to HTTPS redirects, and HSTS preload list inclusion. However, more in-depth analysis is better done with a dedicated TLS scanning tool.
Understanding what WebSecurity.is doesn’t do is equally important as what it does. It’s not a vulnerability scanner. It doesn’t check for injection attacks (like SQL injection), XSS vulnerabilities or the presence of CSRF tokens. There are many tools, commercial and open source which specialize in that type of scanning.
As with most types of security scanning, it’s possible to score highly and still be insecure, and vice-versa. There are a lot of bugs (logic and otherwise) which no tool can reliably detect. Conversely, all security tools are susceptible to reporting false positives (issues which are wrong or not relevant), and this one is no exception.
Despite these limitations I believe there’s a lot of value in this sort of scanning. WebSecurity.is aims to not only reveal where there is room for improvement for developers, but also to educate and provide recommendations. I hope it’ll be useful for you.
Photo credit: Strokkur hot spring, Iceland. Own photo..