Die 25 gefährlichsten Programmierfehler

[Bastian]

Vielleicht allgemein ganz interessant -> klick mich!

Neben Cross-Site-Scripting, SQL-Injection und anderen Banalitäten auch Programmausführung mit unnötigen Rechten.

Ein kleines Checkheft für Anfänger und 'faule' Programmierer ;)

[frankx]

Hellihello

Ein kleines Checkheft für Anfänger und 'faule' Programmierer ;)

Oder eher ein großes?

"Unter denen, die bei der Top-25-Auswahl mitgearbeitet haben, finden sich beispielsweise Symantec, Microsoft, die National Cyber Security Division des Department of Homeland Security und die Information Assurance Division der NSA. Der Anstoß für die Initiative ist von der National Security Agency ausgegangen mit finanzieller Unterstützung durch das die National Cyber Security Division des DHS. Die Ausführung lag bei den Instituten MITRE und SANS (SysAdmin, Audit, Network, Security) ."

http://www.heise.de/security/Die-25-gefaehrlichsten-Programmierfehler--/news/meldung/121611

Dank und Gruß,

frankx

[frankx]

Hellihello

... Interessant mal auch, welche der Fehler auf Webprogrammierungen zutreffen. Buffer-Overflow ja zB. wohl weniger.

Ich dachte, mit kontextspezifischer Maskierung wäre man schon immer einen guten Schritt voran, zumindest was den direkten Austausch per HTTP angeht.

Gegen FTP-Hacker hilft ja wohl nur ein langes und gemischtes Passwort.

Und die Serversicherheit liegt ja für viele eh in den Händen eines Providers. Zumindest habe ich hier im Forum dazu nicht immer Antworten bekommen http://forum.de.selfhtml.org/archiv/2008/12/t180335/#m1191159 - vielleicht hab ich ja auch zu blöd gefragt (oder zu unsicher?)?

Dank und Gruß,

frankx

[Christoph Jeschke]

Guten Tag,

Gegen FTP-Hacker hilft ja wohl nur ein langes und gemischtes Passwort.

Da hilft vorallem, entweder FTPS (mit gutem Passwort) oder gleich etwas SSH-basiertes (mit Passwort, besser ohne und dafür mit Key-basierter Authentifizierung) zu verwenden.

Und die Serversicherheit liegt ja für viele eh in den Händen eines
Providers. Zumindest habe ich hier im Forum dazu nicht immer Antworten
bekommen

Schade. Hatte ich damals übersehen. Ich betreibe eine Umgebung mit suexec und PHP als FastCGI.

Gruß
Christoph Jeschke

[frankx]

Hellihello Christoph,

Schade. Hatte ich damals übersehen. Ich betreibe eine Umgebung mit suexec und PHP als FastCGI.

Naja, antworten kannst Du ja immer noch (;-).

Warum PHP nicht als Modul? PHP-Safe Mode "natürlich" "off"? Und warum suexec. Wenn man damit was falsch macht, ist ja schlimmer als vorher, oder? Und open_base_dir kommt doch auch irgendwie ins Spiel, nicht wahr?

Dank und Gruß,

frankx

[Christoph Jeschke]

Guten Tag,

Warum PHP nicht als Modul?

Weil ich die verschiedenen Projekte, die jeweils ein VHost sind, gerne voneinander trenne: Jedes Projekt hat eigene Folder für Sessiondateien, Uploads, Logs, etc. Jedes Projekt wird als eigener User behandelt.
Zusätzlich ist PHP als Modul (bzw. einige der Extensions) nicht threadsicher, was ich für meinen Worker-MPM-Apache aber benötige. Abschließend ist der Betrieb als FastCGI auch noch deutlich performanter als der Betrieb als CGI oder Modul.

PHP-Safe Mode "natürlich" "off"?

Ja. Denn der Safe_Mode ist kein Sicherheitsfeature, da er sich leicht umgehen lässt. Suexec kann das deutlich besser.

Und warum suexec.

Hauptsächlich zur Nutzertrennung. Ansonsten siehe Manual.

Wenn man damit was falsch macht, ist ja schlimmer als vorher, oder?

Geht es schlimmer als gar keine Nutzertrennung? suexec bewahrt dich vor den größten Problemen (Skripte unter root laufen lassen). Dafür ist die Konfiguration etwas umfangreicher.

Und open_base_dir kommt doch auch irgendwie ins Spiel, nicht wahr?

Ja. Aber da open_basedir genauso wenig wie der safe_mode hunderprozentig funktioniert, verlasse ich mich doch eher auf sorgfältig vergebene Rechte.

Gruß
Christoph Jeschke

[frankx]

Hellihello Christoph,

Warum PHP nicht als Modul?

Weil ich die verschiedenen Projekte, die jeweils ein VHost sind, gerne voneinander trenne: Jedes Projekt hat eigene Folder für Sessiondateien, Uploads, Logs, etc.

Das geht demnach nicht, wenn PHP ein Modul ist?

Jedes Projekt wird als eigener User behandelt.

Das ist ja Voraussetzung für suexec, oder? Die Skripte stammen vom FTP-User und können deshalb nur Skripte einbinden, die dem selben User gehören (es sei denn, man konfiguriert das absichlich anders)?

Zusätzlich ist PHP als Modul (bzw. einige der Extensions) nicht threadsicher, was ich für meinen Worker-MPM-Apache aber benötige.

Das ist dann also wirklich auch das no-go, oder?

Abschließend ist der Betrieb als FastCGI auch noch deutlich performanter als der Betrieb als CGI oder Modul.

Du hast mit MPM und FastCGI also einen merklich schnelleren(=effizienteren) Server?

Und warum suexec.

Hauptsächlich zur Nutzertrennung. Ansonsten siehe Manual.

"However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security."

Das hatte mich jetzt etwas abgeschreckt. Wenngleich das Plesk auf einem virtuellen Server das eben von sich aus mitbringt. In Kombination mit open_base_dir, wenn ich das recht erinnere.

Geht es schlimmer als gar keine Nutzertrennung? suexec bewahrt dich vor den größten Problemen (Skripte unter root laufen lassen). Dafür ist die Konfiguration etwas umfangreicher.

Ich dachte, die Skripte würden sonst unter dem Apachenutzer laufen? Also wwwrun:psaserv (unter Suse/Plesk).

Ja. Aber da open_basedir genauso wenig wie der safe_mode hunderprozentig funktioniert, verlasse ich mich doch eher auf sorgfältig vergebene Rechte.

Dank und Gruß,

frankx

[Christoph Jeschke]

Guten Tag,

Das geht demnach nicht, wenn PHP ein Modul ist?

Das geht schon, da man jeden VHost mit php_admin_*-Settings umkonfigurieren kann. Jedoch fand ich es wesentlich sauberer, jedem Vhost eine eigene php.ini zuzuordnen.

Das ist ja Voraussetzung für suexec, oder?

Nein. Man kann auch alle Skripte unter einer Identität laufen lassen. Das fand ich nur nicht sehr sinnvoll.

Die Skripte stammen vom
FTP-User und können deshalb nur Skripte einbinden, die dem selben User
gehören (es sei denn, man konfiguriert das absichlich anders)?

Was genau meinst du mit einbinden?

Zusätzlich ist PHP als Modul (bzw. einige der Extensions) nicht
threadsicher, was ich für meinen Worker-MPM-Apache aber benötige.

Das ist dann also wirklich auch das no-go, oder?

Ja.

Du hast mit MPM und FastCGI also einen merklich
schnelleren(=effizienteren) Server?

Ja. Mal als Beispiel: Der Server unter lexikon.meyers.de (damals noch ein MediaWiki) wurde als Apache-Preforker+PHP-Modul betrieben. Nach einer Umstellung auf Apache-Worker+PHP-FCGI konnte das System bei ansonsten gleichbleibender Konfiguration 50% mehr Anfragen beantworten.

Das hatte mich jetzt etwas abgeschreckt. Wenngleich das Plesk auf einem
virtuellen Server das eben von sich aus mitbringt. In Kombination mit
open_base_dir, wenn ich das recht erinnere.

Weder open_basedir noch safe_mode sind irgendwie schädlich, jedoch sollte man sich nicht nur auf diese verlassen.

Ich dachte, die Skripte würden sonst unter dem Apachenutzer laufen? Also
wwwrun:psaserv (unter Suse/Plesk).

Das ist eben abhängig von der gewählten Konfiguration.

Gruß
Christoph Jeschke

[frankx]

Hellihello Christoph,

Die Skripte stammen vom
FTP-User und können deshalb nur Skripte einbinden, die dem selben User
gehören (es sei denn, man konfiguriert das absichlich anders)?

Was genau meinst du mit einbinden?

Umgekehrt vielleicht, was ich meine:

mit open_base_dir und suexec kann ein Script des Users FTPUser1 _nicht_ per phps "include" (oder require_once) .../library/Zend/Zend_Loader.php einbinden, wenn dies zB "wwwrun:psaserv" gehört, also jemand anderes. Scripte des FTPUser1 können nur Scripte des FTPUser1 includieren.

Wie aber macht man es in Deiner Konfiguration, dass aus einem zentralen Verzeichnis alle Vhosts/User bestimmte Libraries (PEAR/ZendFW) einbinden können?

Dank und Gruß,

frankx

[Christoph Jeschke]

Guten Tag,

mit open_base_dir und suexec kann ein Script des Users FTPUser1 _nicht_ per
phps "include" (oder require_once) .../library/Zend/Zend_Loader.php
einbinden, wenn dies zB "wwwrun:psaserv" gehört, also jemand anderes.
Scripte des FTPUser1 können nur Scripte des FTPUser1 includieren.

Ok, jetzt habe ich dich verstanden. Nein, das funktioniert natürlich nicht. suexec verhindert, dass die Skripte aufgerufen werden. Der safe_mode prüft ähnlich.

Wie aber macht man es in Deiner Konfiguration, dass aus einem zentralen
Verzeichnis alle Vhosts/User bestimmte Libraries (PEAR/ZendFW) einbinden
können?

Es gibt (bei mir) kein zentrales Verzeichnis mit Libraries, von daher musste ich dieses Problem nicht lösen. Sollte man das aber wollen, könnte man die Libraries automatisch verteilen, nachdem sie aktualisiert wurden. Sowas lässt sich relativ trivial automatisieren (Cronjob der ein PEAR-Update anstößt und nach bestimmten Regeln auf die Projekt-Library-Folder verteilt).

Ich persönlich trenne auch hier jedes Webprojekt, denn die Anforderungen sind doch teilweise sehr unterschiedlich, z.B. könnte ein Projekt eine bestimmte Version eines PEAR-Teils benötigen. Eines meiner Projekte hat sogar eigens kompilierte PECL-Module, die sonst nicht benötigt werden (und daher sonst auch nicht geladen werden müssen).

Gruß
Christoph Jeschke

[frankx]

Hellihello Christoph,

Ich persönlich trenne auch hier jedes Webprojekt, denn die Anforderungen sind doch teilweise sehr unterschiedlich, z.B. könnte ein Projekt eine bestimmte Version eines PEAR-Teils benötigen. Eines meiner Projekte hat sogar eigens kompilierte PECL-Module, die sonst nicht benötigt werden (und daher sonst auch nicht geladen werden müssen).

Das Modul muss geladen werden, die Pear/Zend-Klassen ja nur bei Bedarf. Es ist ja eigentlich Platzverschwendung (16MB), wenn man das nicht zentral anbietet. Zumal man sich dann pro Projekt auch nicht erst das zusammensuchen muss, was man braucht.

Kann man mit suexec dem Skript denn nicht die Rechte für zwei User geben, und einen globalen AbstractZendUser haben?

Dank und Gruß,

frankx

[Christoph Jeschke]

Guten Tag,

Das Modul muss geladen werden, die Pear/Zend-Klassen ja nur bei Bedarf. Es
ist ja eigentlich Platzverschwendung (16MB), wenn man das nicht zentral
anbietet. Zumal man sich dann pro Projekt auch nicht erst das
zusammensuchen muss, was man braucht.

Speicherplatz ist sehr billig, heutzutage.

Kann man mit suexec dem Skript denn nicht die Rechte für zwei User geben,
und einen globalen AbstractZendUser haben?

Nein.

Gruß
Christoph Jeschke

[hotti]

hi,

da steht
CWE-319: Cleartext Transmission of Sensitive Information

Kann mir mal jemand erklären, warum die Wahl eines unzweckmäßigen Übertragungsprotokolls (z.b. http statt https) ein Fehler des Programmierers sein soll?

Hotte

[Christoph Jeschke]

Guten Tag,

Kann mir mal jemand erklären, warum die Wahl eines unzweckmäßigen
Übertragungsprotokolls (z.b. http statt https) ein Fehler des
Programmierers sein soll?

Auch Programme verwenden Übertragungsprotokolle. Zum Beispiel könnte ein Programmierer eine Clientsoftware für ein CMS schreiben, welche Uploads nur über FTP oder HTTP durchführen kann.

Gruß
Christoph Jeschke

[hotti]

moin,

Kann mir mal jemand erklären, warum die Wahl eines unzweckmäßigen
Übertragungsprotokolls (z.b. http statt https) ein Fehler des
Programmierers sein soll?

Auch Programme verwenden Übertragungsprotokolle. Zum Beispiel könnte ein Programmierer eine Clientsoftware für ein CMS schreiben, welche Uploads nur über FTP oder HTTP durchführen kann.

Das ist schon klar. Aber letztendlich entscheidet ein Programmierer nicht ausschließlich eigenständig, ob sichere oder unsichere Protokolle verwendet werden.

Vielmehr hat dabei der Auftragggeber eine gehörige Portion mitzureden, so habe ich das gelernt.

Hotte

[Christoph Jeschke]

Guten Tag,

Das ist schon klar. Aber letztendlich entscheidet ein Programmierer nicht
ausschließlich eigenständig, ob sichere oder unsichere Protokolle verwendet
werden.

Vielmehr hat dabei der Auftragggeber eine gehörige Portion mitzureden, so
habe ich das gelernt.

Wenn der Programmierer wieder besseren Wissens kein sicheres Protokoll einsetzen darf, ist dies kaum ein Programmierfehler, sondern Absicht.

Gruß
Christoph Jeschke