ugrás a tartalomhoz

PHP login rendszer

Hacker1990 · 2008. Aug. 14. (Cs), 20.37
Szép napot kívánok mindenkinek.Egy login rendszer fejlesztésén töröm a fejem mar napok óta.Nem is volna nehéz,ha session-t használnák.A kérdés az.hogyan oldható meg a login session nélkül biztonságosan.
Megoldható ez valahogy?Tudna nekem segiteni valaki?Köszönöm mindenki segitségét
‹ google maps marker mozgatása fájlból vett koordináta alapján Kommentrendszer ›
 ■
1

Szevasz Istvan!

Protezis · 2008. Aug. 14. (Cs), 22.07
Ez ugyanaz a projekt, mint ahol cookie kezelest kell megvalositanod javascriptben anelkul, hogy leirnad a cookie szot?! :D

Komolyra foditva a szot: ha cookie-ban elkuldod mindig a felhasznalo nevet, jelszot (vagy barmit, amivel egyertelmuen azonosithatod a felhasznalot), akkor megoldhato. Megkerdezhetem, miert nem hasznalhatsz sessiont?
2

minek újból?

Szekeres Gergő · 2008. Aug. 14. (Cs), 23.03
ha cookie-ban elkuldod mindig a felhasznalo nevet, jelszot (vagy barmit, amivel egyertelmuen azonosithatod a felhasznalot),


akkor létrehozok az adott domainre egy új cookiet, benn egy felhasználónévvel, és már be is vagyok lépve.. Nyilván meg lehet csinálni, generálsz egy hosszú stringet, ami mint egy sessionid végigkiséri a felhasználó, az egyéb munkamenetváltozókat meg mondjuk DB-ben tárolod, de ebben az esetben meg kell oldanod az id egyediségét. Ez gyakorlatilag egy saját munkamenet-kezelés. Inkbb a fő kérdés, hogy minek is ezzel vesződni?
3

???

Protezis · 2008. Aug. 15. (P), 07.32
akkor létrehozok az adott domainre egy új cookiet, benn egy felhasználónévvel, és már be is vagyok lépve
- ezt mondtam en is
4

nem biztos

McWatt · 2008. Aug. 15. (P), 23.31
Ha két külön adatot tárolsz el, mondjuk júzernév és randomszám, és e kettő mellett az adatbázisban tárolod a felhasználó jogait, akkor nem olyan könnyű megtörni. Mondjuk én sem értem, hogy miért nem jó a session.
5

miert nem akarok sessiont

Hacker1990 · 2008. Aug. 17. (V), 12.33
Lehet hogy maradok megis a sessionnal,de az azert nem jo,mert ha nem tevedek,akkor a juzernak engedelyeznie kell a sütiket.Ha pedig nincs engedelyezve,akkor nem tud belepni.Ha pedig nem tud,akkor a felhasznalok egy részét kizárom.
En ugy gondoltam,hogy MySQL tabla logged_in_users, oszlopok:user_name, user_id(20 karakteres random), belepes_datum,
Csak azt nem tudom,hogy ezeket az adatokat,oldalrol oldalra hogy vigyem át.
6

Nem úgy van hogy...

Ustak · 2008. Aug. 17. (V), 13.03
session mindenképpen tárolódik (vagy a szerveroldalon, ha nincs süti vagy a kliensoldalon ha van?)
Lehet hogy rosszul tudom ,de mintha hozzáillesztené a "query string" hez automatikusan a php, ha a sütiket kikapcsolta a böngésző aki böngészik épp.
7

nem feltétlenül

Hodicska Gergely · 2008. Aug. 17. (V), 13.06
Itt olvashatsz a munkamenet kezelésről: http://weblabor.hu/cikkek/munkamenetkezeles1, http://weblabor.hu/cikkek/munkamenetkezeles2. Ebben láthatod majd, hogy a PHP magától megoldja neked, hogy kikapcsolt COOKIE esetén bizonyos HTML tagekbe beírja a session azonosítót. Amire figyelned kel ilyenkor, hogy header átirányítás esetén ez nem történik meg, ezért az átirányítást végző függvényedben (egy ilyet mindig érdemes használni) ezt kezelni kell, ha ilyen irányban mész el...

