Das 1 mal 1 gegen Sicherheitslücken (??)

Stonebroke

Stonebroke

klammUrgestein
10 Juni 2006
2.554
63
Hallo erstmal,

ich bin auf der Suche nach leicht verständlichen Tutorials, die einem die häufigsten Fehler bei der Programmierung aufzeigen.

Wer kann mir Tipps zu Webseiten geben, die einen Hobby-Progger die gravierensten Fehler beim Proggen erklärt.

Was ich mir wünsche würde, wären aufgezeigte und relativ einfache Operationen (bzw. Prozesse) die zunächst in fehlerhafter und dann in richtiger Form dargestellt werden.

Sorry vorab, ich bin mir nicht sicher, ob dieser Thread hier hingehört oder das Thema bisher in dieser Form angesprochen wurde.
 
Hi,

deine ganze Beschreibung ist arg schwammig.

Um welche Programmiersprachen geht es? Objektorientiert oder Funktionsorientiert? Oder gehts um sowas wie SQL-Injections?

Je nach Gebiet sind das schließlich völlig verschiedene Themen.

PlaciD
 
@PlaciD

Funktionsorientiert.
PHP & MySQL

Genau, alle Arten von Injections ( via mail() , CSS etc. )

renoja9a8.gif

Werde es mir merken ;-)
 
Ich kann das Buch "PHP-Sicherheit" empfehlen - sobald man denkt, dass man jetzt gut gerüstet ist, kommen die Autoren wieder mit einem anderen Beispiel, dass das umgehen kann. Zumindest mir hat es bis dato viel gebracht :)
 
§3 "das @-Zeichen"

Wird ausnahmslos bei Mail-Adressen oder Firmennamen genutzt. In PHP-Code hat es nichts verloren!
Zum Vergrößern anklicken....


§2 "error_reporting"

Wird grundsätzlich auf E_ALL gesetzt, in Ausnahmefällen sei der Zusatz - E_NOTICE bzw. E_ALL & ~ E_NOTICE gestattet.
Zum Vergrößern anklicken....

Das halte ich für ein Witz!!

Ein Beispiel was mir mal passiert ist und dank Mone verhindert wurde:

PHP: 
<?php
$anfrage = fopen("https://www.klamm.de/engine/lose/send.php?ef_id=xy&efpw=xxy",r);

?>

viel Spass ohne @ wenn Klamm down ist! :ugly:

Eine kleine Unaufmerksamkeit reicht, und das wars dann schon. Wenn man was tut, muss man wissen was man tut, und vor allem warum man es tut, und man muss bedenken was im Fehlerfall passieren kann. Wozu ein Script in der Lage ist, und wozu es missbraucht werden könnte.

Bei einer SQL Anfrage muss ich mich des Injections fürchten.
Bei Api Anfragen der Offenlegung der Daten. (Für sicheren Transport sorgen).
usw... einfache Gedankengänge können oft das schlimmste verhindern. Und auch jeder eingefleischt Programmierer macht Fehler. Deshalb ist der größte Selbstmord immer der, von sich zu behaupten alles besser zu wissen. Den in der Programmierung lernt man wirklich nie aus.

Wer daher Gesetze schreibt, die das genau verhindern sollen, der hat im selben Moment Gesetze geschrieben, die genau das bewirken. Denn es gibt keine Festen Regeln. Es ist immer noch eine Maschine, die mit Millionen von Rechenbefehlen bombardiert wird. Wer es schafft eine Rechnung zu manipullieren, der wird auch darin Erfolg haben, das Ergebnis zu verfälschen. Ich kann dies nicht an simplen Regeln verhindern.

Es kommt immer darauf an, ob der Angreifer schlauer ist wie der Programmierer oder anders herum.

Der sicherste Programmcode in PhP, denek ich sieht wie folgt aus:

PHP: 
<?php
exit;
?>

Ironie muss sein!

P.s. Unter Unix oder Linux würde man sagen als Regel nr.1

Root weis was er tut!

Das einzige was man machen kann ist aus Fehler lernen und sich den Angreifermöglichkleiten stehts informieren. Das würde zumindest den Schaden begrenzen. Einen absolut sicheren Code welcher komplex ist, wird es nicht geben.

Man kann auch sagen, der Wert eines Programmieres liegt in seiner Erfahrung.
 
