How to hack unsecure web application

I denne artikkelen vil jeg gjerne vise hvor enkelt det er å få konfidensiell informasjon fra en web-applikasjon som… vi vil, betaler ikke for mye oppmerksomhet til sikkerhet. Det jeg skal jobbe med er et Eksempel På Java-program som jeg opprettet I Spring Boot for demonstrasjonsformål. Men angrepene som utføres er gyldige for andre programmeringsspråk eller rammeverk. Noen sårbarheter og sikkerhetsproblemer som vil bli demonstrert inkluderer:

• SQL Injection
• sensitiv dataeksponering
• Utilstrekkelig logging
• Ødelagt autentisering

oppsettet

vi vil jobbe med en fiktiv webapplikasjon som lar deg logge inn som bruker som er en del av en gruppe. Basert på brukerrolle kan han se enten grunnleggende eller konfidensielle data. I dette tilfellet vil du se en liste over ansatte i et selskap, deres status, etc.

du kan finne kildene til dette programmet i Min Github: https://github.com/rapasoft/hackme.

Angrep #1: Man in the middle attack

Tenk deg at du sitter i en restaurant og vil gjerne sjekke noe i søknaden ovenfor. Du kobler til restaurantens Wi-Fi, åpner påloggingssiden, skriver inn legitimasjon og henter informasjon du vil ha(f. eks. listen over bestemte ansatte). Det du kanskje ikke nå, er at legitimasjonene dine har blitt kompromittert. La oss undersøke påloggingssiden nøye:

dette programmet bruker IKKE SSL / TLS (f. eks no https:// tilkobling). Dette betyr at all informasjon som sendes, kan ses som ren tekst av alle som har tilgang til kommunikasjon mellom klienten og serveren.

dette er akkurat det som skjer i såkalt Man in the middle attack. MER spesifikt, I DETTE tilfellet HAR ARP-spoofing blitt brukt som en måte å forgifte hele nettverket på, slik at angriperen er klar over alt som skjer og kan snuse på alle pakker. Jeg kommer ikke til å gå inn i detaljer om HVORDAN ARP spoofing fungerer, men vil demonstrere det på denne videoen:

Du må kanskje åpne Denne Youtube-videoen i et nytt vindu og fullskjerm for å se flere detaljer

det du kan se ovenfor er at Jeg har startet Ettercap, som er en omfattende pakke FOR MITM-angrep, og utført ARP-spoofing i mitt lokale nettverk. I mellomtiden, når brukeren (meg via iPad) går inn i legitimasjonene, er de synlige både I Ettercap og I Wireshark (verktøy for nettverkstrafikkanalyse).

Angrep # 2: SQL Injection

Fortsetter vår rolle som angriper av dette programmet, har vi nå legitimasjon for brukeren hgravesmed passord P4SSW0RD. Du kan se at ikke bare dette programmet ikke bruker TLS, det har en veldig svak passordpolitikk som gjør at brukerne valgte virkelig forferdelige passord.

vi logger inn ved hjelp av legitimasjonene ovenfor og kan se ett inntastingsfelt med mulighet for å søke etter liste over personer. Når du trykker Search vil vi få hele listen over personer. Hvis vi setter «Fra» for eksempel vil vi få filtrerte resultater basert på søk. Hva om vi setter det noen ulovlig karakter? Det er åpenbart at det er noen database bak dette programmet, så la oss prøve ' tegnet:

ikke bare mislyktes dette, men vi kan se at POST forespørsel har mislyktes med svært spesifikk feilmelding som avslører strukturen i hele SQL-setningen. Vi kan se at WHERE P.NAME LIKE '%'%' brukes på slutten.

Dyktig hacker trenger ikke mer. Justering av søkestrengen kan etter få forsøk gi disse resultatene:

injeksjonen i dette tilfellet opprettet union for å velge setning som henter brukernavn og passord sammen med deres rolle. Ikke bare dette var vellykket, vi har klart å vise den i den opprinnelige klientprogrammet.

Vi har nå legitimasjon for alle brukere, og deres roller (vises av heltallet i kolonnen «Alder»). Hvis hframe har rolle 1, må rgraves derfor være viktigere bruker med rolle 3.

Angrep # 3: Attacking svakt hashed passord

vi har lært i det første angrepet, at det sannsynligvis ikke er noen passordpolicy satt for denne applikasjonen. Dette vil gi oss håp om at rgraves ikke betaler for mye oppmerksomhet på sikkerhet heller.

den enkleste måten å knekke hash av passord som bruker utilstrekkelig hashing algoritme (SOM MD5 i dette tilfellet) er å utføre ordbok eller rainbow table attack. Det er mange muligheter, men det enkleste er å bruke internett-tjenester som allerede har stor database med passord-til-hash-kombinasjoner:

Den første er hframe, den andre er rgraves. smorgan ser ut til å bruke sterkere passord enn andre, siden det ikke er i ordboken.

du kan se at passordet for rgraves er sverdfisk, noe som betyr at han ikke nå hvor viktig det er å velge ikke-ordbok passord ;). Nå stopper ingenting oss fra å logge inn som denne brukeren og oppdage» admin » – delen og konfidensiell informasjon:

Ikke les dette hvis du er tysk 🙂

hvordan fikse dette?

du kan si at alt dette lett kunne forhindres. Du kan si at dette var rookie feil. Vel, dette kan være sant, men det Som også er sant Er At Open Web Application Security Project viser Injeksjon som #1 sårbarhet i webapplikasjoner (og det har vært slik i flere år).

Så, hvis du fant deg selv lurer på hvordan du kan forhindre alt dette, la oss oppsummere:

• BRUK ALLTID SSL / TLS når du sender noe til serveren. Det trenger ikke å være legitimasjon, det anses for tiden som god praksis generelt. Selv om du ikke har noen innganger på siden din i det hele tatt! Den enkleste måten er å gi sertifikat via tjenester som La Oss Kryptere.
• Husk at selvsignerte sertifikater kan redusere problemet med dataeksponering, men ikke hindre MITM-angriperen til å forfalske hele nettstedet med sitt eget selvsignerte sertifikat helt.
• når du arbeider MED SQL-spørringer alltid unnslippe parametere hentet fra klienten. Om Våren kan Du bruke NamedParameterJdbcTemplate som også er bra for lesbarhet.
• Vær paranoid. Validere noen brukerinngang. Igjen I Java / Spring world kan du legge til valideringsregler ved hjelp av bønne validering implementering som Hibernate validator og annotate parametere, f. eks.
• Logg eventuelle forsøk på å passere i ugyldig inndata i søknaden. Videre, i tilfelle feil ikke utsett noen implementeringsspesifikk informasjon til klienten.
• Forbedre autentiseringen.
  • hvis mulig, bruk minst 2-faktorautentisering.
  • ikke implementer tilpasset passordlagring eller krypteringsalgoritmer. Det er ekstremt vanskelig å gjøre på egen hånd, og du vil definitivt mislykkes. Det er påvist løsninger som BCrypt.
• LES OG bokmerke OWASP TOP 10. Start med det og deretter gå gjennom sin liste over beste praksis.