SQL Injections

32
Bug #
Priorität1 (🔺 Sehr Hoch)
BereichLayout
TitleSQL Injections
Beschreibungzorg ist anfällig für SQL Injections, z.B.:

http://www.zooomclan.org/actions/poll_unvote.php?poll=106 OR user != NULL OR TRUE

...und schwups sollten die Polls-Logs weg sein.
Reported by @
 
Git Commit
Assigned to @ 03.01.2005 13:57
StatusResolved @ 32
zorg.ch
#62398 by @ 02.01.2005 21:13 - nach oben -
Ist sicher nicht die einzige. Keiner der Coder interessiert sich ansatzweise fuer Sicherheit.
zorg.ch
#62399 by @ 02.01.2005 21:16 - nach oben -
das ist in der tat schon immer das grösste problem bei zorg gewesen, ja...
zorg.ch
#62489 by @ 03.01.2005 17:59 - nach oben -
darauf würd ich sogar wetten.
zorg.ch
#62502 by @ 03.01.2005 19:51 - nach oben -
Falsch. ich interessiere mich etwas mehr als nur ansatzweise für sicherheit. und ich sichere meine queries grundsätzlich gegen solche hässlichkeiten ab. natürlich kann es passieren, dass mal was vergessen geht. ich hab auch nicht die zeit, alles auszutesten. ich würde mal behaupten, dass mehr als 90% meiner queries vor sql injections geschützt sind.

zum konkreten fall: der hätte nicht funktioniert. (habs auch ausprobiert - mit backup natürlich)
zorg.ch
#62512 by @ 03.01.2005 20:26 - nach oben -
> ich interessiere mich etwas mehr als nur ansatzweise für sicherheit.

Aber Stellenweise von Unix-Permissions ueberfordert?

Versteh mich nicht falsch, aber der Satz liest sich seeehr komisch, wenn du in anderen Threads "777" als Loesung fuer Permissions-Probleme nimmst.
Gerade deswegen, da Unix-Permissions wesentlich einfach sind als Windows ACLs.

> ich würde mal behaupten, dass mehr als 90% meiner queries vor sql injections geschützt sind.

*sigh*

> zum konkreten fall: der hätte nicht funktioniert. (habs auch ausprobiert - mit backup natürlich)

Im konkreten Fall konnte man SQL Befehle injecten. Inwiefern das man damit im konkreten Fall jetzt Bullshit anstellen konnte ist eigentlich ziemlich irrelevant.

Fakt ist, das Zorg nicht mit dem geringsten Interesse an Sicherheit gecodet/konzipiert wurde. Das sieht man alleine schon an dem laxen Permission-Managment was ihr bis vor kurzem hattet.

Eigentlich ist mir das ganze auch wurscht, ich habe nicht die noetige Kompetenz um euren Code zu auditen. Wenn das System gehackt wird, who cares? root bekommen duerfte dann ein Stueckchen komplizierter werden ;)
zorg.ch
#62519 by @ 03.01.2005 20:43 - nach oben -
bei den unix-permissions hats nicht auf anhieb anders funktioniert. und ich hab weder lust noch zeit, das genauer unter die lupe zu nehmen. und da es sicherheitstechnisch nicht extrem nachteilig ist, habe ich die schnelle hässliche variante genommen. schliesslich muss man erst auf dem server zugriff haben, um da was zu basteln. da ist die sicherheitslücke schon wesentlich kleiner.

ich habe nicht die zeit dazu, sicherheitstechnisch alles rauszuholen. wie gesagt, es gibt garantiert dinge, die nachlässig gecodet wurden. aber ich mache mir gedanken um die sicherheit und setze dies in für mich vertretbaren aufwand um. deshalb lasse ich mir nicht unterstellen, dass ich ohne das geringste intersse code.
zorg.ch
#62522 by @ 03.01.2005 20:47 - nach oben -
> und ich hab weder lust noch zeit

Ist ja okay. Dann musst du aber auch nicht sagen das dir die Sicherheit nicht egal ist :)

> aber ich mache mir gedanken um die sicherheit und setze dies in für mich vertretbaren aufwand um.

Sorry, Unix-Permissions sind genauso wie Windows ACLs bei der Software-Entwicklung unter Unix respektive Windows essentiell.
zorg.ch
#62549 by @ 03.01.2005 21:45 - nach oben -
"Gerade deswegen, da Unix-Permissions wesentlich einfach sind als Windows ACLs. "

Nein, zumindest nicht zum anwenden. ;)
zorg.ch
#62551 by @ 03.01.2005 21:50 - nach oben -
Oehm, da sind wir nicht einer Meinung.
zorg.ch
#62552 by @ 03.01.2005 21:57 - nach oben -
chasch denn wohl sägä.

nein also ich finds einfacher wenn ich sagen kann "apache: lesen, besitzer: lesen, schreiben" als wenn ich da noch gruppenbastel machen muss.
zorg.ch
#62553 by @ 03.01.2005 22:03 - nach oben -
Ja, klar. Die Unix-Permissions koennen recht wenig, so dass man ziemlich basteln muss.

Aaaber:

Die Windows Chose kennt:

Owner (kann Grupper oder User sein)
Inherited ACLs
Eigene ACLs

Ein ACL kann sich aus folgenden Elemten zusammensetzen: 


Windows				Unix

Full Control			rwx

Traverse Folder / Execute File	x

List Folder / Read Data		r

Read Attributes			N/A

Read Extended Attributes	N/A

Create Files / Write Data	w

Create Folders / Append Data	N/A

Write Attributes		N/A

Write Extended Attributes	N/A

Delete Subfolders and Files	w? 

Delete				w? (nur tw. moeglich)

Read Permissions		x auf Parent?

Change Permissions		N/A

Take Ownership			N/A


Windows ACLs sind was krass komplexes, aber definitiv cool.
zorg.ch
#62555 by @ 03.01.2005 22:09 - nach oben -
Vererbung versteht man sehr schnell, den Rest muss man nicht komplett anwenden wenn man nicht will :)
zorg.ch
#62559 by @ 03.01.2005 22:17 - nach oben -
Trotzdem sind die Windows ACLs insgesamt trickier als Unix-Permissions.

Obwohl man mit Basteln bei letzteren sehr schwer verstehbare konstrukte hinkriegen kann, vorallem dann auch noch im Zusammenspiel mit Secondary Groups und wie Programme diese Interpretieren.
zorg.ch
#62563 by @ 03.01.2005 22:21 - nach oben -
Nah eben, bei Unix perms muss man viel zu schnell basteln. Nene, ein Jammer dass posix ACLs noch nicht so verbreitet sind. Irgendwie krieg ich jedesmal einen Magenkrampf wenn ich irgendwo ne Erklärung der Unix perms lese. Vorallem weil das ja meist in irgendner "Linux Anleitung" steht wo zuerst noch 2 Absätze lang steht wie sicher und durchdacht "Unix" ist.
Additional posts
zorg.ch
#62460 by @ 03.01.2005 13:56 - nach oben -
Wie fixt man das am besten?
zorg.ch
#62461 by @ 03.01.2005 13:57, edited @ 03.01.2005 13:58 - nach oben -
Hab mal ein is_numeric überprüfung eingebaut für $_GET[poll].

Merci für den Bugreport.
zorg.ch
#62463 by @ 03.01.2005 14:10 - nach oben -
das ist ja aber nicht das problem....schlim ist eigentlich mehr das man ohne angabe einer user_id die votes für einen poll löschen kann.

zorg.ch
#62471 by @ 03.01.2005 14:50 - nach oben -
Ok, dann check ich noch das man eingeloggt ist.
zorg.ch
#62497 by @ 03.01.2005 19:34 - nach oben -
natürlich kann man keine user-id dafür angeben. das wäre ja fatal, denn jeder könnte irgend eine id angeben. es wird die user-id genommen unter der man eingeloggt ist.
zorg.ch
#62498 by @ 03.01.2005 19:36 - nach oben -
ist mir im nachhinein auch aufgefallen...*g*
zorg.ch
#62486 by @ 03.01.2005 17:45 - nach oben -
Saemtlicher Untrusted Input muss ueberprueft werden.

Bei Perl gibts da etwas das einem beim Entwickeln helfen kann (tainted mode). Evtl. kann PHP was aehnliches?
zorg.ch
#62510 by @ 03.01.2005 20:15 - nach oben -
wenn du (oder jemand anders) mal auf biegen und brechen test willst, dann sag bescheid. wenn möglich nicht grad zur zorgschen rush hour. dann machen wir n backup, was wir nachher wieder zurückspielen. (müssten halt im header notieren, dass für diese zeit keine änderungen gespeichert werden)
zorg.ch
#62511 by @ 03.01.2005 20:15 - nach oben -
oder wir machen mal eine zorg-test-session
zorg.ch
#62583 by @ 03.01.2005 23:29 - nach oben -
Ne Zorg-test-und-coding-session. wo du nebenbeil mal noch das Smarty erklährst für die die das noch nicht gehört haben.
zorg.ch
#62589 by @ 03.01.2005 23:43 - nach oben -
wobei ich das schon die letzen 2x angeboten habe und nur lamber da war.
zorg.ch
#62600 by @ 04.01.2005 06:57 - nach oben -
Drum sag ich ja, für die dies noch nicht gehört haben.
zorg.ch
#62612 by @ 04.01.2005 08:50, edited @ 04.01.2005 08:50 - nach oben -
*lol* ist wohl wiedermal coder-bashing Zeit...
zorg.ch
#77920 by @ 09.08.2005 11:49 - nach oben -
Da die Codersessions bisweilen eher marginal besetzt sind, schlage ich, natürlich nach bundigem Backup des ganzen Systems, eine Zorg Cracksession vor =)

Mal schauen, was man alles kaputtmachen kann. Rekursive Smarty-Sachen, PHP im Post, scripten im IRC, irgendwelche ID's in der URL ändern, blah.

Ja, mir ist beinahe langweilig. Aber nur beinahe.