Es gab einen Sicherheitscheck für die Startseite. Hier sind die Ergebnisse:
webbkoll | dataskydd.netFAQTech Svenska
Results for leererschreibtisch.de Check again 2018-03-30 03:17:37 Etc/UTC
Input URL: http://leererschreibtisch.de/
Secure Referrers leaked 1 Cookie 0 Third-party requests 0 Third-parties contacted
The server leererschreibtisch.de (220.127.116.11) appears to have been located in Germany during our test.
Please note that some sites use CDNs – content delivery networks – in which case the server location might vary depending on the location of the visitor. This tool, Webbkoll, is currently on a server in France. Secure connection
leererschreibtisch.de uses HTTPS by default.
HTTPS encrypts nearly all information sent between a client and a web service. Properly configured, it guarantees three things:
Confidentiality. The visitor's connection is encrypted, obscuring URLs, cookies, and other sensitive metadata. Authenticity. The visitor is talking to the "real" website, and not to an impersonator or through a "man-in-the-middle". Integrity. The data sent between the visitor and the website has not been tampered with or modified.
A plain HTTP connection can be easily monitored, modified, and impersonated. Every unencrypted HTTP request reveals information about a user’s behavior, and the interception and tracking of unencrypted browsing has become commonplace.
The goal of the Internet community is to establish encryption as the norm, and to phase out unencrypted connections. See W3C, IETF, IAB. Also:
Browsers support HTTP/2 — which improves page loading speeds — only over encrypted connections. Google Chrome (1, 2) and Mozilla Firefox (1) will mark plain HTTP as affirmatively non-secure and make powerful features impossible to use on non-secure sites. Google has begun to favor HTTPS websites in search rankings.
Please note that this tool only checks whether HTTPS is used by default. Next step is to ensure that the server is configured correctly and not susceptible to attacks due to out-of-date software, weak ciphers, etc.
Such things are out of scope for this tool, but Qualys SSL Labs provides an excellent free service that lets you check how a server is doing:
Analyze leererschreibtisch.de on SSL Labs Strict Transport Security not enabled
HTTP Strict Transport Security (HSTS) is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.
When a browser knows that a domain has enabled HSTS, it does two things:
Always uses an https:// connection, even when clicking on an http:// link or after typing a domain into the location bar without specifying a protocol. Removes the ability for users to click through warnings about invalid certificates.
Strict Transport Security was proposed in 2009, motivated by Moxie Marlinspike's demonstration of how a hostile network could downgrade visitor connections and exploit insecure redirects. It was quickly adopted by several major web browsers, and finalized as RFC 6797 in 2012.
The basic problem that HSTS solves is that even after a website turns on HTTPS, visitors may still end up trying to connect over plain HTTP. For example:
When a user types "example.com" into the URL bar, browsers default to using http://. A user may click on an old link that mistakenly uses an http:// URL. A user’s network may be hostile and actively rewrite https:// links to http://.
In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds (the policy is refreshed every time browser sees the header again):
In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be "preloaded" into browsers:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Since it's just an HTTP header, HSTS is very easy to add to a domain.
However, to enable HSTS for a domain via the HTTP header, the browser does have to see the header at least once. This means that users are not protected until after their first successful secure connection to a given domain.
To solve the "first visit" problem, the Chrome security team created an "HSTS preload list": a list of domains baked into Chrome that get Strict Transport Security enabled automatically, even for the first visit. Firefox, Safari, and newer versions of Internet Explorer also incorporate Chrome’s HSTS preload list.
The Chrome security team allows anyone to submit their domain to the list, provided it meets a few requirements.
Read more about HSTS and how to configure it in nginx, Apache and IIS. Referrers leaked
When you click a link, your browser will typically send the HTTP referer [sic] header to the webserver where the destination webpage is at. The header contains the full URL of the page you came from. This lets sites see where traffic comes from. The header is also sent when external resources (such as images, fonts, JS and CSS) are loaded.
The referrer header is privacy nightmare as it allows websites and services to track you across the web and learn about your browsing habits (and thus possibly private, sensitive information), particularly when combined with cookies.
Let's say you're logged in on Facebook. You visit a page with the URL http://www.some-hospital.com/some-medical-condition. On that page, you click a link to their Facebook page. Your browser then sends Referer: http://www.some-hospital.com/some-medical-condition to facebook.com, along with your Facebook cookies, allowing Facebook to associate your identity with that particular page.
The problem is made worse by the fact that many websites load resources like images and scripts from dozens of third-parties, sending referrer information to all of them, with the typical visitor having no idea that this is happening.
Thanks to a fairly recent development, Referrer Policy, it's finally possible for websites to tell browsers to not leak referrers. It lets you specify a policy that's applied to all links clicked, as well as all other requests generated by the page (images, JS, etc.).
A few different policies are offered, such as origin (strips everything except the origin) and origin-when-cross-origin (sends full URL with same-origin requests, otherwise stripped). We recommend no-referrer, which kills the referrer header entirely for all requests, no matter the destination; or same-origin, which kills the referrer for third-party requests but not for requests to the same origin.
A referrer policy can easily be set with a <meta> element in your HTML. Simply include this inside the <head> section:
<meta name="referrer" content="no-referrer">
While still a work in progress, Referrer Policy is now supported by all major browsers (except Internet Explorer, although it is supported by Edge, the new browser in Windows 10). First-party cookies
One first-party cookie. leererschreibtisch.de cpPosTime 1522379846.8774 2018-03-30 03:18:26Z Third-party cookies
No third-party cookies without consent. Third-party requests
No third-party requests.
A third-party request is a request to a domain that's not leererschreibtisch.de or one of its subdomains. Content-Security-Policy not enabled
Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. It can also help prevent information leakage.
report-uri.io has excellent (free) tools with which you can build or analyze a Content Security Policy. HTTP headers Header Set? Public-Key-Pins NO
HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.1 Referrer-Policy NO
Referrer-Policy is a new header that allows a site to control how much information the browser includes with navigations away from a document (or when loading external resources) and should be set by all sites. (It can also be set using a meta element; see above.) Strict-Transport-Security NO
HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. X-Content-Type-Options YES, nosniff
X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. This helps to reduce the danger of drive-by downloads. The only valid value for this header is "X-Content-Type-Options: nosniff". X-Frame-Options NO
X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. X-Xss-Protection NO
X-XSS-Protection sets the configuration for the cross-site scripting filters built into most browsers. The best configuration is "X-XSS-Protection: 1; mode=block".
1. Note that Public-Key-Pins can brick your site if something goes wrong and should only be used with great caution, if at all. See 1, 2, 3. What this tool checks (and doesn't check)
This tool attempts to simulate what happens when a user visits a specified page with a typical browser. The browser has no addons/extensions installed, and Do Not Track (DNT) is not enabled, since this is the default setting in most browsers.
External files such as images, scripts and CSS are loaded, but the tool performs no interactions with the page — no links are clicked, no forms are submitted.
Disclaimer: The results presented here might not be 100% correct. Bugs happen. This tool is meant to be used by site owners as a starting point for improvements, not as a rigorous analysis.
The HTTP header descriptions are based on the ones from securityheaders.io by Scott Helme, CC-BY-SA 4.0. Text about HTTPS partly adapted from the CIO Council's The HTTPS-Only Standard (public domain). MaxMind's GeoLite2 country database (CC-BY-SA 4.0) is used for GeoIP lookups.
Developed by dataskydd.net. Originally funded by Internetfonden / IIS.
The code is available on GitHub.
Feedback? Questions? email@example.com
All text, except quotes and where noted, is available under CC0.