- Magga: PLEX: multimédia az egész lakásban
- Gurulunk, WAZE?!
- gban: Ingyen kellene, de tegnapra
- Parci: Milyen mosógépet vegyek?
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Argos: Szeretem az ecetfát
Új hozzászólás Aktív témák
-
Tele von Zsinór
őstag
1. erre az az általános megoldás, hogy bejelentkezéskor egy hosszú lejáratú sütit is adsz a felhasználónak valami véletlen értékkel, amit emellett egyaránt tárolsz adatbázisban. Legközelebb, ha olyan helyzet áll elő, hogy ilyet kapsz, de sessiont nem, akkor tudod ellenőrizni, van-e ilyen azonosítójú "hosszú session", és belépteted a megfelelő felhasználót.
Az alkalmazás megkövetelt biztonsági szintjétől függ, hogy pár nap vagy pár hét lejáratú a süti, illetve hogy milyen gyakran cseréled az így tárolt random értéket.2. az utf8 egyike a számos úgynevezett változó szélességű karakterkódolásnak - jelen esetben ez annyit tesz, hogy egy karaktert lehet, hogy egy byte kódol, de akár szükség lehet hatra is. A php-ban vannak erre szolgáló függvények, ezek neve mb_-vel kezdődik, itt az összefoglaló dokumentáció a multibyte stringfüggvényekről. Elsőre soknak tűnhet, de kellenek.
3. azokról valóban érdemes leszokni. A már meglevő kódjaid ne féltsd, még legalább évekik létezni és működni fognak azok a függvények is.
A vélemények megoszlanak, de a többség (én is) arra hajlik, hogy a PDO jobb. Hasznos lehet, ha menet közben esetleg váltanod kell másra (mysql helyett pgsql, például), magánvéleményem szerint az apija is kényelmesebb, nem túl rég írtam egy rövid bevezetőt a PDO-ba, ezt az aláírásomban szereplő .eu-s linken megtalálod).4. ha valami hiba történik, arról értelmezhető hibaüzenetet soha ne kapjon a felhasználó. Semmit nem ér vele, általános esetben legfeljebb összezavarja, rossz esetben megtud valami olyat a rendszer belső működéséről, amit támadási felületként használhat - ezt hívják információszivárgásnak. Bármi hiba történik, amit nem tudsz lekezelni normálisan, a felhasználó kapjon egy általános http500-as hibaoldalt. Ez nálam egy sima html oldal, php-ből include-olom és die(). Nyilván naplózás után.
5. olvass utána a prepared statement kifejezésnek. Röviden: átadsz a szervernek egy queryt, jelezve, hogy itt és itt és itt paraméterek lesznek. Ezt ő előkészíti, aztán mondod, hogy hajtsa végre azt, ezekkel a paraméterekkel. Legjobb tudomásom szerint tökéletes védelem az SQL injection ellen, felesleges körök nélkül.
A még mysql_ függvényeket használó kódjaidban elég a mysql_real_escape_string mindenre! alkalmazva, ami a felhasználótól jön. És nyugodtan feltételezheted, hogy a függvény létezik, nem kell külön ellenőrizni.6. ennyi. Esetleg hetente egyszer egy olyat csinálj, hogy törlöd azokat, akik legalább n napja regisztráltak, de még azóta sem aktiváltak.
-
Peter Kiss
őstag
-
Sk8erPeter
nagyúr
Lenne még hozzáfűznivalóm:
igen, lehetőleg egyezzenek a karakterkódolásaid.
4. pontra: igen, sebezhetőséget jelent az, ha kiíratsz bármi "nyers" hibaüzenetet. Már eleve az egy sebezhetőség, hogy bármilyen információt árulsz el a rendszered belső működéséről. Akár mezőnevek, akár szintaktikai hibák adott lekérésben vagy máshol, akár elérési utak, vagy bármilyen, a külvilágra nem tartozó információ segíthet egy ártó szándékú látogatót a céljai elérésében. Ezt akkor hiszed majd el igazán, ha valaki gyakorlati példán mutatja be neked (mondjuk előadás keretében), hogy egy sebezhető rendszer adataihoz pl. kiírt hibaüzenetek alapján hogyan lehet még gyorsabban hozzájutni; akár bejuttatni saját, nem kívánt adatot a rendszerbe.
PDO tényleg jó, és ha ezt kezded el használni, könnyebben rá fog állni a kezed és agyad az ORM-ek használatára.
Most hirtelen még ennyi jutott eszembe. -
1. Session -nal csinálod, akkor a session tömböt használd - [link]. Én úgy szoktam, hogy csinálok egy random valamit, amit eltárolok mind a session tömbben, mind az adatbázisban és ha létezik + megegyezik, akkor tovább dobom a usert, ellenkező esetben beléptetem újra.
2. Az utf8 -nak jónak kéne lenni, ott valami nem jó szerintem. Ha teheted utf8 -at használj, igen mindenhol.
3. PDO
4. Hát amíg fejlesztesz, szerintem mindent írass ki, utána pedig logolj.
5. a mysql_real_escape_string elvileg "elég".
6. Mondjuk kiküldesz neki egy random jelszót, amit első bejelentkezéskor kell megváltoztatni, és akkor állítod true -ra a változóját?
Új hozzászólás Aktív témák
Hirdetés
- Telefon felvásárlás!! Xiaomi Redmi Note 12, Xiaomi Redmi Note 12 Pro, Xiaomi Redmi Note 12 Pro+
- BESZÁMÍTÁS! 860W Fractal Design ION + 2 Platinum tápegység garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS ROG STRIX X570-E Gaming alaplap garanciával hibátlan működéssel
- Beszámítás! Apple iPad 11 2025 128GB WiFi tablet garanciával hibátlan működéssel
- BESZÁMÍTÁS! Gigabyte B450M R5 5600X 16GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Seasonic 520W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged