Autor | Zpráva | ||
---|---|---|---|
Magnus123 Profil |
#1 · Zasláno: 17. 11. 2011, 18:03:27
Zdravím.
Chtěl bych se zeptat, k čemu je dobré u přihlášeného uživatele používat ochranný hash, který se předává přes URL? A pokud možno ještě jeden malý dotaz. Mohu mít u objektů mezi proměnnou, operátorem a vlastností mezeru? Tzn. zápis $promenna -> neco? Děkuji všem za pomoc. |
||
Kcko Profil |
#2 · Zasláno: 17. 11. 2011, 19:16:12
add 1) Není třeba, existují SESSIONS
add 2) ano a můžeš si to příště zkusit sám |
||
Magnus123 Profil |
#3 · Zasláno: 17. 11. 2011, 19:21:36
2) Já to zkoušel, spíš mi šlo o to, jestli je možnost, že by to někdy/e udělalo nějakou chybu, protože bych ji nejspíš velmi těžko hledal.
Každopádně děkuji za reakci. :-) |
||
DarkMeni Profil |
#4 · Zasláno: 17. 11. 2011, 21:48:39
Magnus123:
„k čemu je dobré u přihlášeného uživatele používat ochranný hash“ Teď nevim jestli myslíš to co já ale taky mě to zajímá, snad tomu ale řikali token nebo tak nějak než hash. Na hodně portálech v administraci vidim že je v adrese nějakej řetězec co nedává smysl a vypadá jako náhodně vygenerovanej dlouhej řetězec nebo md5 hash něčeho, ale k čemu je to dobrý? Prej je to kvůli vyšší bezpečnosti že uživatel který je v administraci je opravdu admin, takže nestačí že je při kontrole přihlášení do proměnné nebo konstanty s levlem hodnota admina nebo vyšší? |
||
okolojdouci Profil * |
#5 · Zasláno: 17. 11. 2011, 21:55:04
DarkMeni:
„Prej je to kvůli vyšší bezpečnosti“ Spíš je to známka toho, že je něco špatně nebo přinejmenším je to nadbytečné. Hash v adrese má smysl třeba při ověření registrace nebo při jednorázově vygenerované adrese určené pro jeden konkrétní download souboru apod. Veřejně zobrazovaný hash neznamená žádné zvýšení bezpečnosti, naopak může v určitých případech signalizovat její zanedbání. |
||
juriad Profil |
#6 · Zasláno: 17. 11. 2011, 22:26:55
Existuje jeden případ, kdy je tento způsob (výměna tokenů) velice vhodný, totiž pro detekci změn několika uživateli zároveň. Typický příklad je Bugzilla; několik lidí může upravovat stav jednoho bugu.
Uživatel A i B mají zobrazený formulář pro změnu položky v databázi. Uživatel A změní položku. Uživatel B změní položku na formuláři, který je toho času neplatný. (Neví, že došlo k změně položky a součet změn může být nekonzistentní.) K vyřešení tohoto je možné zavést v databázi sloupec verze, ve kterém je uložené nejčastěji číslo verze nebo datum poslední změny. Aby si server nemusel pamatovat, jakou verzi klient naposledy stáhnul, bude po klientovi vyžadovat nějaký doklad o verzi, kterou upravuje. Změna se provede, jen pokud si verze odpovídají. Větší bezpečí se zajistí tím, že místo plain-textové verze se odešle její otisk (hash) a případný útočník nemůže podvrhnout novější formulář. Případnou alternativou může být zamykání jak záznamů na úrovni databáze, nebo uchovávání informací o zobrazených formulářích v session. |
||
Časová prodleva: 13 let
|
0