Kysymys:
Pitäisikö minun käyttää AntiForgeryTokenia kaikissa muodoissa, jopa sisäänkirjautumisen ja rekisteröinnin yhteydessä?
Artiom Chilaru
2011-02-12 03:08:46 UTC
view on stackexchange narkive permalink

Minulla on melko suuri sivusto, jolla on tuhansia vierailuja päivässä, ja melko suuri käyttäjäkunta. Siitä lähtien kun aloitin siirtymisen MVC 3: een, olen laittanut AntiForgeryTokenin useisiin lomakkeisiin, jotka muuttavat suojattuja tietoja jne.

Jotkut muut lomakkeet, kuten sisäänkirjautuminen ja rekisteröinti, käyttävät myös AntiForgeryTokenia nyt, mutta Minusta tulee aluksi epäilevä heidän tarpeestaan ​​siellä, parista syystä ...

Kirjautumislomake edellyttää, että julistaja tietää oikeat tunnistetiedot. En todellakaan voi ajatella mitään tapaa, jolla CSRF-hyökkäys hyötyisi tässä, varsinkin jos tarkistan, että pyyntö tuli samalta isännältä (tarkista Referer-otsikko).

AntiForgeryToken-tunniste luo erilaisia ​​arvoja joka kerta sivu ladataan. Jos minulla on kaksi välilehteä kirjautumissivun kanssa ja yritän sitten lähettää ne, ensimmäinen latautuu onnistuneesti. Toinen epäonnistuu AntiForgeryTokenExceptionin avulla (lataa ensin molemmat sivut ja yritä sitten lähettää ne). Turvallisemmilla sivuilla - tämä on tietysti välttämätön paha, sisäänkirjautumissivuilla - tuntuu ylimitoitukselta ja vain ongelmien pyytämiseltä.

On olemassa muita syitä, miksi tunnusta tulisi käyttää tai olla käyttämättä yhdessä. lomakkeet. Olenko oikeassa olettaessani, että tunnuksen käyttö jokaisessa postilomakkeessa on ylimitoitettua, ja jos on - minkälaiset lomakkeet hyötyvät siitä ja mitkä ehdottomasti eivät hyödytä?

PS Tämä kysymys kysytään myös StackOverflow'sta, mutta en ole täysin vakuuttunut. Ajattelin kysyä sitä täältä, jotta saat lisää turvallisuus kattavuutta

Onko tähän kysymykseen päivitetty? Mitä tulee siihen, että useita samanaikaisia ​​kirjautumissivuja lähetetään? Nykyinen ratkaisuni on poistaa väärennöstunnus kirjautumissivulta.
En usko, että sen pitäisi enää olla ongelma .. Minulla on väärennösten estotunnus kirjautumissivullamme, eikä se ole enää ongelma.
Olen myös varmistanut, että web.config -laitteellani on määritetty kone-avain, joka poisti useita asioita, jotka minulla oli alun perin
Kaksi vastused:
#1
+73
D.W.
2011-02-12 08:32:14 UTC
view on stackexchange narkive permalink

Kyllä, on tärkeää sisällyttää väärentämisen estävät tunnukset kirjautumissivuille.

Miksi? "CSRF-sisäänkirjautumishyökkäysten" mahdollisuuden vuoksi. Sisäänkirjautumisessa CSRF-hyökkäyksessä hyökkääjä kirjaa uhri kohdesivustoon hyökkääjän tilillä. Harkitse esimerkiksi pahaa hyökkääjää Evelynin hyökkäystä Aliceen, joka on Paypalin käyttäjä. Jos Paypal ei suojannut kirjautumissivujaan CSRF-hyökkäyksiltä (esim. Väärentämisen estävällä tunnuksella), hyökkääjä voi hiljaa kirjautua Alice-selaimen Evelynin tilille Paypalissa. Alice viedään Paypalin verkkosivustolle, ja Alice on kirjautunut sisään, mutta kirjautunut sisään nimellä Evelyn. Oletetaan, että Alice linkittää sitten luottokorttinsa Paypal-tiliin napsauttamalla sivua ja syöttää luottokorttinumeron. Alice luulee yhdistävän luottokorttinsa Paypal-tililleen, mutta itse asiassa hän on linkittänyt sen Evelynin tiliin. Nyt Evelyn voi ostaa tavaraa ja laskuttaa sen Alicen luottokortilta. Oho. Tämä on hienovarainen ja vähän hämärä, mutta riittävän vakava, että sinun tulisi sisällyttää väärentämisen estävät merkit kirjautumista varten käytetylle lomaketoimintakohteelle. Katso lisätietoja ja joitain tosielämän esimerkkejä tästä tästä paperista. haavoittuvuudet.

Milloin väärentämisen estävän tunnuksen jättäminen on OK? Yleensä, jos kohde on URL-osoite ja että sillä ei ole sivuvaikutuksia, sinun ei tarvitse sisällyttää väärentämisen estävää tunnusta kyseiseen URL-osoitteeseen.

Karkea nyrkkisääntö on: sisällytä väärentämisen estävä tunnus kaikkiin POST-pyyntöihin, mutta et tarvitse sitä GET-pyyntöihin. Tämä karkea nyrkkisääntö on kuitenkin hyvin karkea arvio. Siinä oletetaan, että kaikki GET-pyynnöt ovat sivuvaikutuksettomia. Hyvin suunnitellussa verkkosovelluksessa sen pitäisi toivottavasti olla, mutta käytännössä joskus verkkosovellusten suunnittelijat eivät noudata tätä ohjetta ja toteuttavat GET-käsittelijöitä, joilla on sivuvaikutus (tämä on huono idea, mutta se ei ole harvinaista) . Siksi ehdotan ohjetta sen perusteella, onko pyynnöllä sivuvaikutus verkkosovelluksen tilaan vai ei, sen sijaan, että se perustuisi GET vs POST -ohjelmaan.

Ymmärrän .. Oletan, että tällä on järkeä. Ainoa asia, josta olen huolissani, on saada käyttäjät ärsyttämään sitä, että jos heillä on kaksi lomaketta auki samanaikaisesti, ja yritä sitten lähettää ne - yksi niistä todennäköisesti epäonnistuu vahvistuksessa :(
+1, niice. CSRF-kierre istunnon kiinnityksessä ... Myös hieno paperi, btw.
Eikö ole mitään ratkaisua virheeseen, joka syntyy, kun käyttäjä kirjautuu sisään kahdesta välilehdestä?
CSRF-tunnusta käyttävä @AntonAnsgar, ei tarkoita, että virheen täytyy olla, kun käyttäjä kirjautuu sisään kahdesta välilehdestä. Jos saat tällaisen virheen, käytä parempaa CSRF-tunnuksen toteutusta.
Kiitos. Käyttäjä avaa kirjautumissivun kahdella välilehdellä. Kirjautuu sisään toisesta, menee toiseen ja yrittää kirjautua uudelleen, sovellus heittää poikkeuksen. "System.Web.Mvc.HttpAntiForgeryException: Annettu väärennösten estotunnus oli tarkoitettu käyttäjälle" ", mutta nykyinen käyttäjä on kirjautunut sisää[email protected]" Tämä on asp.net mvc 4: ssä. Käytän [ValidateAntiForgeryToken]
Olenko oikeassa ajatellessani tätä asetusta - AntiForgeryConfig.SuppressIdentityHeuristicChecks = true kuten tässä viestissä mainitaan http://stackoverflow.com/questions/14970102/anti-forgery-token-is-meant-for-user-but-the-current-user-is-username jättäisivätkö sinut todella avoimeksi evelyn-tyyliin kohdistuvalle hyökkäykselle?
@ChrisNevill, En tiedä - kuulostaa siltä kuin sinun pitäisi kysyä siitä erillinen kysymys.
Voisiko joku selittää, mitä tämä lause tarkoittaa?"Milloin väärentämisen estävän tunnuksen jättäminen on OK? Jos kohde on URL-osoite ja jos URL-osoitteen käyttämisellä ei ole sivuvaikutuksia, sinun ei tarvitse sisällyttää väärentämisen estävää tunnusta kyseiseen URL-osoitteeseen"
@Ned, ehkä voisit kysyä uuden kysymyksen käyttämällä oikeassa yläkulmassa olevaa Kysy kysymys -painiketta?Voit linkittää tähän viestiin kontekstin.Ehdotan, että kuvailette mitä osia ymmärrät ja mistä olet hämmentynyt, ja auta meitä ymmärtämään nykyinen ymmärtämyksesi ja miksi tämä tuntuu sinulle epäselvältä kysymyksessäsi.
Kiitos, että selitit oikean suunnan, @D.W.Olen luonut uuden viestin: https://security.stackexchange.com/questions/204041/when-is-it-okay-not-to-use-anti-forgery-token-in-login-page
#2
+2
Steve
2011-02-12 07:59:25 UTC
view on stackexchange narkive permalink

Tunnuksen saaminen sisäänkirjautumissivulle voi olla välttämätöntä, kun sinun on estettävä joku kirjautumasta sinua vahingossa tietyillä tunnuksilla. Näen, että näin on, jos joku on kehitetty jostakin, mikä edellyttää kirjautumista partlar-käyttäjän kanssa. Tämän sanottuaan, se on vähän keksitty esimerkki.

Ei niin keksitty ... Katso @D.W: n vastaus.


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 2.0-lisenssistä, jolla sitä jaetaan.
Loading...