$ pip install hsecscan

$ hsecscan 
usage: hsecscan.py [-h] [-P] [-p] [-H Header] [-u URL] [-R] [-i]
                   [-U User-Agent] [-D DBFILE] [-d 'POST data'] [-x PROXY]
                   [-a]

Ein Sicherheitsscanner für HTTP-Antwortheader.

optionale Argumente:
  -h, --help            Zeigt diese Hilfemeldung an und beendet.
  -P, --database        Gibt die gesamte Datenbank der Antwortheader aus.
  -p, --headers         Gibt nur die aktivierten Antwortheader aus der Datenbank aus.
  -H Header, --header Header
                        Zeigt Details für einen bestimmten Header an (Beispiel: Strict-
                        Transport-Security).
  -u URL, --URL URL     Die zu scannende URL.
  -R, --redirect        Gibt Umleitungsheader aus.
  -i, --insecure        Deaktiviert die Zertifikatsprüfung.
  -U User-Agent, --useragent User-Agent
                        Setzt den User-Agent-Request-Header (Standard: hsecscan).
  -D DBFILE, --dbfile DBFILE
                        Setzt die Datenbankdatei (Standard: hsecscan.db).
  -d 'POST data', --postdata 'POST data'
                        Setzt die POST-Daten (in einfachen Anführungszeichen), andernfalls wird ein GET ausgeführt (Beispiel: '{ "q":"query string",
                        "foo":"bar" }').
  -x PROXY, --proxy PROXY
                        Setzt den Proxyserver (Beispiel: 192.168.1.1:8080).
  -a, --all             Zeigt Details für alle Antwortheader an. Gut geeignet zur Überprüfung der zugehörigen RFC.

$ hsecscan -i -u https://google.com
>> ANTWORTINFORMATIONEN <<
URL: https://www.google.com.br/?gfe_rd=cr&ei=GF5HV4ucH7DL8geg-aK4Dw
Statuscode: 200
Header:
 Datum: Thu, 26 May 2016 20:35:36 GMT
 Läuft ab: -1
 Cache-Control: private, max-age=0
 Content-Type: text/html; charset=ISO-8859-1
 P3P: CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
 Server: gws
 X-XSS-Protection: 1; mode=block
 X-Frame-Options: SAMEORIGIN
 Set-Cookie: NID=79=hDENeVI81zBYDtmqeCKAc5mxg6AQ-S24ahNqZ8El37rlJmYwUtgJg4vXAya7jKSyB2VqYI33JlLPacGonMPajpcDpUkb7mMtWMbNwIZQ8CyQBA1qXsRhjlLXU_4WExlI; expires=Fri, 25-Nov-2016 20:35:36 GMT; path=/; domain=.google.com.br; HttpOnly
 Alternate-Protocol: 443:quic
 Alt-Svc: quic=":443"; ma=2592000; v="34,33,32,31,30,29,28,27,26,25"
 Accept-Ranges: none
 Vary: Accept-Encoding
 Connection: close