Zuletzt bearbeitet:
ABC schrieb:
Das halte ich für ein Witz!!

Ein Beispiel was mir mal passiert ist und dank Mone verhindert wurde:

PHP: 
<?php
$anfrage = fopen("https://www.klamm.de/engine/lose/send.php?ef_id=xy&efpw=xxy",r);

?>

viel Spass ohne @ wenn Klamm down ist! :ugly:

Eine kleine Unaufmerksamkeit reicht, und das wars dann schon. Wenn man was tut, muss man wissen was man tut, und vor allem warum man es tut, und man muss bedenken was im Fehlerfall passieren kann. Wozu ein Script in der Lage ist, und wozu es missbraucht werden könnte.
Zum Vergrößern anklicken....

Les mal unter was die § geführt werden. Da steht "Das Fehlersuchen-Gesetzbuch (FSGB)" und nicht "Die sichere PHP Anwendung".
 
ABC schrieb:
PHP: 
<?php
$anfrage = fopen("https://www.klamm.de/engine/lose/send.php?ef_id=xy&efpw=xxy",r);

?>

viel Spass ohne @ wenn Klamm down ist! :ugly:
Zum Vergrößern anklicken....
Gutes Beispiel, aber leider gibt's auch hier eine Anmerkung, die man nicht verachten sollte:

Ich kenne ausser ExportForce (und den ganzen Kopien auf externen Seiten) eigentlich keine derartige API, die sicherheitsrelevante Daten per GET empfangen will. Würden die Daten alle mittels POST gesendet, gäbe es dieses Sicherheitsrisiko gar nicht erst...
 
tleilax schrieb:
Gutes Beispiel, aber leider gibt's auch hier eine Anmerkung, die man nicht verachten sollte[...]
Zum Vergrößern anklicken....

Gutes Beispiel? Was ist daran gut? Ein @ hat meiner Meinung nach nicht wirklich was in einer produktiven PHP Anwendung verloren. Fehler unterdrücken würd ich entweder durch ein eigenen Error Handler oder wenn ich faul bin durch error_reporting E_NONE. Es können auch mal Fehler auftreten die nicht unbedingt erwartet werden und ich find es nicht wirklich berauschend wenn dann die Besucher mit Fehlern überschütet werden. Ausserdem können derartige Fehlermeldungen auch ein Sicherheitrisiko darstellen. Und bei der Entwicklung kann so ein @ ein auch die Nerven kosten. Spätestens wenn man sich mal ne Halbestunden mit dem unnormalen verhalten einer PHP Anwendung rumgeschlagen hat die durch so ein @ hervorgerufen wurde (bzw. durch den Fehler der unterdrückt wurde).
 
ZeroCCC schrieb:
Gutes Beispiel? Was ist daran gut? Ein @ hat meiner Meinung nach nicht wirklich was in einer produktiven PHP Anwendung verloren. Fehler unterdrücken würd ich entweder durch ein eigenen Error Handler oder wenn ich faul bin durch error_reporting E_NONE.
Zum Vergrößern anklicken....

Genauso sehe ich das auch, das @ hat im Programmcode NICHTS zu suchen, Fehlermeldungen zeigt man dem Kunden/Besucher sowieso nicht an ergo schalten wir erstmal display_errors aus. Zudem regestrieren wir noch einen eigenen event-handler damit wir auch ja alle Fehelr abfangen und protokoloieren können, denn DAS kann die Unterdrückung durch @ nicht.
 
Em was ist der Unterschied, ob ich nun die Fehlermeldungen nicht anzeige, oder mit @ unterdrücke? Sicher das erstere undterdrückt alle, aber dies wäre so, als ob vor jeder Zeile ein @ stehen würde.

Von daher kann ich die Aussagen nicht ganz verstehen.

Der einzige Wahre unterschied wäre nur, wenn ich mir meine Fehler notieren lasse. Was aber bei @davor und notice auch gehen würde. Er würde sie dennoch notieren.

Die Erfindung des @hast schon seinen Sinn.

Beispiel ich habe einen SWF Slot der an eine PHP Datei dockt.

Dann möchte ich beispielweise, dass der slot was mitbekommt, statt Fehler selbst bringt.

PHP: 
<?
...

