Javascript Code in Webseite

Hallo

Währe dies ein Kündigungsgrund??

Dies ist ein Managed Server!! Da ich für die Sicherheit eigentlich bezahle!
Und nicht wenig

Tobi
 
wenn es von euch nicht so verlangt wurde, dass das ding deart offen ist. keine ahnung was in den verträgen drin steht. aber unter mananged verstehe ich was anderes. du selbst hättest dir mit jedem 08-15 tutorial da bessere sicherheit verschaffen können.

schreib mal den support von deinem anbieter an, warum die configuration so aussieht.
 
easteregg hat gesagt.:
register globals auf on...
hau dem serveranbieter das ding um die ohren, wenns nen managed server is.
ne größere sicherheistlücke gibts gar nicht....
Zum Vergrößern anklicken....

Na ja, an und für sich ist es nicht register globals, das unsicher ist, sondern die Scripts, die Variablen vor ihrer Verwendung nicht initialisieren. :wink:

register globals aus zu schalten ist da mehr ein workaround, der sich so eingebürgert hat.
 
sicherlich, man sollte die variablen immer brav initialisieren, aber die meisten sicherheitslücken basieren nunmal darauf und mit register globals zu arbeiten ist zudem noch schlechter stil, wieso das also auf on lassen? ;)
 
unter 'managed' verstehe ich definitiv auch was anderes...

und nein, register_globals=off ist kein Sicherheits-"Workaround", sondern ein Weg, die Programmierer wenigstens zu ein klein wenig mehr Sauberkeit im Code zu zwingen...

Die letzte Seite, die ich mit register_globals = on geschrieben habe, stammt aus dem Jahr 2004 ...

und open_basedir-Restrictions gehören genauso zu 'ner sicheren Standard-Config - echt erschreckend, wie unbekümmert manche Anbieter hier riesige Scheunentore ins Netz stellen...

und allow_url_fopen = on .... also Tür und Tor offen für RFI...


@master-protic:
um dir mal die Gefahren, die durch unsicheren Code gepaart mit unsicherer Server-Config entstehen, zu verdeutlichen, hier nochmal der Link zu dem Vortrag, den ich bei uns an der FH mal gehalten habe:

http://studium.cs-bergann.de/inet/phpsecurity/

da gibt's paar ganz simple konstruierte Beispiele, die leider viel zu häufig in ähnlicher Form in der Realität vorkommen und ein paar Tipps A) zur sichereren Programmierung und B) zur sichereren Server-Config...
 
nohcmal für die threadersteller.
das alte wbb2 in kombination mit irgendwelchen plugins und der einstellung register globals ist mit sicherheit der verursacher für den geglückten hackangriff.

wenn es sich bei der flinte wirklich um einen managed server handeln sollte, dann sei dir dringend geraten, den anbieter zu wechseln und dem support mal ordentlich zu berichten, dass das unter aller sau ist, was die da anbieten.

wenns kein manged server ist, sondern nen normaler root, wechsel auf nen managed server (lol :D) oder belese dich über die absicherung von apache/php. letzteres ist fürn laien aber auf anhieb auch nen ganz schöner akt. daher lieber jemand suchen, der das professionell macht.
 
beavisbee hat gesagt.:
und nein, register_globals=off ist kein Sicherheits-"Workaround", sondern ein Weg, die Programmierer wenigstens zu ein klein wenig mehr Sauberkeit im Code zu zwingen...
Zum Vergrößern anklicken....

Es ist definitiv kein Sicherheitsleck an sich :P
Einem sauberen Script ist es egal, ob register globals ein oder aus ist. An der Sicherheit des Scripts ändert diese Einstellung rein gar nichts.
 
Zuletzt bearbeitet von einem Moderator:
Wie gesagt, an der Sicherheit ändert es nur bedingt etwas. Es zwingt dich vielleicht auf alle EGPCS-Variablen über die entsprechenden Arrays zu zugreifen, aber solange die restlichen Variablen nicht sauber initialisiert werden, ist und bleibt das Script unsicher.

Und wenn ich ein Problem habe, das sich zumindest zeitweise, beheben lässt, ohne, dass ich an der Ursache des Problems arbeiten muss, dann ist diese "Lösung" für mich ein Workaround. :wink:
 
wie gesagt, änder alle zugangspasswörter, setz die passwörter von den benutzer deines forums zurück, schick ne mail an strato, versichere dich, dass es wirklich nen manged server ist und setz das forum mitsammt allen plugins neu auf.
 
Malware

Das

eval(base64_decode("aWYoZnVuY........gICB9ICB9"));?>


ist malware, Ich habe das und Ich habe alle PHP files gelöscht und jetz arbeit nocheinmal.
Ich denke, Du kann sagen immer eval(base64_decode(".... ) ist schädlich.
 
say what?
du hast nen ähnliches problem gehabt?
dann musst dir aber im klaren sein, dass es mit nem einfachen löschen nicht getan ist, sondern der ganze server vielleicht kompromittiert ist!
 
Ja, Es ist in bluehost remote server. Ich lese im Internet anderen Berichten , dass sie die Malware gehabt haben. Ihre Kunden-Support sagt, dass Anwender ihre Websites sauber , aber das ist nicht fair. ANyway, ich reinigte es. Download to local, mit AdobeDreamweaver denn "Find and Replace" in my complete folder (site),Vorsicht mit leeren Zeilen nach dem Unterricht an der bösartigen beginnin. Sie müssen sie auch löschen weil einige PHP- Anweisungen nicht korrekt ausgeführt:
http://us3.php.net/manual/de/function.header.php

Es ist besser, Suchen und Ersetzen von <? eval ( base64_decode ( "aw ... till nächste Symbol und ersetzen mit das nächste Symbol (die meisten der Zeit "<?"). Denn Suchen "eval ( base64_decode" noch einmal wenn das nächste Symbol ist anders und Ändern Sie die "Suchen und Ersetzen" nocheinmal.
Glücklicherweise war es nur in PHP-Dateien.
Entshuldigen Sie mein Deutsch. Ich bin Cuban und ich wohne in Miami. ENglish would be OK.
 
ok, i think bevor you hurt yourself by trying to translate to german, we should try english ;)

the problem described by easteregg is, that you can't be sure if your whole server has been manipulated or just your PHP scripts ...

from the facts that are known, the attacker was able to access the whole system

in cases like this there is only one common solution that will work:

flatten and rebuild - means you delete every single bit on the whole system and start at zero, reinstalling the operating system ... you can not repair, since you can't be sure what the attacker did ... for example: did he setup a root kit? has he captured your passwords/keyfiles? you can't know for sure => the only secure way to deal with it, is to assume that nothing on that system can be trusted ... and needs to be destroyed and replaced a.k.a. "flatten and rebuild"

your data on the machine is a problem ... because you can't know, you have to assume that it is compromised ... you will need to restore from a clean backup, but there still is the question how old the backup has to be, to be clean
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben