- Samsung Galaxy A52s 5G - jó S-tehetség
- Android alkalmazások - szoftver kibeszélő topik
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- Samsung Galaxy A34 - plus size modell
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Samsung Galaxy Watch7 - kötelező kör
- Extra erő egy gombnyomásra - Engwe EP-2 Boost
- Mobilinternet EU-n kívül, eSIM adatcsomagok használata
- Érintésnélküli fizetési megoldások - PayPass via NFC
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
Új hozzászólás Aktív témák
-
cucka
addikt
válasz
Odiepapa #3623 üzenetére
Ezt a https dolgot minek erőlteted? A weboldalak 98%-a sima http-n megy, talán azért, mert a hálózati adatforgalmat marha nehéz elcsípni és megtalálni benne a jelszót. Nyilván vannak esetek, ahol ettől függetlenül szükséges a https, de gondolom nem banki weboldalt készítesz..
A másik, hogy ha nem igényelsz (pénzért) egy hitelesített cert-et, akkor inkább csak bosszantó lesz az egész a felhasználónak. -
cucka
addikt
válasz
Odiepapa #3613 üzenetére
Viszont egy double hashelest bevetek en is. A jelszoemlekeztetohoz meg kicsit maskeppen/ masmezoben tarolom a dolgokat, hogy vissza tudjam fejteni,
Ennek semmi értelme. Ha szükséged van a jelszóemlékeztetőre, akkor tárold el sima szövegként a jelszót, ellenkező esetben pedig elég a hash.Ujabb biztonsagi kerdes: formbol gondolom keyloggerrel lehet a legegyszerubben kiszedni adatokat
Gondolom egy átlagos weboldalról van szó. Ez esetben a gonosz hackereket egyáltalán nem a jelszó érdekli. Ha én lennék a gonosz hacker és fel szeretném törni a prohardveres felhasználói fiókodat, akkor nem a jelszavad érdekelne, hanem bármilyen más módszer, amivel el tudom hitetni a rendszerrel, hogy be vagyok lépve a te nevedben. Például ellopom a session-ödet, vagy valamilyen sql injection-t használok, ilyesmi.Cucka, megtenned, hogy gyorsan felvazolod ennek a megoldasat?
Már felvázolták. Amikor bejelentkezik egy felhasználó, akkor eltárolod az adatbázisban az ip címét és a user agent-jét. Minden oldallekérés elején ellenőrzöd, hogy változtak-e ezek az adatok. Ha változtak, az azt jelenti, hogy az illető felhasználónak sikeresen ellopták a session-jét, tehát kilépteted és átirányítod a bejelentkezéshez. Továbbá oda kell figyelni arra, hogy az adatok tárolására szolgáló adatbázis táblát karbantartsd, illetve ez a módszer gondot okozhat azoknál a felhasználóknál, akik valamilyen anonimizáló rendszeren keresztül érik el az oldaladat. -
fordfairlane
veterán
válasz
Odiepapa #3613 üzenetére
Cucka, megtenned, hogy gyorsan felvazolod ennek a megoldasat?
Bizonyára valami olyan megoldásra gondolt, hogy belépésnél eltárolod a kliensgép IP címét és/vagy user agent stringjét ($_SERVER["REMOTE_ADDR"] , $_SERVER["HTTP_USER_AGENT"]) , amit minden oldallekérésnél ellenőrzöl, hogy stimmel-e. Ha nem stimmel, az az esetek praktikusan 100 százalékában session hijack próbálkozást jelent.
-
cucka
addikt
válasz
Odiepapa #3604 üzenetére
2. hogyan tudom visszafejteni a kodot egy esetleges jelszoemlekezteto email kuldese alkalmaval?
Sehogy. Az a lényege, hogy nem lehet visszafejteni.3. Ti hogy oldjatok meg a jelszoemlekeztetot, ha esetleg nem fejtitek vissza a kodot?
Értelemszerűen sehogy. Ha nem tárolod el a jelszót, akkor nem küldhetsz jelszóemlékeztetőt, ehelyett mondjuk kérhet a felhasználó egy új jelszót, amit megkap email-ben.Azert kerdezem, mert egyre jobban parazok a jelszolopasok miatt.
Annyira azért nem kell, a jelszavakat nem így lopják.hogy a session-be belepeskor betoltottem a jelszot is az adatok koze, hogy tudjon valtoztatni rajta (alias lassa a jelenlegit is), de ezt a dolgot kiszedtem, mert attol is parazok hogy a cockie-bol ki lehet preselni ezeket az adatokat.
Nem lehet kipréselni, a cookie-ban csak a session id van eltárolva. Olvass utána, hogy hogy működik a php session. -
1ed
csendes tag
-
cucka
addikt
válasz
Odiepapa #3226 üzenetére
Úgy kell megoldani, hogy a webszerver ütemezője időnként elindít egy php programot, ami megcsinálja a feladatot (természetesen a php-t parancssorosan hívja). Ha ilyen kérdéseid vannak, akkor remélhetőleg nem te vagy a szerver rendszergazdája, szóval kérdezd meg nyugodtan, egy rendszergazdának ez nem számít sem túl bonyolult feladatnak, sem pedig extrém kérésnek.
-
Tele von Zsinór
őstag
válasz
Odiepapa #2939 üzenetére
Mintha *nix szervereken az aktuális usert helyettesítené be, de nem vagyok rendszergazda, szóval google. Másrészt pedig a mailnek van egy additional headers paramétere, oda tegyél egy From-ot, és jó lesz.
Állítsd be rendesen a szervert, hogy ne csak az index.html-t, hanem a .php-t is indexnek tekinse. A böngésző úgyis csak úgy kéri, mint "/".
Használj get helyett post-ot. -
burgatshow
veterán
-
Tele von Zsinór
őstag
válasz
Odiepapa #2736 üzenetére
Miért "sajna"? Ez annyit tesz, hogy a kliens böngészője ismeri és engedélyezi a sütik fogadását, nem urlben kell átadnod a sessionid-t.
Ezzel visszaélni akkor lehet, ha elkapja valami köztes fél, beállítja magánál sütinek és meglátogatja az oldalad - persze az is kell, hogy nálad ne legyen ip, user-agent, stb. ellenőrzés. -
ArchElf
addikt
válasz
Odiepapa #2719 üzenetére
Javaslatok:
- password ne menjen át cleartext-ben a hálózaton, ne legyen cleartextben tárolva az adatbázisban (lehetőleg ne is titkosítva, hanem hash-elve legyen)
- username:password ne legyen eltárolva cookie-ban
- az include könyvtárra ne legyen joga a böngésző usernek
- a php hibaüzeneteket nem jelenítjük meg az oldalon (tipikus hiba adatbázis kezelésnél), menjenek szerver oldali logba, és esetleg dobjon egy mail-t a kód az üzemeltetőnek
- szerveroldalon a kapott adatokat mindig ellenőrizni kell: a kliens azt küld, amit akar, nem szükségszerúen azt, amit várunk
- adatbázis beillesztésnél az SQL injection-re figyelni kell, legegyszerűbb (mint alant is írtam) prepared insert-et használni
- XSS védelem: amennyiben a GET/POST-ban kapott adatokat (azonnal, vagy később) megjelenítjük, figyeljünk oda, hogy véletélenül se jelenítsünk meg olyan HTML kódot, amit nem szeretnénk (legegyszerűbb kivédési mód a htmlspecialchars() használata - letárolás vagy megjelenítés elött)Amennyiben komolyak biztonsági szempontok, akkor a következőkre kell figyelni:
- ne lehessen egy kérést újra elküldeni - a session azonosítóban kel egy (illetve kettő) számláló, amit a szerver (kettö esetében a szerver és a kliens) növel, vagy generáljon a szerver minden letöltéshez új session hash-t
- ha kézikusan készül a session kezelés, akkor a session lejáratra oda kell figyelni
- célszerű titkosításon keresztül üzemelni, de legalább is az azonosítást azon keresztül végezni - bár ezt leginkább a password cleartextben való elküldésének védelmére szokták használni (https - csakis aláírt tanúsítvánnyal)
- ha cookie alapú a session, akkor a cookie ellopásával ne lehessen másik helyról bejelentkezni, lejárt, de kézzel visszatöltött cookie-val ne lehessen bejelentkezniEgyelőre ennyi jutott az eszembe...
AE
-
Odiepapa
csendes tag
válasz
Odiepapa #2712 üzenetére
kicsi modositas az elozo kerdesemen:
Amikor adatbazisbol betoltom az elozoleg feltoltott textarea tartalmat az oldalra egy $valami [blob] valtozoba es kiiratom print $valami, akkor nem tartja a szokozoket. Viszont ha modositashoz betoltom a textarea ablakba a $valami tartalmat, akkor viszont ott van a szokoz. Tehat a soremelesek tarolodnak, csak print parancsra nem igazan adja vissza azt, ami igazabol ott van. (remelem ertheto modon irtam le
)
ezen hogy lehet segiteni?
-
vancha2
aktív tag
válasz
Odiepapa #2710 üzenetére
A mysql_real_escape_string() escape-eli a karaktereket, pl a "-ből \"-öt csinál.
A htmlspecialchars() a speciális, HTML-ben használt karaktereket alakítja át az entitás kódjukká, pl a "-ből "-ot csinál.Ezek után egyértelmű, hogy mikor melyiket érdemes használni.
-
ArchElf
addikt
válasz
Odiepapa #2705 üzenetére
Ha sok elemed van, akkor benyomod az összeset egy temp táblába, és betöltöd a következővel:
INSERT INTO
CelTabla (mezo1, ...)
SELECT
mezo1, ...
FROM
Temp
WHERE
ID NOT IN (SELECT ID FROM CelTabla)Utána csak droppolod a temp táblát.
Ja és nem kell vacakolni az escapeléssel, PREPARED EXECUTE-ot kell használni.
AE
-
Tele von Zsinór
őstag
válasz
Odiepapa #2705 üzenetére
A te $eredmeny változód nem egy tömb lesz, hanem egy mysql erőforrásra való mutató. Egy-egy sort a mysql_fetch_* függvények valamelyikével tudsz lekérni, ha az egészet tömbbe akarod, akkor valahogy így:
$tomb = array()
while (false !== ($row = mysql_fetch_array($eredmeny))) { $tomb[] = $row; }Ahol a $eredmeny az, amit te beállítottál neki a függvényed első sorában, a $tomb pedig az összes sort fogja tartalmazni asszociatív és számokkal indexelt tömbökként.
Más: a $service és a $id már escapelt? Ha nem, komoly biztonsági kockázatot jelent csak így berakni őket a querybe, használd előbb rajtuk a mysql_real_escape_string() függvényt!
Új hozzászólás Aktív témák
Hirdetés
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- OLED monitor topik
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Autós topik látogatók beszélgetős, offolós topikja
- Filmvilág
- Vegyszerek, permetezés, Élettani hatások
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
- UF Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -60% i7-1360P 16/1TB Iris Xe 2,8K OLED 90Hz
- Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -60% i7-1260P 16/512 Iris Xe 2,8K OLED 90Hz
- Új DELL Inspiron 16 Fémházas Multimédiás Laptop 16" -40% Ryzen 7 8840U 8mag 16/1TB FHD+ IPS
- Új DELL Inspiron 16 Fémházas Multimédiás Laptop 16" -40% Ryzen 7 8840U 8mag 16/1TB FHD+ IPS
- Sony FE 28-70 mm F3.5-5.6 OSS
- BESZÁMÍTÁS! Gigabyte A620M R5 7600 32GB DDR5 512GB SSD RTX 4070 12GB ZALMAN S2 TG EVGA 650W
- Wilbur Smith könyvek (15 db) egyben
- BESZÁMÍTÁS! Logitech G923 kormány + Driving Force Shifter garanciával hibátlan működéssel
- BESZÁMÍTÁS! Nintendo Switch 32GB V2 játékkonzol garanciával hibátlan működéssel
- Csere-Beszámítás! Asus Tuf RX 9070 XT 16GB Videokrátya! Bemutató darab!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest