3
-
deni3 #3 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 -
gombabácsi #2 é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) -
#1
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.