Hacked by 0o_zeus_o0 - Az olimpusklan feltörte az oldalam!
2005-11-09T10:07:23+01:00
2005-11-17T18:32:55+01:00
2022-07-26T22:17:35+02:00
  • A legjobb módszer az elfelejtett jelszóra a jelszó újraküldés: megadja az e-mail címét, amire kkimegy egy vérvényesítő link. Arra rákattint, és ha érvényes és kód, akkor felültudja írni a régi jelszót.

    Igen, csak mint tudjuk, az email címek megszűnhetnek, akár önhibán kívül is. És akkor máris meg van lőve ez a módszer.
    Mutasd a teljes hozzászólást!
  • Neked, djcomplexnek, nekem tényleg ez a legjobb megoldás, mert ez érdekel, ezt csináljuk. Biztonságosabb is, meg logikusabb. Sose használtam még, de nem vagyok benne biztos, hogy anyukám, nagymamám, meg a boltos bácsi nem használná. Nekik az talán sokkal egyszerűbb, talán még akkor is, ha nem engeded emlékeztetőnek magát a jelszót (vagy azt tartalmazó szöveget). Nem kötekedés akar lenni.

    Mert szerintem egy hirdetési oldalt kevesebb jellegű ember használ, mint laikus. (- Há, komám, ee köllene má anni aztat a zsigulit. - Há tödd fő a zinternetre, a vejöm is ottan szokta elanni a dógait! - ő nem fog olyan könnyen megbirkózni egy több sorba tördelt, kódot tartalmazó linkkel, aminek a levelezője csak az 1. sorát ismeri fel linkként, aztán meg nem fog tudni belépni, mert a hiányos kódra nem kap jelszót.)
    Mutasd a teljes hozzászólást!
  • Jah, az emlékeztető egy nagy hülyeség, azt is ugyanúgy el lehet felejteni, sőt még jobban.
    A legjobb módszer az elfelejtett jelszóra a jelszó újraküldés: megadja az e-mail címét, amire kkimegy egy vérvényesítő link. Arra rákattint, és ha érvényes és kód, akkor felültudja írni a régi jelszót.
    Mutasd a teljes hozzászólást!
  • Más:
    Te használtad már valaha is valamire azt az emlékeztetőt?
    Mert én még soha. Nem sok értelmét látom.
    Mutasd a teljes hozzászólást!
  • Ehhez még hozzátenném, hogy ennél sokkal körültekintőbben kéne kezelni a userek adatait, jelszót 2x kérdezni meg, ha már nem mondja meg személyiségi jogokra hivatkozva, legalább védd az elgépelés ellen. És figyelj oda jobban, hogy a user mit kavarhat az adatbázisban. Ha nem mondod meg a jelszót, legalább rendelhetnél a user névhez emlékeztetőt.
    Mutasd a teljes hozzászólást!
  • A session-kezelésen azért még van mit foltozni..
    - nem jó, ha URL-ben továbbítod
    - hiába lépek ki, nem törlődik a session
    - ha ismét az oldalra lépek, ugyanazt a session kapom, akárhányszor lépkedek ki-be, csinálok bármit.
    - kimásolva a session tartalmazó URL-t, akár egy másik böngészőbe is beillesztve tudom módosítani az adatokat (pedig ugye kilptem..)
    Mutasd a teljes hozzászólást!
  • user banned
    Mutasd a teljes hozzászólást!
  • Valami változhatott, mert most meg nem működik. Belépni nem tudok az új jelszóval, de a régivel se.
    Mutasd a teljes hozzászólást!
  • Persze, hiszen minek is bajlódna az ember ilyesmivel, ha van sokkal egyszerűbb mód is. Légyszi a

    nick LIKE 'Athos%'

    felhasználókat, és az 'Athos' által feladott 1 db. állat-növény hirdetést is töröld, már nincs rájuk szükség.

    SZVSZ még ne élesítsd, hanem próbáld ki ezt:

    1. regisztrálj egy felhasználót pl. 'Athos3' néven, 'proba' jelszóval, többi adat tetszőleges.
    2. lépj ki, és regisztráld 'Athos4'-et, 'valami' jelszóval.
    3. Athos4-ként belépve nézd meg az Adataim menüpontot.
    4. Írd át a nevet Athos3-ra, a jelszót pedig 'ujjelszo'-ra (akár az összes többi adatot is módosíthatod).
    5. Küldd el a formot, majd lépj ki, és próbálj belépni Athos3 néven, 'proba' jelszóval.
    6. Vedd észre, hogy az 'ujjelszo' sokkal hamarabb vezet eredményre.

    Tipp: én nem hasznám a user-eimet azonosítót váltani, vagy ha igen, akkor az azonosító legyen már egyedi.

    Jelszó váltásnál kérném a régi jelszót, és az újat kétszer.

    A főoldalon a belépős jelszó input legyen password típusú.

    Adat-jelszó módosításnál legelőször azt vizsgálnám, hogy a nick, amivel a user azonosítani akarja magát, egyedi-e (akkor is, ha változik, mindegy, csak legyen egyedi, és a régi nickjét pedig tedd a session-ba, azt nem tudja megváltoztatni).

    A célom az volt, hogy egy felhasználó valamely adatát megváltoztassam, ami hirdetéseknél azért jó nekem, mert az ő érdeklődőit magamhoz tudom irányítani, vagy kamu elérhetőségre, és én magam tudom vele felvenni a kapcsolatot. Mivel rajtam kívül senki nem jelentkezik nála, ezért előnyhöz juthatok, pl. alkuval. Lásd: Robin Williams Mrs. Doubtfire (Mrs. Tűzvolte) c. filmjét.

    Ja, és légyszi ne perelj be hekkelésért.
    Mutasd a teljes hozzászólást!
  • Ha ez a topic meg lesz oldva, akkor sokat segít rajtunk!

    mármint az sql incejtiont kilövi :)
    Mutasd a teljes hozzászólást!
  • Kössz, mostmár világos; végigolvastam a topicot, csak nem volt így összefoglalva, és elvesztem a sorok között.
    Ezek szerint egy ilyen móriczka hekkeléssel nem biztos, hogy fel lehet törni egy egyszerű oldalt.
    Mutasd a teljes hozzászólást!
  • Olvasd már el a topicot... akkor lehetséges, ha
    - van nem ' közé tett változó a queryben (nálad nincs, de nagyon sok kódban van)
    - a magic quotes a php.iniben vagy .htaccess fájlban le van tiltva, vagy stripslasheled a változót. UWh mq on az iniben, htaccess nem használható, a kódodban stripslashes nincs. Nem mellesleg utóbbi lehetne, mert a jelszót most perekkel együtt md5ölöd... Tehát ha a jelszó i'yé, akkor te i/'yé az jelszó md5ét tárolod el...
    Mutasd a teljes hozzászólást!
  • Üdv.
    Nem egészen értem, miért mondjátok, hogy olyan egyszerű ez az sql injection.
    Nekem nem sikerült feltörni az egyik oldalam (elkelt.uw.hu), hiába próbálkoztam.

    Az adatok kinyerése:
    $fnev=$_POST["fnev"];
    $password=md5($_POST["password"]);
    $check="SELECT * FROM felh WHERE nick='$fnev' AND pass='$password'";
    $eredm = mysql_query($check);

    Ha ebben az esetben valójában egyszerű a hackelés, leírhatná valaki, hogy kezdjek neki.

    (Meg lehet próbálni nyugodtan feltörni az oldalt :) )
    Mutasd a teljes hozzászólást!
  • És volt már róla szó, hogy a megoldást a tárolt eljárások, illetve a paraméterezett queryk jelentik (sprintf illetve vsprintf a barátod)
    Mutasd a teljes hozzászólást!
  • Már van saját adatbázis osztályom.

    De engem most konkrétan az SQL Innjecció elleni megoldás érdekelne.
    Mutasd a teljes hozzászólást!
  • "Persze nem tudom ez mennyire veszélyes, hisz a legtöbb helyen a delete eleve felhasználói jogosultsághoz van kötve, a select-ből meg nem lehet akkora baj."


    NEM!


    Képzeld el mondjuk egy ehhez hasonló fórumnak a regisztrációs adatbázisát.

    Általában szokott lenni egy "elfelejtett jelszó" menüpont, mely elküldi levélben a felhasználói név + jelszó kombinációdat a megadott e-mail címre.

    Nos ebben az esetben az 1=1 -el, (amit inkább 'a'='a - ként szoktak írni...) egy rosszul megírt script esetén elérheted, hogy az összes felhasználó nevét+jelszavát megkapod levélben!

    Ez talán még nem is tűnik olyan vészesnek - :) - de lehet ilyen lista, ahol a bankszámlaszámaidat írják ki...


    Ami pedig a jogosultsághoz kötött DELETE-t illeti:

    Kétlem, hogy a regisztrációs táblából - ha lehet törölni - akkor csak a saját nevedet tudnád letörölni. Ebben az esetben ugyanis a fórumot látogató pár ezer embert fel kéne venni userként...

    Mutasd a teljes hozzászólást!
  • Én is utána néztem a témának és ezt találtam:
    sql injection

    Eszerint a mysql_query nem enged meg több SQL utasítást, és ez a támadások esélyét jelentősen csökkenti.

    (Nincs ;delete from xyz)

    A Magic Quotes a stringeknél véd hisz a '-jelet nem lehet kiküszöbölni, viszont a numerikus adatoknál nem.

    Tehát a select xyz from xyz where xyz=$id

    az $id lehet "1 or 1=1" tehát ez hiba lehetőség

    Persze nem tudom ez mennyire veszélyes, hisz a legtöbb helyen a delete eleve felhasználói jogosultsághoz van kötve, a select-ből meg nem lehet akkora baj.

    Tehát azt kell leellenőrizni, hogy akinek van törlési jogosultsága nehogy olyat töröljön, amit már neki se szabad.

    Én legalábbis így látom.
    Mutasd a teljes hozzászólást!
  • Biztosan többen is megtették már.

    De valóban, irhatsz te is. Kiindulásnak ez szerintem megfelelő. Aztán lehet gondolkodni a továbbiakon.
    Mutasd a teljes hozzászólást!
  • Írj saját db-kezelő osztályt, amiben egy osztályon belül kezeled a kapcsolatot, a kéréseket, eredményeket, stb, stb, és abban úgy ellenőrzöl le akár minden karakter, ahogy akarsz, és azt adnak vissza az metódusaid, amit megengedsz.
    Mutasd a teljes hozzászólást!
  • Ha ez a topic meg a tudástár meg a linkek alapján nem tudsz írni egy normális sql classt, akkor a helyedben elgondolkodnék miért programozok...

    Vagy ott van a pear.
    Mutasd a teljes hozzászólást!
  • Nem írna valaki egy SafeMySQLQuery() függvényt? (PHP)
    Mutasd a teljes hozzászólást!
  • Ha valakit érdekel a beszélő SQL szerver:

    Amikor elsül a kapanyél...
    Mutasd a teljes hozzászólást!
  • "Bármi esetén ami SQL adatbázist használ és POST-al vagy GET-el kapott adatokat küzvetlenül fölhasznál."


    Nem kell oda még webes technológia sem. Elég egy rosszul megírt hagyományos program is, akár Delphi-ben vagy VB-ben, stb...

    Egy sima TEdit-el is el lehet követni ezt a hibát...


    Ezért írtam a paraméterezett eljárásokat: ott alapból védve vagy a technológia miatt mindegy, hogy miképp viszed be az adatokat (web, TEdit, SMS, stb...)
    Mutasd a teljes hozzászólást!
  • Akit érdekel, itt egy jó könyv, most találtam, Chris Shiflett - Essential PHP Security.
    (SQL injection, session hijacking, bruteforce, stb. példákon keresztül mutatja be, a védekezés módszereit.)
    Mutasd a teljes hozzászólást!
  • Elírtam.
    topic WHERE parent='.$_GET['parent']); akart lenni, és így már tényleg veszélyes.

    mysql_insertnél a querybe perekkel kerül bele, de egy stringbe, tehát a mysql tudja hogy escapelt, és leszedi róla. Selectkor nem escapeli újra, ez logikus. A probléma nem a kiíráskor van, hanem pl. a hosszellenőrzéskor.

    urlencode nem arra való, az a linkekhez kell a href tagba, meg form action, és ilyenek. De van htmlspecialchars, htmlentities, stb, azokkal ki lehet védeni.
    Mutasd a teljes hozzászólást!
  • topic WHERE parent='.$_GET['parent;]); - működhetne
    - helló, erre szerintem kiakad a php

    Az addshashes-stripslashes párosra meg nem tudok mit mondani, az tény:

    1) User posted name: D'rk
    2) $_POST["name"] ==> "D\'rk";
    3) mysql_insert..$_POST["name"]
    nade
    4) $nev=mysql_select.. where name=$_POST["name"] szal a most regelt név visszakeresése
    5) print $nev
    Na, mi lesz az eredmény?
    Elsőnek aszittem D\'rk, de ehelyett simán visszadata a D'rk-ot. Ugyanígy D"rk - kal is.
    Tehát úgytűnik a php okosan megoldja a dolgot, így sql injectionra nincs lehetőség
    (ellenben HTML injectionra meg igen lásd:
    adamódosítás.

    $user=select.... ($user -> D"rk)
    print 'Új név: <input type="text" name="name" value="'.$user.'">';

    nos új névnek meg beírom:
    olyan value, amit én adok hozzá ehe ehe" onmouseover="javascript:alert('this is little problem')"

    Ha megint az "adatmódosításra" mész, kiakad

    Ezt most vettem észre.

    Szerintem alapvető az < &lt; > &gt; csere, így a most említett hibával ilyet, hogy <img.. nem lehet beszúrni. Nade: js-sel innerhtml-lel nem lehet odairatni pl asci kód alapján?

    Na meg mi lenne a legjobb megoldás? Ez, hogy value="<?=urlencode($nev)"?> nem ad megoldást a " hibára????
    Mutasd a teljes hozzászólást!
  • Bármi esetén ami SQL adatbázist használ és POST-al vagy GET-el kapott adatokat küzvetlenül fölhasznál.
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    en csak kerdeznek valamit, sql injektalas problemaja csak php eseteben allhat fenn, vagy barmilyen hasonlo webes technologianal?
    Mutasd a teljes hozzászólást!
  • Gusztustalan is lenne egy olyan oldal, esetében, ahol pont programozással foglalkoznak....

    üdv.
    Mutasd a teljes hozzászólást!
  • Szerintem a prog.hu-n nem egészen így van leprogramozva, mint az átlag sql-injection-nal hekkelhető oldalakban. :D
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd