1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Interview: Umstieg auf…

Sicherheitslücken

  1. Thema

Neues Thema Ansicht wechseln


  1. Sicherheitslücken

    Autor: RipClaw 17.10.07 - 15:34

    Um die zur Zeit schlimmsten Lücken in PHP Skripten direkt von der Sprache aus dicht zu machen müsste man mal über folgende Maßnahmen bei PHP nachdenken:

    * Abschaffung der globalen Variablen (wird in PHP6 glaub ich sogar gemacht)
    * Bei den Befehlen include und require generell keine URLs mehr erlauben oder alternativ müssen Urls über eine Whitelist freigegeben werden.
    * Ein Filter für den Upload der von Haus aus sehr restriktiv eingestellt ist und bei dem man erst die entsprechenden Dateitypen explizit via Whitelist freigeben muß.
    * Für Administratoren die Möglichkeit einer Blackliste von Funktionen die pro virtuellem Host oder Verzeichnis eingestellt werden kann. So können Funktionen wie shell_exec, exec, system & Co global deaktiviert werden und speziell für einzelne Benutzer freigegeben werden.

    Mit Suhosin kann man das zum größten Teil schon jetzt realisieren.
    Wäre schön wenn diese Möglichkeiten direkt ins PHP integriert werden würden.

    Ich weiß das die Unsicherheit durch Schlampige Programmierung der Skript kommt aber da die Programmierer solcher Skripte wohl auf Sicherheit keinen großen Wert legen muß man sie wohl zu ihrem Glück zwingen :-)

  2. Re: Sicherheitslücken

    Autor: xaff 17.10.07 - 18:43

    RipClaw schrieb:
    -------------------------------------------------------
    > Um die zur Zeit schlimmsten Lücken in PHP Skripten
    > direkt von der Sprache aus dicht zu machen müsste
    > man mal über folgende Maßnahmen bei PHP
    > nachdenken:
    >
    > * Abschaffung der globalen Variablen (wird in PHP6
    > glaub ich sogar gemacht)

    Da soll was gemacht werden, ob es eine komplette Abschaffung wird weiss ich aus dem Stehgreif aber nicht mehr. Zumindest wurde mit PHP5 register_globals standardmäßig auf Off gestellt.

    > * Bei den Befehlen include und require generell
    > keine URLs mehr erlauben oder alternativ müssen
    > Urls über eine Whitelist freigegeben werden.

    allow_url_fopen, allow_url_include, gibt´s also schon wenn auch leider löchrig durch Input-Streams.

    > * Ein Filter für den Upload der von Haus aus sehr
    > restriktiv eingestellt ist und bei dem man erst
    > die entsprechenden Dateitypen explizit via
    > Whitelist freigeben muß.

    Hm, der dürfte aber nicht greifen beim Upload von Scripten irgendeiner Art.

    > * Für Administratoren die Möglichkeit einer
    > Blackliste von Funktionen die pro virtuellem Host
    > oder Verzeichnis eingestellt werden kann. So
    > können Funktionen wie shell_exec, exec, system
    > & Co global deaktiviert werden und speziell
    > für einzelne Benutzer freigegeben werden.

    Gibt es auch bereits: disable_functions

    >
    > Mit Suhosin kann man das zum größten Teil schon
    > jetzt realisieren.
    > Wäre schön wenn diese Möglichkeiten direkt ins PHP
    > integriert werden würden.
    >
    > Ich weiß das die Unsicherheit durch Schlampige
    > Programmierung der Skript kommt aber da die
    > Programmierer solcher Skripte wohl auf Sicherheit
    > keinen großen Wert legen muß man sie wohl zu ihrem
    > Glück zwingen :-)
    >


  3. Re: Sicherheitslücken

    Autor: RipClaw 17.10.07 - 22:15

    xaff schrieb:
    -------------------------------------------------------
    > RipClaw schrieb:
    > --------------------------------------------------
    > -----
    > > Um die zur Zeit schlimmsten Lücken in PHP
    > Skripten
    > direkt von der Sprache aus dicht zu
    > machen müsste
    > man mal über folgende Maßnahmen
    > bei PHP
    > nachdenken:
    >
    > * Abschaffung
    > der globalen Variablen (wird in PHP6
    > glaub
    > ich sogar gemacht)
    >
    > Da soll was gemacht werden, ob es eine komplette
    > Abschaffung wird weiss ich aus dem Stehgreif aber
    > nicht mehr. Zumindest wurde mit PHP5
    > register_globals standardmäßig auf Off gestellt.

    Das war schon ab PHP 4.3 so.
    Leider gibt es das überhaupt noch, so das Leute die alte Skripte am laufen haben diese noch weiter verwenden können ohne sich die Mühe machen zu müssen sie mal sicher zu machen.

    Du glaubst garnicht welche Heulsusen die Leute sein können wenn es darum geht das sie mal ihre Skripte die sie anno dazumal geschrieben haben überarbeiten müssen. Hab ich schon dutzendfach erlebt.

    > > * Bei den Befehlen include und require
    > generell
    > keine URLs mehr erlauben oder
    > alternativ müssen
    > Urls über eine Whitelist
    > freigegeben werden.
    >
    > allow_url_fopen, allow_url_include, gibt´s also
    > schon wenn auch leider löchrig durch
    > Input-Streams.

    Nur kann man dummerweise allow_url_include bzw. allow_url_fopen auf On schalten.
    Wenn man zumindestens eine Whitelist vorgeben muß kann keine beliebige URL aufgerufen werden wenn allow_url_include auf On steht.

    > > * Ein Filter für den Upload der von Haus aus
    > sehr
    > restriktiv eingestellt ist und bei dem
    > man erst
    > die entsprechenden Dateitypen
    > explizit via
    > Whitelist freigeben muß.
    >
    > Hm, der dürfte aber nicht greifen beim Upload von
    > Scripten irgendeiner Art.

    Doch, wenn man als Typ nur Bilder zulässt.

    > > * Für Administratoren die Möglichkeit
    > einer
    > Blackliste von Funktionen die pro
    > virtuellem Host
    > oder Verzeichnis eingestellt
    > werden kann. So
    > können Funktionen wie
    > shell_exec, exec, system
    > & Co global
    > deaktiviert werden und speziell
    > für einzelne
    > Benutzer freigegeben werden.
    >
    > Gibt es auch bereits: disable_functions

    Nur ist das nicht pro Verzeichnis bzw. pro Virtuellem Host verfügbar.
    Das ist eine der Einstellungen die nur in der php.ini vorgenommen werden kann.

    Wenn man PHP als CGI oder mit suPHP laufen lässt kann man für jeden Benutzer eine eigene php.ini festlegen. Dann ist es möglich pro Benutzer die Funktionen zu sperren oder aber auch nicht.

  4. Re: Sicherheitslücken

    Autor: xaff 17.10.07 - 23:50

    RipClaw schrieb:
    -------------------------------------------------------
    > xaff schrieb:
    > --------------------------------------------------
    > -----
    > > RipClaw schrieb:
    >
    > --------------------------------------------------
    >
    > -----
    > > Um die zur Zeit schlimmsten
    > Lücken in PHP
    > Skripten
    > direkt von der
    > Sprache aus dicht zu
    > machen müsste
    > man
    > mal über folgende Maßnahmen
    > bei PHP
    >
    > nachdenken:
    >
    > * Abschaffung
    > der
    > globalen Variablen (wird in PHP6
    > glaub
    >
    > ich sogar gemacht)
    >
    > Da soll was gemacht
    > werden, ob es eine komplette
    > Abschaffung wird
    > weiss ich aus dem Stehgreif aber
    > nicht mehr.
    > Zumindest wurde mit PHP5
    > register_globals
    > standardmäßig auf Off gestellt.
    >
    > Das war schon ab PHP 4.3 so.
    > Leider gibt es das überhaupt noch, so das Leute
    > die alte Skripte am laufen haben diese noch weiter
    > verwenden können ohne sich die Mühe machen zu
    > müssen sie mal sicher zu machen.

    Doch, ich glaube es und ich kenne es sogar. Oftmals liegt es aber auch daran, dass die Leute die da jammern nicht die Leute sind, die den Müll verbrochen haben. Es gibt durchaus noch das ein oder anderepopuläre Projekt, dass auf solchen Müll aufbaut.

    >
    > Du glaubst garnicht welche Heulsusen die Leute
    > sein können wenn es darum geht das sie mal ihre
    > Skripte die sie anno dazumal geschrieben haben
    > überarbeiten müssen. Hab ich schon dutzendfach
    > erlebt.
    >
    > > > * Bei den Befehlen include und
    > require
    > generell
    > keine URLs mehr
    > erlauben oder
    > alternativ müssen
    > Urls
    > über eine Whitelist
    > freigegeben werden.
    >
    > allow_url_fopen, allow_url_include, gibt´s
    > also
    > schon wenn auch leider löchrig
    > durch
    > Input-Streams.
    >
    > Nur kann man dummerweise allow_url_include bzw.
    > allow_url_fopen auf On schalten.
    > Wenn man zumindestens eine Whitelist vorgeben muß
    > kann keine beliebige URL aufgerufen werden wenn
    > allow_url_include auf On steht.

    Das ist aber ein Problem der Hoster bei Shared Hosts und es läge durchaus in deren Interesse es zu deaktivieren.

    >
    > > > * Ein Filter für den Upload der von Haus
    > aus
    > sehr
    > restriktiv eingestellt ist und
    > bei dem
    > man erst
    > die entsprechenden
    > Dateitypen
    > explizit via
    > Whitelist
    > freigeben muß.
    >
    > Hm, der dürfte aber
    > nicht greifen beim Upload von
    > Scripten
    > irgendeiner Art.
    >
    > Doch, wenn man als Typ nur Bilder zulässt.

    Okay, da stimme ich zu.

    >
    > > > * Für Administratoren die
    > Möglichkeit
    > einer
    > Blackliste von
    > Funktionen die pro
    > virtuellem Host
    > oder
    > Verzeichnis eingestellt
    > werden kann. So
    >
    > können Funktionen wie
    > shell_exec, exec,
    > system
    > & Co global
    > deaktiviert
    > werden und speziell
    > für einzelne
    >
    > Benutzer freigegeben werden.
    >
    > Gibt es
    > auch bereits: disable_functions
    >
    > Nur ist das nicht pro Verzeichnis bzw. pro
    > Virtuellem Host verfügbar.
    > Das ist eine der Einstellungen die nur in der
    > php.ini vorgenommen werden kann.

    Nein, das stimmt so nicht generell. Je nach konfiguration kannst Du auch über die htaccess verzeichnisspezifische Einstellungen für PHP vornehmen. Pro virtuellem Hosts kannst Du sowieso schon über die httpd.conf und übergetrennte php.ini Einstellungen vorgeben.

    >
    > Wenn man PHP als CGI oder mit suPHP laufen lässt
    > kann man für jeden Benutzer eine eigene php.ini
    > festlegen. Dann ist es möglich pro Benutzer die
    > Funktionen zu sperren oder aber auch nicht.
    >

    Wie oben erwähnt, geht auch mit PHP als Modul mit Einschränkungen. Nichtsdestotrotz stimmt es natürlich, dass es durchaus einige sehr sinnvolle Sicherheitsoptionen gibt, die in PHP einfließen sollen. Ein Punkt den ich sehr sinnvoll fände wäre ein tainted-mode und eine strict-option für eine optionale strenge Typisierung.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Klinikum der Universität München, München
  2. Süddeutsche Krankenversicherung a.G., Fellbach bei Stuttgart
  3. Team GmbH, Paderborn
  4. Amprion GmbH, Pulheim-Brauweiler bei Köln

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. gratis (bis zum 12. April)
  2. 799€ statt 934€ im Vergleich
  3. (Canon EOS 250D Spiegelreflexkamera, 24,1 Megapixel mit Objektiv 18-55 mm (7,7 cm Touchscreen...


Haben wir etwas übersehen?

E-Mail an news@golem.de