Seitentest von sb-innovation

[Bluesteel]

Mach ich die auswertung läuft bereits

[jazzrul]

Gibt es Hinweise, welche Stellen der ursprünglichen NV Source kontaminierungsgefährdet sind? Also ganz allgemein z.B. "nicht escapte Get-Parameter in der announce.php", oder "numerischer Wert 'id' lässt unzulässigerweise strings durch". Sowas in der Art. Evtl. hat auch noch jemand konkretere Hinweise, wie die (unhöflichen, weil auch nur publicity-geil, statt hilfreich) Gestalten bei SB-Inno... genauer vorgehen.

Ja, die, bei den jeweiligen Codern weitergewachsenen NV Sourcen sind alle divergiert und zum größten Teil wohl noch mehr "Spaghetti-Code" als vor 10 Jahren. Aber es gibt immer noch Gemeinsamkeiten, die wir hier austauschen können. Ist ja schließlich open Source das Ganze und steht unter GPL (soweit ich mich erinnere).


1. Am allerwichtigsten: Definieren eines globalen DB Objektes, als Wrapper um mysqli::class und im Code dann alles mittels $unsere_db->methode() ansprechen.
dazu empfehle ich die Definition einer Funktion "sqlesc($string)", als Wrapper um mysqli::real_escape_string($string), da man die ziemlich oft braucht, und so weniger tippen muss, bzw. der Code etwas übersichtlicher wird. (Persönliche Vorliebe)


2. Parameter von aussen VOR Verwendung mit isset() prüfen und ggf. mit sinnvollem Null-Wert belegen. Damit es bei späterem Einfügen in die DB keine NULL-Value errors gibt.
Bei enum Werten, mittels php funktion switch(){} den Wert ermitteln und ggf entspr. String  zurückliefern (Stichwort Entkopplung)



3. Die Quirks in den php files ...(das meiste kann man mit prepared Statements, intval() und sqlesc() erschlagen und die Hälfte der Files liegt eh im Admin-Bereich ...) ...:




bookmark.php: komplette Umstellung auf prepared Statements. Da ist fast alles neu, deswegen keine nähere Beschreibung
casino.php einige unescapte $..._id s, die alle mit intval() sicher gemacht werden konnten.
messages.php ca. Zeile 150, escapen  per Adresszeiger: foreach ( $_REQUEST["selids"] as &$rid ) { $rid = intval($rid); } ... $_REQUEST["id"] wird bei späterer Verwendung mit intval() behandelt
userstraffic.php: komplette Umstellung auf prepared Statements.

mypic.php dito

userhistory.php: intval auf $_GET["id"]
uploadapp.php auch hier nahezu komplette Umstellung auf prepared Statements.Nur queries ohne Variablen von aussen können direkt bleiben.
delacctadmin.php komplette Umstellung auf prepared Statements, etc.
takelogin.php: komplette Umstellung auf prepared Statements, etc.

takeprofedit.php: an allen Stellen mit > $updateset[] = "var=".$var < , die $var entspr. escapen  mit intval() oder sqlesc()
modtask.php: ca. Zeile 100: zusätzliches isset() auf $_POST() vars.
include/wo_auch_immer_die_login_funktionen_definiert_sind.php: die entspr. Funktionen auf prepared Statements umstellen.


Hoffe, das hier hilft irgendwem weiter.
LG
jazz



(offtopic: weiß jemand, wie ich bei debian stretch, die limits NOFILE und NPROC ohne reboot dauerhaft verändern kann? Mein mysql zickt mit der Meldung "too much open files" rum)

[Cerberus]

Warum mysqli???
Gleich PDO und fertig ... in einer eigenen Klasse gepaselt und aus die Maus ...


Eingaben prinzipiell über einen Input-Filter laufen lassen -- damit wird dann alles komplett erschalgen.


Um ein Rewrite wirst du aber nicht umhinkommen, wenn du jemals "Ruhe" rein bekommen willst.
Kinder, wie SBI versuchen immer wieder irgend welchen Blödsinn -- als erste Blockade kommt dann ein IDS zu einsatz.
Ich habe irgenbdwann den CTRACKER mal auf ne Klasse umgebaut - um ihn einfacher Pflegbar zu machen.
Aber er hat mittlerweile 2 weitere Vorgeschaltete Systeme -- unter anderem einen IDS.


Und den ganzen Kinderkrahm bekommst du mit dem Input-Filter "erschlagen".


PS: Deine OT-Frage -- mach nen Thread in der Hilfe-Sektion auf -- das kommt immer mal wieder als Fragestellung rüber

[Stifler]

Ich finde mysqli jetzt nicht schlechter als pdo, auch unter MySQLi gibt es prepared Statements
Wovon ich gar nichts halte sind die Datenbankklassen wo man einzelne Teile in Arrays/Params quetscht.. da verlernt man teilweise Statements zu schreiben

[Lex]

Zitat von Stifler

Ich finde mysqli jetzt nicht schlechter als pdo, auch unter MySQLi gibt es prepared Statements
Wovon ich gar nichts halte sind die Datenbankklassen wo man einzelne Teile in Arrays/Params quetscht.. da verlernt man teilweise Statements zu schreiben

Was glaubst du wie ich zum Kotzen anfange wenn ich ne PDO Query händisch schreiben muss Bin einfach von TT2´s Klasse verwöhnt

Lg Lex

[jazzrul]

@Cerberus: mit dem rewrite hast du sicherlich recht. Konkret tue ich das eigtl. auch bei jeder Stelle, die ich anfassen muss. Einige Dinge funktionieren allerdings seit Anfang an klaglos, so dass sie mir erst jetzt auf die Füsse fallen. Und so erfolgt der rewrite weiterhin sukzessive.


@Stifler: Als jemand der SQL mit dBase III gelernt hat, gefällt dieses Maß an Abstraktion bei PDO auch nicht mehr wirklich. Das war vor ca. 3 Monaten auch der Grund für meine Wahl der mysqli-Technik stat PDO, um die relevanten Stellen in der (eh schon divergierten) NV Source zu ersetzen.


Danke für eure Anregungen.

[Cerberus]

Wenn die Querys über eine Klasse gekapselt werden, ist es egasl, wie du sie benutzt ....
MySQLi, PDO, --- irgend was anderes ....


Wichtig ist einzig, das die Ausgabe die selbe ist -- die Verarbeitung an sich ist im Grunde wurscht

[blondie009]

Bei uns hat auch jemand ein Screenshot vom Staff-Panel gemacht obwohl da nur ein Coder ran kommt , wir haben eine Vermutung aber den Namen sage ich nicht

[Thunder™]

Wenn man eine Vermutung hat, sie aber nicht belegen kann, sollte man schweigen.
Jeden Tag wird so viel Scheiße im Internet geschrieben wovon meistens nicht mal 1 Prozent stimmt.

Menschen labern hat gerne wenn der Tag lang ist

Achja eines noch, ich weiß nicht von welchen Tracker du schreibst aber wenn einer gehackt wird und lieber bei sbi diskutiert als hier, kann euch keiner helfen!! Auch wenn es hier Tot aussieht, so kann man hier dennoch Hilfe erhalten. Alle Tracker die bei sbi durchgefallen sind, wurden mit Lücken gehackt wo es HIER seit Ewigkeiten Fixes für gibt. Darüber sollte man nachdenken. Mfg

[blacky]

Achja eines noch, ich weiß nicht von welchen Tracker du schreibst aber wenn einer gehackt wird und lieber bei sbi diskutiert als hier, kann euch keiner helfen!! Auch wenn es hier Tot aussieht, so kann man hier dennoch Hilfe erhalten. Alle Tracker die bei sbi durchgefallen sind, wurden mit Lücken gehackt wo es HIER seit Ewigkeiten Fixes für gibt. Darüber sollte man nachdenken.

dem ist NICHTS hinzuzufügen !!!!