Ankündigung

Einklappen
Keine Ankündigung bisher.

Sicherheits-Checkliste für ein WebProjekt?

Einklappen

Neue Werbung 2019

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

  • Sicherheits-Checkliste für ein WebProjekt?

    Tachchen!

    Ich hab da mal eine Frage. Gibt es eine standartisierte Checkliste für Sicherfragen bezüglich eines Webprojects?

    Beispiel:
    1. sind Unterordner mit .htaccess geschützt?
    2. sind Funktionen durch Benutzer- /Rechteabfragen geschützt?
    3. sind öffentlich mögliche Eingaben durch CaptCha geschützt?
    4. etc...etc...etc

    Wenn es keine gibt, könnte man ja mal eine erstellen, oder was meint ihr?

    Wenn ihr eine Checkliste habt, dann her damit. Wenn ihr keine habt, aber Punkte, die in solch einer Checkliste nicht fehlen dürfen, dann auch her damit.

    Bin grad dabei die Plattform für mein, ich sag mal ganz vorsichtig in Anführungszeichen, "Internet-Label" zu programmieren. Da will man viel mit machen können und es soll flexibel sein...aber alles soll die Öffentlichkeit nicht zu Gesicht bekommen bzw. zerstören können.

  • #2
    nun, die sicherheitsfragen sind anderer natur. auf sowas muss dein (php) code getestet werden:

    XSS
    SQL-Injection
    Code-Injection

    was du aufzählst versteht sich mit unter von selbst, außer Captchas (siehe hier).
    ob du die unterordner mit htaccess schützen musst, kann ich dir nicht sagen. programmierst du OOP ist das nur ein I-Tüpfelchen....

    Kommentar


    • #3
      Ah, schön ... eine Projektplanung ... *misch ein* Eine wirkliche Liste hätte ich nicht im Angebot, aber wir können drüber reden.

      Internet-Label klingt interessant ... habe ich doch eine Casting-Plattform (offline) mit ähnlichen Bedingungen geschaffen. (Background: selbst mal im Studio geschraubt und immer fehlte das passende Vocal für den Track - Casting dauert aber zu lange)

      Aber mal ganz rudimentär gestartet: Deine Zielgruppe könnte jede(r) sein - richtig? CaptCha ist ja ganz nett, Du sperrst aber auf diesem Wege Menschen aus, die z. B. auf Voice-Software angewiesen sind (Stichwort: Barrierefreiheit). Alternativen gibt es, Bots außen vor zu lassen ...

      Was willst Du denn warum schützen (s. Punkt 1 + 2)? Wenn Du bspw. User-Profile meinst, so kannst Du das im Script selbst erledigen ... musst halt bei der Umsetzung schon dran denken - im Nachhinein ändert sich sowas sehr ätzend. ^^

      Ey, wir können das Thema hier komplett ausweiden ... startet beim rudimentärsten Site-Hack über die robots.txt, über Paramterübergabe und XSS & Co. bis zum Schutz möglicher Uploads bzw. Wege dafür eeeeeetc.

      Ich war jetzt gerade mal auf der Seite ... ich glaube, Du redest von den Audiofiles, die Du direkt verdrahtet hast und somit von anderen Seiten ebenfalls verlinkt werden könnten (Dein Traffic!) ...

      Na, einfach mal Feedback oder ein paar Infos mehr.

      Grüße.

      Kommentar


      • #4
        Zumindest kannst du die Sicherheitseinstellungen des Servers checken:
        http://phpsec.org/projects/phpsecinfo/index.html

        Das sagt aber nur etwas über die Einstellungen aus, nicht über die Programmierung (logisch).

        Was du schützen willst habe ich nicht so ganz verstanden.

        Kommentar


        • #5
          Naja, schützen will ich folgendes:

          - Gästebuch (vor willkürlichen BotEinträgen)
          ...meine bisheriger schutz dafür war kein Captcha, sondern wie auf meiner Seite zu sehen ist, eine simple 4 stellige Ziffern- und Buchstabenkombi. (gerade mal die Ziffern 1-4 und die Tasten qwer asdf yxcv). Funktionierte bis dato auch. Denke aber, dass es auch daran liegt, welche Bots sich auf der seite getummelt haben. So großartig bekannt ist die Seite ja nun nicht.

          Ok, das mit dem Captcha sehe ich ein und die Ideen, die unter dem oben genannten Link, genannt werden, sind ziemlich klasse.

          - Administrative Formulare / Funktionen:
          ...diese sind bereits geschützt durch dementsprechende Abfragen (Funktionen prüfen die Gruppenzugehörigkeit innerhalb der Datenbank und dementsprechend wird der Code des Formulars / der Funktion bearbeitet oder eben nicht)

          - Dateien via .htaccess (oder vielleicht andere Wege?):
          ...bisher sollten meine Daten via .htaccess gesichert sein, allerdings sind das vorgefertigte Einstellungen des Providers. Ich würde mich gern selbst mal einer .htaccess annehmen, aber auf'm localhost klappt das irgendwie nicht. Muss der Server noch die Anweisung bekommen, dass er .htaccess Dateien beachtet?


          ...meine Überlegung ist bei der ganzen Geschichte nicht, was will ich schützen, sondern, wie sollte ich mein WebProjekt im allgemeinen schützen? Worauf muss geachtet werden? Was ist von besonderer Relevanz?

          Ich bin noch fortgeschrittener Anfänger, behaupte ich mal, und bilde mir deshalb nicht ein, nur weil ich eine Kontrollabfrage gebastelt habe, die auf einem doch recht simpel gehaltenen Rechtesystem beruht, dass ich der Spezi wäre und ich nichts weiter zu beachten habe.

          Naja...soviel dazu.

          btw: Die momentane Präsenz auf schwarzerton.de ist die alte Version. habe vor ein paar Tagen mit einer neuen Version begonnen, die komplett neu geschrieben wird als auch gestaltet wird. Übersichtlicher für die Besucher, einfacheres Design für mich als "Entwickler" und "Designer" der Seite, kontrolliertere Abfragen bei Formularübergaben und vor allem Zugriffsschutz auf alle erdenklichen Funktionen / Formulare. Dabei will ich aber gewährleisten können, dass es sozusagen "MultiUser"-fähig ist und diese verschiedenen User auch verschiedene Rechte bekommen (der eine darf News schreiben, aber nicht löschen und wenn nur seine eigenen...etc.)

          So...Captcha...die Mühe mach ich mir also nicht.

          Kommentar


          • #6
            Achso...was genau ist XSS?

            Kommentar


            • #7
              Hola,

              hier ein grundlegener Link:
              http://de.wikipedia.org/wiki/Cross-Site_Scripting

              Und hier der passende Sandkasten dazu:
              http://ha.ckers.org/xss.html


              Bis dääähne.

              Kommentar


              • #8
                Hier eine Fülle an Infos [en]:

                OWASP Testing Guide
                http://www.owasp.org/images/2/28/OWA...v2_RC1_pdf.zip

                Kommentar


                • #9
                  @ Nikosch: Die Datei ist beschädigt ... (2x probiert)

                  @ squig: Der Sandkasten ist cool ... wo sind noch gleich meine "Förmchen"?!

                  Kommentar


                  • #10
                    @Curanai
                    Die Datei ist nicht beschädigt, liegt sicherlich an deinen ZIP-Programm.

                    Kommentar


                    • #11
                      japp, Korrektur ... mit "save as(s) ... " geht es ... thx.

                      Kommentar


                      • #12
                        Okay, das heißt also im Grunde genommen, wenn ich alle Eingaben auf meiner Webseite soweit bearbeite, dass diese, bevor sie behandelt bzw. gespeichert werden, keinen HTML-Code ergeben, ist schonmal Gutes getan?

                        Sprich...> oder < durch bspw. ? ersetzen.

                        Zudem wird einem hier bewusst, wie vorteilhaft es ist, seine Seiten ohne JavaScript zu betreiben...*grübel*...

                        ...dann sind ja Entwickler vorn, die sich lediglich auf eine Kombination von PHP mit HTML (XHTML) beschränken, wa? Im Sinne von, dass sie jeder anschauen kann und die Funktionen im vollen Umfang nutzen kann.

                        Kommentar


                        • #13
                          Naja mitlerweile hat fast jeder JS aktiviert. Durch die vielen Frameworks wie jQuery, Prototype etc. kann JS jetzt endlich auch effektiv ergänzend zur Webseite laufen! Genauso Ajax.

                          Und deine Seite ist nicht sicherer wenn DU kein JS verwendest. Das Problem tritt auf wenn ein User in einem Formular irgendwelche JavaSkript Anweisungen schreibt und diese dann, wenn der Inhalt des Formulars als HTML angezeigt wird, ausgeführt werden. DA liegt das Problem mit XSS.

                          Aber du kannst JS verwenden ohne dass dies ein Sicherheitsrisiko birgt. Davon ausgegangen dass du es richtig einsetzt.


                          Und anstatt < und > zu entfernen würde ich Funktionen nutzen die extra dafür gedacht sind. Der Vorteil darin liegt dass wenn jemand in seinem Quellcode schreibt "Ich <der Verfasser> ist toll!" dann werden < und > eben auch als solche dargestellt und NICHT als HTML interpretiert! Im Quelltext steht dann für < dieses hier "&lt;" bzw. für > "&gt;" ohne die " " natürlich.

                          PHP-Code:
                          <?php
                          // Nutze diese Funktion bevor du einen String/Text in der DB speicherst um SQL-Injection zu vermeiden
                          function escape($string) {

                              
                          // Wenn magi_quotes an ist, überflüssige Slashes entfernen
                              
                          if (get_magic_quotes_gpc()) {
                                  
                          $string stripslashes($string);
                              }

                              return 
                          mysql_real_escape_string($string);
                          }

                          function 
                          prepare_string($string) {

                              
                          // Slashes
                              
                          $string stripslashes($string);

                              
                          // HTML entfernen
                              
                          $string htmlspecialchars($string);

                              
                          // Zeilenumbrüche entfernen (fürs Anzeigen egal, lässt aber lange Texte im Quellcode in nur einer Zeile anzeigen)
                              
                          $string preg_replace('#[\n\r]#'''$string);

                              return 
                          $string;
                          }
                          ?>

                          Kommentar


                          • #14
                            Gut...das mit'm Formular sollte ja mehr oder weniger über htmlentities() geregelt werden können. Ist damit das Problem aus der Welt geschafft, dass jemand meine Formulare für solche Zwecke nutzen kann? Oder ist es zumindist einer der wichtigen Schritte? (gut, davon gehe ich eigentlich aus)

                            Ich habe mal den Tip bekommen, alles was an Adressen auf der Seite zu finden ist, in ASCII Code umzuwandeln. Hab ich bisher getan, nur zweifel ich ein wenig am Sinn des ganzen. Ich mein, wenn Captchas von den Bots erkannt werden können, dann sowas doch ohne Probleme, oder nicht? Die Ausgabe der Adresse passiert ja sowieso wieder in lesbarer Form.

                            edit: Achso, noch was anderes. Bisher habe ich die Rechteverwaltung auf Basis einer einzelnen Tabelle in meiner SQL-Datenbank bewerkstelligt. Dabei habe ich dem DB-User (der für die Querys verwendet wird) zwar Zugriff auf die gesamte Datenbank gewährt, allerdings mit der Einschränkung, dass er lediglich SELECT,UPDATE,INSERT und DELETE ausführen darf.
                            Das könnte man die untere Ebene nennen.
                            Die obere Ebene, auf PHP gestützt, bezieht sich auf eine Tabelle, die in der Datenbank angelegt wurde. Diese hat die Benutzer und die dazugehörige Binärziffer gespeichert, um die Rechte zu bestimmen. Nun frage ich bei jeder Funktion ab, ob er die Rechte besitzt oder eben nicht.
                            Funktioniert in etwa so...
                            Die Binärwerte sind folgende:
                            100 = Benutzer
                            110 = erweiterte Benutzer
                            111 = Admins

                            Die Prüffunktion fragt jeweils die 1., 2. und 3. Stelle der 3 -stelligen Ziffern ab. Ist 1 an Stelle 3 vorhanden, dann ist der Zugriff als Admin gewährt. Ist 1 an Stelle 2, dann ist der Zugriff als erweiterte.....und so weiter.

                            Ist das eine geeignete Herangehensweise oder ist es besser, wenn man die Zugriffsrechte direkt auf die SQL Benutzer bezieht und dementsprechend die verschiedenen MySQL Anweisungen zugewiesen bzw. nicht zugewiesen bekommen?

                            Kommentar


                            • #15
                              Will jemand mal XSS ausprobiern? Ich hätte da ne Seite wo das funktioniert

                              Die ham haufenweise User aber keinen Plan von nix ^^

                              Die lassen einen sein Profil mit etwas HTML aufpeppen und da war ich doch versucht mal <image onclick="..."> einzubauen und voila es funktioniert

                              Kommentar

                              Lädt...
                              X