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
1 up |
^^^ Additional posts ^^^
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.
zorg.ch
#62564 by @ 03.01.2005 22:24 - nach oben -
Die Posix ACLs loesen leider viele Probleme der Unix-Permissions nicht :/
Additional posts