hur till hacka unsecure web application

i den här artikeln vill jag visa hur lätt det är att få konfidentiell information från en webbapplikation som… Tja, betalar inte för mycket uppmärksamhet åt säkerheten. Vad jag kommer att arbeta med är ett exempel på Java-program som jag skapade i Spring Boot för demonstrationsändamål. Men attackerna som utförs är giltiga för något annat programmeringsspråk eller ramverk. Vissa sårbarheter och säkerhetsproblem som kommer att demonstreras inkluderar:

• SQL Injection
• känslig dataexponering
• otillräcklig loggning
• trasig autentisering

inställningen

vi kommer att arbeta med en fiktiv webbapplikation som låter dig logga in som användare som ingår i någon grupp. Baserat på användarroll kan han se antingen grundläggande eller konfidentiella data. I det här fallet kommer du att se en lista över anställda i ett företag, deras status etc.

du hittar källorna till den här applikationen i min Github: https://github.com/rapasoft/hackme.

Attack # 1: Man i mitten attack

Tänk dig att du sitter i en restaurang och vill kontrollera något i ansökan ovan. Du ansluter till restaurangens Wi-Fi, öppnar inloggningssidan, anger referenser och får information du vill ha (t.ex. listan över specifika anställda). Vad du kanske inte nu är att dina referenser har äventyrats. Låt oss undersöka inloggningssidan noggrant:

den här applikationen använder inte SSL / TLS (t.ex. ingen https:// – anslutning). Det betyder att all information som skickas kan ses som vanlig text av alla som har tillgång till kommunikation mellan klienten och servern.

det här är precis vad som händer i så kallad Man in the middle attack. Mer specifikt har ARP-spoofing i detta fall använts som ett sätt att förgifta hela nätverket så att angriparen är medveten om allt som händer och kan sniffa på alla paket. Jag kommer inte att gå in på detaljer om hur ARP spoofing fungerar, men kommer att visa det på den här videon:

du kan behöva öppna den här Youtube-videon i ett nytt fönster och helskärm för att se mer information

vad du kan se ovan är att jag har startat Ettercap, som är en omfattande svit för MITM-attacker och utfört ARP-spoofing i mitt lokala nätverk. Under tiden, när användaren (mig via iPad) anger referenser, de är synliga både i Ettercap och i Wireshark (verktyg för nätverkstrafikanalys).

Attack # 2: SQL Injection

fortsatt vår roll som angripare av denna applikation har vi nu referenser för användare hgraves med lösenord P4SSW0RD. Du kan se att inte bara den här applikationen inte använder TLS, den har en mycket svag lösenordspolicy som gör det möjligt för användare att välja riktigt hemska lösenord.

vi loggar in med referenserna ovan och kan se ett inmatningsfält med möjlighet att söka efter lista över personer. När du trycker på Search får vi hela listan över personer. Om vi sätter ”Fra” till exempel får vi filtrerade resultat baserat på sökning. Vad händer om vi lägger dit någon olaglig karaktär? Det är uppenbart att det finns någon databas bakom den här applikationen, så låt oss försöka ' tecknet:

inte bara misslyckades detta, men vi kan se att POST begäran har misslyckats med mycket specifikt felmeddelande som exponerar strukturen för hela SQL-satsen. Vi kan se att WHERE P.NAME LIKE '%'%' används i slutet.

skicklig hacker behöver inte mer. Justering av söksträngen kan efter några försök ge dessa resultat:

injektionen i detta fall skapade union to select uttalande som hämtar användarnamn och lösenord tillsammans med deras roll. Inte bara detta lyckades, vi har lyckats visa det i den ursprungliga klientapplikationen.

vi har nu referenser för alla användare och deras roller (visas av heltalet i kolumnen ”ålder”). Om hframe har Roll 1 måste rgraves därför vara viktigare användare med roll 3.

Attack # 3: Attacking svagt hashade lösenord

vi har lärt oss i den första attacken att det förmodligen inte finns någon lösenordspolicy för denna applikation. Detta skulle ge oss hopp om att rgraves inte betalar för mycket uppmärksamhet på säkerheten heller.

det enklaste sättet att knäcka hash av lösenord som använder otillräcklig hashing algoritm (som MD5 i detta fall) är att utföra ordbok eller rainbow table attack. Det finns många möjligheter, men det enklaste är att använda internettjänster som redan har stor databas med lösenord-till-hash-kombinationer:

den första är hframe, den andra är rgraves. smorgan verkar använda starkare lösenord än andra, eftersom det inte finns i ordboken.

du kan se att lösenordet för rgraves är svärdfisk, vilket innebär att han inte nu hur viktigt det är att välja icke-ordbokslösenord ;). Nu hindrar ingenting oss från att logga in som den här användaren och upptäcka avsnittet ”admin” och konfidentiell information:

läs inte detta om du är tysk 🙂

Hur fixar du det här?

du kan säga att allt detta lätt kan förhindras. Man kan säga att dessa var rookie misstag. Tja, det kan vara sant, men det som också är sant är att Open Web Application Security Project listar injektion som #1 sårbarhet i webbapplikationer (och det har varit så här i flera år).

så, om du befann dig undrar hur du kan förhindra allt detta, låt oss sammanfatta:

• använd alltid SSL / TLS när du skickar något till servern. Det behöver inte vara referenser, det betraktas för närvarande som god praxis i allmänhet. Även om du inte har några ingångar på din sida alls! Det enklaste sättet är att tillhandahålla certifikat via tjänster som Let ’ s Encrypt.
• kom ihåg att självsignerade certifikat kan mildra problemet med dataexponering, men förhindra inte att MITM-angripare förfalskar hela webbplatsen med sitt eget självsignerade certifikat helt och hållet.
• när det handlar om SQL-frågor alltid Fly parametrar som erhållits från klienten. Det enklaste sättet att göra det är att använda funktionerna i ditt ramverk, t.ex. på våren kan du använda NamedParameterJdbcTemplate vilket också är bra för läsbarhet.
• var paranoid. Validera alla användarinmatningar. Återigen i Java / Spring world kan du lägga till valideringsregler med hjälp av JSR-380 bean validation implementation som Hibernate validator och annotate parameters, t.ex. @Pattern(regexp = "*") String name skulle förhindra att du anger '.
• logga alla försök att passera i ogiltig inmatning i programmet. Dessutom, i händelse av fel exponera inte någon implementeringsspecifik information för kunden.
• förbättra din autentisering.
  • använd om möjligt minst 2-faktorsautentisering.
  • implementera inte anpassade lösenordslagrings-eller krypteringsalgoritmer. Det är extremt svårt att göra på egen hand och du kommer definitivt att misslyckas. Det finns beprövade lösningar som BCrypt.
• Läs och bokmärke OWASP TOP 10. Börja med det och gå sedan igenom deras lista över bästa praxis.