>> DETAILS DER ANTWORTHEADER <<
Header-Feldname: X-XSS-Protection
Wert: 1; mode=block
Referenz: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
Sicherheitsbeschreibung: Dieser Header aktiviert den in den meisten aktuellen Webbrowsern integrierten Cross-Site-Scripting (XSS)-Filter. Normalerweise ist er ohnehin standardmäßig aktiviert. Die Aufgabe dieses Headers besteht darin, den Filter für diese bestimmte Website wieder zu aktivieren, falls er vom Benutzer deaktiviert wurde. Dieser Header wird im IE 8+ und in Chrome (Versionen nicht sicher) unterstützt. Der Anti-XSS-Filter wurde in Chrome 4 hinzugefügt. Es ist nicht bekannt, ob diese Version diesen Header berücksichtigte.
Sicherheitsreferenz: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Empfehlungen: Verwenden Sie "X-XSS-Protection: 1; mode=block", wann immer möglich (Ref. http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx).
CWE: CWE-79: Fehlerhafte Neutralisierung von Eingaben während der Webseitengenerierung ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header-Feldname: Set-Cookie
Wert: NID=79=hDENeVI81zBYDtmqeCKAc5mxg6AQ-S24ahNqZ8El37rlJmYwUtgJg4vXAya7jKSyB2VqYI33JlLPacGonMPajpcDpUkb7mMtWMbNwIZQ8CyQBA1qXsRhjlLXU_4WExlI; expires=Fri, 25-Nov-2016 20:35:36 GMT; path=/; domain=.google.com.br; HttpOnly
Referenz: https://tools.ietf.org/html/rfc6265
Sicherheitsbeschreibung: Cookies weisen eine Reihe von Sicherheitsrisiken auf. Insbesondere ermutigen Cookies Entwickler, sich auf Ambient Authority für die Authentifizierung zu verlassen, was oft zu Angriffen wie Cross-Site Request Forgery führt. Auch beim Speichern von Sitzungskennungen in Cookies erzeugen Entwickler häufig Schwachstellen durch Sitzungsfixierung. Transportverschlüsselung wie bei HTTPS reicht nicht aus, um einen Netzwerkangreifer daran zu hindern, die Cookies eines Opfers zu erhalten oder zu verändern, da das Cookie-Protokoll selbst verschiedene Schwachstellen aufweist. Darüber hinaus bieten Cookies standardmäßig keine Vertraulichkeit oder Integrität gegenüber Netzwerkangreifern, selbst wenn sie in Verbindung mit HTTPS verwendet werden.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc6265#section-8
Empfehlungen: Bitte lesen Sie zumindest diese Referenzen: https://tools.ietf.org/html/rfc6265#section-8 und https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies.
CWE: CWE-614: Sensitives Cookie in HTTPS-Sitzung ohne 'Secure'-Attribut
CWE URL: https://cwe.mitre.org/data/definitions/614.html

Header-Feldname: Accept-Ranges
Wert: none
Referenz: https://tools.ietf.org/html/rfc7233#section-2.3
Sicherheitsbeschreibung: Unbeschränkte Mehrfachbereichsanfragen sind anfällig für Denial-of-Service-Angriffe, da der Aufwand für die Anforderung vieler überlappender Bereiche derselben Daten im Vergleich zu der Zeit, dem Speicher und der Bandbreite, die für den Versuch, die angeforderten Daten in vielen Teilen bereitzustellen, benötigt wird, gering ist.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7233#section-6
Empfehlungen: Server sollten übermäßige Bereichsanfragen ignorieren, zusammenführen oder ablehnen, z. B. Anfragen nach mehr als zwei überlappenden Bereichen oder nach vielen kleinen Bereichen in einem einzigen Satz, insbesondere wenn die Bereiche ohne ersichtlichen Grund nicht in der richtigen Reihenfolge angefordert werden.
CWE: CWE-400: Unkontrollierter Ressourcenverbrauch ('Ressourcenerschöpfung')
CWE URL: https://cwe.mitre.org/data/definitions/400.html

Header-Feldname: Server
Wert: gws
Referenz: https://tools.ietf.org/html/rfc7231#section-7.4.2
Sicherheitsbeschreibung: Übermäßig lange und detaillierte Server-Feldwerte erhöhen die Antwortlatenz und geben möglicherweise interne Implementierungsdetails preis, die es Angreifern (geringfügig) erleichtern könnten, bekannte Sicherheitslücken zu finden und auszunutzen.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7231#section-7.4.2
Empfehlungen: Ein Ursprungsserver SOLLTE kein Server-Feld mit unnötig feinen Details erzeugen und SOLLTE die Hinzufügung von Unterprodukten durch Dritte einschränken.
CWE: CWE-200: Preisgabe von Informationen
CWE URL: https://cwe.mitre.org/data/definitions/200.html

Header-Feldname: Cache-Control
Wert: private, max-age=0
Referenz: https://tools.ietf.org/html/rfc7234#section-5.2
Sicherheitsbeschreibung: Caches legen zusätzliche potenzielle Schwachstellen offen, da der Inhalt des Caches ein attraktives Ziel für böswillige Ausbeutung darstellt. Da Cache-Inhalte nach Abschluss einer HTTP-Anfrage bestehen bleiben, kann ein Angriff auf den Cache Informationen lange nachdem der Benutzer glaubt, dass die Informationen aus dem Netzwerk entfernt wurden, offenlegen. Daher müssen Cache-Inhalte als vertrauliche Informationen geschützt werden.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7234#section-8
Empfehlungen: Speichern Sie keine unnötig vertraulichen Informationen im Cache.
CWE: CWE-524: Preisgabe von Informationen durch Caching
CWE URL: https://cwe.mitre.org/data/definitions/524.html

