- Samsung Galaxy S23 Ultra - non plus ultra
- One mobilszolgáltatások
- Redmi Note 13 4G
- Milyen okostelefont vegyek?
- Felújított okostelefonokat kínál a Rejoy
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
- Fotók, videók mobillal
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Vivo X200 Pro - a kétszázát!
Ú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. -
#3614
fordfairlane
veterán
Odiepapa
#3613
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. -
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.
-
#2940
Tele von Zsinór
őstag
Odiepapa
#2939
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. -
#2752
burgatshow
veterán
Odiepapa
#2736
burgatshow
veterán
-
#2737
Tele von Zsinór
őstag
Odiepapa
#2736
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
-
#2706
Tele von Zsinór
őstag
Odiepapa
#2705
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!
Pedig hasonlót csináltam az admin felületen. 
Új hozzászólás Aktív témák
Hirdetés
- Precision 3580 27% 15.6" FHD IPS i7-1360P RTX A500 32GB 512GB NVMe magyar vbill gar
- Intel Core i5-13500 OEM
- Toshiba Surveillance Pro S300 8TB megfigyelőrendszerekre optimalizált merevlemez
- Seasonic Focus GX 1000W 80+ gold
- Latitude 5530 27% 15.6" FHD IPS i7-1265U 16GB 512GB NVMe magyar vbill ujjlolv IR kam gar
- Samsung Galaxy A04 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! ASROCK B650 R5 7600X 32GB DDR5 1TB SSD RTX 3070 8GB MSI MPG Gungnir 100 Enermax 750W
- BESZÁMÍTÁS! ASUS ROG CROSSHAIR VI EXTREME alaplap garanciával hibátlan működéssel
- Csere-Beszámítás! Asus Rog Strix GTX 1080Ti 11GB GDDR5X Videokártya!
- Bomba ár! HP EliteBook 830 G5 - i5-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest