hoe te hacken unsecure web application

In dit artikel wil ik laten zien hoe gemakkelijk het is om vertrouwelijke informatie te krijgen van een web applicatie die… hij besteedt niet te veel aandacht aan beveiliging. Wat Ik zal werken met is een voorbeeld Java-applicatie die ik gemaakt in de lente Boot voor demonstratiedoeleinden. Maar de uitgevoerde aanvallen zijn geldig voor elke andere programmeertaal of framework. Enkele kwetsbaarheden en beveiligingsproblemen die zullen worden aangetoond, zijn::

• SQL-injectie
• blootstelling aan gevoelige gegevens
• onvoldoende logging
• verbroken authenticatie

de instelling

we zullen werken met een fictieve webtoepassing waarmee u kunt inloggen als gebruiker die deel uitmaakt van een groep. Op basis van de rol van de gebruiker kan hij zowel basisgegevens als vertrouwelijke gegevens bekijken. In dit geval ziet u een lijst van werknemers in een bedrijf, hun status, enz.

je kunt de Bronnen voor deze toepassing vinden in mijn Github: https://github.com/rapasoft/hackme.

aanval # 1: Man in the middle attack

stel je voor dat je in een restaurant zit en iets wilt controleren in de bovenstaande applicatie. U maakt verbinding met de Wifi van het restaurant, opent de inlogpagina, voert referenties in en verkrijgt de gewenste informatie (bijvoorbeeld de lijst met specifieke medewerkers). Wat je nu misschien niet weet, is dat je referenties zijn aangetast. Laten we de login pagina goed bekijken:

deze toepassing Gebruikt geen SSL/TLS (bijvoorbeeld geen https:// verbinding). Dit betekent, dat alle verzonden informatie kan worden gezien als platte tekst door iedereen met toegang tot de communicatie tussen de client en server.

dit is precies wat er gebeurt in de zogenaamde Man in the middle aanval. Meer specifiek, in dit geval is ARP spoofing gebruikt als een manier om het hele netwerk te vergiftigen, zodat aanvaller zich bewust is van alles wat er gebeurt en op alle pakketten kan ruiken. Ik ga niet in detail treden over hoe ARP spoofing werkt, maar zal het demonstreren op deze video:

het kan nodig zijn om deze Youtube video in een nieuw venster en volledig scherm te openen om meer details te zien

wat je hierboven kunt zien is dat ik Ettercap ben gestart, een uitgebreide suite voor MITM aanvallen, en ARP spoofing heb uitgevoerd in mijn lokale netwerk. In de tussentijd, wanneer gebruiker (me via iPad) voert de referenties, ze zijn zichtbaar zowel in Ettercap en in Wireshark (tool voor netwerkverkeer analyse).

aanval # 2: SQL Injection

door onze rol als aanvaller van deze toepassing voort te zetten, hebben we nu de referenties voor gebruiker hgraves met wachtwoord P4SSW0RD. U kunt zien dat niet alleen deze applicatie geen gebruik maakt van TLS, het heeft een zeer zwak wachtwoord beleid waardoor gebruikers koos echt verschrikkelijk wachtwoorden.

we loggen in met behulp van de referenties hierboven en kunnen een invoerveld zien met de optie om te zoeken naar de lijst met personen. Als u op Search drukt, krijgen we de volledige lijst met personen. Als we bijvoorbeeld “Fra” zetten, krijgen we gefilterde resultaten op basis van zoeken. Wat als we er een illegaal karakter in zetten? Het is duidelijk dat er een database achter deze applicatie zit, dus laten we het ' teken proberen:

dit is niet alleen mislukt, maar we kunnen zien dat POST het verzoek is mislukt met een zeer specifieke foutmelding die de structuur van het hele SQL-statement blootlegt. We kunnen zien dat WHERE P.NAME LIKE '%'%' aan het einde wordt gebruikt.

ervaren hacker heeft niet meer nodig. Het aanpassen van de zoekstring kan na enkele pogingen deze resultaten opleveren:

de injectie in dit geval creëerde Unie om een statement te selecteren dat gebruikersnamen en wachtwoorden samen met hun rol ophaalt. Niet alleen dit was succesvol, we zijn erin geslaagd om het weer te geven in de oorspronkelijke client applicatie.

we hebben nu de referenties van alle gebruikers, en hun rollen (weergegeven door het gehele getal in de kolom “leeftijd”). Als hframe rol 1 heeft, moet rgraves daarom een belangrijkere gebruiker zijn met rol 3.

Aanval # 3: Aanvallen zwak gehashte wachtwoorden

we hebben geleerd in de eerste aanval, dat er waarschijnlijk geen wachtwoord beleid ingesteld voor deze toepassing. Dit zou ons hoop geven dat rgraves ook niet te veel aandacht besteedt aan veiligheid.

de eenvoudigste manier om de hash van het wachtwoord te kraken die onvoldoende hash-algoritme gebruikt (zoals MD5 in dit geval) is door een dictionary-of rainbow table-aanval uit te voeren. Er zijn veel mogelijkheden, maar de makkelijkste is om internetdiensten te gebruiken die al een grote database van wachtwoord-naar-hash combinaties hebben:

de eerste is hframe, de tweede is rgraves. smorgan lijkt sterkere wachtwoorden te gebruiken dan andere, omdat het niet in het woordenboek staat.

u kunt zien dat het wachtwoord voor rgraves swordfish is, wat betekent dat hij nu niet weet hoe belangrijk het is om niet-woordenboek wachtwoord te kiezen;). Nu, niets weerhoudt ons van inloggen als deze gebruiker en het ontdekken van de” admin ” sectie en vertrouwelijke informatie:

lees dit niet als je Duits bent:)

hoe los je dit op?

je zou kunnen zeggen dat dit alles gemakkelijk kan worden voorkomen. Je zou kunnen zeggen dat dit beginnersfouten waren. Goed, dit kan waar zijn, maar wat is ook Waar is dat de Open Web Application Security Project lijsten injectie als #1 kwetsbaarheid in webapplicaties (en het is al een paar jaar zo).

dus, als je jezelf afvraagt hoe je dit alles kunt voorkomen, laten we het samenvatten:

• Gebruik altijd SSL / TLS wanneer u iets naar de server verzendt. Het hoeft geen referenties te zijn, het wordt momenteel beschouwd als een goede praktijk in het algemeen. Zelfs als u geen ingangen op uw pagina helemaal! De makkelijkste manier is om certificaat te bieden via diensten zoals Let ‘ s Encrypt.
• onthoud dat zelfondertekende certificaten de blootstelling aan gegevens kunnen beperken, maar voorkomen niet dat MITM-aanvaller de hele site vervalst met zijn eigen zelfondertekende certificaat.
• bij het omgaan met SQL-query ‘ s ontsnappen altijd parameters die van de client zijn verkregen. De makkelijkste manier om dat te doen is gebruik te maken van de mogelijkheden van je framework, bijvoorbeeld in het voorjaar kun je NamedParameterJdbcTemplate gebruiken, wat ook goed is voor de leesbaarheid.
• paranoïde zijn. Alle gebruikersinvoer valideren. Ook in Java / Spring world kunt u validatieregels toevoegen met JSR-380 bean validation implementatie zoals Hibernate validator en annotate parameters, bijvoorbeeld @Pattern(regexp = "*") String name zou het invoeren van 'voorkomen.
• Log pogingen om ongeldige invoer door te geven in de toepassing. Bovendien, in geval van een fout geen implementatie-specifieke informatie bloot aan de klant.
• Verbeter uw authenticatie.
  • gebruik indien mogelijk ten minste 2-factor authenticatie.
  • implementeer geen aangepaste wachtwoordopslag – of versleutelingsalgoritmen. Het is uiterst moeilijk om te doen op uw eigen en je zal zeker falen. Er zijn bewezen oplossingen zoals BCrypt.
• lees en bladwijzer OWASP TOP 10. Begin met daar en ga dan door hun lijst van best practices.