sicherheitsaspekte in der security.php

1. offizieller Beitrag

    Die Schablone wird mMn nicht benötigt im moment...

    Wird diese Codezeile auch in der Security Pro verwendet?

    PHP
    $request = $_REQUEST;
foreach ($request as $key => $temp) {
  if (isset($_REQUEST[$key])) $$key = $_REQUEST[$key];
}


    dank dieser schleife ist es einem möglich, den scriptblocker, die ipprüfung udgl. fein auszuschalten.

    ob eine injection in dem script möglich ist, weiß ich noch nicht, habs noch nicht versucht. in den sql query kann man aber recht viel übergeben. ungeprüft werden variabeln an die datenbank gesendet...


    So viel gemütlichkeit muss mMn nicht sein, dass man ALLE Superglobalen variabeln umwandelt... :rolleyes:


    mfG
    Zagon


    PS: Nachtrag -> auch bei der Pro scheint es zu gehen... :rolleyes:
    So wie es also jetzt ist, bietet es recht wenig schutz...

    5 Mal editiert, zuletzt von zagon (24. August 2005 um 14:15)

    Wir sind bemüht, alle Sicherheitsfehler in Bugfix-Versionen auszubessern.

    @earlyhost:
    das erinnert mich an Woltlab... "Ja, wir tun eh schon". wer wir? und wann?
    sonst kein kommentar zu der lücke?

    Bist nicht der meinung, dass diese Fehler einer sofortigen reaktion bedürfen?
    schließlich wirkt der fehler so, als gäbe es dein addon nicht am server.


    DodCom...
    ich hab deinen link gelesen, leider ist nicht jeder sein eigener server"admin".
    hardened php hab ich deswegen aus dem text entfernt, hat keinen weiteren sinn, darauf einzugehen. ich kenns selbst nur vom lesen, aber es hat mich soweit interessiert, dass ichs mal local testen werde.

    mod_security kann man wahrscheinlich kicken, wenn man sauber programmiert... :rolleyes:

    Einmal editiert, zuletzt von zagon (24. August 2005 um 14:37)

    Ich bin nicht earlyhost, sondern Dominik ^^
    deswegen kann ich momentan nichts zu der Lücke sagen.

    Zitat

    Original von zagon
    sry, hab mich verlesen.
    dann nehm ich natürlich mein geschwafel in dem post (sicherheitsaspekte in der security.php) zurück!

    dennoch ist eine phrase wie "ja wir tun schon" für die klientel nicht zufriedenstellent. mM :)

    grüße und nochmal sry
    Zagon

    Ist kein Problem.
    Ich kann leider nichts genaues zu der Sicherheitslücke sagen, da earlyhost momentan ja an neuen Bugfix-Versionen arbeitet.
    Ich weiss da leider auch nichts genaueres darüber. Tut mir Leid.

    Jawohl :)

    das hier:
    >>dennoch ist eine phrase wie "ja wir tun schon" für die klientel nicht zufriedenstellend. mM
    (tippfehler)

    war in dem sinn nicht mehr auf dich bezogen, wir kennen diese antworten aus anderen bereichen *gg


    grüße
    Zagon

    • Offizieller Beitrag
    Zitat

    Original von Dominik
    Ich wollte es auch nur anmerken, dass earylhost mehr zu der Sicherheitslücke sagen kann, als ich momentan.

    Also natürlich kann das als SIcherheitslücke angesehen werden, wenn man schlecht programmiert. SQL Injections können nur durch schlecht gemachte Scripte gemacht werden. Die Version 2.1 pro wird gegen soetwas schützten können!

    In der ACp security.php ist das auf keinen Fall eine Sicherheitslücke, da man die Sid braucht... Und wenn man die hat, kann man effektivere Sachen machen...

    In der Forumversion kann diese Funktion ausgenützt werden, zu bedenken ist aber, dass die wenigsten Server diese Zeilen überhaupt benötigen. Ich kann nur sagen ich bin am Arebiten, auch wenn das vielleicht einige nicht befriedigen aknn. Zur Zeit arbeite ich alleine an dem Sicherheitssystem und das ist viel Arbeit. Außerdem gehts mir privat auch nihct gerade rosig. Ich kann nur auf die bald erscheindene Version 2.1 pro verweisen. (Benutzer von 2.0 pro bekommen einen Patch).

    Nocheinmal: Diese Sicherheitslücke kann nur ausgenützt werden, wenn das Script schon nicht ganz fehlerfrei programmiert wurde. Dazu reicht schon die SQL INjection im $_POST. $_GET ist da meistens gar nciht nötig...

    Hallo,

    ja, ich hätte dazu sagen müssen... die Boardroot security.php ist "unsicher".
    es geht jetzt um flooding tools, oder zB um die SQL-injection bei ungepatchten foren, weil fremdscripte nicht mehr geblockt werden. nicht um die "übernahme" des acp.

    man kann sich selbst seine Superglobalen erstellen lassen durch dein script.
    _POST, _GET, _COOKIE, etc... alles kein problem.
    oder eben andere arrays, wie in dem fall die securityconfig[xcy]...

    auch das wbb selbst versäumt es, die Superglobalen nach dem zu filtern, aber es erzeugt wenigstens nicht wie dein script aus jedem Superglobal key eine variabel.


    was meinst du mit dem:
    >>zu bedenken ist aber, dass die wenigsten Server diese Zeilen überhaupt benötigen.

    welche zeilen benötigen die wenigsten server?


    >>Nocheinmal: Diese Sicherheitslücke kann nur ausgenützt werden, wenn das Script schon nicht ganz fehlerfrei programmiert wurde.

    ja, das ist in deinem script (boardroot/security.php) der fall.


    >>Dazu reicht schon die SQL INjection im $_POST. $_GET ist da meistens gar nciht nötig...

    ???


    mfG
    Zagon

    PS: es ist dir keiner böse,
    >>auch wenn das vielleicht einige nicht befriedigen aknn

    ich wollt dir nur zeigen, dass in der datei unsicher programmiert wurde.


    PPS:
    dieser Fehler wäre in 2 sekunden gepatched...

    4 Mal editiert, zuletzt von zagon (24. August 2005 um 15:31)

    Zitat

    Original von zagon
    was meinst du mit dem:
    >>zu bedenken ist aber, dass die wenigsten Server diese Zeilen überhaupt benötigen.

    welche zeilen benötigen die wenigsten server?

    Ich denke mal, er meinte deinen zitierten Code

    PHP
    $request = $_REQUEST;
