diff --git a/.dockerignore b/.dockerignore new file mode 100644 index 0000000..1b4d0bb --- /dev/null +++ b/.dockerignore @@ -0,0 +1,4 @@ +.git +database/database.sqlite +app/storage/ +.env diff --git a/.env.example b/.env.example index d445610..9d6626d 100644 --- a/.env.example +++ b/.env.example @@ -1,32 +1,14 @@ -APP_ENV=local -APP_KEY= -APP_DEBUG=true -APP_LOG_LEVEL=debug +APP_ENV=production +APP_KEY=base64:I8dXfAzV1sKdq5hSygF0kxduUOZjPYk7V2d7HtiTxik= +APP_DEBUG=false +APP_LOG_LEVEL=info APP_URL=http://localhost -DB_CONNECTION=mysql -DB_HOST=127.0.0.1 -DB_PORT=3306 -DB_DATABASE=homestead -DB_USERNAME=homestead -DB_PASSWORD=secret +LOG_CHANNEL=stderr -BROADCAST_DRIVER=log -CACHE_DRIVER=file -SESSION_DRIVER=file -QUEUE_DRIVER=sync - -REDIS_HOST=127.0.0.1 -REDIS_PASSWORD=null -REDIS_PORT=6379 +DB_CONNECTION=redis -MAIL_DRIVER=smtp -MAIL_HOST=mailtrap.io -MAIL_PORT=2525 -MAIL_USERNAME=null -MAIL_PASSWORD=null -MAIL_ENCRYPTION=null - -PUSHER_APP_ID= -PUSHER_KEY= -PUSHER_SECRET= +BROADCAST_DRIVER=log +CACHE_DRIVER=redis +SESSION_DRIVER=redis +QUEUE_DRIVER=redis diff --git a/.gitignore b/.gitignore index e6066f6..c350f9c 100644 --- a/.gitignore +++ b/.gitignore @@ -6,4 +6,5 @@ Homestead.json Homestead.yaml .env .phpstorm.meta.php -_ide_helper.php \ No newline at end of file +_ide_helper.php +laradock/ diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..5be03cf --- /dev/null +++ b/.travis.yml @@ -0,0 +1,43 @@ +language: php + +php: + - "7.2" + +cache: + directories: + - "./vendor" + +dist: trusty + +before_script: + - composer install --no-interaction + +script: + - ./vendor/bin/phpunit + - docker build -t hshs-domxss-scanner . + +before_deploy: + - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin + +deploy: + - provider: script + skip_cleanup: true + on: + branch: develop + script: >- + docker tag hshs-domxss-scanner siwecos/hshs-domxss-scanner:develop && + docker push siwecos/hshs-domxss-scanner:develop + - provider: script + skip_cleanup: true + on: + branch: master + script: >- + docker tag hshs-domxss-scanner siwecos/hshs-domxss-scanner:latest && + docker push siwecos/hshs-domxss-scanner:latest + - provider: script + skip_cleanup: true + on: + tags: true + script: >- + docker tag hshs-domxss-scanner siwecos/hshs-domxss-scanner:$TRAVIS_TAG && + docker push siwecos/hshs-domxss-scanner:$TRAVIS_TAG diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..5871a3b --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,122 @@ +# Changelog +All notable changes to this project will be documented in this file. + +The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) +and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). + +## [Unreleased] + +## [1.6.0] - 2019-05-07 +### Changed +- Output format to new [defined standard](https://github.com/SIWECOS/siwecos-core-api/tree/develop#translatablemessage-object) +- Docker base image to `siwecos/dockered-laravel:7.2` + + +## [1.5.5] - 2019-04-10 +### Changed +- Travis workflow + +## [1.5.4] - 2019-04-10 +### Changed +- Translation string for ReferrerPolicy `DIRECTIVE_SET` + +## [1.5.3] - 2019-04-05 +### Fixed +- Fixed typo + +## [1.5.2] - 2019-04-05 +### Fixed +- Timeout issues +- Crash when the `Set-Cookie` header was invalid + +## [1.5.1] - 2019-04-04 +### Added +- Correct callback logic via Job implementation. +- Feature to use a custom `userAgent` + +### Fixed +- Several issues with DOMXSS part +- Documentation +- Deployment via Travis +- Returning correct json responses +- `TranslatableMessage` scheme +- Minimized docker image + +## [1.3.1] - 2018-10-18 +### Fixed +- Fixed Set-Cookie name + +### Changes +- Updated README for Set-Cookie headers. + + +## [1.3.0] - 2018-10-17 +### Added +- Implemented SetCookieRating #32 + +### Fixed +- Fixed deprecation error in PHP 7.2 +- Fixed parent constructor call. +- Fixed missing php dependency in Dockerfile + + +## [1.2.1] - 2018-10-11 +### Fixed +- Fixed deprecation error `INTL_IDNA_VARIANT_2003 is deprecated`.
+[Further Information](https://bugs.php.net/bug.php?id=75609) + + +## [1.2.0] - 2018-10-10 +### Fixed +- Fixed #51 + +### Added +- Support for domains with umlauts + +### Changed +- Upraded to Laravel 5.7 +- SpeedUp PHPUnit tests + + +## [1.1.0] - 2018-10-01 +### Added +- `Referrer-Policy` header rating + + +## [1.0.2] - 2018-09-14 +### Fixed +- Bugs in ContentTypeRating when only the `meta` tags are set. +- Rating of sources and sinks with comments (#41). + +### Changed +- Upgraded `voku/simple_html_dom` to actual version. + + +## [1.0.1] - 2018-09-12 +### Fixed +- Bugs in ContentTypeRating when only the `meta` tags are set. +- Rating of sources and sinks with comments (#41). + +### Changed +- Upgraded `voku/simple_html_dom` to actual version. + + +## [1.0.0] - 2018-09-07 +### Added +- CHANGELOG.md and semantic versioning + +[Unreleased]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.6.0..develop +[1.6.0]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.5.5...1.6.0 +[1.5.5]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.5.4...1.5.5 +[1.5.4]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.5.3...1.5.4 +[1.5.3]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.5.2...1.5.3 +[1.5.2]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.5.1...1.5.2 +[1.5.1]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.3.1...1.5.1 +[1.3.1]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.3.0...1.3.1 +[1.3.0]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.2.0...1.3.0 +[1.2.1]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.2.0...1.2.1 +[1.2.0]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.1.0...1.2.0 +[1.1.0]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.0.2...1.1.0 +[1.0.2]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.0.1...1.0.2 +[1.0.1]: https://github.com/SIWECOS/HSHS-DOMXSS-Scanner/compare/1.0.0...1.0.1 + diff --git a/DOMXSS.de.md b/DOMXSS.de.md new file mode 100644 index 0000000..bb8abde --- /dev/null +++ b/DOMXSS.de.md @@ -0,0 +1,112 @@ + +# DOMXSS + +DOMXSS Scanner + +## SINKS + +### Headline + +Überprüfung des JavaScript-Codes nach DOMXSS-Sinks + +### Category + +JavaScript + +### Description + +Es wurde mindestens eine Codestelle beim Scan Ihrer Webseite gefunden, der unter bestimmten Voraussetzungen auf eine DOM-basierende [[Cross-Site Scripting|Cross-Site Scripting-Anfälligkeit]] hindeutet. Diese Stelle kann eine Schwachstelle auf Ihrer Webseite darstellen. + +### Background + +[[Cross-Site Scripting]] stellt eine Möglichkeit dar, den HTML-Code auf Ihrer Webseite zu manipulieren und zu infiltrieren. Es ermöglicht einem Angreifer, Skripte indirekt an den [[Browser]] Ihres Webseiten-Besuchers zu senden und damit Schadcode auf der Seite des Besuchers auszuführen. + +### Consequence + +[[Cross-Site Scripting]] ermöglicht es Kriminellen auf Ihrer Webseite Schadcode zu hinterlegen. Dieser Code kann Ihre Besucher oder Kunden infizieren und so möglicherweise massiven Schaden anrichten, z. B. wenn der Schadcode zur Installation eines [[Ransomware|Erpressungstrojaners]] in dessen Unternehmensnetzwerk führt. In diesem Fall könnten Sie für den Schaden haftbar gemacht werden. IT-Sicherheitsunternehmen könnten Sie in den Index von gefährlichen Webseiten aufnehmen und so Dritten den Zugriff auf Ihre Webseite aus Sicherheitsgründen verweigern. Die Information, dass Ihre Webseite Schadsoftware enthält/enthielt, ist auch viele Jahre nach dem Entfernen des Schadcodes bei Internet-Suchmaschinen ersichtlich. Eine Listung auf solch einer Blacklist kann zudem dazu führen, dass Sie auch keine [[Email|E-Mails]] mehr empfangen oder senden können, da Ihr gesamtes Netzwerk und die [[IP]] als Gefährdung anderer eingestuft wird. + +### Solution_Tips + +Wenn unsicherer JavaScript-Code gemeldet wird, ist die [[Webanwendung]] eventuell anfällig für sog. [[DOMXSS-Sinks|DOMXSS]]-Angriffe. +Das Ergebnis der Untersuchung kann nur als Hinweis auf Sicherheitslücken verwendet werden. Weitere Tests sind erforderlich, um die [[Schwachstellen|Schwachstellen]] auf der Webseite zu bestätigen. + +### Link + +DOMXSS-Schwachstelle + +### Negative + +Unsicheren [[JavaScript]]-Code verwendet [[DOMXSS-Sinks]]. + +### Positive + +Automatisiert wurden keine unsicheren Codebestandteile für [[DOMXSS-Sinks]] erkannt. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## SOURCES + +### Headline + +Überprüfung des JavaScript-Codes nach DOMXSS-Sources + +### Category + +JavaScript + +### Description + +Bei der Überprüfung wurde mindestens eine [[Schwachstellen|Schwachstelle]] auf der Webseite gefunden, die von einer externen, möglicherweise nicht vertrauenswürdigen Quelle gesteuert werden könnte. + +### Background + +Durch das Laden von Dateien und Codes aus unsicheren bzw. externen Quelle entsteht für Ihre Webseite eine potentielle Sicherheitslücke. Ein Angreifer, der die externe Quelle kontrolliert, könnte einen Schadcode hochladen, der dann auf Ihrer Seite ausgeführt werden kann. + +### Consequence + +[[Cross-Site Scripting]] ermöglicht es Kriminellen auf Ihrer Webseite Schadcode zu hinterlegen. Dieser Code kann Ihre Besucher oder Kunden infizieren und so möglicherweise massiven Schaden anrichten, z. B. wenn der Schadcode zur Installation eines [[Ransomware|Erpressungstrojaners]] in dessen Unternehmensnetzwerk führt. In diesem Fall könnten Sie für den Schaden haftbar gemacht werden. IT-Sicherheitsunternehmen könnten Sie in den Index von gefährlichen Webseiten aufnehmen und so Dritten den Zugriff auf Ihre Webseite aus Sicherheitsgründen verweigern. Die Information, dass Ihre Webseite Schadsoftware enthält/enthielt, ist auch viele Jahre nach dem Entfernen des Schadcodes bei Internet-Suchmaschinen ersichtlich. Eine Listung auf solch einer Blacklist kann zudem dazu führen, dass Sie auch keine [[Email|E-Mails]] mehr empfangen oder senden können, da Ihr gesamtes Netzwerk und die [[IP]] als Gefährdung anderer eingestuft wird. + +### Solution_Tips + +Wenn unsicherer JavaScript-Code gemeldet wird, ist die [[Webanwendung]] eventuell anfällig für sog. [[DOMXSS-Sinks|DOMXSS]]-Angriffe. +Das Ergebnis der Untersuchung kann nur als Hinweis auf Sicherheitslücken verwendet werden. Weitere Tests sind erforderlich, um die [[Schwachstellen|Schwachstellen]] auf der Webseite zu bestätigen. + +### Link + +Schadcode-Ueber-Fremde-Quellen + +### Negative + +Unsicheren [[JavaScript]]-Code verwendet (Sources). + +### Positive + +Automatisiert wurden keine unsicheren Codebestandteile für [[DOMXSS-Sources]] erkannt. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## _RESULTS + +### NO_CONTENT + +Auf der Seite wurde kein Inhalt gefunden. + +### NO_SCRIPT_TAGS + +Der Scanner hat keine Skript-Inhalte zum Bewerten gefunden. + +### NO_SINKS_FOUND + +Es wurden keine „[[DOMXSS-Sinks]]“ gefunden. + +### NO_SOURCES_FOUND + +Es wurden keine „[[DOMXSS-Sources]]“ gefunden. + +### SINKS_FOUND + +Es wurden „[[DOMXSS-Sinks]]“ gefunden. + +### SOURCES_FOUND + +Es wurden „[[DOMXSS-Sources]]“ gefunden. diff --git a/DOMXSS.en.md b/DOMXSS.en.md new file mode 100644 index 0000000..9bdb41a --- /dev/null +++ b/DOMXSS.en.md @@ -0,0 +1,112 @@ + +# DOMXSS + +DOMXSS Scanner + +## SINKS + +### Headline + +Checking the JavaScript code for DOMXSS sinks + +### Category + +JavaScript + +### Description + +At least one code segment was found by scanning your website that may, under certain circumstances, indicate a DOM-based [https://en.wikipedia.org/wiki/Cross-site_scripting cross-site scripting vulnerability]. This segment can be a security flaw on your website. + +### Background + +[https://www.siwecos.de/wiki/Cross-Site_Scripting Cross-Site-Scripting] is a method of manipulating and infiltrating the HTML code on your website. It allows an attacker to send scripts indirectly to your visitor's browser and to execute malicious code on the side of the visitor. + +### Consequence + +[https://en.wikipedia.org/wiki/Cross-site_scripting Cross-site scripting] allows criminals to store malicious code on your website. This code can infect your visitors or customers and thus cause severe harm, for example if the malicious code leads to the installation of a [https://en.wikipedia.org/wiki/Ransomware ransomware] in their company's network. In this case you could be held liable for the damage. IT security companies could list you on their index of dangerous websites and thus prevent access to your website for security reasons. The information that your website contains/contained malicious code can still be found by search engines, even many years after the malicious code was removed. If your website is listed on such a blacklist, you may no longer be able to receive or send emails, because your entire network and the IP would be rated as a security risk to others. + +### Solution_Tips + +If unsafe JavaScript code was reported, the web application may be vulnerable to so-called DOMXSS attacks. +The check result can only be taken as an indication of security flaws. Further tests are necessary to confirm that there are vulnerabilities on the website. + +### Link + +DOMXSS vulnerability + +### Negative + +Unsafe JavaScript code used (sinks). + +### Positive + +No unsafe code components for DOMXSS sinks were recognized in an automatic check. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## SOURCES + +### Headline + +Check of JavaScript code for DOMXSS sources + +### Category + +JavaScript + +### Description + +During the check, at least one vulnerability was found on the web page that could be controlled by an external, potentially untrustworthy source. + +### Background + +A potential vulnerability for your website is caused by loading files and code from unsafe or external sources. An attacker who controls the external source could upload malicious code which could then be executed on your web page. + +### Consequence + +[https://en.wikipedia.org/wiki/Cross-site_scripting Cross-site scripting] allows criminals to store malicious code on your website. This code can infect your visitors or customers and thus cause severe harm, for example if the malicious code leads to the installation of a [https://en.wikipedia.org/wiki/Ransomware ransomware] in their company's network. In this case you could be held liable for the damage. IT security companies could list you on their index of dangerous websites and thus prevent access to your website for security reasons. The information that your website contains/contained malicious code can still be found by search engines, even many years after the malicious code was removed. If your website is listed on such a blacklist, you may no longer be able to receive or send emails, because your entire network and the IP would be rated as a security risk to others. + +### Solution_Tips + +If unsafe JavaScript code was reported, the web application may be vulnerable to so-called DOMXSS attacks. +The check result can only be taken as an indication of security flaws. Further tests are necessary to confirm that there are vulnerabilities on the website. + +### Link + +Malicious-Code-By-External-Sources + +### Negative + +Unsafe JavaScript code used (sources) + +### Positive + +No unsafe code components for DOMXSS sources were recognized in an automatic check. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## _RESULTS + +### NO_CONTENT + +The site was empty and there was nothing to scan for. + +### NO_SCRIPT_TAGS + +The scanner found no script tags to rate. + +### NO_SINKS_FOUND + +No "sinks" were found. + +### NO_SOURCES_FOUND + +No "sources" were found. + +### SINKS_FOUND + +"Sinks" were found. + +### SOURCES_FOUND + +"Sources" were found. diff --git a/Docker/Caddyfile b/Docker/Caddyfile new file mode 100644 index 0000000..7935013 --- /dev/null +++ b/Docker/Caddyfile @@ -0,0 +1,16 @@ +0.0.0.0 + +root /scanner/public + +fastcgi / 127.0.0.1:9000 php { + index index.php +} + +rewrite { + to {path} {path}/ /index.php?{query} +} + +on startup php-fpm7 + +log stdout +errors stdout diff --git a/Docker/supervisord.conf b/Docker/supervisord.conf new file mode 100644 index 0000000..17e2916 --- /dev/null +++ b/Docker/supervisord.conf @@ -0,0 +1,32 @@ +[supervisord] +nodaemon=true +loglevel=info + +[program:caddy] +command=/usr/bin/caddy --conf /etc/Caddyfile +user=root +stdout_logfile=/dev/stdout +stdout_logfile_maxbytes=0 +stderr_logfile=/dev/stderr +stderr_logfile_maxbytes=0 + +[program:redis] +command=/usr/bin/redis-server +user=root +stdout_logfile=/dev/stdout +stdout_logfile_maxbytes=0 +stderr_logfile=/dev/stderr +stderr_logfile_maxbytes=0 + +[program:laravel-worker] +process_name=%(program_name)s_%(process_num)02d +directory=/scanner +command=php artisan queue:work --sleep=3 --tries=3 +autostart=true +autorestart=true +user=root +numprocs=8 +stdout_logfile=/dev/stdout +stdout_logfile_maxbytes=0 +stderr_logfile=/dev/stderr +stderr_logfile_maxbytes=0 diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000..fd111fd --- /dev/null +++ b/Dockerfile @@ -0,0 +1,13 @@ +FROM siwecos/dockered-laravel:7.2 + +LABEL maintainer="Sascha Brendel " + +# Copy application +COPY . . +COPY .env.example .env + +# Install all PHP dependencies and change ownership of our applications +RUN composer install --optimize-autoloader --no-dev --no-interaction \ + && chown -R www-data:www-data . + +EXPOSE 80 diff --git a/HEADER.de.md b/HEADER.de.md new file mode 100644 index 0000000..307b514 --- /dev/null +++ b/HEADER.de.md @@ -0,0 +1,648 @@ + +# HEADER + +Header Scanner + +## CONTENT_SECURITY_POLICY + +### Headline + +Überprüfung der Content Security Policy (CSP) + +### Category + +Webserver + +### Description + +Die [[Content-Security-Policy]] ist eine strukturierte Vorgehensweise, welche das Injizieren und Ausführen von evtl. bösartigen Befehlen in einer [[Webanwendung]] ([[Injection|Injection-Angriffe]]) mildern soll. Es stellt über eine [[Whitelist]] dar, von welchen Quellen z. B. [[Javascript]], Bilder, Schriftarten und andere Inhalte auf Ihrer Seite eingebunden werden dürfen. + +### Background + +Content Security Policy (CSP) erfordert eine sorgfältige Abstimmung und genaue Definition des Sicherheitskonzeptes. Wenn diese Option aktiviert wurde, hat CSP erhebliche Auswirkungen auf die Art und Weise, wie der Browser die Seiten rendert (zusammensetzt). Zum Beispiel Inline [[JavaScript]] ist standardmäßig deaktiviert und muss explizit in der Policy erlaubt werden. Die CSP kann dazu beitragen, Code-Injection-Angriffe zu mildern. + +### Consequence + +Die Content-Security-Policy ist eine leistungsfähige Möglichkeit, die Sicherheit auf Webseiten zu erhöhen. Auf der anderen Seite ist es nur selten möglich, einen sicheren CSP-[[Header/DE|Header]] zu integrieren, ohne den Quellcode der Webseite zu modifizieren. + +### Solution_Tips + +Wenn die Content Security Policy nicht sicher konfiguriert ist, lädt Ihre [[Webanwendung]] eventuell Inhalte aus unsicheren Quellen nach. + +Verwenden Sie den CSP mit default-src 'none' oder 'self' und ohne 'unsafe-eval' oder 'unsafe-inline' Richtlinien. Mehr zu '''Content Security Policy''' (zu deutsch etwa "Richtlinie für die Sicherheit der Inhalte") finden Sie bei '''[https://wiki.selfhtml.org/wiki/Sicherheit/Content_Security_Policy SELFHTML >>]''' + +'''Beispiele für den [[Header/DE|Header]] der Startseite:''' + + + + + +'''Konfiguration des Webservers''' + +Wenn man seinen eigenen Webserver konfigurieren kann, was bei günstigen Hostingangeboten in aller Regel nicht der Fall ist, dann gibt es diese Einstellungsmöglichkeit über die '''Bearbeitung der .htaccess''': + + # Download: Lade Inhalte nur von Seiten, die explizit erlaubt sind + # Beispiel: Alles von der eigenen Domain erlauben, keine Externas: + + Header set Content-Security-Policy "default-src 'none'; frame-src 'self'; font-src 'self';img-src 'self' siwecos.de; object-src 'self'; script-src 'self'; style-src 'self';" + +Hier finden Sie ein Beispiel, wie eine .htaccess-Datei aussehen kann, um einen höheren Wert beim '''Header Scanner''' zu erzielen. +([[Htaccess/DE|.htaccess-Beispiel]]) + +### Link + +Content-Security-Policy-Schwachstelle + +### Negative + +Content Security Policy unsicher + +### Positive + +Eine sichere Konfiguration der Content Security Policy ([[Content-Security-Policy-Schwachstelle/DE/Background|CSP]]) wurde gefunden. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## CONTENT_TYPE + +### Headline + +Überprüfung des HTTP Content-Types + +### Category + +Webserver + +### Description + +Der Content-Type ist eine Angabe, die für gewöhnlich im Kopfbereich der Webseite, dem sogenannten [[Header/DE|Header]], untergebracht wird. Durch diese Angaben wird der Zeichensatz und der Typ des Inhalts der Seite definiert. Sollte eine Definition fehlen, wird der [[Browser]] versuchen, den Content-Type zu erraten; dies kann zu [[Schwachstellen|Sicherheitslücken]] wie [[Sniffer|Code-Page-Sniffing]] führen. Diese Angaben sind zudem wichtig, damit die Webseite in jedem [[Browser]] und auf jedem Computer einwandfrei dargestellt wird. Wenn ein Server ein Dokument an einen [https://de.wikipedia.org/wiki/User_Agent User-Agent] sendet (zum Beispiel zum [[Browser]]) ist es nützlich, im Content-Type-Feld des HTTP-Headers die Art des Dateiformates zu hinterlegen. Diese Informationen deklarieren den [https://de.wikipedia.org/wiki/Internet_Media_Type MIME-Typ] und senden entsprechend die Zeichenkodierung des Dokuments wie text/html, text/plain, etc. an den Browser. + +### Background + +Der Content-Type ist eine [https://de.wikipedia.org/wiki/Meta-Element Meta-Element-Angabe], die im Kopfbereich der Website, dem sogenannten [[Header/DE|Header]] untergebracht wird. Durch diese Angabe wird der Zeichensatz und der Typ des Inhalts der Seite definiert. Diese Angaben sind wichtig, damit die Website in jedem Browser und auf jedem Computer einwandfrei dargestellt wird. Die Einbettung des Content-Types im Quellcode ist durch eine relativ kurze Angabe möglich. Es sollte der [[UTF-8]] Zeichensatz verwendet werden. + +### Consequence + +Durch die Angabe der korrekten [[Header/DE|Header]]-Deklaration können diverse [[Cross-Site Scripting|XSS-Angriffe]] verhindert werden. Wird der verwendete [https://de.wikipedia.org/wiki/Zeichenkodierung Zeichensatz] nicht angegeben, so interpretieren manche [[Browser|Webbrowser]] den Quellcode selbst, wodurch bestimmte Angriffe möglich werden, die einen anderen Zeichensatz voraussetzen. + +### Solution_Tips + +Wenn die [[Content-Type-Nicht-Korrekt/DE|Content-Type-Angabe]] nicht korrekt konfiguriert ist, sind Angriffe auf Ihre Webseite wahrscheinlich möglich. + +Fügen Sie den entsprechenden HTTP-[[Header/DE|Header]] oder alternativ ein Tag hinzu. Bitte beachten Sie, dass im Gegensatz zu einem HTTP-[[Header/DE|Header]] leichter umgangen werden kann. + +'''text/html; charset=utf-8'''; + + + +Weiterhin muss der Server selber konfiguriert werden, damit die '''richtige charset-Information''' gesendet wird. Dazu werden entsprechende Berechtigungen benötigt, um die Änderungen am Server durchführen zu können. Weitere Informationen zu den verschiedenen Serverkonfigurationen finden Sie auf den Seiten von [https://www.w3.org/International/articles/http-charset/index.de W3.org]. + +Darüber hinaus gibt es auch die Möglichkeit die '''richtige charset-Information''' der [http://httpd.apache.org/docs/2.0/howto/htaccess.html '''.htaccess'''] zu übergeben, welche die Angaben im HTTP-[[Header/DE|Header]] überschreiben. [https://www.w3.org/International/questions/qa-htaccess-charset charset in .htaccess] + +'''In die .htaccess eintragen:''' + AddType 'text/html; charset=UTF-8' html + +Hier finden Sie ein Beispiel, wie eine .htaccess-Datei aussehen kann, um einen höheren Wert beim '''Header Scanner''' zu erzielen. +([[Htaccess/DE|.htaccess-Beispiel]]) + +### Link + +Content-Type-Nicht-Korrekt + +### Negative + +Inkorrekte HTTP Content-Type Konfiguration + +### Positive + +Die [[Content-Type-Nicht-Korrekt/DE/Background|Content Type Angabe]] ist korrekt konfiguriert. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## PUBLIC_KEY_PINS + +### Headline + +Überprüfung des Public Key Pinning (HPKP) - hat keinen Einfluß auf die Bewertung + +### Category + +Webserver + +### Description + +Mächtige Angreifer wie bspw. Geheimdienste können ggf. eine [[Digitale_Signatur|Signatur]] mit der Hilfe einer von den Benutzern akzeptierten [[Zertifizierungsstelle]] erstellen lassen. Um dies zu verhindern, kann eine Webseite definieren, dass beim ersten Aufruf des [[Zertifikate|Zertifikats]] das Zertifikat dauerhaft gespeichert wird (pinning). Mit der Hilfe von [[HTTP_Public_Key_Pinning|Key-Pinning]] wird für die von der Webseite definierten Zeit lediglich das gespeicherte [[Zertifikate|Zertifikat]] akzeptiert. + +### Background + +Einer der für Laien am schwierigsten zu konfigurierende [[Header/DE|Header]]. Besitzt man ein [[Zertifikate|SSL-Zertifikat]] kann man dem anfragenden [[Browser]] mitteilen, wie lange dieses noch gilt und einen “Schlüssel” = eine eindeutige Kennung senden. Damit kann beim erneuten Aufruf festgestellt werden, ob das [[Zertifikate|Zertifikat]] noch das zuvor angegebene [[Zertifikate|Zertifikat]] ist. Sollte ein Angreifer nun versuchen, ein gefälschtes [[Zertifikate|Zertifikat]] dem Nutzer zu unterbreiten, so wird der [[Browser|Webbrowser]] keine Daten senden und keine Informationen darstellen. Weitere Infos zu Public Key Pinning [[HTTP_Public_Key_Pinning|Public Key Pinning (HPKP)]]. + +### Consequence + +Für kleine und mittelständische Unternehmen, die Zielgruppe von SIWECOS, ist dieser [[Header/DE|Header]] zwar einsetzbar, aber kein absolutes Muss. Wird dieser Header falsch konfiguriert, steht Ihre Website für die Benutzer unter Umständen für einen langen Zeitraum nicht zur Verfügung, und zwar solange bis die korrekten [[Zertifikate|Zertifikate]] verwendet werden oder das Ablaufdatum des zuvor gesendeten Headers erreicht ist. + +### Solution_Tips + +Das Setzen des [[Public-Key-Pins-Deaktiviert/DE|Public Key Pinning]] (HPKP) ist kein absolutes Muss und wird aktuell im Siwecos-Scanner nicht gewertet. Es ist ratsam, diese nicht oder nur nach Absprache mit einem Experten zu aktivieren. + +Die [[Browser]] Mozilla, Firefox und Google Chrome richten sich nach dem [https://de.wikipedia.org/wiki/HTTP_Public_Key_Pinning RFC-7469-Standard] und ignorieren daher HPKP-[[Header/DE|Header]]. Wenn nur ein einziger Pin gesetzt ist, wird eine Fehlermeldung angezeigt. Damit die Pin-Validierung funktioniert, ist es also immer notwendig mindestens zwei gültige Public Keys bzw. einen Backup-Pin anzugeben. Interessierte sollten sich dazu an einen IT-Sicherheitsexperten oder Webentwickler wenden. + +Weiterführende Informationen finden Sie im [https://www.zdnet.com/article/google-chrome-is-backing-away-from-public-key-pinning-and-heres-why/ Artikel von ZDNET] + +'''HPKP aktivieren''' - Dieses Feature kann einfach aktiviert werden, indem ein Public-Key-Pins HTTP-[[Header/DE|Header]] beim Aufruf der Seite über [[HTTPS]] zurückgegeben wird. ([https://developer.mozilla.org/de/docs/Web/Security/Public_Key_Pinning Weitere Infos]). + + Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubdomains][; report-uri="reportURI"] + +Hier finden Sie ein Beispiel, wie eine .htaccess-Datei aussehen kann, um einen höheren Wert beim '''Header Scanner''' zu erzielen. +([[Htaccess/DE|.htaccess-Beispiel]]) + + +### Link + +Public-Key-Pins-Deaktiviert + +### Negative + +[[Public-Key-Pins-Deaktiviert/DE/Background|Public-Key-Pinning]] nicht vorhanden (Das Ergebnis fließt nicht in die Bewertung ein). + +### Positive + +[[Public-Key-Pins-Deaktiviert/DE|Public-Key-Pinning]] ist aktiviert (HPKP wird derzeit nicht überprüft). + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## REFERRER_POLICY + +### Headline + +Überprüfung der Referrer Policy + +### Category + +Webserver + +### Description + +Eine gut gesetzte Referrer Policy '''schützt die Privatsphäre''' Ihrer Webseiten-Besucher, hat aber keinen ''direkten'' Einfluss auf die Sicherheit Ihrer Webseite. + +### Background + +Eine gut gesetzte Referrer Policy '''schützt die Privatsphäre''' Ihrer Webseiten-Besucher. + +### Consequence + +Eine fehlende oder falsch gesetzte Referrer Policy ermöglicht unerwünschten benutzeridentifizierenden Informationensabfluss. + +### Solution_Tips + +Mit dem Eintrag '''Referrer Policy''' im [[Header/DE|Header]] wird geregelt, welche der Referrer-Informationen, die im ''Referer Header'' gesendet wurden, in Anfragen aufgenommen werden sollen und welche nicht. Es gibt sehr viele verschiedene Optionen, die gesetzt werden können. Neben Firefox unterstützen Chrome und Opera bereits einige Optionen dieses Header-Eintrages. Aktuell handelt es sich bei diesen Header-Einträgen um einen [https://www.w3.org/TR/referrer-policy/ Empfehlungskandidaten des W3C vom 26.01.2017]. In dem zuvor verlinkten Dokument werden die einzelnen Möglichkeiten genau beschrieben. + +'''Anmerkung zur Schreibweise:''' Die korrekte englische Schreibweise lautet '''Referrer'''. Der ursprüngliche RFC ([https://tools.ietf.org/html/rfc2068#section-14.37 RFC 2068]) enthielt jedoch versehentlich die falsche Schreibweise ''Referer'' und erhebt diesen Wortlaut damit zum Standard innerhalb von HTTP. In anderen Standards wie im DOM wird die korrekte Schreibweise verwendet. Der Webbrowser setzt, wenn ein Referrer gesetzt ist, einen eigenen Header ein, der heißt dann z. B. `Referer: google.com`. Dort ist dann Referrer falsch geschrieben, aber laut Standard richtig. + +Wir empfehlen die Einstellung des Referrer Policy Headers so restriktiv wie möglich zu gestalten, also z. B. "no-referrer" zu setzen. + +== Beispiele == + +'''Referrer Policy Definition durch Server Header:''' + # Referrer Policy + Header set Referrer-Policy "no-referrer" + +'''Referrer Policy Definition durch HTML-Code:''' + + +'''Anweisung:''' Der Wert `'''no-referrer'''` weist den Browser an, '''niemals''' ''Referer Header'' zu senden, die von Ihrer Site gestellt werden. Dazu gehören auch Links zu Seiten Ihrer eigenen Webseite. + +{| class="wikitable" style="margin:auto;" +|- style="border: 4px solid #C31622; color:#000000; background-color:#f6f6f6;" +| +Weitere nützliche Anweisungen können `'''same-origin'''`, `'''strict-origin'''` oder `'''origin-when-cross-origin'''` sein. +|} + +Der Wert `'''same-origin'''` weist den Browser an, nur ''Referer Header'' zu senden, die von Ihrer Webseite gestellt werden. Wenn das Ziel eine andere [[Domain]] ist, werden keine Referrer-Informationen gesendet. + +Der Wert `'''strict-origin'''` weist den Browser an, als ''Referer Header'' immer die Ursprungs-Domain anzugeben. + +Der Wert `'''origin-when-cross-origin'''` weist den Browser an, nur dann die vollständige Referrer-URL zu senden, wenn Sie auf der selben [[Domain]] bleiben. Sobald die Domain über [[HTTPS]] verlassen wird oder eine anderer [[Domain]] angesprochen wird, wird nur die Quell-Domain gesendet. + +Detaillierte Informationen und Beispiele (English) finden Sie bei [https://scotthelme.co.uk/a-new-security-header-referrer-policy/ Scott Helme]. + +### Link + +Referrer-Policy + +### Negative + +Referrer Policy unsicher + +### Positive + +Referrer Policy sicher + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## SET_COOKIE + +### Headline + +Überprüfung von Set-Cookie + +### Category + +Webserver + +### Description + +Cookies sollten durch das Setzen des HttpOnly und Secure flags gesichert werden um zu verhindern, dass Dritte die Informationen abgreifen oder verändern können. + +### Background + +Überprüft ob Flags zur Cookie Sicherheit gesetzt sind. + +### Consequence + +Wenn Cookies nicht abgesichert werden, können sie über einen [[Man-in-the-middle]]-Angriff verändert oder abgegriffen werden. + +### Solution_Tips + +`httpOnly`-Flag setzen, damit das Cookie nicht über [[Javascript|JavaScript]] ausgelesen werden kann. Damit schützen Sie die Session-Informationen vor Auslesen und Diebstahl, denn wer das Cookie hat gilt als [[Authentifizierung|authentifiziert]]. +`secure`-Flag setzen, damit das Cookie nicht über unverschlüsselte Verbindungen [[HTTP]] gesendet wird, sondern ausschließlich über [[HTTPS]]. + +### Link + +Set-Cookie + +### Negative + +Cookies sind nicht gesichert. + +### Positive + +Cookies sind gesichert. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## STRICT_TRANSPORT_SECURITY + +### Headline + +Überprüfung des HSTS Schutzes + +### Category + +Webserver + +### Description + +Strict-Transport-Security ([[HTTP_Strict_Transport_Security|HSTS]]) stellt sicher, dass die Webseite für eine bestimmte Zeit lediglich über [[HTTPS]] gesicherte Verbindung aufgerufen werden kann. Der Webseitenbetreiber kann diesbezüglich u. a. definieren, wie lange der Zeitinterval ist und ob diese Regelung auch für [[Domain|Subdomains]] gelten soll. + +### Background + +Der [[HTTP_Strict_Transport_Security|HSTS]] Schutz ist inaktiv, die Kommunikation zwischen Ihrer Webseite und den Besuchern kann abgehört und manipuliert werden. + +### Consequence + +Aktuell ist Ihre Website nicht gegen Nutzung eines älteren [[SSL|TLS-Standards]] (Protokoll-Downgrade-Angriffe) und Cookie-Hijacking geschützt. Dies ermöglicht Angreifern die Kommunikation Ihrer Benutzer abzuhören und diese zu manipulieren. Mit Hilfe dieser Informationen könnte ein Angreifer weitere Attacken starten oder Ihren Nutzern ungewünschte Werbung und Schadcode zusenden. Die [[HTTP_Strict_Transport_Security|HTTP-Strict-Transport-Sicherheit]] ist eine hervorragende Funktion zur Unterstützung Ihrer Seite und stärkt Ihre Implementierung von [[SSL|TLS]], indem der Benutzeragent die Verwendung von [[HTTPS]] erzwingt. + +### Solution_Tips + +Wenn die Verbindung zu Ihrer Seite ist nicht verschlüsselt ist, kann sämtliche Kommunikation zwischen Ihrer Seite und den Benutzern abgehört und manipuliert werden. + +max-age=63072000; includeSubdomains; +HTTP Strict Transport Security (HSTS) ist ein einfach zu integrierender Web-Security-Policy-Mechanismus. + + # HTTP Strict Transport Security (HSTS) aktivieren + # Pflichtangabe: "max-age" + # Optional: "includeSubDomains" + '''Header set Strict-Transport-Security "max-age=31556926; includeSubDomains"''' + +Hier finden Sie ein Beispiel, wie eine .htaccess-Datei aussehen kann, um einen höheren Wert beim '''Header Scanner''' zu erzielen. +([[Htaccess/DE|.htaccess-Beispiel]]) + +### Link + +Keine-Verschluesselung-Gefunden + +### Negative + +HSTS Schutz Fehler + +### Positive + +Ihre Webseite ist ausschließlich über das sichere [[HTTPS|HTTPS-Protokoll]] erreichbar. Kommunikation zwischen Ihrer Webseite und den Besuchern kann nicht abgehört und manipuliert werden. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## X_CONTENT_TYPE_OPTIONS + +### Headline + +Überprüfung des X-Content-Type Headers + +### Category + +Webserver + +### Description + +Die [[X-Content-Type-Options-Schwachstelle/DE/Background|X-Content-Type-Options]] Einstellungen im [[Header/DE|Header]] verhindern, dass der [[Browser]] Dateien als etwas anderes interpretiert, als vom Inhaltstyp im [[HTTP|HTTP]]-[[Header/DE|Header]] deklariert wurde. Die Headereinstellungen sind hier nicht gesetzt. + +### Background + +Es existiert nur ein definierbarer Wert '''nosniff''', dieser verhindert, dass der Internet Explorer und Google Chrome unabhängig vom deklarierten Content-Type (z. B. text/html) nach weiteren möglichen MIME-Types suchen. Für Chrome gilt dies auch für das Herunterladen von Erweiterungen. Der [[Header/DE|Headereintrag]] reduziert die Belastung durch sog. [[Drive-by-Download|Drive-by-Download-Attacken]]. Webseiten, die den Upload von Dateien unterstützen und die, wenn deren Namen geschickt gewählt wurden, vom [[Browser]] als ausführbare Datei oder dynamische [[HTML|HTML-Datei]] behandelt werden, könnten damit Ihren Rechner oder andere mit Schadcode infizieren. Weitere Informationen zu '''X-Content-Type-Options''' finden Sie im Bericht von [https://www.golem.de/news/cross-site-scripting-javascript-code-in-bilder-einbetten-1411-110264-2.html Golem.de]. + +### Consequence + +Einfach und ohne weitere Anpassungen zu implementieren. Verhindert Angriffe auf Nutzer des Internet Explorers. + +### Solution_Tips + +nosniff; + +'''Beispielcode einer .htaccess auf einem Apache Webserver''' + + + # prevent mime based attacks like drive-by download attacks, IE and Chrome + '''Header set X-Content-Type-Options "nosniff"''' + + +Hier finden Sie ein Beispiel, wie eine .htaccess-Datei aussehen kann, um einen höheren Wert beim '''Header Scanner''' zu erzielen. +([[Htaccess/DE|.htaccess-Beispiel]]) + +### Link + +X-Content-Type-Options-Schwachstelle + +### Negative + +X-Content-Type [[Header/DE|Header]] fehlt. + +### Positive + +Der [[Header/DE|HTTP-Header]] ist korrekt gesetzt. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +## X_FRAME_OPTIONS + +### Headline + +Überprüfung der HTTP-Header X-Frame Optionen + +### Category + +Webserver + +### Description + +Das Setzen von '''X-Frame-Options''' hilft dabei, Angriffe über [[Framing-Mechanismen|Framing-Mechanismen]] zu unterbinden. Dies gewährleistet bspw., dass [[Clickjacking]]-Angriffe größtenteils gemildert werden können. Darüber hinaus werden [[Downgrading_Angriffe|Downgrading-Angriffe]] wie etwa im Internet Explorer minimiert. + +### Background + +Ob einem [[Browser]] erlaubt wird, eine Seite in einem ''frame'' oder ''iframe'' darzustellen, legt dieser [[Header/DE|Headereintrag]] fest. Damit können sog. [[Clickjacking|Clickjacking-Attacken]] vermieden werde, indem sichergestellt wird, dass die Webseite nicht in einer anderen Webseite eingebettet wird. Es gibt verschiedene Werte: + +'''DENY:''' Kein Rendering der Seite, wenn sie in einem ''frame'' oder ''iframe'' geladen wird. +'''SAMEORIGIN:''' Rendering der Seite erfolgt nur, wenn der ''frame'' oder ''iframe'' innerhalb Ihrer Domain ist. +'''ALLOW-FROM DOMAIN:''' Wird hierbei explizit eine Domain angegeben, werden keine anderen Inhalte von unbekannten Sourcen gerendert bzw. dargestellt. + + +### Consequence + +Verhindert z. B. [[Clickjacking]]-Angriffe. Einfach zu implementieren und keine weiteren Anpassungen auf der Website erforderlich. + +### Solution_Tips + +Wenn gemeldet wurde, dass im [[Header/DE|HTTP-Header]] die X-Frame Optionen nicht gesetzt sind, ist Ihre Webseite nicht ausreichend gegen [[Clickjacking|Clickjacking-Angriffe]] geschützt. + +Im [[Header/DE|HTTP-Header]] X-Frame Optionen entsprechend den Bedürfnissen setzen. Die '''X-Frame-Options''' im [[HTTP]] Header kann verwendet werden, um zu bestimmen, ob ein aufrufender [[Browser]] die Zielseite in einem ,