Announcement

Collapse
No announcement yet.

Http-Fehler 403 - You don't have permission to access /path/file.php on this server

Collapse
This topic is closed.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Http-Fehler 403 - You don't have permission to access /path/file.php on this server

    Hi,

    in den letzten Wochen ist es vorgekommen das einige unserer Mitarbeiter einen HTTP 403 Fehler auf einer unserer Seiten angezeigt bekamen.
    Als ich mir das Problem näher angeschaut habe, konnte ich den Fehler zwar reproduzieren, bin aber etwas ratlos. Ich hoffe Ihr könnt mir vielleich weiterhelfen.

    Zur Situation:
    Wir haben eine xampp-Installation auf einem Windows Server 2003 laufen,
    auf welchem die Seite gehostet ist.
    Die Mitarbeiter melden sich dort an und können Ihre Dienstleistungsnachweise schreiben.
    Dabei müssen mehrere Formulare ausgefüllt und abgeschickt werden.
    Das ganze passiert in ein und derselben php-datei welche sich selbst immer wieder aufruft und die jeweiligen Änderungen wegschreibt.
    Im 2. Schritt (also nachdem die Datei bereits aufgerufen wurde) erscheint dann folgende Fehlermeldung:
    You don't have permission to access /_dev/eDL/dl.php on this server.
    Zum Fehler:
    - Der Fehler tritt nicht jedesmal auf, sondern nur wenn ein bestimmter Text in einem Feld eingegeben wird.
    Wenn ich einen anderen Text eintrage wird man ganz normal weiter geleitet.
    - Wenn jeweils nur eine hälfte des Textes verschickt wird, funktioniert es wieder, weswegen ich nicht glaube das es an einem Zeichen liegt.
    - Auch sind im Text nur "normale" Sonderzeichen enthalten ( " , . ; < > - ' : ) und zu lang ist der Text auch nicht
    - Ich habe dem Formular testweise auch mal das Attribut accept-charset='utf-8' hinzugefügt sowie den Text in einem Text-Editor umkodiert und neu eingefügt und auch die Seite mit einem anderen Zeichensatz geladen.
    - Der Fehler tritt im IE 8, Firefox 12 sowie Chrome 19 auf.
    - Der Fehler erscheint nicht im Apache-Log
    - Ich habe bevor ich das Formular abgeschickt habe einmal die Datei selbst soweit geändert das php nur noch ein echo mit dem Text "test" ausgeben sollte, dennoch wird der Fehler angezeigt.


    Ich habe den Text welcher unteranderem auch einen Fehler hervorruft etwas zensiert, damit ich ihn Online Posten kann. (Auch die Zensierte Version wirft den Fehler)

    aaaaaaaaa aaa aa aaaaa aaaaaaaaaa aaa-aaa. 134 aaa 135.
    aaaaaaaaaaaaa aaaa aaaaaaaa aaaaaaaaaaa ("aaaaaa") nicht möglich.
    aaaaaaaaa aaa Herrn aaaaaaaa (aaaaaa aaaaaaa), Fernzugriff auf aaaaa 4000 nicht möglich.
    Anmeldungsversuch über "aaaaaaa" aaaaaaaaaaaaa mit aaaaaaaaaaaaa:
    "aaaa aaaaaaaaaaaa aa aaaaa aaaaaaaaaaaaaaaaaaaa aaaaa aaaaaaaaaaa,aaaaa aaaaa aaa aaaaa aaaaaaa aa aaaaa aaaaaaaaaaaa aaaaaaa aaaaaa"
    aaaaaa aaaaa ohne Erfolg - aaaaaaaaaaaaa:
    "ab-aaaaa;
    S3: aaaaaaaaaa BEI aaaaaaaaaaaaaa aaaa aaa aaaaa, aaaaaaaaaaaa : H'8442"
    Einschalten aaaa ohne Erfolg-aaaaaaaaaaaaa:
    "aaaaaaaaaaa-aaaa:a1,1;
    aaaaaaaaaaa-aaaa:A1,1;
    H500: aaa aaaa aaaaaaaaa
    F22: aaaaaa <:A1H11:> WURDE NICHT aaaaaaaaaaaa, aaaaa aaaa-aaaaaa H'8207"
    Eventuell Neustart der aaaaaa, b.z.W Austausch der aaaaaaaaaa nötig.
    Die folgende Version des Textes mit minimalen Änderungen wirft den Fehler dagegen nicht.

    aaaaaaaaa aaa aa aaaaa aaaaaaaaaa aaa-aaa. 134 aaa 135.
    aaaaaaaaaaaaa aaaa aaaaaaaa aaaaaaaaaaa (aaaaaaaa) nicht möglich.
    aaaaaaaaa aaa Herrn aaaaaaaa (aaaaaa aaaaaaa), Fernzugriff auf aaaaa 4000 nicht möglich.
    Anmeldungsversuch über "aaaaaaa" aaaaaaaaaaaaa mit aaaaaaaaaaaaa:
    aaaaa aaaaaaaaaaaa aa aaaaa aaaaaaaaaaaaaaaaaaaa aaaaa aaaaaaaaaaa,aaaaa aaaaa aaa aaaaa aaaaaaa aa aaaaa aaaaaaaaaaaa aaaaaaa aaaaaaa
    aaaaaa aaaaa "ohne Erfolg - aaaaaaaaaaaaa:"
    aab-aaaaa;
    S3: aaaaaaaaaa BEI aaaaaaaaaaaaaa aaaa aaa aaaaa, aaaaaaaaaa : H'8442a
    Einschalten aaaa ohne Erfolg-aaaaaaaaaaaaa:
    aaaaaaaaaaaa-aaaa:a1,1;
    aaaaaaaaaaa-aaaa:A1,1;
    H500: aaa aaaa aaaaaaaaa
    F22: aaaaaa <:A1H11:> WURDE NICHT aaaaaaaaaaaa, aaaaa aaaa-aaaaaa H'8207a
    Eventuell Neustart der aaaaaa, b.z.W Austausch der aaaaaaaaaa nötig.
    Die Zeichenanzahl ist Identisch, der unterschied liegt lediglich daran das ich an einigen Stellen die Anführungszeichen entfernt/hinzugefügt habe.
    (Zeile: 2, 5, 6, 7, 8, 10, 13)


    Ich bin etwas ratlos ...
    Ich hoffe Ihr habt ein paar Ideen die mir Weiterhelfen.
    Falls Ihr noch ein paar Infos braucht oder Fragen habt,
    einfach Fragen.

    Vielen Dank schonmal
    Mfg Nofoxx

  • #2
    Hallo,

    dass lässt sich für mich so erstmal nicht nachvollziehen.
    Ist /_dev/eDL/dl.php die PHP-Datei die im Formular als action angegeben ist? Wie genau ist das Formular und das Eingabefeld im HTML codiert? (Ein bissel Quellcode wär hier hilfreich )
    Gibt es irgendwelche Regeln - z.B. Rewrite-Rules im Apache - die ggfs. den 403 erzeugen? Tritt der Fehler auch auf, wenn im Formular eine andere Datei als action angegeben wird? Ist der 403 eine direkte Antwort oder resultiert er aus einer Weiterleitung? Gibt es im Formular irgendwelche Javascripts, die den eingegebenen Text noch manipulieren?

    Gruß Falk
    Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

    Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

    Comment


    • #3
      Danke für die schnelle Antwort

      _dev/eDL/dl.php ist das angezeigt php-Script welches auch die textarea darstellt und die action des Formulars verweist ebenfalls auf _dev/eDL/dl.php. (GET Variablen: action=dl.php?var=123456&session=ad89azd8a9shd8... &line=1).

      Die Seite hat folgenden meta-tag:
      <meta content="text/html; charset=iso-8859-15" http-equiv="Content-Type">
      Ansonsten gibt es keine Kodierungsangaben.

      Regeln die diesen Fehler erzeugen habe ich nicht gefunden und ich wüsste auch nicht das wir so eine Änderung vorgenommen hätten.

      Der Fehler tritt ebenfalls auf wenn eine andere Datei als action angegeben wurde.

      Der Fehler ist die direkte Antwort, es gibt keinerlei automatische Weiterleitung.

      Javascripts sind zwar vorhanden, haben aber keine Beziehung zu der textarea.
      Es handelt sich um eine einfach Html-textarea:
      <textarea style="width: 475px; height: 100px;" cols="250" rows="10" name="leistungsb" class="rand"></textarea>

      Comment


      • #4
        Hallo,

        ich würde einfach mal das Formular von GET nach POST umstellen. Tritt der Fehler dann immer noch auf?
        Deine beiden Teststrings haben zwar die gleiche Zeichenanzahl, die URL-Kodierte Variante der Beiden ist jedoch unterschiedlich lang.

        Die maximale Länge einer URL ist zwar im Apache wesentlich größer als 1024, aber offensichtlich wird der 403-Header ja auch im PHP gesetzt (fehlender Logeintrag im Apache-Error-Log).
        Läuft auf dem Server irgendeine PHP-Sicherungssoftware (wie z.B. Suhosin), die lange URLs bzw. GET-Parameter als Angriff wertet und deshalb den Zugriff verweigert?

        Gruß Falk
        Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

        Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

        Comment


        • #5
          Ich hab das wohl schlecht ausgedrückt, das Formular hat als sende Parameter POST.
          Code:
          <form method="post" action=dl.php?var=123456&session=ad89azd8a9shd8... &line=1">
          Lediglich ein paar Einstellungs-Werte werden in der URL übergeben.

          Es läuft außer der xampp installation auch keine weitere Software im Bezug auf den Webdienst.
          Abgesehen von McAfee, welcher aber auch keine Verbindungen blockiert hat.

          Normalerweise wirft php doch aber auch keine HTML fehler oder irre ich mich da?

          Der Fehler wird beim Abschicken bzw. danach und noch vor dem neuen Script aufrufen passieren,
          da der Fehler auch geworfen wird wenn ich im action-Parameter auf eine komplett neues Script Verweise ohne Weiterverarbeitung der Daten.
          Folgendes hatte ich vor einer Weile bereits einmal ausprobiert, um eine möglichst einfachen Ablauf durch zu Spielen
          und dennoch wurde der Fehler angezeigt.

          Script 1 - Formular
          Code:
          <form method="post" action="test.php">
          
          <h1>Eingabe Dienstleistungsnachweis</h1>
          
             <b>Leistungsbeschreibung:</b>
             <br>
          <textarea style="width: 475px; height: 100px;" cols="250" rows="10" name="leistungsb" class="rand">
             
             *der text*
             
             </textarea>  
             
             <table cellspacing="0" cellpadding="0" border="0" style="width: 490px;">
             <tbody>
             <tr> 
             <td valign="top" style="vertical-align: top;">
             <input type="submit" style="width: 140px;" class="submit2" name="NextLine" value="Eingaben übernehmen">
             </td>
             </tr>
             </tbody>
             </table>
             
             <span class="footer">Seite generiert in 0.20565 Sekunden.</span>
             <div class="clear"></div>
          </form>
          Script test.php
          Code:
          <?php
          echo "test";
          ?>

          Comment


          • #6
            Originally posted by Nofoxx View Post
            ...Normalerweise wirft php doch aber auch keine HTML fehler oder irre ich mich da?
            Das wovon du redest ist auch kein HTML-Fehler. Der HTTP-Request wird mit einer entsprechenden HTTP-Response und in deinem Fall mit einem Statuscode 403 - You don't have permission ... beantwortet. Dieser HTTP-Header kann durchaus von PHP gesetzt werden. Und da der Apache keinen Error protokolliert, sieht das ganz danach aus.
            Um das jetzt ganz sicher zu prüfen, könntest du als action mal kein PHP-Script, sondern eine einfache .html Datei angeben. Dann wäre als nächstes zu prüfen, ob eine Autoprepend-Datei von PHP geladen wird und was dort ggfs. passiert.

            Und du bist dir sicher das kein Suhosin installiert ist!? Hast du mal die Ausgabe von phpinfo() danach kontrolliert?

            Gruß Falk
            Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

            Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

            Comment


            • #7
              Ich habe in der action mal auf eine test.html verwiesen.
              Nach dem abschicken wird mir wieder der Fehler angezeigt.

              Eine auto_prepend_file wurde in der php.ini nicht angegeben,
              auch während des Scriptablaufs wird an dem wert nichts geändert.

              Was Suhosin angeht, ich habe eben noch mal meinen Kollegen gefragt und auch er wüsste nicht das so etwas bei uns läuft. Auch phpinfo(); zeigt mir nichts in die Richtung an.

              Comment


              • #8
                Ich habe eben noch einmal das LogLevel vom Apache erhöht und mir die access.log und error.log Datei angeschaut.

                In der error.log Datei wird weiterhin nichts weggeschrieben.

                Was mich etwas irritiert ist das auch im access.log nach dem Submit nichts weggeschrieben wird,
                als würde keine neue Anfrage stattfinden.
                Normalerweise wird jeder Aufruf eingetragen, z.B. das laden des Formulars etc.

                Comment


                • #9
                  Originally posted by Nofoxx View Post
                  ...Abgesehen von McAfee, welcher aber auch keine Verbindungen blockiert hat.
                  Hast du den mal testweise komplett deaktiviert?
                  Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

                  Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

                  Comment


                  • #10
                    Ja, hat leider nicht geändert.

                    Ich habe eben gerade auch noch einmal versucht Seite auf einer anderen xampp Installation auszuführen. Hier kommt es nicht zu diesem Fehler (MCAfee läuft hier ebenfalls).
                    Ich werde bei Gelegenheit noch einmal die Einstellungen beider Installationen vergleichen und schauen ob sich dabei etwas findet.

                    Mal schauen ob sich der Fehler doch noch beheben lässt, so ganz will ich die Hoffnung nicht aufgeben aber bevor es zu viel Zeit in Anspruch nimmt, wird es wohl darauf hinauslaufen, dass die Seite verschoben oder der xampp neu Aufgesetzt wird.

                    Comment


                    • #11
                      Da ich den Fehler leider nicht finden und das Problem beheben konnte,
                      werden wir jetzt einen neuen xampp aufsetzen und die Seite dorthin verschieben.

                      Dennoch vielen Danke für die Hilfe bei der Fehlersuche Falk Prüfer!

                      Comment


                      • #12
                        Naja - hab jetzt nicht alles gelesen....

                        Aber sofern ich doch denke (und hoffe) , dass der POST inhalt noch gefiltert wird -> insbesondere in Hinblick auf die Verwendung einer Datenbank kann hier natürlich (z.B. ein filter etc) etwas ungehalten ob '" usw reagieren und ggf. etwas auslösen , das dann zu der Meldung bez. nicht vorhandener Rechte führt.. ggf. eine Meldung soll ausgegeben werden etc....

                        Comment


                        • #13
                          Was könnte es für einen Sinn haben, Beiträge auszugraben, die fast ein Jahr als sind? Des Weiteren wo sollte da was für ein Filter laufen? Wo steht irgendwas von einer Datenbank?
                          Christian

                          Comment


                          • #14
                            Ach ein forenheld... ja, das Datum habe ich übersehen .. mein Fehler 100.000 mal Entschuldigung... ist halt sehr wenig los in diesem Forum ...hab nicht auf das Datum geachtet.
                            Bin halt großzüig und verteile kostenlose tipps

                            Ich kenne nicht was die sich da zusammengebastelt haben.. ist wahrscheinlich im Intranet unterwegs wie auch immer...

                            Wenn ich Daten irgendwo eingebe, gehe ich davon aus, dass die i.d.R. auch irgendwo gespeichert werden - da bietet sich eine Datenbank halt an...

                            ..und was für ein Filter? tja ... wie gesagt ist jetzt ein Jahr alt - dem Fragesteller wird's nicht mehr helfen ... und wer so doof ist wie ich und unerwünscht alte Beiträge beantwortet ist eben mal besorgt um seine Daten ...
                            da wird halt auch mal gefiltert, was von aussen kommt - und irgendwie muss man ja auch reagieren usw...

                            Was macht es eigentlich für einen Sinn ein Beitrag auf einen alten Beitrag zu kommentieren ?

                            Comment


                            • #15
                              ah ein Anfänger

                              Du stellst eine Vermutung an, und beantwortest diese wieder mit einer Vermutung. Wenig sinnvoll und vor allem wenig hilfreich

                              Wenn ich Daten irgendwo eingebe, gehe ich davon aus, dass die i.d.R. auch irgendwo gespeichert werden - da bietet sich eine Datenbank halt an...
                              Ja du gehst von irgendwas aus, was so nicht gegeben sein muss. Das hat der Threadersteller nicht gesagt, und war auch kein Problem. Es bestehen weitere Möglichkeiten, als Daten in eine DB zu speichern......

                              . und wer so doof ist wie ich und unerwünscht alte Beiträge beantwortet ist eben mal besorgt um seine Daten ....
                              Der kausale Zusammenhang ergibt sich nicht


                              Was macht es eigentlich für einen Sinn ein Beitrag auf einen alten Beitrag zu kommentieren ?
                              geschlossen
                              Christian

                              Comment

                              Working...
                              X