Alkalmazások biztonsága. Szoftverek sérülékenységéből származó kockázatok csökkentése. Flashcards
Sebezhetőség
Egy jól védett, megfelelően menedzselt hálózat: hálózati-, host alapú betörés detektáló, tűzfalak, melyek beengedik általában a HTTP és a HTTPS forgalmat sebezhető pont, ha nincs alkalmazás szintű védelem. Az alkalmazás rétegre jellemző, hogy nincsenek betörés megelőző mintázatok, amikkel lehetne hatékonyan detektálni, jelezni és nincsenek javító szoftverek sem. Előfordulnak házilag készített alkalmazások is.
Drasztikusan növekednek a web alkalmazások elleni támadások. a hagyományos támadások a hálózati rétegből, az operációs rendszer rétegből indultak, ezért itt építették ki a védelmet először, annyira megnehezítették a hackerek dolgát, hogy inkább máshol (a kisebb ellenállás irányában) próbálkoznak, ami ma az alkalmazás réteg.
Open Web Application Security több gyártót összefoglaló nyitott fejlesztési rendszer, a web alapú biztonsági rendszereket vizsgálják és optimalizálják.
Pl.: 2007 TK Maxx Amerikában, Kanadában, Angliában és Írországban lévő boltok. Feltörték a rendszerüket és észre sem vették. 46 millió hitelkártya adatot loptak el. Nem tudták, hogy mihez jutottak és hogy a felhasználókra ez milyen hatással lehet.
Hibás fejlesztői szemlélet: a webalkalmazásunk működik, azt csinálja amit kell, azonosítót is tud adni. Van autentikáció is. Úgy gondolják, hogy megfelelően biztonságos. Ez a baj!
Alapvető hibák
- hibakezelés hiánya: nem létező oldalra való hivatkozás.
- Sérülékenység felhasználható arra is, hogy a támadó állományokat töltsön el a webszerverről. A hiba üzenetek által sok információ kiderülhet, pl.: OS típusa, rendszerpartíciók száma.
- A hibaoldalnak a szeveget URL paraméterként adtuk át. Ha ez nem megfelelően van kezelve akkor lehetőséget nyújt arra, hogy a támadó pl.: JavaScriptet futtasson a szerveren. Kerüljük az ilyen hibaoldalak használatát, inkább, ha a támadó olyan paramétert ad meg, ami nem létező oldalra hivatkozik, a bemutatkozó oldalt kapja.
- A bejelentkezési hibaüzenet: a támadó kipróbálja a legegyszerűbb felhasználónevet, a jelszó mind1 csak ne legyen üres. Megoldás: a felhasználónevet és a jelszót külön-külön ellenőrizzük, ne egy lekérdezésben az adminisztrátor ne az első bejegyzés legyen a felhasználókat tartalmazó táblában. Tiltsuk le az SQL Injection-höz leggyakrabban használt karaktereket (pl.: - ’ =) a bevitel során
- Nem megfelelően védett oldalak: URL begépelésével megkerülhető a bejelentkezési oldal, elérhető a védett oldalak. Egyszerűen megoldható, ha feltételhez kötjük a védett oldal betöltését.
A hackernek ismernie kell a rendszert. Behatolás előtt minél többet meg kell tudnia a célba vett rendszerről. Információ szerezhető: internetes keresőkből, DNS szerverekből. Megszerezhető információ: OR, annak verziója, alkalmazások és típusai… stb
Szoftver sérülékenység
Programozási hiba, amiket a hackerek kihasználnak. Nem végleges állapotba kerül a vevőhöz a szoftver, a fejlesztők patcheket és upgrade csomagokat biztosít a kiadás után.
Támadási formák
- Cross-Site-Scripting
- Információszivárgás
- SQL Injection
- Beviteli korlátozások megkerülése
- Puffer túlcsordulás
- Váratlan kód kombináció
- Szolgáltatás megbénítása – Denial of Service (DoS)
Cross-Site-Scripting
Idegen parancsok végrehajtása. A kliens olyan java script kódot tartalmazó weblapot tölt fel, ami káros. A felhasználónak meghamisított tartalmat adnak át, mely a sebezhető webhely URL-jébe v. űrlapmezőibe szúrt utasítások hatására áll elő.
Információszivárgás
Az OS-k egyre nagyobb szabadságot engednek az új technológiát képviselő adathordozók és komm. eszközök használatában. Otthoni számítógépeknél nagyon hasznos és kényelmes, de pl. egy hivatal esetében már nagy kockázatot jelent. A plug-and-play támogatást kihasználva kontrollálatlan módon csatlakoztathatóak a vállalati számítógépekhez digitális fényképezőgépek, kéziszámítógépek, pen drive-ok , stb., de „célirányos felhasználással” kitűnő eszközök is lehetnek a többnyire csak jelszavas védelem észrevétlen kijátszására. Megoldás: az eszközök és csatlakozási pontok központi felügyelete, engedélyhez kötött használata, a felhasználások, felhasználási kísérletek nyomon követése.
SQL Injection
Az alkalmazások leggyakrabban SQL-lel kapcsolódnak az adatbázisokhoz. Segítségével lehet adat rekordokat feltölteni, törölni, módosítani, stb. A fejlesztők nem nagyon foglalkoznak a bemeneti paraméterek ellenőrzésével. Amit a felhasználó megad, azokat vakon átadják az SQL API-nak. Védelem: felhasználói bevitel ellenőrzése szerver oldalon. Ne jelenítsünk meg adatbázis hibakódokat a kliensnek.
2005: CardSystem (tranzakció processzálást végeztek) rendszerét feltörték. A rendszer egyik webes alkalmazásának paraméterében át tudtak adni egy JavaScriptet, ami a web alkalmazás mögött futó adatbázisra rá tudott települni, időzítve lefutott, kiszedte a kb. 260 ezer hitelkártya adatait, összetömörítette és kirakta egy ftp oldalra.
Beviteli korlátozások megkerülése
A felhasználó által adott paraméterek ellenőrzését a web fejlesztő a kliens böngészőjére bízza, vagy egyáltalán nem foglalkozik az ellenőrzésével Inkább csak a helyes értékek feldolgozására fordítják az erőforrásaikat, kevésbé foglalkoznak azzal, hogy a helytelen értékek hogyan lesznek lekezelve. Védekezés: Nem lehet bízni a kliens oldali ellenőrzésben. Érdemes már a fejlesztőknek tisztában lenni a kódolási algoritmusokkal.
Puffer túlcsordulás
Puffer: adatok bevitelére és küldésére használt ideiglenes tárolás céljából lefoglalt memória blokk, mérete előre meghatározott.
Túlcsordulás: amikor megpróbálunk (és sikerül) a puffer méreténél nagyobb adatot beírni a pufferbe. Ilyenkor a puffer utáni memória területre is írunk adatokat (azt nem lehet tudni, hogy milyen adatokat írunk át). A hacker elérheti, hogy az alkalmazás összeomoljon, vagy pedig lefuttathat egy program kódot, mellyel hozzáférést nyerhet a rendszerhez.
Váratlan kód kombináció
Egy program számára, egy ártatlannak tűnő parancs kiadásával befolyásolhatunk más programokat.
Szolgáltatás megbénítása
A cél, hogy egy számítógépes rendszert, hálózatot, v. szolgáltatást elérhetetlenné, üzemképtelenné tegyenek, úgy hogy azt túlterhelik. A támadás jöhet egy v. akár egyszerre több számítógépről. Egyetlen számítógépről indított támadást szolgáltatás megtagadásos támadásnak (DoS) nevezzük. Több számítógépről indított támadást elosztott szolgáltatás megtagadásos támadásnak (dDoS) nevezzük.
Elosztott szolgáltatásmegtagadásos támadás esetében több számítógép indít valamilyen DoS támadást egyszerre egy célgép ellen. Emiatt a dDoS támadások sokkal hatásosabbak és veszélyesebbek. A legtöbb esetben a támadó számítógépek tulajdonosai nem tudják, hogy a gépüket támadásra használják. A támadást indító program a tudtuk nélkül lett telepítve a számítógépükre, ami szintén behatolásnak számít. Sőt, a számítógépen tárolt adatokat (fájlokat) is meg szokták a hackerek változtatni.
DDoS támadások elleni lehetséges biztonsági intézkedések
- SYN sütik használata a SYN árasztás ellen. Egy kapcsolat sorszámmal ellátott SYN csomagot küld válaszként a SYN csomagra, hogy meggyőződjön a kapcsolatkiépítés tényleges szándékáról. Addig nem készítjük el a kapcsolatot, és nem foglalunk le memóriát, amíg meg nem győződtünk a kapcsolatkiépítés tényleges szándékáról.
- RST sütik használata a SYN árasztás ellen (nem annyira elterjedt, mint az előző). Az RST csomag egy hibás SYN/ACK csomag.
- Tiltsuk le az irányított adatszórást a hálózatban minden egyes gépen.
- Figyeljük a hálózat sávszélességét.
- Figyeljük az átlagos csomagméreteket a hálózaton.
- Korlátozzuk a szerver számára kevésbé szükséges protokollok (pl. ICMP) használatát, sávszélességét.
Büntetés a magyar törvények szerint: DoS támadás egy betörésnek feleltethető meg. Illetéktelen adatmódosítás lopásnak, hamisításnak és vandalizmust jelent.
Scriptek futtatása weboldalon keresztül
Rosszindulatú kód lefuttatása. Ez előfordulhat akkor ha a webszerver nem ellenőrzi a bekért adatokat. Elküldi a böngészőnek, aki elindítja a rossz indulatú scriptet. Akár emailben kiküldheti a felhasználó jelszó párost.
Lehetséges biztonsági intézkedések a scriptek futtatása ellen böngésző esetén
- Böngésző:
o A böngészőnek ne engedélyezzük a scriptek automatikus lefuttatását.
o Ha a script futtatása szükséges a (megbízhatónak tartott) weboldal használatához, csak a honlapról kiindulva engedélyezzük azt.
o Ellenőrizzük a hivatkozások tartalmát és forrását mielőtt arra kattintanánk.
o A státuszsor a legtöbb böngészőn megváltoztatható. HTML forráskód szinten lehet csak biztosra menni a hivatkozás tartalmáról.
Lehetséges biztonsági intézkedések a scriptek futtatása ellen webszerver esetén
- Webszerver:
o Minimális adatbekéréssel korlátozzuk a böngészőnek visszaküldött adatokat.
o Legyen a lekért adatoknak egy felső korlátja, és ellenőrizzük a korlát betartását.
o Töröljük a , <object>, és <embed></embed> beágyazott elemeket, ha nem szükségesek.
o Ellenőrizzük a sütik tartalmát, mielőtt elküldjük a böngészőnek.
o Használjunk viszonyazonosítást, amit minden látogató csak egyetlen lapról (pl. a honlapról) kaphat, tehetjük az URL-be v. egy sütibe. Érvénytelen viszonyazonosító esetén, küldjük a látogatót a honlapra. Hátránya, hogy a weblap mélyebb szintjeire nem lehet hivatkozni.
o A weboldalon egy meghatározott kódolást használjunk (pl. ISO-8859-1), hogy egyértelműek legyenek a speciális karakterek.
o Szűrjük ki a speciális karaktereket a böngésző által szolgáltatott adatokból.
o Hivatkozásokat csak bizonyos forrásoktól engedélyezzünk, és ellenőrizzük a hivatkozó mező tartalmát a HTTP fejlécben.
o Szűrjük ki a speciális karaktereket a böngészőnek küldött adatokból. A bejövő és kimenő adatok formátuma különbözhet. Tehát lehetséges, hogy a bejövő adatoknál egyes speciális karakterekre szükség van, míg azok elküldésére viszont semmi szükség nincs.</object>
