| Statistik |
Beiträge: 146.001 (Täglich: 18,24 )
Themen: 16.892
Mitglieder: 13.220
Neuestes Mitglied: Hugo100.
Ausl. d. letzten Minute: 108%
Ausl. d. letzten 5 Minuten: 226%
Ausl. d. letzten 15 Minuten: 236%
Aktulle Uhrzeit: 03:41
Freier Webspace: 4.15 TB
PHP-Version: 7.4.33
|
|
|
|
  |
 addslashes() noch sicher? |
Thx2 
New Kids Junge
Dabei seit: 17.02.2010
Beiträge: 522
Themen: 66
0 Filebase-Einträge
wBB-Version: wBBLite
Bewertung:
Level: 42 [?]
Erfahrungspunkte: 2.936.031
Nächster Level: 3.025.107
 |
|
| addslashes() noch sicher? |
     |
Hallo,
Ich habe mich die letzten Tage ein bisschen mit SQL Injections und was man heute so dagegen tut beschäftigt.
Also die Kurzfassung ist man benutzt heute Prepared Statements. (Entweder mysqli oder PDO)
Jetzt ist es ja so das dass alte Lite 1 und WBB2 ja keine prepared Statements sondern addslashes() und intval() verwendet als Schutz vor SQL Injections.
Wenn man jetzt mal bisschen googelt kommt man schnell zu dem Schluss das addslashes() wohl NICHT sicher gegen SQL Injections ist.
Ich habe dann weiter gegraben und es sieht wohl so aus das addslashes() solange man den latin1 (singlebyte charset) verwendet sicher ist. Wenn man jedoch auf utf8 (multibyte charset) wechselt dann reicht es wohl nicht mehr aus.
Das Problem ist wenn man ein lite1 jetzt mit Schrimm's Anleitung upgraded und auf einem normalen Webspace installiert dann nutzt sowohl der Webserver als auch die MYSQL Datenbank den UTF8 charset.
Allerdings verwendet man nach den Upgrades von Schrimm immernoch addslashes() und keine Prepared Statements:
WoltLab Burning Board Lite 1.0.2pl3
Da ich jetzt kein großer Hacker bin tut sich nun bei mir die Frage auf ob das sicher ist oder nicht.
Wenn man so googelt könnte man denken das es NICHT sicher ist und die art wie ich your-wbb.de betreibe mit Cloudlinux patched PHP 5.2 und Latin 1 charset in der Datenbank sogar sicherer sein könnte?
|
|
12.06.2025 18:34 |
|
|
Thx2
New Kids Junge
Dabei seit: 17.02.2010
Beiträge: 522
Themen: 66
0 Filebase-Einträge
wBB-Version: wBBLite
Bewertung:
Level: 42 [?]
Erfahrungspunkte: 2.936.031
Nächster Level: 3.025.107
Themenstarter 
|
|
Schade das keiner geantwortet hat.
Ist Schrimm hier eigentlich noch ab und zu aktiv? Würde mich interessieren was er dazu meint. 
|
|
|
18.06.2025 16:16 |
|
|
|
|
|
Zitat:
Original von Thx2
Schade das keiner geantwortet hat.
|
|
|
Hallo Thx2,
Viktor ist derzeit im Urlaub ....
__________________
lg Stine
|
|
|
18.06.2025 18:08 |
|
|
Viktor 
Administrator
Zeige Viktor auf Karte
Dabei seit: 15.08.2003
Beiträge: 32.051
Themen: 483
364 Filebase-Einträge
Alter: 68 Jahre
Herkunft: NRW
wBB-Version: wBB2.3
PHP-Version: 7.4.33
MySQL-Version: 10.11.6-MariaDB
Wo bist du gehostet?: eigener Server
Bewertung:
Level: 71 [?]
Erfahrungspunkte: 256.483.307
Nächster Level: 266.777.854
|
|
|
|
20.06.2025 21:21 |
|
|
Thx2
New Kids Junge
Dabei seit: 17.02.2010
Beiträge: 522
Themen: 66
0 Filebase-Einträge
wBB-Version: wBBLite
Bewertung:
Level: 42 [?]
Erfahrungspunkte: 2.936.031
Nächster Level: 3.025.107
Themenstarter
|
|
| RE: addslashes() noch sicher? |
|
|
Zitat:
Original von Viktor
Man sollte jetzt soweit ich weiß "mysqli_real_escape_string" nehmen.
|
|
|
Eigentlich prepared statements aber ich vermute mysqli_real_escape_string reicht wahrscheinlich auch.
Am schlausten wäre es vermutlich das ganze langfristig auf PDO und Prepared Statements umzumünzen.
|
|
|
21.06.2025 11:09 |
|
|
Viktor
Administrator
Zeige Viktor auf Karte
Dabei seit: 15.08.2003
Beiträge: 32.051
Themen: 483
364 Filebase-Einträge
Alter: 68 Jahre
Herkunft: NRW
wBB-Version: wBB2.3
PHP-Version: 7.4.33
MySQL-Version: 10.11.6-MariaDB
Wo bist du gehostet?: eigener Server
Bewertung:
Level: 71 [?]
Erfahrungspunkte: 256.483.307
Nächster Level: 266.777.854
|
|
|
|
21.06.2025 21:58 |
|
|
|
|
Hallo,
Ob nun "mysqli_real_escape_string" oder "addslashes" verwendet wird ist irrelevant, da es praktisch nur einen unterschied gibt auf welcher Ebene sie operieren.
Beides ist mehr oder weniger gleich unsicher/sicher, da diese Funktionen nicht dazu gedacht sind um SQL-Injection zu verhindern, sondern um einen mehr oder weniger fehlerfreien Ablauf zu gewährleisten.
"mysqli_real_escape_string" ist daher nicht wirklich sicherer, wenn es um SQL-Injection geht, sondern um Statements bezüglich einer Abfrage fehlerfreier zu machen.
"addslashes" hingegen ist nicht wirklich direkt auf Hinblick auf SQL-Statements entwickelt worden und daher weicht das Verhalten etwas ab, welche Symbole escaped werden.
mysql_real_escape_string: \x00, \n, \r, \, ', " und \x1a
addslashes: \x00, \, ' und "
Welcher Zeichenkodierung verwendet wird ist mehr oder weniger egal.
ISO-8859-1 oder UTF-8 ist beides unsicher/sicher.
Der Unterschied liegt rein darin, dass man bei einer Singlebyte-Codierung keine Charsetmanipulation durchführen kann, da eben ein Byte genau einem Zeichen entspricht und man dadurch eben gewisse Filter nicht austricksen kann.
Prepared statements ist die Antwort gegen SQL-Injection, da diese gewährleistet, dass ein SQL-Statement nicht verändert werden kann und Daten auch wirklich Daten bleiben und nicht Teil des SQL-Statements werden und das SQL-Satement abändern können.
__________________
|
|
|
23.06.2025 16:10 |
|
|
Thx2
New Kids Junge
Dabei seit: 17.02.2010
Beiträge: 522
Themen: 66
0 Filebase-Einträge
wBB-Version: wBBLite
Bewertung:
Level: 42 [?]
Erfahrungspunkte: 2.936.031
Nächster Level: 3.025.107
Themenstarter
|
|
 |
|
 |
|
Zitat:
Original von Schrimm
Hallo,
Ob nun "mysqli_real_escape_string" oder "addslashes" verwendet wird ist irrelevant, da es praktisch nur einen unterschied gibt auf welcher Ebene sie operieren.
Beides ist mehr oder weniger gleich unsicher/sicher, da diese Funktionen nicht dazu gedacht sind um SQL-Injection zu verhindern, sondern um einen mehr oder weniger fehlerfreien Ablauf zu gewährleisten.
"mysqli_real_escape_string" ist daher nicht wirklich sicherer, wenn es um SQL-Injection geht, sondern um Statements bezüglich einer Abfrage fehlerfreier zu machen.
"addslashes" hingegen ist nicht wirklich direkt auf Hinblick auf SQL-Statements entwickelt worden und daher weicht das Verhalten etwas ab, welche Symbole escaped werden.
mysql_real_escape_string: \x00, \n, \r, \, ', " und \x1a
addslashes: \x00, \, ' und "
Welcher Zeichenkodierung verwendet wird ist mehr oder weniger egal.
ISO-8859-1 oder UTF-8 ist beides unsicher/sicher.
Der Unterschied liegt rein darin, dass man bei einer Singlebyte-Codierung keine Charsetmanipulation durchführen kann, da eben ein Byte genau einem Zeichen entspricht und man dadurch eben gewisse Filter nicht austricksen kann.
Prepared statements ist die Antwort gegen SQL-Injection, da diese gewährleistet, dass ein SQL-Statement nicht verändert werden kann und Daten auch wirklich Daten bleiben und nicht Teil des SQL-Statements werden und das SQL-Satement abändern können. |
|
 |
|
 |
|
Wenn ich dich richtig verstehe bedeutet das in hinblick auf das alte WBB das addslashes() + ISO-8859-1 = sicher, addslashes() + UTF-8 = nicht sicher weil:
|
Zitat:
man bei einer Singlebyte-Codierung keine Charsetmanipulation durchführen kann, da eben ein Byte genau einem Zeichen entspricht und man dadurch eben gewisse Filter nicht austricksen kann. |
|
|
Wenn dem so ist gibt es Pläne deineseits auf prepared Statements (idealerweise PDO) umzurüsten?
Oder habe ich das missverstanden und UTF-8 + addslashes() ist soweit sicher und man kann alles so lassen? (Aktueller Stand deiner Umrüstanleitung)
|
|
|
24.06.2025 18:01 |
|
|
Thx2
New Kids Junge
Dabei seit: 17.02.2010
Beiträge: 522
Themen: 66
0 Filebase-Einträge
wBB-Version: wBBLite
Bewertung:
Level: 42 [?]
Erfahrungspunkte: 2.936.031
Nächster Level: 3.025.107
Themenstarter
|
|
Leider hat Schrimm bislang nicht mehr geantwortet.
|
Zitat:
Wenn dem so ist gibt es Pläne deineseits auf prepared Statements (idealerweise PDO) umzurüsten? |
|
|
Ich hoffe ich hab dich hiermit nicht verschreckt?
Selbstverständlich gibts hier keine "Verpflichtungen" selbst wenn es aktuell unsicher ist.
Aber ich hätte schon gerne eine konkrete, unmissverständliche Antwort ob das jetzt aktuell sicher ist oder nicht.
WBBLite/WBB2 + Schrimm Anleitung mit UTF 8.
Ich würde nämlich gerne wissen woran ich aktuell bin.
|
|
|
11.07.2025 21:13 |
|
|
|
|
|
|
|
© für wbb2 by Bandy & 
Geblockte Angriffe: 12.489