Ankündigung

Einklappen
Keine Ankündigung bisher.

Jemand Lust an bncms mitzuarbeiten?

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #46
    Man muss unterscheiden zwischen die Tabellen und Formularen die vom bncms Core gebildet werden (den Renderings fürs Frontend die über displayTable / displayRow ablaufen) und die anderen Datenbankanfragen und Formulare in der Anwendung zb im Backend wo es sehr viele Formulare gibt. Die SQL-Anfragen im Backend wurden jetzt auch überarbeitet und escaped um Injection endgültig zu verhindern. Aber auf den Backendbereich haben die Endbenutzer auch keinen Zugriff. Die Frontendausgaben hingegen sind auf höchstem Stand abgesichert, da es dort auch so wichtig ist.

    Ausgaben im Frontend verfügen standartmässig über Schutz gegen Cross Site Request Forgery ausserdem Cross Site Scripting und Injection.

    Somit genügen Formulare und Tabellen, die mit bncms generiert werden, höchsten Sicherheits-Ansprüchen an Webfrontends.

    Sehr viele Anwendungen hingegeben grosse Portale wie Amazon, Google schützen nicht flächendeckend gegen CSRF da es aufwändig umzusetzen ist.
    bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

    Kommentar


    • #47
      Zitat von bncms Beitrag anzeigen
      Das ist keine Kritik sondern Diffamierung auf dem untersten Level. Wahrscheinlich müssen sie darüber hinwegtäuschen, dass ihr eigenes CMS nicht im geringsten rankommt.
      Ich habe kein eigenes CMS, brauche ich auch nicht.

      Man muss unterscheiden zwischen die Tabellen und Formularen die vom bncms Core gebildet werden (den Renderings fürs Frontend die über displayTable / displayRow ablaufen) und die anderen Datenbankanfragen und Formulare in der Anwendung zb im Backend wo es sehr viele Formulare gibt. Die SQL-Anfragen im Backend wurden jetzt auch überarbeitet und escaped um Injection endgültig zu verhindern. Aber auf den Backendbereich haben die Endbenutzer auch keinen Zugriff. Die Frontendausgaben hingegen sind auf höchstem Stand abgesichert, da es dort auch so wichtig ist.

      Ausgaben im Frontend verfügen standartmässig über Schutz gegen Cross Site Request Forgery ausserdem Cross Site Scripting und Injection.

      Somit genügen Formulare und Tabellen, die mit bncms generiert werden, höchsten Sicherheits-Ansprüchen an Webfrontends.

      Sehr viele Anwendungen hingegeben grosse Portale wie Amazon, Google schützen nicht flächendeckend gegen CSRF da es aufwändig umzusetzen ist.
      Und der Login gehört nicht zum Frontend? Selbst da ist die einfachste SQL Injection möglich.

      https://github.com/damianhunziker/bn...s.inc.php#L758
      https://github.com/damianhunziker/bn....inc.php#L1286
      https://github.com/damianhunziker/bn....inc.php#L1389
      https://github.com/damianhunziker/bn....inc.php#L1408
      https://github.com/damianhunziker/bn....inc.php#L1422
      https://github.com/damianhunziker/bn....inc.php#L1050
      https://github.com/damianhunziker/bn....inc.php#L1535

      Wenn ich alle paar Zeilen eine Sicherheitlücke finde, dann nenne ich sowas schlampig. Ich nehme mal an dieses File erzeugt die Ausgaben im Frontend.

      Wo ist denn CSRF aufwendig zu implementieren? Das macht jedes vernünftige Framework komplett im Hintergrund und zwar ohne dass ein Entwickler eine Zeile Code mehr schreiben muss.
      Und wo schützen Google oder Amazon nicht "flächendeckend" gegen CSRF, gib mir da mal bitte ein paar Beispiele.

      "Software is like Sex, it's best if it's free." - Linus Torvalds

      Kommentar


      • #48
        Standart ist eine Art zu stehen.

        Zum Thema: ich sehe hier ebenfalls erschreckend großen Qualitätsmangel. Beurteilt am Code sieht das für mich nach einem Hobby-/ Lernprojekt aus.

        Kommentar


        • #49
          Das sind CSS Sicherheitslücken und eine Injections werds später integrieren. Das Login gehört zum Backend. Wäre schön wenn du nicht in jedes zweite Wort eine Beleidigung verpacken könntest

          Wenn eine Anwendung kritische oder schwerwiegende Aktionen durchführt per GET-Parameter ohne vorherige Benutzerbestätigung oder Token im Link, immer dann ist CSRF möglich. Das findet man immer wieder auch bei grossen Portalen.
          bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

          Kommentar


          • #50
            Zitat von bncms Beitrag anzeigen
            Das sind CSS Sicherheitslücken und eine Injections werds später integrieren. Das Login gehört zum Backend. Wäre schön wenn du nicht in jedes zweite Wort eine Beleidigung verpacken könntest

            Wenn eine Anwendung kritische oder schwerwiegende Aktionen durchführt per GET-Parameter ohne vorherige Benutzerbestätigung oder Token im Link, immer dann ist CSRF möglich. Das findet man immer wieder auch bei grossen Portalen.
            Und da der Login zum Backend gehört hat er keine Sicherheitsrelevanz oder wie?
            Das sind nicht nur die paar XSS und Injections. Das war eine Datei (von vielen) aus deinem System, bei der ich beim drüberscrollen schon unzählige Sicherheitslücken gefunden habe. Ich lehne mich mal aus dem Fenster und behaupte dass das bei den anderen nicht viel anders sein wird.

            Ich beleidige dich nicht, ich möchte nur klar und deutlich sein. Aus dem einfachen Grund, weil ich an eventuelle Benutzer da draußen denke, die sich auf deine Sicherheitsversprechen verlassen (müssen) und im Prinzip das komplette Gegenteil bekommen.
            "Software is like Sex, it's best if it's free." - Linus Torvalds

            Kommentar


            • #51
              Wir sind diese Dinge schrittweise am fixen. So war das geplant. Du reitest nur darauf rum um es in den Dreck zu ziehen.



              bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

              Kommentar


              • #52
                lerne doch mal kritik, sei diese auch hart, ist kein "dissen".

                Kommentar


                • #53
                  Neuer Security Patch von gestern fixt CSS an vielen Stellen und unnötige Dateien wurden gelöscht. Alles wurde noch einmal nach Injections abgesucht. https://github.com/damianhunziker/bn...10399414242cc2
                  bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

                  Kommentar


                  • #54
                    Zitat von bncms Beitrag anzeigen
                    Neuer Security Patch von gestern fixt CSS an vielen Stellen und unnötige Dateien wurden gelöscht.
                    Du meinst XSS? Dafür ist strip_tags aber nicht geeignet. Verwende besser htmlspecialchars

                    Zitat von PHP-Handbuch
                    Warnung
                    Diese Funktion sollte nicht verwendet werden, um zu versuchen XSS-Attacken zu verhindern. Statt dessen sind geeignetere Funktionen wie htmlspecialchars(), oder andere Mittel abhängig vom Ausgabekontext, zu verwenden.
                    Eine Mannschaft aus Granit! So wie einst Real Madrid!
                    Und so zogen wir in die Bundesliga ein und wir werden wieder Deutscher Meister sein!

                    Kommentar


                    • #55
                      Du hast Recht, strip_tags entfernt nur valides HTML. Habe deswegen noch htmlspecialchars hinzugefügt an diesen Stellen wo sowieso nirgends Tags in den Variablen erlaubt sind. https://github.com/damianhunziker/bn...21b46bc5e23c54
                      bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

                      Kommentar


                      • #56
                        Warum überhaupt strip_tags()? Warum überhaupt diese Funktionen, die nur eine andere Funktion aufrufen?

                        Kommentar


                        • #57
                          Zitat von bncms Beitrag anzeigen
                          Neuer Security Patch von gestern fixt CSS an vielen Stellen und unnötige Dateien wurden gelöscht. Alles wurde noch einmal nach Injections abgesucht. https://github.com/damianhunziker/bn...10399414242cc2
                          Du hast das Prinzip von Kontextwechseln sowie deren korrekter Behandlung nicht verstanden. Deine Funktionen eh() und et() sind völliger Unsinn: damit wendest du htmlspecialchars *und* mysqli_real_escape_string (bei et vorher noch strip_tags()) auf die Werte an - du behandelst also gleichzeitig zwei verschiedene Kontextwechsel die nichts miteinander zu tun haben! Du machst dir damit sogar deine Daten kaputt da du nicht die Originaldaten in der Datenbank speicherst sondern die behandelten. Zudem gibt es noch mehr Kontextwechsel, den Wechsel zu einem Header z.B. versuchst du auch mit htmlspecialchars zu behandeln was natürlich nichts bringt da der Header nie im HTML-Kontext ausgegeben wird.

                          Kommentar


                          • #58
                            Nein ich will Benutzervariablen, die eh keine Tags enthalten sollen, schon vor der Speicherung maskieren und stripen damit der schädliche Code gar nicht erst in der Datenbank steht. Das ist sicherer als nur im Frontend-Kontext die Zeichen zu maskieren.
                            bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

                            Kommentar


                            • #59
                              Zitat von bncms Beitrag anzeigen
                              Nein ich will Benutzervariablen, die eh keine Tags enthalten sollen, schon vor der Speicherung maskieren und stripen damit der schädliche Code gar nicht erst in der Datenbank steht. Das ist sicherer als nur im Frontend-Kontext die Zeichen zu maskieren.
                              Nein, ist es nicht. Hast du die von mir in #57 verlinkte Seite mal gelesen? Du behandelst einfach mal den Kontextwechsel nach HTML ohne zu wissen ob die Daten wirklich mal als HTML ausgegeben werden. Was machst du wenn die Daten doch mal in einem anderen Kontext ausgegeben werden sollen? Ob Daten schädlich sind hängt immer vom Kontext ab, prinzipiell ist z.B. ein <b> in der Datenbank völlig ungefährlich. So wie du das machst hast du dann defekte Daten die sich nicht mehr vernünftig weiter bearbeiten lassen - deswegen müssen Kontextwechsel immer genau dann behandelt werden wenn sie erfolgen und nicht irgendwo vorher!

                              Kommentar


                              • #60
                                Oder, wenn es dir wirklich so wichtig ist, validieren die Eingaben und zeige ggf. einen Fehler an.

                                Kommentar

                                Lädt...
                                X