[quote=Bauhaus,19.12.2005, 15:00]So kommt der Thread nicht weiter.
Einer liest den von ihm zitierten Text falsch (esskar).
Einer testet Exploits und übersieht was (pq).[/quote]
wenn du uns für solche dilettanten hälst und dich für so schlau, warum
gibst du dich überhaupt noch mit uns ab?
du hast ein cooles exploit-script und kannst nun die ganze welt hacken.

[quote=pq,19.12.2005, 15:11][quote=Bauhaus,19.12.2005, 15:00]So kommt der Thread nicht weiter.
Einer liest den von ihm zitierten Text falsch (esskar).
Einer testet Exploits und übersieht was (pq).[/quote]
wenn du uns für solche dilettanten hälst und dich für so schlau, warum
gibst du dich überhaupt noch mit uns ab?
du hast ein cooles exploit-script und kannst nun die ganze welt hacken.[/quote]
Nope - das Skript war doch lediglich ein Beispiel (das ich esskar zugesagt hatte) und da ging es (wie nachzulesen ist) um print/eval.

Wenn ich in Sicherheitsfragen 'schlau' wäre, dann hätte ich diesen Thread nicht eröffnet.
Auch halte ich die Mitglieder dieses Forums keineswegs für Dilettanten - ganz im Gegenteil - ich gehe davon aus, hier eine geballte Menge an Wissen vorzufinden; hätte ich sonst gefragt?

Bitte nicht persönlich werden sondern einfach beim Thema bleiben.

Hier, der Klarheit halber, nochmals:
Ich habe nur sehr begrenzte Vorstellungen darüber, was ein Angreifer anstellen kann/könnte.
Von daher versuche ich, alle Usereingaben die 'irgendwie ausführbar' sein könnten, schon im Vorfeld auszuschalten.
Es wäre nett wenn dieses Forum mir dabei helfen würde.\n\n

<!--EDIT|Bauhaus|1135005380-->

okay, was willst du noch beantwortet haben?

[quote=pq,19.12.2005, 15:08][quote=Bauhaus,19.12.2005, 15:00]So kommt der Thread nicht weiter.[/quote]
ja, seh ich auch so. du scheinst daran kein interesse zu haben.
was genau an "usereingaben benutzt man nicht ungeprüft als dateinamen"
verstehst du nicht?
und was genau an "benutze -T" verstehst du nicht?
und was an "perldoc perlsec" versehst du nicht?
du verhältst dich irgendwie trollig (sic!).[/quote]
Ich verstehe und verwende -T sehr wohl.
perlsec (wie auch die entsprechende Literatur) ist mir bestens bekannt.
Den Begriff 'trollig' weiß ich auch einzuordnen.
Bei sic! müsstest du mir auf die Sprünge helfen ...

Sorry - alles nicht böse gemeint :)
Ich suche nur nach Lösungen.

Edit:
In Sachen -T hab ich ein Problem.
Unter Windows funktioniert das nicht (kommt ne Fehlermeldung)\n\n

<!--EDIT|Bauhaus|1135006168-->

[quote=esskar,19.12.2005, 15:58]okay, was willst du noch beantwortet haben?[/quote]
Außer dem Gemeinplatz:
Traue keiner Usereingabe
Habe ich m.E. bisher keinerlei sachdienliche Antworten erhalten.

Ich berichtige mich:
der Link den Dubu geposted hat, war sehr informativ und konnte auch sehr gut umgesetzt werden.
Das war ein tatsächliches Erfolgserlebnis - Danke!

stell eine konkrete frage, dann kannst ich konkret antworten.
wissen zu dumpen ist schwer. und man bekommt erst nach ein paar jahren erfahrung ein gfeühl dafür, was sicher ist und was nicht.

[quote=esskar,19.12.2005, 16:18]stell eine konkrete frage, dann kannst ich konkret antworten.
wissen zu dumpen ist schwer. und man bekommt erst nach ein paar jahren erfahrung ein gfeühl dafür, was sicher ist und was nicht.[/quote]
Du beschäftigst dich seit sechs Jahren mit Sicherheitsfragen.
Sag mir doch einfach was gefährlich ist.
Den Code zum Abschalten kann ich dann schon schreiben (und auch hier zur Diskussion vorstellen).
Wäre das ein Deal?

[quote=Bauhaus,19.12.2005, 16:36]Sag mir doch einfach was gefährlich ist.
Den Code zum Abschalten kann ich dann schon schreiben (und auch hier zur Diskussion vorstellen).[/quote]
truncate blabla ist gefährlich - wenn es an eine datenbank übergeben wird.

system("rm -rf /") ist gefährlich - wenn es an den perl-interpreter übergeben wird.

.
To: spam@test.example
Subject: Spam-Mail[...] ist gefährlich, wenn es an sendmail
übergeben wird, ohne die option -oi

<script>/* irgendwas übles in javascript */</script> ist gefährlich,
wenn es an einen browser übergeben wird.

alles oben genannte ist nicht gefährlich, wenn es in eine datei geschrieben wird.
der springende punkt ist, du wirst keinen code entwickeln können, der
generell allen input ungefährlich macht.
es gibt encode_entities für HTML. es gibt platzhalter für SQL. es gibt -oi für
sendmail. es gibt -T zum checken.
es gibt nichts für eval (nichts wirklich sicheres z.Zt. jedenfalls)

glaubst du, esskar beschäftigt sich seit 6 jahren damit und hatte bisher einfach
keine lust, sowas zu programmieren, und kein anderer experte, aber
du schreibst uns sowas in ein paar tagen?

ich sage es zum x-ten mal: du musst wissen, wo in deinem programm
welcher user-input verwendet wird. dann kannst du dich konkret
absichern. generell zu sagen: make_secure(%input) geht nicht.

edit: naja, es geht doch:
%input = ();\n\n

<!--EDIT|pq|1135011463-->

[quote=Bauhaus,19.12.2005, 15:00][quote=pq,19.12.2005, 14:15][quote=Dubu,19.12.2005, 09:48]Kein Wunder, dass das nicht klappt, du hast das Pipezeichen aus dem Exploitcode (%7C) weggelassen.[/quote]
ups... =) muss ich übersehen haben[/quote]
So kommt der Thread nicht weiter.
Einer liest den von ihm zitierten Text falsch (esskar).
Einer testet Exploits und übersieht was (pq).

Könnten wir uns nicht darauf einigen dass dies ein wichtiges Thema ist und von daher alles aufmerksam/unvoreingenommen gelesen/getestet werden sollte um dann zu einer umfassenden Lösung zu gelangen?

Muß doch irgendwie möglich sein - denk ich mal. :)[/quote]
Es ist nicht möglich. Die Möglichkeiten, Code zu schreiben, sind unbegrenzt. Und die Möglichkeiten, unsicheren Code zu schreiben, sind ebenfalls unbegrenzt.

Ich hab jetzt mal so angefangen bzw. erweitert


Was haltet ihr davon?