zu lange ladezeiten bei array mit tausenden datensätzen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #31
    Nachtrag:

    Ich hab mal geschaut was die letzten minuten versucht wurde... (kommt also von euch)

    - http://ctxtra.de/smf/index.php?page=9\'
    - http://ctxtra.de/index.php?download=./.htaccess

    Tja scheinbar arbeitet er ja doch gut... wenn du geblock wurdest.

    Der user hat keinen grund eine Url zu ändern und zu probieren was geht und was geht nicht... ich hab alle variablen die ich auf meiner seite verwende in die whitelist eingetragen also wird kein user geblockt solange er sich "an die spielregeln" hält... andernfalls, jor pech... selber schuld.

    Ich hab die letzten Ips wieder freigeschalten...

    Kommentar


    • #32
      Original geschrieben von Nordin
      Ja hast recht müsst ich mal nen text fertig machen...
      der könnte dann so anfangen:

      ich habe selbst wenig ahnung von php und security, darum progge ich zur abwechslung mal ein security-script (kein brwosergame), was alle möglichen ips und query-strings filtert ...

      ... oder so ähnlich, scnr

      Kommentar


      • #33
        Original geschrieben von Nordin
        Der user hat keinen grund eine Url zu ändern und zu probieren was geht und was geht nicht...
        Man kann sich ja auch mal vertippen.

        Du prüfst nicht auf Wurmsignaturen, SQL-Injection oder Brute-Force-Anfragemuster sondern blockierst einfach jede IP, die einen "unerlaubten" Request sendet.
        Zuletzt geändert von onemorenerd; 24.08.2007, 01:05.

        Kommentar


        • #34
          Man kann sich ja auch mal vertippen.
          Aus meiner sicht hat der user keinen grund die request_uri auf z.B. ./.htaccess zu ändern. und das der user sich mal vertippt wann passiert das mal??? 1 mal? 2 mal? im monat... ja ok, dann bekomme ich eine email und schalte ihn dann wieder frei.

          Kommentar


          • #35
            Original geschrieben von onemorenerd
            Man kann sich ja auch mal vertippen.
            zählt aber nicht bei links, hier kann man sich nicht verklicken

            trotzdem fragwürdig, ob alle nutzer hinter einem proxy für die handlung eines nutzers ausgeschlossen werden müssen.

            das interessiert nordin aber wahrscheinlich nicht - sicherheit geht vor!

            Kommentar


            • #36
              Du prüfst nicht auf Wurmsignaturen, SQL-Injection oder Brute-Force-Anfragemuster sondern blockierst einfach jede IP, die einen "unerlaubten" Request sendet.
              was würde folgendes machen? http://www.seite.tld/find.php?ID=42+...in,+password,+'x'+FROM+user
              Richtig! und damit das nicht passiert überprüfe ich die request_uri auf z.B. +UNION+

              trotzdem fragwürdig, ob alle nutzer hinter einem proxy für die handlung eines nutzers ausgeschlossen werden müssen.

              das interessiert nordin aber wahrscheinlich nicht - sicherheit geht vor!
              Das ist auch nicht richtig ich stelle diese IPs nur zur verfügung! Der user kann dann selber entscheiden welche ips er sperren will und welche nicht und kann sie dann im ACP rausschmeißen... ich lass sie bei mir aber drin... user die nix böses vorhaben brauchen nicht über öffentliche proxys kommen.

              Kommentar


              • #37
                Original geschrieben von Nordin
                was würde folgendes machen? http://www.seite.tld/find.php?ID=42+...in,+password,+'x'+FROM+user
                Richtig! und damit das nicht passiert überprüfe ich die request_uri auf z.B. +UNION+
                nochmal, falscher ansatz.
                wenn ich einen int erwarte, benutze ich inval() und nicht dein stümperscript.

                Original geschrieben von Nordin
                user die nix böses vorhaben brauchen nicht über öffentliche proxys kommen.
                spätestens das zeigt mir, dass du überhaupt keine ahnung hast, wovon du überhaupt redest.

                Kommentar


                • #38
                  wenn ich einen int erwarte, benutze ich inval() und nicht dein stümperscript.
                  wat ist los?? was hat das mit diesem sql-inject beispiel (der link) zu tun?? du verstehst doch nur bahnhof... oder du weißt selber nicht mehr was du redest. aber gut "jedem das seine"

                  ach ja, ich hab dich oder das was du scriptest noch nicht beleidigt... und stümperhaft sind sind andere scripte.. es gibt bei mir sicher hier und da noch schwächen die ich besser machen könnte, aber so schlimm wie du es hier darstellst ist es 100%ig nicht! Du bist scheinbar einer der anderen lieber sagt das er scheiße scriptet aber ihn nict dabei hilft es zu verbesseren... beleidigst mich hier von beitrag zu beitrag aber was sinnvolles ist bis jetzt von dir überhautnoch nicht gekommen... ausser vieleicht zu sagen das ich ne rücktaste vergessen habe zu drücken oder so eine grütze...

                  Kommentar


                  • #39
                    Original geschrieben von Nordin
                    was hat das mit diesem sql-inject beispiel (der link) zu tun?? du verstehst doch nur bahnhof...
                    Vorsicht! Du bist hier derjenige, der etwas nicht versteht.

                    Der Link enthält ?ID=42, also erwartet das Script einen Integer-Wert.
                    3DMax hat das erkannt und richtig argumentiert: Wer einen Integer erwartet, soll ihn mit intval() "abholen". Das entschärft jegliche Injection absolut zuverlässig und läßt dennoch den ganzen Integer-Wertebereich zu (ohne 2^32 Einträge in eine Whitelist hacken zu müssen).

                    Kommentar


                    • #40
                      Original geschrieben von Nordin
                      wat ist los?? was hat das mit diesem sql-inject beispiel (der link) zu tun?? du verstehst doch nur bahnhof... oder du weißt selber nicht mehr was du redest.
                      das zeigt mir ein weiteres mal, dass es zwecklos ist, mit dir zu diskutieren (die frage/bemerkung bezüglich des proxies hast du schließlich auch ignoriert).

                      Kommentar


                      • #41
                        Original geschrieben von Nordin
                        Richtig! und damit das nicht passiert überprüfe ich die request_uri auf z.B. +UNION+
                        jetzt habe ich erstmal verstanden, was kleinhirn da treibt, er überprüft den gesamten query-string als einen parameter.
                        das ist ja geil

                        scripte die die welt nicht braucht, von einem dau für daus

                        Kommentar


                        • #42
                          jetzt habe ich erstmal verstanden, was kleinhirn da treibt, er überprüft den gesamten query-string als einen parameter.
                          na geht doch...

                          Der Link enthält ?ID=42, also erwartet das Script einen Integer-Wert.
                          3DMax hat das erkannt und richtig argumentiert: Wer einen Integer erwartet, soll ihn mit intval() "abholen". Das entschärft jegliche Injection absolut zuverlässig und läßt dennoch den ganzen Integer-Wertebereich zu (ohne 2^32 Einträge in eine Whitelist hacken zu müssen).
                          Ahh jetzt jaa... ok das ist richtig.
                          Aber das eben nur wenn man einen int erwartet... wenn man jetzt aber betrachtet das die software nicht mur für mich gedacht ist sondern für jederman (der sie nutzen möchte) dann weiß ich ja nicht was die user für querys haben... somit kann ich ja nicht gleich geziehlt was "abholen" sondern muss alles überprüfen.... oder doch nich?

                          Kommentar


                          • #43
                            Original geschrieben von 3DMax
                            scripte die die welt nicht braucht, von einem dau für daus
                            jetzt echt mal, mach lieber eine sinvolle security-seite nach dem motto Traue niemandem. Validiere allen Input oder stirb. und Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?
                            von mir auch schreibe klassen dazu, anstelle deines jetzigen gegurkes.

                            schlimm genug, dass fast jeder php-lagastheniker eine "scharfe" seite offen im netz hat. darum musst du das nichtdenken nicht auch noch zusätzlich unterstützen bzw. gefühlte sicherheit vermitteln, weil sie durch dein script einfach nicht gegeben ist.

                            Kommentar


                            • #44
                              Deine Herangehensweise ist völlig falsch. Frag lieber den User, welche Parameter er erwartet - POST/GET, Name, Datentyp, Wertebereich (von-bis, erlaubte Zeichen, zulässige Strings), Verwendungszweck (DB-Query, Email, ...), Default Wert.

                              Mit diesen Informationen könntest du einen Request prüfen, alle Werte putzen, unsinnige Werte durch den Default ersetzen, überflüssige Parameter wegwerfen usw.

                              Du schießt nur mit Kanonen auf Spatzen und dabei fällt irgendwas vom Himmel. Ich möchte gar nicht in deinen Code sehen ...


                              Außerdem hast du auto_prepend, Filter-Extension, Proxy-Header, Session-IDs, File-Uploads, Namespacing, Selbstsicherung statt .htaccess, Debugger, u.v.m. nicht bedacht.

                              Kommentar

                              Lädt...
                              X