Így varázsolsz biztonsági rést ASP.NET-ben

Az ASP.NET WebForms egyik óriási előnye, hogy villámgyorsan lehet vele adatelérési kódot varázsolni. Példaként vegyük a Northwind adatbázist, és legyen az a feladat, hogy csak az amerikai beszállítókat kell megjelenítenünk.

Dobjunk a Default.aspx-re egy GridView vezérlőt, majd állítsuk be szépen a Configure Data Source varázslóban, hogy a Suppliers táblából adja vissza… (kattints a teljes méretű képért)

PK-in-URL-1

… az USA-hoz tartozó beszállítókat:

PK-in-URL-2

Pofozzunk még annyit a GridView beállításain, hogy dobjuk le a SupplierID és a CompanyName oszlopokat, majd az utóbbit tegyük vissza, ám ezúttal HyperLinkField formájában. A link vezessen a (még nem létező) View.aspx oldalra, és query string paraméterben adjuk át neki a beszállító azonosítóját:

PK-in-URL-3

Készen is vagyunk, bátran ki lehet próbálni, íme az amerikai beszállítók listája:

PK-in-URL-4

Készítsük el a View.aspx oldalt, amire dobjunk egy DetailsView vezérlőt. Indítsuk el a Configure Data Source varázslót és kérjük le a Supplier rekord összes oszlopát…

PK-in-URL-5

…de csak abból a rekordból, amire a query stringben hivatkozunk, hiszen így kapcsoljuk össze a két oldalt:

PK-in-URL-6

Kitt és katt (Next és Finish) és máris készen van a működő oldalunk, amin a kiválasztott beszállító összes adatát át tudjuk tekinteni:

PK-in-URL-7

Működik? Igen, kiválóan lehet vele böngészni az USA-beli beszállítókat. Hurrá!

Hány sor kódot írtunk? Egyet sem, mert mindet a varázslók írták meg nekünk. Hurrá!

Van benne biztonsági rés? Van bizony! Elég átírni az URL végén lévő számot 2-ről mondjuk 4-re és máris hozzáférünk egy japán beszállító adataihoz, miközben nekünk csak az USA-ban lévőket szabadna látnunk:

PK-in-URL-8

Sőt, ha 1-től szép sorban minden számot kipróbálunk, akkor pillanatok alatt letölthetjük magunknak az összes beszállító adatait, azaz elvihetjük a teljes beszállítói kapcsolat adatbázist, az pedig már érték! Hurrá?

Ez történhet, ha az ember vakon megbízik egy varázslóban, vagy vakon követi valamelyik “hú-de-egyszerű-ez” demó lépéseit.

Most persze mondhatod, hogy a profik ilyet nem csinálnak. Pedig de, mondok is rögtön két példát.

Pár évvel ez előtt 114.000 iPad tulajdonos személyes adatait vitték el pillanatok alatt úgy, hogy egy URL-ben egyszerűen végigpróbálták a lehetséges eszköz azonosítókat (ICC ID – integrated circuit card identifier). Mindössze egy fél képernyőnyi szkript kellett hozzá és így került a címlapokra:

PK-in-URL-9

A biztonságcentrikus fejlesztéssel foglalkozók pedig így reagáltak rá:

PK-in-URL-facepalm-1

Ugyanezt a hibát később egy bank is elkövette. A Citibanktól – igen, egy banktól! – 200.000 ügyfél személyes-, folyószámla- és bankkártya adatait vitték el pont ugyanígy: csak átírták az ügyfél azonosítót az URL-ben. Erre aztán már nem csak a biztonsági szakemberek reagáltak így:

PK-in-URL-facepalm-2

Két rövid tanulság a fentiekből:

  • Ne tégy kitalálható azonosítót az URL-be!
  • Az eltitkolt URL nem védelem!

A varázslók a produktivitásban segítenek, de nem gondolkodnak. Egy biztonságtudatosan gondolkodó és a biztonságos programozás gyakorlatát követő fejlesztő bár valószínűleg lassabban kódol, hosszabb távon mégis kifizetődőbb.

 

Technorati-címkék: ,,,

14 thoughts on “Így varázsolsz biztonsági rést ASP.NET-ben

  1. jankajanos

    Ue. kell figyelni web api fejlesztéskor is. Én implmentáltam ehhez egy saját ACL megosztási mechanizmust a Google API-k mintájára, ahol minden ki van osztva, hogy melyik erőforráshoz kinek és milyen jogosultságai vannak. Az én agyamba ez volt az első gondolat amikor neki kezdtem web api-t fejleszteni.🙂 A Web API demo példák is ott véreznek, hogy szimplán az Authorize attribútumot használják az akciókra, holott nemcsak azt kell védeni, hogy valaki be van jelentkezve, hanem azt is, hogy milyen erőforráshoz fér hozzá és azon milyen műveletet szeretne végrehajtani. A Facebook üzenőfala is jó példa erre, ahol minden egyes üzenethez úgyszint tartozhat több Access Control entry (ACE), azaz ACL.

  2. LC

    Ez nem varázslófüggő dolog, kb. a weben található, kézzel összerakott PHP-s oldalak jó részénél is eljátszhatod. És az esetek nagy részében nem is probléma. Ahol az, ott kezelni kell, akár az ID elkódolásával, akár hogy nem querystringként adod át a paramétert.

  3. apr

    “Ne tégy kitalálható azonosítót az URL-be!
    Az eltitkolt URL nem védelem!”

    Igaz, de mivel visszafejthető, van értelme “eltitkolni”?

    Lehet, hogy maradi vagyok, de az elmúlt tíz évben nulla azaz nulla darab varázslót sikerült web fejlesztés során elindítanom🙂

  4. Zsolti

    Baromság!

    Az erőforrás id-je ne legyen kitalálható? Gratulálok!

    Ha az erőforrás id-je 1, akkor az URL-ben …/Jarmu/Details/1, ha szerkeszteni akarja, akkor az URL-ben ../Jarmu/Edit/1, és így tovább.

    Ha pl. Józsival ki akarom javíttatni a skoda alvázszámát, akkor küldök neki egy URL-t. Oszt mindenkü boldog!

    Ez így kényelmes? Egen.
    Ez így biztonségos? Egen. (elkódoltam az I-betűt, nehogy kitaláld mit írtam; ügyes vagyok?)

    Akkor miről beszélsz? Az, hogy mitől biztonságos, hogy Józsinak megy az id URL-ben, találd ki; házi feladat…

      1. Zsolti

        Itt mindenki modoroskodik vagy hízeleg; jó nekem, hogy nem kell köröket futnom.

  5. Fekete György

    Az első hozzászólónak van igaza, a cikkíró kamuzik. Az, hogy elkódoljuk, az csak megnehezíti az adatok ellopását, de nem csökkenti 0-ra a kockázatot(bármilyen bonyolult, próbálkozással össze lehet hozni legalább pár rekordot, béna kódolás meg hamis biztonságérzetet ad!). Minden műveletre jogosultságkezelés. Az 0-ra csökkenti az adatlopás technikai esélyét.

  6. Balássy György Szerző

    A cikkíró nem kamuzik, ez a cikk a hibáról szól és nem a megoldásról. A nem kitalálható ID jelentősen megnehezíti a támadó dolgát, ezért célszerű alkalmazni, nem azért, mert tökéletes. Az igazi megoldás valóban az erőforrás védelme. Az SSL ezen a problémán nem segít.

    1. Zsolti

      Ja, az a biztonság nálad, hogy nem átlépi a kerítést, hanem át kell neki másznia rajta.
      Még mindig csak gratulálni tudok.

      A fizetős tanfolyamon is ilyen kerítésmászós anyagot fogtok letolni?

      1. Balássy György Szerző

        Nem figyeltél. “Az igazi megoldás valóban az erőforrás védelme.”

        Apropó kerítésmászás: pont erről szólt a mai Hacktivity keynote csak épp mobil témakörben.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s