• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

:Money-Event:

Pixel Tomsen

Aktiver Nutzer
Als Einleitung...

Wir nutzen ein Web-Basierendes Bezahl-System zur Begleichung der Tierzahlung.Das Websystem errechnet Ablaufzeit sowie loggt auch alle Aktionen (z.B. Rezz-Ort, Betrag, Bezahler, Fehler etc.) durch die Ingame genutze PayBox.

Die Zahlung erfolgte regulär mit der Objektkennung Ingame (Position, Betrag, Einzahler etc.), also optisch laut Web-Log augenscheinlich erstmal alles i.o. inc. Keys.

Meine Fragen:
- ist ein HTTP-Request,welches in keiner Form optisch Ingame erscheint auslesbar, z.B. durch einen Software-Bot, es würde eventuell diesen Reinfall erklären, wenn die Stringketten bekannt wären für den Aufruf (p.s. es ist KEINEM, ausser mir der Quellcode bekannt, Linden sicherlich)
- ist der Money-Event manipulierbar, z.B. wenn man es 'überlastet'
- die Box ist so denke ich in allen Regeln gut auf Fehler programmiert, auch findet die Gutschrift im Web nicht ohne Permission statt

Der Grundablauf der Bezahlung: BoxRezz->Permission erteilen-> einzahlen->Webcore berechnet und schreibt gut -> sagt ok der Box mit neuen Daten->zahlt an den Empfänger

Habe nun den Code Rauf und Runter gerattert.
Schade , dass es keine Verifikation gibt, ob das Geld in dem Moment auch ausgezahlt wurde....

vll hat ja wer eine Idee...in Bezug auf Möglichkeiten der Manipulation.


lg PiTo
 
- ist der Money-Event manipulierbar, z.B. wenn man es 'überlastet'

Ja:
LlGiveMoney - Second Life Wiki

Use is limited to 30 payments in a 30 second interval for all scripts owned by that resident on a region. Sustained overage will produce a script error and halt payments while the rate remains excessive. Historically, faster payments have failed intermittently.

Damit lassen sich alle Vendoren austricksen, die das Geld "weitergeben".
 
Als Einleitung...
Die Zahlung erfolgte regulär mit der Objektkennung Ingame (Position, Betrag, Einzahler etc.), also optisch laut Web-Log augenscheinlich erstmal alles i.o. inc. Keys.


lg PiTo

und was passierte dann? "alles i.o." und dann doch nicht? kann man nicht einfach in seiner transaction history alle zahlungen nachvollziehen?
ich wuerde gerne etwas dazu schreiben, habe aber das problem noch nicht erkannt. irgendwie scheint geld, das einmal da war, wieder verschwunden zu sein?
jemand hat von deinem account geld abgebucht?
 
Der Grundablauf der Bezahlung: BoxRezz->Permission erteilen-> einzahlen->Webcore berechnet und schreibt gut -> sagt ok der Box mit neuen Daten->zahlt an den Empfänger

moin,

Wer ist Besitzer der gerezzten Box und erteilt die Paypermission?
Warum ist die Zahlung an den Empfänger nicht direkt nach dem Einzahlen?

Sollte der Besitzer der Box der Mieter sein würde ich das System überdenken.
Sicherer ist es wohl, wenn der Vermieter der Boxbesitzer ist.

gruss
thinkangel
 
Ich habe mir dazu und zu dieser Art Abwicklung viele Gedanken gemacht, als ich es entwickelte.

Als Antworten:
- Besitzer der PayBox ist der Landowner, dieser erteilt auch die Permission, der Vorteil, es arbeitet wie eine Geldbörse in SL und prangert nicht an Strassenrändern rum als MUSS. selbst wenn man es vergisst, wird ausdrücklich durch extra Komponente benachricht, so kann man es nach belieben überall in SL nutzen
- es ist in meinen Augen NICHT sicherer, wenn eine Payment-Permission seitens des Vermieters besteht, den die gilt auch für Auszahlungen und durch Maßnahmen, auch schon bekannt durch Fälle erzwungen werden kann
-das System habe ich entwickelt auch, weil ich keinerlei Einsicht besitze auf das Ziel, und wenn ich nachfrage als Vergleich des jenigen ewig keine Initiative kommt (sprich...ich sehe die Transaktionen nicht real, ich sehe lediglich die gesamte Log-History der gesamten Events seitens der PayBox Abwicklung, so habe ich es kreiert)
- warum erst Bezahlung nach dem WebLog, das sind ganz einfach Erfahrungswerte, da es ganz schnell geht dann seitens des Kunden...ich habe bezahlt, aber keine Tage wurden gut geschrieben...klemmt mal der Webserver...geht sowas ganz schnell, deshalb diese Methode, deshalb....geht der WebLog nicht, funktioniert auch die Bezahlung nicht zu Gute des Kunden!
- ich habe nur einene Transaktionsabschnitt derzeit zum Vergleich, es zahlten vor und nach dem Betreffenden Leute ein, diese Transaktionen waren auch vorhanden, nur SEINE waren nicht enthalten, welche sich genau dazwschen befanden laut halt dem WebLog
- und p.s. es gab keine ReRezz Methoden, falls das Script wegen Überlastung gestorben wäre, wegen zuviel Bezahlungen innerhalb 30secs


lg PiTo
 
moin Pito,

Dein Anliegen, dem Kunden gegenüber so fair und freundlich als möglich zu sein, ist Ehrens- und Lobenswert.

Eine deRezz Funktion wird dir auch in Zukunft nicht helfen dein Problem zu lösen.
Die 30 Zahlungen pro 30 Sekunden beziehen sich nicht auf das Script oder den Prim, sondern auf den Agenten pro SIM.
Beispiel:
Hat der Mieter ein anderes Script laufen das fröhlich 5 Zahlungen pro Sekunde ausführt ist das Limit nach 6 sek. erreicht.
Weitere Zahlungen werden vermutlich noch in einer Warteschlaufe gepuffert.
Ist diese voll ( ca 20-30 sek), versagt jede weitere Zahlung ohne das irgendwo eine Fehlermeldung registriert wird.

Das heisst für dein System, es funktioniert alles wie es soll, nur die Zahlung selbst wird nicht ankommen.
Dein Script kann nicht wissen das der Mieter sein Zahlungslimit mit einem anderen Script bereits ausgeschöpft hat.

:arrow: Um dein System sicher zu machen bleibt nur, den Zahlungseingang selbst zu Verifizieren bevor irgendetwas gutgeschrieben wird.

Oder Du änderst dein System dahingehend das (wie üblich) die PayBox dem Vermieter gehört.

Orginelle Lösungen die hässlich rumprangernde PayBoxen vermeiden dürfte es sicher auch geben:wink:

gruss thinkangel

P.S.
Wie währe es mit einem Marienkäfer der Fingernagelgross in einer Landecke sitzt, dessen Punkte auf dem Rücken die letzten 10 verbleibenden Tage visualisiert, angeklickt grösser wird und Hovertext anzeigt?.
 
Da ja schon ein Webbasiertes System genutzt wird, denke ich mir mal es wird eine MySQL Datenbank dabei verwendet.
Warum nicht zentral einige Terminals hinstellen wo jeder einzahlen und seine Daten abrufen kann?
Den Usernamen/Userkey zu verwenden bei den Dingen wäre dann auch denkbar einfach.
keine lästigen Boxen mehr überall und weit weniger Ärger.

Nur so eine Idee, die ich auch grad mit nem Bekannten umsetze.
 
Hi;-)
danke thinkangel, glaub nun habe ich plausibel verstanden, um es so zu betrachten.
Es könnte dann glaube näher betrachtet diese Schwachstelle evt. wissend genutzt worden sein. Der Jenige zahlt zuvor in Selbst-Zahl-Gutschrift Pott und danach in die PayBox (was ja 10-20x erfolge in kurzen abständen),welche die angeblichen Gutschriften schön schreibt ,aber an sich durch diese Einschränkung der Zahltechnik das Auszahlen nicht mehr funzt.

Mal so betrachtet, durch diese Schwachstelle ist wirtschaftlicher Schaden möglich.
Man kann nicht immer gutmütig von Normal-Benutzung ausgehen, sondern wie es AllWelt praktiziert auch wird, Schwachstellen auszunutzen.

Aber auch andersrum betrachtet, ob die Permission seitens des Vermieters ist (wo es vll auch Lücken gibt, da auch eine Geldauszahl-Permission besteht), oder gar auch mal so betrachtet, Zahlungen auf der Sim durchgeführt werden und derweilen vor dem Sim Tier Empfänger verharrt und danach das gleiche tut, wäre dies nicht die selbe Logik oder Gefahr?

Ich denke dahingehend müsste in SL die Funktionalität ausgebaut werden gerade bei diesem sensiblen Thema 'Geld', nur der Event ist mir zu schlapp, es fehlt die Rückmeldung, so könnte man weitaus sicherer aggieren.

Ich denke als Fazit,
für Mieter, welche immer ehrlich und unter NORMALER Nutzung des Systems seine Zahlungen erfüllt, kann jeder Vermieter immer im Sicheren sein und dadurch keine Auffälligkeit aufgetauchen.
Andersrum, wem das 'Glück' trifft, Mieter manipulanter wissender Art mal zu haben, kanns mal schnell anders sein...dort hilft derzeit immer die visuelle Kontrolle in der Linden Transaktionslist....aber die hat ich leider nicht, deshalb der ganze Aufwand des Systems;-)
Ich glaube das mit einer zentralen Bezahlstelle wäre eine gute Idee mit.


Ich denke, die Erkenntnis sollte wertvoll sein, für Entwickler und Scripter, dies einzubeziehen.



lg Pix.
 

Users who are viewing this thread

Zurück
Oben Unten