Wie Mailspammer nach Lücken suchen

Jürgen Auer

Jürgen Auer

Legendäres Mitglied
Vorhin fiel mir auf, daß meine Newsletter-Anmeldung wiederholt aufgerufen wurde. Da aktuell ein NET-Trace läuft, werfe ich einen Blick in dieses und finde die folgende Auflistung:

Beispiel 1:

QUOTE Form Collection
Name Value
_oA-myButton promised2759@beispiel.server-daten.de
__pa promised2759@beispiel.server-daten.de
__fn promised2759@beispiel.server-daten.de
UI_mail promised2759@beispiel.server-daten.de
__et promised2759@beispiel.server-daten.de
_uA promised2759@beispiel.server-daten.de
_parent-myButton meat Content-Transfer-Encoding: quoted-printable Content-Type: text/html Subject: in the nited tates by bcc: eeeese@wearyingldm.com that is at least 20.5 protein (not counting fat portions) and contains no a= dded water. owever ham can be legally applied to such things as turkey ham = if the meat 1cd9355ef4739dee1cd80f463acc7282 .

Querystring Collection
Name Value
url http://www.sql-und-xml.de/freeware-tools/o...ml-trainer.html


Beispiel 2:


QUOTE Form Collection
Name Value
_oA-myButton or3525@beispiel.server-daten.de
__pa or3525@beispiel.server-daten.de
__fn or3525@beispiel.server-daten.de
UI_mail or3525@beispiel.server-daten.de
__et or3525@beispiel.server-daten.de
_uA over Content-Transfer-Encoding: quoted-printable Content-Type: text/html Subject: is an bcc: joanballinge6925@leavingisl.com at least 800 meters above sea level, with a minimum 9faa5d4a5d56f7e99fab64ce93e91885 .
_parent-myButton or3525@beispiel.server-daten.de

Querystring Collection
Name Value
url http://www.sql-und-xml.de/technik-dieser-s...xml-praxis.html



'Form Collection' sind die Html-Felder innerhalb eines <form>-Elements, die zurückgesandt wurden.
'Querystring Collection' listet die mit ? an die Url angehängten Werte.

Der Newsletter kann über die Seite http://beispiel.server-daten.de/newsletter-subscribe.html abonniert werden und nutzt die Standardtechniken mit einigen öffentlichen bzw. versteckten Feldern: UI_Mail ist das Feld, in das der Nutzer etwas eingibt, __pa/__fn/__et/_uA sind auf allen Formularen gleich, die anderen versteckten Felder verwenden vorgegebene Kürzel und den Namen (hier: myButton), den der Ersteller dieser Ausgabeseite dem angeklickten Button verpaßt hat. Ein passender Code ist auf verschiedenen Seiten meiner Hauptdomain links im Menü eingebunden. Der Code schickt immer die Aufruf-Url als Querystring url=Aufruf-Url mit. Die obigen Aufrufe (18 insgesamt) kamen alle als POST-Aufrufe von verschiedenen (also gefälschten) IP-Adressen.

Man sieht also: Die Spambots holen sich einmal per GET die aufrufende Seite (auf meiner Hauptdomain), lesen alle Formularfelder aus und bestücken eines mit einem injizierten Mailheader, alle anderen mit einer Zufallsmailadresse (hier bsp. or3525@beispiel.server-daten.de ). Das ganze durchläuft zyklisch alle Felder.

Es ist zu vermuten, daß die Mailadressen eeeese@wearyingldm.com usw. dem Spammer gehören, erst wenn auf dieser Mailadresse eine Mail mit einem passenden Zufallsschlüssel bzw. einer @beispiel.server-daten.de - Adresse eintrudelt, wird das Formular erneut aufgesucht - um dann massivst Spam zu versenden.

Es ist natürlich klar, daß ein bloßes Umbenennen der Seite oder ein Umbenennen der öffentlichen oder der versteckten Felder gegen so einen Angriff nicht schützt.

Edit: Kleine Ergänzung: Der injizierte Code ist korrekt mit Returns gefüllt, das oben zitierte Trace zeigt das nicht an.


CODE over
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html
Subject: is an
bcc: joanballinge6925@leavingisl.com

at least 800 meters above sea level, with a minimum












9faa5d4a5d56f7e99fab64ce93e91885
.
 
klingt sehr interessant, aber ich bin nicht sicher ob ich das Prinzip kapiert hab. Was ich verstanden habe:

- die Spammer scannen das Formular
- dann befüllen sie ein Feld mit einem Mailheader, das BCC kriegt eine Adresse des Spammers und am Ende eine Art Schlüsselwert
- die anderen Felder erhalten Zufallsmailadressen@der Domain, zu der das Formular gehört
- dann wird das Formular abgeschickt

Danach wäre der Spammer für den Newsletter registriert. Was ich nicht kapiere, ist wie er dann Spam versenden will. Über dieses Formular gehts ja nicht, weil das kein Mail versendet. Er kriegt dann höchstens irgendwann einen Newsletter und weiss damit, dass seine Daten über dieses Formular in einer DB gelandet sind.

Nutzen würds ihm nur dann, wenn das Formular ein offener Formmailer wäre, d.h. nach Eingabe direkt ein Mail an beliebige Adressen versenden würde. Und damit hast Du recht, ein Umbenennen der Felder oder der Seite bringt gegen solche Methoden garnix. Offene Formmailer werden so quasi zu offenen Mailrelays, und das bringt mittelfristig jeden Server ins Off.

Aber ich glaube fast, ich hab jetzt den Sinn mancher Spam-Mails erkannt. Ich meinte, ich hab so ähnliche Headers schon in Spammails gesehen, die ich erhalten hab. Und ich hatte da jeweils überhaupt nicht kapiert, was der Sinn dieser Mails eigentlich sein soll - kein Link und nix drin, was irgendwie mal Geld bringen könnte. Das waren wahrscheinlich genau solche Form-Scan-Mails. In Zukunft werd ich eher auf sowas achten, vielleicht kann ich dann irgendwann einen Spammer vollspammen ;-)

Griessli
Irene
 
Sehr schöne Study, danke Dir @Jürgen.

Eigentlich ist das Absichern der Formularmailer kein Problem. Aber es sind noch so viele Standardscripts im Umlauf, dass es für den Serveradmin einfach Pflicht ist jeden Formmailer zu kennen bzw. wenigstens kurz angeschaut zu haben.