Header-Feldname: P3P
Wert: CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
Referenz: http://www.w3.org/TR/P3P11/#syntax_ext
Sicherheitsbeschreibung: Obwohl P3P selbst keine Sicherheitsmechanismen enthält, ist es für die Verwendung in Verbindung mit Sicherheitstools vorgesehen. Persönliche Daten der Benutzer sollten stets mit angemessenen Sicherheitsvorkehrungen geschützt werden, die der Sensibilität der Informationen entsprechen.
Sicherheitsreferenz: http://www.w3.org/TR/P3P11/#principles_security
Empfehlungen: -
CWE: -
CWE URL: -

Header-Feldname: Content-Type
Wert: text/html; charset=ISO-8859-1
Referenz: https://tools.ietf.org/html/rfc7231#section-3.1.1.5
Sicherheitsbeschreibung: In der Praxis konfigurieren Ressourcenbesitzer ihren Ursprungsserver nicht immer richtig, um den korrekten Content-Type für eine bestimmte Darstellung bereitzustellen. Dies führt dazu, dass einige Clients den Inhalt einer Nutzlast untersuchen und den angegebenen Typ überschreiben. Clients, die dies tun, riskieren, falsche Schlussfolgerungen zu ziehen, was zusätzliche Sicherheitsrisiken aufdecken kann (z. B. „Privilegieneskalation").
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7231#section-3.1.1.5
Empfehlungen: Konfigurieren Sie ihren Ursprungsserver richtig, um den korrekten Content-Type für eine bestimmte Darstellung bereitzustellen.
CWE: CWE-430: Einsatz des falschen Handlers
CWE URL: https://cwe.mitre.org/data/definitions/430.html

Header-Feldname: X-Frame-Options
Wert: SAMEORIGIN
Referenz: https://tools.ietf.org/html/rfc7034
Sicherheitsbeschreibung: Die Verwendung von „X-Frame-Options" ermöglicht es einer Webseite von Host B zu erklären, dass ihr Inhalt (z. B. ein Button, Links, Text usw.) nicht in einem Frame (<frame> oder ) einer anderen Seite (z. B. von Host A) angezeigt werden darf. Dies geschieht durch eine im HTTP-Header deklarierte Richtlinie, die von Browserimplementierungen durchgesetzt wird.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7034
Empfehlungen: In den Jahren 2009 und 2010 führten viele Browseranbieter ([Microsoft-X-Frame-Options] und [Mozilla-X-Frame-Options]) die Verwendung eines nicht standardmäßigen HTTP [RFC2616]-Headerfeldes „X-Frame-Options" ein, um vor Clickjacking zu schützen. Bitte prüfen Sie hier https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet, welche Option für Ihren Fall am besten geeignet ist.
CWE: CWE-693: Fehler im Schutzmechanismus
CWE URL: https://cwe.mitre.org/data/definitions/693.html

>> FEHLENDE ANTWORTHEADER <<
Header-Feldname: Pragma
Referenz: https://tools.ietf.org/html/rfc7234#section-5.4
Sicherheitsbeschreibung: Caches legen zusätzliche potenzielle Schwachstellen offen, da der Inhalt des Caches ein attraktives Ziel für böswillige Ausbeutung darstellt.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7234#section-8
Empfehlungen: Das „Pragma"-Headerfeld ermöglicht die Abwärtskompatibilität mit HTTP/1.0-Caches, sodass Clients eine „no-cache"-Anfrage spezifizieren können, die sie verstehen (da Cache-Control erst mit HTTP/1.1 definiert wurde). Wenn das Cache-Control-Headerfeld ebenfalls vorhanden und in einer Anfrage verstanden wird, wird Pragma ignoriert. Definieren Sie nach Möglichkeit „Pragma: no-cache".
CWE: CWE-524: Preisgabe von Informationen durch Caching
CWE URL: https://cwe.mitre.org/data/definitions/524.html

Header-Feldname: Public-Key-Pins
Referenz: https://tools.ietf.org/html/rfc7469
Sicherheitsbeschreibung: HTTP Public Key Pinning (HPKP) ist ein Trust-on-First-Use-Sicherheitsmechanismus, der HTTPS-Websites vor Identitätsdiebstahl durch betrügerische Zertifikate schützt, die von kompromittierten Zertifizierungsstellen ausgestellt wurden. Der Sicherheitskontext oder die Pinset-Daten werden von der Website oder dem Ursprung bereitgestellt.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7469
Empfehlungen: Die sichere Bereitstellung von Public Key Pinning (PKP) erfordert operative und organisatorische Reife, da die Gefahr besteht, dass Hosts sich selbst unerreichbar machen, indem sie auf eine Menge von SPKIs pinnen, die ungültig wird. Mit Sorgfalt können Hostbetreiber das Risiko von Man-in-the-Middle (MITM)-Angriffen und anderen Problemen mit der falschen Authentifizierung für ihre Benutzer erheblich reduzieren, ohne unangemessene Risiken einzugehen. PKP ist für die Verwendung zusammen mit HTTP Strict Transport Security (HSTS) [RFC6797] gedacht, aber es ist möglich, Schlüssel ohne HSTS zu pinnen.
CWE: CWE-295: Fehlerhafte Zertifikatsprüfung
CWE URL: https://cwe.mitre.org/data/definitions/295.html

Header-Feldname: Public-Key-Pins-Report-Only
Referenz: https://tools.ietf.org/html/rfc7469
Sicherheitsbeschreibung: HTTP Public Key Pinning (HPKP) ist ein Trust-on-First-Use-Sicherheitsmechanismus, der HTTPS-Websites vor Identitätsdiebstahl durch betrügerische Zertifikate schützt, die von kompromittierten Zertifizierungsstellen ausgestellt wurden. Der Sicherheitskontext oder die Pinset-Daten werden von der Website oder dem Ursprung bereitgestellt.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7469
Empfehlungen: Die sichere Bereitstellung von Public Key Pinning (PKP) erfordert operative und organisatorische Reife, da die Gefahr besteht, dass Hosts sich selbst unerreichbar machen, indem sie auf eine Menge von SPKIs pinnen, die ungültig wird. Mit Sorgfalt können Hostbetreiber das Risiko von Man-in-the-Middle (MITM)-Angriffen und anderen Problemen mit der falschen Authentifizierung für ihre Benutzer erheblich reduzieren, ohne unangemessene Risiken einzugehen. PKP ist für die Verwendung zusammen mit HTTP Strict Transport Security (HSTS) [RFC6797] gedacht, aber es ist möglich, Schlüssel ohne HSTS zu pinnen.
CWE: CWE-295: Fehlerhafte Zertifikatsprüfung
CWE URL: https://cwe.mitre.org/data/definitions/295.html

Header-Feldname: Strict-Transport-Security
Referenz: https://tools.ietf.org/html/rfc6797
Sicherheitsbeschreibung: HTTP Strict Transport Security (HSTS) ist ein Websicherheitsrichtlinienmechanismus, der dazu beiträgt, sichere HTTPS-Websites vor Downgrade-Angriffen und Cookie-Entführung zu schützen. Es ermöglicht Webservern zu erklären, dass Webbrowser (oder andere konforme Benutzeragenten) nur über sichere HTTPS-Verbindungen mit ihnen interagieren sollten und niemals über das unsichere HTTP-Protokoll. HSTS ist ein IETF-Standard-Track-Protokoll und wird in RFC 6797 spezifiziert.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc6797
Empfehlungen: Bitte lesen Sie zumindest diese Referenz: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security.
CWE: CWE-311: Fehlende Verschlüsselung sensibler Daten
CWE URL: https://cwe.mitre.org/data/definitions/311.html

Header-Feldname: Frame-Options
Referenz: https://tools.ietf.org/html/rfc7034
Sicherheitsbeschreibung: Die Verwendung von „X-Frame-Options" ermöglicht es einer Webseite von Host B zu erklären, dass ihr Inhalt (z. B. ein Button, Links, Text usw.) nicht in einem Frame (<frame> oder ) einer anderen Seite (z. B. von Host A) angezeigt werden darf. Dies geschieht durch eine im HTTP-Header deklarierte Richtlinie, die von Browserimplementierungen durchgesetzt wird.
Sicherheitsreferenz: https://tools.ietf.org/html/rfc7034
Empfehlungen: In den Jahren 2009 und 2010 führten viele Browseranbieter ([Microsoft-X-Frame-Options] und [Mozilla-X-Frame-Options]) die Verwendung eines nicht standardmäßigen HTTP [RFC2616]-Headerfeldes „X-Frame-Options" ein, um vor Clickjacking zu schützen. Bitte prüfen Sie hier https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet, welche Option für Ihren Fall am besten geeignet ist.
CWE: CWE-693: Fehler im Schutzmechanismus
CWE URL: https://cwe.mitre.org/data/definitions/693.html

Header-Feldname: X-Content-Type-Options
Referenz: http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
Sicherheitsbeschreibung: Der einzige definierte Wert „nosniff" verhindert, dass Internet Explorer und Google Chrome einen MIME-Sniffing einer Antwort weg vom deklarierten Content-Type durchführen. Dies gilt auch für Google Chrome beim Herunterladen von Erweiterungen. Dies reduziert die Gefahr von Drive-by-Download-Angriffen und Websites, die benutzerhochgeladene Inhalte bereitstellen, die durch clevere Namensgebung von MSIE als ausführbare oder dynamische HTML-Dateien behandelt werden könnten.
Sicherheitsreferenz: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Empfehlungen: Verwenden Sie stets den einzigen definierten Wert „nosniff".
CWE: CWE-79: Fehlerhafte Neutralisierung von Eingaben während der Webseitengenerierung ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header-Feldname: Content-Security-Policy
Referenz: http://www.w3.org/TR/CSP/
Sicherheitsbeschreibung: Content Security Policy erfordert eine sorgfältige Abstimmung und präzise Definition der Richtlinie. Wenn aktiviert, hat CSP erhebliche Auswirkungen auf die Art und Weise, wie der Browser Seiten rendert (z. B. wird Inline-JavaScript standardmäßig deaktiviert und muss explizit in der Richtlinie erlaubt werden). CSP verhindert eine breite Palette von Angriffen, einschließlich Cross-Site-Scripting und anderen Cross-Site-Injection-Angriffen.
Sicherheitsreferenz: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Empfehlungen: Lesen Sie die Referenz http://www.w3.org/TR/CSP/ und stellen Sie gemäß Ihrem Fall ein. Das ist keine einfache Aufgabe.
CWE: CWE-79: Fehlerhafte Neutralisierung von Eingaben während der Webseitengenerierung ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header-Feldname: X-Content-Security-Policy
Referenz: http://www.w3.org/TR/CSP/
Sicherheitsbeschreibung: Content Security Policy erfordert eine sorgfältige Abstimmung und präzise Definition der Richtlinie. Wenn aktiviert, hat CSP erhebliche Auswirkungen auf die Art und Weise, wie der Browser Seiten rendert (z. B. wird Inline-JavaScript standardmäßig deaktiviert und muss explizit in der Richtlinie erlaubt werden). CSP verhindert eine breite Palette von Angriffen, einschließlich Cross-Site-Scripting und anderen Cross-Site-Injection-Angriffen.
Sicherheitsreferenz: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Empfehlungen: Lesen Sie die Referenz http://www.w3.org/TR/CSP/ und stellen Sie gemäß Ihrem Fall ein. Das ist keine einfache Aufgabe.
CWE: CWE-79: Fehlerhafte Neutralisierung von Eingaben während der Webseitengenerierung ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header-Feldname: X-WebKit-CSP
Referenz: http://www.w3.org/TR/CSP/
Sicherheitsbeschreibung: Content Security Policy erfordert eine sorgfältige Abstimmung und präzise Definition der Richtlinie. Wenn aktiviert, hat CSP erhebliche Auswirkungen auf die Art und Weise, wie der Browser Seiten rendert (z. B. wird Inline-JavaScript standardmäßig deaktiviert und muss explizit in der Richtlinie erlaubt werden). CSP verhindert eine breite Palette von Angriffen, einschließlich Cross-Site-Scripting und anderen Cross-Site-Injection-Angriffen.
Sicherheitsreferenz: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Empfehlungen: Lesen Sie die Referenz http://www.w3.org/TR/CSP/ und stellen Sie gemäß Ihrem Fall ein. Das ist keine einfache Aufgabe.
CWE: CWE-79: Fehlerhafte Neutralisierung von Eingaben während der Webseitengenerierung ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header-Feldname: Content-Security-Policy-Report-Only
Referenz: http://www.w3.org/TR/CSP/
Sicherheitsbeschreibung: Wie Content-Security-Policy, jedoch nur mit Berichten. Nützlich während der Implementierungs-, Abstimmungs- und Testphasen.
Sicherheitsreferenz: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Empfehlungen: Lesen Sie die Referenz http://www.w3.org/TR/CSP/ und stellen Sie gemäß Ihrem Fall ein. Das ist keine einfache Aufgabe.
CWE: CWE-79: Fehlerhafte Neutralisierung von Eingaben während der Webseitengenerierung ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html