Webalkalmazások biztonsági hibái - 3. Hibakezelés

Betörési tesztjeink során gyakran találkozunk azzal a jelenséggel, hogy a weboldalak fejlesztői ugyanazokat a hibákat követik el újra és újra. Ezen klasszikus hibákat egy több részből álló sorozatban szeretnénk bemutatni.

A hibakezelés gyakran elhanyagolt terület webalkalmazások fejlesztése során: a fejlesztők sokszor nem foglalkoznak vele, az üzemeltetők pedig egészen egyszerűen, egy könnyed vállrándítással a fejlesztőkhöz dobják vissza a problémát, mondván, hogy nekik kellene megfelelően megírt kódot kommitálni. Nagyon veszélyes a fenti hozzáállás, ugyanis a támadót számtalan módon segíthetik a hibakezelés hiányosságai. Lássunk néhány tipikus példát.

A hibakezelés kihagyása az alkalmazásból. Naiv, nem kellőképp biztonságtudatos fejlesztési folyamat egyenes következményei az olyan alkalmazások, ahol nem várt helyen, nem várt formátumú felhasználói inputok (vagy akár a legitim használattal előhozható bugok) eredményeként igencsak bőbeszédű hibaüzenetek jelennek meg. Milyen típusú hibaüzenetekkel találkozhatunk?

• A webalkalmazás saját debug üzenetei. Sok esetben előfordul az, hogy az üzembe állítási határidők miatt a webfejlesztők "ott felejtik" azokat a kódokat, amelyek a hibák detektálását, javítását megkönnyítik. Tipikusan ilyen eset az, amikor az oldal forrásában html kommentben debug üzenetek, TODO címkék olvashatóak, néhány (tesztelési szempontból) szerencsés esetben még fel is hívják a figyelmet az alkalmazás nem befejezett funkcióira. Egyik auditunk során találtunk egy nem kellőképpen validált input paramétert, amely segítségével blind SQL injection támadást tudtunk indítani. A támadással kinyerhető a teljes adatbázistartalom - elég hosszú idő alatt, de "szerencsére" a fejlesztő gondoskodott arról, hogy az AJAX-os hívás során lefutó PHP állomány közvetlenül meghíva kidumpolja az adatbázisquery eredményét, így két-három nagyságrenddel lerövidült a támadás időtartama.
• A háttérben futó adatbázis-kezelő rendszer hibaüzenetei. A leghálásabb forrása a hibaüzeneteknek, ugyanis az adatbázis-kezelő rendszerek többnyire meglehetősen bőbeszédű hibaüzenetekkel segítik az alkalmazások fejlesztőit: ODBC alapú kapcsolódásnál a teljes hibás query kidumpolását is tapasztaltuk már. Ez amiatt roppant hálás, ugyanis a támadó egyrészt felmérheti, hogy milyen input validációs kontrollokon mennek keresztül a felhasználói inputok és hol kötnek ki végül az adatbázis-kezelő által feldolgozott queryben (ezáltal eldöntheti, hogy milyen módon tud kitörni az SQL query programozó szabta keretei közül), másrészt megkönnyíti az adatbázistáblák feltérképezését. A legtöbb esetben nem ilyen szerencsés a tesztelő, de kellő mértékben adva teljesen értelmetlen inputokat (azaz magyar kifejezéssel élve fuzzolva az alkalmazást), a legtöbb adatbázis-kezelőből ki lehet facsarni valamilyen hibaüzenetet. A hibaüzenet többnyire pedig hibát, sebezhetőséget enged megsejteni: a leggyakoribb esetben a hibaüzenet ismeretében ki lehet következtetni valami módot, amivel SQL injectionnel sebezzük az alkalmazást.
  
• A PHP/ASP .net/JSP/stb. motor hibaüzenetei. Elsősorban az oldal felépítésének, az alkalmazás architektúrájának felderítésében hasznosak: amikor valamilyen szkriptfeldolgozó motor hibára fut, valamilyen rövid hibaüzenetben jeleníti meg a hiba okát, többnyire a hibát okozó forrás adott sorának megjelölésével. Ez segíti a támadót abban, hogy leszűkítse a támadás fókuszát, hibás/sebezhető pontokat keressen az alkalmazásban. Tesztelés során azt a stratégiát követjük, hogy hibaüzenet esetén más típusú inputot adva ellenőrizzük, hogy nagyjából azonos kódrészletben történik a hiba (a sorok számozása jó támpont erre), vagy különböző komponensekben. A hibaüzenetek jó kiindulási pontot adnak arra is, hogy megállapítsuk a háttérben futó szolgáltatás (pl. portálmotor) szállítóját.
• Exceptionök. Bár szorosan kapcsolódnak a motor hibaüzeneteihez, mégis fontosságuk miatt érdemes külön kezelni a kivételeket. Az exceptionök olyan, strukturált hibaüzenetek, amelyek rendszerint több részből állnak: ha eljutnak a felhasználóhoz, bőbeszédű stacktrace-t adnak vissza, amelyből pontosan megállapítható az elhasaló függvény hívási lánca, megállapítható, hogy milyen külső java-s/.net-es csomagokat használnak a fejlesztők, továbbá sok esetben információt árulnak el magáról a kódról, illetve a környezetről (pl. .net framework verziószáma)
  
• A webszerver hibaüzenetei. A webszerver hibaüzenetei gyakran elárulják, hogy milyen típusú/verziójú az adott webszerver, PHP motor, adatbázis-kezelő stb., emellett (főleg a régi verziójú webszerverek) XSS-sel is sebezhetőek: például a http://www.portal.hu/<script>alert("XSS")</script>.html cím esetén visszajövő hibaüzenet sokszor feldobja az árulkodó alert ablakot. A webszerverek hibaüzeneteivel *NIX rendszereken gyakran enumerálhatóak a felhasználók olyan módon, hogy a http://1.2.4.5/~felhasználónév kérések kiadására létező felhasználóra 200-as, illetve 403-as üzenettel, nem létezőre pedig 404-essel válaszolnak.
  
• A webalkalmazás köré épített architektúra hibaüzenetei. Sok esetben előfordul, hogy nem egy (fizikai v. logikai) webszerveren fut a tesztelt webalkalmazás, hanem valamilyen egyéb eszközön keresztül érünk el hozzá: proxy szerverek, load balancerek gyakran érzékelhetőek azzal, ha érvénytelen HTTP-kérést küldünk a webalkalmazásnak, és például egy Squid által generált hibaüzenet jelenik meg.

A fenti példákból érzékelhető, hogy a hibaüzenetek információval szolgálnak az oldal felépítéséről, architektúrájáról, a háttérrendszerekről. Sőt: időzített bombaként működhetnek, ugyanis sok keresőmotor megtalálja és rögzíti a hibákat, ezekkel pedig specifikus verziójú alkalmazások, speciális típusú hibák kereshetőek nagyon egyszerűen.