Hacken lernen zum Testen der eigenen Seiten (Seite 4)

Ich habe mein CMS schon früh auf stricte Gleichheit und auf Eingangsprüfung (traue keiner Eingabe) umgestellt.
Wenn es fertig ist, stelle ich es hier gerne für das Ausprobieren von Attacken zur Verfügung (in einer Subdomain meiner Webseite).

Apropo traue keiner Eingabe, man sollte nicht vergessen:
Referrer und Browser Kennungen sind genauso anfällig wie GET Parameter und Eingabefelder.

Roman hat recht. Es gibt Dinge, die muss man vom Kern her gelernt haben. Ohne eine gewisse Grundsubstanz wird es ganz schwer zu folgen.

Auch wenn man ein Mini-Projekt als Vorlage nimmt, so hat jeder eine andere Herangehensweise. Um neutral zu bleiben, müsste man alle Sachen aufnotieren und ggf. die Vor- und Nachteile gegenüberstellen. Das müsste getan werden. Gibt es da Freiwillige?

Hallo,

da ich die Lawine des Interesses losgetreten habe, möchte ich mich jetzt auch nicht drücken. Zuerst werde ich versuchen mein Grundwissen auf das notwendige Maß versuchen zu erhöhen und im Anschluss würde ich gerne den ersten oder einen der ersten Threads in dieser Richtung eröffnen und bis zum fertigen Tutorial schreibender Weise begleiten.

Wie ich mir das so vorstelle:

Ich eröffne den Thread:

"PHP-Sicherheits Tutorial Teil 1 | Dispatch-Methode"
oder kurz
"PST 1 | Dispatch-Methode"

Dort werde ich mit meinen Worten die Methode versuchen fachgerecht zu beschreiben und stelle meinen Text zur Vervollständigung und Prüfung auf Richtigkeit zur Diskussion.

Sollte diese Diskussion einen fruchtbaren Erfolg haben, so werde ich das fertige Tutorial für diese Methode gerne am Ende dieses Threads zum Download stellen.

Auf diese Weise können alle Themen sogar gleichzeitig abgearbeitet werden. Jeder Threadstarter ist auch Pate "seines" Tutorials. Am Ende sollten wir nicht nur alle wieder etwas schlauer sein, sondern auch so einige brauchbare Texte erstellt haben, die man vielleicht sogar in Reihenfolge als PHP-Sicherheits-Wiki komplettieren könnte.

Na dann werde ich mal Grundwissen lesen und iun den kommenden Tagen den Thread eröffnen. Wer natürlich schon über ein ausreichendes Wissen verfügt, der könnte gerne auch schon ein für Ihn oder Sie spannendes Thema ähnlicher Größe (nicht zu viel, keine ganzen Projekte würde ich vorschlagen) als Threadstarter der PST-Reihe beginnen.

Mal lesen, was wir hier so kluges zusammen bekommen.

...Ich setze hier einmal den Threat fort. Im Augenblick nehme ich Joomla 1.6 auseinander und erfreue mich über die enorm verbesserte Sicherheit für Formulare.

Um die folgenden Zeilen zu verstehen muss man von Joomla gar keine Ahnung haben. Es stellt den Normal-Zustand bei vielen Webseiten dar.

Der Angriff, wenn man ihn so nennen kann, ist wirklich simple.

Beispielsweise hat man eine Anmeldung für einen Newsletter auf seiner Webseite. Seit letztem Jahr muss das Double-Opt-In Verfahren angewandt werden (hat jemand nen link dazu?)
Dabei muss der sich Eintragende einen Link aus der Bestätigungsmail klicken...Damit auch klar ist, dass der Empfänger der Bestätigungsmail diesen Newsletter auch haben möchte.

Andernfalls würde man spasseshalber vom Arbeitskollegen in diversen Newslettern eingetragen werden.

Bis hier hin sollte der Vorgang klar sein.

In der Datenbank für den Newsletter wird es diverse Spalten geben.

Name|email|bestaetigungscode|wurde-bestaetigt|
ich |@ich |1245566 |0 |

..so sollte der Eintrag aussehen.

Das formular sieht dann in etwa so aus
[html]
<form>
<input name="Name" value="" />
<input name="email" value="" />
</form>
[/html]

nun zur Aktion "Ärger im Netz"

[html]
<form>
<input name="Name" value="" />
<input name="email" value="" />
<input name="wurde-bestaetigt" value="1" />
</form>
[/html]

