[HaBo]

**xeno** · 10.03.10, 19:18

Zitat:

Zitat von easteregg

der führt den inhalt des cookies aus.
sprich du kannst da beliebigen code reinbringen indem du den per cookie übermittelst...

das is mega gefährlich ;D

OK, eval sollte ich von der Shell kennen *g*. Nicht drauf geachtet, sorry

master-protic · 10.03.10, 19:46

Hallo

Es ist kein Root Server!!
Es ist ein Strato MX3 Managed Server

Tobi

beavisbee · 10.03.10, 19:52

erstell mal eine Datei, meinetwegen info.php, mit folgendem Inhalt:

PHP-Code:

  <?php
phpinfo();
?>

und die Seite, die dort dann ausgespuckt wird, postest du hier mal bitte in code-Tags - dann können wir hier 'nen groben Überblick bekommen, wie sicher / unsicher die PHP-Config ist...

Angaben zu Domain und Kundennr. (z.B. steckt die Kundennr. bei vielen Anbietern im Pfad auf dem Server drin) kannst du ja durch XXX "schwärzen"

master-protic · 10.03.10, 22:09

Hallo

http://85.214.123.63/info.html

Tobi

easteregg · 10.03.10, 22:15

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....

die php version is nichmehr offiziell supportet... die ist gut 2 jahre alt!

open_base_dir is auch nich gesetzt....
exec funktionen nicht unterbunden....

master-protic · 10.03.10, 22:19

Hallo

Währe dies ein Kündigungsgrund??

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

Tobi

easteregg · 10.03.10, 22:24

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.

Thunderb0lt · 10.03.10, 22:25

Zitat:

Zitat von easteregg

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....

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.

register globals aus zu schalten ist da mehr ein workaround, der sich so eingebürgert hat.

easteregg · 10.03.10, 22:29

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?

master-protic · 10.03.10, 22:31

Hallo

Der wurde ganz normal bestellt, nix mit register globals auf on usw

Tobi

beavisbee · 10.03.10, 22:37

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...

easteregg · 10.03.10, 22:40

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

) 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.

Thunderb0lt · 10.03.10, 22:41

Zitat:

Zitat von beavisbee

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...

Es ist definitiv kein Sicherheitsleck an sich

Einem sauberen Script ist es egal, ob register globals ein oder aus ist. An der Sicherheit des Scripts ändert diese Einstellung rein gar nichts.

beavisbee · 10.03.10, 22:50

Zitat:

Zitat von Thunderb0lt

An der Sicherheit des Scripts ändert diese Einstellung rein gar nichts.

Aber an der Einstellung des Programmierers zum Thema sichere und saubere Programmierung ändert's gewaltig was

( in der Hoffnung, dass durch das plötzliche 'Fehlen' der register_globals-Einstellung dem Programmierer die Augen geöffnet werden...

)

Thunderb0lt · 10.03.10, 22:59

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.

Empfehlung

10.03.10, 19:52	#18 (permalink)
beavisbee Member of Honour Registriert seit: 22.02.07 Likes: 75	erstell mal eine Datei, meinetwegen info.php, mit folgendem Inhalt: PHP-Code: `<?php phpinfo(); ?>` und die Seite, die dort dann ausgespuckt wird, postest du hier mal bitte in code-Tags - dann können wir hier 'nen groben Überblick bekommen, wie sicher / unsicher die PHP-Config ist... Angaben zu Domain und Kundennr. (z.B. steckt die Kundennr. bei vielen Anbietern im Pfad auf dem Server drin) kannst du ja durch XXX "schwärzen"

10.03.10, 22:15	#20 (permalink)
easteregg Member of Honour Registriert seit: 14.09.07 Likes: 60	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.... die php version is nichmehr offiziell supportet... die ist gut 2 jahre alt! open_base_dir is auch nich gesetzt.... exec funktionen nicht unterbunden.... __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|> Geändert von easteregg (10.03.10 um 22:18 Uhr)

10.03.10, 22:24	#22 (permalink)
easteregg Member of Honour Registriert seit: 14.09.07 Likes: 60	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. __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|>

10.03.10, 22:29	#24 (permalink)
easteregg Member of Honour Registriert seit: 14.09.07 Likes: 60	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? __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|>

10.03.10, 22:40	#27 (permalink)
easteregg Member of Honour Registriert seit: 14.09.07 Likes: 60	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 ) 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. __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|>

10.03.10, 19:46	#17 (permalink)
master-protic Themenstarter Registriert seit: 08.03.10 Likes: 0	Hallo Es ist kein Root Server!! Es ist ein Strato MX3 Managed Server Tobi

10.03.10, 22:09	#19 (permalink)
master-protic Themenstarter Registriert seit: 08.03.10 Likes: 0	Hallo http://85.214.123.63/info.html Tobi

10.03.10, 22:19	#21 (permalink)
master-protic Themenstarter Registriert seit: 08.03.10 Likes: 0	Hallo Währe dies ein Kündigungsgrund?? Dies ist ein Managed Server!! Da ich für die Sicherheit eigentlich bezahle! Und nicht wenig Tobi

10.03.10, 22:31	#25 (permalink)
master-protic Themenstarter Registriert seit: 08.03.10 Likes: 0	Hallo Der wurde ganz normal bestellt, nix mit register globals auf on usw Tobi

10.03.10, 22:37	#26 (permalink)
beavisbee Member of Honour Registriert seit: 22.02.07 Likes: 75	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...

10.03.10, 22:59	#30 (permalink)
Thunderb0lt Registriert seit: 06.06.09 Likes: 6	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.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

[HaBo]

Javascript Code in Webseite