How to hack unsecure web application

in this article I would like to demonstrate how easy it is to get confidential information from a web application that… ei kiinnitä liikaa huomiota turvallisuuteen. Mitä aion työskennellä on näyte Java-sovellus, jonka olen luonut Spring Boot esittelytarkoituksiin. Mutta tehdyt hyökkäykset ovat voimassa mille tahansa muulle ohjelmointikielelle tai kehykselle. Joitakin haavoittuvuuksia ja tietoturvaongelmia, jotka osoitetaan ovat:

• SQL Injection
• Sensitive data exposure
• riittämätön kirjautuminen
• rikkinäinen todennus

setup

työstämme kuvitteellista verkkosovellusta, jonka avulla voit kirjautua käyttäjäksi, joka on osa jotain ryhmää. Käyttäjän roolin perusteella hän voi tarkastella joko perus-tai salassapidettäviä tietoja. Tässä tapauksessa näet luettelon yrityksen työntekijöistä, heidän tilanteestaan jne.

tämän sovelluksen lähteet löydät Githubistani: https://github.com/rapasoft/hackme.

hyökkäys #1: Keskihyökkäyksen mies

Kuvittele istuvasi ravintolassa ja haluaisi tarkistaa jotain yllä olevasta sovelluksesta. Muodostat yhteyden ravintolan Wi-Fi: hen, avaat kirjautumissivun, syötät tunnukset ja saat haluamasi tiedot (esim.luettelon tietyistä työntekijöistä). Et ehkä nyt, että valtakirjasi ovat vaarantuneet. Tarkastellaan kirjautumissivua tarkasti:

tämä sovellus ei käytä SSL/TLS: ää (esim.Ei https:// yhteyttä). Tämä tarkoittaa, että kaikki lähetetyt tiedot voidaan tarkastella tekstinä kuka tahansa, jolla on pääsy asiakkaan ja palvelimen väliseen viestintään.

juuri näin tapahtuu niin sanotussa Keskihyökkäyksessä. Tarkemmin sanottuna tässä tapauksessa ARP-huijausta on käytetty keinona myrkyttää koko verkko niin, että hyökkääjä on tietoinen kaikesta, mitä tapahtuu ja voi haistaa kaikki paketit. En aio mennä yksityiskohtiin siitä, miten ARP huijaus toimii, mutta osoittaa sen tällä videolla:

saatat joutua avaamaan tämän Youtube-videon uudessa ikkunassa ja koko ruudussa nähdäksesi lisätietoja

mitä näet yllä on, että olen aloittanut Ettercapin, joka on kattava sarja MITM-hyökkäyksille, ja tehnyt ARP-huijauksia paikallisessa verkossani. Sillä välin, kun käyttäjä (me kautta iPad) syöttää tunnukset, ne näkyvät sekä Ettercap ja Wireshark (työkalu verkkoliikenteen analysointi).

hyökkäys #2: SQL Injection

jatkaen rooliamme tämän sovelluksen hyökkääjänä, meillä on nyt käyttäjän hgraves tunnukset salasanalla P4SSW0RD. Voit nähdä, että ei vain tämä sovellus ei käytä TLS, se on hyvin heikko salasanakäytäntö, jonka avulla käyttäjät valitsivat todella kauhea salasanoja.

kirjaudumme sisään käyttämällä yllä olevia tunnistetietoja ja näemme yhden syöttökentän, jossa on mahdollisuus etsiä henkilöiden luetteloa. Painettaessa Search saamme koko listan henkilöistä. Jos laitamme esimerkiksi ”Fra”, saamme suodatettuja tuloksia haun perusteella. Mitä jos laittaisimme sinne jotain laitonta? On selvää, että tämän sovelluksen takana on jokin tietokanta, joten kokeillaan ' – merkkiä:

ei ainoastaan tämä epäonnistunut, mutta voimme nähdä, että POST pyyntö on epäonnistunut hyvin spesifisellä virheilmoituksella, joka paljastaa koko SQL-lausekkeen rakenteen. Voidaan nähdä, että WHERE P.NAME LIKE '%'%' käytetään lopussa.

taitava hakkeri ei tarvitse lisää. Hakumerkkijonon säätäminen voi muutaman yrityksen jälkeen tuottaa nämä tulokset:

injektio tässä tapauksessa loi unionin valitsemaan statement, joka hakee käyttäjätunnukset ja salasanat yhdessä roolinsa kanssa. Paitsi että tämä onnistui, olemme onnistuneet näyttämään sen alkuperäisessä asiakassovelluksessa.

meillä on nyt kaikkien käyttäjien tunnistetiedot ja heidän roolinsa (näytetään kokonaisluvulla ”Ikä” – sarakkeessa). Jos hframe on rooli 1, rgraves on siis oltava tärkeämpi käyttäjä roolin 3 kanssa.

hyökkäys #3: Hyökkäämällä heikosti hashed salasanoja

olemme oppineet ensimmäisessä hyökkäyksessä, että luultavasti ei ole mitään salasanakäytäntöä asetettu tälle sovellukselle. Tämä antaisi toivoa siitä, että rgraves ei myöskään kiinnitä liikaa huomiota turvallisuuteen.

helpoin tapa murtaa puutteellista tiivistysalgoritmia (kuten MD5 tässä tapauksessa) käyttävän salasanan hash on suorittaa sanakirja-tai rainbow table-hyökkäys. Mahdollisuuksia on monia, mutta helpointa on käyttää internet-palveluita, joissa on jo laaja tietokanta salasanasta hash-yhdistelmistä:

ensimmäinen on hframe, toinen on rgraves. smorgan näyttää käyttävän vahvempia salasanoja kuin muut, sillä sitä ei sanakirjasta löydy.

voit nähdä, että rgraves salasana on swordfish, eli hän ei nyt tiedä, kuinka tärkeää on valita ei-sanakirjasana ;). Nyt, mikään ei estä meitä kirjautumasta sisään tämän käyttäjän ja löytää ”admin” osio ja luottamuksellisia tietoja:

älä lue tätä, jos olet Saksalainen 🙂

miten korjata tämä?

voisi sanoa, että kaikki tämä olisi helposti estettävissä. Voisi sanoa, että nämä olivat aloittelijan virheitä. No, tämä voi olla totta, mutta mikä on myös totta, että avoimen Web-sovelluksen Tietoturvaprojekti listaa injektio #1 haavoittuvuus web-sovelluksissa (ja se on ollut näin useita vuosia).

joten, jos huomasit miettiväsi, miten estää tämä kaikki, kerrataan:

• käytä aina SSL / TLS: ää, kun lähetät jotain palvelimelle. Sen ei tarvitse olla valtakirja, sitä pidetään nykyisin yleisesti hyvänä käytäntönä. Vaikka sinulla ei ole mitään tuloa sivulla ollenkaan! Helpoin tapa on antaa varmenne Let ’ s Encryptin kaltaisten palveluiden kautta.
• muista, että itse allekirjoitetut varmenteet saattavat lieventää tietojen altistumista, mutta älä estä MITM-hyökkääjää väärentämästä koko Sivustoa omalla itse allekirjoitetulla varmenteellaan kokonaan.
• kun käsitellään SQL-kyselyjä, aina poistuu asiakkaalta saadut parametrit. Helpoin tapa tehdä se on käyttää ominaisuuksia oman kehyksen, esim keväällä voit käyttää NamedParameterJdbcTemplate joka on hyvä luettavuus samoin.
• ole vainoharhainen. Validoi käyttäjän syöte. Jälleen Java / Spring Worldissa voit lisätä validointisääntöjä käyttämällä JSR-380 bean validation implementationia, kuten Hibernate validator ja annotate parameters, esim. @Pattern(regexp = "*") String name estäisi 'syöttämisen.
• Kirjaudu kaikki yritykset syöttää virheellistä syötettä sovelluksessa. Älä myöskään virheen sattuessa paljasta asiakkaalle mitään toteutuskohtaista tietoa.
• Paranna tunnistautumista.
  • jos mahdollista, on käytettävä vähintään 2-tekijäistä todennusta.
  • älä ota käyttöön mukautettuja salasanojen tallennus-tai salausalgoritmeja. Se on äärimmäisen vaikeaa tehdä itse ja tulet varmasti epäonnistumaan. On olemassa todistettuja ratkaisuja, kuten BCrypt.
• Lue ja kirjanmerkki OWASP TOP 10. Aloita sieltä ja käy sitten läpi heidän parhaita käytäntöjään.