Auch auf diesem Server hatten wir vor etwa einem halben Jahr n selbständigen Webmaster ohne genügenden technischen Sachverstand. Das Formular war aber customized. Also kann es genau nur so exploited werden, wie es Jürgen hier darlegt (oder natürlich manuell). Plötzlich haben viele viele Mails versendet ;-( Das Problem hat schon immer bestanden, aber die gammligen Scripts die solche Webmaster benutzen wurden damals noch nicht ausgenutzt.
 
QUOTE (Irene @ Sa 16.12.2006, 14:21)- die Spammer scannen das Formular
- dann befüllen sie ein Feld mit einem Mailheader, das BCC kriegt eine Adresse des Spammers und am Ende eine Art Schlüsselwert
- die anderen Felder erhalten Zufallsmailadressen@der Domain, zu der das Formular gehört
- dann wird das Formular abgeschickt

Das ist genau die Abfolge. Nur dürfte der Spammer nichts davon wissen, daß es sich bei dem Formular um eine Newsletter-Anmeldung handelt. Er fand einfach ein Formular und füllte es aus, um zu sehen, ob man das zum Spammen verwenden kann.


QUOTE (Irene @ Sa 16.12.2006, 14:21)Danach wäre der Spammer für den Newsletter registriert. Was ich nicht kapiere, ist wie er dann Spam versenden will. Über dieses Formular gehts ja nicht, weil das kein Mail versendet. Er kriegt dann höchstens irgendwann einen Newsletter und weiss damit, dass seine Daten über dieses Formular in einer DB gelandet sind.


Bei mir noch nicht einmal das. Würde er nur das UI_mail - Feld mit einer Mailadresse ausfüllen und alle anderen Werte mit den Standardwerten übernehmen (und zurücksenden!), dann würde er eine Mail mit einem Bestätigungsschlüssel für das Double-Opt-In bekommen. Das nutzt ihm aber spamtechnisch nichts, weil er zwar die Zieladresse festlegen, aber den Inhalt der Mail nicht beeinflussen kann.

Hintergrund ist, daß es mein System zuläßt, daß auf einer Seite mehrere Formulare mit mehreren Buttons definiert werden. Damit benötigt der Verarbeitungscode aber in den versteckten Feldern genau passende Werte, um bsp. zu wissen, welche Aktion durchgeführt werden soll (ein Button kann suchen oder speichern) und welcher Button geklickt wurde. Die passenden Werte erhält man dadurch, daß man die hidden-Feldwerte unverändert mitschickt. Der Spamer übernickelt die Werte mit Mailadressen - und erzeugt damit nicht einmal einen Datensatz. Mein Verarbeitungscode findet einfach nichts mehr, was zu tun wäre (kein 'search'/'save', kein Name des Eingabeobjektes usw.) und macht folglich nichts.

Der Spammer hätte ebenso die Masken unter http://beispiel.server-daten.de/tabellen.html testen können.
 
QUOTE (jAuer @ Sa 16.12.2006, 15:57)Mein Verarbeitungscode findet einfach nichts mehr, was zu tun wäre (kein 'search'/'save', kein Name des Eingabeobjektes usw.) und macht folglich nichts.

Das ist gut
biggrin.gif


Ich hab glaub auch noch irgendwo so ein Formular im Einsatz, was auf einem Hidden-Feld die auszuführende Aktion hinterlegt. Und es gibt wohl noch weitere solche Forms irgendwo im Netz. Aber wenn ein Spammer - oder sonst ein unangenehmer Mensch - mal drauf kommt, dass er "save" für ein Feld benutzen kann, wird es wieder heikel. Im dümmsten Fall könnten so Werte in die DB gelangen, die da nicht hingehören. Wenn ich mal Zeit hab, ändere ich meine Aktions-Strings in wilde Strings, deren Bedeutung nicht grad so offensichtlich ist...

Griessli
Irene
 
QUOTE (Irene @ Sa 16.12.2006, 15:53)Aber wenn ein Spammer - oder sonst ein unangenehmer Mensch - mal drauf kommt, dass er "save" für ein Feld benutzen kann, wird es wieder heikel. Im dümmsten Fall könnten so Werte in die DB gelangen, die da nicht hingehören.

Nö, das ist völlig unproblematisch.

Das, was der Clientbrowser hier dem Webserver schickt, ist ja nur die Bitte, die Daten als neuen Datensatz (und weder zur Suche noch als ein editierter Datensatz) zu behandeln. Bei der Suche kann bsp. in einem Mailfeld nur ein Buchstabe eingetragen sein (suche alle Mails mit b am Anfang), hier muß der Ausdruck keine gültige Mailadresse (wie bei der Dateneingabe) sein. Also prüft der Webserver hier schwächer. Ebenso wird bei der Suche nicht auf Pflichtfelder überprüft.

Hintergrund ist, daß die Eingabeformulare bei mir immer sowohl zur direkten Neueingabe (Kontaktformular), zur Neueingabe nach vorherigem Klick auf einen Link 'Neu', zum Editieren eines vorhandenen Datensatzes oder zur Suche verwendet werden können. In Abhängigkeit von der gewünschten Aktion muß der Webserver die Daten aufbereiten und schickt sie anschließend zum Datenbankserver. Erst der prüft die Berechtigung und weist sie gegebenenfalls zurück.

Wer es ausprobieren will, gehe auf die Seite http://dgam.server-daten.de/mpv.html :
Quellcode lokal abspeichern, im Head die js-Datei von http://www.server-daten.de/admin/sd.js laden, das action-Element auch absolut (auf http://dgam.server-daten.de/mpv.html ) ändern und im Code


CODE <script type="text/javascript">__write("/mpv.html/sample-input/sample-output", "myForm", "myButton", "", 0)</script>

durch

CODE <script type="text/javascript">__write("/mpv.html/sample-input/sample-output", "myForm", "myButton", "Speichern", 0)</script>


ersetzen: Dann wird ein Speichern-Link ausgegeben, sinnigerweise ist das _oA-myButton-Element hier sogar auf 'save' gesetzt. Beim Versuch, zu speichern, kommt trotzdem die Fehlermeldung aus der Datenbank: 'Keine Berechtigung' - vorausgesetzt, daß alle Pflichtfelder ausgefüllt, die Daten nicht zu lang und die Mail im korrekten Format ist.

Sprich: Das kann nur noch von jemandem manipulativ genutzt werden, der ohnehin Schreibberechtigung hat - aber bei dem werden alle Schreibaktivitäten protokolliert und sind damit für den Datenbank-Admin immer sichtbar.

Oder anders ausgedrückt: Trau nie, nie, nie Benutzereingaben - aber eine reguläre Verarbeitung von Berechtigten muß ja auch möglich sein.
 
QUOTE (jAuer @ Sa 16.12.2006, 18:13) [...]
Oder anders ausgedrückt: Trau nie, nie, nie Benutzereingaben - aber eine reguläre Verarbeitung von Berechtigten muß ja auch möglich sein.

*gg* Full ACK
Wenn das doch mal nur mehr so handhaben würden...
 
QUOTE Dann wird ein Speichern-Link ausgegeben, sinnigerweise ist das _oA-myButton-Element hier sogar auf 'save' gesetzt. Beim Versuch, zu speichern, kommt trotzdem die Fehlermeldung aus der Datenbank: 'Keine Berechtigung' - vorausgesetzt, daß alle Pflichtfelder ausgefüllt, die Daten nicht zu lang und die Mail im korrekten Format ist.

Ich bin mit der Lösung irgendwie nicht zufrieden, weil sie JavaScript vorraussetzt. Und das ist gerade wenn man auch Deinen ursprüngliches "Problem" betrachtet sogar eher kontraproduktiv. Denn Du möchtest ja vermutlich, das jeder Deinen Newsletter abonnieren kann. Die von Dir vorgeschlagene Lösung schließt allerdings Benutzer ohne aktivitertes JavaScript aus. Für eine öffentliche Umgebung (wie es eben ein Newsletter ist, oder ein Foreneintrag oder was sonst noch so an scriptgesteuerten (und eventuell datenbankgestützten) Anwendungen so läuft) ist das eigentlich nicht praktikabel.
Eine Fallbacklösung zum Beispiel mit "noscript" schlösse sich ja bei dem Problem eigentlich auch aus, weil das wieder durch simples Crawling ausgelesen werden kann, was Du ja explizit nicht anbieten wolltest.

Wenn ich den Sinn Deiner Beispielseite richtig begriffen habe, dann wäre da das Speichern sowieso nur einem speziell Berechtigten möglich, was ja in der Regel via SESSIONs oder .htaccess/.htpasswd gelöst wird. Und da ist das dann auch nicht mehr nötig, da dort sowieso nur Befugte Zutritt haben.


QUOTE Oder anders ausgedrückt: Trau nie, nie, nie Benutzereingaben - aber eine reguläre Verarbeitung von Berechtigten muß ja auch möglich sein.

Richtig, die Lösung kann gar nicht so ausgeklügelt sein, als daß man das vernachlässigen dürfte. Da kann die Gebetsmühle gar nicht oft genug angeworfen werden.
 
QUOTE (MarkusH @ Mo 18.12.2006, 0:07)Ich bin mit der Lösung irgendwie nicht zufrieden, weil sie JavaScript vorraussetzt. Und das ist gerade wenn man auch Deinen ursprüngliches "Problem" betrachtet sogar eher kontraproduktiv. Denn Du möchtest ja vermutlich, das jeder Deinen Newsletter abonnieren kann. Die von Dir vorgeschlagene Lösung schließt allerdings Benutzer ohne aktivitertes JavaScript aus.

Für eine öffentliche Umgebung (wie es eben ein Newsletter ist, oder ein Foreneintrag oder was sonst noch so an scriptgesteuerten (und eventuell datenbankgestützten) Anwendungen so läuft) ist das eigentlich nicht praktikabel.
Eine Fallbacklösung zum Beispiel mit "noscript" schlösse sich ja bei dem Problem eigentlich auch aus, weil das wieder durch simples Crawling ausgelesen werden kann, was Du ja explizit nicht anbieten wolltest.


Entweder hast Du meine Seiten nicht mit deaktiviertem JavaScript aufgerufen oder Du hast den Quellcode nicht hinreichend gründlich studiert.

Die Newsletter-Anmeldung und das meiste auf den anderen Seiten funktioniert auch mit deaktiviertem JavaScript, da wird das <noscript> - Element verwendet.

Es ist ja gerade eine Besonderheit meines Angebotes, daß ich die übliche NET-Technik (die tatsächlich JavaScript voraussetzt), so umgeschrieben habe, daß in den Fällen, in denen auf einer Seite nur ein Submit-Button vorkommt, alles auch ohne JavaScript funktioniert.

Würde der Mailspammer nur das UI_Mail-Feld bestücken und die anderen Felder unverändert übernehmen (wie das ein Standard-Browser mit oder ohne JavaScript abschickt), dann würde er sich zum Newsletter anmelden. Der Mailspammer überschreibt aber meine internen <input type='hidden'> - Felder, deshalb wird nichts gemacht.

Das, was ohne JavaScript nicht geht, sind Ausgabeseiten mit mehreren verschiedenen Submit-Buttons mit unterschiedlicher Funktionalität, bei denen also Daten per POST (und nicht nur per GET) übertragen werden. 'Einfache Seiten' wie eine reine Such- oder Anmeldungsseite benötigen nur einen POST-Button, das funktioniert alles auch ohne JavaScript.


QUOTE (MarkusH @ Mo 18.12.2006, 0:07)Wenn ich den Sinn Deiner Beispielseite richtig begriffen habe, dann wäre da das Speichern sowieso nur einem speziell Berechtigten möglich, was ja in der Regel via SESSIONs oder .htaccess/.htpasswd gelöst wird. Und da ist das dann auch nicht mehr nötig, da dort sowieso nur Befugte Zutritt haben.


Die Newsletteranmeldung entspricht dem Speichern eines Datensatzes in der Newsletter-Mail-Tabelle. Für diese Tabelle benötigen nicht authentifizierte Nutzer natürlich eine Insert-Berechtigung. Diese ist allerdings nicht innerhalb des MS-SqlServers, sondern im Rahmen meines eigenen, aufgesetzten Berechtigungskonzepts definiert. Ansonsten wäre das System niemals so flexibel, daß Kunden in ihren Datenbanken Nutzern verschiedene Berechtigungen vergeben könnten.
 
QUOTE so umgeschrieben habe, daß in den Fällen, in denen auf einer Seite nur ein Submit-Button vorkommt, alles auch ohne JavaScript funktioniert.

Richtig, es funktioniert auch ohne JavaScript, da im noscript-Bereich der submit-Button steht. Soweit kann ich folgen. Diesen findet auch jeder Crawler, denn er wird vermutlich die Seite mit Regexes durchlaufen und es wird ihm wurscht sein, ob das im noscript-Bereich steht oder einfach so im Quelltext. Demnach steht bei Newsletteranmeldung auch ein submit-Button.


QUOTE Der Mailspammer überschreibt aber meine internen <input type='hidden'> - Felder, deshalb wird nichts gemacht.

Ok, und hier habe ich das nicht mit Deinem Ursprungsposting verglichen. Das ist natürlich dämlich (vom Spammer). Ich muß aber gestehen, daß, wenn ich Spammer wäre, hidden-Fields nicht überschreiben würde. Das umzusetzen ist ja kein Aufwand und scheint die Trefferquote deutlich zu erhöhen. Ich kann mir auch nicht recht vorstellen, daß da nicht eine Menge Scripts ähnlich arbeiten. Der Aufwand ist ja minimal.


QUOTE Diese ist allerdings nicht innerhalb des MS-SqlServers, sondern im Rahmen meines eigenen, aufgesetzten Berechtigungskonzepts definiert.

Das hat aber jetzt mit dem Problem ja eigentlich nichts mehr zu tun, oder? Das fällt dann ja unter "Trau nie, nie, nie Benutzereingaben", was serverseitig verarbeitet wird. Mir ist allerdings nicht klar, was Dein Benutzerberechtigungskonzept für anonyme Benutzer für einen Eintrag ins Newslettersystem aussieht? Du kommst ja auch dort nicht drumherum, die Benutzerdaten zu filtern.

Wäre ich Spammer, würde ich Aliase für Email, Empfänger, Absender etc anlegen und dort gegebenenfalls meine Injections o.ä. probieren, hidden-Felder wären grundsätzlich Tabu.

Wie sieht denn eigentlich Dein Berechtigungskonzept aus(wenn das hier nicht den Rahmen sprengt)?
 
QUOTE (MarkusH @ Mo 18.12.2006, 10:57)
QUOTE Diese ist allerdings nicht innerhalb des MS-SqlServers, sondern im Rahmen meines eigenen, aufgesetzten Berechtigungskonzepts definiert.

Das hat aber jetzt mit dem Problem ja eigentlich nichts mehr zu tun, oder? Das fällt dann ja unter "Trau nie, nie, nie Benutzereingaben", was serverseitig verarbeitet wird. Mir ist allerdings nicht klar, was Dein Benutzerberechtigungskonzept für anonyme Benutzer für einen Eintrag ins Newslettersystem aussieht? Du kommst ja auch dort nicht drumherum, die Benutzerdaten zu filtern.

Wäre ich Spammer, würde ich Aliase für Email, Empfänger, Absender etc anlegen und dort gegebenenfalls meine Injections o.ä. probieren, hidden-Felder wären grundsätzlich Tabu.

Wie sieht denn eigentlich Dein Berechtigungskonzept aus(wenn das hier nicht den Rahmen sprengt)?


Man muß zwei verschiedene Dinge auseinanderhalten: Das Zulassen und Verweigern von Berechtigungen und das Filtern von Eingaben, um Injektionen jeglicher Art auszuschließen. Das gilt sowohl für anonyme als auch für registrierte, interne Nutzer. Schließlich gibt es bei Datenbanken Angriffe meistens von internen, bereits authentifizierten Nutzern.

Bei mir können Kunden sich eigene Datenbanken erstellen, in diesen Sql-Abfragen (beschränkt auf Select) zusammenbauen und Ausgabeseiten (mit Html-Code) erzeugen. Ein Speichern für eine Kundentabelle kann folglich von einem internen Menü oder von verschiedenen Ausgabeseiten her initiiert werden. Da kann ich Berechtigungen nicht mit einer htaccess (wie weiter oben vorgeschlagen) steuern, sonst bräuchten diese Kunden die Berechtigung, .htaccess-Dateien zu erstellen. Ferner muß ich sicherstellen, daß bsp. nicht ein Kunde per Select auf eine andere Kundendatenbank zugreifen und Daten des anderen Kunden auslesen kann. So etwas klappt nicht mehr mit den Standardtechniken des DB-Backends, da in diesem Fall der Webserver mit lauter verschiedenen Kennungen auf den Datenbankserver zugreifen müßte. Stattdessen verwendet der Webserver nur einen einzigen Account. Die aufgerufenen gespeicherten Prozeduren prüfen anhand der eigenen Berechtigungstabellen, ob der ausführende Nutzer die Berechtigung zum Zugriff auf diese Tabelle hat.

Mehr zum Berechtigungskonzept unter Konzepte und in der Menü-Hilfe (Menüs 13, 15, 16).
 
So, ich muß den Thread nochmals hervorkramen.

Um Weihnachten 2007 herum fiel mir auf, daß es doch tatsächlich ein Bot geschafft hatte, in mein Beispiel-Kontaktformular Spameinträge zu hinterlassen. Das hatte zwar keine negativen Auswirkungen. Würde dasselbe aber bei Kontaktformularen von server-daten - Kunden auftreten, wäre das mindestens doof: Sie denken, sie bekommen eine Nachricht - und finden Spam.

Also wurde ein Timer eingebaut. Sehr simpel - man kann beim sd:button - Element über ein Attribut sd:delay-save="5000" festlegen, daß zwischen Aufruf und Speichern mindestens 5000 Millisekunden, also 5 Sekunden liegen müssen. Denn es hatte sich gezeigt, daß der Bot die Seite abruft, alle hidden-Felder unverändert mitschickt (damit wird gespeichert, der Bot 2006 hatte die hidden-Felder mit Inhalt überschrieben) und nur die sichtbaren Felder ausfüllt. Nur macht er das innerhalb einer Sekunde. Zusätzlich wurde eine Mailbenachrichtigung für diesen Fall aktiviert.

Vorhin war es soweit - eine Mail kam. Die Kontrolle lehrte:

QUOTE __timer -8590015195496805808
__fn myForm
__et ,myButton
__rt
tables-name kontaktformular
input-table sample-input
sample-input._kontaktformularId
sample-input.Nachname Frunnybus
sample-input.Vorname Frunnybus
sample-input.Mailadresse dolopol@coomahalig.info
sample-input.Kommentar To you obviously will help this site - <a href=http://digilander.libero.it/coiffur/>clip free sex</a> ))) Restrain oneself!!!
_parent-myButton
_oA-myButton save
__pa myButton


Alle sichtbaren Felder wurden ausgefüllt - es wurde nur eben nicht gewartet, also wurde nichts gespeichert. Theoretisch könnte man da auch einen 404 oder 500 zurückgeben - aber warum den Bot warnen. So kriegt er einen 200 und wähnt sich glücklich, stört aber nicht.

Durch die obige Attributregelung läßt sich das auf jene Seiten einschränken, bei denen anonyme Nutzer etwas eintragen dürfen. Die angemeldeten / authentifizierten Nutzer innerhalb von Kundendatenbanken können beliebig schnell speichern, auch wenn sie so ein Formular verwenden.

Sprich: Einige Bots sind inzwischen klüger geworden, allerdings sind sie 'zu hastig'
biggrin.gif


PS: In der Dokumentation fehlt das Attribut noch. Aber da fehlen auch noch die Attribute, die es inzwischen für die Nutzung von Bezahlvorgängen (PayPal, Sofortüberweisung) gibt.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben