1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › PHP: Rechenaufgabe legt Server…

Workaround (PHP)

  1. Thema

Neues Thema Ansicht wechseln


  1. Workaround (PHP)

    Autor: core 04.01.11 - 21:00

    Ungetestet, da ich selbst nur noch 64 bit-Systeme habe.

    prevent_num_err.php:
    http://pastebin.com/ctfCBMvR

    prevent_num_err_test.php:
    http://pastebin.com/ihwknwJN

    Viele Grüße,
    Denis

  2. Re: Workaround (PHP)

    Autor: verysmall 04.01.11 - 23:57

    versuche 222.50738585072011e-310 ;)

  3. Re: Workaround (PHP)

    Autor: w13531 05.01.11 - 00:15

    ich würde daten löschen nicht unbedingt als workaround ansehen.....

  4. Re: Workaround (PHP)

    Autor: ThiefMaster 05.01.11 - 00:19

    Du kennst foreach?
    foreach($array as $key => $value)

    Dieser list/each-Krempel stammt aus PHP3-Zeiten.

  5. Re: Workaround (PHP)

    Autor: Dieter Cee 05.01.11 - 00:47

    Kommt darauf an wie man Workaround definiert... :-)

  6. Re: Workaround (nicht PHP)

    Autor: Meister Bit 05.01.11 - 00:48

    auf VB ausweichen...

  7. hahaha ... typisch PHPler :)

    Autor: nussknacker 05.01.11 - 03:07

    core schrieb:
    --------------------------------------------------------------------------------
    > Ungetestet, da ich selbst nur noch 64 bit-Systeme habe.

    OK, gibt (vermutlich) auch gute PHP-Programmierer, aber einen Workaround veröffentlichen ... ungetestet ... no comment. :)

  8. Re: Workaround (PHP)

    Autor: blubbb 05.01.11 - 11:05

    Ne also wirklich, wegen solcher IMHO "eigenartigen" Konstrukte hat PHP u.a. so ein miesen Ruf.

    Die wenigsten PHP Webanwendungen werden eine 2.2250738585072011e-308 von außen erwarten oder überhaupt damit rechnen müssen, daher gilt schon mal:

    1. Variablen die von außen ( $_POST & $_GET )kommen sind immer potentiell schädlich.

    2. Potentiell schädliche Daten *müssen* *immer* gefiltert und validiert werden.

    3. Frameworks wie z.B. Zend Framework bieten einfache objektorientierte Möglichkeiten genau das zu machen.

    > http://framework.zend.com/manual/de/zend.filter.input.html

    Ob das Zend Framework gut oder schlecht ist sei mal dahin gestellt aber es ist IMHO z.Z. das umfangreichste Framework für PHP.

  9. Re: Workaround (PHP)

    Autor: Ellis 05.01.11 - 12:41

    blubbb schrieb:
    --------------------------------------------------------------------------------
    > 2. Potentiell schädliche Daten *müssen* *immer* gefiltert und validiert
    > werden.

    2.2250738585072011e-308 ist ja eine valide Zahl. Wenn ich weiß, dass ich sie nie benötige, kann ich sie natürlich ausschließen, muss allerdings auch alle möglichen Exponenten beachten (wie verysmall schrieb). Zu Lasten der Genauigkeit aller Zahlen könnte man auch die Länge der Mantisse begrenzen.

    Aber ich frage mich, wieviele Programmierer alle Eingabeparameter erst als String (!) validieren und danach erst Typecasten und den Wertebereich als Zahl validieren. Egal ob mit Zend_input_filter oder manuell.

  10. Von wegen

    Autor: AmigoJack 05.01.11 - 12:52

    Leute! Es reicht allein schon die Anweisung

    <?php
    $foo= 2.2250738585072011e-308;
    ?>

    ...als Aufhänger. Es geht gar nicht um Eingaben von draußen - das kann genausogut von DBMSen oder Dateien erfasst werden und dann ebenfalls so unglücklich angefasst werden. Gerade bei letzterem geht man doch am ehesten von der Denkweise "hey, die Datei hab nur ich angelegt - die wird nie verändert und da kann nur Text drin sein" aus.

    Im übrigen ist es ein GCC-Bug - da könnt ihr auch PHP generell vorwerfen, dass der genausowenig all seine Zulieferer und Verarbeiter prüft.

  11. Re: Von wegen

    Autor: Ellis 05.01.11 - 13:22

    AmigoJack schrieb:
    --------------------------------------------------------------------------------
    > ...als Aufhänger. Es geht gar nicht um Eingaben von draußen - das kann
    > genausogut von DBMSen oder Dateien erfasst werden und dann ebenfalls so
    > unglücklich angefasst werden.

    Ja aber hättest du diesen Code in deinen Dateien, würdest du schon beim ersten Test den Fehler bemerken.

    Bei Datenbanken bin ich nicht sicher, denn wenn die Zahl bereits als double vorliegt, gibt es keine Probleme. Wenn man natürlich die Zahl als String in der DB vorhält, sodass man wieder über zend_strtod stolpert, naja dann ist man auch selbst Schuld.

  12. Re: Von wegen

    Autor: blubbb 05.01.11 - 13:52

    AmigoJack schrieb:
    --------------------------------------------------------------------------------
    > Leute! Es reicht allein schon die Anweisung
    >
    > <?php
    > $foo= 2.2250738585072011e-308;
    > ?>

    Eingabewerte über $_POST und $_GET kommen als String an, erst wenn daraus eine Zahl wird, kommt es zu diesem Fehler, so versteh ich jedenfalls den Artikel siehe:

    "Bei einem Angriff muss die Zahl lediglich als *numerischer Wert* übergeben werden. "

    Wenn man nun seine Eingabeparameter überprüft und nur in den Grenzen zulässt die wirklich benötigt werden, sollte man zu mindestens Angriffe von außen vermeiden können.

  13. Re: Von wegen

    Autor: blubbb 05.01.11 - 14:00

    Ach vergesst das ganze, bin heute nicht so ganz bei der Sache -.-

    Um die Grenzwerte zu überprüfen wird der Eingabewert ja in einen nummerischen Wert gecastet...


    Validieren und filtern ist trotzdem ein muss für den Input ;)

  14. Re: Von wegen

    Autor: Rafi 05.01.11 - 17:54

    Hier noch ein workaround, der PHP-sites zumindest vor Script-Kiddies schützt, die jetzt überall dei bösen Zahlen in GET-Parameter einfügen.

    http://www.aircraft24.com/en/info/php-float-dos-quickfix.htm

    Löscht einfach die entsprechende Variable, wenn die üblen Zahlen als Parameter übergeben werden (auch HTTP_POST). Ist ein wenig "quick und dirty" und eignet sich daher nicht für das Betriebssystem einer Herz-Lungen-Maschine. Sollte aber fürs erste automatisierten Bots den Hahn abdrehen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Phoenix Contact Electronics GmbH, Bad Pyrmont
  2. Artschwager & Kohl Software GmbH, Herzogenaurach
  3. DREWAG - Stadtwerke Dresden GmbH, Dresden
  4. Deutscher Akademischer Austauschdienst e.V. (DAAD), Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 362,06€ (Bestpreis!)
  2. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de