leider wurde mir das text-feld "<input name="wurde-bestaetigt" value="1" />" nicht mitgeliefert.. darum habe ich das selbst erledigt.
.absenden
...sollte der Webmaster "wurde-bestätigt" nicht gefiltert oder geprüft haben steht nun in der Datenbank "wurde-bestaetigt=1"....

dieser Kniff funktioniert bei vielen Applikationen, egal ob handgeschrieben oder CMs, wenn man nicht selbst ne Schüppe drauflegt.

Joomla hatte bereits in der 1.5er einen recht guten Kanal um solche unschönen Dinge zu blocken oder abzuwehren.

Für Joomla 1.6 wurde kräftig draufgelegt. Es existiert nun ein komplett ausgewogenes Formular-Management.

Die Funktion die hier zum Einsatz kommt heisst "validate".
Hierbei wird überprüft
Welche Formular-Elemente wurden zum User geschickt und welche kommen wieder zurück

Im Klartext heisst das, nicht an den User/Client geschickt, wird ungelesen zerrissen und nicht verarbeitet.

Wichtig und bitte nicht vergessen. Joomla liefert diese Formulartmethoden es ist nicht gesichert, das die Componenten-Entwickler dies auch ordnungsgemäss anwenden.

romacron schrieb:
(hat jemand nen link dazu?)

http://www.antispam.de/wiki/Double-Opt-In

Ich verstehe dein Posting nicht ganz. Wenn ich das richtig sehe, geht es darum, dass am Server mehr Formularfelder ankommen als das Formularfeld enthält.

Das Formularfeld enthält z.B. folgende Felder (um bei deinem Beispiel zu bleiben):
[html]<form>
<input name="Name" value="" />
<input name="email" value="" />
</form>[/html]

Es kommt aber folgendes an:
var_dump($_POST);
/* ergibt:
array(
\'Name\' => \'Max Mustermann\',
\'email\' => \'nachbars@email.com,
\'wurde-bestaetigt\' => \'1\'
)
*/


Ich sehe nicht, wo daran das Problem ist? Solange ich nicht Dinge ausführe wie
$db->insert($_POST);
sollten die zusätzlichen Daten doch sowieso niemals den Weg in die Datenbank finden.
Viele Grüße

Oskar

UFOMelkor schrieb:

romacron schrieb:
(hat jemand nen link dazu?)

http://www.antispam.de/wiki/Double-Opt-In

Ich verstehe dein Posting nicht ganz. Wenn ich das richtig sehe, geht es darum, dass am Server mehr Formularfelder ankommen als das Formularfeld enthält.

Das Formularfeld enthält z.B. folgende Felder (um bei deinem Beispiel zu bleiben):
[html]<form>
<input name="Name" value="" />
<input name="email" value="" />
</form>[/html]

Es kommt aber folgendes an:
var_dump($_POST);
/* ergibt:
array(
\'Name\' => \'Max Mustermann\',
\'email\' => \'nachbars@email.com,
\'wurde-bestaetigt\' => \'1\'
)
*/


Ich sehe nicht, wo daran das Problem ist? Solange ich nicht Dinge ausführe wie
$db->insert($_POST);
sollten die zusätzlichen Daten doch sowieso niemals den Weg in die Datenbank finden.
Viele Grüße

Oskar

Wenn die DB das Feld \'wurde-bestaetigt\' enthält, und das Formular-Script \'wurde-bestaetigt\' verarbeitet, dann klappt das wahrscheinlich schon. Ansonsten killt MySQL den Query.

Es gibt noch immer Seiten im Netz, bei denen man sich mit z.B. www.domain.tld/admin.php?login=1 anmelden kann.

Gruß Matthias

Hallo Oskar

Wenn ich das richtig sehe, geht es darum, dass am Server mehr Formularfelder ankommen als das Formularfeld enthält.

Jepp, das ist immer wieder der Fall und öfters als man denkt. Frameworks, egal welcher Art, bieten viel "Luxus". Hier schleicht sich hin und wieder ein Invalider ein.

$db->insert($_POST) ...ganz so hart ist es nicht. Die Richtung stimmt dennoch.

sollten die zusätzlichen Daten doch sowieso niemals den Weg in die Datenbank finden.

Der Konjunktiv... stimme ich dir zu, ist dennoch öfters der Fall.

Es scheint ein wenig Faulheit zu sein. Um dem Entgegen zu wirken habe ich diesen Post verfasst. ggf sollte ich die Formvalidierung in J1.6 genauer beschreiben, so geht hervor, wie Luxeriös die neue Version in Hinblick auf die Validierung der FormVars ist