Vlákno názorů k článku Zranitelnosti typu injekce: vložení systémového příkazu od mhi - Neni to reseni vsech problemu, ale dovoluji si...

Neni to reseni vsech problemu, ale dovoluji si tvrdit, ze vetsiny - osetrit nejake vstupy, napr. aby nekdo nepodvrhnul misto URL /etc/passwd apod., je uz pomerne trivialni a "snadno" uhlidatelny problem. Na rozdil od "nenapada mne ani co vsechno s tim shell muze udelat".

problem je, ze v tom url muzete mit %2f%65%74%63%­2f%70%61%73%73%77%64 misto /etc/passwd... nebo /etc/passwd
tudiz budto vite presne jak vypada vas vstup nebo to proste osetrujete jinak...

'/etc/passwd' bylo to druhe....

tak root mi to prevadi na text.. .:D

Ono jde hlavne o to, ze kdyz mas vstup, kde ma byt URL, tak zajistit, aby se to nijak jinak nez jako URL nedalo pouzit. A ne ze nekdo veme vstup, posle ho nejakym parseru a ten z toho trebas zjisti, ze ma vlastne spustit rm -rf. Coz jaksi tvurce vubec nepobral, protoze on prece pouziva tu uzasnou knihovnu (nebo ten uzasnej frejmwork) aby se timhle nemusel zebejvat.

Je to stejny, jako kdyz v kodu vidis try (a+b) catch "asi to neni cislo". 0xAC47 ... ovsem tahle vec jako cislo klidne veme. A to se pak dejou veci ... kdyz trebas aplikace tvrdi, ze A + B = 21 ;D.

Ktera bezna utilita vezme argv[] a prohani to nejakym urldecoderem? Pak at' si klidne "2f%65%74%63%­2f%70%61%73%73%77%64 " otevira ...

Chtel jsem tim jen rict, ze volani system() vnasi celou radu problemu, o kterych autor aplikace ani nemuze tusit (protoze treba jen nevi co je /bin/sh). namatkou zneuziti $VAR v ruznych formach zapisu , `cat /etc/passwd`, "... ; cat /etc/passwd", hvezdickove doplneni, ... atd.

U execve resime jen bezpecnost volane aplikace, u system() navic i shellu, ktery dneska umi pomalu uvarit i kafe.