foreach ($request as $key => $temp) {
  if (isset($_REQUEST[$key])) $$key = $_REQUEST[$key];
}
    • Offizieller Beitrag

    Das ist schon richtig, dass du sagen kannst, dass du eine neue Securityconfig definierst, aber bringen tut dir das nciht viel. Die $securityconfig wird ja weiter unten definiert. Da nützt dir deine $_GET Variable gar nichts!

    nichts, nur das securitysystem abschalten, mehr net.

    hier 2 testbilder:
    das zweite konnte ich nur als gif speichern, ich hab hier in der arbeit nur MS Paint, das zickt ständig rum.

    ja, hast recht, hätte ich hier auch zeigen können, sry.
    ich versichere dir, es macht nichts schlimmes.

    das erste bild (das größere) zeigt, wie man ins forum reinkommt, obwohl das script meinen client gesperrt hat - siehe bild 2?

    Einmal editiert, zuletzt von zagon (24. August 2005 um 16:13)

    ich wäre dafür das mein link zum forum da wieder wegkommt

    wie schalte ich das wieder ein??

    wann gibts nen patch dafür?

    warum schreibst du keinen zagon??......hier gibts ne rubrik wo user module usw...anbieten können.....da findet bestimmt auch dein patch platz

    warum arbeitet ihr nicht zusammen?

    ich lösche den link zu deinem forum :) sollt dich jedoch nicht weiter beunruhigen (der link selbst).

    wieder einschalten brauchst du es nicht, es ist nur für den einen aufruf abgedreht.

    ich weiß nicht, was du einsetzt, ich habs auf meinem testforum nur mit dem basic script getestet. das kann man eben für den einen aufruf deaktivieren.
    ansonsten kann ich dir eine lösung zukommen lassen.

    =)

    >>warum arbeitet ihr nicht zusammen:
    weil auch ich meine projekte habe, die mir zeit rauben :)
    ich habe ihn jedoch darauf hingewiesen, das müsste langen. das problem hier ist ja in 1 sec behoben.

    2 Mal editiert, zuletzt von zagon (24. August 2005 um 16:27)