Ennek egyik módja az lenne, ha titkosítaná a paramétert, amikor a szerveren tárolt kulccsal továbbítja a felhasználónak (a jobb védelem érdekében fontolja meg egy HMAC hozzáadását is). Majd amikor a felhasználó elküldi az űrlapot, dekódolja a paramétert (és ellenőrizze a HMAC-ot, ha van ilyen), és használja a felhasználó átirányítására.

Láttam olyan eseteket, amikor az URL-t csak elhomályosították (base64-es kódolás stb.) . Ez elriaszthatja az alkalmi támadókat, de nem bíznék benne, mivel egy elszánt támadó valószínűleg kidolgozza a használt rendszert.

Hozzáadhatja webhelye előtagját az URL-hez, hogy azok a következő helyre kerüljenek:

example.com/login.php?returnurl=profiles/home.php

És a azt szeretné, ha visszatérne a http://example.com/ webhelyre, és hozzáadná a visszatérő URL-t. (http://example.com/RETURNURLHERE)

Számos mód van a felhasználók / böngészők megtámadására, az URL-ek elfedésére / átirányításra. Őrült módszer, hogy fájni fog az agyad, és megkérdezed, miért működik ez ?! (lásd: http://code.google.com/p/browsersec/) Általánosságban elmondható, hogy a bemenet érvényesítésekor ne próbálja meg kijavítani az adatokat, ha azok nem olyanok, mint amire számítottál, vagy nem a kívánt formátumot, dobja el. Ne feledje az alapértelmezett tagadást, ez csak egy példa erre.

Mint bármi, ennek megvalósítása is az Ön igényeitől függ. Az átirányítások kezelésével is tisztában kell lennie a végrehajtási hibákkal, amelyek további sérülékenységeket is fel tudnak nyitni, például a HTTP válasz felosztása, a fejléc beinjekciózása stb.

Általában a rendeltetési hely engedélyezőlistájához és aláírás kérése (HMAC használatával, hasonlóan Rory javaslatához). A kérelem aláírásának előformálása során szeretném láthatóvá tenni a célállomást az URI-ban. Például:

http://yoursite.com/login.php?returnurl=welcome.php&hash=yourlonghashhere

Ez lehetővé teszi a felhasználó számára, hogy csekély életképesség arra, hogy hová kell eljutnia a kérésnek, és lehetővé teszi az ügyesebb felhasználók számára, hogy esetleg maguk is észrevegyék az adathalászatot vagy más támadást.

Amikor átirányítás készül:

1. Ellenőrizze a 'returnurl' kivonatát a kivonattal
2. Ellenőrizze, hogy a 'returnurl' engedélyezőlistára került-e
3. Ezután formázza előre az átirányítást.

Ha az ellenőrzési folyamat bármelyik lépése sikertelen, vagy irányítson át egy alapértelmezett / kezdőlapra, vagy utasítsa el a kérést.

Íme néhány további forrás:

• http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your- site-being.html
• https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
• http://cwe.mitre.org/data/definitions/601.html

1. Távolítson el minden felesleges információt az URL-ből (pl. http: // , a webhely neve stb.). Ha több lehetősége van (pl. Öt webhely), használja az indexüket.
2. Számoljon ki egy maradvány kivonatot egy szerveroldali titkos só használatával, és tegye előre (vagy annak egy részét - annál rövidebb, annál nagyobb a sikeres ütközési támadás veszélye a returnUrl
3. A returnUrl fogadásakor ellenőrizze, hogy a hash érvényes-e. Ha nem, akkor utasítsa el.
4. Adja vissza az összes hiányzó információt és irányítsa át.

Emellett egyes átirányítások egy általános mintát követhetnek, ahol csak néhány paramétert kell csatlakoztatnia. Ebben az esetben nem is kell a kivonat.

Például:

  returnUrl = http helyett: //www.myfifthsite.com/common/webpage/profile ? user = lserni  

felforralhatja az

returnUrl=5-5-lserni

ötödik webhelyet , 5. engedélyezett átirányítási minta, ennek a mintának csak egy paramétere van, és értéke a felhasználónév:

sites: ... 5 => ' http://www.myfifthsite.com '...

az 5. számú minták (természetesen a hitelesítést nem felülírják!): 5 =>' / common / webpage / profile? user = $ 1 '6 => '/ common / webpage / messages? user = $ 1'

A támadó felsorolhatja az összes megengedett webhely- és mintaszámot, de csak érvényes URL-eket kap az Ön által engedélyezett webhelyekről.

Tehát bizonyos értelemben így semmit sem kell ellenőriznie. Az URL-ek mindig automatikusan érvényesek lesznek (még akkor is, ha egyesek még mindig hitelesítési sütiket igényelnek)