Probleme nach Update 16.8.3.0

  • Ich betreibe mit Zeta Producer 2 Internetseiten "http://www.schuetzenkreishohenstaufen.de" und "http://www.sv-hattenhofen.de". Als ich heute früh die Seiten aktualisieren wollte, wurde mir ein Update (16.8.3.0 Express) angezeigt, welches ich nach Backup auch installiert habe. Anschließend habe ich auf beiden Seiten kleine Aktualisierungen vorgenommen. Bei der Seite des Schützenkreises funktioniert alles wie vorher, bei der Seite des SV Hattenhofen kommt nach Aufruf mit PC oder Handy nachfolgende Servermeldung: 403 - Verboten Zugriff verweigert.
    Wenn ich die Seite über Tablet aufrufe komme ich auf die Startseite, jedoch nach Akzeptieren oder Ablehnen der Cookies folgt die gleiche Meldung.

    Auf dem Server wurde bereits alles überprüft, dort ist alles okay, PHP 8.1.27 ist installiert. Der Mitarbeiter kam auch auf die Startseite, dann aber kam die Fehlermeldung. Wer kann mir weiterhelfen?

  • Hallo,

    das hat sicherlich nichts mit dem Update zu tun. Da ist irgend etwas auf dem Webserver falsch eingestellt oder der Webserver hat Probleme und das verursacht dann die 403-Fehler.

    Da müssen Sie den Provider kontaktieren.

    Freundliche Grüße
    Stefan S. (Zeta Producer-Support)

  • Ich hatte schon mit dem Provider Kontakt, bevor ich diese Meldung eingestellt habe. Es wurde wirklich alles überprüft. Ich kenne den Mitarbeiter der Fa. persönlich und ich bin überzeugt, dass wirklich alles geprüft wurde. Vor dem Update hat alles funktioniert und meine 2 HP funktioniert ja wie bisher ohne Probleme. Die 2. funktionierende Seite hat kein Cookie-Consent, es müsste evtl. an diesem liegen. Der Mitarbeiter vom Provider arbeitet auch mit Zeta und kennt sich aus. Hier die Antwort von Provider, der auf die Startseite kam (so weit komme ich dar nicht), dann aber nicht weiter:

    Hallo Herr Straub,

    Das ist mal tatsächlich ein Fall für den ZetaProducer-Support bzw. für das ZP-Forum: Zeta Producer

    Dort mal ihren Fall schildern. Am besten mit allem an was sie sich erinnern können was vorher alles geschehen bzw. geändert worden ist!

    Es hat auf jeden Fall mit dem cookie-consent zu tun: 

    Solange man hier nichts anklickt werden alle Seiten korrekt angezeigt. Nach Auswahl, egal ob ablehnen oder akzeptieren kommt der bekannte Fehler.

    Diesen kann man zurücksetzen in dem man zunächst alle Browserfenster beendet. Danach öffnet man den Browser und löscht den Browsercache, Cookies, etc.

    Nun kann man das Verhalten wieder reproduzieren. 

    Auf dem Webserver war PHP 7.3.33 installiert. Ich hab das jetzt auf PHP 8.1.27 upgedatet, ändert aber nichts am Verhalten.

    Mit freundlichen Grüßen

    Dirk Passek

    Infrastruktur

    Scriba AktiengesellschaftWertstrasse 8

    D-73240 Wendlingen am Neckar

    Tel: +49 7024 9772660

    Fax: +49 7024 97726699

    E-Mail: dirk.passek@scriba-ag.de

    Web: http://www.scriba-ag.de/

    Für den Notfall, wie komme ich zu der Version vor dem Update?

    Mit freundlichen Grüßen
    Günther Straub

  • Sobald der Webserver einen Request mit entsprechendem Cookie erhält sendet er den 403 Fehler. Warum er das macht erschließt sich mir nicht. Geben Sie das folgende bitte an den Provider, dann kann er mir ggf. erklären, warum das so ist und warum der Fehler bei uns liegen soll:

    Code
    curl -I --cookie "zp_consent=%7B%22zp_consent_all%22%3Afalse%2C%22zp_consent_yt%22%3Afalse%2C%22zp_consent_vimeo%22%3Afalse%2C%22zp_consent_gmaps%22%3Afalse%2C%22zp_consent_ga%22%3Afalse%2C%22zp_consent_gtm%22%3Afalse%2C%22zp_consent_googlefonts%22%3Afalse%2C%22zp_consent_googlerecaptcha%22%3Afalse%2C%22zp_consent_zp%22%3Atrue%7D" https://www.sv-hattenhofen.de/                        
    
    HTTP/2 403 
    content-length: 1244
    content-type: text/html
    server: Microsoft-IIS/10.0
    x-powered-by: ASP.NET
    x-powered-by-plesk: PleskWin
    date: Wed, 28 Feb 2024 17:15:44 GMT

    Freundliche Grüße
    Stefan S. (Zeta Producer-Support)

  • Hallo Herr Stefan S.,

    vom Provider erhielt ich nachstehende Antwort:

    Hallo Herr Straub,

    hab mit dem Support-Chat des Hosters gerade das Problem lokalisieren können:

    Auf der Website war eine "Web Application Firewall (kurz WAF)" aktiviert.

    Diese habe ich jetzt auf "Detection_only" eingestellt. Somit läuft jetzt ihre Website wieder normal. Im Logging der WAF wird folgendes zurückgegeben:

    ######################

    12033618215071403953 77.189.109.168 80 127.0.0.1 80

    --23480000-B--

    GET /assets/consentsettings.json?_=1709196445452 HTTP/1.1

    Connection: close

    Accept: application/json, text/javascript, */*; q=0.01

    Accept-Encoding: gzip, deflate, br, zstd

    Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7

    Cookie: zp_consent_denied=false; zp_consent=%7B%22zp_consent_all%22%3Atrue%2C%22zp_consent_yt%22%3Atrue%2C%22zp_consent_vimeo%22%3Atrue%2C%22zp_consent_gmaps%22%3Atrue%2C%22zp_consent_ga%22%3Atrue%2C%22zp_consent_gtm%22%3Atrue%2C%22zp_consent_googlefonts%22%3Atrue%2C%22zp_consent_googlerecaptcha%22%3Atrue%2C%22zp_consent_zp%22%3Atrue%7D

    Host: http://www.sv-hattenhofen.de/

    Referer: https://www.sv-hattenhofen.de/


    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

    sec-ch-ua: "Chromium";v="122", "Not(A:Brand";v="24", "Google Chrome";v="122"

    x-requested-with: XMLHttpRequest

    sec-ch-ua-mobile: ?0

    sec-ch-ua-platform: "Windows"

    sec-fetch-site: same-origin

    sec-fetch-mode: cors

    sec-fetch-dest: empty

    --23480000-F--

    HTTP/1.1 500 Internal Server Error

    --23480000-H--

    Message: Warning. Pattern match "(?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\s*?\\(\\s*?space\\s*?\\(|,.*?[)\\da-f\"'`][\"'`](?:[\"'`].*?[\"'`]|(?:\\r?\\n)?\\z|[^\"'`]+)|\\Wselect.+\\W*?from))" at REQUEST_COOKIES:zp_consent. [file "C:\/Program Files (x86)/Plesk/ModSecurity/rules/modsecurity_crs-plesk/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "690"] [id "942200"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: ,\x22zp_consent_yt\x22:true,\x22zp_consent_vimeo\x22:true,\x22zp_consent_gmaps\x22:true,\x22zp_consent_ga\x22:true, found within REQUEST_COOKIES:zp_consent: {\x22zp_consent_all\x22:true,\x22zp_consent_yt\x22:true,\x22zp_consent_vimeo\x22:true,\x22zp_consent_gmaps\x22:true,\x22zp_consent_ga\x22:true,\x22zp_consent_gtm\x22:true,\x22zp_consent_googlefonts\x22:true,\x22zp_consent_googlerecaptcha\x22:true,\x22zp_consent_zp\x22:true}"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [t

    Message: Warning. Pattern match "(?i:[\"'`]\\s*?(?:(?:n(?:and|ot)|(?:x?x)?or|between|\\|\\||and|div|&&)\\s+[\\s\\w]+=\\s*?\\w+\\s*?having\\s+|like(?:\\s+[\\s\\w]+=\\s*?\\w+\\s*?having\\s+|\\W*?[\"'`\\d])|[^?\\w\\s=.,;)(]++\\s*?[(@\"'`]*?\\s*?\\w+\\W+\\w|\\*\\s*?\\w+\\W+[\"'`])|(?:unio ..." at REQUEST_COOKIES:zp_consent. [file "C:\/Program Files (x86)/Plesk/ModSecurity/rules/modsecurity_crs-plesk/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "751"] [id "942260"] [msg "Detects basic SQL authentication bypass attempts 2/3"] [data "Matched Data: \x22:true,\x22z found within REQUEST_COOKIES:zp_consent: {\x22zp_consent_all\x22:true,\x22zp_consent_yt\x22:true,\x22zp_consent_vimeo\x22:true,\x22zp_consent_gmaps\x22:true,\x22zp_consent_ga\x22:true,\x22zp_consent_gtm\x22:true,\x22zp_consent_googlefonts\x22:true,\x22zp_consent_googlerecaptcha\x22:true,\x22zp_consent_zp\x22:true}"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [ta

    Message: Warning. Operator GE matched 5 at TX:anomaly_score. [file "C:\/Program Files (x86)/Plesk/ModSecurity/rules/modsecurity_crs-plesk/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "94"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 10)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"]

    Message: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "C:\/Program Files (x86)/Plesk/ModSecurity/rules/modsecurity_crs-plesk/rules/RESPONSE-980-CORRELATION.conf"] [line "92"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 10 - SQLI=10,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 0, 10, 0, 0"] [ver "OWASP_CRS/3.3.5"] [tag "event-correlation"]

    Apache-Handler: IIS

    Stopwatch: 1709196445517933 15615 (- - -)

    Stopwatch2: 1709196445517933 15615; combined=31230, p1=0, p2=0, p3=0, p4=0, p5=15615, sr=0, sw=0, l=0, gc=15615

    Producer: ModSecurity for IIS (STABLE)/2.9.7 (http://www.modsecurity.org/); OWASP_CRS/3.3.5.

    Server: ModSecurity Standalone

    Engine-Mode: "DETECTION_ONLY"

    --23480000-Z--


    ######################

    Könnten Sie das dem Zeta Support nochmals zukommen lassen. Ich selbst steig bei dieser Log-Meldung aus.

    Aber irgendein Inhalt läuft bei der WAF auf einen Fehler!

    Grundsätzlich könnten wir die WAF so belassen. Die Website ist dann halt besser hackbar.

    Ich finde, es wäre besser wenn wir das Problem finden und ausmerzen könnten.

    Mit freundlichen Grüßen

    Dirk Passek

    Infrastruktur

    Scriba Aktiengesellschaft

    Wertstrasse 8

    D-73240 Wendlingen am Neckar

    Tel: +49 7024 9772660

    Fax: +49 7024 97726699

    E-Mail: dirk.passek@scriba-ag.de

    Web: http://www.scriba-ag.de/

  • Na prima.

    Abschließend ist also zu sagen, dass dies absolut nichts mit dem Update zu tun hatte, sondern nur daran lag, dass ein Sicherheitstool des Providers wg. Fehlalarm den Zugang blockiert hatte.

    Freundliche Grüße
    Stefan S. (Zeta Producer-Support)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!