Ez durva. Szerencsére én egyrészt csak úgy titkosítatlanul nem tárolok semmi érzékeny dolgot idegen gépen, másrészt meg nem is a Dropboxot használom, hanem a kicsit jobb Sugarsync-et (5 GB ingyen, tetszõleges mappa szinkronizálható, multi platform stb.). Aki kipróbálná, kap még 500 MB-ot (meg persze én is), ha rajtam keresztül regisztrál: https://www.sugarsync.com/referral?rf=dhkixkci6g3zr
én meg úgy szoktam, hogy automatizálok minden ilyensmit release-be sose mehet ki debug céllal berakott izé legalábbis 20 éve így csináltam amikor még aktívan kódoltam, azóta persze biztos sokat fejlõdött a világ :o)
Azért ez durva...
Ha van egy kis eszük, biztos nem adatbázislekérés szûrõfeltételeként implementálják a jelszóellenõrzést, hiszen minden SQL Injection tutorialban egy ilyen ellenõrzés támadását mutatják be. Még ha szûrve vannak a bemeneti mezõk, akkor sem célszerû ennyire közismert és pofonegyszerû ellenõrzést használni.
A saját rendszerem pl a megadott felhasználónév alapján lekéri a komplett rekordot függetlenül a jelszó helyességétõl, majd azt csak késõbb ellenõrzi egy if szelekcióval. Direkt nézegettem most a kódomat, hogy mit tudnék elbaszni véletlenül, hogy ez a hibajelenség elõállhasson ami a Dropboxnál.
Arra a következtetésre jutottam, hogy a C nyelvcsaládban használatos == (egyenlõ -e) jelbõl csináltak valahogy véletlenül = (legyen egyenlõ) jelet, ami ugye egy if szelekció feltételeként megadva is érvényre jut, sikeres értékadási mûvelet esetén TRUE visszatérési értéket adva. Ha ez történt, márpedig akárhogy nézek egy megfelelõen biztonságos authentikációs ellenõrzést más nem történhetett, akkor az egyszerûen nevetséges. Az IDE amit használok ordít, ha szimpla egyenlõségjelet írok egy szelekcióba (sokszor szándékosan, resource hozzárendelés + mûvelet sikerességének ellenõrzése), lehetetlen nem észrevenni.
Informatika és tudomány