...viszont ez nem igazán ajánlott manapság. Biztonság szempontjából sem a legjobb, ha a userek egy linkkel együtt küldik a session azonosítójukat. Ha megnézed ma már teljesen bevett szokás, hogy akinek ki van kapcsolva COOKIE, az így járt, ne akarjon belépkedni. Google stb., sehol nem tudsz kikapcsolt cookieval bejelentkezni.


Üdv,
Felhő
10

na meg a js..

Szekeres Gergő · 2008. Aug. 17. (V), 13.58
az ajax kérésekhez sem csapja hozzá a sessionidt, bár gondolom ha cookie nem lehet, akkor a javascript eleve kilőve.. :)
9

pont fordítva

Pal_ur · 2008. Aug. 17. (V), 13.29
A session van a szerveren, ehhez a felhasználónak semmi köze. A süti (cookie) van a felhasználó gépén, ezt kell engedélyeznie. Legalábbis alapból, a részleteket meg majd elmondják mások :)
8

Cookie nélkül

vbence · 2008. Aug. 17. (V), 13.13
Használhatsz még standard HTTP azonosítást is, bár ez is kicsit ingoványos terep, plusz nem is a legesleg biztonságosabb, de működik cookie nélkül is. (Mindezek mellett én is a cookie-s megoldásra szavazok).

http://hu.php.net/features.http-auth
11

Köszönet mindenkinek

Hacker1990 · 2008. Aug. 18. (H), 10.24
Mindenkinek köszönom a hozzászólását.Úgy döntöttem,hogy a login rendszert mégis cookie-val fogom megoldani.Ez tűnik nekem a legegyszerűbb megoldásnak.A biztonság az oldalnál szerintem nem mérvadó,mert egy fotómegosztó oldalról lenne szó.Esetleg beiktatnák egy ellenőrzést,hogy a cookie engedélyezve van-e.Ha nincs megjelenne a hibaüzenet.
12

Biztonság

Max Logan · 2008. Aug. 18. (H), 11.25
[...]A biztonság az oldalnál szerintem nem mérvadó,mert [...]

Csak halkan jegyezném meg, hogy amit kiteszel netre ott igenis fontos a biztonság, legyen szó bármilyen kicsi, egyszerű, bonyolúlt, összetett honlapról, rendszerről ...
13

Végül is....

Hacker1990 · 2008. Aug. 18. (H), 19.06
Végül is igazad van.De,egy bank weboldalának erősebb biztonsági rendszer kell,mint egy fotómegosztó oldalnak.
14

Ha a funkcionalitást nézzük ...

Max Logan · 2008. Aug. 18. (H), 19.58
... akkor igen, de ha azt vesszük, hogy egy nem feltétlenül fontos fotómegosztón keresztül törnek fel, lassítanak le, tesznek használhatatlanná egy szervert, akkor már mindjárt más a leányzó fekvése.

Egy megosztott tárhelyen lehet pl. egy cég webáruháza a te oldaladdal együtt, ami ha – a te biztonsági résektől hemzsegő kódod miatt – nem lesz elérhető csak 1 órára, az adott cégnek jelentős anyagi veszteséget jelenthet a te hibádból – itt most nem térek ki arra, hogy az említett webáruházat illik prémium tárhelyre rakni.

Tehát azért fontos többek között a normális (biztonságos) kód írása, mert nem csak te "laksz" egy tárhelyeket kiszolgáló szerveren.
15

Tenyleg ugyelni kell erre?!

Protezis · 2008. Aug. 18. (H), 20.25
Javitsatok ki ha tevedek, de szerintem ha felnyomnak egy oldalt, es azon keresztul kart tudnak tenni a kurrens szerveren levo tobbi oldalban, akkor ez bizony a szerver uzemeltetoit minositi.
16

Nem egyértelmű a dolog

Max Logan · 2008. Aug. 18. (H), 21.14
A biztonság elég tág fogalom WEB-es környezetben, az említett példa elég szélsőséges, és nem is konkrét fizikai károkozásra gondoltam, hanem például túlterhelés, ez által pedig a szerveren lévő tartalom ki nem szolgálása, ami az említett webáruház esetében adott ügyfélnek komolyan fájhat (jól menő webáruház esetén néhány órás kiesés, jelentős veszteséget jelenthet).

Velem például megtörtént, hogy az egyik "szomszédos" user beállításai hazavágták a .htaccess beállításaimat. Ezt orvosolta a rendszergazda, amikor jeleztem a gondot, de ettől még az oldalam elérhetetlen volt x ideig (amit magam sem tudok pontosan, hogy mennyi volt).

És igen, igazad van a szerver üzemeltetőket illetően, ezért is írtam, hogy business critical cuccot érdemes megfelelő környezetbe helyezni, de ettől függetlenül jó ha az ember MINŐSÉGI kódot ad ki a kezéből.

Hasonlattal élve, ha egy kis sámlit csinál az asztalos, akkor az legyen olyan minőségű, mint a konyhabútor, mert 30 cm-ről is lehet fájdalmas balesetet szenvedni (ez pedig ha jól sejtem, akkor pl. gondatlan veszélyeztetés kategória is lehetne, persze most erősen túlzok, de ugye nagyobb léptékben már érthető, hogy hova akarok kilyukadni – törekedjünk a minőségre kicsiben is, ezzel kialakul egyfajta szakmai igényesség, még akkor is ha csak hobbiból dolgozik az ember).
17

Szakmai igenyesseg

Protezis · 2008. Aug. 18. (H), 21.40
Ertem amit mondani akarsz. De minosegi es biztonsagos kodot - en legalabbis - azert irok, hogy az en oldalamnak jo legyen, a tobbie nem erdekel. Ha egy masik ugyfel miatt nem megy x ideig a webaruhazam, a rendszergazdat fogom felelossegre vonni, mert neki fizetek ( illetve a cegenek ).
19

Így van

janoszen · 2008. Aug. 18. (H), 21.41
Valóban, ez fog bekövetkezni, attól függetlenül, hogy Téged meg a szolgáltató az incidens után valszeg ki fog rakni.
20

Hm?

Protezis · 2008. Aug. 18. (H), 21.50
Enyem az aruhaz, masik ugyfel lerohasztotta a szervert, felelossegre vonom a ceget, es engem raknak ki?!
23

Nem így

janoszen · 2008. Aug. 19. (K), 10.44
Nem így értettem. Te lerohasztod a szervert, másik ügyfél bepereli a szolgáltatót, szolgáltató téged rak ki. Így értettem.
18

Is

janoszen · 2008. Aug. 18. (H), 21.40
Valóban, egy osztott tárhelyet üzemeltető cégnek illene ilyesmire figyelni, de ettől függetlenül pl a PHP-ban is lehetnek olyan rések, amiket a Te biztonsági lukaidon keresztül ki tud aknázni. Ha pl az én szerveremen megjelennél insecure kódokkal, akkor valszeg a néhány századik log-megabájt után megkérnélek, hogy talán keress magadnak másik hostot. Az más kérdés, hogy én nem vagyok publikus hosting-cég, de sztem ha veszélyt jelentesz a szerverre, akkor sec perc alatt kilakoltatnak.
21

Biztonság,avagy,hogyan írjunk biztonságos szkripteket

Hacker1990 · 2008. Aug. 19. (K), 10.00
Lassan már átlehetne nevezni ezt a temát arra,hogy: "Biztonság,avagy,hogyan írjunk biztonságos szkripteket".
22

Én szívesn olvasnék ilyen topicot...

Ustak · 2008. Aug. 19. (K), 10.13
ha van valami a témában (php, security, stb), ami egy összefoglaló cikk szerű dolog és érdemesnek tartjátok, linkeljétek már be légyszi, lehet idegen nyelven is (angol :-))
Köszi!
24

Security

janoszen · 2008. Aug. 19. (K), 10.47
Sajnos az a tévhit, hogy a security egy cikkből vagy összefoglaló leírásból megtanulható még mindig tartja magát. A security úgy fog megszületni, hogy a fejlesztő megérti és átlátja atechnológia működését, pl a HTTP protokollt és rájön, hogy a felhasználóktól kapott adatok manipulálhatóak és azokban a változókban bármi lehet, majd megérti hogy ezzel akár bármilyen SQL parancsot is kiadhat és védekezik ez ellen.