Řešil už někdo hashování/šifrování parametrů GET v url?
- worsik
- Člen | 40
Ahoj, hledám jednoduchou funkčnost.
Chtěl bych všechny parametry v URL, např.
„&action=neco&presenter=necojineho&id=3“ zašifrovat do
nějakého tvaru, který teprve uvedu v URL, aby nebylo čitelné a bylo tam
třeba jen „&hash=G4Gcd5%O6GE56UMNG32SW7K?P“. Ideálně s pevnou
délkou.
Důležité je ale to, aby se to dalo rozšifrovat a přitom aby aplikace
fungovala, jako by URL zašifrovaná nebyla.
Máte na to nějaký nápad?
Jde hlavně o to, ať mi někdo ručně nemění např. id
- Blizzy
- Člen | 149
Takovéto praktiky se nazývají Security through obscurity. Jsi si jistý, že tohle je postup, který potřebuješ? Nebylo by lepší například konkrétnímu uživateli zakázat přístup k určitým id? Zkus uvést konkrétní použití v aplikaci, možná to není správné řešení.
Každopádně možností máš například následující:
- použít hashování a někde (v databázi) mít uložené páry hash → celá URL
- použít nějakou šifru, kde nepotřebuješ mít tyto páry uložené a stačí ti klíč pro dešifrování
Tyto techniky můžeš uplatnit třeba ve:
- speciální routě (resp. routeru)
- presenteru, který po dekódování požadavku může přesměrovat na jiný presenter
Editoval Blizzy (6. 8. 2010 12:24)
- worsik
- Člen | 40
Důvod, proč hledám takovéto řešení je, že chci, aby uživatel striktně používal navigaci ve stránce, odkazy, tlačítka apod a vůbec nemohl hrabat do URL stránky. Nechci aby mi někdo testoval různé změny URL :o)
Edit: Přístup k nevhodným id mám zabezpečený, neexistující stránka je ErrorPresenterem zachycena a přesměrována. Používám několik parametrů, o nichž v podstatě ani nechci, aby uživatel věděl, že existují.
Editoval worsik (6. 8. 2010 12:31)
- Blizzy
- Člen | 149
Proč nechceš, aby ti někdo testoval různé změny URL? Bojíš se, že by se dostal tam, kam nemá?
Správným řešením jsou routy, můžeš si je navrhnout třeba tak, že na každou stránku povede pouze jedna adresa. Můžeš schovat informace, které nechceš, aby uživatel viděl. Například samotný web Nette frameworku je napsaný v Nette a routy používá, a nikdo se nebojí, že by tam někdo testoval nějaké změny.
Dalším argumentem je SEO, obecně se má za to, že vyhledávače hodnotí stránky lépe, pokud se klíčová slova vyskytují v URL.
Také běžný uživatel má radši normální hezké adresy, a to hlavně pokud je musí opisovat z papíru (např. zdroje v nějaké publikaci, reklamní leták nebo další tiskoviny).
Editoval Blizzy (6. 8. 2010 14:33)
- Panda
- Člen | 569
Při kódování jen parametru ID je možné použít filtry
pro routování (Route::FILTER_IN,
Route::FILTER_OUT), není vůbec potřeba dělat nějaké změny
v presenterech, modelech, nebo nedejbože v databázi.
Jinak víceméně souhlasím s ostatními, dobře napsaná aplikace takovou dodatečnou ochranu vůbec nepotřebuje.
- nemesisqo
- Člen | 2
chcel by som sa opytat, troska som sa hral s prikladom ktory name kedze som zacal s nete pred nieco viac nez mesiacom a flastne urobil som to zobral som nete pridal som tam navigacny bar kde odkazuje napr na TodoList ten ktory je uvedeny ako priklad na prve vytvorenie app no a potom som pridal login aby nemohol len tak niekto mazat a pridavat tie ulohy v pohlade som nastavil aby ak nieje prohlaseny tak nezobrazil stransku s TodoListom ale napisal ze nech sa uzivatel prihlasi ale ak napr zadate do url :
www/homepage/show/117?do=delete
tak ten prvom maze i ked vypise ze prihlaste sa, ako to zabezpecit aby sa nieco take nestalo aby som nemohol do url napisat a tak je to asi tym ze ta app nieje dobre napisana ako bolo napisane ved je to len priklad ale nieake riesenie alebo odporucania? Vopred dakujem za akukolvek pomoc
Editoval nemesisqo (1. 4. 2011 11:45)
- Šaman
- Člen | 2635
nemesisqo napsal(a):
www/homepage/show/117?do=delete
tak ten prvom maze i ked vypise ze prihlaste sa, ako to zabezpecit aby sa nieco take nestalo aby som nemohol do url napisat a tak je to asi tym ze ta app nieje dobre napisana ako bolo napisane ved je to len priklad ale nieake riesenie alebo odporucania? Vopred dakujem za akukolvek pomoc
Nastuduj si ACL (nový tutorial) a na
začátku actionDelete() proveď kontrolu oprávnění. Lze to
kontrolovat i dynamicky (třeba že můžeš mazat vlastní články,ale
ne cizí).
Dokud jsem používal model založený na active recordu, tak jsem práva u každé CRUD metody kontroloval znovu a to pak bylo celkem neprůstřelné (práva se kontrolovala v modelu i když jsem je zapomněl explicitně zkontrolovat v presenteru).
Editoval Šaman (1. 4. 2011 13:26)
- ic
- Člen | 430
nemesisqo napsal(a):
dakujem za help skusim sa nato pozriet. Je tam este ina alternativa toto je najlepsia?
Lepší neznám, pokud budou v adrese nějaké hashe pořád jde adresa (na nešifrovaném spojení) sledovat po cestě, a taky se ukládá v historii prohlížeče, kde to může kdokoliv prošmejdit.
- Jan Tvrdík
- Nette guru | 2595
Šaman wrote:
Dokud jsem používal model založený na active recordu, tak jsem práva u každé CRUD metody kontroloval znovu a to pak bylo celkem neprůstřelné.
Pokud tam není ochrana před CSRF, tak to má do neprůstřelnosti daleko.
- Šaman
- Člen | 2635
Jan Tvrdík napsal(a):
Pokud tam není ochrana před CSRF, tak to má do neprůstřelnosti daleko.
No dobře, pravdu díš. Ta neprůstřelnost je nadnesená – šlo o to,
že se zkontrolují práva už na úrovni modelu a nezabezpečený
handleDelete() tak nebyla bezpečnostní Macocha.
Jinak už od nemesisqova dotazu uhýbáme od tématu, takže případnou další diskuzi doporučuji směrovat do nového vlákna.