hogyan viselkedni csapkod unsecure web application

ebben a cikkben szeretném bemutatni, milyen egyszerű ez, hogy bizalmas információkat egy webes alkalmazás, amely… nos, nem fordít túl nagy figyelmet a biztonságra. Amivel dolgozni fogok, az Egy minta Java alkalmazás, amelyet a Spring Boot-ban hoztam létre demonstrációs célokra. De az elvégzett támadások bármely más programozási nyelvre vagy keretrendszerre érvényesek. Néhány biztonsági rés és biztonsági probléma, amelyet bizonyítani fognak, a következők:

• SQL Injection
• érzékeny adatok expozíciója
• elégtelen naplózás
• hibás hitelesítés

a Beállítás

egy kitalált webes alkalmazással fogunk dolgozni, amely lehetővé teszi, hogy felhasználóként jelentkezzen be, amely valamilyen csoport része. A felhasználói szerep alapján megtekintheti az alapvető vagy bizalmas adatokat. Ebben az esetben megjelenik a vállalat alkalmazottainak listája, státuszuk stb.

az alkalmazás forrásait a Github-ban találhatja meg: https://github.com/rapasoft/hackme.

támadás #1: Man in the middle attack

képzelje el, hogy egy étteremben ül, és szeretne ellenőrizni valamit a fenti alkalmazásban. Csatlakozik az étterem Wi-Fi-jéhez, megnyitja a bejelentkezési oldalt, megadja a hitelesítő adatokat, és megkapja a kívánt információkat (például az adott alkalmazottak listáját). Amit talán most nem, az az, hogy a hitelesítő adatai veszélybe kerültek. Vizsgáljuk meg alaposan a bejelentkezési oldalt:

ez az alkalmazás nem használ SSL/TLS-t (pl. nincs https:// kapcsolat). Ez azt jelenti, hogy minden elküldött információt egyszerű szövegnek tekinthet bárki, aki hozzáfér a kliens és a szerver közötti kommunikációhoz.

pontosan ez történik az úgynevezett ember a középső támadásban. Pontosabban, ebben az esetben az ARP-hamisítást arra használták, hogy megmérgezzék az egész hálózatot, hogy a támadó tisztában legyen mindennel, ami megy, és minden csomagot szimatolhat. Nem fogok részletekbe menni arról, hogyan működik az ARP spoofing, de ezt a videót bemutatja:

lehet, hogy meg kell nyitnia ezt a Youtube-videót egy új ablakban és teljes képernyőn a További részletek megtekintéséhez

a fentiekben látható, hogy elindítottam az Ettercap-ot, amely egy átfogó csomag a MITM támadásokhoz, és ARP-hamisítást hajtottam végre a helyi hálózaton. Időközben, amikor a felhasználó (me iPad-en keresztül) beírja a hitelesítő adatokat, azok mind az Ettercap-ban, mind a Wireshark-ban (hálózati forgalomelemző eszköz) láthatók.

2. támadás: SQL Injection

folytatva az alkalmazás támadó szerepét, most már rendelkezünk a hgraves felhasználó hitelesítő adataival P4SSW0RD jelszóval. Láthatjuk, hogy nem csak ez az alkalmazás nem használja a TLS, hogy van egy nagyon gyenge jelszó politika, amely lehetővé teszi a felhasználók úgy döntött, nagyon szörnyű jelszavakat.

a fenti hitelesítő adatokkal jelentkezünk be,és egy beviteli mezőt láthatunk az emberek listájának keresésére. Ha megnyomja a Search gombot, megkapjuk az emberek teljes listáját. Ha például “Fra” – t teszünk, akkor a keresés alapján szűrt eredményeket kapunk. Mi lenne, ha valami illegális figurát tennénk oda? Nyilvánvaló, hogy van valami adatbázis az alkalmazás mögött, ezért próbáljuk ki a ' karaktert:

nem csak ez nem sikerült, de láthatjuk, hogy POST kérés nem sikerült nagyon konkrét hibaüzenet, hogy ki a szerkezet egész SQL utasítást. Láthatjuk, hogy a végén WHERE P.NAME LIKE '%'%' használatos.

képzett hacker nem kell több. A keresési karakterlánc beállítása néhány kísérlet után eredményezheti ezeket az eredményeket:

az injekció ebben az esetben létrehozott union to select utasítás, amely letölti felhasználónevek és jelszavak együtt szerepüket. Nem csak ez volt sikeres, sikerült megjeleníteni az eredeti kliens alkalmazásban.

most már minden felhasználó hitelesítő adatait és szerepkörét (az “életkor” oszlopban az egész szám jelenik meg). Ha a hframe – nek 1.szerepe van, akkor a rgraves – nek fontosabb felhasználónak kell lennie a 3. szereppel.

támadás #3: Támadó gyengén hashed jelszavak

megtanultuk az első támadás, hogy valószínűleg nincs jelszó házirend ehhez az alkalmazáshoz. Ez reményt adna nekünk, hogy rgraves nem fordít túl sok figyelmet a biztonságra sem.

a legegyszerűbb módja annak, hogy feltörje a jelszó hash-ját, amely elégtelen hash algoritmust használ (mint például az MD5 ebben az esetben), a szótár vagy a rainbow table támadás végrehajtása. Sok lehetőség van, de a legegyszerűbb az olyan internetes szolgáltatások használata, amelyek már rendelkeznek nagy adatbázissal A jelszó-hash kombinációkról:

az első hframe, a második rgraves. smorgan úgy tűnik, hogy erősebb jelszavakat használ, mint mások, mivel nem szerepel a szótárban.

láthatja, hogy a rgraves jelszava kardhal, ami azt jelenti, hogy most nem tudja, mennyire fontos a nem szótári jelszó kiválasztása ;). Most semmi sem akadályozza meg minket abban, hogy bejelentkezzünk, mint ez a felhasználó, és felfedezzük az “admin” részt és a bizalmas információkat:

ne olvassa el ezt, ha német vagy:)

hogyan lehet ezt kijavítani?

azt mondhatnánk, hogy mindez könnyen megelőzhető. Mondhatni, hogy ezek újonc hibák voltak. Nos, ez igaz lehet, de az is igaz, hogy az Open Web Application Security Project a webes alkalmazások #1 sebezhetőségét sorolja fel (és ez már évek óta így van).

tehát, ha azon töprengett, hogy vajon hogyan lehet mindezt megakadályozni, összefoglaljuk:

• mindig használjon SSL/TLS-t, amikor valamit küld a szerverre. Nem kell, hogy hitelesítő adatok legyenek, jelenleg általában jó gyakorlatnak tekintik. Még akkor is, ha egyáltalán nincs bemenete az oldalán! A legegyszerűbb módszer a tanúsítvány biztosítása olyan szolgáltatásokon keresztül, mint a Let ‘ s Encrypt.
• ne feledje, hogy az önaláírt tanúsítványok enyhíthetik az adatexpozíció problémáját, de ne akadályozza meg az MITM támadóját abban, hogy az egész webhelyet hamisítsa a saját önaláírt tanúsítványával.
• az SQL lekérdezések kezelése során mindig elkerülje az ügyféltől kapott paramétereket. Ennek legegyszerűbb módja a keretrendszer képességeinek használata, pl. tavasszal használhatja a NamedParameterJdbcTemplate-t, amely jó az olvashatóság szempontjából is.
• legyen paranoiás. Minden felhasználói bemenet érvényesítése. A Java / Spring világban ismét hozzáadhatsz validációs Szabályokat a JSR-380 bean validation implementációval, mint a Hibernate validator és az annotate paraméterekkel, pl. @Pattern(regexp = "*") String namemegakadályozná a ' beírását.
• jelentkezzen be minden olyan kísérletet, hogy adja át érvénytelen bemenet az alkalmazásban. Ezenkívül hiba esetén ne tegyen ki semmilyen implementáció-specifikus információt az ügyfélnek.
• javítsa a hitelesítést.
  • ha lehetséges, használjon legalább 2 faktoros hitelesítést.
  • ne hajtson végre egyedi jelszótár-vagy titkosítási algoritmusokat. Nagyon nehéz egyedül csinálni, és biztosan kudarcot vall. Vannak olyan bevált megoldások, mint a BCrypt.
• olvassa el és könyvjelző OWASP TOP 10. Kezdje ott, majd nézze át a legjobb gyakorlatok listáját.