Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 40 von 63

Thema: Fehler 403 Forbidden durch Cookiebar AH10508: Unsafe URL with %3f URL rewritten

  1. #1
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard Fehler 403 Forbidden durch Cookiebar AH10508: Unsafe URL with %3f URL rewritten

    Ich habe ein durch die Cookiebar geblocktest iframe. Seit kurzem bekomme ich statt des iframes eine Fehlermeldung "Forbidden You don't have permission to access this resource. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request."

    Es scheint an der Cookiebar zu liegen. Im Protokoll des Webservers erscheint die Fehlermeldung "AH10508: Unsafe URL with %3f URL rewritten without UnsafeAllow3F".

    Die URL, die den Fehler verursacht ist wohl:
    HTML-Code:
    https://ferienhaus-schwarzwald-todtnauberg.de/cookiebar/block/de/20?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.php%3Fpropid%3D155937%5B%26%5Dlang%3D%5B%26%5Dreferer%3Dwebseite-leer
    diese wird irgendwie automatisch durch Cookiebar erzeugt:
    PHP-Code:
    <iframe data-ccb-id="20" src="/cookiebar/block/de/20?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.php%3Fpropid%3D144283%26lang%3D%26referer%3Dwebseite-leertest" data-src="https://beds24.com/booking2.php?propid=144283&amp;lang=&amp;referer=webseite-leertest" width="1100" height="100%" scrolling="no" style="max-width:100%;border:none;overflow:auto;"></iframe
    Ich versehe nur nicht warum. Der eigentliche HTML Code für den iframe wird durch ein PHP Script generiert. Auf der HTML Seite selbst greift dann dort nochmal die Cookiebar ein. Der Zusammenhang ist mir leider nicht klar. Ich vermute irgend ein Java Skript? Aber welche Einstellung, damit Cookiebar dort eingreift?

    falsch: https://ferienhaus-schwarzwald-todtn...ropid%3D155937

    gut: https://ferienhaus-schwarzwald-todtn.../propid=155937

    Scheinbar liegt es an der seltsamen Umschlüsselung der gblockten Ziel-URL durch Cookiebar. Wie kann ich hier eingreifen und z.b. diese Unschlüsselung abschalten. Wenn ich die "%3A" usw. durich die normalen ASCII Zeichen ersetzte funktioniert wieder alles.
    Geändert von d003232 (13.07.2024 um 10:53 Uhr)

  2. #2
    Alter Contao-Hase
    Registriert seit
    24.02.2021.
    Beiträge
    1.473
    Partner-ID
    11715
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Sehr spezifische (Auf Google findet man sicher etwas) oder sehr unspezifische Fehlermeldung deinerseits (Settings? Contao Version? Screenshots? Mehr URLS? Genaue Fehlerbeschreibung? Bitte mehr Informationen wenn du kostenlosen Support willst -> Man für dich dein Problem recherchieren soll).


    • Was hast du versucht und wie sind deine Einstellungen in der Cookiebar?
    • Was erwartest du?
    • Was ist das genaue Problem mit der URL? Du hast hier mehrere gepostet?


    Du kannst nicht in die Generierung eingreifen, ohne dass du hier die Klassen der Cookiebar überschreibst.

  3. #3
    Alter Contao-Hase
    Registriert seit
    24.02.2021.
    Beiträge
    1.473
    Partner-ID
    11715
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Nur zur Nachverfolgung, wurde auch 2 Stunden nach Erstellung des Threads auf GitHub gepostet:
    https://github.com/oveleon/contao-cookiebar/issues/212

  4. #4
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    @d003232: du hast in deinem Github Ticket auch das PHP Script veröffentlich. Dieses PHP Script solltest du umgehend von der Website in dieser Form entfernen, da du damit eine XSS Sicherheitslücke eingebaut hast. // achso, die Nutzung von $_GET ist vermutlich nur für {{file::*}}, dann ist es weitgehend ok.

    Davon abgesehen scheint der 403 Fehler von deinem Web Server zu kommen. Du musst daher bei deinem Web Server prüfen, warum es dazu kommt.
    Geändert von Spooky (14.07.2024 um 09:46 Uhr)
    » sponsor me via GitHub or Revolut

  5. #5
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Danke für die Anregungen. Ein klein wenig bin ich weiter gekommen. Offenbar liegt es an der Umschlüsslung von "?" in "%3F" in der URL durch cookiebar. Aber warum schreibt cookiebar das "?" in der URL überhaupt um?

    So funktioniert die URL nicht und führt zum 403 Fehler:
    ferienhaus-schwarzwald-todtnauberg.de/cookiebar/block/de/16?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.ph p%3Fpropid%3D155937%26lang%3D%26referer%3Dwebseite-leer

    so funktioniert die URL:
    ferienhaus-schwarzwald-todtnauberg.de/cookiebar/block/de/16?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.ph p?propid%3D155937%26lang%3D%26referer%3Dwebseite-leer

    Im Server Log von Strato finde ich einen dazu passenden Fehler: AH10508: Unsafe URL with %3f URL rewritten without UnsafeAllow3F

    Nun ist mir nicht klar:
    1. Liegt es an einer Webserver Einstellung bei Strato, d.h. ich muss irgendwie ein "UnsafeAllow3F" aktivieren?
    2. oder müsste cookiebar einfach das "?" in der URL lassen und dieses nicht umschreiben?

    Ansonsten:
    Contao 5.3.11
    cookiebar 2.1.1

    Ich bin verunsichert, ob es vielleicht noch durch eine veraltetet Datei aus Contao 4.x kommt? Gleichzeitig tritt der "forbidden Fehler" nicht zu 100% auf. Machmal geht es einfach.

  6. #6
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Der Fehler kommt wie gesagt vom Web Server direkt und hat nichts mit Contao oder PHP zu tun.
    » sponsor me via GitHub or Revolut

  7. #7
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Zitat Zitat von Spooky Beitrag anzeigen
    Der Fehler kommt wie gesagt vom Web Server direkt und hat nichts mit Contao oder PHP zu tun.
    Dass der Webserver den 403 Fehler meldet habe ich verstanden.

    Was mir nicht klar ist, ist warum cookiebar das "?" in der URL umschlüsselt? Wenn das nicht passieren wäre, würde der Webserver auch keinen 403 Fehler erzeugen. Ich kann z.B. das "%3f" in der url im Firefox Debugger manuell wieder auf 2?" abändern. Dann wird das iframe wieder ordentlich geladen.

    Fehler.jpg
    Fehler ohne 3f.jpg
    Geändert von d003232 (14.07.2024 um 16:11 Uhr)

  8. #8
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Das zweite Fragezeichen (also der gesamte Wert des "redirect" Parameters) muss encodet sein, andernfalls wäre es eine ungültige URL.
    » sponsor me via GitHub or Revolut

  9. #9
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Zitat Zitat von Spooky Beitrag anzeigen
    Das zweite Fragezeichen (also der gesamte Wert des "redirect" Parameters) muss encodet sein, andernfalls wäre es eine ungültige URL.
    Hmm. Warum kommt es dann zum 403 Fehler, wenn das zweite Fragezeichen encodet ist? Wenn es nicht entcodet ist funktioniert alles.

    Liegt das an den Einstellungen des Webservers? Wo könnte ich da etwas einstellen? Eigentlich bekommt doch der Webserver gar nicht direkt den redirect Parameter?

  10. #10
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Zitat Zitat von d003232 Beitrag anzeigen
    Eigentlich bekommt doch der Webserver gar nicht direkt den redirect Parameter?
    Doch, natürlich, der Web Server bekommt die URL als Erstes.
    » sponsor me via GitHub or Revolut

  11. #11
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Ich bin einen kleinen Schritt weiter, brauche aber nochmal Hilfe:

    1. Ursache scheint ein Sicherheitsupdate zum 1.7.2024 im Apache Server 2.4.59 zu sein, der Rewrite Rules für das '?' (%3F) nicht mehr erlaubt:
      https://www.cve.org/CVERecord?id=CVE-2024-38474
    2. Um der Umschreibung zu erlauben, kann man das Rewrite Flag UnsafeAllow3F setzen (oder vermutlich hoffen, dass de Provider ein Update von Apache auf 2.4.60 vornimmt?):
      https://httpd.apache.org/docs/curren...nsafe_allow_3f


    Wer weiß, in welcher Rewrite Rule ich das UnsafeAllow3f setzten muss, damit das Encoding von cookiebar wieder funktioniert. Welche Rewrite Rule nutzt cookiebar?
    Geändert von d003232 (15.07.2024 um 07:14 Uhr)

  12. #12
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Hm, ich denke du bist schon auf Apache 2.4.60 und deswegen kommt es zu diesem Fehler. So lese ich das zumindest.
    » sponsor me via GitHub or Revolut

  13. #13
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Zitat Zitat von Spooky Beitrag anzeigen
    Hm, ich denke du bist schon auf Apache 2.4.60 und deswegen kommt es zu diesem Fehler. So lese ich das zumindest.
    phpinfo sagt: "SERVER_SOFTWARE Apache/2.4.59 (Unix)" / Provider ist Strato

    Ich hätte es so verstandem, dass das Sicherheitsupdate für 2.4.59 gilt, um das Sicherheitsrisiko zu patchen. Mit 2.4.60 wäre das grundsätzliche Problem dann behoben, so dass man den Workaround mit UnsafeAllow3F nicht mehr bräuchte?

  14. #14
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    So interpretiere ich das zumindest nicht. Die Sicherheitslücke betrifft alle Apache 2.4 Versionen bis inkl. 2.4.59. Die Sicherheitslücke wurde in allen Apache Versionen mit Build Date am or nach dem 4. Juli geschlossen. Seitdem tritt das Problem in diesen Apache Versionen auf, da man nun immer UnsafeAllow3F braucht.

    Angeblich ab 2.4.61 dann aber nicht mehr, laut einem Stackoverflow Post, das konnte ich aber nicht unabhängig bestätigen.

    Poste mal deine .htaccess
    Geändert von Spooky (15.07.2024 um 09:02 Uhr)
    » sponsor me via GitHub or Revolut

  15. #15
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Zitat Zitat von Spooky Beitrag anzeigen
    Poste mal deine .htaccess
    PHP-Code:
    # Zugriff auf .htaccess und .htpasswd verbieten, falls in Benutzung
    <FilesMatch "(\.htaccess)">
      
    Order deny,allow
      Deny from all
    </FilesMatch>

    <
    IfModule mod_rewrite.c>
        
    RewriteEngine On

        
    <IfModule mod_headers.c>
            
    # Assets in /assets and /bundles either contain a hash in their filename
            # or are called with a ?version suffix, therefore cache them for 1 year.
            
    RewriteRule ^(assets|bundles)/ - [ENV=CONTAO_ASSETS:true]
            
    Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

            
    # Allow CORS on the Contao TinyMCE skin.
            
    RewriteRule ^assets/tinymce4/js/skins/contao/fonts/ - [ENV=CONTAO_TINYMCE_SKIN:true]
            
    Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN
        
    </IfModule>

        
    # Determine the RewriteBase automatically and set it as environment variable.
        # If you are using Apache aliases to do mass virtual hosting or installed the
        # project in a subdirectory, the base path will be prepended to allow proper
        # resolution of the index.php file and to redirect to the correct URI. It will
        # work in environments without path prefix as well, providing a safe, one-size
        # fits all solution. But as you do not need it in this case, you can comment
        # the following 2 lines to eliminate the overhead.
        
    RewriteCond %{REQUEST_URI}::$^(/.+)/(.*)::\2$
        
    RewriteRule ^(.*) - [E=BASE:%1]

        
    # Sets the HTTP_AUTHORIZATION header removed by Apache
        
    RewriteCond %{HTTP:Authorization} .
        
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

        
    # Redirect to URI without front controller to prevent duplicate content
        # (with and without `/index.php`). Only do this redirect on the initial
        # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
        # endless redirect loop (request -> rewrite to front controller ->
        # redirect -> request -> ...).
        # So in case you get a "too many redirects" error or you always get redirected
        # to the start page because your Apache does not expose the REDIRECT_STATUS
        # environment variable, you have 2 choices:
        # - disable this feature by commenting the following 2 lines or
        # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
        #   following RewriteCond (best solution)
        
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
        
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$[R=301,L]

        
    # If the requested filename exists, simply serve it.
        # We only want to let Apache serve files and not directories.
        
    RewriteCond %{REQUEST_FILENAME} -f
        RewriteRule 
    ^ - [L]

        
    # Rewrite all other queries to the front controller.
        
    RewriteRule ^ %{ENV:BASE}/index.php [L]
    </
    IfModule>

    <
    IfModule !mod_rewrite.c>
        <
    IfModule mod_alias.c>
            
    # When mod_rewrite is not available, we instruct a temporary redirect of
            # the start page to the front controller explicitly so that the website
            # and the generated links can still be used.
            
    RedirectMatch 302 ^/$ /index.php/
            
    # RedirectTemp cannot be used instead
        
    </IfModule>
    </
    IfModule

  16. #16
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Ersetze

    RewriteRule ^ %{ENV:BASE}/index.php [L]

    mit

    RewriteRule ^ %{ENV:BASE}/index.php [L,UnsafeAllow3F]
    » sponsor me via GitHub or Revolut

  17. #17
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Zitat Zitat von Spooky Beitrag anzeigen
    Ersetze

    RewriteRule ^ %{ENV:BASE}/index.php [L]

    mit

    RewriteRule ^ %{ENV:BASE}/index.php [L,UnsafeAllow3F]
    Die Verwendung des Flags scheint grundsätzlich zu einem 500er Fehler des Webservers zu führen. Ich vermute, dass der Parameter aktuell bei Strato nicht erlaubt ist?

    Nun habe ich dreimal versucht, den Support von Strato zu erreichen. Tatsächlich dreimal in weniger als 60 Sekunden durchgekommen ... nur versuch das Problem mal jemandem zu erklären, der im First Level Suport von Webservertechnik quasi nichts versteht.

  18. #18
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Falls es dem Support hilft: einfach nur erklären, dass URLs wie
    Code:
    https://ferienhaus-schwarzwald-todtnauberg.de/?foo=%3F
    aktuell nicht funktionieren.
    » sponsor me via GitHub or Revolut

  19. #19
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Zitat Zitat von d003232 Beitrag anzeigen
    Die Verwendung des Flags scheint grundsätzlich zu einem 500er Fehler des Webservers zu führen.
    Poste die .htaccess nach der Änderung.
    » sponsor me via GitHub or Revolut

  20. #20
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Zitat Zitat von Spooky Beitrag anzeigen
    Poste die .htaccess nach der Änderung.
    Nein, kein Tippfehler :-)

    PHP-Code:
        RewriteRule ^ %{ENV:BASE}/index.php [L,UnsafeAllow3F
    Die Idee mit dem kleinen Beispiellink https://ferienhaus-schwarzwald-todtnauberg.de/?foo=%3F ist gut.

  21. #21
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Zumindest in meinem lokalen Apache 2.4.61 konnte ich das Problem nicht nachstellen. Leider habe ich (für Windows) keinen Download für 2.4.60 oder 2.4.59.1 gefunden um zu verifizieren, dass das Problem dort tatsächlich auftritt.
    Geändert von Spooky (15.07.2024 um 12:33 Uhr)
    » sponsor me via GitHub or Revolut

  22. #22
    Contao-Nutzer
    Registriert seit
    22.04.2013.
    Beiträge
    131

    Standard

    Leider dauert es bei Strato mehrere Stunden, bis man den aktuelle Errorlog des Webservers sieht. Hier nun das Ergebnis von gestern:
    PHP-Code:
    home/strato/http/premium/rid/00/00/xxxxxxxx/htdocs/xxxxxxxxxxxx/contao-prod/public/.htaccessRewriteRuleunknown flag 'UnsafeAllow3F' 
    Das bedeutet ich muss auf die Antwort des Strato Supports warten, bis ich das neue rewrite flag UnsafeAllow3f in der .htaccess setzen kann.

    Ich melde mich, sobald ich Neues habe. Bis dahin nehme ich meine iframes erst mal aus der cookiebar raus, damit mein Buchungsformular wieder nutzbar wird.

  23. #23
    Contao-Nutzer
    Registriert seit
    30.03.2010.
    Beiträge
    33

    Standard Vielen Dank für die Nachrichten, wir scheinen den gleichen Server zu benutzen

    Leider kann ich nicht wirklich helfen, da ich keinen Zugang zum Strato Vertrag habe. Alles was mit FTP zu tun hat, kann ich aber testen.

  24. #24
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    @eisensau: einfach an eine URL einer auf Strato gehosteten Contao 4+ Seite ?foo=%3F anhängen. Wenn kein 403 Fehler vom Server kommt, bist du nicht betroffen.
    » sponsor me via GitHub or Revolut

  25. #25
    Contao-Nutzer
    Registriert seit
    30.03.2010.
    Beiträge
    33

    Standard

    Da war ich etwas sparsam mit den Informationen.
    Ich habe gestern aufgrund des gleichen Problems die Cookiebar für die Youtube Videos abgeschaltet.

  26. #26
    Contao-Nutzer
    Registriert seit
    16.07.2024.
    Beiträge
    6

    HTML TYPO3 Community auch von %3F Problem betroffen - Lösung in Sicht

    FYI: Die TYPO3 Community ist von diesem Problem ebenfalls betroffen. Danke Euch für die Insights hier.
    Ein Benutzer bei uns im TYPO3 Community Hub hat nun folgendes geteilt:
    Antwort vom Support eben: Problem ist bekannt und soll heute Abend spätestens Morgen früh behoben sein.
    Quelle: https://forum.t3academy.de/d/507-neu...n-error-403/22

  27. #27
    Contao-Nutzer
    Registriert seit
    16.07.2024.
    Beiträge
    6

    HTML

    Aus einem Thread im TYPO3 Slack Channel #typo3-cms:
    Update vom STRATO Service
    Wir verweisen auf Schwachstellenbeschreibung CVE-2024-38474 (https://www.cve.org/CVERecord?id=CVE-2024-38474). Dieses Update wird generell auf allen gängigen Apache Instanzen installiert werden.
    Aus Sicherheitsgründen werden wir die unsichere Methode die Typo3 verwendet auf den Hostsystemen nicht wieder freigeben. Wir bitten Sie ggfs. den Entwickler von Typo3 zu Kontaktieren und Ihn auf die Schwachstelle hinzuweisen. Wir empfehlen ausdrücklich keine Modifikationen die dies umgeht umzusetzen, weil Sie dadurch angreifbar werden.
    Quelle: https://typo3.slack.com/archives/C02...&cid=C025BQLFA

    Das merkwürde daran ist, dass das Problem ja laut CVE-2024-38474 in Apache 2.4.60+ behoben ist. Benutzer berichten, dass ihre betroffenen Instanzen noch Apache 2.4.59 nutzen.
    image.png

    Betroffene STRATO-Kunden sollten also darum bitten, Apache zu aktualisieren.
    Geändert von ErHaWeb (17.07.2024 um 07:49 Uhr)

  28. #28
    Alter Contao-Hase
    Registriert seit
    24.02.2021.
    Beiträge
    1.473
    Partner-ID
    11715
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Wenn man nicht im Typo3 Slack angemeldet ist, kann man dies leider nicht lesen

    Wenn Nutzer von 2.4.59 berichten, evtl. gab es hier einen Fix vom Provider (STRATO) selbst? (Ähnlich wie beim extended Support)

  29. #29
    Wandelndes Contao-Lexikon Avatar von tab
    Registriert seit
    22.10.2013.
    Beiträge
    10.259
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Zitat Zitat von ErHaWeb Beitrag anzeigen
    Aus einem Thread im TYPO3 Slack Channel #typo3-cms:

    Quelle: https://typo3.slack.com/archives/C02...&cid=C025BQLFA

    Das merkwürde daran ist, dass das Problem ja laut CVE-2024-38474 in Apache 2.4.60+ behoben ist. Benutzer berichten, dass ihre betroffenen Instanzen noch Apache 2.4.59 nutzen.
    image.png

    Betroffene STRATO-Kunden sollten also darum bitten, Apache zu aktualisieren.
    Klar, die TYPO3-Entwickler und auch andere darum zu bitten, die Schwachstelle in Apache zu umgehen, die Apache bereits behoben hat, ist ein netter, wenn auch recht plumper Versuch davon abzulenken, dass man es selbst schlicht nicht schafft, das entsprechende Sicherheits-Update für Apache schnell genug einzuspielen. Wenn das die beste Lösung wäre, dann hätten sich die Apache-Entwickler das Sicherheits-Update sparen können.

    Tritt der Fehler bei Ionos auch auf oder sind die mit dem Update schon durch?

  30. #30
    Contao-Nutzer
    Registriert seit
    16.07.2024.
    Beiträge
    6

    Standard

    Wenn man nicht im Typo3 Slack angemeldet ist, kann man dies leider nicht lesen
    Schon klar, die Quellenangabe ist nur für diejenigen gedacht, die in direkten Kontakt mit "Leidensgenossen" der TYPO3 Community treten wollen und sich dort im Slack registrieren.
    Das ist natürlich ein Aufwand den nicht jeder betreiben will. Aber hey, lieber eine Quelle zu viel als zu wenig

    Hier habe ich weitere Interessante Infos gefunden:
    https://stackoverflow.com/questions/...-unsafeallow3f
    The issue here is not question marks in URLs as such. It is url-encoded question marks in URLs that are used for serving static files.

    Bad version:
    example.com/images?route=/cats/long-hair%3fsize=large
    example.com/login?returnto=/cats/long-hair%3fsize=large

    Good versions:
    example.com/images/cats/long-hair?size=large
    example.com/login?returnto=/cats/long-hair&returntoparams=size%3dlarge
    Bei uns wird aktuell noch versucht herauszufinden, wer für die Lösung des Problems verantwortlich ist.

    Zitat Mathias Brodala aus dem Slack Channel:
    Die schlechte Version in dem Beispiel auf StackOverflow ist an sich nicht schlecht. Das Schlimme daran ist, dass es nichts gibt, was die Integrität von route / returnto sicherstellt. So kann jeder Client den Wert des Parameters manipulieren und ihn frei ändern. Dies wird normalerweise durch authentifizierte Hashes, Token usw. verhindert. Und TYPO3 tut das AFAIK. Daher ist es IMO ziemlich sinnlos, URLs mit einem verschlüsselten Fragezeichen selbst zu verweigern.

  31. #31
    Alter Contao-Hase
    Registriert seit
    24.02.2021.
    Beiträge
    1.473
    Partner-ID
    11715
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Zitat Zitat von ErHaWeb Beitrag anzeigen
    Schon klar, die Quellenangabe ist nur für diejenigen gedacht, die in direkten Kontakt mit "Leidensgenossen" der TYPO3 Community treten wollen
    Slack ist ein flüchtiger Speicher - Forumsbeiträge können schneller gefunden werden und die Informationen stehen bereit.
    Selbes Thema mit GitHub Issues - Alle Informationen stehen im Forum mit Link -> Dann wird das Issue halt ignoriert, bis alle Informationen im Issue stehen - Man muss ja nicht für jeden recherchieren und den Extra-Aufwand betreiben

  32. #32
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Zitat Zitat von ErHaWeb Beitrag anzeigen
    Das merkwürde daran ist, dass das Problem ja laut CVE-2024-38474 in Apache 2.4.60+ behoben ist.
    Siehe mein vorheriger Post. Mit Apache 2.4.60 wurde UnsafeAllow3F eingeführt - dieses Feature, also der Patch für die Sicherheitslücke, wurde allerdings auch in alten Versionen über neuere Builds gepatched.

    Der Fehler liegt nicht bei Strato selbst. Das Problem ist die Art und Weise wie Apache diese Sicherheitslücke handhabt. Meiner Meinung nach muss Apache hier zurück rudern und eine andere Lösung finden.
    » sponsor me via GitHub or Revolut

  33. #33
    Alter Contao-Hase
    Registriert seit
    24.02.2021.
    Beiträge
    1.473
    Partner-ID
    11715
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Nur mal zur Nachverfolgung:
    Hier wird das Fragezeichen angehängt:
    https://github.com/oveleon/contao-co...tener.php#L377

    Gestern habe ich schon nachgeschaut, man müsste es umbauen, damit es auch ohne gehen würde, dann würde innerhalb des IFrames aber auch nicht mehr die URL erhalten werden können... das kommt noch aus Anfängen der Cookiebar.
    Ist nun halt die Frage ob hier Strato schuld ist, Apache es schon behoben hat oder nicht?

  34. #34
    Alter Contao-Hase
    Registriert seit
    24.02.2021.
    Beiträge
    1.473
    Partner-ID
    11715
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Oder anders gesagt:

    Wenn es schon behoben wurde in Apache 2.4.61... Dies aber auftritt, da Hoster wie STRATO einfach zu schnell patchen und dann auf einer Kaffeefahrt sind (So schnell geht günstig, Faster. Better. Strato, So schnell geht das), lohnt sich der Aufwand des Umbaus?

  35. #35
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Soweit ich das verstehe wird das Problem in jeder Apache Version auftreten (also in allen Versionen wo UnsafeAllow3F unterstützt ist).

    Contao selbst ist davon auch betroffen, nicht nur Extensions.
    » sponsor me via GitHub or Revolut

  36. #36
    Wandelndes Contao-Lexikon Avatar von tab
    Registriert seit
    22.10.2013.
    Beiträge
    10.259
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Das heißt, das Problem ist derzeit nur dadurch behoben, dass diese URLs einfach per Default nicht mehr genutzt werden können? Und wer dann meint, dass seine Anwendung selbst die Angriffsmöglichkeiten zuverlässig verhindert - oder dass ihm die Sicherheit egal ist, der kann dann das Flag setzen und gut ist (oder eben auch nicht)? Sprich, man überträgt die Verantwortung dafür dem Programmierer und/oder Anwender der Anwendung (hier TYPO3, Contao, ...)?

  37. #37
    Contao-Nutzer
    Registriert seit
    16.07.2024.
    Beiträge
    6

    Standard

    Ja, genau so würde ich es auch zusammenfassen nach aktuellem Wissensstand.

    Im Fall von STRATO kommt allerdings erschwerend hinzu, dass das Flag "UnsafeAllow3F" nicht gesetzt werden darf > Error 500
    https://community.contao.org/de/show...ten#post586344
    Geändert von ErHaWeb (17.07.2024 um 09:54 Uhr)

  38. #38
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Zitat Zitat von tab Beitrag anzeigen
    Das heißt, das Problem ist derzeit nur dadurch behoben, dass diese URLs einfach per Default nicht mehr genutzt werden können?
    Man muss die jeweilige Applikation umschreiben, bspw. auf base64 encoded URLs (wäre mein Ansatz).


    Zitat Zitat von tab Beitrag anzeigen
    Und wer dann meint, dass seine Anwendung selbst die Angriffsmöglichkeiten zuverlässig verhindert - oder dass ihm die Sicherheit egal ist, der kann dann das Flag setzen und gut ist (oder eben auch nicht)? Sprich, man überträgt die Verantwortung dafür dem Programmierer und/oder Anwender der Anwendung (hier TYPO3, Contao, ...)?
    Die Anwendung selbst hat gar nichts mit der Sicherheitslücke zu tun. Die betrifft einzig und allein den Web Server selbst (also Apache).

    In wie weit UnsafeAllow3F bei der Default RewriteRule von Symfony/Contao (also die, die alle sonstigen Requests auf die index.php umschreibt) ein Sicherheitsproblem für den Web Server darstellt, kann ich auch nicht beurteilen, da ich das eigentliche Sicherheitsproblem zu wenig verstehe. Meine Vermutung wäre, dass das hinzufügen von UnsafeAllow3F bei der oben erwähnten Regel kein Problem wäre, da dass ja ohnehin nur für Requests gilt, die nicht auf physische Ressourcen gehen. Aber wie gesagt - könnte eine Fehleinschätzung sein.
    » sponsor me via GitHub or Revolut

  39. #39
    Wandelndes Contao-Lexikon Avatar von tab
    Registriert seit
    22.10.2013.
    Beiträge
    10.259
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Zitat Zitat von ErHaWeb Beitrag anzeigen
    Ja, genau so würde ich es auch zusammenfassen nach aktuellem Wissensstand.

    Im Fall von STRATO kommt allerdings erschwerend hinzu, dass das Flag "UnsafeAllow3F" nicht gesetzt werden kann ? Error 500
    #post586344
    Fände ich aber auch nachvollziehbar, je nachdem was Angreifer aus der "Weakness" machen können. Strato wird sich im Shared Webhosting schwer tun zu entscheiden, welche Anwendung eines Kunden trotz Setzen des Flags tatsächlich sicher ist und welche nicht. Das kann man eventuell noch dem einzelnen Kunden überlassen, aber nur solange es nur den Kunden selbst betrifft. Wenn das Setzen des Flags "UnsafeAllow3F" durch einen Kunden (bei Verwendung einer unsicheren Anwendung) aber möglicherweise auch Webspaces anderer Kunden kompromittiert, dann wäre das natürlich ein absolutes NoGo im Shared Webhosting.

  40. #40
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    37.141
    Partner-ID
    10107

    Standard

    Ja, Strato liegt hier nicht falsch.
    » sponsor me via GitHub or Revolut

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •