[Funktion] Bildfunktion funktioniert mit neuer PHP 4.1 Version nicht mehr

[der_milchmann]

Folgende Funktion für die Erzeugung von Thumbnails hatte immer gut funktioniert, geht auf einmal nicht mehr.

Ein Kollege meinte, eine TOUCH() FUnktion müsse ich einfügen, weiss aber nicht wo.


$TN = "TN";
$PicPathIn="galerie/$ordner/";

$PicPathOut="galerie/out/";
$Thumbnail=$PicPathOut."$ordner"."$TN".$bild;

if(!(file_exists($Thumbnail)))
{
$size=getimagesize("$PicPathIn"."$bild");
$breite=$size[0];
$hoehe=$size[1];
$neueBreite=49;
$neueHoehe=$hoehe*$neueBreite/$breite;
$size[2]==2;
$altesBild=ImageCreateFromJPEG("$PicPathIn"."$bild");
$neuesBild=ImageCreateTruecolor($neueBreite,$neueHoehe);
ImageCopyResampled($neuesBild,$altesBild,0,0,0,0,$neueBreite,$neueHoehe,$breite,$hoehe);
ImageJPEG($neuesBild,"$PicPathOut"."$ordner"."$TN"."$bild");
}


Folgender Fehler wird gezeigt:

Warning: imagejpeg(): Invalid filename
'../beispiel.jpg' in html/head.php
on line 65

[onemorenerd]

Schätzungsweise vor imagejpeg() ...
http://php.net/touch
http://php.net/manual/en/language.types.string.php

[BenOmania]

"neuer PHP 4.1 Version" trifft es ja nicht so ganz
*scnr*

[der_milchmann]

Hilft nix, touch funktioniert auch nicht - muss wohl ein neues script her.
Danke dennoch

[der_milchmann]

Nachtrag: Vielleicht kann mir doch einer helfen - und zwar in einer Erklärungssache:

Ich habe alles mögliche versucht, es läuft kein einziges Script, alle scheitern mit Unable to access - also kein Zugriff, alles auf CHMOD 777 geschaltet - testhalber - nix geht.

Mein Provider meinte nun, er haben vor kurzem SAFE MOD deaktiviert - ich weiss nicht, was das sein soll, nun muss man eine Gebühr zahlen, um es wieder freizuschalten - wo liegt der Sinn, dass er es auf einmal aktiviert hat ? Auf meinem 1und1 Account läuft das Script einwandfrei, auf meinem anderen mit besagtem Provider nicht - Fehler wie gesagt Unable to access ...


Was würdet ihr mir raten? Was heisst Safe Mod?

[Kropff]

Was würdet ihr mir raten? Was heisst Safe Mod?

google ist dein freund

gruß
peter

[der_milchmann]

Danke für die Info, das ganze hört sich nicht wirklich danach an, als ob mein Provider wüsste, was er da tut - hab ich nur den EIndruck oder ist es wirklich so?

Sowas müsste doch normal auch anders zu lösen sein, ohne dass der User seine ganzen Scripte umschreiben muss. Oder ist tatsächlich in diesem Falle für Provider das der einzige Weg?

[onemorenerd]

Der weiß bestimmt sehr genau, was er tut. Zumindest viel genauer als jeder User, der seine Scripte nicht selbst umschreiben kann (der weiß nämlich auch nicht um die Gefahr).
Finde ich auch einen interessanten Ansatz: Wer seine Scripte nicht SafeMode-konform schreibt, muß mehr bezahlen. Entstandener Schaden oder vorsorgliche Sicherheitsmaßnahmen werden also von den wirklich nachlässigen Usern bezahlt, die 'braven' läßt man in Ruhe.

[der_milchmann]

Interessant schon - nur finde ich die Methodik ebenfalls interessant, ohne Vorwarnung einfach alle bisher funktionierenden Scripte unbrauchbar zu schalten.

Übrigends finde ich, nicht jeder, der ein PHP Script schreibt, muss zuvor Informatik studiert haben. Für die Sicherheit des Serverbetriebs sollte nicht der User sondern der Provider zuständig sein, für Probleme, die auf meinem Webspace durch meine Scripte verursacht werden, sind meine Probleme. Und ich hatte mir obigen noch nie welche. Zwar behaupten X sogenannte Hacker, sich durch diese und jene Scripte Zugang verschaffen zu können, komischerweise nahm bislang niemand das Angebot an, es bei meinem Webspace mal zu probieren, die Logdatei findet zwar kläglich gescheiterte Versuche, extern z.B: etwas in meinen Bilderordner zu laden, aber alles mehr oder minder heisse Luft.

Da ist jedes BulletBoard wie dieses hier ebenso anfällig gegen Exploits wie jede private Webseite. Mit dem unterschied, dass ein individuell programmiertes Script viel schwerer zu durchschauen ist, als ein Board, dessen Code frei im Netz rumschwirrt und die Sicherheitslücken gibts mit einem Stück Kuchen + Kaffee per Google.de dazu.

[wahsaga]

Original geschrieben von der_milchmann
Für die Sicherheit des Serverbetriebs sollte nicht der User sondern der Provider zuständig sein

Und um diese Pflicht zu erfüllen, kann er u.a. den Safe Mode anschalten, um den Zugriff auf fremde Userverzeichnisse (mutwillig, oder von extern durch schlecht geschriebene Scripte) halbwegs zuverlässig zu unterbinden - was ohne Safe Mode (und open_basedir) in Umgebungen, in denen PHP als Modul läuft und damit alle User alle Zugriffsrechte des Apache-Users haben, schwerlich möglich ist.

Um es zusammenzufassen, du beschwerst dich also darüber, dass dein Provider versucht hat, die Sicherheit zu erhöhen, und siehst dies gleichzeitig aber als eine seiner Aufgaben an.
Die Aufgabe "widerspreche dir selber" hast du mit Bravour gelöst.

[goth]

Original geschrieben von der_milchmann
... Mit dem unterschied, dass ein individuell programmiertes Script viel schwerer zu durchschauen ist, als ein Board, dessen Code frei im Netz rumschwirrt und die Sicherheitslücken gibts mit einem Stück Kuchen + Kaffee per Google.de dazu.

So ein blödsinn ... und die Standard Anfänger Idioten Fehler zu scannen gibt's mittlerweile haufenweise Tools ... haufenweise!

[der_milchmann]

So? Und wieso werden dann primär sofort bei Bekanntwerden von Lücken diverser Boards (wie diesem hier) Bretter haufenweise gesucht und versucht, zu befallen (nicht jeder Privatuser updated sofort seine Software, die meisten haben uralte Bretter drauf).

Kleines Beispiel?
Ds WMA Exploit wurde wunderbar über diese Art verbreitet.


Mein eigen programmiertes PHP/MySQL Forum besitzt bessere SPAM/Flood Sperren als jedes andere Free-Board.

Grund? Weil ich individuell scripte und das Ding Routinen kennt, die der Angreifer nicht kennt.

Ich kann mir in einem Bulletboard systematisch Schwachstellen rauspicken, sie zuhause auf localhost schön durchleuchten und online den großen Supergau planen.

Seltsamerweise kenne ich niemanden, der auf seiner privat betriebenen Seite Angriffe hatte oder dergleichen - komischerweise sind auch individualisierte Seiten weniger oft von so etwas betroffen, als standardisierte CMS Software.

Die Tools mag es geben - zeig sie mir mal und ich lass sie über meine Seite laufen - auch per Private Message.

Vergleichbar ist das im Übrigen mit Outlook. Es gibt Tausend andere Mail Programme mit vielleicht 10 000 x Schwachstellen und Lücken mehr - wieso das nicht so tragisch ist, wie nur 1 einzige bekannte Lücke in Outlook? Liegt ja wohl auf der Hand.

Ein wenig genutztes (hier individuell programmierte Webseite) System ist weitaus uninteressanter für Angreife als ein standardisiertes bekanntes System (Vergl. Schneeballsystem bzw. Effekt).

In meinen Augen vollkommen logisch, wer macht sich die Mühe, wenns darum geht, eine einzige Homepage zu knacken, deren Routinen herauszufinden, wenn man (im Sinne eines Hackers) viel mehr Schaden anrichten kann, wenn man ein Brett nach Schwachstellen abgrast, das im Netz 50 000 mal verwendet wird uns superleicht per Google.de zu finden ist?

Die Frage beantwortet sich selbst.


@wahsaga: Nicht traurig sein, du hast mein Problem nicht gelesen oder nicht verstanden.

[ghostgambler]

omg, du gehst von Skriptkiddies aus ... ein "Hacker" hat interesse daran in EIN BESTIMMTES System zu kommen

[der_milchmann]

Ok, du hast Recht, ich muss mit den Begriffen vorsichtig sein, ich meinte tatsächlich Script Kiddies - die meist kein finanzielles Interesse haben, sondern einfach nur sich daran ergötzen wollen, zu sehen, wie ein Admin mit seiner Seite um Schadensbegrenzung kämpft.

Hacker haben zumeist finanzielle oder wirtschaftliche - oder andere - oft (nicht immer) tiefgründigere Ambitionen - und wenn es "nur" persönlicher Rachefeldzug ist - aber eben gezielt auf eine Seite.

Und da ist natürlich die Frage - wie hoch ist die Wahrscheinlichkeit, dass ein Hacker (Kenntnisse entsprechend vorausgesetzt, und die müssen meiner Meinung nach tiefgründiger sein, als die eines Script Kids, um mit den Begriffen richtig umzugehen) eine einzelne private Webseite lahmlegt.

Dass Script Kiddies versuchen, Bullet Boards die neuesten Lücken zu entlocken, ist eine andere Sache - mehr kommerziell und darauf hatte ich abgezielt.


Wenn man es kleinlich nimmt, wird wohl von jedem wirklich gutem Programmierer mit der entsprechenden Gerätschaft und dem kriminellen Touch nahezu jede Seite geknackt werden können. Da hilft dann auch kein ausgeschalteter Safe Mode mehr, der laut Beschreibung ja wohl eher die auch noch "falsche" Lösung sei, eine Serverarchitaktur zu sichern.

Und damit wären wir wieder beim Thema - wenn Safe Mode die falsche Art und Weise ist, steht schon wieder die Frage im Raum, wieso man es den Usern überhaupt abschaltet, wenn doch ohnehin auch mit aktivem Safe Mode ein Angriff möglich ist.

[wahsaga]

Original geschrieben von der_milchmann
@wahsaga: Nicht traurig sein, du hast mein Problem nicht gelesen oder nicht verstanden.

Oder du meine Antwort nicht kapiert ...

Und damit wären wir wieder beim Thema - wenn Safe Mode die falsche Art und Weise ist, steht schon wieder die Frage im Raum, wieso man es den Usern überhaupt abschaltet, wenn doch ohnehin auch mit aktivem Safe Mode ein Angriff möglich ist.