Auf Thema antworten 2026

JavaScript ist deaktiviert. Für eine bessere Darstellung aktiviere bitte JavaScript in deinem Browser, bevor du fortfährst.

Beitrag: <blockquote data-quote="Curanai" data-source="post: 2279080" data-attributes="member: 534923">AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...Moinsen, vorab: Ich bin seit 1999 u. a. bei 1&1 (Server; root wie managed) ... kann auch gar nicht meckern. Klar stolpert mal das eine oder andere Vorhaben, aber richtig verbockt wurde in der Zeit sehr wenig. Bei Hoster-Wahl gibt es immer einiges zu beachten: "wen will ich erreichen" (wenn Du für China was anbietest, brauchst in GER keinen Hoster etc.), Redundanz und "fallback" bei Ausfall, Erreichbarkeit, Backup, Support (gern auch eine kostenlose Hotline!), Premium-Service (wenn echt mal Alarm ist!) usw.Das Thema Sicherheit ... hierzu gibt es wunderbare Bücher, die Dir das sehr detailliert aufzeigen. Auch in diesem Thread kommt wieder viel "aus unserer Erfahrung", also stinke ich ein wenig darüber mit: mysql_(real_)escape_string und htmlentites() ist zu wenig! Gut, dass hier schon nachgelegt wurde ... <img src="/styles/default/xenforo/smilies/zwinker.gif"  class="smilie" loading="lazy" alt=";)" title="Wink    ;)" data-shortname=";)" />Fakt ist aber: Eine "config.inc.php" muss nicht mit einer weiteren .htaccess "versiegelt" werden - diese rennt eh aufgrund Endung durch den Interpreter (PHP). Eine htaccess macht nur dann - IMO - Sinn, wenn das Teil "config.inc" einfach nur heißt - eine htaccess wäre dann:[code]<Files ~ "\.inc$">Order allow, denyDeny from all</Files>[/code]Hüte Dich in der "config.inc.php" vor "god modes" (bspw. deplatzierter "autoload"-Call, wenn was fehlt - brich lieber ab!), Rückgabewerten (via return) o. ä. Konstanten mit hochindividuellen Namen "fits it".Und msa1989 muss ich leider sagen: Backup-Dateien haben auf einem produktiven Webserver GAR NICHTS verloren!!! (ich komme drauf wegen der Berücksichtigung von "bak" in Deiner htaccess). Unter Umständen machst Du das "für den Fall, dass mal was durchrutscht", aber das darf schon nicht ... <img src="/styles/default/xenforo/smilies/zwinker.gif"  class="smilie" loading="lazy" alt=";)" title="Wink    ;)" data-shortname=";)" />Ist das Dein eigener geschriebener Shop oder verwendest Du einen Drittanbieter? Ist mir nicht ganz klar ... bedenke, dass die Administrationsoberflächen haben (gilt für Foren, CMS etc. genauso). Und darin sind wieder Plugins ... diese sind angreifbar, wenn nicht "versiegelt" (erinnere mich immer nur ungern an den JCE-Editor von Joomla ... *kotz*).Als Angreifer schaue ich mir zuerst eine "robots.txt" an - hier geben die Leute gern an, was Suchmaschinen nicht spidern sollen ... Directory-Listing unbedingt aus ...Kommentare, die Usernamen oder Pfadangaben im Quellcode enthalten, unbedingt raus ...Ausgelieferten Header an den Client runterkürzen: Verzeichte auf Angaben zur PHP-Version, Apache usw. ... so wenig Angriffsfläche wie möglich anbieten. Dazu gehört: phpinfo() gehört nicht auf ein Produktivsystem - egal wo!Konform gehe ich auch nicht mit "wenn es in dem Verzeichnis 'drüber' liegt, kommt man da nicht hin" - regulär nicht, mit einer Webshell, die per Bildupload hochgeschickt wird, definitiv! Ich kann nicht schreiben - aber lesen (und zwar ganz runter!; Linux). Was noch? Cookie-Poisoning, -Stealing, Session-Capturing ... verwende niemals nicht für Deine Session oder Cookies das Standardverzeichnis ... schon gar nicht bei "sharedHosting" oder "Webpaketen" ... 1x am Tag spätestens alle Sitzungen für ungültig erklären. Cookies behandeln wie Eingabedaten vom User ... = hochgiftig!Vor Speichern Sonderzeichen immer maskieren - was passiert bei Dir in folgendem Szenario? = javascript ... eine andere Schreibweise ... IE führte das bspw. mal direkt in den Ursprung übersetzt aus ... berücksichtige also mit hexedezimal kodierte Tabulatoren, Newlines, Nullbytes und Blanks etc. Denn: Aus "<" mache ich auch "< oder "< ... ein Filter ist also nicht permissiv, sondern sollte restriktiv agieren! Heißt: Nicht säubern! Ablehnen!!! (ja, hier greift das Minimum aus htmlentities() - keine Bange)Hässlich wird es in der Kombination aus XSS, CSRF und DOM-Manipulation - da sind die Möglichkeiten irgendwie "grenzenlos".Für Deine App gilt, nimm das an, was Du erwartest und versuche vorab mit Cast-Operatoren zu hantieren. Gib nie irgendwas ungeprüft in die Datenbank und diese sollte mit "prepared statements" arbeiten, damit keine ganzen SQL-Queries abgegeben werden - sondern nur noch die überarbeiteten Daten (maskiert usw.).Nur bedenke: Es gibt keine 100%ige Sicherheit - das ist Utopia und sollte Dir auch niemand verkaufen. Du kannst vieles unternehmen, um es einem Angreifer schwerer zu machen ... und je mehr Du unternimmst, umso größer die Chance, dass er aufgibt ...Finaler Tipp: Alles, was Fehler auf Deinem Projekt produziert, kommt direkt per E-Mail mit $_POST, $_GET, IP, Query(-Versuch) usw. zu Dir ...Sorry für den Umfang, aber das Thema "Sicherheit" ist eben sehr umfangreich, wobei hier längst nicht alles erwähnt ist.Viel Erfolg und ein schönes Wochenende.</blockquote> Bilder bitte hier hochladen und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.

Authentifizierung: Wenn ★ = 12, ◇ = 4 und die Hälfte von ★ zu ◇ addiert wird, was ist das Ergebnis?