Webalkalmazás-biztonság a gyakorlatban

A webalkalmazás a szervezet leginkább kitett része: az internetről bárki eléri, és minden funkciója potenciális belépési pont. Az OWASP Top 10 ennek a területnek a prioritási listája, de a lista önmagában absztrakt. Ez a cikk arra fókuszál, mi jelenik meg belőle a valós tesztekben.

1. Törött jogosultság-kezelés

Ez az egyértelműen leggyakoribb és legsúlyosabb kategória. A tipikus eset: az alkalmazás ellenőrzi, hogy a felhasználó be van-e jelentkezve, de nem ellenőrzi, hogy az adott erőforráshoz van-e joga.

A /szamla/1234 URL-ben átírja a számot 1235-re, és megjelenik valaki más számlája. Ez percek alatt megtalálható, és a legtöbb tesztben előfordul.

Amit tenni kell: minden kérésnél szerveroldalon ellenőrizni, hogy az azonosított felhasználónak van-e joga az adott objektumhoz. A kliensoldali ellenőrzés nem ellenőrzés.

2. Injektálás

A támadó adatnak álcázott parancsot juttat egy értelmezőbe. Klasszikusan SQL, de ugyanez létezik parancsértelmezőnél, LDAP-nál és sablonmotoroknál.

Amit tenni kell: paraméterezett lekérdezés. Nem a bemenet szűrése, mert azt mindig meg lehet kerülni, hanem az, hogy az adat sose kerüljön az utasítás pozíciójába.

3. Hitelesítési hibák

Gyenge jelszó-házirend, hiányzó fiókzárolás, kiszámítható munkamenet-azonosító, a munkamenet nem szűnik meg kijelentkezéskor.

Amit tenni kell: MFA, biztonságos munkamenet-kezelés (véletlen azonosító, HttpOnly és Secure süti, észszerű lejárat), és a jelszó-visszaállítás folyamatának átgondolása, mert az gyakran gyengébb, mint maga a bejelentkezés.

4. Biztonsági félrekonfigurálás

Alapértelmezett hitelesítő adatok, részletes hibaüzenet éles környezetben, nyitva hagyott adminisztrációs felület, könyvtárlistázás, elavult komponens.

Amit tenni kell: dokumentált alapkonfiguráció és annak automatizált ellenőrzése. A hibaüzenet éles környezetben soha ne tartalmazzon veremkiírást vagy adatbázis-információt.

5. Sérülékeny komponensek

A modern alkalmazások túlnyomó része harmadik féltől származó kódból áll. Egy ismert sérülékenységű könyvtár ugyanolyan kockázat, mintha saját kódban lenne a hiba.

Amit tenni kell: függőség-nyilvántartás és automatizált vizsgálat. Erről a szoftverfüggőségekről szóló cikkünkben írtunk.

6. XSS

A támadó szkriptet juttat az oldalba, ami a látogató böngészőjében fut le. Ezzel munkamenet-süti lopható, vagy művelet hajtható végre a felhasználó nevében.

Amit tenni kell: kontextus-függő kimenet-kódolás, HttpOnly süti, és Content Security Policy, ami korlátozza, honnan futhat szkript.

Amit egy szkenner nem talál meg

Üzleti logikai hibák. Negatív mennyiség a kosárban, kupon többszöri felhasználása, munkafolyamat lépéseinek kihagyása. Ezekhez érteni kell, mit csinál az alkalmazás.

Jogosultsági láncok. Egy alacsony jogú felhasználó eléri egy másik szerepkör funkcióját.

Versenyhelyzetek. Két párhuzamos kérés olyan állapotot hoz létre, ami egyébként lehetetlen.

Ezért a szkennelés és a penetrációs teszt nem helyettesíti egymást.

Mit javítson először

1. Jogosultsági ellenőrzés minden erőforrás-hozzáférésnél, szerveroldalon
2. Paraméterezett lekérdezés mindenhol, ahol adat kerül lekérdezésbe
3. MFA a bejelentkezésre és a jelszó-visszaállításra
4. Függőségek naprakészen tartása automatizált vizsgálattal
5. Biztonsági fejlécek: CSP, HSTS, X-Content-Type-Options

Ez az öt lépés a valós tesztekben talált hibák túlnyomó részét lefedi. A tesztelésről a penetrációs tesztelés oldalunkon írtunk.