$result = @mysql_query() || or die('&fehler=1');
?>

Da möchte ich sicher keinen mysql_error() an den Slot übergeben, der noch nicht mal mit & zur Datenübertragung an die SWF übergeben wird.

Ich lasse mich gerne vom Gegenteil überzeugen.
 
Zuletzt bearbeitet:
ABC schrieb:
PHP: 
<?
...

$result = @mysql_query() || or die('&fehler=1');
?>

Da möchte ich sicher keinen mysql_error() an den Slot übergeben, der noch nicht mal mit & zur Datenübertragung an die SWF übergeben wird.

Ich lasse mich gerne vom Gegenteil überzeugen.
Zum Vergrößern anklicken....

so ein sch*** kann man aber echt nurin php basteln :roll:
mysql_Query returned ein false wenn ein feher auftritt und printed keine meldung ;)
und das ganz konstrukt ist sowieso no-way! noch unsauberer kann man nicht mehr coden.
 
ice-breaker schrieb:
mysql_Query returned ein false wenn ein feher auftritt und printed keine meldung ;)
und das ganz konstrukt ist sowieso no-way! noch unsauberer kann man nicht mehr coden.
Zum Vergrößern anklicken....

Stimmt schon, wenn die Funktion schon anbietet bei nem Fehler n FALSE zurück zu geben, dann sollte man das wenn möglich auch nutzen!
 
scriper schrieb:
wenn die Funktion schon anbietet bei nem Fehler n FALSE zurück zu geben, dann sollte man das wenn möglich auch nutzen!
Zum Vergrößern anklicken....
*nicht versteht ob das kritik an seinem post ist* :LOL:

neija er wertet es ja aus, aber sowas von idiotisch das gibts ja net :biggrin: nen die() bei nem mysql-fehler? wozu gibt es transaktionen? und zu geil: der fehler wird nichtmal geloggt, es merkt also nicht unbedingt jemand den fehler^^
und das das @ unnütz ist, habe ich ja schon erwähnt
 
@tester, ice-breaker
ist ja schön, dass ihr auf meine seiten verweist, aber bitte im richtigen zusammenhang.
@ABC
wer lesen kann, ist klar im vorteil
Setzt das @ nur im absoluten(!) Notfall ein, wenn ihr zum Beispiel auf eine Datei zugreifen wollt, von der ihr nicht wißt, ob sie existiert.
@stonebroke
als einstieg für sql-injections hilft wikipedia
zum thema mail-injection empfehle ich dir das hier (zweiter thread)

gruß
peter
 
ZeroCCC schrieb:
Les mal unter was die § geführt werden. Da steht "Das Fehlersuchen-Gesetzbuch (FSGB)" und nicht "Die sichere PHP Anwendung".
Zum Vergrößern anklicken....
Jepp, jede beseitigte Sicherheitslücke, bzw. jeder beseitigte Fehler macht die Anwendung sicherer.

ABC schrieb:
Ein Beispiel was mir mal passiert ist und dank Mone verhindert wurde:
PHP: 
<?php
$anfrage = fopen("https://www.klamm.de/engine/lose/send.php?ef_id=xy&efpw=xxy",r);
?>
viel Spass ohne @ wenn Klamm down ist! :ugly:
Zum Vergrößern anklicken....
Du musst auch nicht gerade fopen() benutzen, es geht auch anders.
Das fopen() ist bei vielen Servern für remote zum Glück eh gesperrt.

kropff schrieb:
@tester, ice-breaker
ist ja schön, dass ihr auf meine seiten verweist, aber bitte im richtigen zusammenhang.
Zum Vergrößern anklicken....
Nanu, wen habe ich denn da angelockt? ;)

kropff schrieb:
@ABC
wer lesen kann, ist klar im vorteil
Setzt das @ nur im absoluten(!) Notfall ein, wenn ihr zum Beispiel auf eine Datei zugreifen wollt, von der ihr nicht wißt, ob sie existiert.
Zum Vergrößern anklicken....
Sehe ich auch so, denn so ein @ kann verhidnern, dass man bestimmte Fehler nicht angezeigt bekommt und so das Debuggen recht aufwändig wird.
Vor einem Zugriff auf Datei von der man nicht weiss ob sie existiert muss man ein file_exists() machen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben